Gameboy Development Forum

calc84maniac · 2009-02-28 14:49:37

I've been thinking about attempting to make a Game Boy emulator on the TI-83+ line of calculators.

These calculators have a z80 CPU. I decided that a nice solution to run the code quickly is to translate the gameboy code directly to z80. For example:

Code:

add sp,2

becomes

Code:

ld ix,2
add ix,sp
ld sp,ix

However, this will change the size of the code, so I would have to disassemble the ROM and reassemble it with the new code. I figured I could put the extra code in the unused $e000-$fe00 region of RAM upon page swap (7.5 KB should be more than enough for any extra code).

The main problem is that there doesn't seem to be a disassembler which will accurately figure out what is code and what is data (which is a must).

Can anyone think of a solution? Thanks.

nitro2k01 · 2009-02-28 17:57:42

The code most certainly must be recompiled in some way or the other. Apart from what you're pointing out, that the instruction size will increase, the memory paging is different, you'll also need some glue code mainly for rendering graphics, but also for converting button input, emulating timer interrupts etc. You will probably also want to remove sound/music code and data to save space and CPU cycles. And I wonder how well games will look on the screen since it's lower res and only monochrome.
All in all I think you won't be able to make a fully automated process for converting ROMs into executables for the TI-83. It'll need alot of manual work for each game. I think you'll need to manually analyze the ROM and find which areas are data and which are code. I think your workflow must be something like this:
* Analyze and produce a list of areas
* Disassemble code and data areas based on this list
* Assemble again using an assembler which can convert instructions using macros (For example WLA)
* Add glue code as needed
Needless to say, this is a big project that will take a lot of work.

calc84maniac · 2009-02-28 18:10:56

Yeah, page 0 is going to be a problem. At one point I was thinking I could translate it from $0000 to $4000 and swap there, but then I remembered that page 0 code needs to be able to access data from other pages. I think that, if anything, this project should be a replacement to the built-in OS so I can use page 0 (and thereby the $0000-$3fff sector).

The hardware emulation code would likely be interrupt-based. I don't really have any worries about speed -- the calculator's CPU is over 3.5 times as fast as the Game Boy's, so I have 70% of the CPU time left to emulate the hardware.

Thus, the only problems are the space and disassembly issues. I wonder if there are some Game Boy games that people have already fully disassembled? That would be very useful.

Lai · 2009-03-02 17:23:05

If you don't know there is a similar project on the MSX called GEM (http://www.tni.nl/products/gem.html), which uses dynamic recompilation. The processor in Turbo-R is R800 which from what I read on Wikipedia, essentially is a z80 with a multiplication.

Good luck with the project anyway!

calc84maniac · 2009-03-02 19:15:07

Yes, I was actually considering the dynamic recompilation approach, as it would be able to run any ROM without needing to disassemble beforehand. This would be a large hit on the speed, though. It might be worth it just to get it running, even if not at full speed.

calc84maniac · 2009-04-05 18:19:04

Well, I've been working on this again, and I decided to make it an interpreter. I already have 200 of the opcodes covered, so it's coming along fairly well.

There are some things I wonder if I can assume when emulating commercial games, though:
1. Is it safe to assume that interrupts will always return using RETI?
2. I suppose that relative jumps won't jump to another page (this is kind of a no-brainer)
3. Can I ignore HALTs safely? This could boost the speed a bit.
4. Can I assume that the writes to ROM space (commands to the memory controller) will always be done using the LD (nnnn),A command?
Edit:
5. The bit commands for (HL) won't be used on ROM, I suppose?

Thanks!

Last edited by calc84maniac (2009-04-05 22:31:24)

nitro2k01 · 2009-04-06 17:00:54

1. In the end, interrupts will almost always return using a RETI, yes. But sometimes a game might enable interrupts with EI to allow other interrupts to be served.
You should also be aware of the common tactic to store a list of pointers to interrupt functions in RAM, (The list in RAM; the code is using some function to dynamically add or remove hooks to the interrupt.) and call each of them using jp HL.
2. Correct assumption, except POSSIBLY that a 32 kB game might treat the whole ROM area is a single continuous memory area, since it's not using banking anyway. I haven't analyzed a lot of 32 kB games though, so I wouldn't know for sure.
3. You can ignore them safely. It's a common tactic among performance critical emulators to treat HALT as a NOP. But also note that HALT usually exists in the main loop when waiting for an interrupt. If a game calls HALT it usually means that that game doesn't need to do anything for a while. You might be able to use that fact to your advantage.
4. Don't take that for granted. It's quite possible that, especially compiled C code, might use LD HL,$2000 then LD [HL],(Value or register). If so, the LD HL,$2000 will probably be situated right before the memory write.
5. You mean in actually using these commands with HL pointing to ROM? Not likely.

calc84maniac · 2009-04-07 16:43:36

Well, I have to say it's progressing well. Here's a screenshot of the current progress (tilemap rendering only):

Edit:
Now I have added sprite support!

Last edited by calc84maniac (2009-04-07 21:26:08)

calc84maniac · 2009-04-14 18:14:58

Well, now it can run Link's Awakening quite well...
Screenshot - (Best viewed in FireFox. Warning, 3.8MB filesize)

Next I'll probably need to modify the renderer so it can work with the special effects involving LY/LYC coincidence so it can run things like Super Mario Land.

Edit:
Now that I think about it, where's the best documentation on what exactly happens when values are changed, like the SCY and such?

Last edited by calc84maniac (2009-04-14 18:24:55)

Gameboy Development Forum

#1 2009-02-28 14:49:37

Accurate disassembler?

Code:

Code:

#2 2009-02-28 17:57:42

Re: Accurate disassembler?

#3 2009-02-28 18:10:56

Re: Accurate disassembler?

#4 2009-03-02 17:23:05

Re: Accurate disassembler?

#5 2009-03-02 19:15:07

Re: Accurate disassembler?

#6 2009-04-05 18:19:04

Re: Accurate disassembler?

#7 2009-04-06 17:00:54

Re: Accurate disassembler?

#8 2009-04-07 16:43:36

Re: Accurate disassembler?

#9 2009-04-14 18:14:58

Re: Accurate disassembler?

Board footer