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