Ok, so now it runs. But, what did it take to get here?
First up - I'm chasing down a replacement fusable PROM and I'll likely have to build a programmer for it. The programmer will need to run a bit at a time, which is very different to what the EPROM programmers available today support. It works for now, but I don't like it.
I've uploaded a dump of the PROM here - https://erikarn.github.io/pcat/notes.html .
Here's how the repair looks so far:
Next - getting files onto the device. Now, remember the hard disk is unstable, but even given that it's only DOS 5.0 which didn't really ship with any useful file transfer stuff. Everyone expected you'd have floppies available. But, no, I don't have DOS available on floppy media! And, amusingly, I don't have a second 1.2MB drive installed anywhere to transfer files.
I have some USB 3.5" drives that work, and I have a 3.5" drive and Gotek drive to install in the PC/AT. However, until yesterday I didn't have a suitable floppy cable - the 3.5" drive and Gotek USB floppy thingy both use IDC pin connectors, and this PC/AT uses 34 pin edge connectors. So, whatever I had to do, I had to do with what I had.
There are a few options available:
- You can write files in DOS COMMAND.COM shell using COPY CON <file> - it either has to be all ascii, or you use ALT-<3 numbers> to write ALT CODES. For MS-DOS, this would just input that value into the keyboard buffer. For more information, Wikipedia has a nice write-up here: https://en.wikipedia.org/wiki/Alt_code .
- You can use an ASCII only assembly as above: a popular one was TCOM.COM, which I kept here: https://erikarn.github.io/pcat/tcomtxt.asm
- If you have MODE.COM, you could try setting up the serial port (COM1, COM2, etc) to a useful baud rate, turn on flow control, etc - and then COPY COM1 <file>. I didn't try this because I couldn't figure out how to enable hardware flow control, but now that I have it all (mostly) working I may give it a go.
- If you have QBASIC, you can write some QBASIC!
- Remember, DOS (and Windows too, yay!) has a difference between files open for text reading/writing and files open for binary reading/writing.
- QBASIC has sequential file access or random file access. For sequential, you use INPUT/PRINT, for random you use GET and PUT.
- There's no byte type - you define it as a STRING type of a certain size.
- This is an 8MHz 80286, and .. well, let's just say QBASIC isn't the fastest thing on the planet here.
- I used tip on FreeBSD to talk to the serial port
- I had to put "hf=true" into .tiprc to force hardware handshaking; it didn't seem to work when I set it after I started tip (~s to set a variable)
- On the QBASIC side I had to open it up with hardware flow control to get reliable transfers;
- And I had to 128 byte records - not 1 byte records - to get decent transfer performance!
- On tip to send the file I would ask it to fork 'dd' to do the transfer (using ~C) and asking it to pad to the 128 byte boundary:
- dd if=file bs=128 conv=sync
OPEN "COM1:9600,N,8,1,CD0,CS500,DS500,OP0,BIN,TB2048,RB32768" FOR RANDOM AS #1 LEN = 128
DIM c AS STRING * 128 ' 128 byte record
FOR i = 1 TO size#
GET #1, , c
PUT #2, , c
- 9600 baud, 8N1, hardware flow control, 32K receive buffer.
- 128 byte record size for both the file and UART transfers.
- the DSZ.COM file size, padded to 128 bytes, was 413 blocks. So, 413 block transfers.
- Don't forget to CLOSE the file once you've written, or DOS won't finalise the file and you'll end up with a 0 byte file.