64mb Ram - What Will This Mean...

[Prophet]

Everyone knows the GPX2 design was upgraded to 64MB RAM. A very good thing, but let's take a moment to discuss what that will mean in real world terms.

I think most people instantly think NeoGeo AES/MVS emulation, or CPS2 emulation. Can the GPX2 emulate those systems well enough (with sound) to be playable at good frame rates? Who knows... We just don't yet. But it's within the reasonable realm of possibility. So just for fun, we can at least look at what games the GPX2 could load into RAM.

Since NeoGeo ROM sets are generally rather large. So let's take a look at what NeoGeo games could be loaded into that 64MB. keep in mind, you have to consider the UNZIPPED size of the ROM set, because you can't have the data compressed during emulation. So here are some of the largest & most popular games we could fit in 64MB RAM, and some of the games we could not:

Metal Slug 2 ~44MB. Easy fit.
Metal Slug X ~ 65MB. Can't fit. And forget MSlug 3, 4 & 5 - all too big.

King Of Fighters 96 ~46MB. Easy fit.
King Of Fighters 97 ~59MB. Tight fit, depends on system overhead & program/work RAM needed.
King Of Fighters 98 and above, can't fit. Too big.

Samurai Shodown 4 ~48MB. Easy fit. Meaning SS1, 2 and 3 also fit nicely.

Last Blade ~61MB. Very tight fit. A maybe.
Last Blade 2 ~71MB. Can't fit.

Pulstar ~40MB. Easy fit.
Blazing Star ~44MB. Easy fit. Great SMHUP btw. =)

Garou Mark of the Wolves ~90MB (varies depending on ROM set). Too big.
Real Bout Fatal Fury ~44Mb. Easy fit.
Real Bout Special ~50MB - Easy fit.
Real Bout 2 ~71MB. Too big.

Waku Waku 7 ~36MB. Easy fit. Fun game.

Of course, all the older NeoGeo games will fit easily. Including many great puzzle games like Puzzle Bobble 1 & 2 and the Magic Drops etc. A lot of good games. Then there's also the NeoGeoCD, you only need around 7MB for that - so no problems there. So we could have some of the later KoF's (up to 99) that way. But sadly there never was a CD version of Garou, which is unfortunate.

Now let's consider some CPS2 games. CPS2 carts actually were more limited in ROM capacity than NeoGeo carts, which became larger and larger capacity over the years. So literally ALL CPS2 games will fit easily into 64MB RAM. Here are some nice examples:

19XX ~20MB. Easy fit.
Alien Vs. Predator ~23MB. Easy fit.
Mars Matrix ~44Mb. Easy fit.
Marvel Vs. Street Fighter ~46MB. Easy fit.
Marvel Vs. Capcom ~46MB. Easy Fit.
Street Fighter Alpha 3 ~46MB. Easy fit.
Vampire Savior ~46MB. Easy fit.

So if a CPS2 emu is ever dev'ed and optimized for GPX2, we'd have a lot to play.

Any other systems you can think of where the 64MB RAM will be particularly useful for emulation?

 

[Vimacs]

sorry, but i realy doubt that we get a neogeo emulator that will play any of the above games at fullspeed, maybe a few of the oldr ones.
neo geo cd is way more realistik

 

[Prophet]

sorry, but i realy doubt that we get a neogeo emulator that will play any of the above games at fullspeed, maybe a few of the oldr ones.
neo geo cd is way more realistik

​

Well we'll see. Keep in mind the AES/MVS and NGCD basically were the same system inside. The NGCD had some minor differences in sprite handling, to make the most of the 7MB RAM in the console. But for the major components, the CPU and all it was the same. So if you can emulate the NGCD at reasonable speeds, the AES/MVS should be in the same neighborhood.

Anyway, let's just hope for the best and see what happens.

At least NeoGeo AES/MVS/CD and CPS1/2 were all 68000 based, so we already have CPU cores for them in ARM ASM. In fact, one could say these systems weren't THAT much more powerful than the Genesis in most respects. Much better sprite and tile engines, and slightly higher clocked 68000's.

Let me see what fps/fs I get on my PSP running NGCD at 222Mhz...

 

[Prophet]

OK did some tests on PSP. Very nice numbers to report.

Using YoyoFr's NeoGeo CD emulator for PSP. Which BTW, doesn't have an ASM core, since Cyclone is ARM and PSP uses a MIPs CPU.

PSP clocked at 222Mhz, playing Metal Slug 2 NGCD:

1) MP3 music ON, frame skip 2 -> get between 50 - 60 fps.

2) MP3 music OFF, frame skip 1 -> 60 fps.

3) MP3 music OFF, frame skip 0 -> around 50 - 55 fps.

NOTE: even with MP3 music off, you get FULL sound effects!

Now consider that music on NGCD requires mp3 decoding. So that eats extra cycles. On AES/MVS, the Yamaha soud chip does the sound and the music. So no mp3 decoding needed. Now let's imagine adding some ASM cores to the emu. Seems we have some good possibilities for the GPX2.

Next pessimist, step up to the plate. Heh.

 

[moz]

do that calculations take the size of the emulator into account? or just the rom sizes of the games?

ah it does, maybe there could be some rom trimming done for the bigger roms?

final thought, how long would it take to transfer ~64MB from the SD card to the memory of the unit?

 

[Prophet]

do that calculations take the size of the emulator into account? or just the rom sizes of the games?

​

Those numbers are just ROM size. Which is why on some I wrote "tight fit." However, most leave plenty of space over for emu and work space. Most emus are actually pretty small for executable size anyway.

 

[moz]

do that calculations take the size of the emulator into account? or just the rom sizes of the games?

​

Those numbers are just ROM size. Which is why on some I wrote "tight fit." However, most leave plenty of space over for emu and work space. Most emus are actually pretty small for executable size anyway.

​

ah just noticed that

final thought, how long would it take to transfer ~64MB from the SD card to the memory of the unit?

 

[Prophet]

ah it does, maybe there could be some rom trimming done for the bigger roms?

final thought, how long would it take to transfer ~64MB from the SD card to the memory of the unit?

​

Trimming: actually yes you could. On NeoGeo you could leave out the V ROMs. Would allow you fit some bigger games, but you'd have no sound or music.

SD speed to load 64MB? Don't know exactly till we get the system. But we can wait a few seconds to play a good game.

UPDATE: Ok looked at some SD specs ( http://www.kingston.com/products/securedigital_home.asp ). Seems read speeds are ~5MB/second, or 8MB/second depending on the type of SD you get. Also unzipping algo will add some time. So it could vary a lot. But not that long. And once the game is in RAM, no more loading is needed.

 

[moz]

ah it does, maybe there could be some rom trimming done for the bigger roms?

final thought, how long would it take to transfer ~64MB from the SD card to the memory of the unit?

​

SD speed to load 64MB? Don't know exactly till we get the system. But we can wait a few seconds to play a good game.

​

seconds exactly lets hope its not minutes

 

[Tobriand]

Well, from the sound of it a great deal of rather large games can now - potentially - be loaded, although I'd hasten to add that we should all bear in mind the whole thing about needing a fair proportion of Ram for the emu - and if Craig doesn't manage to make sure that Linux is unloadable whilst running other stuff so we aren't merely limited to running stuff on top of an OS (not necessarily a problem, but I bet it won't helop if its the case) then there's it's memory footprint as well... I'd say its probably safe (with no research at all) to say anything of 50mb or less is ertainly in the feasable area for loading straight into ram.

However, I would like to point out the streling work done by the guys over at GPAdvance when it came to loading... well, anything (including those 32mb monsters), despite the GP32's not so stunning 8mb of ram. The theory - and practice - being that not all of a rom is needed at once, so if you index it at the start, then only load the sections as they're asked for the result is a bit slow, but certainly functional. This has the added benefit that, unlike a swapfile, where you're using a storage medium as RAM, so you have to write it all the time, because you're dealing with stuff that should have originally been unchanged, you don't have to bother with that; just throw out the unused bits and load in what's needed as and when it is. Result: not as slow as it might sound, and no need to worry about killing your card before its time.

Whilst NG roms could be very different to GBA ones - at some point in the loading process, conceivably, the entire roms could be required - but even considering a ROM in hardware form is so much faster to access than a ROM from an SD card, there's still only so much ram to process the things, and I think that's only around 8mb of the stuff.

So personally, I don't see why anything whatsoever could be ran on any ammount of ram, as long as there's more than the original system ram after all processors and thingamies are emulated.

The only point that it comes down to is speed - things will, inevitably, be a great deal faster when entirely in RAM rather than when being swapped.

 

[Vimacs]

the problem with the dynamic loading in the way gp advance is doing it is that you need direct acces to the mmu for it, wich wont be possible while linux is running, but iam positive that linux wont be locked.

 

[moz]

but iam positive that linux wont be locked.

​

wait until Squide gets his mits on it and the linux will be toast

 

[Tidus]

So if a CPS2 emu is ever dev'ed and optimized for GPX2, we'd have a lot to play.

Any other systems you can think of where the 64MB RAM will be particularly useful for emulation?

​

Great words Prophet

My dream is definitly to get a handled able to emulate CPS2 perfectly :rolleyes:
so I would adore that somebody bring it real for the GPx2 and I think as you do that it's totaly possible


concerning the use of more memory, I think a x86 machine emulator to run DOS for exemple would find alot of advantage to get more memory under the emulated system, I mean after everything is loaded, if we still have 32 Mb free for running the DOS games, then yahoooo we'll have long long winter nights ;op

 

[Fishbong]

Now consider that music on NGCD requires mp3 decoding. So that eats extra cycles. On AES/MVS, the Yamaha soud chip does the sound and the music. So no mp3 decoding needed. Now let's imagine adding some ASM cores to the emu. Seems we have some good possibilities for the GPX2.

​

LoL, think one step further....
Of course you don´t need to decode mp3 music in AES/MVS emulation. You got to emulate it. Guess what´s way faster ?*


*[Hint] It´s mp3 decoding !!!

 

[Prophet]

Fishbong, you didn't read carefully enough.

The NGCD emu is ALSO emulating the YM2610 chip, that's where the sounds effects are coming from. But NGCD doesn't play the YM2610 based tunes but instead plays the CD based tunes. So emulating NGCD means all the Neo hardware INCLUDING the YM2610 is running PLUS mp3 decoding at the same time. So emulating AES/MVS is similar to emulating NGCD but WITHOUT mp3 decoding being needed.

Hopefully you get it this time. If not, just ask and I'll type it slower for you.

 

[Huxley]

Funny thing is, the regular MVS hardware was home to some fantastic full-vocal tunes later in its life without the need for MP3. Personally I'd prefer to see the regular NeoGeo emulated rather than the CD systems, because there were some great games never released on CD. But either would be fantastic

 

[Fishbong]

Fishbong, you didn't read carefully enough.

The NGCD emu is ALSO emulating the YM2610 chip, that's where the sounds effects are coming from. But NGCD doesn't play the YM2610 based tunes but instead plays the CD based tunes. So emulating NGCD means all the Neo hardware INCLUDING the YM2610 is running PLUS mp3 decoding at the same time. So emulating AES/MVS is similar to emulating NGCD but WITHOUT mp3 decoding being needed.

Hopefully you get it this time. If not, just ask and I'll type it slower for you.

​

I am 100% sure that the soundchip has nothing to do with the playback of CD music.

 

[Prophet]

Fishbong, c'mon man... :blink:

The point is this - emulating the NGCD system requires that we emulate all the NeoGeo hardware INCLUDING the NeoGeo sound chip (YM2610) while ALSO decoding MP3's.

More clarification:

The YM2610 is the audio chip. On AES/MVS games the music AND sound effects are produced by the YM2610. But on NGCD the sound effects are STILL played through the YM2610, they simply don't play the music files because we have the CD music instead. The YM2610 is still there, it's still running, it's still being used, and it's still being emulated. All the time.

So the YM2610 is being emulated in the NGCD emulator. It's running. It's just only playing sound effects, not music. Instead, we have to decode mp3's to emulate the CD music playback - the same way the real NGCD works, by playing audio tracks off the CD.

In AES/MVS emulation, you ONLY need to run YM2610, because it plays the sound and the music.

This means you have LESS processing involved to emulate AES/MVS. And slightly more to emulate NGCD. More simply:

NGCD = All NeoGeo hardware + MP3 decoding
AES/MVS = All NeoGeo hardware only

The reason NGCD is a good target for PSP and Dreamcast is memory - both have too little RAM to load most AES/MVS games. BUT with NGCD you only need around 7MB and you can run all the NGCD games.

On a system with 64MB RAM, the AES/MVS become more feasible targets because a significant number of ROMs can fit into RAM. And since you don't need to decode MP3's for music on AES/MVS, you have LESS (not more) processing to do per second. Meaning potentially FASTER emulation.

Which is why I showed the numbers I did, the ones with CD music OFF being the most significant. Because those numbers best reflect the frame rates you'd get with AES/MVS.

Now do you get it?

 

[Sonic-NKT]

sad thing is just that the resolution of the CPS2 is a bit to big for the gp32.. i think arround x380 and the gp32 has only x320. so we have to rescale it, that will take cpu power, but perhaps this wont be a big problem if the GPU is good enoguh

 

[Jarska333]

Prime candidate for TV-out.