GBA Open Bus

3324 Views 2 Replies 2 Participants Last post by nocash, Apr 20, 2015

nocash

Discussion Starter · Apr 15, 2015

I am just updating the GBA Open Bus definition. The old info in gbatek's Unpredictable Things chapter was essentially saying:

Code:

  For ARM Code:   WORD = [$+8]
  For THUMB code: LSW = [$+4], MSW = [$+4]

But it turned out that some GBA games won't work with that open bus values (thanks to Ricardo for pointing me on it). There are a bunch of special cases for THUMB code in WRAM (and also in OAM and BIOS):

Code:

Reading from Unused Memory (00004000-01FFFFFF,10000000-FFFFFFFF)
Accessing unused memory at 00004000h-01FFFFFFh, and 10000000h-FFFFFFFFh (and
02000000h-03FFFFFFh when RAM is disabled via Port 4000800h) returns the
recently pre-fetched opcode. For ARM code this is simply:
  WORD = [$+8]
For THUMB code the result consists of two 16bit fragments and depends on the
address area and alignment where the opcode was stored.
For THUMB code in Main RAM, Palette Memory, VRAM, and Cartridge ROM this is:
  LSW = [$+4], MSW = [$+4]
For THUMB code in BIOS or OAM (and in 32K-WRAM on Original-NDS (in GBA mode)):
  LSW = [$+4], MSW = [$+6]   ;for opcodes at 4-byte aligned locations
  LSW = [$+2], MSW = [$+4]   ;for opcodes at non-4-byte aligned locations
For THUMB code in 32K-WRAM on GBA, GBA SP, GBA Micro, NDS-Lite (but not NDS):
  LSW = [$+4], MSW = OldHI   ;for opcodes at 4-byte aligned locations
  LSW = OldLO, MSW = [$+4]   ;for opcodes at non-4-byte aligned locations
Whereas OldLO/OldHI are usually:
  OldLO=[$+2], OldHI=[$+2]
Unless the previous opcode's prefetch was overwritten; that can happen if the
previous opcode was itself an LDR opcode, ie. if it was itself reading data:
  OldLO=LSW(data), OldHI=MSW(data)
  Theoretically, this might also change if a DMA transfer occurs.
Note: Additionally, as usually, the 32bit data value will be rotated if the
data address wasn't 4-byte aligned, and the upper bits of the 32bit value will
be masked in case of LDRB/LDRH reads.
Note: The opcode prefetch is caused by the prefetch pipeline in the CPU itself,
not by the external gamepak prefetch, ie. it works for code in ROM and RAM as
well.

The "previous-opcode" effect is nastiest because it couldn't be emulated without memorizing what the previous opcode was doing, which would cause some useless slowdown. I am hoping that there aren't any GBA games relying on that particular dirt effect.

Interestingly, the original NDS produces some different garbage than other consoles (whilst the NDS-Lite adopts the behaviour of the real GBA series). That makes me wonder... Are there any GBA titles that don't work on original NDS consoles?

If there aren't any known compatibility issues: The game that didn't work with the old no$gba open bus emulation was "MegaMan Battle Network 4 Blue moon" so theoretically, that game may have similar problems on original NDS (and nintendo may have fixed it by changing the open bus behaviour in later NDS-Lite models).

See less See more

Save

1 - 3 of 3 Posts

loldude

· #2 · Apr 18, 2015

Also should note there's a phantasy star collection game that relies on DMA having its own separate open bus instance. Specifically the phantasy star 1 sub-game relies on the last valid dma write copying the value over the another dma channel's illegal read for that interlaced scanline effect.

While we're on DMA weirdness, it turns out nintendo specified setting DMAs you want to force stop to immediate mode first before clearing the start bit is because the immediate mode trigger seems to occur only when the start bit was 0 at first, so that avoid the DMA lockup issue when stopping DMAs at the same time as it's requested to start.

Save

nocash

Discussion Starter · #3 · Apr 20, 2015

loldude said:
Also should note there's a phantasy star collection game that relies on DMA having its own separate open bus instance. Specifically the phantasy star 1 sub-game relies on the last valid dma write copying the value over the another dma channel's illegal read...

Thanks for the info! I am afraid there might be a bunch nasty "special" cases, too. Do you know more about it? Like what happens when combining 16bit DMA with 32bit DMA, or vice versa, reading from different memory regions like Main RAM, OAM, WRAM, etc, with this or that alignment. And especially, what happens if there was no preceeding valid DMA (during past some seconds)?

Save

1 - 3 of 3 Posts

This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.

Top Contributors this Month