#79990 - thegamefreak0134 - Mon Apr 17, 2006 11:54 pm
How difficult is it to develop a GBA emulator?
The reason I ask is, (and this is a complete side project with no priority, mind you) a friend of mine and I want to eventually develop a development environment for the GBA. We would like to have it be able to debug code "on-the-fly" with an emulator built in to the environment. That way, if you compile your code either in C++ or in ASM, you can go through the code line by line, in either language.
The emu would obviously have to be built in, as it would need to be able to sync with the debugger at all times.
Course, we're just curious at this point.
-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#79997 - keldon - Tue Apr 18, 2006 12:30 am
Doesn't VBA have some way of interfacing with debuggers?
#80014 - gauauu - Tue Apr 18, 2006 2:22 am
Yeah...I think it would be easier to have your ide talk to VBA than to write a new emulator. Writing emulators is HARD.
edit: then/than...whatever....
Last edited by gauauu on Tue Apr 18, 2006 6:15 am; edited 1 time in total
#80016 - sgeos - Tue Apr 18, 2006 2:29 am
A project I worked on launched VBA from the map editor using a custom ROM/filesystem combo. It was really neat. You could probably do something similar with your IDE.
-Brendan
#80021 - gladius - Tue Apr 18, 2006 3:10 am
Writing an emulator is a huge time sink if nothing else. If it's only a side project with "no priority" I doubt it will get done :). An emulator requires at least a few months of solid development time if you know the system pretty well.
But there are a few open source emulators out there that you can play with. VBA is great, but it's code is generally hard to understand and the pure win32 dialogs make extending the source for debugging a pain. On the other hand it has elf/gdb support which is very nice.
Or you could (and here comes some shameless promotion ;) extend my emulator, located at http://forwardcoding.com/projects/gbaemu.html. It's open source, written in C# and the code is pretty clean. The debugger and sprite viewer were incredibly easy to tack on.
#80050 - sgeos - Tue Apr 18, 2006 8:30 am
| gladius wrote: |
Writing an emulator is a huge time sink if nothing else.
... An emulator requires at least a few months of solid development time if you know the system pretty well. |
How many 20 hour weeks (part time job equivalent) does it take to get a basic emulator up and running?
-Brendan
#80052 - gauauu - Tue Apr 18, 2006 9:21 am
| sgeos wrote: |
How many 20 hour weeks (part time job equivalent) does it take to get a basic emulator up and running?
-Brendan |
The answer to that depends on:
How well do you know ARM assembly, the ins and outs of the GBA sound and graphics hardware, and and how good are you at reading nasty techincal documentation?
#80053 - gladius - Tue Apr 18, 2006 9:26 am
It really depends. For the GBA, if you get your cpu core architecture right the first time and have a good understanding of the graphics/memory system I'd say 6-8 weeks if you were able to put in the 20 hours a week. If you decide to mostly re-use someone else's cpu core it could be quite a bit faster. (Edit: 6-8 weeks to get things working decently. As with any other software project, the last 10% takes 90% of the time :).
This is also because the documentation is so damn good, and there are excellent examples with source out there (VBA and mappy are excellent resources, along with mine hopefully).
It's getting the tricky little details right that takes a ton of time. Fixing bugs in CPU cores is just a time intensive process, no way around it. Then if you want speed on top of accuracy, things take even longer.
#80054 - DekuTree64 - Tue Apr 18, 2006 9:49 am
For some reference times from a beginner at emulation, I started writing a GBA emu a while back for practice because I was thinking of doing a SNES emu. After 2 weeks I had working ARM and THUMB cores, a nice disassembly dialog, breakpoints, and very basic mode4 graphics. It was rather slow though :)
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#80074 - thegamefreak0134 - Tue Apr 18, 2006 5:15 pm
Hmm... Thats kinda what I was afraid of... Well, how hard would it be to get VBA to stop after a certain point in code, and then have my program figure out where all of the points were for every line? (since I know C++ does not by any means translate directly into asm)
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#80080 - keldon - Tue Apr 18, 2006 5:33 pm
I think the elf2 format can include the source in the executable - relating the c code to the corresponding asm line. I know this is what I had for debugging with turbo c++ on the pc and for the GB in nocash.
#80089 - thegamefreak0134 - Tue Apr 18, 2006 7:18 pm
So thats why it does an .elf file first. Cool.
Can you point me to some docs so I can get this to work happily?
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#80096 - keldon - Tue Apr 18, 2006 7:51 pm
http://www.wotsit.org/download.asp?f=elf11g
Martin [nocash] says its in the ELF file using the Dwarf2 format. I did look into it a bit when I saw the [need help from crazy programmer] request, but the documentation is really awkward to understand. I honestly just thought **** it I'm not getting paid enough.
Document is in postscript format, so you will need ghost viewer.
#80112 - sumiguchi - Tue Apr 18, 2006 9:08 pm
You can use GDB for debugging while running in Visual Boy Advance. It works very well and yes, you can step through code.
I don't know how to do this myself - but it is built in to the VisualHAM editor.
I think VisualHAM is open source on source forge now, but you can get that information off the original authors site: www.console-dev.de
Instead of writing an emulator or dev environment from scratch - why not see what visual HAM has to offer and improve it.
I know that VisualHAM is being used for HAM, non-HAM and even non GBA projects...