Print

[desertboy]

I've seen hundreds of posts about virtual memory as if it's this is the holy grail for emulating large roms.

Why I think it won't work (Not can't just won't)

When dealing with a rom I think people just assume it's accessed in the same way as a normal cd. IE using a file system streaming the data you want from one part of the cd. Roms aren't accessed like that because there is very very limited space games have to reuse textures from ealier levels and the same sounds throughout the game.

EG. if a shooter on the psx uses the same sound for a gun on all it's levels the data is probably stored multiple times so when the PSX is loading the level data the sound data is probably stored linearly with the level data to speed up loading.

With a rom it would pull data from all over the rom meaning you would never know which piece of data was going to be needed next so as to load it into memory.

A hard disk is slow, it's very slow in comparison to a rom (or read write memory), virtual memory doesn't somehow magically run faster if anything it actually runs slower than if it was just reading a file from the hardisk.

I think many people don't understand how virtual memory works, it works by writing the part of the contents to memory before then loading in the required info to memory (So you have a write and then a read from HD for the equiverlent memory read) it's just too damn slow for rom usage (Fine for cd emulation .cue .bin style as CD's have a low transfer rate.)

I could think of several ways to combat the rom problem but all of them involve a lot of work on a game by game basis.

Possibly storing the compressed in memory might be a better way but you've got a performance hit there as well.

[Mage]

Um...on demand paging works quickers than you think.
You have a page directory that breaks the memory up in to page tables, with each being 4KB big.  (You can do 2MB, but normally you stick with 4KB pages.)

Here's why it would be quicker than just using software to do it, the software doesn't have to know anything is why.  It just accesses memory as normal, and when it hits a page that isn't in memory, a fault is generated.  

The IDT #PF gate is then called and it is responsible for loading the page.  So the speed is critical to how that function loads.  It can use caching to its advantage, so you don't need to access the hard drive as much.

It works far quicker than you would think.

[Lowen Na]

^^^^Mage's post sounds more informed than mine


This is a very well thought out and well reasoned post, and I think that you are right for the most part.

I think that IF virtual memory is worked in to the N64 emulator, we will be able to play some (maybe even all) of the larger than 32MB roms, but with a performance hit during page swaps.

This post has been edited by Lowen Na: Jun 13 2003, 02:33 PM

[oDD_]

This is all very nice, but the X-Box kernel doesn't perform  Demand Paging.

A software implementation (eg. LRU) would have to be written.

This post has been edited by oDD_: Jun 13 2003, 02:39 PM

[Mage]

!--QuoteBegin-oDD_+Jun 13 2003, 08:31 AM-->

QUOTE (oDD_ @ Jun 13 2003, 08:31 AM)

This is all very nice, but the X-Box kernel doesn't perform  Demand Paging. A software implementation (eg. LRU) would have to be written.

Of course it doesn't, currently.
However it doesn't have the #pf IDT entry, so you can just add it.
Then setup your page tables and modify the GDT to how you'd prefer it to be, and then enable the PG bit in cr0.

[desertboy]

!--QuoteBegin-Mage+Jun 13 2003, 04:13 PM-->

QUOTE (Mage @ Jun 13 2003, 04:13 PM)

Um...on demand paging works quickers than you think. You have a page directory that breaks the memory up in to page tables, with each being 4KB big.  (You can do 2MB, but normally you stick with 4KB pages.) Here's why it would be quicker than just using software to do it, the software doesn't have to know anything is why.  It just accesses memory as normal, and when it hits a page that isn't in memory, a fault is generated.   The IDT #PF gate is then called and it is responsible for loading the page.  So the speed is critical to how that function loads.  It can use caching to its advantage, so you don't need to access the hard drive as much. It works far quicker than you would think.

Maybe I'm wrong but I assume the memory page functions are handled by logic on the processor (thus only having to take a perfomance hit when memory needs to be paged)

I don't know what the cache is like on an xbox (whether it's part of the unified memory, extra memory for cache purposes or there just isn't a cache)
but surely if the cache is part the unified memory it'll be stealing memory away from the emu/application thus compounding the original memory problem.

Demand paging might well work quicker than I think but I pretty certain it doesn't work quick enough for an N64/Mame rom to run at a decent speed.

Paging surely is just removing the overhead of memory managment (admittedly a large overhead) but does nothing for HD transfer speeds which aren't good when you're accessing the HD pretty randomly (Like an N64 rom would) and of course you will have to do a write then a read for every byte you swap into and out of memory which given the HD is slower than a rom to begin with is not good.

I'm sure virtual memory will let you run larger roms you just wouldn't want to.

I guess the paging is all done by the MMU does the P3 in the xbox have an MMU?

As you can probably guess I know shit about the MMU and virtual memory but I do know disk access times and memory and they just don't compute.

I'm guessing about rom accessing but I know that's what I'd do if I had to write a prog for a cartridge based system.

[Mage]

You're assuming the memory acccess has to be quicker than it really does.
Of course the p3 has an MMU, you're accessing 64MB of ram already...

As for the cache, that is made by the software doing the paging, so it is part of the 64MB obviously.  Tell me this, does a 64MB n64 rom use all 64MB in a single second?  I doubt it.

Does it even change 8MB every second?  I doubt it.

The n64 isn't that memory hungry to cause major paging hits half as close as you're thinking.

Page support will enable the emulator to do all the startup with for the whole rom, load the whole rom, and then only the parts needed will stay in memory over time.

[dankydoo]

Why doesn't somone try Mame with a very large rom on xbox-linux and see how it runs?


dankydoo

[Mage]

!--QuoteBegin-dankydoo+Jun 13 2003, 12:31 PM-->

QUOTE (dankydoo @ Jun 13 2003, 12:31 PM)

Why doesn't somone try Mame with a very large rom on xbox-linux and see how it runs? dankydoo

Linux overhead will be eating more memory, not to mention libc in linux will be far larger than the size of mame when it is directly ported to the xbox.

The only thing that'd show is if it runs nice in linux, then for sure it'll run great when using virtual memory in a direct xbox port.

If it runs slow, that won't mean it will for sure run slow in a direct port though.