GS ROM 1 checksum

[g***@sasktel.net]

I finished correcting the bugs in applesoft according to the Bandaids article from Nibble. And I added a couple of my own fixes.

The GSPort emulator freezes up on startup, but a control-reset gives me some functionality. I can Load, Bload, Save and Bsave files, but using the smart dash command and using BYE just hangs.

Sweet16 won't launch but says the ROM file is corrupt.

There are some free bytes in ROM I can add additional bytes to balance the checksum for the ROM image.

Does anyone have the means to balance the checksum to be the same as the original?

I am using GS ROM 1

Rob

[g***@sasktel.net]

I borrowed the ROM 03 checksum routine and revised it a bit for ROM 01. This is what I came up with.

0300: 18 CLC
0301: FB XCE
0302: C2 30 REP #30
0304: A9 00 00 LDA #0000
0307: AA TAX
0308: 18 CLC
0309: 7F 00 00 FE ADC FE0000,X
030D: 08 PHP
030E: E0 F6 FF CPX #FFF6
0311: F0 07 BEQ 031A {+07}
0313: 28 PLP
0314: 7F 00 00 FF ADC FF0000,X
0318: 2C EA 28 BIT 28EA ; After the 2C is a NOP and a PLP
031B: E8 INX
031C: E8 INX
031D: D0 EA BNE 0309 {-16}
031F: 85 06 STA 06
0321: 38 SEC
0322: A9 34 12 LDA #1234
0325: E5 06 SBC 06
0327: 85 08 STA 08
0329: 38 SEC
032A: FB XCE
032B: 20 8E FD JSR FD8E
032E: A5 08 LDA 08
0330: 20 DA FD JSR FDDA
0333: A9 A0 LDA #$A0
0335: 20 ED FD JSR $FDED
0338: A5 09 LDA $09
033A: 20 DA FD JSR $FDDA
033D: 20 8E FD JSR $FD8E
0340: 4C 69 FF JMP $FF69


Two problems.

First, this routine is out by 2 when run on a non-revised ROM image. The bytes at $FF/FFF6.FFF7 are E9 and 67 consecutively. This routine comes up with EB and 67. Ok, no problem. I will just subtract 2 from the revised ROM image.

Second problem. How to do a checksum on a 256 kb file running under Prodos 8?

GSport to the rescue. It allowed me to load the ROM file that was revised even though it has a bad checksum. Running the checksum program on the revised ROM image gave me bytes of D3 and 6B.

So I subtracted 2 from the D3 to give me D1 and 6B. Plugged those into the revised ROM image. All should have been well, right?

Sadly, no. I tried both D1 6B and D3 6B in the revised image and nada. Going into the ROM verifies that the bytes at FF/FFF6.FFF7 have indeed been changed to these values.


Any suggestions, links or otherwise to steer me in a different direction. The checksum links out there are all for ROM 03.

Rob

[g***@sasktel.net]

Adding 2 lines takes care of a possible carry when the checksum is complete.
The Checksum now comes out correct.

0300: 18 CLC
0301: FB XCE
0302: C2 30 REP #30
0304: A9 00 00 LDA #0000
0307: AA TAX
0308: 18 CLC
0309: 7F 00 00 FE ADC FE0000,X
030D: 7F 00 00 FF ADC FF0000,X
0311: E8 INX
0312: E8 INX
0313: D0 F4 BNE 0309 {-0C
0315: 69 00 00 ADC #0000
0318: 38 SEC
0319: ED F6 FF SBC FFF6
031C: 85 06 STA 06
031E: 38 SEC
031F: A9 34 12 LDA #1234
0322: E5 06 SBC 06
0324: 85 08 STA 08
0326: 38 SEC
0327: FB XCE
0328: 20 8E FD JSR FD8E
032B: A5 08 LDA 08
032D: 20 DA FD JSR FDDA
0330: A9 A0 LDA #$A0
0332: 20 ED FD JSR $FDED
0335: A5 09 LDA $09
0337: 20 DA FD JSR $FDDA
033A: 20 8E FD JSR $FD8E
033D: 4C 69 FF JMP $FF69


Although the checksum now comes out correct, the revised ROM images still do not work properly. Are the emulators doing some other checking?

[Antoine Vignau]

Why did you want to revise the ROM checksum routine? It works well, doesn't it?
av

EJECT
TITLE 'Vegas ROM test'
;...............................................................
; ROM.CHECKSUM
;
; Compute Checksum of rom banks $FE, $FF.
; and compare with expected value
;
; Call : In Full native mode, Data Bank 0, use JSL
; Return: In Full native mode
;
; 20 Feb 86: Created
; 09 Apr 86: Add register based ram test
;
;...............................................................

; SEG RUNBANK
ROM_CHECKSUM EQU * ;Called from test sequencer
STZ RamBank
JSR DoZPageInd ;Register based ram test first
DATA16
BCS BAD_RAM ;Ram is bad so report and stop
STZ CHK_BEG ;Starting address
PEA |$FCFC ;Firts bank $FC
PLB
PLB ;et data bank register
LDY #$FFFF ;Entire 64k of rom
JSR CAL_CHECKSUM ;Go get checksum
PEA |$FDFD ;Bank $FD
PLB
PLB
DEY ;Entire 64k of rom
JSR CAL_CHECKSUM2 ;Get checksum
PEA |$FEFE ;Bank $FE
PLB
PLB
DEY ;Entire 64k of rom
JSR CAL_CHECKSUM2 ;Get checksum
PEA |$FFFF ;Bank $FF
PLB
PLB
DEY ;Entire 64k of rom
JSR CAL_CHECKSUM2 ;Get checksum
;
; Note that the rom checksum must be adjusted
; to equal $1234
;
CMP #$1234 ;Compare with a fixed value
; Change CHECKSUM condition in file: MAIN
IF CHECKSUM <> 0 THEN ;Normally do next line
BNE BAD_ROM ;Bad checksum so fail
ELSE ;Do next line for debugging only
BRA GOOD_ROM ;Don't fail ROM checkum
ENDIF
GOOD_ROM EQU * ;Rom ok
CLC
RTL
BAD_ROM EQU * ;Rom does'nt check out
STA >TST_STATUS+1 ;Save actual checksum for display
LDA #$CDD2 ;"RM" = RoM fail
STA >LINE1+$100 ;Put "RM" msg on screen in case system hangs
SEC
RTL ;ttempt to return to sequencer to put bad message on screen
BAD_RAM EQU * ;Encountered bad ram during rom test
LDA #$01 ;Bad ram
STA |TST_STATUS+3 ;01-> can't do rom tst because bad ram
STA |TST_STATUS+1 ;Error that occurred (See Test code)
SEC
RTL
EJECT
;...............................................................
;
; Calculate Checksum. 16 Bit ADC
;
; Call : In Full native mode, use JSR
; Return: In Full native mode
;
; Inputs:
; C: Partially computed checksum, or else 0
; CHK.BEG: Start address to checksum (Zero Page var)
; Y: No Bytes (odd) to checksum
; B: Set data bank reg to required bank.
;
; Output:
; C: Checksum of C to C+Y inclusive
;
;
; Note: Have partially computed checksum in C when
; dealing with more than one bank.
;
; xxx nov85
;...............................................................
CAL_CHECKSUM EQU * ;Enter here first bank with C=0, else enter next line+1
LDA #$0000 ;Clear checksum to zero
CLC
CAL_CHECKSUM2 EQU * ;Enter here for remaining banks.
DEY ;rop to low byte of top address
N_NXT_CHK EQU *
ADC (CHK_BEG),Y ;Add to previous value
DEY ;ve to next byte
BEQ CHK_END ;Fin except for last 2
DEY ;ve to next byte
BNE N_NXT_CHK ;do next two bytes
CHK_END EQU *
ADC (CHK_BEG),Y ;Add last 2 bytes
RTS ;eturn in Native 16 mode

[g***@sasktel.net]

Post by Antoine Vignau
Why did you want to revise the ROM checksum routine? It works well, doesn't it?
av

I wanted to apply the Bandaids fixes from Nibble which fixes all these issues

Bandaids Fixes

- fixed multiplication routine
- fixed reference to certain illegal line numbers
- fixed more than one decimal point not allowed
- statements after "onerr goto" are now recognized
- get number value now fixed
- fixed stack to allow a return to properly terminate for-next loop
- fixed expression after "to" statement
- call without argument defaults to call-151
- a line number is now printed after an error message
- strings that have a length of zero, now returns a null string
- spaces are now used as delimiters when parsing
- replaced duplicate fp value at $F08F to PI/180 value
- FP representation of -32768 now has 5 significant bytes


My own personal choice fixes:

- make the routine @$d500 into a subroutine so UNNEWing a program is as easy as calling the subroutine.

- make the move routine at $D393 into a subroutine to move programs and data up in memory so the subroutine can be used to insert data or text.


Main reason for doing all this is, I like trying to pack as much programming power into an 8 bit machine as possible. By making subroutines in applesoft greatly reduces the code in my ML programs and may even speed up applesoft.

I have already given applesoft a lot of power and greatly reduced the memory usage and sped up some of the applesoft code substantially. For me, both ML and Applesoft are far easier to program than C or Pascal.


I don't believe your routine is totally complete, av. Your routine doesn't take into account the two checksum bytes at $FF/FFF6 and FFF7?

My third post that has the corrected checksum routine that gives the correct checksum.

My routine calculated the un-revised ROM 01 and returns the adjusted checksum of $67E9 which is what is in $FF/FFF6.FFF7

[g***@sasktel.net]

Post by g***@sasktel.net
My routine calculated the un-revised ROM 01 and returns the adjusted checksum of $67E9 which is what is in $FF/FFF6.FFF7

I am at a real loss now. Instead of changing the checksum bytes at FF/FFF6.FFF7 to match the ROM, I added a couple of bytes so the checksum is still $67E9 for a ROM 01 machine. But GSport and Sweet 16 are still reporting a damaged ROM.

Too bad. I would have liked to have uploaded this ROM image somewhere.

[retrogear]

My routine calculated the un-revised ROM 01 and returns the adjusted checksum of $67E9 which is what is in $FF/FFF6.FFF7 I am at a real loss now. Instead of changing the checksum bytes at FF/FFF6.FFF7 to match the ROM, I added a couple of bytes so the checksum is still $67E9 for a ROM 01 machine. But GSport and Sweet 16 are still reporting a damaged ROM. Too bad. I would have liked to have uploaded this ROM image somewhere.

I'll see if I can confuse you more. The actual checksum of all the rom bytes is supposed to equal $1234. The bytes at $FFF6.FFF7 are not the checksum, they are a 'tweak' value to get the checksum to equal $1234. If you modify rom, you need to do a 'checksum' without FFF6.FFF7, then use algebra:
tweak = $1234 - checksum. Then place the tweak value in FFF6.FFF7

There was discussion on this 4/24/13 on csa2:
creating a new apple iigs rom 03 checksum

Larry

[g***@sasktel.net]

Post by retrogear

My routine calculated the un-revised ROM 01 and returns the adjusted checksum of $67E9 which is what is in $FF/FFF6.FFF7 I am at a real loss now. Instead of changing the checksum bytes at FF/FFF6.FFF7 to match the ROM, I added a couple of bytes so the checksum is still $67E9 for a ROM 01 machine. But GSport and Sweet 16 are still reporting a damaged ROM. Too bad. I would have liked to have uploaded this ROM image somewhere.

tweak = $1234 - checksum. Then place the tweak value in FFF6.FFF7
creating a new apple iigs rom 03 checksum
Larry

No. Not confused. If you follow the listing in the 2nd post, it does exactly that. It adds FFF6.FFF7 in to the initial sum, but then gets subtracted from the final result, which is the same as not getting added in at all. Then that result is subtracted from $1234.

I am starting to make some headway now. I started over from the beginning and only changed a few bytes at a time. This seems to work ok with the emulators I am testing with. If a few changed bytes can work, then there must be something that is throwing it all off. I will keep changing one routine at a time until I find the culprit that is throwing everything out of wack and report my findings.

[retrogear]

What I had to do was re-compile gsport to not put in the rom patches and then
enable Text Page 2 Shadow, then I got System Good for ROM 00 and ROM 01 with a fudged checksum.

Larry

[Michael J. Mahon]

Post by g***@sasktel.net
I borrowed the ROM 03 checksum routine and revised it a bit for ROM 01.
This is what I came up with.
0300: 18 CLC
0301: FB XCE
0302: C2 30 REP #30
0304: A9 00 00 LDA #0000
0307: AA TAX
0308: 18 CLC
0309: 7F 00 00 FE ADC FE0000,X
030D: 08 PHP
030E: E0 F6 FF CPX #FFF6
0311: F0 07 BEQ 031A {+07}
0313: 28 PLP
0314: 7F 00 00 FF ADC FF0000,X
0318: 2C EA 28 BIT 28EA ; After the 2C is a NOP and a PLP
031B: E8 INX
031C: E8 INX
031D: D0 EA BNE 0309 {-16}
031F: 85 06 STA 06
0321: 38 SEC
0322: A9 34 12 LDA #1234
0325: E5 06 SBC 06
0327: 85 08 STA 08
0329: 38 SEC
032A: FB XCE
032B: 20 8E FD JSR FD8E
032E: A5 08 LDA 08
0330: 20 DA FD JSR FDDA
0333: A9 A0 LDA #$A0
0335: 20 ED FD JSR $FDED
0338: A5 09 LDA $09
033A: 20 DA FD JSR $FDDA
033D: 20 8E FD JSR $FD8E
0340: 4C 69 FF JMP $FF69
Two problems.
First, this routine is out by 2 when run on a non-revised ROM image. The
bytes at $FF/FFF6.FFF7 are E9 and 67 consecutively. This routine comes
up with EB and 67. Ok, no problem. I will just subtract 2 from the revised ROM image.
Second problem. How to do a checksum on a 256 kb file running under Prodos 8?
GSport to the rescue. It allowed me to load the ROM file that was
revised even though it has a bad checksum. Running the checksum program
on the revised ROM image gave me bytes of D3 and 6B.
So I subtracted 2 from the D3 to give me D1 and 6B. Plugged those into
the revised ROM image. All should have been well, right?
Sadly, no. I tried both D1 6B and D3 6B in the revised image and nada.
Going into the ROM verifies that the bytes at FF/FFF6.FFF7 have indeed
been changed to these values.
Any suggestions, links or otherwise to steer me in a different direction.
The checksum links out there are all for ROM 03.
Rob

Try some more values nearby. And see what the actual checksum is to guide
your iterations.