search

TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.18k stars 382 forks source link

mGBA system bus: I/O registers, VRAM, OAM, GamePak SRAM cannot be written manually through system bus #3537

Open getCursorsExe opened 1 year ago

getCursorsExe commented 1 year ago

At http://problemkaputt.de/gbatek-gba-memory-map.htm these mentioned memory locations are suppossed to be read/write, but in mGBA you cannot poke them manually, just as if these memory locations were completely read-only.

YoshiRulz commented 1 year ago

See also #3524.

I'm guessing this is unintentional; the system bus is implemented separately from the other domains.

CasualPokePlayer commented 1 year ago

It's an "issue" upstream. IO/PALRAM/VRAM/OAM are unimplemented https://github.com/mgba-emu/mgba/blob/dbffb46c4e7d2e7a2cbed7c3488cece4c2176d4c/src/gba/memory.c#L1362-L1373 SRAM is partially implemented (only works when it's actually SRAM and not Flash/EEPROM/etc) https://github.com/mgba-emu/mgba/blob/dbffb46c4e7d2e7a2cbed7c3488cece4c2176d4c/src/gba/memory.c#L1388-L1396

getCursorsExe commented 1 year ago

In VBA-Next, we could write to IO/PALRAM/VRAM/OAM as intended.

getCursorsExe commented 1 year ago

This would mean that debugging functions in mGBA core aren't even finished at all, but VBA-Next, it was.

nattthebear commented 1 year ago

Since GBAPatch16 and GBAPatch32 do implement those things, we could fix it in the memory domain by adding separate writeshort and writelong implementations. This would probably be good enough, as in real usage you'd have little reason to write only 8 bits at a time to most of these locations.

endrift commented 1 month ago

Fixed in upstream bb8a6e05f9fb440efdf2121f08448814d6a7ed1f. No one ever told me this was a problem so I never knew.