Not everything is as fast as planned


Who cares about the LCD, just ship the bottom half to me as I can hook my 1080P desktop LCD to it.  Ship me the top half later when everything is iron out with the rotation. :)
 
The Rotator chip works fine and rotates, with X, you won't have any issues in its current state.


However, as it's missing the sync, you would see a feint line on fast video animations, similar to the VSync issue the WIZ had at first (where there was a feint diagonal line when playing games) or any emulator that does not support VSync on the Pandora.


The chip can be bypassed, so games using OpenGL can use the 3D chip to rotate the screen (so any of the Emu-EX emulators would work).


So the problem is NOT that the chip doesn't work at all, it just has VSync lines until we get the sync working. The hardware is there and connected, but the software is missing.
 
So, your goal is still to really make the chip work "global" under any circumstances, independent on what is runing onto the Pyra? Sounds good of course, good luck. It would surely be very efficient if the chip "just" rotates and the various software does not need to be adjusted to rotate their output.
 
So the problem is NOT that the chip doesn't work at all, it just has VSync lines until we get the sync working. The hardware is there and connected, but the software is missing.



I think what people are worrying about here is that you may put the first Pyra on sale / shipping the first units  while not having this issue resolved yet. So can you confirm if you will delay the release of the Pyra in case the Vsync problem is not figured out, or ship them anyway expecting the problem to be solved later on ?
 
Last edited by a moderator:
Bypass and hardware accelerate, or run double the resolution with flipped RGB sub-pixel smoothing. You would only notice on batterylife, which if nobody told you it was supposed to be even better, wouldnt be a thing.


Its an open handheld, as soon as the hardware is ready is when "delays" is just waiting for waiting.
 
Last edited by a moderator:
I think what people are worrying about here is that you may put the first Pyra on sale / shipping the first units  while not having this issue resolved yet. So can you confirm if you will delay the release of the Pyra in case the Vsync problem is not figured out, or ship them anyway expecting the problem to be solved later on ?



What should a delay help here?


There's nothing to be fixed in hardware.
 
I'd personally like notaz's agreement that the system has access to all the signals (probably) needed.  I guess for that he'll need access to a proper prototype board set up and running first though.


I'm a little confused by the problems this delay is causing.  Presumably the people you're talking about sending boards and cases separately to are the ~20 prototype users, not the ~200 preorder users.  That sounds like business as usual to me; prototype users can be expected to do something useful with just a board and a way to power it.  Retail users, less so.
 
Prototype users also already paid for their hardware ;) Its not like they aren't each and all ecstatic anyhow. The best chance anything has at getting fixed is getting those units out.



The prototype pre-orders paid up front in full plus shipping.  


It should be OK with a part injection molded and part 3d printed case.  I want to be able to fiddle with the device away from an antistatic workbench though, so some sort of case please?  It does not have to be art gallery quality, just functional.


Rotator chip's software not working at prototype time isn't a big deal.  Sketchy software at prototype time is expected.


I'm still looking forward to the first video from ED of a complete unit in a case running on battery.  That will be magical.
 
The Rotator chip works fine and rotates, with X, you won't have any issues in its current state.


However, as it's missing the sync, you would see a feint line on fast video animations, similar to the VSync issue the WIZ had at first (where there was a feint diagonal line when playing games) or any emulator that does not support VSync on the Pandora.


The chip can be bypassed, so games using OpenGL can use the 3D chip to rotate the screen (so any of the Emu-EX emulators would work).


So the problem is NOT that the chip doesn't work at all, it just has VSync lines until we get the sync working. The hardware is there and connected, but the software is missing.



I knew most of that information but thank you for all the clarifications. What about the alternative LCD? I haven't read anything on the boards, maybe it is lose on some random post that I didn't saw.
 
Landscape 5" LCDs are non-existent. So the rotator chip is needed no matter what LCD you use, unless you want to GPU-rotate everything like Android does.



Ok, just saw some people talking about another LCD and was curious about that. Thanks for the explanation.
 
What should a delay help here?


There's nothing to be fixed in hardware.



I'm taking about a delay in delivery, because of software not being ready yet to accommodate Vsync and ensure the first Pyra owners do not suffer from this ? It does not seem Notaz was very confident it could be fixed easily based on his post on this thread.
 
I'm taking about a delay in delivery, because of software not being ready yet to accommodate Vsync and ensure the first Pyra owners do not suffer from this ? It does not seem Notaz was very confident it could be fixed easily based on his post on this thread.



Is it important?


It's just an annoying line in some programs.


I'd rather have my Pyra and play Games (some with a small line) and use all the other stuff instead of having nothing.


A software update is not a big deal.
 
I'm taking about a delay in delivery, because of software not being ready yet to accommodate Vsync and ensure the first Pyra owners do not suffer from this ? It does not seem Notaz was very confident it could be fixed easily based on his post on this thread.

It is well known what is technically needed http://projects.goldelico.com/p/gta04-kernel/issues/703/ . If someone wants to jump in to write this code, please contact me. Otherwise you have to wait until I find the time to do it (after finishing/fixing the pre-production issues which are currently of higher priority). It is not a matter of "if" it can be fixed, it is a matter of "when".
 
It isn't complicated for use, the rotator works fine. Only sync is missing, but that's because we use MIPI in video stream mode whereas the sync-signal is only used in MIPI command mode.


That's a MIPI standard, not the fault of the rotator chip.

Which means the rotator is basically unusable in the video mode, I don't see how you can say it's not a fault of that chip. It could've provided some way to sync to the video stream but it does not. The only way to use it is the command mode, but OMAPs have no drivers for that (Nikolaus has another solution, see below, but I'm a bit skeptical).


And it IS complicated to use, it's very picky on register programming sequence where you have to program tons of obscure parameters "right" for it to do anything at all.

* Configure the OMAP5 to wait for the sync signal once and then start the videostream (right now it simply starts the stream whenever you tell it to)


If you do something like this you should measure the interval between several sync signals and calibrate a timer to match this. Otherwise the difference in clocks will cause too much drift and eventually you'll fall out of sync. This method will still cause drift but it can possibly be mitigated to where it only becomes an issue after the unit is on for days or weeks. Maybe you'd need to occasionally try to resync.


That is, unless the OMAP5 and rotation chip have the same clock source (seems unlikely?)

The clock sources are different. I've already experimented with that and failed, it's just always drifting away. Even if we could somehow find compatible multipliers/dividers to make it stable one one unit, it doesn't mean it will work on another. Hell, it might even start drifting when temperature conditions change.


Nikolaus has a solution (see his link) but for me it still looks problematic to both implement now and to maintain later.

There's nothing to be fixed in hardware.


It is not a matter of "if" it can be fixed, it is a matter of "when".

I wouldn't be so certain but I'll trust you both on that...

A software update is not a big deal.

If there is nobody to work on that software update it is, don't you think?
 
Last edited by a moderator:
A software update is not a big deal.

If there is nobody to work on that software update it is, don't you think?
A software update is not a big deal.

If there is nobody to work on that software update it is, don't you think?



Didn't mean it like that.


I don't want to say it's easy to do but it wouldn't be a big deal for me.


I'd rather hope for the update and have my Pyra than waiting.


(Gaming is not main use for me. It's working, Music and hopefully Mobile Internet)


(Quote messed up. Silly Editor. Can't handle it)
 
Back
Top