test-drb

test-drb@ccmp.vtda.org

101090 discussions

by cclist＠sydex.com

> Date: Sat, 10 May 2008 12:29:24 -0400 > From: Dave McGuire > I dunno Chuck...the only reason more CP/M systems weren't ROM- > resident back in the day was due to convention, not technical > restrictions. I (personally) don't think there's anything > non-"period" about ROM-ing CP/M. It's not the ROM-ing of CP/M that disturbs me, but rather the "disklessness" of the thing. Wasn't the whole idea of CP/M originally to give you something to manage files on your floppy drives? I mean, that's what the bulk of the code in CP/M is for-- heaven knows, the support for other I/O is nothing to write home about. If one wants to enjoy a "vintage" experience, what sense is there in being diskless? At any rate, even something as simple as a WD1770- type controller added to the design would give that capability with a minimum of support "glue". Alternatively, one could stay diskless and add a sound-effects module to emulate the "chunk" and "grrr" of a head-load and seek--and the "thunk-click" of a drive door being opened and a floppy inserted. I still don't have the hang of this "vintage" thing yet, probably because I'm vintage myself. Please forgive my density... Cheers, Chuck

17 years, 11 months

cctalk Digest, Vol 57, Issue 24

by aek＠bitsavers.org

> I spent 15 years at Apple. My suspicion is Ron is probably still there. He was, the last I heard. He's one of the senior system architects, like Dave Conroy, that you will never hear anything about outside The Fruit.

17 years, 11 months

DOS/Floppy backup program benchmarks

by cclist＠sydex.com

> Date: Sun, 11 May 2008 22:35:36 -0500 > From: Jim Leonard > If I missed an obvious one that runs on XT-class hardware, let me know. I think I might have a couple to add to your list. I know I have an earlier version of FastBack that *does* use a proprietary format. I can shoot you a copy if you're interested. Cheers, Chuck

17 years, 11 months

any STD bus users or developers?

by jeffj＠panix.com

I'm getting the itch to get back to Z80 stuff. Has anyone used the STD bus, or have any parts? I have a few card cages and cards but never enough I/O cards! In the least, I was planning on using the STD bus just for expansion cards to a single board computer. -- Jeffrey Jonas

17 years, 11 months

IBM 5150 seen in movie

by jgessling＠yahoo.com

In "Broadcast News" during the big layoff scene there is at least one clear shot of a 5150. I think it was a dual floppy model. Regards, Jim ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

17 years, 11 months

cctalk Digest, Vol 57, Issue 24

by cclist＠sydex.com

> Date: Sun, 11 May 2008 16:25:18 -0700 > From: Al Kossow > It was Sidhu, Ron Hochsprung, Larry Kenyon, and Alan Oppenheimer > > http://www.patentstorm.us/patents/4689786-fulltext.html > > Ron came up with the low-level stuff. He also did the PC Appletalk > card and firmware (and tons of other stuff since then). Would this be the same Ron Hochsprung who served as the computer center manager at IIT in Chicago around 1967? Cheers, Chuck

17 years, 11 months

Minimal CP-M SBC design

by cclist＠sydex.com

Allison wrote: > It would not be diskless only floppy less. Er, I don't what to get into the subject of what a "disk" is, but I'll concede that the beast would have secondary storage. > IF you really want to enjoy the vintage experience you can include a > floppy controller but be warned...They are a PAIN to use and program. > The most important detail is the unless you include DMA (more parts) > the cpu does all the heavy lifiting in real time and that requires > tight code or some hardware tricks (more parts). It stops getting > simple real fast. Then there are the various floppies with their > interface quirks. I disagree--I've been known to program a floppy controller or two in my time and never found them particularly nasty--except for the WD1781 which had a really annoying tendency to hang during some operations. WD never fixed that--the 'B' part still had the problem when they discontinued it. Our fix involved timing the operation and then resetting the controller if it went out to lunch. So when the PC came along when a drive-not-ready condition would cause the 8272 to hang, it seemed like old home week. (Does anyone have a datasheet for the WD1781? I can't seem to locate my copy anymore.) A WD1770 is very easy program (as are most of the WD x7xx parts), requires very little in the way of interface logic and can be serviced with non-DMA data transfers, even on a 2MHz 8080. (Herb Johnson has a good section on floppy transfer vs. CPU speed on his retrotechnology.com site.) A 4MHz can easily handle DD 8" drives without DMA, which should mean that HD 1.44MB drives should also work. Don Tarbell's first 8" controller handled SD 8" on a 2MHz 8080 quite reliably. The topic interested me at one time because I wondered if it was possible to read DD 8" floppies without DMA with a 2MHz 8080. I think it is, but you have to resort to some strange programming tricks. I believe that Herb has my notes on this. Cheers, Chuck

17 years, 11 months

Is this the smallest PDP-11 compatible?

by cclist＠sydex.com

Date: Sun, 11 May 2008 21:44:31 -0700 (PDT) From: "Eric Smith" > No, the MK-90 is smaller, and weighs only 0.7 kg: > > http://www.taswegian.com/MOSCOW/mk-90.html > > When I first heard of it I was skeptical of the claim that > it used a PDP-11-compatible processor, but since then I've > verified it by actually running my own PDP-11 code on one. Hmmm. My guy has it listed under "calculators". But I think the MK 87 might even beat the MK-90: http://www.leningrad.su/museum/show_calc.php?n=173 It's not clear that one can actually get to the CPU at a machine- language level, however. Cheers, Chuck

17 years, 11 months

DEC8235 ICs

by bob＠jfcl.com

Does anybody know of an equivalent or source for replacement DEC 8235 ICs? They're AND-OR-INVERT gates used as bus drivers on the TD8E (and probably other OMNIBUS boards). Thanks, Bob Armstrong

17 years, 11 months

DOS/Floppy backup program benchmarks

by trixter＠oldskool.org

The question of which DOS-era floppy backup program was "best" has always bothered me over the years, so today I spent the better part of an afternoon satisfying my curiosity. (By "floppy backup program", I mean programs that intelligently used high-speed DMA to format and write backup data while the computer was doing other things in the background, like reading from the hard disk and compressing the data.) Results are here, for the curious: http://www.oldskool.org/guides/dosbackupshootout If I missed an obvious one that runs on XT-class hardware, let me know. -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

17 years, 11 months

Miniscribe 6085

by bear＠typewritten.org

Can somebody with a Miniscribe 6085 tell me the value (or at the very least the color code) of the inductor near CR16, RP17, Q17, C59, etc. ? (the actual location marking on my board is under the component). It's at the edge of the board, toward the back of the drive. Mine is charred and unreadable. Thanks! ok bear

17 years, 11 months

Early Appletalk; was Re: Interconnecting classic computers

by aek＠bitsavers.org

>>I was almost like they were re-inventing Ethernet. :-) > When Sidhu started on that project ethernet was still pretty nascent. It was Sidhu, Ron Hochsprung, Larry Kenyon, and Alan Oppenheimer http://www.patentstorm.us/patents/4689786-fulltext.html Ron came up with the low-level stuff. He also did the PC Appletalk card and firmware (and tons of other stuff since then). Ron also did AppleNet for Lisa.

17 years, 11 months

Minimal CP-M SBC design

by ajp166＠bellatlantic.net

> >Subject: RE: Minimal CP-M SBC design > From: "Barry Watzman" <Watzman at neo.rr.com> > Date: Sun, 11 May 2008 11:16:18 -0400 > To: <cctech at classiccmp.org> > >RE: "1.4 really didn't even do a DISK bios, it was embedded in the bdos. >the bios for 1.4 was only terminal, punch reader and printer IO. Yes, it >was a pain to interface any new disk to it." > >Allison, that is simply not true. The diskette format (DPH and DBP) was >imbedded in the BDOS, but the disk I/O was in the BIOS, more or less like >2.x. Right and sorta right. When you get down to it thats nearly as bad. But your right the hardware was tweekable but the hardware was always assumed to be 8" SSSD in the end. Being able to easily alter the media dimensions (DPH and DPB) allowed for larger media and more varied media. Allison

17 years, 11 months

Minimal CP-M SBC design

by ajp166＠bellatlantic.net

> >Subject: RE: Minimal CP-M SBC design > From: "Chuck Guzis" <cclist at sydex.com> > Date: Sun, 11 May 2008 10:24:57 -0700 > To: cctalk at classiccmp.org > >> Date: Sat, 10 May 2008 08:26:41 -0400 >> From: Allison > > >> Do a A>:ASM BIGFIL.AAB and forget the disk in B: and you remember >> why you hate that. > >Or doing "ASM BIGFIL.ASM" or even just "ASM". I got into the habit >of using M80/L80 as soon as I got my hands on a copy. DRI assemblers >(even RMAC) weren't any great shucks. > >> But then I wa an early adptor of hard disk and from late '80 on >> had at least a 5mb drive to avoid that. Is that less authentic? >> By the end of 1981 I'd built a system with romdisk and ramdisk >> and no floppy or har disk. Was that authentic? > >I think I failed to make my point well enough. Almost all the people >who worked with CP/M initially did so in the context of floppy disks. >Someone attempting to duplicate that experience would get a less-than- >authentic experience without that aspect, in much the same way one >would be deprived of the experience of big mainframe iron without the >machine room noise level. Could you get a true experience of running >OS/360 without a card reader? An authentic experience consists of >all aspects of the experience, not just the convenient or pleasant >ones. Without the whole, one gets a "dude ranch" picture. For the latter without the card reader you couls substitute the tape or even first floppy based job feeds. As to CP/M if you want the pain oops wrong disk grab an old PC and dont use hard disk with DOS. IT's somthing that one likes to forget quickly. Floppies and CP/M the major issues were lack of space, not enough drives and some cases systems that could crunch (on power off or power fail) media left in drive (data lost). Authentic yes, get as much done NO. Every ones had to learn those fast and after that it was part fo the psyche and largely forgotten save for lack of space and not enough dives. >> What is authentic? To me if the platform has 8080, 8085, >> Z80, Z180/64180, Z280, or NSC800 it's running on real iron. Of >> course if you have a Z380 or eZ80 in native mode or a NEC V20 >> in 8080 mode those may count too. > >No, one gets extra bugs with a V20 that the 8080 never had. ;) but they are Authentic. >> 1.4 really didn't even do a DISK bios, it was embedded in the bdos. >> the bios for 1.4 was only terminal, punch reader and printer IO. >> Yes, it ws a pain to interface any new disk to it. > >Not according to my archives. While it's true that the 1.4 BIOS >lacked the configurability of 2.0/2.2 (i.e. there were no DPBs, etc. >to define your own disk format), it contained the disk access code >(e.g. SELDSK, SETTRK, etc.) If you'd like, I can send you a copy of >the CBIOS that came with my Tarbell controller, complete with >Processor Technology video board driver (which I didn't use). It's >remarkable in one aspect--it allows for simulated 2-drive operation >on one drive by prompting for the A: or B: floppy when required. > I have 1.4 for 8" and NS* Horizon (still running!) and their respective manuals. Your right I forgot that NS* created a second level bios strictly for the terminal, printer, punch, reader part of the interface. That part if the ihterface is very lightly doumented in my Alteration Guide. >CP/M 1.4 had the right idea--it supported only one diskette format, >so if you had more than 250K of storage, you were pretty much forced >to accommodate this by simulating multiple floppy drives. (Wasn't >there an early system that used an IMI "shoebox" drive for the Apple >II that simulated about 50 floppies?) Where things got out of hand >is when DRI said "Roll your own" with no guidance as to disk format >standards. > >> It is in 2.0 (deblocking). However their explanation is thin and >> some of the fine details have to be infered by really reading the >> code. It was very mysterious when I did it for the first time back >> in '80 when I was working with a early sample 765 DD FDC. It was >> later that Andy Johnson-Laird wrote The Programmers CP/M Handbook >> which covers the subject in much greater detail and has two BIOS >> exammples that are very commented. > >It's been years since I've chatted with Andy. My acquaintance with >him began after his book, however and I hadn't even realized that >he'd done anything with CP/M. > I'd say he write "the book" that explains things from both the bios/systems perspective and the applicatiosn programmers eye view. It's the book I refer everyone too after the Alteration Guide has confused, narrowed and limited their view of what can be done. I've always maintained that CP/M was a UI and filesystem mostly and there was little it prevents and mostly allowed anything. It did a far job of hardware abstraction and mostly kept out of the way. Allison >Cheers, >Chuck

17 years, 11 months

Early Appletalk; was Re: Interconnecting classic computers

by earl＠baugh.org

>> I guess there's nothing quite like the not invented here syndrome. > > Certainly some of that, but more in Appletalk v2 and than original > Appletalk. To my mind the original appletalk was simple and elegant > - a > good fit for the system... At a company I worked at we looked at Ethernet at the time, and it simply was way too pricey compared to AppleTalk at the time. Phone wire was cheap, and the office spaces we had were already wired up for two phone jacks, so it simply was a matter of isolating the punch down blocks for which jacks to use. (Luckily the folks who wired up the spaces put all the even numbered jacks on the same blocks, odds on the others... ) For the cost of one ethernet card (for the one machine we had that actually could take one) we wired up two offices, probably a couple hundred machines. (Mostly Mac's of course... but ultimately a few Caymen Gator boxes to bridge to the small ethernet segments that supported our Sun boxes...which had ethernet built in..) It was chatty, protocol wise, but a very cost effective way to network things at the time... I've actually got a NEW in the box Farallon PhoneNet (which was yet another name for it..) Star Controller sitting here. (I tried to sell it on EBay recently but apparently nobody has any of these networks that I can find. ) It's about to go into the recycler pile... (if someone is interested, drop me a line...) Earl

17 years, 11 months

Minimal CP-M SBC design

by cclist＠sydex.com

> Date: Sat, 10 May 2008 21:07:12 -0700 > From: dwight elvey > The metal blades will dull quickly on fiberglass boards. The cutting > disk will work but tend to gum up. You can do a lot of damage with a Dremel, the big problem being that it's hand-held. This is one case where I might be tempted to use a jeweler's frame saw and use as many blades (they're very cheap) as needed to get the job done. Alternatively, a small carbide bit in a table-mounted router would do the job in a jiffy. Personally, I'd just find out if the IC was available in PLCC. Cheers, Chuck

17 years, 11 months

STD bus cards

by cclist＠sydex.com

> Date: Sat, 10 May 2008 20:50:33 -0400 > From: "Roy J. Tellason" > Oh, and these aren't STD bus, which is 56 pins rather than 22/44. :-) Yeah, I know. My wondering was that there was an abundant common source of small-profile cards that might be adapted to an 8-bit bus and wondering if they were still common at all. Although there are fewer pins, I do remember mounting a small "sub- bus" in my MITS 8800 using these as a "cheap" expansion for little peripheral projects where an S-100 card was overkill. I basically brought the 8 bits of data and 8 bits of address out with the I/O port handshaking lines to a card. Most peripherals don't need access to RAM I/O space anyway. Does anyone recall what the original application of the 22/44 cards was? I suspect industrial control or maybe telco switching. Cheers, Chuck

17 years, 11 months

Minimal CP-M SBC design

by cclist＠sydex.com

> Date: Sat, 10 May 2008 08:26:41 -0400 > From: Allison > Do a A>:ASM BIGFIL.AAB and forget the disk in B: and you remember > why you hate that. Or doing "ASM BIGFIL.ASM" or even just "ASM". I got into the habit of using M80/L80 as soon as I got my hands on a copy. DRI assemblers (even RMAC) weren't any great shucks. > But then I wa an early adptor of hard disk and from late '80 on > had at least a 5mb drive to avoid that. Is that less authentic? > By the end of 1981 I'd built a system with romdisk and ramdisk > and no floppy or har disk. Was that authentic? I think I failed to make my point well enough. Almost all the people who worked with CP/M initially did so in the context of floppy disks. Someone attempting to duplicate that experience would get a less-than- authentic experience without that aspect, in much the same way one would be deprived of the experience of big mainframe iron without the machine room noise level. Could you get a true experience of running OS/360 without a card reader? An authentic experience consists of all aspects of the experience, not just the convenient or pleasant ones. Without the whole, one gets a "dude ranch" picture. > What is authentic? To me if the platform has 8080, 8085, > Z80, Z180/64180, Z280, or NSC800 it's running on real iron. Of > course if you have a Z380 or eZ80 in native mode or a NEC V20 > in 8080 mode those may count too. No, one gets extra bugs with a V20 that the 8080 never had. > 1.4 really didn't even do a DISK bios, it was embedded in the bdos. > the bios for 1.4 was only terminal, punch reader and printer IO. > Yes, it ws a pain to interface any new disk to it. Not according to my archives. While it's true that the 1.4 BIOS lacked the configurability of 2.0/2.2 (i.e. there were no DPBs, etc. to define your own disk format), it contained the disk access code (e.g. SELDSK, SETTRK, etc.) If you'd like, I can send you a copy of the CBIOS that came with my Tarbell controller, complete with Processor Technology video board driver (which I didn't use). It's remarkable in one aspect--it allows for simulated 2-drive operation on one drive by prompting for the A: or B: floppy when required. CP/M 1.4 had the right idea--it supported only one diskette format, so if you had more than 250K of storage, you were pretty much forced to accommodate this by simulating multiple floppy drives. (Wasn't there an early system that used an IMI "shoebox" drive for the Apple II that simulated about 50 floppies?) Where things got out of hand is when DRI said "Roll your own" with no guidance as to disk format standards. > It is in 2.0 (deblocking). However their explanation is thin and > some of the fine details have to be infered by really reading the > code. It was very mysterious when I did it for the first time back > in '80 when I was working with a early sample 765 DD FDC. It was > later that Andy Johnson-Laird wrote The Programmers CP/M Handbook > which covers the subject in much greater detail and has two BIOS > exammples that are very commented. It's been years since I've chatted with Andy. My acquaintance with him began after his book, however and I hadn't even realized that he'd done anything with CP/M. Cheers, Chuck

17 years, 11 months

TDL Zapple Monitor Listing

by ddsnyder＠zoominternet.net

To all, Found this while cleaning out some old S100 stuff. A source listing for the 8080 Zapple Monitor from Computer Design Labs, Trenton, NJ dated 1979 and 1980. Funny it is named the "Apple" monitor, I supposed maybe Apple was not pursuing naming IP as it did later.. The listing is bound in a spiral type binding and I believe I purchased it sometime in that time frame. I'm feeling a bit old now.... It is free (plus S&H) to the first to reply. Dan, Butler, PA

17 years, 11 months

Minimal CP-M SBC design

by Watzman＠neo.rr.com

RE: "1.4 really didn't even do a DISK bios, it was embedded in the bdos. the bios for 1.4 was only terminal, punch reader and printer IO. Yes, it was a pain to interface any new disk to it." Allison, that is simply not true. The diskette format (DPH and DBP) was imbedded in the BDOS, but the disk I/O was in the BIOS, more or less like 2.x.

17 years, 11 months

Minimal CP-M SBC design

by ajp166＠bellatlantic.net

> >Subject: Re: RE: Minimal CP-M SBC design > From: "Chuck Guzis" <cclist at sydex.com> > Date: Fri, 09 May 2008 09:36:31 -0700 > To: cctalk at classiccmp.org > >> Date: Thu, 08 May 2008 07:50:46 -0400 >> From: Allison > >> I can make the boot process easier as you can plop the rom in >> mappable space. The usual arguement is can you get a Z180 >> in a package most people are willing to deal with (64pin dip)? > >I wouldn't want to deal with the DIP as it's a "skinny" DIP with >0.050 pin spacing, unlike, say, the 68K. While it probably makes >little difference on a PCB, it requires an adapter if you're >prototyping--and sockets are hard to find. It's easier to use the 68 >pin PLCC to keep the spacing--smaller footprint too. Cant argue with that but many are put off by that and discard playing with Z180. >> The latter is the shadow rom many have refered to. I usualy do that. >> And make the rom BIG so not only can I map it in when I want but also >> access part of it (ROMDRIVE). > >I believe the Amstrad Joyce uses the printer controller to force the >necessary boot code onto the Z80 bus. (Tony?) At least I've never >seen a boot ROM on a Joyce PCB. Ther are a lot of way s to stuff in code, the real trick is doing with few parts as wirewrapping or other build strategies are labor intensive and "kitting with a board" is cost sensitive. >> There is no requriement to boot the system from "disk" >> and making that change can make bring up simpler. > >But that's where the "authentic" aspect fails me. Why run a >"vintage" CP/M system without the experience a disk drive gives you? >You'll be deprived of the "BDOS Err on B:" messages. What fun is >that? Do a A>:ASM BIGFIL.AAB and forget the disk in B: and you remember why you hate that. But then I wa an early adptor of hard disk and from late '80 on had at least a 5mb drive to avoid that. Is that less authentic? By the end of 1981 I'd built a system with romdisk and ramdisk and no floppy or har disk. Was that authentic? What is authentic? To me if the platform has 8080, 8085, Z80, Z180/64180, Z280, or NSC800 it's running on real iron. Of course if you have a Z380 or eZ80 in native mode or a NEC V20 in 8080 mode those may count too. But what about 68000 or Z8000 runing CP/M they exist too? The problem there being they are file system compatable but neither can ran any of the vast library of CP/M 80 code base. >One might as well run an emulation program on a PeeCee. I wouldn't >be at all surpised to find that someone's done it for the iPod Touch-- >there already exists a NEC 9801 emulator for that platform. I'd argue that CP/M on an iPOD is not close to a useful experince. For one without a keyboard the interaction is via GUI that could never have existed back when on anything Z80. That falls into cool hack catagory right up there with using a WRT54GL as a wireless web server. There are many emulators the classic ones and some really useful ones too. I'd argue for playing with aps a SIM on PC is valid enough. I'd also for hacking hardware a sim on PC is bogus. I never figured out a way to simulate a board of random logic to emulate a process control card adn plug that into a sim complete with simulated stimulus. For me and I may be atypical I use both. I use the PC with MyZ80 or Daveid Dunfields N*Horizon and of course SIMH as software test platforms and even as portable CP/M when I've forgotten to bring my PX-8. But I also use those SIMs to build real platforms with 8085 or Z80. And there is a different feel, real or perceived, to running on real iron even if the iron is a 10mhz Z80 with 64k of ram and 512kb of ram disk and 32mb of CF or my NS* Horizon built in '78 with a 32mb hard disk, 5.25" floppy and 8" floppy. >From a modern perspective, regardless of the hardware used be it CF or a SA800 programming the BIOS is a mystery or stopper for many as for all the people out there writing code few ever get that close to the metal. That makes the real iron a challange. >> Deblocking is not too mysterious. The real missing bit in the >> Alteraion guide is how the BDOS telegraphs the need to preread >> and when to skip it. > >Page 14, section 12 entitled "Sector Blocking and Deblocking" in the >Alteration Guide covers it pretty well. I remember being relieved to >find the information after I struggled with 1.4 not having any such >mechanism. I don't think it was in 2.0 either, but I can check if >anyone's curious. > 1.4 really didn't even do a DISK bios, it was embedded in the bdos. the bios for 1.4 was only terminal, punch reader and printer IO. Yes, it ws a pain to interface any new disk to it. It is in 2.0 (deblocking). However their explanation is thin and some of the fine details have to be infered by really reading the code. It was very mysterious when I did it for the first time back in '80 when I was working with a early sample 765 DD FDC. It was later that Andy Johnson-Laird wrote The Programmers CP/M Handbook which covers the subject in much greater detail and has two BIOS exammples that are very commented. Allison >Cheers, >Chuck

17 years, 11 months

Interconnecting classic computers

by aliensrcooluk＠yahoo.co.uk

Why not wait for the WiMax cards that are due out later this year? Allegedly they have a range of about 30 miles! :) Then most of us in the UK can interconnect our computers, hehe. Regards, Andrew B aliensrcooluk at yahoo.co.uk

17 years, 11 months

Interconnecting classic computers

by ard＠p850ug1.demon.co.uk

As I think most of you know, I have a fairly diverse collection of classic computers (I suspect some others do too). Quite often I need to transfer data between 2 machines. Maybe to download a file from this PC, which I've in turn downloaded from a web site, to run on one of the classics. Maybe to print out some listing from a classic. Whatever. My machines vary in size from the pocket computers up to machines that it's not practical to move. They're scattered throughout a house. They are, alas, not in a machine room. Most of the machines (and all the ones I want to consider for this) have an RS232 port, either built-in or as an option (which I have). Most of the machines run kermit. Or I can simply print to the RS232 port on one machine and capture the incoming characters on the other So, I think the problem reduces to 'how to interconnect RS232 ports'. let me add some constraints : Must work over a distance longer than the RS232 spec allows (i.e. the answer is probably not 'A long RS232 cable' :-)). Prefereably no cables at all. One solution I've come up with is to use a couple of line drivers and a long cable between them. A long cable that my parents, or the cat, will get tangled up in :-( No line-of-sight between the machines Must work at 300 and 1200 baud. 110 and 9600 baud would be a bonus I only need one pair of machines linked at a time. I don't need a network. So if the solution involves a radio link, the fact that there's only one channel available would not be a problem. Must not make use of any flow control lines on the RS232 port, since some of my machines don't support them. Using classic, or at least repairable, hardwre is a bonus :-) I said 'RS232'. I mean asynchronous serial, of course :-). If somebody has a solution for TTL or 3.3V level serial ports, I can trivially convert the signal levels I've been looking at some of the license-exempt radio modules, but they either are half-duplex or amke use of the flow control lines (typically they buffer <n> bytes internally, then de-assert a flow control line while they pack up that data and send it to the other end). So far the best I've come up with is to link one machine to a palmtop (HP95LX), then transfer the data to that, carry the palmtop to the other machine and transdfer the data on. It's not ideal, but it does work. Any other ideas? -tony

17 years, 11 months

Zilog Zeus

by jeffj＠panix.com

From: Matthias Knoth <mknoth at earthlink.net> > does anybody have information/source code/anything > about the Zilog Zeus System? It is a System III Unix derivate > running on a Z8001 16bit CPU Gaaah, it's coming back to haunt me! The NJ Computer Museum has a Zilog System 8000 model 21 what's probably running that! One of my AT&T IS consulting assignments was running URTS (Unix Regression Test Suite) on the SVR3 port and examining the source code. I'm unsure I have any of that on tape or printouts :-( The comments were amusing such as the Z8000 CPU forcing the Z80's "RETI" instruction on the peripheral bus to reset the Z80 peripherals chips interrupt daisy chain. The comments were something like ld foo ; now watch my lips ... mov bar ; RE- ld baz ; mov qux ; -TI That's the first place I saw "deadbeef" as a magic number. I really liked the System 8000 as a development system since it had a firmware monitor that could be invoked in case of a system crash to poke at the RAM. I think that's where I learned how to repair the system using the stand-alone bootable tapes such as SASH: Stand Alone Shell, and SADIE: the diagnostic tape. When Exxon owned Zilog (around 1982), they had an office in Rockefeller Center (NYC) for their office automation featuring the Zilog System 8000 running Zeus. Back then, breadbox sized Z8000 systems running Unix System III were common, such as the Onyx, so the Unix manuals were all around (Then 68k based systems took over, then Intel x86). I like in an apartment, so I can't save 'em all :-( From: Dave McGuire <mcguire at neurotica.com> > I ran a Zilog System 8000 running Zeus daily > for quite a while back in the late 1980s. But did you get to peek into the kernel or use the maintenance programs? From: "Mark Davidson" <mdavidson1963 at gmail.com> > I'd love to hear what people have as well... > I remember "porting" an RM/COBOL system for a doctor's office > from a CP/M system to ZEUS and loving the system. > I've never seen any on the collector/used market I remember seeing 2 on the back of an old pickup truck, for sale, at the Trenton Computer Fest in the late 80s. Talk about a fall from grace! The only RM/COBOL I remember seeing was a manual for the NCR Tower, but I was a firm Unix/C kinda guy by then. -- Jeff Jonas

17 years, 11 months

Minimal CP-M SBC design

by ajp166＠bellatlantic.net

> >Subject: RE: Minimal CP-M SBC design > From: "Andrew Lynch" <lynchaj at yahoo.com> > Date: Sat, 10 May 2008 14:43:26 -0400 > To: <cctalk at classiccmp.org> > > >> Date: Sat, 10 May 2008 12:29:24 -0400 >> From: Dave McGuire > >> I dunno Chuck...the only reason more CP/M systems weren't ROM- >> resident back in the day was due to convention, not technical >> restrictions. I (personally) don't think there's anything >> non-"period" about ROM-ing CP/M. > >It's not the ROM-ing of CP/M that disturbs me, but rather the >"disklessness" of the thing. Wasn't the whole idea of CP/M >originally to give you something to manage files on your floppy >drives? I mean, that's what the bulk of the code in CP/M is for-- >heaven knows, the support for other I/O is nothing to write home >about. > >If one wants to enjoy a "vintage" experience, what sense is there in >being diskless? At any rate, even something as simple as a WD1770- >type controller added to the design would give that capability with a >minimum of support "glue". > >Alternatively, one could stay diskless and add a sound-effects module >to emulate the "chunk" and "grrr" of a head-load and seek--and the >"thunk-click" of a drive door being opened and a floppy inserted. > >I still don't have the hang of this "vintage" thing yet, probably >because I'm vintage myself. Please forgive my density... > >Cheers, >Chuck > >-----REPLY----- > >Hi Chuck, > >I hear what you are saying and agree there is something just very >disconcerting about diskless CP/M computers. However, CP/M in the CBIOS is >really just about block devices and the OS really could care less whether >you attach a 8" SSSD floppy, a CF drive or a ROM. It is all the same to the >BDOS. > >My goal here is to *eventually* allow expansion to include IDE and floppy >drives. As a matter of fact, the CBIOS does support IDE hard disks already >but requires the interface IO card and the ECB backplane to attach it to the >SBC. I have an IDE hard disk with CP/M format and some programs on it. > >My goal with the SBC using ROM/RAM drives was to allow something minimal to >operate as a SBC and have some functionality with the option to expand to as >desired. I am trying for a modular, low cost approach with easy to build >increments. > >Assuming I get this SBC respun and into manufacturing my next project is to >redo my ECB backplane as a PCB. After that will be the disk IO board and >bus debuggers which are also made from prototype boards. > >My Test Prototype home brew computer was built entirely with prototype >boards and point to point wiring. It supported IDE drives and even had a >NEC765 FDC circuit built in. I wrote some software but never got around to >test the FDC part since the machine started experiencing reliability >problems which I think trace back to poor grounding and power distribution >issues. The new PCB SBC version seems much more solid than the prototype >did. You used it as it's one of the few you can still buy. I happen to use that chip as I have them and was even supporting them back years ago. But you know adding that chip with it's support nearly doubles the chip count of a minimal CP/M engine. A few areas I watch for. Sockets do not help reliability. Ground is never ground enough. Bypass everything. Allison >The SBC is something which works but gives only limited functionality. If >that is enough, people can stop there. If they want more they can plug it >into the ECB backplane and add peripheral cards. So far only two peripheral >cards exist; the disk IO card and the bus debugger. Hopefully more in the >future. I have some ideas kicking around in my head but am concentrating on >the SBC for now. > >Thanks and have a nice weekend! > >Andrew Lynch

17 years, 11 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