Closed condret closed 10 years ago
What about placing all banks linear in memory and add hints to the instructions referencing memory from a specific rombank. I guess you need some previous code analysis to know which rombank is selected. But I'm not sure to understand how that works in real, do you have an example with code? I guess that's similar to how memory segmentation works on x86-16.
I found some notes about rombank switching here:
http://imrannazar.com/GameBoy-Emulation-in-JavaScript:-Memory-Banking
/ (fcn) fcn.0000019a 20 | 0x0000019a f0b8 ld a, [0xffb8] | 0x0000019c f5 push af | 0x0000019d 3e03 ld a, 0x03 | 0x0000019f e0b8 ld [0xffb8], a | 0x000001a1 ea0020 ld [0x2000], a | 0x000001a4 cd0040 call 0x4000 ; (fcn.00004000) | fcn.00004000(0x0) ; section_end.rombank0 | 0x000001a7 f1 pop af | 0x000001a8 e0b8 ld [0xffb8], a | 0x000001aa ea0020 ld [0x2000], a | 0x000001ad c9 ret
this is an extract from pokemon red (so much bugs in it :D ) . this rom has a mbc3. the bankswitch is perfomed at 0x1a1 to bank 3. the real address, which is called at 0x1a4 is 0x14000. between bank 1 and 2 there is some hw-io-foo.
http://gbdev.gg8.se/wiki/articles/Memory_Bank_Controllers explains it quite detailed.
so, you suggest to map bank 2 at 0x14000, bank 3 at 0x24000 ... (pc-register should fit, i want to use vbam, an emulator with gdb-backend (r2 would be the first tool, supporting this for normal gb-roms))
ld hl, 0x4003 ld 0x2000, hl call hl
would call 0x14003
even call from bank 3 to bank 0, where a bankswitch to bank 9 is performed and then return to bank 9 is possible,
the gameboy cannot switch a bank, which is in use
https://wk3.org/uploads/images/scaled_full_79626a6a348dd52bd856.png <=== inner-bank jumps and calls are done
This jr nz looks wrong
On 13 Dec 2013, at 02:53, condret notifications@github.com wrote:
https://wk3.org/uploads/images/scaled_full_79626a6a348dd52bd856.png <=== inner-bank jumps and calls are done
— Reply to this email directly or view it on GitHub.
thanks a lot, you're right. Seems like i have to add ilen to op->jump
fixed
Can we close this bug?
hm, what should i do with rambank-switches? rambanks are part of the internal gb-hardware, therefor not a part of the rom-file. (sure, this can be closed, we can still discuss on it)
I also need bank support for disassembling c64 snapshots. Was "bank support" added ? or is there any work around ?
Basically, I have 2 blocks of code, both of them must be mapped at the same address, but only one can be active.
Ask @condret for this. This is similar to gameboy requirements. And i think this is done by changing priorities in the sections
On 24 Nov 2015, at 18:52, Ricardo Quesada notifications@github.com wrote:
I also need bank support for disassembling c64 snapshots. Was "bank support" added ? or is there any work around ?
Basically, I have 2 blocks of code, both of them must be mapped at the same address, but only one can be active.
— Reply to this email directly or view it on GitHub.
It is done by changing priorities in sections? Can someone please explain this? And how this can be done? there is a tutorial somewhere? I think rombank switching is a so specific thing that it should be implemented independently for each architecture. I had to build my own disassembler because of this. Maybe having a mechanism for switching the rombanks like the processor does? The software also will have specific inter-rombank calls which will be different for every software... so...
radare could offer a rombank switch, like a command to change rombank, maybe if the processor can understand everything, the disassembler also can understand it, most banks also will refer to functions in the bank itself, so, rombank switching should maintain everything working without the section add/priority mess
How can i perform bankswitches in anal_gb? Each bank is sized to 0x4000. rombank0 is fixed. Depending on the MBC, defined in the gb-header, several write operations to ro-memory cause a bankswitch at (in most cases) 0x4000. I'm fearing to confuse the reflines, if I just redefine the rva of a rombank-section.
How could I handle rambank-switches?
This all might be neccessary for tracing data