Hey barf, :D. I need to finish the libdraw and libgraph libraries first. I've been researching anamorphic display modes, heh, as well as the DISPLAY and DISPFB registers. There's something bugging me about the read circuits and merge circuit on the PS2, but I can't put my finger on it yet :?.
Karas, that'd be helpful. There's a rewrite in progress for VBA-M called VBA2, which just recently got into working condition from what I've seen. I think it doesn't have any sound support or anything, but browsing the code, it looks like it uses a lot less memory. There's also VBA Minimum, but the guy who made it said that it's slower and kind of broken.
For the GBA, if I understand it right, the largest supported size without bank switching is 256 megabits or 32 megabytes. I think, on the PS2, you have the full 32 megabytes available, though ps2sdk's loadfile loads the program @ 1 megabyte. The best way would probably be to strip the rom to see if the size can be lowered. Trying to load memory chunks at a time might not be feasible on the PS2, since there's the EE<->IOP request through SIF bus, then the device's irx module needs to do the seeking and reading which then the sends it back IOP<->EE through SIF.
The tlb could be fiddled with to give an extra megabyte from the IOP, though... Not sure if that's neccessary, heh.
Can we try out this VBA-M LIMITED with slow GBC support? :))
ragnarok2040 no matter how big GBA ROM is it always needs 0x2000000 (32 MB) free space for rom image in memory.
Either way you can try to do something with it :P
@CaptainHIT yes you can if you have pendrive because only mass support is implemented at the moment. All you have to do is change GBC ROM file name to ROM.GBC and past it to your pendrive root folder (mass:/ROM.GBC that's default path)
i hope the new version snes9x for ps2 comes out better someday because i want to play some snes games on ps2
It looks like VBA is hardcoded to allocate 32 megabytes for a gba rom and 256 kilobytes for work ram and uses it directly from ram. It then allocates space for the bios, internal ram, palette, vram, oam, pix, and iomem.
Since GBA images are direct mirrors of the gamepaks, from what I've read, limiting the allocation for smaller images should work since the emulator shouldn't read past the actual size of the image... It should be possible to just directly read from an uncompressed image from the hdd, mass, or dvd, using an interface with the cpu core, kind of like simulating the way the gba reads from a cart without using actual ram. The problem is with the latency from doing that...
Found some better info, and access times for reading from the ROM are down to single digit cycles or nanosecond scale of CPU time so trying to read from anywhere but ram will result in delays. Memory paging should work, but I'm not sure if it'll be all that good on the ps2, since you need to go from ee->sif->iop->device->iop->sif->ee when a pagefault occurs, heh. Perhaps some sort of cpu instruction prefetching could be done on the arm core so that pagefaults can be anticipated.
I want to thank you for FCEUltra port.
And i'm looking forward to you finishing Snes9x port.
Your work on PS2 SDK is also important.
Thanks a bunch KarasQ, I'll try it out. :)
I'm really interested in the new code for gsKit video mode detection.
I'm currently having some problems with SDL always wanting to go PAL, and as there is no maitainer in the PS2 SDL code, maybe I can start fixing some issues on it, such as the SDL_Delay (freezes) and SDL_Timer (always returns 0). And another thing giving me problems is how SDL-PS2 handles the PAL/NTSC detection badly.
I actually posted the instructions to fix up the video in SDL on ps2dev's forums, so that might help for a start, :D.
There should be enough information there to even implement the ability to change graphics modes as well.
I took a cursory glance at the timer code in SDL, but it looks only partially implemented. From what I could tell, if the timer is threaded, it might work. SDL_Delay seems to be related to that. There could be a conflict with SDL's timer1 interrupt handler and ps2sdk's timer1 interrupt handler for libc. They both try to be at the top of an interrupt handler chain. Lukasz mentioned that using -1 as the "next" parameter for AddIntcHandler would append the interrupt handler to the end of the current chain. Other than that, it seems to look fine. SDL's timer code even uses the correct pointer size for the timer registers.