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
>
>Subject: Re: Minimal CP-M SBC design
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Sat, 10 May 2008 11:27:50 -0700
> 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.
It would not be diskless only floppy less.
>
>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".
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.
IDE and CF have simple interfaces, they do not have to be written
or read in real time, they are obtailable.
FYI reading and writing in real time for a 5.25" DD floppy (seriously
anything less than 360K is useless) requires the CPU to fetch/put
a byte every 16uS without delay and in somecase the worst case
timing for that is 14us. Write a simple routine in Z80 at 4mhz
that does that, reliabily. Forget using 1.44MB floppies as doing
that in under 8uS is out of the question without a 8mhz Z80, fast
ram to support it, fast Eprom and all the other nice things that
go with faster. FYI: at 4ux a CPU cycle is .25uS and the shortest
instruction is nop at 4 cycles (no wait states) or 1us and a DJNZ
is around 7/10 cycles or 1.75uS to 2.5uS... the timing picture
is tight.
Also there is the problem of getting some FDCs like the 1770,2793
and other more highly integrated chips that aren't 44 pin QFP.
>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.
How many more parts do you think you need for that?
>I still don't have the hang of this "vintage" thing yet, probably
>because I'm vintage myself. Please forgive my density...
;) having built my first Altair in january 1975 and prior to that
for work an 8008 when it was new.. what me vintage?
Allison
I just got my hands on an old IBM 129 keypunch. It seems to power on,
but I have no idea how to operate or test it. Anyone know there there
might be a manual? I tried all the usual sources (bitsavers, etc) with
no luck. I found some old keypunch manuals, but not for this
particular model.
Thanks.
Paul
> Date: Fri, 9 May 2008 10:59:35 -0700 (PDT)
> From: "Eric Smith"
> The lead pitch of shrink DIP packages is 0.070 inch (1.78 mm). I
> haven't seen any 0.050 (1.27 mm) inch DIPs. Shrink DIPs were popular
> with Japanese semi companies, but never caught on very well with US
> companies, most of which skipped those and went straight to PLCC and
> PQFP packages.
Right you are--I dug out a couple of shrink DIPs and they are indeed
0.070 inch. Unless you're going right to PCB, these are a real pain
to deal with today--hard to find sockets, odd spacing, etc. I think
I've still got a couple of 64180s in this package kicking around
somewhere.
Thanks for the correction.
Cheers,
Chuck
> PCBs with edge connectors really drive the costs up because specialized
> prototype boards are required or if you manufacture the PCBs using edge
> connectors and gold fingers are extra.
It's very strange--at one time Radio Shack (under their "Archer"
brand) sold 22/44 position edge-connector prototyping cards, in
phenolic, rather than FR4 and with tinned, rather than gold-plated
fingers. Vector had similar prototype cards as well. It's kind of
hard to believe that they're all gone now, since at one time, they
were very common.
Cheers,
Chuck
Speaking of Z80 build-it-yourself boards, has anyone had any
experience with the Russian PDP-11 clone chips, e.g. KH1801BM4? How
difficult are they to obtain and how compatible are they with the
real thing? The photos of ones that I've seen have date codes in the
90s, so they can't be that rare.
Cheers,
Chuck
Hi,
I am working on a home brew SBC and am trying to build a serial cable for
it. Are there any RS-232 serial port gurus who could help me plumb out a
custom cable?
The SBC serial connection works but as it currently is configured it only
works as 3 wire serial with no flow control (ie, RD, TD, & GND pins).
I would very much like to make the serial cable and SBC support hardware
flow control. Having the DSR/DTR pins connected should allow it. However
the PC is expecting CTS/RTS hardware flow control.
My SBC UART is wired so that the RD, TD, DTR, DSR, and GND pins are brought
to the serial connector. I probably should have brought CTS & RTS out but
it is too late to change it now.
I have wired a cable like this which works for 3 wire serial (no flow
control)
PC DB25 (9 to 25 pin cable) SBC (25 pin female)
2 TD----------------------RD
3 RD----------------------TD
7 GND---------------------GND
6 DSR---------------------DTR
20 DTR---------------------DSR
Obviously this cable does not support hardware flow control because when I
try to connect with hardware flow control enabled, I can see the SBC boot
message on the terminal screen but cannot send characters from the PC to the
SBC.
So I have been experimenting trying to figure out how to fix this. I got
the data sheet for the 16C550 and a serial port breakout box. After much
combinations, I discovered that if I connect a jumper between the PC serial
port pins 5 (PC CTS) and pin 20 (SBC DSR) then the serial port *DOES*
support hardware flow control. At least it appears to. I get the feeling
though that I am mixing dissimilar control signals and it is confusing me.
My question is, does the above configuration with the PC CTS and SBC DSR
connected really use hardware flow control or is it just "faking out" the PC
and/or SBC UART? As a follow on, are both sides actually getting hardware
flow control or is it just one side or the other?
This is my new and improved serial cable with *appears* to support hardware
flow control. Is there any way to test this?
PC DB25 (9 to 25 pin cable) SBC (25 pin female)
2 TD----------------------RD
3 RD----------------------TD
7 GND---------------------GND
6 DSR---------------------DTR
20 DTR----+----------------DSR
5 CTS----+
Thanks in advance for any help!
Andrew Lynch
>
>Subject: Re: Minimal CP-M SBC design
> From: Dave McGuire <mcguire at neurotica.com>
> Date: Sat, 10 May 2008 12:29:24 -0400
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
>On May 9, 2008, at 12:36 PM, Chuck Guzis wrote:
>>> 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?
>>
>> 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 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.
Worked for the PX8 and likely a few others.
Actually the real and most likely reason is you needed 8k or so of
rom and back when Eprom (or enough eprom) that size was a bit later
and even then expensive for a while. However by around 84ish 8 and
16k parts were getting reasonable and that is plenty enough space.
Besides booting from rom is like booting from disk, the differnce is
the rom is read only and doesn't rotate. Oh it is simpler.
As to "BDOS Err on B:" you can still have that if the system only
boots from rom and still expects a floppy drive (or other removable
media). Personally that is one of the error messages that I can do
without. ;)
Allison
>
> -Dave
>>
>
>
>--
>Dave McGuire
>Port Charlotte, FL
>
