Gba Emu


Status
Not open for further replies.
pip posted on Mar 11 2004 at 09:06 AM said:
khephren posted on Mar 11 2004 at 02:34 PM said:
Nah, I think your being to pessimistic. This a first, unoptomised, non overclocked test (in fact it might be running in GP default speed, which is what, 99MHZ or 66, craig you should remember from doom?) , and in these modes is alreadty way faster at these demo's than the real thing.
My only worry is....how far can we UNDERclock? :)
Unoptimized? It is not like you can optimize is much more than letting it live on the GP32 hardware and use ASM for the rest. The default clockspeed for the gp32 is 66Mhz. Would indeed be interesting to know what clockspeed it is running at. These modes are not much of a problem since it is living on the hardware. Remember, the faster it is now the more features can be implemented. Such as full screen, good sound etc.
why the heck would somsone want fullscreen... unless the resolution is perfecty scaled from 32x240 to the GBA rsolution *constant ratio* then it would be ugly, large pixles and such. If the ratio is constant between 32x240 and the gba resolution, and 320x240 to 640x480 tehn yes, fullscreen would be nifty, but uneeded right now.
 
Last edited by a moderator:
This piece of software is amazing. If the GP32 itself would allow us to load files bigger than 4MB, i would definatelly sale my FC! I also think it´s much to early to talk about stretching or anything, I just hope, this project never gets cancelled.
 
ThndrShk2k posted on Mar 11 2004 at 03:12 PM said:
pip posted on Mar 11 2004 at 09:06 AM said:
khephren posted on Mar 11 2004 at 02:34 PM said:
Nah, I think your being to pessimistic. This a first, unoptomised, non overclocked test (in fact it might be running in GP default speed, which is what, 99MHZ or 66, craig you should remember from doom?) , and in these modes is alreadty way faster at these demo's than the real thing.
My only worry is....how far can we UNDERclock?  :)
Unoptimized? It is not like you can optimize is much more than letting it live on the GP32 hardware and use ASM for the rest. The default clockspeed for the gp32 is 66Mhz. Would indeed be interesting to know what clockspeed it is running at. These modes are not much of a problem since it is living on the hardware. Remember, the faster it is now the more features can be implemented. Such as full screen, good sound etc.
why the heck would somsone want fullscreen... unless the resolution is perfecty scaled from 32x240 to the GBA rsolution *constant ratio* then it would be ugly, large pixles and such. If the ratio is constant between 32x240 and the gba resolution, and 320x240 to 640x480 tehn yes, fullscreen would be nifty, but uneeded right now.
Of course you would retain the ratio, didn't think anyone would think otherwise. "unneeded right now?" Has anyone been talking about right now for it? Last time I checked I spoke about features that can be implemented. Your comment make absolutely no sense.
 
Last edited by a moderator:
lizard808uk posted on Mar 11 2004 at 02:22 PM said:
@ Horscht You'd sell your football club for it? Damn thats dedication. (I'll buy it for a £1) :p

At this early stage, this emu is looking promising.
Ken Bates! :p
 
Last edited by a moderator:
i just want that this never appears on the zodiac :)
im really looking forward for the next version. i Hope that enf65 will continue his work like before. If he finishes it, he will be definatly a special coder in the gp32 history!
 
This piece of software is amazing. If the GP32 itself would allow us to load files bigger than 4MB, i would definatelly sale my FC! I also think it´s much to early to talk about stretching or anything, I just hope, this project never gets cancelled

well we'll just have to wait to see if mashmods makes a 32mb upgrade for the GP32.... as that would open a lot upto us.... :D
 
Sonic-NKT posted on Mar 11 2004 at 02:29 PM said:
i just want that this never appears on the zodiac :)
im really looking forward for the next version. i Hope that enf65 will continue his work like before. If he finishes it, he will be definatly a special coder in the gp32 history!
i think he allready is RIGHT NOW. I mean, he´s the same thing that loopy is for the GBA. Everyone said: "No way, we wont get SNES on GBA", until loopy proved them wrong. Everyone said: "No way, we wont get GBA on GP32", now he made one. Do you see anything in common?
 
Last edited by a moderator:
yes... your right.. he is allready special... that he started it and got it to work.
Because of him we can perhaps enjoy every new GBA homebrew( yes and also games) on the gp32.. as it would be made for it.
 
but its already impressing. You know it was always said "you wont get it past 3fps", now look at it! It everns runs faster than the GBA itself does.
 
Well, if most of the emulation modes and sprites and that supported and i can play Mario Kart at a reasonable speed, maybe with sound, then i will be very impressed. Would this be possible. I used to think that GBA emulation was impossible on any sort of form on the GP32, i was wrong so now i am going to keep my gob shut! :)
 
news from yaronet :
J'ai réécrit les timers, maintenant ça marche mieux. J'essaye en ce moment d'afficher un menu en cours d'émulation, mais là il se passe des trucs bizards :
Dans mes timers, je scrute les touches et si la bonne conbinaison de touches est faite, je lance une fonction qui s'appelle "void InGameMenu(void)", et là le menu s'affiche très bien mais ça plante aussi tôt.
La fonction marche très bien quand je la lance par exemple au démarrage du programme, c'est à dire pas dans un timer.
Pourtant je lance pleins d'autres fonctions pendant mes timers qui marchent très bien. La seule différence que j'ai pu trouver entre la fonction qui plante et les autres est que j'utilise des fonctions du SDK. Je vais donc essayer de réecrire ces fonctions du SDK.
J'ai remarqué aussi qu'au moment du plantage, la console avait changé de mode (du mode IRQ (normal pour un timer) au mode System (Privilegied User))
Ca peut poser des problèmes si on change de pile en plein milieu d'une fonction.

Bref si quelqu'un a déjà utilisé les timers et qu'il a eut ce genre de problème, ça m'intéresse.

ça me fait penser aussi que j'ai remarqué que la fonction ARMDisableInterrupt() qui est une fonction du SDK (même si j'ai jamais trouvé d'aide dessus) ne marche pas du tout. (Je m'en sers pas, c'est pas grâve)

I rewritted timers so now its working better.
Im now working on an onscreen menu during emulation but some weird things are happening:
In my timers Im looking buttons and if this is the right combination then I launch "void InGameMenu(void)", and then the menu popup but just after it crashes
The function is working great if I launch it in the main menu (just after the fxe is loaded) so timers arent buggy
But a lot of functions are launched during timers and are well working.
The only dif Ive found between the crashy fct and the others is that Im using functions from the SDK
Iwill try to rewrite those fct from the SDK
Ive also noticed at the crash time the GP32 switch from IRQ mode (normal with timers) to SYSTEM mode (Privilegied User)
Maybe it is causing Pbs to change the stack during a function

So if anyone already used timers and he had those Pbs please tell me...

I found that "ARMDisableInterrupt() " from the SDK (but no help on it in a doc file) isnt working at all (Im not using it so I dont care)

see you :lol:
 
Okayu, i am not good at technical stuff... Could someone tell me a percentage of speed it has reached. What comercial games is it compatible with?
 
Status
Not open for further replies.
Back
Top