Same BCC, but diffrent bins?

[JeepsAndGuns]

I found this kida odd. The reason I found out was just pure curiosity, still dont even know why I checked, but I did.
Heres what I found. I have a 7427 memcal, with the BCC of BNKM. Its a V8 $31 bin. It was what was in my spare 7427 I keep. I then bought another V8 memcal from another member, witch has the same BCC. I figured it would be handy to have a extra V8 memcal around.

When I got the memcal, I noticed it had a sticker on it with the BCC. It looks to be the same silver material and font as whats on the old 7747 chips I have. I thought this was odd, as the other memcal I have with the same BCC, has it "printed" on the blue cover itself. All the other memcals I have ever seen are the same way. They have the BCC printed on the body, no stickers.
There are also other numbers on there, and then stickers and more numbers on the actual chips.

On the "printed" memcal, it goes as follows:

DELCO
3480 BNKM

Then on the chip:
5125
1618
8020

On the "sticker" memcal, it goes as follows:

BNKM
1621
3479

Then on the chip:
6128
1618
8020

I took my memcal readout header and read both and saved them. Seeing the diffrences, something told me to compare them. So I loaded them up and used the diffrence finder in TP and it found a crapload of diffrences. 99.9% of them were in undefined areas, and the only defined areas was "platform ID (MSW)" and "platform ID (LSW)"
The sticker one has FFFF, while the printed one has 7F7F. What oes that mean?

So anyone have any clue as to what the diffrences might be that are in the undefined areas? And why one has a sticker instead of being printed? Could it be a factory replacement? I will attach the bins if anyone wants to look at them. The sticker ones is called BNKM-3479, and the printed one is BNKM-3480.

[RobertISaar]

i've seen this once or twice before... since all of the changes were in undefined areas, it sounds like an algorithm change.

[EagleMark]

and what does that mean?

One looked like filled spots with 00 and other looked like filled spots with FF. Why?

[jim_in_dorris]

I am not 100% positive on this, but IIRC when I was learning $0D I had a conversation with 98 about 0 fill versus FF fill. Before address $4000, nothing is changable, that is all RAM and Prom addresses, so it doesn't matter what is in there. If you are assembling it, you can use that as an equate area to define stuff you reference in the code.

[JeepsAndGuns]

and what does that mean?

One looked like filled spots with 00 and other looked like filled spots with FF. Why?

I noticed that too, most al of them was 00 on one, and FF on the other, but if you keep scrolling down, you will see some lines that have other numbers in them.

Jim, your saying its basicly changes in the code, and not the bin? What is, and why is it diffrent, when they are both the same BCC?

[EagleMark]

Jim, your saying its basicly changes in the code, and not the bin? What is, and why is it diffrent, when they are both the same BCC?That is what I am wondering as well. I didn't look to see if the rest of hex in bin area was same, just thought it strange that same bin changed ram area from 00 to FF? 00 in decimal is 000 and FF in decimal is 255. One extreme to the other...

[historystamp]

BitHoist gives these results, not that I know how to interpret.

1756

[jim_in_dorris]

After address 4008 there are no differences. I used a hex compare to check it. Remember that before 4000, all the addresses are hardware, not prom addresses. To change from FF to 00 use the DS directive (DS $100 fills the next 100 addresses with zero's) My guess is that BNKM-3479 is an early release that changed to -3480 for production. If you look at $0d bins, some are $FF and some are $00 in the first $4000 addresses.

[JeepsAndGuns]

So for those of us who are less knowledgeable in computer code, what does that translate to?

What is the diffrence between 00 and FF?
And whats platform ID?

[RobertISaar]

meaning everything before 4000(or at least the FF or 00 blocks) can be changed from whatever they are now to pretty much anything, since the MCU will not attempt to read the PROM if it's accessing a register/RAM.

[1project2many]

Well, first off this means that the code and cal you're looking at are only 48k large and the data below $4000 is unused. So from $4000 up there are only 4 differences. Second, it means that the sequence information which gives a date and cal # are not used properly. That's all.

The difference between $00 and $FF is the difference between 00000000 and 11111111. An Eprom is set to all 1's when it's erased. A burner's software only changes 1 to 0 when needed during programming. It cannot change 0 to 1. So 00 is fully programmed and couldn't be changed without a complete erasure. Platform ID is a GM variable, likely designed to have info regarding the make/model (platform) the cal was installed in. Many times it's not used and this is true in many of the $0D cals I looked at. I have also seen BCC's with different numeric codes but they have no significant differences.

[JeepsAndGuns]

So basicly, the diffrences are in a area of the chip that is not used and means nothing?

[93V8S10]

Well it is used by the code when operating (gets changed constantly), but as far as looking at the bin goes, it means nothing.

[gregs78cam]

Yes the first 4K is RAM used by the PCM to write to and read data from. That is also where the ALDL portion of the code pulls data from to send out in the datastream. If there is anything written there, at key on it will be overwritten with a new value during the first cycle.

[1project2many]

The processor can address locations from $0000 to $FFFF. It has no idea what's at those addresses, it just reads and writes as instructed. The eprom in the memcal has to be set up a special way. The "end" of the program has to be at the last address the processor can access, $FFFF. The last two bytes of the chip contain the address where the processor starts running code, called the reset vector. If the end of the eprom has to be at $FFFF as seen by the processor, then the beginning address of the eprom depends on how much data is in the eprom.

When you "read" the eprom in a hex editor, the editor will show you the file beginning at $0000 and ending wherever it runs out of data. In the case of these calibrations it runs to $FFFF. The fact that this is the same address as $FFFF above is purely a coincidence. Smaller calibrations could end at $BFFF, or $3FFF, or any other address. The only catch is that when they're put into the memcal, the ecm / pcm has to be able to look at the last address to get the reset vector. If you've ever seen someone say they have to load a cal "in the top" or "in the upper half" of a chip, this is why.

Below $4000 cannot be all ram. There are hardware addresses in the $3000 range. $3FC0 contains a value used for RPM. $3000 is the base address for CPU registers. $3209 is a value representing the last time between ref pulses, used for checking change in RPM. $30F8 and $30F9 are time values provided by hardware representing total engine run time since started. $326F and $3270 will contain injector PW times as reported by hardware. These values can be accessed like RAM but they are not RAM. $2000 to $2FFF is not available to the processor. There are no writes or reads to these addresses. This is typical of GM ecm's. $1800 would contain the code and addresses used for the external heads up display used by GM engineers during calibration development. When this hardware is not connected, these addresses are not available to the processor.

The eprom is a ROM which is read only memory. If any address lines are wired so the processor can access eprom locations below $4000 it will not be able to successfully write to these locations. For the most part these locations are completely invisible to the processor. They also should never change after programming. They are, after all, Read Only.

HTH

[gregs78cam]

You're right not the whole 4K.