I've been working on some Epson laptops and their associated TF20 drive.
I'll post my notes on the TF20 and the drive mechanisms (SD320) as
separate messages, along with the wirelists of the various cables I've
made. One other thing that might be of interest : The 34 pin connector on
the back of the TF20 is not some kind of parallel host interface. It's
exactly what you'd expect a 34 pin connector on a disk controller to be
-- namely a SA400-compatible disk drive bus. The hardware can handle up
to 4 drives which can be connected either to the intenral drive
connector or to the connector on the back. I have no idea if the standard
software (which is clearly CP/M based) can be made to support more than
the 2 internal drives. The hardware also seems to support FM operation
(unlike the QX10, which seems to be MFM only), I have no idea if the
software does
There is a spave for another 34 pin connector on the PCB. This is some
kind of parallel interface, the missing 4 pin chip is an 8255. Again I
have no idea if the software cane be made to support it. But shorting
pins 33 and 34 on this connector will do a hard reset of the controller,
which can be useful to know when debugging one.
As is well-known, I think, the TF20 controller is really a CP/M-based
computer. There's a Z80 with 64K DRAM in there. The EPROM contains
something that looks suspiciously like a CP/M BIOS, it's copied to the
top of RAM after reset, then the EPROM is switched out.
My TF20 didn't work. It never tried to load an OS from disk, it never
responded to commands from the host. The first thing to ckeck was the PSU
rails (including the -12V line that's generated on the controller board),
all were fine. The Z80 was clearly clocking, it was executing
instructions (looked to have got trapped executing FF from loacation 38,
if you see what I mean :-)). The EPROM was not swtiched out (this was
interesting. The EPROM can be swtiched out in software, but can never be
switched in again other than by a hardware reset. So this meant the EPROM
had never been swtiched out).
I looked at the start of the EPROM code. It copies the BIOS to the top of
RAM, then jumps to the cold boot entry point. The first thing this does
is to swtich out the EPROM.
I usspected a RAM problem -- the BIOS in RAM therefore couldn't be
executed correcrtly. A few chyecks showed that the address lines at the
RAM (after the multipleser) were fine, so were RAS/ and CAS/. I susepcted
a RAM chip.
I desoldered all 8 RAMs (no easy way to run a RAM test in that unit),
then put sockets in their place. Put the RAMs into an old IBM PC,
it failed the POST and told me one of the RAMs was dead. I put the other
7 back in the TF20 along with a replacement. It now works fine.
I have a little problem with the HX20.
I've been using the RS232 port from disk BASIC (I suppose I should see if
ROM BASIC behaves the same way). According to the user manual, the way
to do this is to do something like
OPEN "O",1,"COM0:(58N1F)"
WHere ; The first "O" means open it for OUTPUT
The paramters in brackets are :
Baud Rate (here 5 == 2400 baud)
Word length (8 bits)
Parity (none)
Stop bits (1)
Handshake control (here F)
It's the last that's giving me problems. According to the user manual,
this is a single hex digit, the bits of which are used as follows
Bit 3 : Is DSR enabled or masked out
Bit 2 : Is CTS enabled or mashed out
Bit 1 : State of RTS output
Bit 0 : Is CD enabled or masked out
I may have got bits 3 and 2 the wrong way round, but anyway.
The problem is that bits 1 and 0 seem to do nothing. RTS is always turned
on when the port is openned, CD is always ignored. DSR and CTS behave as
I'd expect them to.
Is this a known bug in the BASIC, or is there some very odd fault with my
HX20?
-tony