Needham SA-20 Eprom programmer
Needham SA-20 Eprom programmer
Connecting the SA-20 to the
Parallel Port
**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
(http://hem.passagen.se/tomasf/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!!
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..