Back To The Gp32, Coding To Hardware On Gp2x

[DijiTao]

What emulators could benefit from better/direct hardware access? From looking over the wiki article (http://wiki.gp2x.org/wiki/Emulation) it looks like the following:

(*Note I don’t even kind of claim to know what I’m talking about here, I don’t know many of these systems very well or even at all and so I may be grossly wrong. Feel free to correct me)

Arcade (MAME)
Amiga
MS-DOS
PC-Engine
GBA
SNES
Genesis/Megadrive
Sega Mega-CD
NeoGeo MVS
NeoGeo CD
PSX

Everything else is either:
Already working fine (2600)
Needs an assembly core but Linux isn’t holding it back (NES)
Is beyond the scope of what the GP2X is capable of (N64)

So off that list, what do people think? How many of those systems are really going to benefit from direct hardware access? Did I forget any?

What about non-emulators? What benefits would direct hardware access bring to interrupters such as SCUMVM? What about native GP2X games? Have any developers (other than Ressy on DrMD) hit any places where Linux is getting in the way (from a practical standpoint)?

 

[sand_man]

HH would make better use of the second CPU wouldn't it?

 

[theoddbot]

why?

 

[FluffyPanda]

HH would make better use of the second CPU wouldn't it?

​

My understanding is no, it wouldn't.

The problem with the second CPU all comes down to memory bandwidth. It has a smaller cache and has to access main memory accross the same bus as the first core. This means that for memory intensive tasks adding the second core into the equation can slow your app down since the two cores are competing for the same memory.

If you can find a way to get the first core operating soley on cached data and let the second have access to the full memory bandwidth you can use the second core to great effect, though this is rarely practical.

Linux doesn't seem to be getting in the way of anything much to be honest. It's not the resource hog that people here seem to think it is.

 

[Epicenter]

And it still leaves the fact that multiprocessor arrangements are just plain difficult to program from the get-go, often even in SMP configuration where the OS provides ready access to the hardware and a secondary MMU is present. Multithreaded programming just isn't easy. Hell, I doubt we see multithreaded programming truly take off in GENERAL until multi-core processors are able to divide one thread into multiple threads on their own.

In all honesty the 2nd core in the '2x isn't that useful a design attribute, but were it not there and MagicEyes opted for say, a 300 MHz ARM9, the performance gains wouldn't have been that great and people would whine about the battery life.