GBA Emulator Development

[old_macdonald]

sup evrybody!

i just thought most gba romz are only 3-5meg in size.
as this is how big the ones i download are...

and

rattboi, i will try and do a gameboy emu first as i've never done a emulator for anything before.
So if anyone knows where some emu writing stuff eg. help/tutorials are could you plz post a link.

i still haven't got my gp32 coz ive only got $30 AUD :angry:

i am definitely getting one though!!
i first found them on gbax.com while searching for gba sp and flash advanced linker cards :lol:

most of the reason i wanted one was because i saw somewhere that it could play gba gamez :blink:
when i found out it couldn't i was dissapointed then thought what the heck ill just make it myself

thanx for any help anyone can give me my email is: shiel_7@hotmail.com

thanx!

 

[unlucky]

all i can say is 'POKEMON' (ruby) hope this can b done i want 2 play pokemon ruby on the same system

 

[Swiss_Cheeseman]

my mistake, there are a reasonable amount of 4mb roms. However, anything over 6mb will be impossible to emulate, at least using traditional emulation techniques. I doubt a programmer for the GP32 will spend the time finding a brand new way to emulate roms.

 

[ctirad]

my mistake, there are a reasonable amount of 4mb roms. However, anything over 6mb will be impossible to emulate, at least using traditional emulation techniques. I doubt a programmer for the GP32 will spend the time finding a brand new way to emulate roms.

The basic question is, how does the GBA handle data in the roms. One possibility is that CPU/GPU/SPU can access the rom directly and read data permanently from there durning gameplay. Other possibility is that GBA reads (and perhaps also unpacks) some data from the rom before each screen/menu/level and then it runs from the RAM only. Then it´s OK, because we can leave the whole ROM in SMC.

 

[Axeman]

NOTE: SMC's, flash cards, and other game cartridges aren't actually ROMs, they're EPROMs. Meaning ERASABLE PROGRAMMABLE READ ONLY MEMORY

Actualy, they're not EPROMS, they're EEPROMS (Electrically erasable programmable read-only memory). Old style EPROMS could only be written and the erased (often by UV light through a window on the chip), they couldn't be added to once written.

Flash memory obviously allows this.

For a full explanation - take a look at http://computer.howstuffworks.com/rom5.htm.

Cheers

 

[Rigor Mortis]

This is an impossible project, at least impossible to get any practical use from. Most GBA roms are 8mb +, and the gp32 only has 8mb ram, which leaves no room for the emulator, or emulated GBA ram.

I'm afraid you're wrong! most GBA games are 8 Megabits and the GP32 has 8 MegaBytes. if my calculations are correct you can fit 8 GBA games at that size into the GP32 physical memory.

Most GBA games that I've found ARE in fact 8 megabytes in size. Just download Tekken Advance, or Sonic Advance, or Kirby, or Castlevania: Harmony of Dissonance - all of them are 8 MB. The only 4 MB ROM I have is Super Mario advance, and the GP32 can already play that with the SNES or NES emulator (Mario All-stars or Mario 2, respectively). What other 4 MB ROMS are there?

However, Visual Boy Advance has the ability to play ROMS that are compressed in .ZIP format. If the GP32 could compress the info as well, and only load a portion of the game at a time as was previously suggested, the problem might be solved.

 

[Arutha]

Probably at least a 1/4 and maybe up to half of the GBA roms are 4 megs... but the best games are usually going to be larger, so most of those downloaded regularly are going to be 8 megs. Either way, a GBA emu that only supports 4 megs limits the number of roms a LOT.

I have NO idea if splitting the roms will or will not work, but zipping them will NOT work. Yes, it reduces the size of the GBA rom, but consider two things: 1) how long does it take to unzip things... the reason for having the entire ROM in memory is so that the data can be accessed very quickly. Unzipping that data, with the extra processor time and speed hit to do so means you may as well access it from the SMC and 2) When you need the data, where is it going to be unzipped to? If the 6 meg of ram left free after running the emu program itself is full with 5-6 megs zipped, where are you unzipping the data to?

What emulators that use a zipped rom do is unzip it as it is loaded into memory, saving space on the HD (or SMC in GP32's case). I would guess that should someone create a GBA emu that loads portions of a rom at a time they will probably not enable zip compatability as that would create additional load times whenever a level/intro/game section is loaded while the rom is unzipped again.

 

[Rigor Mortis]

Good point. I didn't think about the unzipping process.

 

[mafen]

Just remember the main hindering factor. If the whole rom (meaning the game) cannot be loaded into memory, then every time a data page is required by the emulator, it takes time to page fault and retrieve the data page from disk into memory. So if data was needed which wasn't in memory already, it would slow the game down incredibly. One could optimise code all he wants, but this problem would still hinder gameplay. Unless someone started from scratch maybe, they could come up with a clever way to handle this problem.

 

[Rigor Mortis]

(Hmm.... I know terribly little about emulation programming, so there's a high possibility this is impossible. ) What if someone were to come up with a program that did not emulate GBA games, but instead automatically ported them to the GP32? I've seen ROM disassemblers, is there any way a ROM be disassembled, and then reassembled with to run natively on a GP32?

 

[mafen]

I think that might be possible actually. The downside is that a port would have to be made for each game. But I say forget all those crap games (such as britney beat or whatever it's called) and bring on golden sun The project would still be difficult though. Gotta find someone who has spare time.

 

[Rigor Mortis]

Well, if it was a simple one-step program that you could run on your own PC to process any ROM you wanted, it would, quite simply. rock. Better yet, it probably wouldn't require assembly programming for the GP32. (Hey, Old_macdonald, notice that!!! Perhaps there's a way to do what you suggested without assembly!!!)

 

[old_macdonald]

that might be a good idea Rigor Mortis! B)
I would be willing to try as im in grade 10 and have a s@#tload of free time. but i don't quite understand how it would work
is it like a program that diassembles the rom and then reassembles it to run on the gp32.
How would this work? i understand disassembling the romz but how would you get it to run on a gp32?
could someone plz explain it to me better?

also do all you guys live on the other side of the world from me because the only time i can find most new replys and topics is overnight!

is there many/any other aussies?

 

[Rigor Mortis]

Well, I don't know how to code this, I'm not a good enough programmer - which means I'm unfortunately just an idea man, but I think there would be 3 steps involved: The ROM is disassembled into GBA code, the GBA code is then converted to GP32 code, and then the converted code is compiled into a GP32 executable. What the world needs is a program that does these 3 steps automatically.

Emulators already do this conversion, but they do it in real-time while the program runs. This program would do the conversion ahead of time.

(BTW, I live in western Canada...)

 

[abbibi]

What does he mean by conversion? Well, all the sprites, images, animations & sounds would have to be converted from GBA formating to GP32 formats. Then the program's architecture would have to be converted (probably to c++) and then recompiled for the GP32. But there is a problem with this: we have to figure you how to interpret the compiled program. Unless you can get your hands on the source of a game, or someone else has managed to do this for the GBA, this will be a long an arduous task.

You could, on the other hand, take a VERY good GBA emulator, and actually "record" its conversion of a game when it opens it. Then you take the "recording" (which would probably be in C++), and convert its commands to GP32 ones. That make sense to anyone?


Earlier, Axeman corrected me about the whole EPROM, EEPROM mistake. I learned everything I know about videogaming from my Atari 800, the love of my life. :wub: Thank you Axeman, fro making me feel old and decrepid. :lol:

 

[ralp99]

ok this topic is officially giving me a headache.
emulation of GBA on GP32 is a good thing. Possible or not, or somewhat possible.. whatever. I don't care. If it could be done then cool, go for it.
Disassembling GBA roms, one by one, then reassembling them one by one to run on GP32?? What the hell is that all about? Insane amounts of work for the sake of it? For crying out loud, if you want GBA games then just fork over a little cash for a GBA already! Hell, trade in your GP32 for funds if you want it that badly..!

I love this system but why try to go through crazy roundabout timewasting methods to get it to be something it's not? GP32 is great because it emulates OLDER systems. MSX, Vectrex, Atari ST, 2600, Lynx, etc. Things that are hard to come by in person and just "feel" better playing on a handheld than thru your PC (in my opinion). Emulating GBA, if it's possible, would be novel but not necessary in my eyes as the system is obviously gonna suffer for power to do it properly and, it's a system you can go out and buy RIGHT NOW, relatively inexpensively, anyway...! Esp. if you want to play it's full range of titles.

just my 2 cents.

 

[old_macdonald]

o.k.....
i dont know how i would turn romz into gba code??
and then convert them into gp32 code? :blink: :blink: :blink:
how long would a program like this take to write??

how would i record a very good emulator while it was decoding romz?
and then use it somehow?
or turn it into c++??????
What the..?

 

[Rigor Mortis]

You could, on the other hand, take a VERY good GBA emulator, and actually "record" its conversion of a game when it opens it. Then you take the "recording" (which would probably be in C++), and convert its commands to GP32 ones. That make sense to anyone?

That makes perfect sense to me. It's sort of what I was thinking of - a program that did the emulation beforehand so that it didn't have to be done in real time. Is it actually feasible to do that?



(hey ralp99, I wasn't talking about disassembling and reassembling roms by hand, I was saying that if writing an emulator is not practical for a GP32, perhaps writing a convertor would be.)

 

[mafen]

Although it would be nice to have a gba emulator, I'd recommend skipping this project old macdonald. It's way out of your league. Try following footsteps of the dude porting his own version of Pang! Or try emulating gb or gbc. Much more possible and doable than gba and many people will thank you for it. Asking people on the method to code the emulator for the gba is not the way to go. If people already knew, the emulator would have been finished by now. For now, stick with stuff you know how to do / understand how to do.

 

[old_macdonald]

ok mafen i will not make a gba emulator.......
i will instead make a gb emu or a gbc or some homebrew gamez..

so everybody there is not going to be a gba emu for a while until i feel i can code good enough.
im sorry