Data IO 29B Unipak and Harris 7621 & 7685 PROMs

JuanUp

Active member
Joined
Jan 25, 2007
Messages
904
Reaction score
36
Location
Orange County, California
Data IO 29B Unipak and Harris 7621 & 7685 PROMs

I set the device to a Harris 7621 or 7685. When I load a .BIN file, it doesn't set the high nibble of any of the bytes of data, (0F 01 04 0E instead of 2F 91 34 AE etc.), in the programmer's RAM and returns 'CHECKSUM ERROR'. However, I set the device to an AMD 2716 and the same .BIN file loads fine in to the programmer's RAM. With the correct data loaded, I'll then switch the device to the Harris 7621 or 7685 and *BAM* the high nibble of all the bytes switch to zero in the programmer's RAM when I view it.

WHAT... THE... F... is going on? Keep in mind that I haven't read any datasheets on either chip yet. I'm venting more than anything.

Annoyed...
Juan
 
I had that problem with one particular bin file on my data I/O. I did not have time to investigate and ended up using a spare programmer I had. The base unit then got flakey and I replaced it. Never did try the file on the replacement and can't even tell you which one.

Could be a number of things. If you send the bin files to me I can try loading them in mine and see what happens. PM me if interested and I will pm back my email addy.

Bill
 
thats because its a 4 bit wide prom. Go into setup, memory parameters, and reset the word width to 4 bits and it'll function as it should.
 
I set the device to a Harris 7621 or 7685. When I load a .BIN file, it doesn't set the high nibble of any of the bytes of data, (0F 01 04 0E instead of 2F 91 34 AE etc.), in the programmer's RAM and returns 'CHECKSUM ERROR'. However, I set the device to an AMD 2716 and the same .BIN file loads fine in to the programmer's RAM. With the correct data loaded, I'll then switch the device to the Harris 7621 or 7685 and *BAM* the high nibble of all the bytes switch to zero in the programmer's RAM when I view it.

WHAT... THE... F... is going on? Keep in mind that I haven't read any datasheets on either chip yet. I'm venting more than anything.

Annoyed...
Juan

Harris made great PROM's and other components...but I just might be a little biased on that one. :)

However, both 7621 and 7685 are 4-bit wide parts - there is no upper nibble on them. Not sure how your original checksum got generated but it sounds like the checksum may have taken into account the upper 4-bits when it should not have. The Data Oh-No is zeroing the upper 4-bits (as they are not used) and then recalculating the check sum. Lo and behold, they no longer match. It sounds like your original checksum may be incorrect.

Ed
 
Well, I tested setting the word length to '4' and the data still will not load correctly... or does it?

The low nibble in the .BIN hex file vs the RAM in the programmer are identical from 0x0000 to 0x03ff when I view it in a hex editor. Everything after that is garbage, (actually, the .BIN file had '?F' from 0x0400 to 0x07ff on the file), or '00' in the programmer, (I clear all RAM data before reading the device or loading the .BIN file).

The 7685 has a 2K 4 bit/word format, (8192 bits).

So there's a few things that might be going on:

  • The .BIN file has garbage in the high nibble... probably from a previous 8-bit word burn and the checksum was calculated outside of the programmer.
  • The high nibble in the .BIN file is data for 0x0400 to 0x07ff...
  • There were only 1024 4-bit words programmed...
  • Everything's broken and I'm going insane...

I'll test all of these later.

Juan
 
I hope the food was good at lunch :)


Well, I tested setting the word length to '4' and the data still will not load correctly... or does it?

The low nibble in the .BIN hex file vs the RAM in the programmer are identical from 0x0000 to 0x03ff when I view it in a hex editor. Everything after that is garbage, (actually, the .BIN file had '?F' from 0x0400 to 0x07ff on the file), or '00' in the programmer, (I clear all RAM data before reading the device or loading the .BIN file).

The 7685 has a 2K 4 bit/word format, (8192 bits).

So there's a few things that might be going on:

  • The .BIN file has garbage in the high nibble... probably from a previous 8-bit word burn and the checksum was calculated outside of the programmer.
  • The high nibble in the .BIN file is data for 0x0400 to 0x07ff...
  • There were only 1024 4-bit words programmed...
  • Everything's broken and I'm going insane...

I'll test all of these later.

Juan
 
After some VBS coding, (and some soul searching), I removed the high nibble from the originally burned PROMs that are found on the web. It matches exactly to the first 1024 bytes of data. The remaining data seems to be garbage, (all low nibble 'F').

What bugs me is that it's a 2048 word 4-bit PROM with only 1024 word 4-bit data on it.

I have a feeling the most significant bit address pin is dead and can't access that portion of the ROM.

Burnin' the midnight oil...
 
Yes, it has several... but if the ROM dumps were bad from the beginning then it makes it a lot harder to debug. :) Fortunately, it wasn't the MSB pin that was bad but I'm still concerned about the upper 1024 4-bit words of empty data on that 7685-5.
 
Back
Top Bottom