Where Did The Bits Go?
Luckily the original source code is included with the DOS software. You just click on SOURCE.EXE and it'll extract all the source code. The unfortunate thing is a lot of it is assembly code, all but the main SA.c (C programming language) that drives the assembly code.
Looking at the SA.c, here's the section of code being called to send a file to the SA-20:
/*downloads file to sa via printer port */
int max_ctr =0;
asm_data_byte = 0;
asm_file_pack_resend_ctr = 0;/* also in file_pack_send in sapar.asm */
/* filename_ptr now set after display if asm_len ret f/kbd input */
if( (fileptr=fopen( asm_filename_buf, "rb")) == NULL) /* open file */
asm_data_byte = 1;
while(in_EOF != FALSE)
if (asm_file_pack_resend_ctr !=0) goto not_read_next_256;
if (asm_data_byte!=0) break;
if (ch == EOF) in_EOF = FALSE;
xfer_buf[j]=ch; /* put next char to 256 buffer */
if (j==256 || in_EOF == FALSE )
j = 0;
if (asm_command != 0x88 ) break;
if (asm_data_byte!=0) break;
asm_ptr = max_ctr;
if (asm_command == 0x87 )
Ah, there's a "256" in there -- so that immediately jumped out at me. It appeared to be filling an array of 256 elements and then calling the assembly code to write it to the SA-20. So I began tracing through the C code and corresponding assembly code. My initial thought was -- maybe it's an array size issue and only writing 255 characters and dropping the 256th character off. Could Needham's really have had a coding bug in this software and not have a customer complain about it since 1990? It seemed highly unlikely! But I looked through the code anyway.
I'm not great at assembly language, but I
Google'd any commands I didn't know and just tried tracking down the part it
was looping through and writing out the 256 characters. I couldn't find
any issues with the code itself. On top of that and trying some more
file transfers, I noticed that sometimes a 256th character wouldn't get
dropped. So it wasn't consistantly dropping every single 256th
character. That lead me to believe something else was up..
Parallel Port Sync Issues / CPU Skew
I had read that parallel port devices made for older computers (like 386, 486 era) sometimes had problems with port sync issues. Parallel ports have 8 pins to send data, whereas a serial port transmits data over a single pin. I'm not sure of all the specifics but parallel ports are apparently more prone to having data get messy when you use a faster cpu with older hardware and timing screws up between the computer/device. I tried reading as much as I could about parallel port sync issues & cpu skew when you use a fast processor with older devices, but I couldn't find anyone having a similar issue where just a few bytes would get messed up.
Unfortunately I didn't have a 486 computer to test with and confirm this was the problem. So I did the next best thing to eliminate the parallel port timing as the issue -- bought a RS232 db9 (female) to db25 (male) serial null modem cable since the programmer can also use RS232.
I was also wondering if it could be a hardware issue. Some hex inverter or other IC (integrated chip) flaking out. I opened up the SA-20 just to see what it looked like and.... wow, there's a lot of chips in there!!!
Just look at it..
More IC chips than I was expecting without a doubt! So, definitely not worth the time trying to poke with a meter. There's schematics included with the DOS software, but they're in an old Epson MX-80 dot matrix printer format and I could not convert them even after setting up a dummy Epson MX-80 printer driver that writes to a file on my computer. It was meant to print straight to an Epson MX-80 so has printer commands specifically for that model printer. So much for that. Basically if it's a hardware malfunction, I'd rather not invest any more time with it and salvage some parts.
But was it hardware? Let's try that RS232 cable..