Check if the game file has a good iNES header.austere wrote:This had me stumped for ages, in my emulator, bomberman hangs on the opening title. I've coded up loopy's register model and Super Mario Bros works fine -- hell, I've got most MMC3 games working fine and glitch free. But Bomberman still doesn't run. Any clue what it could be? Does it check the sprite overflow flag before displaying the menu select sprite (not displayed before it hangs)?
a) The DiskDude string found at the 8th byte.
b) The mapper number is incorrect (should be zero).
c) If a) is true, then b) is really true.
d) Check the CRC32 to identify a good/bad dump.
I suspected this, I ran blargg's sprite0 tests. I passes most non-timing tests except 07.screen_bottom.nes where it fails with status #3.WedNESday wrote:Bomberman uses sprite 0 to get the game running. But I don't know if that would cause the title screen to freeze like SMB.
3) Can hit when Y < 239
Yup, ran the NES (US) version (DB9DCF89) and it showed identical behaviour. I disassembled Japanese bomberman ROM to see where it access the sprite hit flag:
Code: Select all
reset: sei cld ldx #$ff txs lbl_c005: lda $2002 ;PPU Status Register bpl lbl_c005 ;Wait for vblank lbl_c00a: lda $2002 ;PPU Status Register bpl lbl_c00a ;Wait for vblank jmp main_game ... (end of nmi routine) lbl_c16a: lda $2002 ;PPU Status Register and #$40 ;Check sprite 0 hit bne lbl_c16a ;Wait until not hit lbl_c171: lda $2002 ;PPU Status Register and #$40 ;Check sprite 0 hit beq lbl_c171 ;Wait until hit lda $e sta $2005 ;VRAM Address Register #1 lda $f sta $2005 ;VRAM Address Register #1 lbl_c182: lda #$5 eor $db sta $db pla tay pla tax pla rti ... lbl_c11e: lda $2002 ;PPU Status Register (clear vblank) jsr lbl_c28e ... lbl_c28e: lda $d sta $2001 ;PPU Control Register #2 lda #$0 ldx #$0 jsr lbl_c18e lda #$0 sta $2005 ;VRAM Address Register #1 sta $2005 ;VRAM Address Register #1 lda $c sta $2000 ;PPU Control Register #1 rts main_routine -> lbl_c1ea ... -> lbl_c283 lbl_c283: lda $2002 ;PPU Status Register bmi $c283 lbl_c288: lda $2002 ;PPU Status Register bpl lbl_c288 rts
You mean you don't calculate the correct number of cycles an opcode might need in the correct manner?austere wrote:The NMI timing inaccuracy might stem from the fact that I use the best case cycle count for all opcodes in my 6502 and that seems to work for [almost?] all games I've tried so far. Are your cores fairly accurate in cycle count?
No offense, but it annoys me so much that people come to this forum with problems like this before they have even implemented even the most basic of CPU accuracy and then ask us why game A or B doesn't work properly.
The thing is that you have reached as experienced developer emu author and/or .rom author.WedNESday wrote:No offense, but it annoys me so much that people come to this forum with problems like this before they have even implemented even the most basic of CPU accuracy and then ask us why game A or B doesn't work properly.
I remember when you were a beginner and made question such as "is there not a technical doc othat NES 2C02 reference??" Making note that it was too difficult to you. (i don't wan't to search the link for your old post, but you remember it don't you?)
And no offense to you, but everybody was a begginer at first and needed help (like you) to work around a problem.
So, if you think the question or issue somebody expose here is too "noob" remember your old days when you had the Signature "Wednesday, the best emulator in the net.... well according to the author" and don't reply the noob question if you think so.
I did assume so, I never really expected many games to run given that I didn't account for page crossing and branch adjustment cycles. I've made accommodations for adjustment in the code but haven't bothered changing the cycle count until I had everything else working. I was actually surprised that most things I've thrown at it worked fairly well, even Shatterhand which has faux parallax scrolling.tepples wrote:Emulators that can run a wide variety of commercial NES games need to have accurate cycle counts for all instructions. Games' raster effect loops can and do depend on extra cycles inserted due to page crossing.
No offense taken but "most basic of CPU accuracy" is kind of vague, like I said, I assumed best case (i.e didn't account for zero page crossing or branch miss). It's not like I set the cycle count to 4 for all instructions, I used the correct base values. Anyway, I'm sure someone else who has this problem with bomberman in the future will find this post and not ask the question again thanks to Anes and Zepper's hints towards correct behaviour. I mean that's the point of a forum after all, WedNESday.WedNESday wrote:No offense, but it annoys me so much that people come to this forum with problems like this before they have even implemented even the most basic of CPU accuracy and then ask us why game A or B doesn't work properly.