Restoring a Cromemco Z-2

[glitch]

While cleaning out part of our warehouse at work, I found two Cromemco Z-2 rackmount chassis enclosures, one with the original Cromemco S-100 motherboard, and one with a Thinker Toys Wunderbuss motherboard. One of the cases had the ZPU card and an Ithaca Intersystems 64K dynamic RAM board. Neither case has a functional power supply (blown rectifiers and bad caps in one, just bad caps in the other). Since the Wunderbuss is small enough to work on at my workstation, and set aside at the end of the day, I've been working with it, using a triple-voltage bench supply.

So far, I've repaired the Wunderbuss to the point that I'm getting the correct voltages on the S-100 connectors (bad tantalum caps...) and regulated voltage on the spade connectors (presumably for drives?). I plugged the ZPU card in last week, and its regulators put the right voltages onto the Z80's socket pins. The oscillator produces the correct frequency at the crystal. Someone had scavenged TTL chips from the ZPU, so I spent the weekend pulling them from other board I've got. The ZPU will get another firing-up Monday at work, to see if the oscillator signal reaches the Z80.

I'm not sure as what to do for the next step, though. I purchased a 4FDC card, which is reported to be working, in order to test the system. Does the 4FDC require a RAM board to be installed to get anything from the console? Its manual suggests that RDOS does use a portion of RAM for a stack. The Ithaca board is questionable, as it has several board-level modifications, and the 5 volt regulator has been replaced (I think this is a result of the failure of the power caps in the chassis it was installed in).

Any suggestions or pointers?

 

[NobodyIsHere]

Hi! There is a good article on how to repair S-100 systems at S100Computers.com. You seem to be going on the right approach.

First step is to remove all the boards. Second is to get the power supply working reliably and recondition the electrolytic capacitors.

Then you'll need three elements to make a working system: the CPU board, RAM/ROM, and serial IO. The most important is the CPU. Even without any memory installed the Z80 should behave in a very specific fashion. If it's working the databus should load $FF and execute. You should see /MEMR pulsing and /IORQ staying high. You should see the address bus cycling through its range in an orderly way.

The next step is to load a known good EPROM board (or use a front panel and RAM board) and see if you can get the CPU to execute arbitrary code. I like JP $0000 program since it is about the simplest program and if you can get the CPU to run in a tight loop you can use your oscilloscope/logic probe to debug the rest of the system.

I use /IORQ and /MEMR as pseudo IO pins. You can program specific sequences in EPROM that can be detected using an oscilloscope. Then write small programs to test address ranges, see if RAM is reading and writing, etc. Once you are sure the memories are working then try move on to the serial IO.

If you can get the CPU, ROM, RAM, and serial IO working you are almost all of the way to a fully working system.

I hope this helps. Thanks and have a nice day!

Andrew Lynch

 

[glitch]

I read through the article concerning troubleshooting S-100 cards, which was a great bit of information. I tested the ZPU further at work, and after discovering the wait state jumper missing, I did observe the Z80 stepping through its address space, and pulses on the memory request and refresh pins. I didn't get any further than that, since either my 4FDC card doesn't work, or it just doesn't work without RAM. I think there are further blown capacitors or a shorted regulator on the Ithaca board, as it shorts one of the 16 volt rails to ground -- fortunately, I'm using a Lambda triple-voltage supply, which current limits.

I've got a Vector S-100 proto board coming in from eBay soon, so I think I'm going to populate it with a 2716 EPROM and 6116 static RAM for getting the Z-2 up and running. TIL311 displays on the data/address bus, and some LEDs for things like the HALT line should let me make sure the ZPU board is actually going to execute code from memory. I don't have any S-100 boards, aside from the three mentioned, so I have no other way to attach an EPROM to the system: I do intend to run the test code available in the S-100 troubleshooting guide, once I've got a ROM/RAM board built.

 

[NobodyIsHere]

Hi! Personally, I would put the 4FDC board away for now and focus on the basics. Your Z-2 has to have good power, CPU, memory, and console IO. I would start with the ZPU assuming the power supply is good.

Do you have a boot EPROM?

Can you burn your own EPROMs?

Has the reset vector been set on the ZPU and is does the boot ROM appear at that address? If it doesn't have one most likely it expects to see memory at $0000. That could be a ROM or RAM if you have a front panel board.

Building a SRAM/EPROM with a prototype board is a good idea. There are some sample schematics in the Bursky S-100 book. Also the Libes book.

Thanks and have a nice day!

Andrew Lynch

 

[glitch]

The problem is that the 4FDC, in addition to providing a floppy interface, also provides my serial console, and the Cromemco RDOS monitor. The Z-2 doesn't have a front panel, so the serial console from the 4FDC is the only way to communicate with it.

I'm going to rebuild the power supply at a later time...I'm not sure if I want to convert my S-100 boards for regulated rails operation yet. I have a pile of switcher boards that provide +5 V @ 25 A, +/-12V @ 2 A, so they might replace the huge linear supply in the Cromemco chassis eventually. For now, my Lambda bench supply should suffice; I especially like being able to watch the current on all three power bus lines.

The reset vector had been set at 0xC000, which is where the RDOS monitor resides on the 4FDC. I've disabled Jump-on-Reset (it's a wire jumper on the ZPU) since I'm going to leave the 4FDC out of it for now. I plan on wiring the eventual RAM/EPROM board to start using address space starting at 0x0000, and possibly including an option to place the EPROM at 0xC000, so that I may test the ZPU's Jump-on-Reset functionality.

I can burn my own EPROMs, I have several programmers and an UV eraser, and many used EPROMs. I've also been working on an 8085-based single board for embedded projects, so I've got the 8080-compatible source for my debugging programs.