Back To The Gp32, Coding To Hardware On Gp2x

[Fez]

I dug out the Gp32 tonight, which i pretty much shelved since i picked up the GP2x. And man, I was like holy **** this this rocks, i mean i cant really see whats going on as well (no backlight) but the control, I hadnt realized how good I had it before. I wasnt getting annoyed and putting the game down after three minutes. I also thought gee these emulators are quite fast i.e. Fday, the GP2x with all its power isnt meeting its full potential as yet. I guess thats due to linux, and the software not being coded directly to the hardware? So I ask are there any non GPH firmwares in the pipeline? Do you think the software will will take a direct to hardware approach in the future?

 

[Quiest]

Yeah, I wonder, too, what happened to that very promising sounding HH mode?

 

[FluffyPanda]

I think that the hardware isn't being used to the fullest yet, but I don't think it's linux's fault.

As I understand it HH wasn't really followed through on since it was found that linux was being pretty damn efficient at letting code run well.

Most likely the best speed boosts will come from (in this order):

1) Paeryn's harware accelerated SDL libs maturing (or other libs)
2) Devs learning how best to code for the gp2x
3) tweaking of the firmware

Obviously there is a lot that can be gained by using the second processor and writing optimised asm, but this seems unlikely to be used outside the speed-hungry emulators.

... though I could be wrong

 

[aapje89]

As I understand it HH wasn't really followed through on since it was found that linux was being pretty damn efficient at letting code run well.

​

didnt know that, damn

 

[DaveC]

No HH means No raster interrupts like the water effect in Sonic. It was said that Linux keeps you from reading the screen area directly or something to that effect. It is still important to nix linux if we want better emulation.

 

[Epicenter]

Hardware-level programming is only going to be useful for a limited number of applications and the majority of programs won't benefit. It would require booting from an SD card and not from the system itself likely on a per-program basis, be slower than booting from NAND memory, and more trouble to get applications running. But it would allow significant speed gains in SOME programs-- though MOST of the speed gains that can be had with hardware-level access can also be had just by plugging in bits of ASM code into C programs. The things that'll benefit are things that need to sit at the 'bare metal' level and talk to the hardware itself-- which are pretty few and far between, like DaveC said-- DrMDx's raster effects issue.

 

[Mudi]

No HH means No raster interrupts like the water effect in Sonic. It was said that Linux keeps you from reading the screen area directly or something to that effect. It is still important to nix linux if we want better emulation.

​

I'm betting if Reesy gets DrMDx to run fast enough in 16-bit mode (as he says he was going to work on) the raster interrupts would be trivial to emulate rather than reconstruct at a hardware level.

 

[FluffyPanda]

No need to get rid of linux as I understand it. Linux is currently stealing the interrupts itself and not letting Reesey at them. All that needs to be done is add a node under /dev/ that passes the interrupt out the other side.

This is all stuff that cleverer folk than I have said on these boards, and from memory at that, so it's not too unlikely that I've got something wrong.

 

[Fez]

Hmm interesting, it would good to get some other devs who have looked at the issue to comment too.

 

[Squidge]

Don't forget there's a lot of work in writing a true HH-app. If we take DrMD as an example, HH mode would give it raster interrupts, but the disadvantage would currently be the inability to change roms without rebooting (there's currently no file system in HH-mode), and no sound support (no one has worked on getting sound working yet).

Which would you prefer?

 

[Fez]

I see the situation. Obviously when you have a system that is working well already and only requires a bit of tweaking to get very good results you would go down that path, rather than going from scratch with the HH. I guess its something that will get looked at a fair bit down the track and slowly come together with work from multiple sources.

By bringing up this topic, I dont want to make it an excuse to nag developers to go down a certain path or anything. I have no preferences, I just aprrectate anything that gets released regardless, any software you guys release is a privaledge not something we have a right to demand for.

 

[Squidge]

Yup, give it time, and the SD stuff with mature, the file system will be finished, and the audio will eventually get figured out and be usable.

Once that is done, it will be a lot easier to create the applications, so more people will use the additional power it gives.

At the moment, people just want to get a few applications under there belt and see what Linux has to offer before trying to hack the hardware directly to see how much extra they can get.

 

[Aninhumer]

I don't know much about this but I would have thought it wouldn't take too long to port a file system. I expect I'm very wrong...

 

[DijiTao]

I'm somewhat surprised that more effort hasn't been put into just "fixing" Linux. Like FluffyPanda said, adding a node to /dev/ to pass the interrupts - that seems quite reasonable to me. While you might theortically get better preformance out of direct hardware access, the increase in development time for what should really be some pretty modest gains, make it a fairly irrational path to follow. By fixing linux, we get to keep easy development and still get good preformance.

 

[chris_r]

But we're not talking about porting to linux here Things arent just a matter of recompiling in HH land

 

[Aninhumer]

I would still have thought large chunks of code can be reused, I guess there are probably complications.

 

[Squidge]

I'm somewhat surprised that more effort hasn't been put into just "fixing" Linux. Like FluffyPanda said, adding a node to /dev/ to pass the interrupts - that seems quite reasonable to me. While you might theortically get better preformance out of direct hardware access, the increase in development time for what should really be some pretty modest gains, make it a fairly irrational path to follow. By fixing linux, we get to keep easy development and still get good preformance.

​

Adding a node to /dev for various things is fine, but then your going down the dependencies tree again. People wondering why certain programs don't work and just give black screen etc, and then find out they need to add certain modules to there nand before it'll work.

Then you have people running cramfs/squashfs which have readonly nands, and so require a new filesystem to be built with these modules in.

Not something you really want to do.

 

[sweetlilmre]

Adding a node to /dev for various things is fine, but then your going down the dependencies tree again. People wondering why certain programs don't work and just give black screen etc, and then find out they need to add certain modules to there nand before it'll work.

Then you have people running cramfs/squashfs which have readonly nands, and so require a new filesystem to be built with these modules in.

Not something you really want to do.

​

Surely these nodes are pretty important in gaining access to lower level hardware?
Would they not become a 'standard' of sorts, which would in turn suggest an upgrade path as opposed to a million different disparate fixes.

Then again, I may not have the faintest clue here (my last use of interrupts was int13h in the dos days )

The official / unofficial firmware differences effect this in a big way, it would be nice if there was clear dialogue between GPH and the various kernel hackers out there i.e. some kind of coalition or workgroup with a roadmap of things ahead.

Then again, so would world peace...
-(e)

btw Squidge, I've just ordered my Gizmondo, can't wait to get my hands on this device

 

[FluffyPanda]

As far as I'm concerned what we really need is a flasher app that will work even with unlucky SD cards and then a standard community firmware.

I don't think it's unreasonable to have a "requires Open2X v1.7 / theoddbot 2.4.0" notice in a readme file.

DrMDx was the only reason that I upgraded from the 1.0.1 (as soon as Rob's flasher was available) since the menu flickered like mad. Reesey said basically that he couldn't be bothered to fix it and you'd have to use at least fw 1.1.0 with DrMDx.

I think that's fair enough. If he did it again with raster interrupts then I'd just upgrade again. I don't see the problem.

 

[theoddbot]

Both open2x and gph are using devfs, no need to put the modules on the nand, and no need to write a new image for some /dev nodes, just have the app load the module when it starts up.