Re: Any raw data specs for the Apple IIgs BRAM?
- From: "Jeff Blakeney" <jeff.blakeney@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 07 Apr 2007 01:10:43 GMT
To: dempson
On Thu, 5 Apr 2007 17:13:31 +1200, dempson wrote:
I'm scratching my head. My translation of the original assembly code
looks right, and your AppleScript looks right, and I've tested your
original set of example data with the original assembly code and with
the AppleScript, and they don't match.
I've gone back to looking at the original 65816 code and tried to
convert it into PowerBASIC for Windows. I haven't been having much luck
though. I thought I'd post some thoughts here to see if it might help
nudge someone else's thoughts a bit.
Here is the 65816 source:
CalcChecksum ldx #$FA ; init X (notice the bug here?)
rep #$20 ; 16 bit accumulator, 8 bit index
clc
lda #$0000 ; init checksum
Loop rol a
adc BRAMbuff, x
dex
cpx #$FF
bne Loop
rep #$30 ; 16 bit accumulator and index
tax ; this is the actual checksum
eor #$AAAA ; checksum modified for extra checking?
rts
Here is the PowerBASIC code I came up with:
SUB CalculateBRAMChecksum(bBRAM() AS BYTE)
LOCAL A AS WORD
LOCAL c AS BYTE
LOCAL X AS BYTE
LOCAL wX AS WORD
LOCAL Temp AS BYTE
X = &HFA
c = 0
A = 0
DO
' the ROTATE LEFT command in PowerBASIC simply moves the MSB to
' the LSB so to do a ROL like the 65816 does, we need to get the
' value of the MSB, shift the data left by one bit, add the
' current value of the carry flag and then change the carry flag
' to the value of the MSB that we grabbed earlier
Temp = BIT(A, 15)
SHIFT LEFT A, 1
A = A + c
c = Temp
' don't need to check to see if we need to set the carry flag
' after this addition as it will be cleared by the CPX at the
' end of the loop
A = A + bBRAM(X) + c
DECR X
' CPX can affect the carry flag so check it
IF X < &HFF THEN
' in this case, this will always be used except for the last
' iteration of the loop as that is when X will equal $FF
c = 0
ELSE
' only taken at end of loop so doesn't affect checksum
c = 1
END IF
LOOP UNTIL X = &HFF
wX = A
A = A XOR &HAAAA
bBRAM(252) = LO(BYTE, wX)
bBRAM(253) = HI(BYTE, wX)
bBRAM(254) = LO(BYTE, A)
bBRAM(255) = HI(BYTE, A)
END SUB
My "config.kegs" file has the last four bytes set to 13 24 B9 8E but
when I run my program on that data I get 07 F4 AD 5E. My program
currently reads in the BRAM data from the "config.kegs" file and I've
manually checked that all 256 bytes match. I think I've taken all the
places where the carry flag could mess things up into account but I'm
not sure. Perhaps I've misinterpreted the way ROL works.
By the way, the bug in the 65816 code is that it initializes X to $FA so
the byte at $FB is never included in the checksum and the actual
checksum is stored in byte $FC-$FF. You can change the value of $FB all
you want and the system will never notice. :-)
--- Synchronet 3.13a-Win32 NewsLink 1.83
A2Central.com - Your total source for Apple II computing.
.
- Follow-Ups:
- Re: Any raw data specs for the Apple IIgs BRAM?
- From: Laroquod
- Re: Any raw data specs for the Apple IIgs BRAM?
- From: Michael J. Mahon
- Re: Any raw data specs for the Apple IIgs BRAM?
- From: David Wilson
- Re: Any raw data specs for the Apple IIgs BRAM?
- References:
- Re: Any raw data specs for the Apple IIgs BRAM?
- From: David Empson
- Re: Any raw data specs for the Apple IIgs BRAM?
- Prev by Date: Re: DHGR display?
- Next by Date: Re: Any raw data specs for the Apple IIgs BRAM?
- Previous by thread: Re: Any raw data specs for the Apple IIgs BRAM?
- Next by thread: Re: Any raw data specs for the Apple IIgs BRAM?
- Index(es):
Relevant Pages
|
Loading