test-drb

test-drb@ccmp.vtda.org

101090 discussions

by dennis＠multiprobe.com

Remember this post Chuck? Don't know if this one comes up too often, but I recently acquired an HP 4145 semiconductor analyzer software diskette. It's SSSD 5.25". If anyone's interested, I can shoot out an image. Cheers, Chuck Are you able to make an image still? Do you want to sell this unit? Thanks, Dennis A. Drew 805.560.0404 Ext. 105 dennis at multiprobe.com Director of Software Engineering Multiprobe Corporation 819 Reddick Street Santa Barbara, CA 93103

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Roy J. Tellason" <rtellason at verizon.net> > Date: Sat, 02 Feb 2008 20:48:33 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Thursday 31 January 2008 10:07, Allison wrote: >> Whats more interesting is there was nothing to prevent a termcap file >> and later improved CP/M work alikes did exactly that and many more things. > >What sort of stuff would you put into the category of "CP/M work alikes"? NOvados, DOS+, ZRdos, Zsdos and ZCPR addons to CP/M. They all could run CP/M programs but added things missing from basic V2.2. The gotacha was they required z80 as they were stuffing all that into the same space required by V2.2. Allison >(Snip) >> Andy Johnson-Laird The Programmers CP/M Handbook went far to extend >> and clarify both what the BIOS can do and more. > >Good book, that one. I dug it out of a box recently, and should probably get >to re-reading it sometime soon, maybe. > >(Snip) >> As you can se the whole interrupt thing was not CP/M as a limiting >> factor but hardware or implementor understanding. > >I'd like to implement something that'd not only use one of those single-byte >calls, but take the data inline, as well -- no need to load it into >registers to pass it along, though there are some rather clumsy aspects to >getting the stack pointer and fixing it... > >> For those that never used a really nice bios try a VT180, it didn't >> do two sided but those disks where just emerging at the time. It did >> implement interrupts with ring buffers for IO. > >Can you point to anything specific with regard to this? > >> The other thing was DMA. On S100 is was a timing and bus nightmare >> and took years to almost get right. Many of the single baord systems >> omitted it as it took space (8257 or later 8237 40 pin chips and a latch). > >Hmm, I seem to have some number of those on hand here. :-) > >> It works fine and made useful systems. However it means the CPU is locked >> up for the duration of the transfer and cannot respond to interupts >> making for poor latency as floppies are slow. Again CP/M doesn't care >> how the transfer happens only that it does happen. So the fist system >> built with DMA was a real eye opener. First it allowed background >> activities to run faster and smoother like a line printer spooler. >> also interrupts could be used byy the disk system to say "ready" >> or "ready with error". Thats a lot of available CPU cycles. >> the biggest areas of change is that modem programs werent pausing >> for disk IO, they could fill a big (say 16k) circular buffer and >> the cpu can be processing interrupts for IO and disk to manage >> transfers rather than doing a lot of waiting in loops. It doesn't >> take a lot more code but the complexity and debugging is greater >> due to the near concurrent activities. > >One of the real problems I had with early BBSing was the fact that I was using >a CP/M box and that had only a lmiited buffer in the modem program (probably >MDM740 at first, IMP a bit later I think), while the guy at the other end >had a newer and higher-speed modem that had several K of buffer in it that it >would continue to empty after my end had asked it to hold on a minute... > >That same program had a print or capture buffer (I forget exactly now) that >was way bigger, something on the order of 16K, and it came to me to use >that for buffering the input rather than the teeny buffer provided, but I >never did get around to making that particular modification to it. > >(Snip) > >-- >Member of the toughest, meanest, deadliest, most unrelenting -- and >ablest -- form of life in this section of space, ?a critter that can >be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters" >- >Information is more dangerous than cannon to a society ruled by lies. --James >M Dakin

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by cclist＠sydex.com

> Date: Tue, 05 Feb 2008 02:20:29 -0500 > From: "Roy J. Tellason" > > I'd already done it for DX-85M > > What's that? Proprietary multitasking operating system, based on the 8085; basically the other end of the spectrum from CP/M. Included built-in- interrupt-driven I/O (including 4 channels of async), file types (i.e. differentiated between executable, data, index, etc.), built-in ISAM files and a bunch of other stuff. One of these days I'll chat about it if anyone's curious. Sometimes interrupt-driven I/O wasn't very good. We used an Intel 8275 CRTC in the CPU and some enterprising engineer decided to hardwire it to DMA channel 1, not 0. On the 8257 DMAC that meant that we couldn't use auto-initialize to keep the display going and basically had to re-initialize the DMA transfer between screens, using an end-of-screen interrupt. Servicing that interrupt 60 times per second was a big drag on the CPU--and if you missed it, the screen would flicker. Re: passing arguments on the stack. It's an interesting exercise on the 8085 using the "undocumented" instructions. For example, opcode 38H, which is a two-byte instruction would take SP, add the second instruction byte and stick the result in DE. Opcode 28H would do the same, but use HL instead of SP. Another 8085 16-bit operation, opcode D9H, would store HL in the address pointed to by DE. Opcode EDh would load HL from the address pointed to by DE. There were a couple of other 16-bit operations in 8085 not documented. 08H would subtract BC from HL, 10H shifted HL right one place with sign extension. 18H rotated DE left one place through the carry flag (i.e. 17 bit rotate). There were a few other instructions of less interest: a couple of jumps that tested for unsigned overflow and a conditional restart to location 40H (RST 8) if the overflow flag was set. With the exception of the double-precision subtract, none of these instructions have close analogues in the Z80 instruction set. Nor, AFAIK, did any commercial products exploit them. It was kind of unfortunate that Intel simply didn't leave blanks in the 8080 documentation for the "do nothing" moves; (e.g. MOV A,A; MOV B,B, etc.). It might have freed up a few more spare opcodes for later exploitation. Cheers, Chuck

18 years, 2 months

Looking for TK50 tapes & RX50 disks...

by silvercreekvalley＠yahoo.com

Many thanks for the info. That's a great help. I'll investigate the newer drive as it sounds like it could be the RX33. I have plenty of DSDD 5.25" disks, so I'll give those a try first. Thanks Ian. ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

18 years, 2 months

Any word on OS/2 for PDP-11?

by shoppa＠trailing-edge.com

I don't follow the mailing list closely, but earlier this month folks were talking about a tape supposedly labeled "OS/2" for the PDP-11. My gut feeling is that this is something like how "ASCII" sometimes becomes "ASC-eleven" or even "ASC2" among those who don't know what's a roman numeral vs digits vs whatever. Possibly DOS-11 became D OS-11 became OS/2 :-). But DOS-11 on a TK50 would be unusual in any event! Finding, say, a late version of RT-11 or RSX-11 or RSTS/E or Ultrix-11 on a TK50 seems far more likely. Almost all PDP-11 OS's have an "11" in the name, usually at the end, and it's easy to see how this could become a "2" in the mind of someone who thinks that there is a VAX named Saul or SOL. Tim.

18 years, 2 months

Any word on OS/2 for PDP-11?

by tshoppa＠wmata.com

Al wrote: > I wrote: >> I think it's time for me to unsubscribe from this list and >> get back to reality. > Talk is cheap. > Let's see the proof. Well, I was trying to give him the benefit of the doubt, that of the zillion layered products that DEC was churning out in the 80's and early 90's that a guy might mistakenly think something was on the tape that wasn't there because of the language DEC or somebody else used on the TK50 tape label. But he tells me I'm insulting his intelligence by suggesting that there may have been some confusion based on his reading of the tape label. He's made it perfectly clear he doesn't want any advice on what was actually on the tape, he's made up his mind, case closed, there was a VAX named Saul and OS/2 for the PDP-11 because he's been using the VAX since the year before it shipped. What else can you or I do, Al? Tim.

18 years, 2 months

GEnie National CP/M RoundTable archives?

by d_cymbal＠hotmail.com

Does anyone have an archive of the files for the GEnie National CP/M RoundTable? I am in the process of putting together a site for the Visual 1050 and there was apparently a section dedicated to the 1050: "Library 37. Visual-1050 CP/M". If possible I would like to include these on my site. I have found several stray entries on the net but have not been able to locate the bulk of the contents (most are named VLIBnn.ARK and described as "Visual 1050 Library Disk #nn"). Any help? Thanks. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

18 years, 2 months

MicroAnglelo text editor

by les＠frii.com

I found a web page by a guy who made his own MicroAngelo clone. Its a pretty neat web page but it hasn't been updated for many years, and he doesn't seem to respond to emails. http://www.infinetivity.com/~delscott/ua.htm

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Roy J. Tellason" <rtellason at verizon.net> > Date: Tue, 05 Feb 2008 01:21:19 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Sunday 03 February 2008 09:19, Chuck Guzis wrote: >> > However while the IO was better CP/M had a far better file system that >> > accomodated fragmentation (scatter/gather) where RT-11 (and NS* DOS) had >> > the linear tag and dump that made enlarging a files or creating variable >> > length files harder. >> >> On the other hand, fragmentation on a floppy can result in very bad >> performance--and CP/M had no "defragment" utility. > >Sure it did. It was whatever you used to format a disk... :-) Seriously, >I'd copy stuff off elsewhere and then with a clean start re-copy it back >again, no fragmentation. Defragger for CP/M is both easy and fun... Use pip to copy the source disk to the destination disk. Best with two or more drives. the real problem is it's hard to defrag with limited on disk space without buffering in ram and thats doable too. >I thought I had remembered one, but can't seem to find it at the moment. > >> I can see the advantages of a system that tends to keep files in a small >> number of pieces. I've seen the single-piece file structure a lot on >> industrial equipment controllers. Makes sense where the file is static in size and whats really being done a loader. what happens if your doing data bases or data collection and the assumed file size exceeds the as built file... oops. >> > Assemble CP/M BDOS at around 100k using ASM and you find any disk under >> > 400K free space is too small. You still see that today with faster disks >> > and interfaces. >> >> CP/M was singularly ill-equipped to support hard disks of any size beyond a >> couple of megabytes. We'd started offering SA-8000 14" drives as an option >> and before too many months, we were getting 40MB drives for what we'd been >> paying for the single-platter ones. 5.25" HD size increases went even more >> quickly. We bought 7 and 14MB drives from Rodime and it wasn't long before >> Rodime was telling us that they were substituting 10MB and 20MB drives. I >> was asked if I could artificially (via software) limit the new drives to 7MB >> and 14MB so that marketing could charge for the extra storage. I >> discouraged the idea very strongly, pointing out that the customers weren't >> stupid--someone was going to peek inside and read the drive nameplate. It supported drives to 8mb as a logical unit. ou can have up to 16(less if you have floppies) logical units (A->P) for a total of 128mb. All of the CP/M derived works starting with P2DOS and on fixed the math inside the BDOS allowing for drives to 1Gb. >Oh yeah. I think if there were one thing I'd like to change about CP/M that >would probably be it, give me a multi-level directory. Last time I gave >that some thought I was considering using something like *.LBR files do, >only in those the utilities commonly used would have you set the number of >entries you wanted to add at the outset, and you had to go through some >stuff to add more or compact it., and compressing/decompressing library >members was a whole separate operation and also had to be done manually. But >I think it's possible. Thae allocation scheme used makes it hard to keep track of how many blocks are used by the content of a subdirectory... you can do it but lots of recursion needed and that means a rewrite of the whole files system code and also compatability issues as none of the apps will have any idea of subdirs. >I did have a "COMMAND.LBR" that was around 600K in size, had all sorts of >stuff in it, though mostly I used a fairly small handful of utilities. > >> But then DRI was really thinking of the "user number" feature as that- >> -there was the system (user 0) and your own files under your number, >> never considering that some users might want to use the feature to >> organize their data and go cross-number frequently. > >Yup, that's exactly what I did. Many of the ZCPR and later improved CP/M work alikes added named directories that equated to user numbers. >Any of you know how some of the CP/M variants dealt with HDs and these other >issues? Briefly CP/M doesn't, the BIOS writer does. Since basic CP/M has a hard limit of 8mb per logical disk drives larger than 8mb are divided into logical partitions as needed. I have many (6 or more) systems with hard disks and all have disks greater than 10MB. The system with a 45mb is partitioned (in bios not using MBR or other dosisms) into 5 logial disks four 8mb and one 5mb. The bios also allows for assigning what partition is what letter though a user utility. I also have a system with a 120mb disk set up so any four 8mb partitions can be "mounted" and "dismounted" as needed. Reason for this is each disk in the BIOS has buffers associated and they can become significant in space used. By limiting the number of active drives I save that space at the cost of only have 32mb on line at any given time. That was a fair trade for a large TPA in a non banked machine. that and by most users even 8 megs of disk in one lump is luxury afer using floppies. Allison

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Roy J. Tellason" <rtellason at verizon.net> > Date: Tue, 05 Feb 2008 02:20:29 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Monday 04 February 2008 14:48, Chuck Guzis wrote: >> I wanted to add a "put that diskette back" alarm to my CP/M >> implementation when there were files opened for writing > >:-) Fortunately it at least did a check for a changed disk. >> It was then that I discovered that CP/M made no attempt to track open >> files and indeed, the behavior of many programs depended on this. > >It wasn't really much of an OS, compared to a lot of what else was out there. I'd argue that CPM is barely an OS annd a should be catagorized as a filesystem and monitor. there are thing it doesn't manage. For some without all the IO bells implemented the IO is notably poor. Allison

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Roy J. Tellason" <rtellason at verizon.net> > Date: Tue, 05 Feb 2008 02:00:47 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Sunday 03 February 2008 07:34, Allison wrote: >> >On Thursday 31 January 2008 10:07, Allison wrote: >> >> Whats more interesting is there was nothing to prevent a termcap file >> >> and later improved CP/M work alikes did exactly that and many more >> >> things. >> > >> >What sort of stuff would you put into the category of "CP/M work alikes"? >> >> NOvados, DOS+, ZRdos, Zsdos and ZCPR addons to CP/M. They all could run >> CP/M programs but added things missing from basic V2.2. The gotacha was >> they required z80 as they were stuffing all that into the same space >> required by V2.2. > >Not much of a gotcha, I don't think I'll be doing much with the 8080 these >days anyhow, and pretty much every single one of the CP/M boxes I have on >hand here are all equipped with a Z80. > >ZCPR I've run across, those others are not familiar to me. Are they out >there and available? Might be worth a look at them if so. Try google and expect a lot of results. They have been out there for years. Allison

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Roy J. Tellason" <rtellason at verizon.net> > Date: Tue, 05 Feb 2008 01:58:20 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Sunday 03 February 2008 07:27, Allison wrote: >(Snip) >Yup, but that assumes that you want two bytes. CP/M would give a function >code and then anywhere from zero parameters to several of varying lengths and >some even were pointers to tables and data areas. You might also want to >bump the return pointer past the data. :-) The general methodology works for any length but I showed it for two. >I think rather than use a scratchpad location to save HL into I just swapped >it with the top of the stack, which would give you HL pointing to the first >byte beyond the call, though it's been several years since I worked on this >and my recollection is a bit more than fuzzy about the whole thing. You can but if you need HL to do 16bit arithmetic of some such you may have to save it. I've done code that passed variable length parameters on the stack but after 3 maybe 5 bytes you have to start storing something somehwere. Even Z80 has a finite number of registers. >> >> Interrupt driven, has some basic terminal sense (vt100 specific) >> and uses IObyte. > >Sounds worth looking at, is it out there anywhere? Never looked but whole VT180s are findable. >(Snip) >> >> Thats a lot of available CPU cycles. the biggest areas of change is that >> >> modem programs werent pausing for disk IO, they could fill a big (say >> >> 16k) circular buffer and the cpu can be processing interrupts for IO and >> >> disk to manage transfers rather than doing a lot of waiting in loops. It >> >> doesn't take a lot more code but the complexity and debugging is greater >> >> due to the near concurrent activities. >> > >> >One of the real problems I had with early BBSing was the fact that I was >> > using a CP/M box and that had only a lmiited buffer in the modem program >> > (probably MDM740 at first, IMP a bit later I think), while the guy at >> > the other end had a newer and higher-speed modem that had several K of >> > buffer in it that it would continue to empty after my end had asked it to >> > hold on a minute... >> >> In many cases no buffer. it was more like the other end would stop but by >> time you told it to your 1 byte maybe 2 buffer overflowed. > >I could be mistaken but I think those early comm programs had something like >128 or 256 bytes of buffer in them. Which was like nothing when the >higher-speed modem on the other end had several K... Makes little differnce as the reall pain is when you have to hit the disk be floppy or hard, most systems the CPU is totoally involved in doing PIO for the disk transfer(expecially floppy) and the rest of the world is left to hang. You have to stop the transfer prior to going to the disk. Many cases that doesnt work well. When you need speed this is where releaving the CPU of that using DMA pays. allison

18 years, 2 months

Digitalker Information

by brain＠jbrain.com

My son and I watched War Games a few nights back, and I pulled out my old Jameco JE520 speech synthesizer. We played with it a bit tonight, and it has a bad EPROM #2, so the upper half of the first word set is garbled. Questions: * Anyone have a JE520 that could copy the ROM? * Or, anyone have other ROMs for the DIGITALKER (soft copies, that is)? * Anyone have a datasheet on this device? NS54104 Jim

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by cclist＠sydex.com

> Date: Sun, 03 Feb 2008 07:34:54 -0500 > From: Allison > NOvados, DOS+, ZRdos, Zsdos and ZCPR addons to CP/M. There were also the independent implementations such as TPM (for the QX-10) and TuboDOS. There were others, even a a couple that provided the capability to run CP/M 2.2 programs under non-CP/M OS Z80 platforms. CP/M, particularly 2.2 was easily cloned. Most applications used the information in the reference manual set and didn't rely on "undocumented" features. IIRC, the bigger problem when MP/M came along, was trying to work with those programs that were just plain sloppy and performed file open requests without closing the file (since CP/M didn't even keep so much as an open file count, you could be very sloppy, even opening a file multiple times or not at all (as long as you filled in the FCB fields correctly). Some programs saved FCBs and then used them later. I wanted to add a "put that diskette back" alarm to my CP/M implementation when there were files opened for writing (one needn't even turn on the drive motor--just periodically sample the write- protect status; a diskette being inserted or removed will toggle it a couple of times). I'd already done it for DX-85M and it reduced our diskette file corruption problems to nearly zero. That "R/O error" diagnostic from CP/M was unreliable at best and nearly useless even when it worked. It was then that I discovered that CP/M made no attempt to track open files and indeed, the behavior of many programs depended on this. Cheers, Chuck

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Roy J. Tellason" <rtellason at verizon.net> > Date: Sat, 02 Feb 2008 20:48:33 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Thursday 31 January 2008 10:07, Allison wrote: >> Whats more interesting is there was nothing to prevent a termcap file >> and later improved CP/M work alikes did exactly that and many more things. > >What sort of stuff would you put into the category of "CP/M work alikes"? > >(Snip) >> Andy Johnson-Laird The Programmers CP/M Handbook went far to extend >> and clarify both what the BIOS can do and more. > >Good book, that one. I dug it out of a box recently, and should probably get >to re-reading it sometime soon, maybe. > >(Snip) >> As you can se the whole interrupt thing was not CP/M as a limiting >> factor but hardware or implementor understanding. > >I'd like to implement something that'd not only use one of those single-byte >calls, but take the data inline, as well -- no need to load it into >registers to pass it along, though there are some rather clumsy aspects to >getting the stack pointer and fixing it... That was easy in 8080. ;routine gets 16bit word passed on stack before call ; doesn't do anthing but put that item in bc RRST: org 010h shld hlsave pop hl ;hl has return address pop bc ; BC has data push hl ; hl back to stack lhld hlsave ; restor hl ret ;caller caller: push bc ;data in bc rst2 ...... >> For those that never used a really nice bios try a VT180, it didn't >> do two sided but those disks where just emerging at the time. It did >> implement interrupts with ring buffers for IO. > >Can you point to anything specific with regard to this? Interrupt driven, has some basic terminal sense (vt100 specific) and uses IObyte. > >> The other thing was DMA. On S100 is was a timing and bus nightmare >> and took years to almost get right. Many of the single baord systems >> omitted it as it took space (8257 or later 8237 40 pin chips and a latch). > >Hmm, I seem to have some number of those on hand here. :-) > >> It works fine and made useful systems. However it means the CPU is locked >> up for the duration of the transfer and cannot respond to interupts >> making for poor latency as floppies are slow. Again CP/M doesn't care >> how the transfer happens only that it does happen. So the fist system >> built with DMA was a real eye opener. First it allowed background >> activities to run faster and smoother like a line printer spooler. >> also interrupts could be used byy the disk system to say "ready" >> or "ready with error". Thats a lot of available CPU cycles. >> the biggest areas of change is that modem programs werent pausing >> for disk IO, they could fill a big (say 16k) circular buffer and >> the cpu can be processing interrupts for IO and disk to manage >> transfers rather than doing a lot of waiting in loops. It doesn't >> take a lot more code but the complexity and debugging is greater >> due to the near concurrent activities. > >One of the real problems I had with early BBSing was the fact that I was using >a CP/M box and that had only a lmiited buffer in the modem program (probably >MDM740 at first, IMP a bit later I think), while the guy at the other end >had a newer and higher-speed modem that had several K of buffer in it that it >would continue to empty after my end had asked it to hold on a minute... In many cases no buffer. it was more like the other end would stop but by time you told it to your 1 byte maybe 2 buffer overflowed. Often the probem with byte at a time IO without interrutps. A more reasonable IO would be buffered 64 or 128 chars sing style with high water marking. Interrupt driven of course. >That same program had a print or capture buffer (I forget exactly now) that >was way bigger, something on the order of 16K, and it came to me to use >that for buffering the input rather than the teeny buffer provided, but I >never did get around to making that particular modification to it. 16k was magical as that was the size of a standard CP/M extent and usually assumed to be enough space for capture. Allison > >(Snip) > >-- >Member of the toughest, meanest, deadliest, most unrelenting -- and >ablest -- form of life in this section of space, ?a critter that can >be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters" >- >Information is more dangerous than cannon to a society ruled by lies. --James >M Dakin

18 years, 2 months

compaq portable plus problems

by marvin＠west.net

When I am using debug to format a HD on an unknown controller, I'll do an unassemble at C800:5 and C800:6. The correct address will have a jmp instruction. Besides the HD formatting program on the utilities disk, going *way* back, I think Western Digital put out a formatting program WDFMT (?) that would allow the formatting of MFM HDs. I think there also might have been some PD/shareware programs to do the same thing. Assuming the Simtel archives are still around, I would expect to be able to find these programs there. > From: Roger Pugh <rogpugh at mac.com> > > does anyone know the correct incantation to low level format an MFM > drive, a rodime 351, driven by a Compaq controller board. > > I,ve tried with debug G=C800:5 to no avail. there is no format program > there!.

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by cclist＠sydex.com

> Date: Sat, 02 Feb 2008 13:07:03 -0500 > From: Allison <ajp166 at bellatlantic.net> > Actually PDP-8 OS8 started that, all the other DEC OSs TOPS-10 and RT had > it as well. "PIP" should be the giveaway. Odd that ISIS used "COPY xxx TO xxx". Some hated the mandatory "TO" in ISIS copy, but I thought it was a good idea. How many times under MS-DOS have you mistakenly typed "COPY D:*.*" and then hit the "enter" key before completing your thought? On faster machines, it makes a mess before you can stop it. The PIP "mathematical" syntax with all the strange options could be confusing in CP/M; some vendors supplied their own version of a file copier. > However while the IO was better CP/M had a far better file system that > accomodated fragmentation (scatter/gather) where RT-11 (and NS* DOS) had > the linear tag and dump that made enlarging a files or creating variable > length files harder. On the other hand, fragmentation on a floppy can result in very bad performance--and CP/M had no "defragment" utility. I can see the advantages of a system that tends to keep files in a small number of pieces. I've seen the single-piece file structure a lot on industrial equipment controllers. > Assemble CP/M BDOS at around 100k using ASM > and you find any disk under 400K free space is too small. You still see > that today with faster disks and interfaces. CP/M was singularly ill-equipped to support hard disks of any size beyond a couple of megabytes. We'd started offering SA-8000 14" drives as an option and before too many months, we were getting 40MB drives for what we'd been paying for the single-platter ones. 5.25" HD size increases went even more quickly. We bought 7 and 14MB drives from Rodime and it wasn't long before Rodime was telling us that they were substituting 10MB and 20MB drives. I was asked if I could artificially (via software) limit the new drives to 7MB and 14MB so that marketing could charge for the extra storage. I discouraged the idea very strongly, pointing out that the customers weren't stupid--someone was going to peek inside and read the drive nameplate. CP/M's single-level directory wasn't suited at all to this kind of thing, even using the "user number" feature--something for which DRI never came up with a command-line syntax to express, which further hurt matters. But then DRI was really thinking of the "user number" feature as that- -there was the system (user 0) and your own files under your number, never considering that some users might want to use the feature to organize their data and go cross-number frequently. Cheers, Chuck

18 years, 2 months

How not to fix a classic mac (or: fried logic boards)

by trag＠io.com

>Date: Tue, 13 Nov 2007 11:17:41 -0600 (CST) >From: "Jeff Walther" <trag at io.com> >Subject: Re: How not to fix a classic mac (or: fried logic boards) >To: cctech at classiccmp.org >Message-ID: <12318.209.163.133.242.1194974261.squirrel at webmail.io.com> >Content-Type: text/plain;charset=iso-8859-1 > >> Date: Mon, 12 Nov 2007 22:45:09 -0800 >> From: Josh Dersch <derschjo at msu.edu> >> First point of business, I discharged the CRT. >> To the main chassis. This, as I have now discovered, is not what you >> are supposed to do to discharge the CRT unless you want to destroy the >> logic board. >That particular failure is documented in Larry Pina's "Macintosh Repair >and Upgrade Secrets" and probably in "The Dead Mac Scrolls" as well. I'd >look it up for you, but I don't have my books with me here. Okay, I'm home, I have my books. It says on page 98 that discharging the CRT without a big honking resistor may blow a 74LS38N (U2) on the analog board and the LAG chip on the logic board. The former sounds like it might be fairly standard. The latter sounds like it may be one of the custom programmed PALs or GALs or whatever that Tony was writing about. I wouldn't be surprised if folks had already figured out all the internal logic for the various Mac 128/512/Plus chips though. Finding it might be a bit of a challenge. OTOH, the LAG chip may be fine and it could be U2 on the analog board that has the problem. Jeff Walther

18 years, 2 months

MC3470

by aek＠bitsavers.org

> Also, does anyone have a proper data sheet for the MC3470 (disk read > amplifier etc). A reasonable description appears in the Semens FD100 service manual. The best analysis of a floppy read channel I have ever read appears here: http://bitsavers.org/pdf/shugart/SA850_450_Read_Channel_Analysis_Dec79.pdf

18 years, 2 months

Q-BUS primer?

by tiggerlasv＠aim.com

On 04-Feb-08, Jerome H. Fine wrote: >Probably your best option is to use the BA23 box. However, for that >option, you really need a quad M8189 CPU (PDP-11/23) >or a quad M8190 CPU (PDP-11/73). >It is entirely possible to use the dual M8186 CPU (PDP-11/23), however, >you will then require a controller with a boot ROM (usually only available >with a 3rd party disk controller) or you will need to enter the >boot program via ODT each time you power on the system. If you look carefully down the list, he's got an M8047 - MXV11 with (P)roms, so he'll be able to use the 11/23 that he already has, and, depending on the roms installed, should be able to perform an MSCP boot. >Entering the boot program manually (by hand one instruction at a time) >takes about 5 minutes. A boot program for the MSCP M7555 controller >is available. Entering bootstrap by hand? Eeek! That is what macros on terminal emulators are for. ;-) ________________________________________________________________________ More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Dave Dunfield" <dave06a at dunfield.com> > Date: Mon, 04 Feb 2008 07:21:16 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >> >I'd like to implement something that'd not only use one of those single-byte >> >calls, but take the data inline, as well -- no need to load it into >> >registers to pass it along, though there are some rather clumsy aspects to >> >getting the stack pointer and fixing it... >> >> That was easy in 8080. >> >> ;routine gets 16bit word passed on stack before call >> ; doesn't do anthing but put that item in bc >> RRST: org 010h >> shld hlsave >> pop hl ;hl has return address >> pop bc ; BC has data >> push hl ; hl back to stack >> lhld hlsave ; restor hl >> ret >> >> ;caller >> caller: push bc ;data in bc >> rst2 >> ...... > >I don't think he was talking about pushing data on the stack, >I thought he was refering to putting the system service request >number inline with the code. The way you can "force that" in cpm is use the above code to call say RST2 where the call is broken out and organized in registers per cpm normal. It also has to preserve registers and adjust the returned data to be on the stack but it's not that bad. >This is exactly what I do on both my DMF (8080) and CUBIX (6809) >OS's. Understood and like it better too. However it's more natural for 6809 where 8080/z80 is kinda clunky around playing with stack. >I use an 'SSR' macro which looks something like (DMF/8080): > >SSR MACRO > RST 2 > DB \1 > END > > >It's fairly easy to fetch this: > >SSRENT: STA savea ; Save accumulator > XTHL ; HL = calling address > MOV A,M ; Get service request number > INX H ; Skip for return > XTHL ; Restore HL & new return address >; Now you have the SSR number in A >; most likely you would use it to index into a handler >; table sith something like: (untested) > PUSH H ; Save application HL > MOV L,A ; L = SSR number > MVI H,0 ; Zero high > DAD H ; x2 for two byte entries > PUSH B ; Save BC > LXI B,JMPTAB ; Point to jump table > DAD B ; Offset to table > POP B ; Restore B > MOV A,M ; Get low address > INX H ; Advance to high > MOV H,M ; Get high address > MOV L,A ; Set low address > XTHL ; Restore HL, dest on stack > LDA savea ; Restore A > RET ; Jump to caller That mkes the code read easier and may be easier to maintain but that hides whats really there unles you unroll the code. > >'JMPTAB' would contain a series of 2-byte addresses of >the individual SSR handlers. > >In practice it's usually a bit more complex ... iirc >in my SSR entry I save most of the registers (so that >the handlers don't have to) and switch to my own stack >(but it's been a very long time so I may be mistaken). > >In the application code, you can then do things like: > > MVI A,'?' ; Get prompt > SSR 3 ; Output to console (two byte OS call) > > >Dave Those are interesting ways to deal with it that I'd not have done. Chalk that up to lack of imagination on my part. Allison >-- >dave06a (at) Dave Dunfield >dunfield (dot) Firmware development services & tools: www.dunfield.com >com Collector of vintage computing equipment: > http://www.classiccmp.org/dunfield/index.html

18 years, 2 months

Simple peer to peer network?

by brain＠jbrain.com

Sellam wants to finish the 64 c64 cluster for the next VCF. I've been researching ideas for communicating among the machines, and the best ideas point to using the two synchronous serial ports on the user port (low wire count, transfers at 250kbps). But, I have grawn a complete blank on plans for a true peer to peer (token based or otherwise) networking protocol. Everything I see is master/slave. RS485 material talks about the hardware layer, but there is no detail on the protocol layer. I would think this would be a well researched and innovated area, low speed communication without a master node. Anyone have any pointers for things to look into? Jim

18 years, 2 months

Good Books

by technobug＠comcast.net

A couple of good books showed up on one of the remainder vender's lists at substantial discount that might be of interest to the list: Item 7036752: Power Supply Troubleshooting and Repair - switch mode power supply repair Item 6324134: Semiconductor Cross Reference Book Found at <http://edwardrhamilton.com/> (mail ordering) <http://www.hamiltonbook.com/hamiltonbook.storefront> (on-line ordering) CRC

18 years, 2 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: Holger Veit <holger.veit at iais.fraunhofer.de> > Date: Thu, 31 Jan 2008 09:53:03 +0100 > To: General Discussion: On-Topic Posts Only <cctech at classiccmp.org> > >Allison schrieb: >>> The great thing about CP/M (and I'm talking about the 8-bit version >>> here) was that it imposed a file system and made disk I/O uniform-- >>> 128 byte sectors, regardless of how the information was actually >>> formatted onto a drive. CP/M was really primitive when it came to >>> console I/O, giving only about 3 functions for output and input each. >>> No cursor positioning or screen control; basic TTY style I/O. And, >>> while there was an IOBYTE facility to redirect I/O, implementation >>> was very nonuniform between vendors. >>> >> >> Things like Termcap and the lise were not needed. However the console >> IO was not so good. Try printing a string containing $ using the print >> string call. The other was passing 8bit data when needed. >> >Termcap was very needed, but not present. Net result was that almost any >software that required terminal control beyond backspace and CRLF had to >be tweaked manually. IN that sense yes. Is it requried of the OS no. Does the OS need it, no. CP/M was minimal as it's day ram was expensive interms of cost, power and space. Was it short sighted, yes. Would it have been implmented right in 1975? No as terminals were just starting to have basic intelligence and maybe 2-3 years later what would the requirements be like? > I remember having written code to fit in the >Wordstar patch area to adapt to some obscure or not so obscure terminal >dozens of times. Termcap and terminfo under the various Unixes of the >time was god-sent then even if some entries were plainly buggy - maybe >just estimated from some hear-say information. Many others too like Vedit. It was a one time task, not nice but compact. Whats more interesting is there was nothing to prevent a termcap file and later improved CP/M work alikes did exactly that and many more things. The bottom line is sans BIOS where do you put termcap in a OS thats only 5.5KB? As to unix, it was the big machine OS and was not going to run on a 256kb floppy. It was only popular in academic and research and far from mainstream till the mid 80s. >The print string BDOS function was indeed an example that was almost >immediately replaced by do-it-yourself routines, often by using the '\0' >delimiter (which then caused trouble with slow terminals that require >some delaying NUL bytes after a CRLF). Or the +80H (end of line on high bit set). >> IObyte was mostly uniform, the problem was often it wasnt even >> implemented. This was a problem of allowing the BIOS spec to be >> minimal and it usually was. >> >IO byte, besides as you correctly remarked not being implemented at all, >was outdated soon after CP/M was released for the Altair. I haven't seen >many paper tape readers and punches connected to CP/M systems for >serious business work. IObyte did not take care of additional devices >beyond the 4 standard devices; it did not deal well with additional >serial or parallel ports for more terminals and printers. This resulted >in unofficial BIOS extensions to get such available hardware into the >boat, and again unportable programs to swap vectors in to BIOS to write >output to a second printer, for instance. Needless to say that >"well-written" software to use the IOByte failed to use these additional >devices - there was even software that insisted that PTP is dumb and AUX >is intelligent, so abusing these pseudo devices for two printers >resulted in different behaviour. Paper tape and Punch were rare in most CP/M systems and often unimplmented. I tend to implment the console and list fields (upper and lower two bits) completes to use the printer ports and second (and third serial if available). Andy Johnson-Laird The Programmers CP/M Handbook went far to extend and clarify both what the BIOS can do and more. >> Ignorant, I think no, they gave the hooks and basic requirements. It >> was up to the BIOS developer to do a good job or just enough. I've >> repeatedly posted that if anything CP/M prevents little and you can >> do a great deal at the bios level to really deliver a better system. >> The best way to illustrate this is try a system with basic IO and one >> with a full interrupt drive IO. The first thing you notice is the >> ability to type ahead and the system feels more responsive. >> >Since the BIOS reduced the available space for BDOS and TPA - which >admittedly improved with CP/M+, which, however, IMHO came too late - >many vendors came up with a not so elaborate BIOS but rather tweaked the >sample code from DRI. It was plainly easier to add some custom program >to directly hack the non standard hardware than extend the BIOS with >useful, clever and portable features. What has been the GHz mania of the >processor later was at that time the "xxK TPA available" selling argument. Actually I'm running system with CP/M-V2.2 that page the BIOS and have multiple hard disks and a tpa in the 62-63k range. CP/M+ is not required to achive that. But both approaches need some kind of memory paging and the ram/rom and a BIOS to support it. The otehr issue is most developers didn't have a useful system interrupts or were time pressed enough to feel that it was worth it. By useful interrupts I mean.. most early S100 8080 machine if you pulled the interupt line the default was vector to 38H as that was RST7 (11111111b) which happend as a result of pull up resistors. that location is ued by DDT for trap. Early Z80s also did that. later 8080/8085 and Z80 systems implmented basic vectored interrupts so how you could use RST 2 through 6 and that meant resonable interrupt drivers wer possible. The Z80 SBCs like Ampro and others that used the Z80 peripherals all had the Z80 vectored system which was powerful and a bit intimidating to those that hand not used them before. As you can se the whole interrupt thing was not CP/M as a limiting factor but hardware or implementor understanding. For those that never used a really nice bios try a VT180, it didn't do two sided but those disks where just emerging at the time. It did implement interrupts with ring buffers for IO. The other thing was DMA. On S100 is was a timing and bus nightmare and took years to almost get right. Many of the single baord systems omitted it as it took space (8257 or later 8237 40 pin chips and a latch). It works fine and made useful systems. However it means the CPU is locked up for the duration of the transfer and cannot respond to interupts making for poor latency as floppies are slow. Again CP/M doesn't care how the transfer happens only that it does happen. So the fist system built with DMA was a real eye opener. First it allowed background activities to run faster and smoother like a line printer spooler. also interrupts could be used byy the disk system to say "ready" or "ready with error". Thats a lot of available CPU cycles. the biggest areas of change is that modem programs werent pausing for disk IO, they could fill a big (say 16k) circular buffer and the cpu can be processing interrupts for IO and disk to manage transfers rather than doing a lot of waiting in loops. It doesn't take a lot more code but the complexity and debugging is greater due to the near concurrent activities. >>> Likewise, it wasn't MS-DOS that was the great advance for the IBM PC >>> platform, but rather the well-documented BIOS and I/O interfaces. >>> Heck, PC-DOS 1.0 wasn't that different from CP/M-86--you still had to >>> do your disk I/O through FCBs, just like CP/M. I believe, to this >>> day, you can still issue your DOS calls by loading (CL) with the >>> request number and calling TPA:0005. >>> >CP/M-86 and MS DOS were initially designed to allow a simple 8080->8086 >cross translator to run the whole set of already existing CP/M >applications without reinventing the wheel. Later DOS versions added >Xenix compatible calls (equivalents of Unix raw I/O: open, close, read, >write, lseek, unlink) but often still the well-understood FCB crap was >used. The call to TPA:0005 is still present in contemporary MS-DOS >versions, as well as INT21h calls; Thats what I believe in too for dos. >however today the "DOS box" under Windows just prepares the environment >for such old DOS programs and uses virtualization to fake an existing >DOS. You can't trace an INT21h call any longer into an MSDOS.SYS or IO.SYS. Yes thats true after NT flavored took over (NT, Win2k XP and likely vista). for win 3.1x it was dos with gui and for Win9x dos was very much there. I ahve Dos7 and dos8 which is extractable from win9x. Nothing worth reporting there. :) Allison > >-- >Holger >

18 years, 2 months

Q-BUS primer?

by dave06a＠dunfield.com

Hi Guys, Recently acquired a goodly amount of DEC gear - I had put the Q-BUS stuff aside while I got the "all in one" VAXstation/VAXservers up and running, but I'm starting to collect information - I've no experience whatsoever with Q-bus, but from what I've read, I understand that it will take a bit of research to determine how to properly configure and position the boards. I'm hoping that I have enough material to built up at least one (possibly 2) nice little PDP-11's, and/or a MicroVax II) At this point, all I'm really looking for is a good "starting point". Can anyone recomment a good document/resources for a Q-bus newbie? Btw, this is what I've got - If there's anything I'm obviously missing, or will have to find extra parts for, please advise me so that I can start looking... Three chassis: BA-23: complete with outer shell and end caps. It bears a "MicroVAX II" label on the console switch panel, and has a floppy drive (dual disk) installed in it. I don't know the model numbers for the next two: - One looks like a BA32 but smaller, and has the "3-switch" PDP console/display panel on it. The cards are inserted from the front beside the panel. - The last one is the smallest, looks much like the one above, complete with 3-switch console/display panel, however instead of metal side/top/bottom plates, it has a "wire cage". It also has a second expansion chassis of similar construction with no power supply or console panel. I've got the following DEC Q-BUS cards: (Descriptions taken from the "Field Guide to Q-BUS and Unbus modules" M3106 4-line async M7264 11/03 processor with 4-Kword RAM M7504 Ethernet adapter (older DEQNA) M7546 TMSCP controller for TK50 M7555 Winchester and floppy disk controller M7606 MicroVAX II KA630 M7608 x2 2/4 MB RAM (boards are fully populated) M7940 x2 SLU Module M7944 x3 4-Kword RAM M7946 x2 RX01 floppy disk controller M8043 x2 4-SLU peripheral interface M8044DB x2 32Kword RAM M8044DF x2 32Kword RAM M8047 RAM, Async, ROMs M8186 11/23 CPU M9047 Grant continuity M9400YA 120-ohm terminators with refresh & floppy boot M9400YE Headers and 250 Ohm resistors I've also got the following third party cards - I don't know anything about these, other than the identifying marks found on the boards listed below - if anyone can provide more information on these, that would be helpful: (Several of them appear to be media controllers of one sort or another). Andromedia Systems UDC-11 rev H (50 pin connector at front edge) Micro Technology Inc. MSV05B (x2) (50 pin connector at front edge) TD Systems TDL-11H/A (50 pin connwctor at front edge) Xylogics "Wizard 1" (50 pin connector at front edge) SDC-RXVZ1 "8202 FD Controller" (50 pin connector at front edge) Versatec LSI-11 P/P Interface (40 pin connector at front edge) Sigma Information Systems Assy 40100 - This board has one 40 + one 50 pin connector, and a place to populate another 40 pin - none are at the front edge. W951 "Flip Chip" - This board has places for various sized chips (most of them populated) with pins to wire-wrap connections between them - looks like some sort of prototyping board. + A couple of the little grant continuity boards. I don't expect this to be a short journy, but it should be interesting... Thanks in advance for any advice/tips. Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html

18 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb