Uzebox Micro Handheld
Re: Uzebox Micro Handheld
Is the latency on this solution essentially 0 or does it buffer some data?
Probably a higher resolution display could take advantage of a simple full frame filter like HQX. For real time stuff they use lookup tables which probably is not feasible on CPLD, and even small 1 frame extra latency bothers the hell out of me. Still it is probably one of the simplest filters that has a highly visible change. I guess it is problematic that you would still need to pick an arbitrary resolution when there is no integer resolution that works for all modes besides 1440.
Probably a higher resolution display could take advantage of a simple full frame filter like HQX. For real time stuff they use lookup tables which probably is not feasible on CPLD, and even small 1 frame extra latency bothers the hell out of me. Still it is probably one of the simplest filters that has a highly visible change. I guess it is problematic that you would still need to pick an arbitrary resolution when there is no integer resolution that works for all modes besides 1440.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Uzebox Micro Handheld
Zero latency. I have approximately 4 BYTES of RAM on the CPLD. I can't do much buffering
If it does not look good enough and I decide to try support mode9 then I will have to use an FPGA and deal with 5 power supply rails.
In other news - the little Audio Amp I got works nicely so far. Its about the smallest thing I could find without getting into wafer scale BGAs. Its an LM4875 in a TSSOP8.
If it does not look good enough and I decide to try support mode9 then I will have to use an FPGA and deal with 5 power supply rails.
In other news - the little Audio Amp I got works nicely so far. Its about the smallest thing I could find without getting into wafer scale BGAs. Its an LM4875 in a TSSOP8.
Re: Uzebox Micro Handheld
I think your solution will look good without going a more power hungry expensive direction. Even the composite screen mentioned in the other thread I found to look respectable whereas this I imagine more along S-Video to RGB quality(a big difference of course). I guess it would be nice if there was an easy way it could even barely support a somewhat readable 80 columns setup. In the end though, a lot of the high resolution stuff is probably going to be text and require the keyboard; the type of thing that isn't too fitting with the portable motif anyway.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Uzebox Micro Handheld
slow progress. Light at the end of the tunnel though.
I just swapped in the new Audio amp.
It has a POT in the end there for volume at the moment. But the Volume control is a DC voltage. So the 2nd CPU will be able to control the volume easily.
It's a 3mm x 5mm package and can pump out 0.75 watt. I have found that about 0.1 to 0.2 of a W is all that is needed though.
I just swapped in the new Audio amp.
It has a POT in the end there for volume at the moment. But the Volume control is a DC voltage. So the 2nd CPU will be able to control the volume easily.
It's a 3mm x 5mm package and can pump out 0.75 watt. I have found that about 0.1 to 0.2 of a W is all that is needed though.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Uzebox Micro Handheld
Very very slow. Health not so good again. This has taken days rather than hours to do.
But I have gone from looking like this
To looking like this.
It now has a USB port with a LiPo charger and the tiny switching regulators prototyped.
It is funny how the connectors are larger than the actual PCB real estate. And in the case of the PSU board, I spread everything out a LOT for easy hand soldering.
Fingers crossed health holds out long enough for me to do the next bit.
But I have gone from looking like this
To looking like this.
It now has a USB port with a LiPo charger and the tiny switching regulators prototyped.
It is funny how the connectors are larger than the actual PCB real estate. And in the case of the PSU board, I spread everything out a LOT for easy hand soldering.
Fingers crossed health holds out long enough for me to do the next bit.
Re: Uzebox Micro Handheld
You have this thing cornered. How are you mounting the PCBs in the case?
Hope you are feeling well soon.
Hope you are feeling well soon.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Uzebox Micro Handheld
well - once all the sub PCBs are tested I then will CAD up a new single PCB with all the parts in final position.
This final PCB will be the same size as that test one you can see under the LCD in the above photos.
All the components apart from the USB plug and the SD socket will be hidden behind the LCD.
That PCB is the correct size to fit into the plastic shell with just 6 screws holding the front and back together.
Still to be tested are the new CPLD board (already made and tested on old setup) that can select between
1, Nearest Pixel
2, Centre Weighted
3, Even Weighted
The new 2nd CPU board (not made yet) that takes over the job of reading button presses and can be a USB client
The power control board (not even planned yet) that lets the 2nd CPU board wake up on a button press, go to sleep and have an RTC/Alarm wake up the unit (for watch functionality)
Once those last 3 PCBs are tested, I can make the first final prototype PCB.
This final PCB will be the same size as that test one you can see under the LCD in the above photos.
All the components apart from the USB plug and the SD socket will be hidden behind the LCD.
That PCB is the correct size to fit into the plastic shell with just 6 screws holding the front and back together.
Still to be tested are the new CPLD board (already made and tested on old setup) that can select between
1, Nearest Pixel
2, Centre Weighted
3, Even Weighted
The new 2nd CPU board (not made yet) that takes over the job of reading button presses and can be a USB client
The power control board (not even planned yet) that lets the 2nd CPU board wake up on a button press, go to sleep and have an RTC/Alarm wake up the unit (for watch functionality)
Once those last 3 PCBs are tested, I can make the first final prototype PCB.
Re: Uzebox Micro Handheld
A little back on how many cycles should a square pixel take.
I think after all the best would be settling for 4.5 even if that's a bit off (making things wider). The reason is that this way 9 cycles per pixel would become perfectly 2 LCD pixels, and an alternating 4 / 5 cycles per pixel mode would (with proper sync) produce a perfect high resolution result. The importance here is that in such mode a 8 pixels wide tile demands a fixed 4/5/4/5/4/5/4/5 timing sequence, and 6 pixels tile width is also possible. The 8 pixels tile width however wouldn't be possible with aiming for 4.6667 cycles / square pixel. So the rationale of using 4.5 cycles per pixels would be that it is hackable to get perfect square pixels (even using the full 320 pixels width of the LCD, since this way that's 1440 Uzebox cycles, the commonly used video mode width).
Probably "standardize" where the normal Mode 1 begins to display (Megatris, which is also 1440 cycles wide), that way it would be easy to design to be compatible with the LCD as well.
I think after all the best would be settling for 4.5 even if that's a bit off (making things wider). The reason is that this way 9 cycles per pixel would become perfectly 2 LCD pixels, and an alternating 4 / 5 cycles per pixel mode would (with proper sync) produce a perfect high resolution result. The importance here is that in such mode a 8 pixels wide tile demands a fixed 4/5/4/5/4/5/4/5 timing sequence, and 6 pixels tile width is also possible. The 8 pixels tile width however wouldn't be possible with aiming for 4.6667 cycles / square pixel. So the rationale of using 4.5 cycles per pixels would be that it is hackable to get perfect square pixels (even using the full 320 pixels width of the LCD, since this way that's 1440 Uzebox cycles, the commonly used video mode width).
Probably "standardize" where the normal Mode 1 begins to display (Megatris, which is also 1440 cycles wide), that way it would be easy to design to be compatible with the LCD as well.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Uzebox Micro Handheld
The original AVR644 "GPU" was only capable of 4/5/4/5 timing, So the first photos of T2K and Tetris are that.
The "Slow" averaging/fuzzing version with the AVR was 9 clocks per two pixel. So effectivly 4/5/4/5.
The ARM version with the CPLD was capable of selecting 4/5/4/5 OR 4/5/4 OR 5/4/5 and average across 4 samples. When moving, averaging made some video modes look worse and only made mode9 look markedly better.
I have a new version for the ARM in the wings I am going to try that may be able to make Mode9 look OK without the extra expense of the CPLD. Im not a very good ARM programmer so this is taking some time
The "Slow" averaging/fuzzing version with the AVR was 9 clocks per two pixel. So effectivly 4/5/4/5.
The ARM version with the CPLD was capable of selecting 4/5/4/5 OR 4/5/4 OR 5/4/5 and average across 4 samples. When moving, averaging made some video modes look worse and only made mode9 look markedly better.
I have a new version for the ARM in the wings I am going to try that may be able to make Mode9 look OK without the extra expense of the CPLD. Im not a very good ARM programmer so this is taking some time
Re: Uzebox Micro Handheld
Obviously you are going to be busy for a while fulfilling all the Kickstarter orders for the successful UzeDTV. Are you still thinking you will have the (significant, no doubt) time to bring this one to life in the future? Probably obnoxious for me to even ask at the moment, but I just want to have the dream of a future portable, alive once again!