Category: Cromemco SCC

About Cromemco SCC

Subscribe Feeds

Cromemco Bytesaver

Posted on by Graham

I had been quite intrigued by the idea that the Cromemco Z80 Monitor and 3k Basic could save programs to EPROMs instead of, for example, paper tape, magnetic tape, or floppy disk.

I was thinking particularly of my Cromemco Single Card Computer (SCC) but the same trick is possible using a Cromemco ZPU Card.

To do this requires a card capable of programming an EPROM eg Cromemco 8k Bytesaver, 8k Bytesaver II, or a 32k Bytesaver.

The cards that i had seen on ebay were in the States and were prohibitively expensive, even before adding the postage. Fortunately, though, an 8k Bytesaver come up for sale in Adelaide. Despite its poor condition and significant price, i acquired the card so that the itch could be scratched.

The 8k Bytesaver was a milestone card; the first S-100 card to provide EPROM storage. Prior to this, machines were typically bootstrapped by entering a boot-loader at the front panel. This card was released in 1976 shortly after Intel released the device that made it possible, the 1k x 8 bit 2708 EPROM.

The 2708 is not as easy to work with as later EPROMs. Even for reading it requires +5V, +12V, and -5V supplies. For programming, it requires CS to be taken to 12V and an additional programming voltage at 26V.

The EPROMs themselves are not particularly common, but i have a bunch that i have previously imaged, and they can also be purchased for about AU$6 each.

I wasn’t sure that the 8k Bytesaver would work with the SCC (the SCC manual was a little ambiguous), but i also had the option of using a ZPU.

The purchased card had been modified to use 2732 EPROMs with, as far as i could see, no ability to program the EPROMS. Many tracks had been cut and components removed. Even the original heatsink had been replaced with a lesser version.

As a 2732 EPROM card it was useful, but it was nothing i couldn’t put together on a prototype card as i had done once before. Fully restored it would be far more interesting so that’s what i decided to do.

Cromemco sold the card as a kit, it looks like it was assembled by an amateur, it had been modified (probably twice) by an amateur, and was now about to be restored by an amateur. Some cards are born to a life of hardship.

I checked the programming power supply first; a terminal fault would mean there was no point proceeding. It worked fine.

The programming switch had been stolen, so i stole one from a faulty Lexitron floppy disk controller board. Not sure what to do about the heatsink.

One socket had been replaced with a different type. I found a donor board with the matching type and swapped it out.

I started by removing everything that wasn’t supposed to be there and tidied up the original soldering.

Then i started looking for the track cuts. There were a lot of them on both sides of the board. Many cuts had been made and then repaired. They were a bit rough with deep gouges to the fibreglass and large gaps in the copper.

Each was made good as neatly as possible with the available skill.

I covered the mods with UV cured solder resist just for appearances. It can’t be perfect, but it is a lot better.

I replaced all the missing components, which were fairly generic.

I gave the board a good wash and all the sockets and ICs were given a couple of rounds of deoxit. Many of the ICs had very black legs – i suspect that many of them had silver-plated legs.

With my only two racks in use, i needed to get around to building up a third backplane. This one is based on the S100 Computers 9 slot backplane. Being lazy, i added just the two connectors that i needed.

I was fortunate to have picked up a monster of an S-100 power supply off FB marketplace a while ago. With the power loom made, it was ready to go.

I checked the supplies without any ICs inserted. All good. Then i added the ICs.

The simplest test option for me was the Cromemco SCC. It had been a while, so i had to re-acquaint myself with its operation. It has 2 x 2kB EPROMs holding 3k Basic and the Z80 monitor. The SCC talks with a user via a serial monitor.

On power up, the user has to send a couple of carriage returns so that it can detect the baud rate.

I configured the Bytesaver to be at E000H which is well away from the SCC EPROM/RAM space. It uses no I/O space. Attempts to write to the card are treated as programming cycles with lengthy wait states inserted.

There are several manual scans available, and they do contain schematics, but the resolution is such that they are very difficult to read. This is not helped by Cromemco’s policy of prioritising low sheet count over clarity!

I was not able to reliably quit from the 3k Basic to the Z80 monitor so i did a lot of the debugging in Basic (pic with base address at 6000 rather than E000).

I checked a few signals without EPROMs, and then tried reading some EPROMs that had previously been imaged. I found the fifth EPROM overlapped with the first (a bad address line from the SCC) but once that was corrected (IC48 74LS244) it all looked good.

Then i removed the EPROMs and had a look at the programming cycle. This cycle relies on monostables to do the timing and they weren’t. I replaced the IC1 74LS123 and got some cycles that looked good.

Write cycle with switch OFF:

MWRT, Board_Select, EPROM CS (pin 20), EPROM Program (pin 18)

Write Cycle with switch ON:

This is how it should work according to the manual. With the programming switch on the CS pin rises to 12V and then a short time later the programming voltage is applied.

I looked further at the issue with the transition to the Z80 monitor. I found that it is fine if the PRDY signal is disconnected during the transistion, eg remove IC16-3 and connect with lead after transitioning. This is not a long term solution!

This is what it looks like when QUIT works:

WRT, Board_Select, EPROM CS (pin 20), PRDY

It seems to do 32 writes – is it scanning for available RAM with a write/read check?

I tried replacing the 74367 that drives PRDY. This seemed to have an effect. The transition would work repeatedly. And then it didn’t work repeatedly. And so on and so forth.

I then replaced all the 74367s without any very good reason. It will take some time to work out whether the issue has been resolved.

I tried programming an erased 2708. Remarkably, it programmed just fine! I used the Z80 monitor to copy the first 1k of the SCC ROMs to the blank 2708:

P 0000 S400 E000

I think it verifies during programming, but i verified it anyway:

V 0000 S400 E000

I eyeballed some of the data because i didn’t quite believe it.

It takes about 6 minutes to program a 2708, so a large program would take some patience.

After erasing the EPROM, i tried saving a program in 3k Basic. Victory!

It is worth noting that it is fairly easy to accidentally overwrite an eprom. Just the random check for RAM that seems to occur when the Z80 monitor is invoked would be enough to do it. The programming switch should be set to ON only for the act of programming.

It probably doesn’t look like a big deal, but it has been a fairly painstaking effort to achieve this goal.

Apart from monitoring the reliability issue, i think the next step is to repeat the exercise with the older version of the Monitor & Basic: CB-308. This will require the binary to be programmed into two 2716 EPROMs and placed in the spare sockets of the SCC. Then the binaries can be copied into a set of 4x 2708s. This should also work on the SCC. After that, i can attempt to use the ZPU card together with some RAM and a TUART.

Other Notes:

  • Top left hand blue capacitor is good for Logic Probe power. It is also good for a scope ground connection.
  • A modern socket plugged into the old sockets is more accessible for buzzing out connections.
  • Board_Select AND sMEMR can be picked up at IC16-1.
  • MWRT can be picked up at S100-68
  • CS is pin 20 on the EPROM socket
  • BASIC won’t successfully quit to the Z80 monitor if the RDY signal is connected. Remove IC16-3 and connect with lead after transitioning. This needs to be resolved.
  • The row of 4.7k resistors should be 18k but, this may have been due to a change for Revision 2.

Cromemco SCC and Board Testing

Posted on by Graham

The Cromemco Single Card Computer (SCC) design dates back to 1978 and this particular unit appears to have been made in 1978 or early 1979.

It has a Z80 processor running at 4MHz, 1kB of RAM, space for 8k of 2716 ROM, three parallel ports and one serial port.

The board was ROM-less but the binaries for the usual ROM set, MCB-216 were available online. These ROMs provide a monitor and 3k basic.

This means that with the addition of a terminal it’s possible to have a single card capable of executing programs that can exercise the S-100 bus.

I burnt the code into a couple of EPROMs, hooked up a terminal, and gave it a whirl. It fired up as if 45 years meant nothing. It starts up basic to start with but QUIT sends it to the monitor and B in the monitor sends it back to basic.

Programs can be saved to memory including to EPROM on particular Cromemco boards. They can also be saved to or read from the serial port.

The Monitor includes a memory test. I used it to check out a number of memory cards, with some success.

The Cromemco 64KZ appeared to be working fine. One board didn’t work because it expected pSTVAL to be driven and the SCC does not drive it. This was when i started to understand that the S-100 bus was not as “standard” as i had thought.

The main outcome was that i had a Cromemco memory card that was likely to be functional.

Cromemco 68000 System – Getting Started

Posted on by Graham

Andrew, a friend from the ARC Group, has supplied me with a lot of funky gear including a box of S-100 cards, a couple of chassis, several 8″ floppy disk drives, and about 500 8″ floppy disks.

I never imagined that i would get an opportunity to work with S-100 bus. Components are difficult to find and, when they do appear, people expect an arm and a leg for them.

I had no idea if any of the cards were related to a particular system so all i could do was catalogue them and see if any patterns emerged. One pattern did emerge – there were several Cromemco cards including:

  • a Single Card Computer (SCC)
  • a 64KZ Dynamic Memory Card
  • a DPU Dual Processor Card with Z80 and 68000
  • a MCU Memory Control Unit
  • a 512MSU Memory Storage Unit connected to MCU via a MBus ribbon cable.
  • a 16FDC Floppy Drive Controller
  • a TUART Twin UART

Not knowing much about Cromemco, i started reading and a new world opened up. The Cromemco community seems to exist primarily as a Google Group with a huge repository on GIT. This proved critical because i did not have a skerrick of software or doco. There was nothing related on any of the 8″ disks that i had.

The repository includes a vast array of manuals, disk images, software etc.

I realised that there were sufficient cards to be able to build a system capable of running Cromix (a Unix look alike). It would consist of:

  • a DPU Dual Processor Card with Z80 and 68000
  • a MCU Memory Control Unit
  • a 512MSU Memory Storage Unit connected to MCU via a MBus ribbon cable.
  • a 16FDC Floppy Drive Controller
  • a TUART Twin UART (optional)

I’m not sure where these cards came from. Perhaps they had been used in a bespoke design or stripped out of a Cromemco system. If the latter, then the chassis and drives have not made it into my hands. I will need to use a third party chassis, drive enclosure, and drives. Also, notably missing from the list, is a hard disk controller such as the Cromemco WDI-II but i did see that it was possible to run a skeleton Cromix system from floppy disks. That would be good enough for me (until it wasn’t).

It was also possible to build a system capable of running Cromemco DOS (a CP/M look alike) and that seemed like a less intimidating option to start with. It would consist of the following:

  • a DPU Dual Processor Card with Z80 and 68000
  • a 64KZ Dynamic Memory Card or an MCU Memory Control Unit and a 512MSU Memory Storage Unit connected to MCU via a MBus ribbon cable.
  • a 16FDC Floppy Drive Controller

And there was an even simpler machine that could be built using just the SCC.

I started with the SCC and then used it to help locate faults in other boards. Then i moved onto the CDOS system which was also handy for finding faults in the 68000 system.

First Power up of Cromix System

Posted on by Graham

Having got a CDOS system to start up the next logical step would be to move on to a version of Cromix intended to work with the Z80 processor.

The Z80 Cromix requires at least 128kB of memory and because that is larger than the address space of a Z80 processor it needs to be managed. Cromemco uses a particular scheme to do that and, alas, i have only one 64k card (at least that’s what i thought at the time) that supports this scheme so i was blocked.

68000 Cromix has no such need. Instead, it takes advantage of the large address space of both the 68000 and the S-100 bus. The memory card combo of the Memory Control Unit (MCU) and the 512kB Memory Storage Unit (512MSU) is a compatible memory solution. All of this info was layed out fairly clearly in the 68000 Cromix administrator’s manual.

This is quite a sophisticated storage solution. Each 16 bit word is accompanied by 6 error correcting bits. The 512kB of storage is provided using 64 x 1 bit memory chips so the MSU has a total of 112 ICs. MCU can support up to 4 storage units. There is a memory bus that runs between the MCU and the MSUs.

ECC is off at power up and is optionally enabled by Cromix via a I/O port.

The initial system configuration consisted of:

  • a DPU Dual Processor Card with Z80 and 68000
  • a MCU Memory Control Unit
  • a 512MSU Memory Storage Unit connected to MCU via a MBus ribbon cable.
  • a 16FDC Floppy Drive Controller

On power on i was hoping that after a few keystrokes on the terminal that i would see the RDOS monitor prompt as i had seen with the CDOS arrangement. Nup. Nothing.

Adding the 64KZ back in, even with the MCU/512MSU present, allowed RDOS to function so the MCU/512MSU were apparently not responding at all.

I was able to use RDOS to quickly confirm that the MCU registers were working, although strangely they were located at 44H rather than the 4CH described in the manual.

I pulled all the cards except the MCU/512MSU and added the SCC back in. The SCC is self-contained so provides a stable work place for further testing. I could enter a simple program with the monitor.

A started with a simple write loop to a single location and then upgraded to a write-read loop.

After getting my bearings i could see that nothing was being written to the MSU. A lot of things have to happen for a memory write to work, and the SCC does not drive. SXTRQ_L and Z80/68k_L were both negated with pullup resistors.

Also, obviously, the SCC doesn’t drive the A[23:16]. The MCU pulls these high so when using the SCC the address selection switches must be set for FF rather than 00.

The MCU does have quite a job to do – it must arbitrate at least three different requests:

  • Read
  • Write
  • Refresh

There’s also 8 and 16 bit transactions. And the error detection and correction must also have quite an impact.

As part of dealing with each cycle, it must control the data paths and the DRAM signals eg CAS, RAS, and Write. IC24 initiates the cycles; CYCLE START indicates the start.  CT[2..0] indicate (I think) the type of cycle. 

IC45 steps through the sequence of events and times the length of each step.  IC30 is a lookup table that determines (amongst other things) the duration of each step based on the step number and the cycle type.

IC46 is a large lookup table that generates a bunch of signals based on the step number and the cycle type.

The activity was complicated because the SCC generates external reads and writes even when accessing internal RAM and the presence of the refreshes.  I tried masking the MemR signal and disabling the refreshes but these both had the side-effect of locking up what is, in effect, a very complicated state machine.

In the end it wasn’t necessary, and it was possible to see the write cycle on the scope.  The output signals made no sense so either the lookup table was toast or there was a bad connection.  Sure enough closer inspection revealed a that the pins on IC46 had developed a brown coating (it’s socketed).  I should have checked this on day one, but i wouldn’t have learnt nearly as much!

The reset is interesting – a lot of the MCU is reset by the POC signal – probably so that the RAM is refreshed through a reset.

I cleaned all legs on all socketed ICs and suddenly there was action.  I did find that once the MCU/MSU became responsive there were some issues with the Z80 monitor on the SCC – specifically when quitting BASIC to enter the monitor was unsuccessful.  If the board is disabled (eg set a DIP switch on the MSU to off, then the monitor starts fine.  Once started the DIP switch can be returned to one apparently with no ill effect.

Alas, there are several RAM errors and all the chips are soldered in.  Worse still the 4 x 64kx16bit banks appear to be interleaved.  That means that all of 64 RAM chips need to be working just for the bottom 64k to be available.  And that’s ignoring the error detection and correction etc.  Ouch. On the bright side it’s possible to partially test each RAM chip from the SCC.

Writing zeros revealed 5 faulty ICs.  Writing FF revealed another one. 

I did different fills at different addresses to detect address line issues.

There were a lot of address errors where bits were written to the wrong address, eg because an address line was stuck in an IC. That yielded another 12 duds.

Most of this i could do from the SCC Monitor.

The pattern of ICs on the 512MSU is like this:

I think that the MCU/MSU always performs 16 bit transactions even when an eight bit transaction is requested.  And I think it does this by using read-modify-write cycles ie it writes back the contents of the unchanged byte as well as calculating the new error detection and correction bits.  Tricky!

I made numerous attempts to install 68000 cromix from the source images, but i encountered numerous problems (will cover in another post).  I eventually concluded that i must have a residual hardware issue and was able to confirm this via CDOS – in particular, i could copy files reliably when i used my 64KZ but not when i used the MCU/MSU. 

The MCU/MSU RAM checked out well with the 68k RAM test but i thought i’d try the 8 bit test as well and that showed an issue with the delay test.  I was not able to reproduce the issue by manually changing RAM values in the monitor, so it must be quite a specific situation that triggers it. The delay test is really made for the 16KZ, so the chip identifiers were meaningless – the memory organisation in the MSU is completely different to that of the 16KZ.  Nevertheless, it did indicate that the fault was in bit 8. 

I figured there were 8 x “bit 8” chips on the MSU and i had already replaced 2 so i replaced the other 6.  Having done that, it passed the delay test and eliminated the erratic behaviour.  Consequently, my personal well-being improved dramatically.

I used a socket with each replaced RAM chip, so they are visible in the photo. A total of 24 chips out of 64 memory ICs. I think there’s a fair chance that others will develop faults over time.

I have never checked the ECC ICs, but i would expect that about 1/3 of the 24 ICs will be faulty.

I don’t know why the failure rate has been so high. Sure, 4164 RAMs do fail, but i have not seen this sort of rate before. These are TI TMS4164-15NL with date code P8231.