Anyone know where to get the sourcecode for boycottadvance?
http://sdlemu.ngemu.com/basdl.php
http://sdlemu.ngemu.com/basdl.php
Vba Test Builds
- Thread starter pcklee123
- Start date
Smiths
Still Fresh
pcklee123 posted on Mar 9 2006 at 04:25 PM said:
In the readme:
Last edited by a moderator:
I've given up. Dont have the skills for this Its Domm's port in the 1st place and I was trying to see if it was faster by compiling with static libs & whether .gb roms can be made to work. (they do work)xnopasaranx posted on Mar 28 2006 at 04:55 PM said:
Last edited by a moderator:
Muncher666
Member
- Joined
- Dec 24, 2005
- Messages
- 339
As far as I understand it, the only way we'll see GBA emulation at a decent speed is for someone to 'reinterpret' the ARM codes so it actually uses the ARM processor like a GBA - not really emulation as such, but apparently it could work, and work well - that's how they got it working on the gp32, I understand, it's just a hell of a lot of effort and someone would have to be pretty determined to get it working. 
Allan.
Allan.
yeah I knew about this method. They also did it on that commercial gba emulator for the zodiac as far as I remember... well I figure that this requires too much work for anyone to do right now. Maybe we'll see it in a few month or so. Hmm... back to my DS. I really need to unbrick that fucker. I want to play kingdom hearts!
Squidge
Certified Guru
You mean those muppets behind Crimson Fire? They wrote a arm interpreter in C, and then rewrote it in assembler with many more bugs , but I don't think (and very much doubt) they ever had a version that ran ARM code natively.
Zodiacs and other PALMs only have one processor, and user apps don't have access to the MMU, so you would have to write a solution that broke up the GBA into pieces and ran that (kinda like a Dynarec), which is much more complicated than running the code natively and interrupting it when you want to emulate the rest of the system.
Also remember that the GBA is kinda like the SNES with regards to it's graphics - so even with a fully functioning native arm execution module, you still got all the different tiled graphics modes to worry about, which will take a significant amount of processing power in itself.
, but I don't think (and very much doubt) they ever had a version that ran ARM code natively. Zodiacs and other PALMs only have one processor, and user apps don't have access to the MMU, so you would have to write a solution that broke up the GBA into pieces and ran that (kinda like a Dynarec), which is much more complicated than running the code natively and interrupting it when you want to emulate the rest of the system.
Also remember that the GBA is kinda like the SNES with regards to it's graphics - so even with a fully functioning native arm execution module, you still got all the different tiled graphics modes to worry about, which will take a significant amount of processing power in itself.
Oh, ok. I just read that they ran ASM code natively somewhere back when I was still interested in the zodiac. So basically this whole "let's just run the arm code natively" thing won't actually happen. Is there any other possible approaches to develop a gba emulator that is more usable? Is it all about asm optimisation and the emulator will never reach a playable speed? Is all this talk about the compability of the processors irrelevant? I am really stuck here! Somebody enlighten me please... this has been talked over and over again and also in the WiKi but what are the hard facts?
The "let's just run the code natively" idea is just incomplete. The code has to be "adjusted" so it will run natively. Basically by adding timing code, and the MMU will have to be emulated in software (rather than using the built-in one). Then there's the rest of the hardware...
Squidge
Certified Guru
Native ARM ASM code on the Zodiac (and other palm devices) normally means the emulator is running in arm native code rather than Motorola 68000 code. That's all.
Fez
Still Fresh
I cant wait until GBA works at a decent speed, I you devs are still working on it now and then.
Fez
Still Fresh
The update shows good progress. Thanks for taking up the work again!!
I have found a number of games quite playable with no sound and having the gp2x overclocked to 260Mhz.
Zelda Minish Cap, Ninja 5-0 and mario advance (mario brothers 2) work well.
Bug Report:
I find there is a graphics glitch, which is a line of colored pixels above the playing area.
The config file for the left and right shoulder buttons should be swapped around.
Keep up the great work, pcklee123
I have found a number of games quite playable with no sound and having the gp2x overclocked to 260Mhz.
Zelda Minish Cap, Ninja 5-0 and mario advance (mario brothers 2) work well.
Bug Report:
I find there is a graphics glitch, which is a line of colored pixels above the playing area.
The config file for the left and right shoulder buttons should be swapped around.
Keep up the great work, pcklee123
Fez
Still Fresh
Wow, that was a quick update!
I noticed the graphic glitch, the line of pixels above the screen is fixed, as well as the config for the controls.
Awesome!
Compatibility has even improved, Sega Rally and a few others did not run yesterday they do now.
The majority of games, graphically are pretty bug/glitch free, it basically only the obvious lack of fps that hold the graphics back, which i think for this stage of development is pretty bloody damn good.
Mario Kart is the only game I have at the moment with a major graphic glitch, and that is the main starting screen. This could be my rom dump, I will have to try another.
Again, fantastic work!!
I noticed the graphic glitch, the line of pixels above the screen is fixed, as well as the config for the controls.
Awesome!
Compatibility has even improved, Sega Rally and a few others did not run yesterday they do now.
The majority of games, graphically are pretty bug/glitch free, it basically only the obvious lack of fps that hold the graphics back, which i think for this stage of development is pretty bloody damn good.
Mario Kart is the only game I have at the moment with a major graphic glitch, and that is the main starting screen. This could be my rom dump, I will have to try another.
Again, fantastic work!!
Actually I'm not doing much usually I just delete things and hope it goes faster. I really hope a person who really knows hot to program can take up the vba emulator. My feeling is that with some optimization of the sound code, it can become quite playable. The only problem I have now (apart from it being slow) is that the sound is choppy
Fez
Still Fresh
Maybe Notaz, Reesy or Rhyleh may be able to give some expert advice if you ask them?
