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:
*file_to_sa()*/
/*downloads file to sa via printer port */
file_to_sa()
{
FILE *fileptr;
int ch;
int j=0;
int in_EOF;
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 */
/* printf("fname=%s",asm_filename_buf);
*/
if( (fileptr=fopen( asm_filename_buf, "rb")) ==
NULL) /* open file */
{
asm_data_byte
= 1;
asm_sa_command();
}
in_EOF=TRUE;
while(in_EOF != FALSE)
{
if (asm_file_pack_resend_ctr !=0) goto not_read_next_256;
if (asm_data_byte!=0) break;
ch=getc(fileptr);
if (ch == EOF) in_EOF = FALSE;
xfer_buf[j]=ch; /* put next char to 256 buffer */
j++;
if (j==256 || in_EOF == FALSE )
{
if(in_EOF==FALSE) j--;
if(j==0) break;
asm_len=j;
j = 0;
max_ctr++;
not_read_next_256:
asm_sa_command();
if (asm_command != 0x88 ) break;
if (asm_data_byte!=0) break;
}
}
fclose(fileptr);
asm_ptr = max_ctr;
asm_data_byte=2;
/*
if (asm_command == 0x87 )
{
goto new_file_to_sa;
}
*/
asm_sa_command();
}
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.
Hardware Issue?
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..