Parallel Port Eprom Programmer - Dropping Bits

Status
Not open for further replies.

acebathound

Senior member
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!
 

PottedMeat

Lifer
Apr 17, 2002
12,363
475
126
huh weird issue.

easy things to check -
got a scope? see if the voltage levels are correct, maybe it should be rebuffered with a F244 or something.

it's pretty old, have you taken it apart and checked for connections that may be momentarily open/closed i.e. bad solder joints?


...so programmer->PC = okay data but PC-> programmer->PC = data error hmm.
 

acebathound

Senior member
Mar 11, 2000
525
0
0
I did open it up, found a lot more chips than I expected =) I don't have a scope, but I know some of the 74xx could be checked with the diode setting on a multimeter. I was actually thinking about using parallel/serial port monitor as I've done that in the past with some other applications and I could see what data the program is writing to the port, but the SA-20 needs to be connected to tell the computer it wants to "receive file"........ so I'm not sure if I can both monitor the port & have the SA-20 connected to initiate the request. If I could do that it would definitely isolate it to the code or hardware.

Pic of inside:
http://www.techdose.com/temp/sa20-inside.jpg

I did check the solder side visually briefly but nothing jumped out as a broken solder joint. Did not test any further with continuity test or anything.

It's definitely an odd issue, I'm having a db9/db25 null modem serial cable sent to me and will try that out since the programmer also works with rs232. This programmer uses parallel cable by default, but I've spent long enough trying to get the parallel cable to work (have tried several cables).

Such an odd issue... if I send a file < 256 characters the checksum matches just fine.
 

acebathound

Senior member
Mar 11, 2000
525
0
0
Ever get the feeling that "stuff to fix" just has a way of finding you no matter how hard you try to save yourself the agony?

I got the new db9 to db25 serial null modem cable today, hook it up.. the (#*@ thing still doesn't work! It wouldn't connect at all with the serial cable. So I figured heck with it, I'm throwing in the towel, already invested enough time. Well something made me come back to it and I decided to check the serial cable pinout. Started seeing the wiring was screwed up... I'm not sure how many types of null modem db9 to db25 serial cables they make, but I found a non-standard one anyway. So I cut the cable, stripped the wires inside, soldered them all for the correct pinout & was able to get the programmer working with the serial cable! Better yet..... the file I was trying to transfer from the PC before now retains the correct checksum when I send it to the programmer! So glad all the time spent turned into something good. Some of these old eprom chips can only be programmed by these old programmers, so even when I do buy a new usb programmer I still wanted something that could do the older chips reliably.

As for why the parallel cable didn't work, I'll have to try it again if I can ever find the 486 laptop I used to have. I'd like to know if it was just a CPU thing.
 

acebathound

Senior member
Mar 11, 2000
525
0
0
Yeah I was about to shell out some cash for the True USB GQ-4X and most likely will in the near future when I have to program something newer cause this SA-20 only supports a small handful of chips. I was reading over in mcumall's forums and they were saying some 2532A (or maybe all) are spotty... but most 2532's work. Still they're listed as (TEST) and not guaranteed to work -- so I feel like it's best to have an older programmer that was built for these things if for nothing else than a backup when a newer programmer can't handle a chip and you're wondering if it's the programmer or the chip. From what I was seeing, the True USB's are really decent programmers & have good support behind them (send them a chip that they don't support yet & they'll work on adding it). Definitely will get one at some point.

I used to have a Pocket Programmer II -- paid $250 or more for it, bought a PLCC adapter for $70 (not sure why an adapter had to cost that much). Used it maybe 20-30 times and it died.. wouldn't program anything. Sent it back to get repaired cause it was still under warranty and was told next time it's on me. I can't blame them they can't lose money making repairs all the time, but I sold it right after it was returned. I know you get what you pay for a lot of times but there are SOME things that you might as well get the cheaper version cause if it's gonna break $100 hurts a lot less than $300.

Time to program some eproms! :)
 

ModestGamer

Banned
Jun 30, 2010
1,140
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!


are you getting bad reads after writes ? I am not very clear on how you are determing the issue. Also what types of chips specifically are you pgramming ?Are you sure the chips are not pulls and or have hardened ? OLD eproms get hard to programming after a while.
 
May 11, 2008
21,143
1,216
126
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!

I do not know how the communication is happening, but with the older unidirectional parallel ports, 8 bits of data (1 byte)can be send from pc to device at a time.
But only 4 bits of data (nibble)can be retrieved at any time. As such a bit of hardware was needed to get the 8 bits as sequences of 4 bits after eachother into the pc. Perhaps there goes something wrong with respect to cable problems.

Another question is : do you run your software on a true dos environment or under windows ? Because the NT versions do not allow direct access to the hardware of the pc but maybe there is an emulation driver that you used. Perhaps there goes something wrong.

Other then that, i would almost think that your read data is being converted to a "NULL" terminated string somehow where the maximum size allowed is 255 bytes or characters.

If there are loops in the assembly code, then some form of loop unrolling instructions that is used by modern x86 cpu's can do strange things if used on old software. I remember vaguely this because some versions of windows crashed a long ago with AMD cpu's because these cpu's would unrole a software loop used for timing in in windows.
 
Last edited:

acebathound

Senior member
Mar 11, 2000
525
0
0
I do not know how the communication is happening, but with the older unidirectional parallel ports, 8 bits of data (1 byte)can be send from pc to device at a time.
But only 4 bits of data (nibble)can be retrieved at any time. As such a bit of hardware was needed to get the 8 bits as sequences of 4 bits after eachother into the pc. Perhaps there goes something wrong with respect to cable problems.

Another question is : do you run your software on a true dos environment or under windows ? Because the NT versions do not allow direct access to the hardware of the pc but maybe there is an emulation driver that you used. Perhaps there goes something wrong.

Other then that, i would almost think that your read data is being converted to a "NULL" terminated string somehow where the maximum size allowed is 255 bytes or characters.

If there are loops in the assembly code, then some form of loop unrolling instructions that is used by modern x86 cpu's can do strange things if used on old software. I remember vaguely this because some versions of windows crashed a long ago with AMD cpu's because these cpu's would unrole a software loop used for timing in in windows.

Oops, just realized I was calling it "bits" when really it's losing a byte.. 8 bits :) The issue was only happening when sending data from the PC to the SA-20 programmer (it has a memory buffer / DRAM that it stores the data to). You always write to the memory buffer on the SA-20 first before programming. So even if you put an EPROM right into the SA-20, you'd read it.. stores data in buffer, then you can write it.

My first trial was with an AMD cpu (900mhz Duron I think) -- I used both Windows XP with the "UserPort" application to allow direct i/o and also tried FreeDOS on this machine. Neither would allow the SA-20 to receive the file with a matching checksum. It still wrote to the buffer & for the most part had the correct bytes, but when I then sent the data back to the computer I could see a few bytes were dropped every 256th or so. I then tried an Intel based computer.. think that was a Celeron 850mhz, which admittedly was giving me more problems when attempting to start the DOS program but I did get it to work one time and had the same issue with dropping bytes.

There were loops in the assembly code too -- so I was suspecting them. I did whip up a quick intel assembly with similar loop code though and it appeared to loop correctly on the AMD machine.

If I can ever find the 486 laptop that's around here somewhere I'll probably test the programmer out again on that, for curiosity sake. The serial cable is working great though, so I'm a happy camper :) Fixed a Williams System 7 pinball board that had 2 bad roms with it over the weekend!! Can't complain when you fix two things in the same day.
 
May 11, 2008
21,143
1,216
126
Oops, just realized I was calling it "bits" when really it's losing a byte.. 8 bits :) The issue was only happening when sending data from the PC to the SA-20 programmer (it has a memory buffer / DRAM that it stores the data to). You always write to the memory buffer on the SA-20 first before programming. So even if you put an EPROM right into the SA-20, you'd read it.. stores data in buffer, then you can write it.

My first trial was with an AMD cpu (900mhz Duron I think) -- I used both Windows XP with the "UserPort" application to allow direct i/o and also tried FreeDOS on this machine. Neither would allow the SA-20 to receive the file with a matching checksum. It still wrote to the buffer & for the most part had the correct bytes, but when I then sent the data back to the computer I could see a few bytes were dropped every 256th or so. I then tried an Intel based computer.. think that was a Celeron 850mhz, which admittedly was giving me more problems when attempting to start the DOS program but I did get it to work one time and had the same issue with dropping bytes.

There were loops in the assembly code too -- so I was suspecting them. I did whip up a quick intel assembly with similar loop code though and it appeared to loop correctly on the AMD machine.

If I can ever find the 486 laptop that's around here somewhere I'll probably test the programmer out again on that, for curiosity sake. The serial cable is working great though, so I'm a happy camper :) Fixed a Williams System 7 pinball board that had 2 bad roms with it over the weekend!! Can't complain when you fix two things in the same day.

If it works over the serial cable. I would think it is time to call out : victory ! :D.
 

ModestGamer

Banned
Jun 30, 2010
1,140
0
0
Oops, just realized I was calling it "bits" when really it's losing a byte.. 8 bits :) The issue was only happening when sending data from the PC to the SA-20 programmer (it has a memory buffer / DRAM that it stores the data to). You always write to the memory buffer on the SA-20 first before programming. So even if you put an EPROM right into the SA-20, you'd read it.. stores data in buffer, then you can write it.

My first trial was with an AMD cpu (900mhz Duron I think) -- I used both Windows XP with the "UserPort" application to allow direct i/o and also tried FreeDOS on this machine. Neither would allow the SA-20 to receive the file with a matching checksum. It still wrote to the buffer & for the most part had the correct bytes, but when I then sent the data back to the computer I could see a few bytes were dropped every 256th or so. I then tried an Intel based computer.. think that was a Celeron 850mhz, which admittedly was giving me more problems when attempting to start the DOS program but I did get it to work one time and had the same issue with dropping bytes.

There were loops in the assembly code too -- so I was suspecting them. I did whip up a quick intel assembly with similar loop code though and it appeared to loop correctly on the AMD machine.

If I can ever find the 486 laptop that's around here somewhere I'll probably test the programmer out again on that, for curiosity sake. The serial cable is working great though, so I'm a happy camper :) Fixed a Williams System 7 pinball board that had 2 bad roms with it over the weekend!! Can't complain when you fix two things in the same day.


your issue is port timing speeds. You need to slow down the ports. Those old programmer will loose data and or have buffer errors if you send to much information to fast. I own about 12 eprom programmers a few datamans and a bunch of others.

BTW watch your chip timing on older chips. as they age they typically need more voltage and slower programming speeds to pop the bits.

If you ever need something programmed and don't have a programmer for it. Drop me a line I most likely do have the programmer ya need. throw them in the mail with return postage and image files in Binary and I will burn them for ya.
 

acebathound

Senior member
Mar 11, 2000
525
0
0
your issue is port timing speeds. You need to slow down the ports. Those old programmer will loose data and or have buffer errors if you send to much information to fast. I own about 12 eprom programmers a few datamans and a bunch of others.

BTW watch your chip timing on older chips. as they age they typically need more voltage and slower programming speeds to pop the bits.

If you ever need something programmed and don't have a programmer for it. Drop me a line I most likely do have the programmer ya need. throw them in the mail with return postage and image files in Binary and I will burn them for ya.

Makes sense, glad to have someone confirm the port timing! Thanks for the info & the kind offer =)
 

ModestGamer

Banned
Jun 30, 2010
1,140
0
0
Makes sense, glad to have someone confirm the port timing! Thanks for the info & the kind offer =)


No problem. I play in the binary world of hex and dissassembling motorola stuff back into source code. All kind of wierd stuff. C etc code is completely lost on me.
 
Status
Not open for further replies.