I was offered this XP640 after it was found to be faulty. It powered on ok and displayed the normal startup messages but every command except for "Port" and "Menu" failed with an error or did not perform as expected. It also did something very odd if the cursor keys were used immediately after "XP640 V 1.4 READY" was displayed to change the current memory location. The contents of data memory should be initialised to FF in hexadecimal and if the "Enter" key is pressed "0000 FF FF READY" will be displayed, indicating at address 0000 memory contains FF device contains FF. This XP640 displayed "0000 FF FF READY" but if the "->" cursor key was pressed it displayed "0001 00 FF READY" and if "<-" was pressed it displayed "0000 00 FF READY".
This seemed to show that the data memory was faulty but to prove this conclusively I created simple test firmware for the XP640, xptest based on pp3xtest, that tested the static RAM as well as the dynamic RAM used for data memory. The test firmware found that the static RAM was ok but the data memory test failed at the first address always reading FF when 55 was written to it. This shows that standard XP640 firmware does not test data memory at initialisation which is a surprise to say the least. Even more strange is that xptest reads FF when the standard firmware reads 00 ! My guess is that the value is complemented before writing to and after reading from data memory, possibly because DRAM contents should be 00 after power on and by doing this the firmware does not need to fill each memory location with FF.
Result of xptest data memory test
Inspecting the area of the PCB associated with the dynamic RAM revealed no obvious damage so I put the XP640 to one side while I did more important work.
A few months later I found the time to trace the dynamic RAM connections including the refresh circuit and created the diagram below.
Here is the clock and wait state circuit
To make it easier when probing with a logic analyser I added tests to xptest which access the dynamic RAM in a predictable way. By comparing the analyser output for the faulty XP640 with the analyser output for my working XP640 I could see that the refresh circuit doing the right thing, sort of, but the pulse widths were different. The circuit uses two outputs from the address decoding PROM IC7 and the RFSH, RD and WR signals from the Z80 so I swopped the decoding PROMs and the Z80s over but there was no difference, the faulty XP640 was still faulty and the working one was still working. What could make the timing different between the two ? After some more thought I realised that it was added wait states.
Here is the analyser display for the faulty XP640.
The faulty XP640 is adding no wait states causing the extremely short CAS pulse and so the write fails.
Here is the analyser display for the working XP640.
Wait states are added and the CAS and RAS pulses for reads and writes are longer.
The RAS pulse while RFSH is low is a memory refresh cycle but you may have noticed that there is an extra RAS pulse for each instruction fetch (M1 and WAIT low). This is a design flaw in the refresh circuit as it assumes that if a wait state is added it is for the DRAM and RAS is driven low even when it is the EPROMs that are being accessed. There is only one output from the TBP18S030 PROM IC7 to indicate that wait states are needed, labelled in the circuit above as DRAMSEL.
The analyser showed that the output pin 5 of 74LS74 IC12, next to the large heatsink, was always 0V and so I replaced it which restored the wait states. It now passes the memory tests and functions correctly with standard firmware.
The faulty IC12 is different to the other ICs on the PCB as it is branded RS.
Does anyone know who the real manufacturer would have been ?
Update 08/04/18
Someone has contacted me to say that this was manufactured by Texas Instruments at their Portuguese fab plant in the municipality of Maia, about 10 km north of Porto.
