- Mar 11, 2000
- 525
- 0
- 0
I recently picked up an old Needham SA-20 Eprom Programmer that uses the parallel port and DOS software. I can dump EPROM data from a chip to the memory buffer on the SA-20, then send it to the PC & checksums match fine. But when I try to load the same binary file from PC to the SA-20, it's dropping bits from the original file and obviously checksum no longer matches. It seems like it drops just about every 256th character and basically moves the data up.
Say the original hex was (the "38" on the far right of the top line being the 256th character):
11 38 11 38 11 38 11 38 11 38 11 38 11 38 11 38 <--256th
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.
What I'm wondering is if this could in anyway be a parallel sync issue or if it's more likely a coding issue. The programmer's from the early 90s and I can only find one version of the software. The source code came with it, it's a C file that calls external assembly code and from what I can tell the code looks okay. The C code takes up to 256 characters, then writes to the SA-20 via assembly code for the parallel port. It's almost as if the C code grabs 256 characters but the assembly code only writes 255 characters to the parallel port (thus 256th character never makes it). I definitely thought it might be the code, however I have seen cases where some of the 256th characters do make it.. which brings me back to parallel sync / port timing / clock skew.
If it was true port timing issues, should it be more garbled and not allow me to even dump an eprom to the PC with the correct checksum? Could it be something with a newer CPU executing assembly code differently? Was so close to getting this thing fully working!
Say the original hex was (the "38" on the far right of the top line being the 256th character):
11 38 11 38 11 38 11 38 11 38 11 38 11 38 11 38 <--256th
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.
What I'm wondering is if this could in anyway be a parallel sync issue or if it's more likely a coding issue. The programmer's from the early 90s and I can only find one version of the software. The source code came with it, it's a C file that calls external assembly code and from what I can tell the code looks okay. The C code takes up to 256 characters, then writes to the SA-20 via assembly code for the parallel port. It's almost as if the C code grabs 256 characters but the assembly code only writes 255 characters to the parallel port (thus 256th character never makes it). I definitely thought it might be the code, however I have seen cases where some of the 256th characters do make it.. which brings me back to parallel sync / port timing / clock skew.
If it was true port timing issues, should it be more garbled and not allow me to even dump an eprom to the PC with the correct checksum? Could it be something with a newer CPU executing assembly code differently? Was so close to getting this thing fully working!