Uzebox Micro Handheld

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

OK - I get your 4.6667 now.

I was aiming for maximum LCD fill (no borders or overscan) with 320 pixels and 1440 active vid-clocks. I was not worrying about squareness of pixels or anything like that.

I am aiming for putting the LCD V-Filter into a CPLD now to make the power supplies easier. This probably rules out the moving window filter as you proposed and I will def have to do the fixed-slot-average filter. I may make the width of the slots variable so as to be able to create more "fuzz" as a user selectable option.

I am currently trying to find all my programmable logic dev boards so I can give it a go real time.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox Micro Handheld

Post by Jubatian »

Stretching the display a bit for that purpose I think is reasonable, the LCD is tiny, and that few percents isn't anything much noticable while the viewable area becomes larger. The minor risk there is that how one might center the 1440 cycle wide video mode (in the AVR software), which then easier ends up partially off-screen (although on my TV Mode 3 stuff is also partially off-screen without any way to fix that, it seems like 1440 cycles really stretches the limits). It is however possible to guide developers into fitting the LCD if they use the emulator which provides guidance in this regard by its own visible area.

How that fixed slot filter works by the way? I would assume it added up samples "on the fly", but then you would require two such filters running in parallel to fuzz pixel boundaries horizontally (since an input sample belongs to two output pixels, or even more with more extreme fuzzing).

Not that it is critical (tiny LCD, already way better than nearest), just that I find some horizontal fuzzing pleasant with these.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

Jubatian wrote:Stretching the display a bit for that purpose I think is reasonable, the LCD is tiny, and that few percents isn't anything much noticable while the viewable area becomes larger. The minor risk there is that how one might center the 1440 cycle wide video mode (in the AVR software), which then easier ends up partially off-screen (although on my TV Mode 3 stuff is also partially off-screen without any way to fix that, it seems like 1440 cycles really stretches the limits). It is however possible to guide developers into fitting the LCD if they use the emulator which provides guidance in this regard by its own visible area.
The timing is going to be under control of the "GPU" so it could be a user selected thing for screen width 4-5-4-5 or 5-4-5 - also the start time for left right position.

The Volume control is also going to be done in software by the 2nd CPU as is the button presses and therefore software re-mapping. As many things as I can keep customizable for user prefs in the 2nd CPU as possible.
Jubatian wrote:How that fixed slot filter works by the way? I would assume it added up samples "on the fly", but then you would require two such filters running in parallel to fuzz pixel boundaries horizontally (since an input sample belongs to two output pixels, or even more with more extreme fuzzing).

Not that it is critical (tiny LCD, already way better than nearest), just that I find some horizontal fuzzing pleasant with these.
CPLDs have more limited storage (register) type resources than FPGAs. So if I only only sample 4/5 times and for "fuzzing" only one of them is outside the current sample, then I can simply add most of the values rather than remembering them (a FIFO) . The first CPLD I have in "stock" here has 36 macrocells. That is effectively only 36 "bits" of data it can hold. 5x 8 bit samples would not even fit without looking at output bits. Where as if I only "hold" one 8 bit sample from the previous pixel time for fuzzing. and have 15 bits of 5R-5G-5B for output that is only 23 bits used.

If I find I cant do it in a 72 macrocell CPLD then I am better off price wise to go with the FPGA and deal with the hassle of 2 extra power supply rails.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

I just got some ESP-12E things in stock. I reckon I should have not problem fitting them inside the Uze and Watch.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox Micro Handheld

Post by D3thAdd3r »

I am definitely looking forward to seeing the finalized PCB on this machine.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

How important do people think having the 80 column screen is ?

It looks like it is either going to add $20 to the final cost OR halve the battery life to 6ish hours.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox Micro Handheld

Post by Jubatian »

What exactly do you mean with this? An LCD with higher resolution? I don't think it is necessary at this size, you won't be playing it under a microscope :) If the CPLD can do any kind of interpolation to get it look better than nearest on the 320 pixels horizontal resolution, it is all fine (even with 4.5 uzebox cycles for a pixel, what I wrote are just for theories on which direction the I think best look could be found). The "stock" Uzebox producing NTSC output is neither truly capable to get Mode 9 right since the colorburst is 8 Uzebox cycles, so tight patterns would end up faking hues. Things looking good from Mode 9 over NTSC would also look right on the interpolated LCD. 80 text columns is something which I think just shouldn't be done over NTSC (the reasonable readable maximum I think would be 60 columns, using 8 pixel wide tiles in Mode 9, where you can design a charset to have 2 pixels wide lines, using the extra resolution to make slanted lines clearer).
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

Same resolution LCD. But the CPLD solution which I have just made (using the same fuzzing scheme I first tested) pulls 50mA which almost doubles the current consumption.

Going to a more modern CPLD than the XC95xx(XL) or going to an FPGA will add $10 to $20 extra in parts at the small scale not just from the cost of the FPGA but due to power supplies and level translation.

The CPLD result looks as readable as your FIFO demo you showed pictures of. A human can make out what the words are meant to be, but the pixels are blurry. As you pointed out - no worse than NTSC would be.

But if mode9 is not really needed then I can just drop the CPLD and do "nearest pixel" and save all those mA.

I am not feeling very chipper at the moment and will probably not be on the forums for the next week or so.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox Micro Handheld

Post by Jubatian »

No problem. For me it feels okay with nearest, at least I think battery life is more important here while quality is acceptable. Were there any important 4 cycle / pixel games by the way? (It would also be important for those since that also loses pixels with nearest). For now it seems like only Mode 9 would be affected, UzeSnakes uses it, and there are no other released video modes at 3 or 4 cycles / pixel. Just my opinion on the problem.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

I am part way through building the next hardware spin that has the CPLD running the LCD, but can be switched to "Dumb" mode with nearest pixel.

I will then be able to evaluate if the extra mA is worth it by showing people the video modes real speed.
Post Reply