GP2X Virtual Rom

[Radek]

I have an additional idea...

What about storing in the ram all sprite data however at lower resolution (so it could fit)? Then there wouldn't be stalls and a higher resolution images could be loaded on demand.

There is also a VideoProcessor in the GP2x. Perhaps sprite data could be compressed to jpg and decompressed in realtime by VP?

 

[theoddbot]

anyone ever heard of the mmap system call.
http://en.wikipedia.org/wiki/Mmap

basically you format the rom data in the same way you want it laid out in memory, dump it on the SD card. When you run your program just mmap the rom file and let the kernel take care of the caching.

 

[Blah]

Thing is, the ROM is already mapped in such a way, as it was designed to run on a system with limited RAM.

 

[Minkoff]

Sounds great, but... sort of confusing.
Basically what you're doing is loading things into RAM on demand, and then not getting rid of them if they're used frequently, right? Why are people talking about virtual memory and stuff too? :s

 

[DijiTao]

Thing is, the ROM is already mapped in such a way, as it was designed to run on a system with limited RAM.

​

Not really - atleast in the case of the NeoGeo. It had a massive 64 KB of work RAM, 68 KB Video RAM, and 2 KB Z80 RAM. So with the NeoGeo it's not like it pull things from the ROM and put them in RAM when it needed them, it just used them directly from the ROM.

 

[Digitalrat]

Digitalrat:
We do have 2 CPUs. Or are you saying 2x200MHz isn't enough?

Yes, That's what I was saying. I don't speak about emulators like GB/GBC, Sega Genesis,.. because they don't even need this solution. If I understand it correctly the solution is needed for example for NeoGeo or MAME. (because roms are bigger than the ram) Right? And they supposely are not that fast without virtual rom and I think it would be even worse with virtual rom.

Wasn't the GBA-Emu using something like this and wasn't that the reason that it's as slow?

 

[DijiTao]

anyone ever heard of the mmap system call.
http://en.wikipedia.org/wiki/Mmap

basically you format the rom data in the same way you want it laid out in memory, dump it on the SD card. When you run your program just mmap the rom file and let the kernel take care of the caching.

​

If you mmap something that’s larger then the amount of physical memory isn’t it just going to use swap thus getting us back to where we started? Also how does mmap help with caching? We know that in a Neo Geo that physical location is very important and that loading everything into RAM that adjacent to an area of the ROM that’s called makes perfect sense – well at least on the Graphics ROMS.

 

[DijiTao]

Sounds great, but... sort of confusing.
Basically what you're doing is loading things into RAM on demand, and then not getting rid of them if they're used frequently, right? Why are people talking about virtual memory and stuff too? :s

​

Hopefully your actually loading things into RAM before demand, since that’s kinda the point. This is why when the emulator needs ‘b’ you go ahead and load ‘a’ ‘b’ & ‘c’ So you loaded ‘b’ on demand but ‘a’ & ‘c’ ahead of it. Then hopefully the emulator will use ‘c’ which is already loaded, and it can now move ‘d’ into RAM and move ‘a’ out of it. I think a least *Recently* used algorithm makes more sense for Neo Geo graphics ROMs then a Least *Frequently* used algorithm. On the Neo Geo program ROMs a Least Frequently used Algorithm might make more sense. As for virtual memory, we can borrow ideas on how paging works, but a typical virtual memory implementation isn’t gong to work here because of the limited writes issue, as well as the latency on writing.

 

[Aimless_E]

The best way to do this would of course be to do it pre-Linux, as trying to do something like this whilst in linux would be silly due to restrictions such as ram, and having no access to the mmu. Prelinux would mean full ram access and MMU control, which would be a lot faster than trying to do it in software.

​

Typically you wouldn't want to use the MMU since the emulator already manages the memory space of the emulated device. The EMU itself would have to manage detecting page misses and such. You could make this work under Linux. You would just malloc the memory needed for the RAM space of the emulated hardware, and malloc a large block of memory for streaming ROM pages into and out of as needed.

You're right though that the Linux kernel does restrict the amount of memory that you can use as well as eats CPU resources.

​

Correct me if Im wrong but in a former thread there was talk about how GPH setup the second processor. It was my understanding that anything above the memory range of "0xwhatever" was passed to the second cpu. If thats the case could you right a program that completly bypasses the OS will the OS is running? And could this memory range be used as the "virtual rom" or as a precaching ground for the emulator?

like this [sd+rom]--> [second cpu+(x)ram]-->[main cpu +32ram]

Im all for bypassing linux if it means better preformance but theres a certian coolness factor in being able to jump right out of a movie and into a game and back again without having to power cycle the device.

 

[Tobriand]

Ahhh... I see.

Tbh, I thought you were talking about simply pausing system calls and loading a chunk of memory as and when it was asked for (possibly in, say, 1MB segments).

Nice idea .

 

[theoddbot]

If you mmap something that’s larger then the amount of physical memory isn’t it just going to use swap thus getting us back to where we started?

​

Nope. It uses the mmu to trap memory access and reads the data from the file. If its in the file cache, then its fast, if not, slow.

 

[MiniMoose]

If you mmap something that’s larger then the amount of physical memory isn’t it just going to use swap thus getting us back to where we started?

​

<strikethrough>Yes, mmap doesn't solve the problem.</strikethrough>

I take that back, theoddbot is correct. the mmap call uses the MMU to determine which blocks of the file to load and when.

This solution will work if the ROM is accessed sequentially or nearly so since the read-ahead mechanism in the file I/O will pre-cache blocks ahead of time.

 

[DijiTao]

If you mmap something that’s larger then the amount of physical memory isn’t it just going to use swap thus getting us back to where we started?

​

<strikethrough>Yes, mmap doesn't solve the problem.</strikethrough>

I take that back, theoddbot is correct. the mmap call uses the MMU to determine which blocks of the file to load and when.

This solution will work if the ROM is accessed sequentially or nearly so since the read-ahead mechanism in the file I/O will pre-cache blocks ahead of time.

​

problem is I don't think we'll only need read ahead - but read behind as well.