Gp2x New Revision: Will It Come Soon?

[Trashman]

I work for the military and we get stiffed worse than you think. Basically because the muppets that agree contracts on our behalf seem to have no buiseness background.

I hope you don't have to kill us all now h34r:
That seems to happen nearly everywhere, the guys at the top don't have a clue.

​

No, but when you wake tomorrow you wont remmeber this happened.

 

[Aninhumer]

Remember what happened?

 

[Trashman]

Remember what happened?

​

lol

 

[Radek]

DaveC we will not have the same issues as with blu+ again, software dosnt acces the screen direcktly anymore as we are useing linux, so the timeings are defined in linux itself not the software.

​

That is when using linux.

Sorry to bug you but that is wrong. My competition entry is using hardware directly without any added layer of software. That's under Linux and it's easy. I have just to open the framebuffer device and got a pointer to it. The all hardware registers of GP2x are also memory mapped. Linux isn't making any difference here.

What happens when/if HH is out? Trouble. That uses the hardware directly. HH mode emus like DrMD will use screen timing and raster interrupts for things like water palette scanline switches. Reesy has said that is not doable in linux but will be for HH mode.

And I don't see a reason why change of LCD should make all this impossible or corrupt? The only difference with Linux is that there are privileges and memory protection plus premptive multitasking. That can make some things difficult (and it's making other very easy) but again - the change of LCD should not have any effect on the software compatibility.

I don't know about GP32 at all but with GP2x changing the LCD will not be different than changing a monitor for PC. Is that breaking any software even if it's using hardware directly?

Because the GP32 has issues with LCDs it doesn't mean the GP2x will be the same. The MMSP2 is very different animal than the GP32's internals.

And... I was searching but didn't find anything - what was the technical issue with the "BLU+" exactly? No, I haven't effects in a mind but the cause.

 

[DaveC]

Dude, freaking listen. The display is interfaced with the MMSP2 chipset. The LCD suddenly is no longer an issue, providing it's the same size. End of story. Please, please relax, you freak out over everything like someone has invaded your space. You're a nice guy, just don't worry so much!

Allan.

​

Ok don't freak out about me freaking out I have been though the mess of the BLU+ where you needed different versions of programs for each LCD type. A real PITA. so I was a bit concerned.

 

[DaveC]

And... I was searching but didn't find anything - what was the technical issue with the "BLU+" exactly? No, I haven't effects in a mind but the cause.

​

It was a timing thing. The new display module had a bit different timing causing bars, wrapped pixels etc. I nkow it doesn't make sense but it caused hell. I thought as you, it is just an LCD how could it possibly effect anything? It is just a display, it just shows whatever is put to it. But for some reason somewhere you needed to change your code to drive the new screen different. Electronically it was never really explained fully. I had a hunch that it wasn't the LCD itself but a change in the LCD driver chip to drive the new LCD. That chips timing was slightly different causing the trouble.

 

[Radek]

And... I was searching but didn't find anything - what was the technical issue with the "BLU+" exactly? No, I haven't effects in a mind but the cause.

​

It was a timing thing. The new display module had a bit different timing causing bars, wrapped pixels etc. I nkow it doesn't make sense but it caused hell. I thought as you, it is just an LCD how could it possibly effect anything? It is just a display, it just shows whatever is put to it. But for some reason somewhere you needed to change your code to drive the new screen different. Electronically it was never really

What it does mean - "code to drive the new screen different"?

The framebuffer format changed or what!?

This is very important question because if it was so then indeed... it was crap. If otherwise then not that big problem at least from technical standpoint.
(thought it needed new binaries so it was tiresome to recompile all software)

explained fully. I had a hunch that it wasn't the LCD itself but a change in the LCD driver chip to drive the new LCD. That chips timing was slightly different causing the trouble.

​

As long the framebuffer format will be intact (and knowing few things about the MMSP2 chipset it should) changed timings will not be a big issue. Even the HH will have some kind of initialization code so any correct timings could be set at the bootup.

You talked about the raster type effects... for them perhaps it could be an issue. But imho for machine like GP2X resorting to such tricks isn't necessary. Check my competition entry - it proves that very well.

 

[Squidge]

I think DaveC is freaking out because of the timing values required by different LCD screens. Accessing the hardware directly under Linux is one thing, but if you go from scratch you need to setup all the LCD timings first, and if these change because of an LCD change, the any software with the old values will need to be changed also.

However, what DaveC seems to be missing is that HH-mode simply means applications run before Linux. Linux doesn't initialise the display on the current firmware - uboot does, and so neither the Linux kernel or HH-mode applications have any need to have LCD timing values embedded within themselves.

So, if the timing values change, some GP2X's will have a different uboot, that's all.

Raster effects/etc will work from hblank and vblank interrupts, and these will be the same regardless of LCD, as the timings will be setup up appropriately.

 

[nickspoon]

If you're writing to /dev/fb0, congratulations, you're writing to the framebuffer under Linux!

What Squidge says is absolutely right, so don't worry.

 

[Radek]

If you're writing to /dev/fb0, congratulations, you're writing to the framebuffer under Linux!

Well... I started doing so because of some reason I couldn't compile with SDL and was interested in the direct framebuffer manipulation anyway.

What Squidge says is absolutely right, so don't worry.

​

That's reassuring as if the framebuffer format would change then I'd have to do total rewrite of all my routines...