[PDE]

Is anyone able to tell me the address of ROM1 for the GUF1 strategy?
I know for GUFB it is 786A, but this address does not work for GUF1.
Appreciate your help.

[PDE]

Let me be more specific.
Need to know this address, so I can set it from 2000 to 0 to eliminate Code 15 during KOEO test.
Some of the the tuning software suppliers that don't recalculate the checksum do this as a work-around.
I assume that they would know the address where this resides since they include it in their software.
Any help is appreciated. GUF1 Strategy.

[cgrey8]

0x786a is what's in the open source GUF1 def. If that's wrong, it's been wrong for a long time.

I didn't check the latest TunerPro def.

[mpaton]

7826

[cgrey8]

This must have never worked for the BE GUF1 strat. I'm curious as to what data it was corrupting!
It probably makes sense that ROM2 is also wrong. Do you know what its offset is? My guess is it's 2-bytes away making it 0x7828.

I'll see if I can get that updated.

What's GUFA's offsets for these? I'll update that def too if wrong.

[cgrey8]

I'll hold off on updating the defs until somene can confirm GUF1 ROM2 address and GUFA ROM1 & ROM2 addresses.

I'm assuming GUFB is correct since it's the more popular of the GUFx trio and nobody's complained about it.

[sailorbob]

Yes, the 'ROM2' address is at the next address.

The GUFA 'ROM1' address is at 0x7858.

[cgrey8]

Thanks.
I got them updated and mailed to Clint for publishing. These will be v99 as published.

[PDE]

Is the checksum calculation still done from 2000 Hex to 9FFF Hex or has that changed as well?

[cgrey8]

The only change I made to the defs were the address offset location of where ROM1 and ROM2 are to be found in the tune (*.bin). I didn't change anything else.

If you open the def file and go to the config tab, you'll see the start and end of the checksum calc is defined, and is 2000-9FFF. Note though, these are BE's settings for how it calculates the checksum to place into ROM_TO...not the EEC's settings for it's own runtime start and end memory location. Although it is assumed that the values, as defined, in your def file should match what the EEC is going to be doing at runtime.

In my GUFB-based tune, my ROM1 value is 8192 (0x2000) which is as expected. However my ROM2 value is 40958 (0x9FFE), not 0x9FFF as defined in the def. I don't know if the EEC checksums 2-bytes at a time and thus 0x9FFE implicitly includes 0x9FFF or if this is something that's been in error in my tune since the beginning.

[PDE]

Thanks for the information.
I would think that the checksum range must be correct as well.
My tune is running perfectly fine but cannot get rid of code 15.

I put zeros in for ROM_TO 200A & 200B and also in the FIXSUM locations 2004 & 2005.
After that I ran a checksum from 2000 to 9FFF and got a sum of 6C87 HEX.
The checksum for the entire chip is FA23.

Do you know what the algorithm is that the BE guy uses to calculate the correct ROM_TO word?
Now that I have the checksum 6C87, what are the next steps to calculate the ROM_TO?
I'd like to understand how he does it. I don't have QH or BE although I would buy them as long as I knew they would work.

Thanks again

[jsa]

Looking at TVRfans GUFB/A9L disassembly;

Code: Select all

############################################################
# ROM Checksum
############################################################
   Do_Csum:
7844: 01,30               clrw  R30              R30 = 0;
7846: 01,3c               clrw  R3c              R3c = 0;                          # 
7848: a1,6a,78,42         ldw   R42,786a         R42 = 786a;                       # Start address (2000)
784c: 46,43,00,3a         ad3w  R3a,R0,[R42++]   R3a = [R42++];                    # End address  (9fff)
7850: df,0d               je    785f             if (R3a != 0)  {                  # If real end address
7852: a2,43,3e            ldw   R3e,[R42++]      R3e = [R42++];
7855: 66,3b,3c            ad2w  R3c,[R3a++]      R3c += [R3a++];                   # add to sum
7858: 88,3e,3a            cmpw  R3a,R3e                                            # end address reached?
785b: d1,f8               jleu  7855             if ((uns) R3a <= R3e) goto 7855 ; # loop
785d: 27,ed               sjmp  784c             goto 784c ; }                     # load next ROM range

785f: 88,3c,00            cmpw  R0,R3c           
7862: df,03               je    7867             if (0 = R3c) goto 7867 ;          # checksum zero ?
7864: 2b,48               scall 7bae             SaveTCode1(15);                   # E15 - EEC ROM fail
7866: 15                  #args  
7867: 20,62               sjmp  78cb             goto 78cb ;                       # zero 1CA timer, incr R38 self test index, and return

7869: ff                  ???   

######################## ROM checksum adresses ##############
786a: 00,20               word   2000                                              # start address(set 0 for no checksum test) # Chkbase               checksum base address. Set to
                                                                                    zero to clear error code 15
786c: fe,9f               word   9ffe                                              # last address of ROM checksum
786e: 00,00               word      0
.
.
.
## 9ea1 to 9fff = ff (filler ?) ## 

You will see;
The start and end addresses are read from words at 0x786A and 0x786C.
The addition is word by word, so word at 9ffe captures 9ffe and 9fff.
200A & 200B are not excluded from the sum calculation.
A valid sum equals zero.

You can tell BE to change any address to zero the checksum.
It does not have to be ROM_TO or FIXSUM. It could be in filler if you wished.

@cgrey8 Please meld this and the other new thread as you see fit.

[cgrey8]

That's interesting to know.

The ROM_TO value is not the checksum, per se. It's a location that's been chosen that's intended to make the checksum calculation equal 0 at runtime. As you said, any unused location in the range indicated (0x2000-0x9fff) would suffice to make this happen, but ROM_TO is as good as any.

I never fully understood the nuance of how this worked.

[tvrfan]

I have a practical viewpoint............

Putting that checksum value near the front makes ALL changes (i.e. different versions) immediately obvious to anyone looking at it..........so makes sense for that purpose, rather than 'hiding' it in a load of other values. I guess the same would be true it it was put right at the end as well though (0xfffe).

and of course that checksum includes calibration data changes as well as code, so covers everything.

Yes, most (all?) of the checksum code I've seen uses WORD access, so addresses are from 0x2000 to 0xfffe (or 0x9ffe or whatever).

Some of the multibanks do have 'holes' or limits in the address ranges for each bank, which I'm fairly sure is for specialist chips which are mapped to particular addresses, and may not always return the same values on a read, so can't be included.

So a tuner plugin could put a checksum 'fix' value in at last address (0xfffe, 0x9ffe,...) instead of changing the front value at 0x200a, and it would work just as well.

[sailorbob]

The ROM_TO value is the compliment of the checksum so, in every practical sense, it can be considered to be the checksum.

[PDE]

Thanks for the information, it really helped me to figure this out.

For those of you using the GUF1 strategy, which are most automatics, here is what I found.
7826=0
7827=20
which make a word of 2000

7827=FE
7828=9F
which make a word of 9FFE

So changing 7827 from 20 to 0 (zero) did actually work eliminating code 15 for KOEO test.
I hope this helps others.

[sailorbob]

Disabling the checksum routine is not recommended as you will not know if the ROM becomes corrupted. It is far better to recalculate the ROM_TO value.

[jsa]

PDE, Have you got a tuned bin with unadjusted checksum or faulty rom hardware?

[PDE]

Yes I have a good tune with an unadjusted Checksum for the BIN.
For that reason, I am going to invest in a Moates QH in the near future, so I can adjust the checksum as I will probably be making some more adjustments to this tune in the spring.
For now, this will suffice and appreciate your knowledge and help!

[jsa]

No worries. The thanks really goes to those who have done all the ground work for the info I shared.