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.