Connecting the SA-20 to the
**Note: did not work 100%, I suggest using a db9 to db25 null serial modem cable**
Next I connected the programmer with a parallel cable (printer cable) to another desktop I had since my primary desktop didn't have a printer port. It's amazing how many computers don't have printer ports nowadays!! Actually it's really really annoying. But to be fair, USB is much nicer and faster. It just sucks when you're trying to connect something older and have to go scavenging for "rare" computers with parallel ports.
So with everything connected I turned the
SA-20 on and... no go. Didn't expect it to be easy! Found out that
under Windows XP direct access to the i/o ports (like the parallel port) are
protected. So you have to grab a program called UserPort
in order to open up direct access to these ports. You take the .sys file
included with the UserPort zip and put that in your
c:\windows\system32\drivers directory. Then just run UserPort.exe (you
may need to check the port address ranges against your parallel printer port
but the defaults are the common port ranges).
After installing UserPort and exiting & restarting the SA.exe software several times I was able to connect to the SA-20! Not saying it was easy, but I expected to have to fight with getting this thing to work. And.... as it turns out, that's exactly what it was headed towards.
I put in a 2716 eprom and tried reading it on the SA-20 -- success. Checked the device checksum, it gave me "34511". Set the file input/output parameters on the SA-20 (filename, file pointers, file type). I then tried sending the file to the computer and was able to transfer it successfully. Checked the checksum via the hex editor and it matched the original checksum of the eprom on the SA-20! Awesome!
Next I tried sending the same file back from the PC. Checked the checksum of the memory buffer on the SA-20 (when it receives a file it stores the data in the memory buffer... it also does this when you read an eprom on the device) -- it didn't match. BUMMER!!
page1 page2 page3 page4
I'm Losing My Bytes!
It was clear something was happening to the data when sending the file to the SA-20 via the parallel port. So I sent the "bad" data back to the computer to look at in more detail. Again the checksum of the bad data on the programmer matched the checksum of the file that was transferred (that's a good thing). So the data's only getting messed up when sending a file to the SA-20.
Opened up the original file & the "bad data" file sent back from the SA-20. The data in the files looked pretty close. But obviously something was changing cause the checksums didn't match. Turns out, there were only a few bytes of data changing -- and it appeared to happen just about every 256th character sent from the original file.
Say the original hex looked like this (the "38" on the far right of the top line being the 256th character):
<<bunch of lines representing first 256 characters in file>>
11 38 11 38 11 38 11 38 11 38 11 38 11 38 11 38 <--256th character
00 55 00 55 00 55 00 55 00 55 00 55 00 55 00 55
A lot of times this happens:
11 38 11 38 11 38 11 38 11 38 11 38 11 38 11 00
55 00 55 00 55 00 55 00 55 00 55 00 55 00 55 FF
Notice the 38 on the far right of the top line is removed and rest of the data is moved up and at the end there's an FF (which is just what the memory buffer on the SA-20 blanks the addresses to).
So it's dropping the 256th characters from the original file a lot of times (say original file was 1024 characters, it would drop the 256th, 512th, 768th & 1024th characters) -- and the end of the data sent would have just as many blank "FF" bits as those that were dropped. Essentially it's like sending "ABDEF" instead of "ABCDEF". NOT GOOD when you're programming chips. The data needs to be *EXACTLY* the same as the original file (ie. matching checksums), otherwise the chip won't work.
So, I tried figuring out why it was dropping bytes..