tokumaru wrote:
tokumaru wrote:
I'd rather debug the ROM in an emulator to make sure that all mapper writes are happening to ROM locations that contain the same value that's being written... =)
Just in case you're not familiar with bus conflicts: mapper commands are often "masked" as writes to PRG-ROM, because since the PRG-ROM obviously can't be written to, the writes are routed to the mapper instead. However, the ROM isn't disabled (in some mappers it is, but not this one), so it thinks it's being read, so it still outputs what's stored at the specific address that was written to. If the value being written is different than the one stored in the ROM, there's a bus conflict: two different values trying to use the same address lines at the same time.
To avoid this issue, games had to make sure that mapper commands were sent to ROM locations that had the same value as the one being written, so it was common for them to have tables of consecutive values (i.e. $00, $01, $02, $03 and so on, until the largest value that could be written).
The original Herakles no Eikou was only 128KB, so it had 8 PRG-ROM banks, and a bankswitch table with values from $00 to $06 (the last bank, $07, doesn't need to be switched in because it's hardwired to $C000-$FFFF). When they expanded the ROM, they didn't update the table, so whenever the higher banks (which they probably have used only for graphics) are accessed, the bus conflicts cause invalid banks to be selected.
Maybe this should be brought to their attention. They need to either expand the bankswitch table or relocate it to a location where it can count up to $0E.
Thanks for bringing this to my attention. It may take a while, as I am busy with real life right now, but I will fix it if I can. Of course, it never came up in any of our testing on any emu or flash cart or we would have dealt with with at the time. I hate releasing more than one patch for a game...
I appreciate your explanation of the issue, but I don't completely understand it.
For me to modify this, I need to understand this completely.
Could you better explain why it
reads the ROM even though this is a
write command? Do all legitimate writes to RAM areas also do reads?
More importantly, what I don't understand for this game is why the address being written to is $8040 not c56c thru c572... why they didn't do what I see done in other games that do this: sta $c56c,y
I don't see how the processor knows to view anything at the table at c56c just because it comes directly after the code that accesses it.
I don't have the hardware to test it on, so I'd need to work with someone who does.
Code:
;--------------------
; UNROM_8000 = Y = Block_8000 = A
;--------------------
lbl_c565: sta $94 ;
tay ;
sta $8040 ; UNROM_8000 = Y = vbl_94 = A
rts ; Return lbl_c56b:
;--------------------
; Table UNROM_Bank_0_6: C56C thru C572
; 7 bytes
;--------------------
_c56c: .byte $ 0 ;
.byte $ 1 ;
.byte $ 2 ;
.byte $ 3 ;
C570: .byte $ 4 ;
.byte $ 5 ;
.byte $ 6 ;