> 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
> 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.
> 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
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
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
> 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
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
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
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
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/
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
>>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.
>
>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
>
>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
>> 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
> 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
> 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
> 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
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
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.
>
>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
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
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
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
>
>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