New Gpadvance Version - V1.48


Well mine can overclock to 166 but for those without the mod or if it needs the 32mb ram mod it would not be fair. But don't worry, im sure enf65 and company have some tricks up their sleeves.
 
V3X posted on Jul 7 2004 at 05:24 AM said:
Full Speed
Sound
under 133mhz
Full screen
Savestates
Roms over 4mb
RF Link support
Playing with real GBAs (GP32->GBA cable?)
Off your wishlist you will probably get full speed, this because the main component of the GBA (the CPU) doesn't have to be emulated. Sound will work. It might run under 133MHz because of the thing stated above, the CPU doesn't have to be emulated. Full screen will be an option, but who needs it? The GBA screen isn't that much smaller then the GP32's, and it'll only eat CPU power... Savestates arn't that hard to implent, so count on that. Roms over 32Mbit, don't count on it without the mem mod. RF Link support, don't think there's much of a crowd for that, and same with the real GBA link support, though that might be easy if the GBA uses a UART for it's link cable.
 
Last edited by a moderator:
Tristan posted on Jul 6 2004 at 09:28 PM said:
I'm not much of a developer, but I do know something about hardware. And this means that unless he can figure out a way of dividing the ROM into intensive areas and less intensive areas he's going to put access-intenstive areas on the SMC, and non-intensive areas in RAM. Which is quite the opposite of what you want.
Surely a way to do it might be probabilistically over time. So it'd be slow as anything to start with, but gradually speed up as the emu realised what it had to keep in ram - and then you could send over a config file to other people to speed it up for a specific game, which would contain a hash of that game's ROM just to be sure it was the same file.

Presumably the way you'd do that would be index the file on the SMC as though it were stuff on the cartridge memory itself. Then, since you shouldn't actually have to write anything to the card in dynamic loading - after all, the ROM is a ROM; the only stuff that ought to change in the GP32 RAM is the bit that represents the GBA RAM, registers, CPU state etc. - not the ROM itself. So if I'm thinking about it right...

1) Load first X mb. Possibly 2, possibly 4, depending on the rest of the idea.
2) Rom runs for a bit, then makes a call to something not in memory.
3) The emu recognises this, perhaps because the ROM is stored *right* at the end of the GP32's RAM, or just has a limit on or something. It also has in memory a table which effectively is set of names for the GBA ROM - i.e. if you have 512 kb from the start of the rom, then something from somewhere else that had to be loaded, then some more from the start, things would get confusing when later addressing the memory. So you need something to tell the emu which bit of memory everything represents.
4) The emu loads the called section from the SMC into somewhere in RAM. It also discards a different section, probably from the start of the block. Effectively, this is overwritten by the stuff you just loaded, but it doesn't need to be saved. All that need be saved is which "block" you just got rid of and which you loaded - and in 256kb blocks (just a guess as to a good number), even a 32mb rom is only divided into 128 sections, which ought to be easy to index as 1, 2, 3 etc. I.e. you need 128 values stored to index a rom, short of clever wossnaming - but I think that would just be a case of lots of variables which probably wouldn't take too much ram.
5) The emu then writes to the index file which section it loaded. Possibly it might write *when* it loaded it as well, so as to be able potentially to predict bits. It also writes which bit it unloaded, and how long that had been in memory for.
6) As the index file grows, it becomes a better map of high-frequency memory areas. Once its actually a decent size - probably not all that big, considering what you're storing in it (i.e. a list of chunks and how many times they've been loaded) then you could possibly use it to work out which areas of memory are unlikely to be called, and which are.

Now, I'm not an emu coder, nor will I likely ever be, and I'm not that good at coming up with ideas that are actually plausible. Its quite possible the one sepcified above just wouldn't work well, simply because the emu would get too confused or the memory too fragmented, or whatever but it looks at least a possibility. Which is nice.
 
Last edited by a moderator:
One word to google for, in order to answer to many of your questions : MMU (Memory Management Unit).

Basically you can set up virtual zones of memory, have an interrupt raised when there are read or write acess to a particular zone of the memory.

GPAdvance makes intensive use of MMU features. See this documentation for more information.

So dynamically loading parts of a large GBA Rom from the SMC when they're needed could be done (with certainly some speed issues). Be patient.
For the moment, we're trying to fix compatibilty issues (irq/timers/dma), and we will cope about that dynamic loading later... Why would you want to load large Roms if the emu isn't able to run them ?
 
Torlus posted on Jul 7 2004 at 07:40 AM said:
A Rom from the SMC when they're needed could be done (with certainly some speed issues). Be patient.
For the moment, we're trying to fix compatibilty issues (irq/timers/dma), and we will cope about that dynamic loading later... Why would you want to load large Roms if the emu isn't able to run them ?
Ok ;) We're just speculating :D

Edit:

Though, what speed differences are we looking at exactly? I know the GBA roms are almost as fast as RAM, but do they use it? The speed that is. And how fast can you read stuff off the SMC?

And, maybe for the SNES emu's, how fast does the SNES spool data off the cartridge?
 
Last edited by a moderator:
WHICKED WHICKED!! COmmercial Game 'Breath of Fire' [J][!] runs!!

without sound and its a little bit slow but it WORKS!!!! wahhhh *ejaculation*
 
ok im gonna try boulderdash ex, mario kart super circut, midnight club street racing, ok? i shall report back asap! over and out!

/ends salute!

ok boulderdash ex and mario kart dont work and midnight club freezes at the digital o screen :(
 
V-rally 3 = doesnt work
Chuchu Rocket = Doesnt work
Bomberman Tournament= doesnt work
Wai Wai Racing = doesnt work
Breath of fire 2 us = goes up to capcom logo, crashes then
kuru kuru kuririn = just black screen
 
generalnmx posted on Jul 7 2004 at 11:33 AM said:
We all know Nintendo made sure all ROMs are encoded with information to send back to them through transistor fillaments if the GBA ROMs are ever emulated on a handheld.
do we?

what does this translate into for us non-tech heads?
 
Last edited by a moderator:
spray could it be that the internet made u stupid ?

everyone check out Moorhuhn, Breath of Fire 2 USA version (dont press anything on title screen you'll see some ingame scenes!!) and dodgeball advance (title screen at least)

i hope the three coders support IRQ soon :)
 
gba-cube posted on Jul 7 2004 at 12:51 PM said:
PS- I don´t know if you guys know, but you can change the CPU in the Options and then General screen :p
It doesnt work. The emu is running at 66Mhz
 
Last edited by a moderator:
finty101 posted on Jul 7 2004 at 01:55 PM said:
gba-cube posted on Jul 7 2004 at 12:51 PM said:
PS- I don´t know if you guys know, but you can change the CPU in the Options and then General screen :p
It doesnt work. The emu is running at 66Mhz
Are you sure it is running at 66Mhz? The earlier beta ran at 132MHz (0029DE07 11A00300) ofset 0x0E50 (3664) by default, are you positive it has been changed?
 
Last edited by a moderator:
generalnmx posted on Jul 7 2004 at 06:33 AM said:
We all know Nintendo made sure all ROMs are encoded with information to send back to them through transistor fillaments if the GBA ROMs are ever emulated on a handheld.
what are transistor filliments

and

OMG THE DAY HAS COME
GBA EMULATION
 
Last edited by a moderator:
Back
Top