|
|
|
|
Joined: Mar 2007
Posts: 298
Senior Member
|
Senior Member
Joined: Mar 2007
Posts: 298 |
Here's my updated list of bugs (BOBZ compilation 11/04/2010):
Dead Dance (J): graphic glitches when scrolling the fighter selection menu through all the available fighters forward/backward.
Super Kick Boxing (J): Graphic glitches are back (regression).
Rushing Beat (J): The screen 'blinks' in black sometimes during gameplay.
|
|
|
|
|
Joined: Aug 2009
Posts: 1,251 Likes: 171
Very Senior Member
|
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,251 Likes: 171 |
Super Tetris 2 & Bombliss Genteiban (J) is a real case limit open bus behaviour inside the IRQ routine:
00816D: INC $0320
008170: LDA $1fff ;word access read memories 0x1fff and 0x2000, 0x2000 is open bus and should return 0x00 instead of current 0x1f
008173: BEQ 008187 ($12) ;must jump there
Wizardry Gaiden IV - Taima no Kodou:
008023: XCE
008024: SEP #$20
008026: REP #$10
008028: LDX #$1fff
00802B: TXS
00802C: REP #$20
00802E: LDA $7e1b0d
008032: CMP #$6421 ;reads 0x7e1b0d without setting it and expects to be equal to 0x6421 otherwise it dies
008035: BNE 008049 ($12)
Guess that this is a very clear case of SRAM flaw?
Last edited by Kale; 04/11/10 03:56 PM. Reason: Wizardry Gaiden IV - Taima no Kodou info
|
|
|
|
|
Joined: Sep 2009
Posts: 15
Member
|
|
Member
Joined: Sep 2009
Posts: 15 |
It's just checking if you reset the system.
|
|
|
|
|
Joined: Aug 2009
Posts: 1,251 Likes: 171
Very Senior Member
|
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,251 Likes: 171 |
Yeah, but work RAM is all 0x55 filled, and it shouldn't.
|
|
|
|
|
Joined: Sep 2009
Posts: 15
Member
|
|
Member
Joined: Sep 2009
Posts: 15 |
WRAM should be randomized at start but that isn't the problem with this game. It's a mapping issue. Banks $F0-$FF are overwritten with SRAM but Tokimeki Memorial and Wizardry Gaiden are pretty big and have ROM mapped there.
|
|
|
|
|
Joined: Dec 2005
Posts: 443
Senior Member
|
|
Senior Member
Joined: Dec 2005
Posts: 443 |
Ah yes. A "bug" due to the crappy binary blob ROM format that contains no data whatsoever on the actual PCB layout...
|
|
|
|
|
Joined: Aug 2009
Posts: 1,251 Likes: 171
Very Senior Member
|
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,251 Likes: 171 |
Just a note about the Fushigi no Dungeon 2 bug: That's a gameplay bug, not just a graphics bug. The score and floor numbers shown in the screenshot are nonsensical, and the Japanese text underneath (which sums up how the game ended) reads "Defeated by Shiren while carrying the Bizarre Box" which is similarly nonsense (Shiren is the default name of the player character, not an enemy)
The Fushigi no Dungeon games are notable for automatically saving to battery RAM after every action the player performs, so I'm inclined to suspect a SRAM mapping problem, although a CPU bug is also possible. Probably the former, it does this: 818103 lda #$53
818105 sta $b36000
818109 lda #$54
81810b sta $b36001
MESS driver masking seems to apply at every 0x10000 (i.e. it writes at 0xb06000-0xb16000-0xb26000 and 0xb36000) ... BSNES only writes at 0xb36000 (plus it has a completely different mapped memory in there). Cart mode is 21 iirc. Ideas?
|
|
|
|
|
Joined: Jun 2008
Posts: 205
Senior Member
|
|
Senior Member
Joined: Jun 2008
Posts: 205 |
Ah yes. A "bug" due to the crappy binary blob ROM format that contains no data whatsoever on the actual PCB layout... I made an XML format for that, but we still need to fill that out with the 'header detected' mapping data. If we can verify the PCB ID on each games' board, we can get 100% perfect hardware mapping.
|
|
|
|
|
Joined: Jan 2006
Posts: 3,691
Very Senior Member
|
|
Very Senior Member
Joined: Jan 2006
Posts: 3,691 |
WRAM should be randomized at start but that isn't the problem with this game. It's a mapping issue. Banks $F0-$FF are overwritten with SRAM but Tokimeki Memorial and Wizardry Gaiden are pretty big and have ROM mapped there. so we finally have found an example where lines 135-136 of snescart.c apply: /* There could be some larger image needing banks 0x70 to 0x7f at address 0x8000 for ROM
* mirroring. These should be treated separately or data would be overwritten by SRAM */
great! I was waiting for that since forever!!!!
|
|
|
|
|
Joined: Dec 2005
Posts: 443
Senior Member
|
|
Senior Member
Joined: Dec 2005
Posts: 443 |
great! I was waiting for that since forever!!!! If I'd have known you needed to know, I would've been able to tell you that there were games that need ROM in $f0:8000 since forever  There's a few different sets of boards that behave in a specific manner that results in the impossibility of universal mappings. Whatever route you go, moving away from the binary blob as the sole source of information used to map a game is "very very good"...
|
|
|
|
Forums9
Topics9,320
Posts121,944
Members5,074
| |
Most Online1,283
Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|
|
|
