Not everything is as fast as planned


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.
 
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)
 
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).



It is difficult to find out whom to blame: the rotator chip that it can't sync on the vsync embedded in the incoming video stream in video mode or the omap5 dispc not being able to sync to an external vsync input (which the rotator provides) in video mode. So probably both are broken. Anyways, it does not help to find who should have done better, unless we find anyone (or anychip) who really does it better... In other words: we have to live with the hardware as it is (today).


My approach is indeed very old fashioned... TV sets from the '50ies did it that way to sync the vertical retrace of the electron beam to the incoming sync impulses. So it is probably too much vintage for today's digital technology that we do not believe that it can work before it is demonstrated  :)


But for the moment I am going back to fix issues with U-Boot / MLO.


Just to tell the story: I did use a precompiled U-Boot binary from 2013 on the EVM and prototypes so far. Now, for the new CPU board we have to change the pin multiplexing for the boot console to two different pins because they would conflict with the seconds SD slot signals. No big problem - except that U-Boot has completely changed the default environment parameters (from boot.scr to uEnv.txt, from uImage to zImage etc.). So this is the bigger problem - making Linux boot again... MLO/U-Boot already respond - but can't load the Linux that did boot this morning...


Issues like these are very time consuming for apparently easy tasks.
 
Last edited by a moderator:
I'll bet we will get there in the end, some genius will figure it out. Yes, Pyra will ship with imperfect software, its to be expected.


Should be much better than when the original pandora launched though, I'm guessing.
 
Back
Top