Uzebox Micro Handheld

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
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 concur with the others, great progress looks great!

Edit - I forgot to ask how the "Watch" part will work. A dedicated Uzebox rom or somehow with your display processor doing the work if idle too long or turned off?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

Jubatian,

No special code running on the main Mega644. There is a 2ND (Mega644) CPU that reads button inputs, sets up the LCD, and controls timing to the Uzebox Mega644 that is just running stock code. It was done that way so it is 100% binary compatible.

The next itteration the 2nd "housekeeping" CPU is going to be replaced with a 32bit ARM because it is cheaper than a Mega644. Also going to add a $2 FPGA so that it can interpolate the 3:3:2 RGB up to 5:5:5. I've already simulated this. Some games like Tornado2000 look better with centre weighted averages, some look better with linear. So user selectable.

The other nice thing the ARM will be able to do is up-sample the audio to ease the job of the audio filter.

D3thAdd3r,

The Watch part is going to be in the 2nd house keeping CPU. When you dump it into the charging cradle (or plug in a usb cable to charge) it will bring up a clock unless you tell it not too.

Edit: Jubatian, Yes the funny screen position is my code running on the 2nd Mega644 to detect VSync and start the pixel stream is a bit off.
I am about to order an ESP-12E to size up if I can fit one into the case.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

Sorry about the lighting. My little camera has no manual exposure mode on movies as far as I can work out.

https://youtu.be/b8imNGf5L6A
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

Colours are not quite right. It is lacking greens I think. That's OK. The LCD has a CLUT for adjusting individual channels.
P1010382.jpg
P1010382.jpg (98.77 KiB) Viewed 11998 times
It really looks awesome on anything but mode-9. I don't think any of the cheap/easy LCDs would cope with a 480 pixel screen though.

Uze - You can confirm that your 3.5" LCD was not usable with mode 9 ?
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox Micro Handheld

Post by Jubatian »

OK, I understand, so there is a small "GPU" there which still needed some tweaks. I thought you did something of "dumb" hardware to get the signal across (although kind of wondering how you would produce proper square pixel clock for the LCD then).

Anything with 4 cycles / pixel or less (so Mode 9 involved with 3cy / pixel) would have pixels lost. The situation is rather similar to my graphics hacks to the Uzebox emulator which I did because I wasn't content with the nearest interpolation it used (which also more or less destroys Mode 9's look). The solution is also the same: blend the pixels horizontally, producing an effect like if it was an old beamer. It looks nice and it works well for those high-res games. A good FPGA solution for this using low bit-width adds and shifts of the components only might be possible.

(I will do a proof of concept hack on the emu to show what I mean a bit later)
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

I've already simulated on hardware by running the clock for the main CPU as a slave from the "GPU" (Equated to a about 500Khz Uzebox or games that run at 1 frame per second)

Run the sampler at 2x pixel clock - which gives 9 sample clocks per LCD pixel (1440/320 * 2)

Take an 8 bit sample (BBGGGRRR) and break it into 3 values BB, GGG and RRR

Sum the 9x3 samples after multiply each in order by 1,2,2,2,2,2,2,2,1 (The edge samples are 1/2 weight)

Divide the values by 4 - and use the resulting 5 bit value for the for the LCD (in 15/16 colour mode).

In reality it would be more sensible to not double the pixel clock and make alternate 4 or 5 sample clock periods. For the simulation it was easier for me to just 1/2 the CPU clock and run a simple loop on the "GPU"

Sadly didn't think of getting any photos when I had that set up running. I did note that the thin lines in Tornado looked better with a higher value of centre weighting than the above example. Most things that where not thin lines on a black background looked better with the almost flat weighting described above.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox Micro Handheld

Post by D3thAdd3r »

With such flexibility you could really do a lot for user preference. Obviously that is a lot of work that could happen later, but a really nice aspect of the RGB method.

That I recall on the same model screen as Alec, ultra high res mode was generally readable and about as blurry(quite) as you would expect. I would say for most people it would be considered usable for text. Probably no worse than retro handhelds like Sega Nomad.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox Micro Handheld

Post by Jubatian »

I completed the proof-of-concept. The hacked emulator is here on GitHub, note that it has a few bugs whose fixes I didn't care to merge in, but just about everything works all right in it, so you can give it a go to see how things might look like through such a smoothing algorithm I described. The interesting bits are here, the rendersupp_line32() function.

Some example images follow captured from this build:
Megatris through the 320x240 LCD filter.
Megatris through the 320x240 LCD filter.
320x240_LCD_proofofconcept_Megatris.png (24.05 KiB) Viewed 11941 times
Mode 9 demo through the 320x240 LCD filter.
Mode 9 demo through the 320x240 LCD filter.
320x240_LCD_proofofconcept_Mode9.png (7.99 KiB) Viewed 11942 times
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox Micro Handheld

Post by CunningFellow »

Jubatian,

Thanks for that. Mode 9 looks just like it did on the LCD screen with the 122222221 sampling I did.

A question. How are you coming up with the number 4.66667 cycles per pixel.

I took it as 1440 active UZE video clocks divided by 320 LCD pixels = 4.5 (which became 4.5*2 = 9)

Today I am looking more closely at what I am going to try use FPGA wise, I think a Lattice ice40 is the go for price. I will just have to learn a new tool because the Xilinx ones I am used too are too expensive for this application.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox Micro Handheld

Post by Jubatian »

CunningFellow wrote:A question. How are you coming up with the number 4.66667 cycles per pixel.
There are several sources for this conclusion.

First I found this fine article on the Commodore 64's display generation, from which this can be derived exactly (if you compare the clocks, the NTSC C64's HiRes pixel clock will turn out to be 3.5 Uzebox cycles).

The CGA 320x200 mode is regarded to have 1:1.2 PAR, this also displays on television (the CGA had composite out). The same Motorola 6845 was used in Amstrad CPC as well. The timing is such that one CGA pixel equals 4 uzebox cycles, or 2 CGA pixels equal one colorburst tick (this is why NTSC color hackery was possible on these cards!). By this, 4.8 Uzebox cycles would make a square pixel.

The VGA 640x480 standard is NTSC turned into progressive by doubling the line frequency. Its pixel frequency is 25.175 MHz for square pixels. If you "downgrade" it to 320x240 (so back to normal NTSC, 320 pixels width for square pixels with progressive scan), you get 6.294 MHz. This might be familiar from some landscape QVGA panels. Uzebox's maximal theoretical "pixel clock" is 28.636MHz (NTSC colorburst * 8). From this, you get 4.55 Uzebox cycles for a square pixel.

By these it seems like going for 4.66667 would be the closest to the truth, and it is also easy to generate. Of course old beamers could vary in their pixel aspect ratio, so anything between 4.5 and 4.8 should do for an okay looking picture.

Your solution for the thing would get the crispest result with some minor quirks in output strengths as the input Uzebox pixel slides over the output pixels. I would rather suggest 1,2,2,2,1,2,2,2,2 for the multipliers. Here are some comparisonts for output strengths as the 3 * 2 = 6 clocks wide Ultra HiRes pixel is slid across the 9 clock wide pixels:

Code: Select all

The 1,2,2,2,2,2,2,2,1 layout:
  3cy / px               4cy / px                5cy / px
  0: 1,2,2,2,2,2 => 11   1,2,2,2,2,2,2,2 => 15   1,2,2,2,2,2,2,2,1,1 => 17
  1: 2,2,2,2,2,2 => 12   2,2,2,2,2,2,2,1 => 15   2,2,2,2,2,2,2,1,1,2 => 18
  2: 2,2,2,2,2,2 => 12   2,2,2,2,2,2,1,1 => 14   2,2,2,2,2,2,1,1,2,2 => 18
  3: 2,2,2,2,2,1 => 11   2,2,2,2,2,1,1,2 => 14   2,2,2,2,2,1,1,2,2,2 => 18
  4: 2,2,2,2,1,1 => 10   2,2,2,2,1,1,2,2 => 14   2,2,2,2,1,1,2,2,2,2 => 18
  5: 2,2,2,1,1,2 => 10   2,2,2,1,1,2,2,2 => 14   2,2,2,1,1,2,2,2,2,2 => 18
  6: 2,2,1,1,2,2 => 10   2,2,1,1,2,2,2,2 => 14   2,2,1,1,2,2,2,2,2,2 => 18
  7: 2,1,1,2,2,2 => 10   2,1,1,2,2,2,2,2 => 14   2,1,1,2,2,2,2,2,2,2 => 18
  8: 1,1,2,2,2,2 => 10   1,1,2,2,2,2,2,2 => 14   1,1,2,2,2,2,2,2,2,1 => 17

The 1,2,2,2,1,2,2,2,2 layout:
  3cy / px               4cy / px                5cy / px
  0: 1,2,2,2,1,2 => 10   1,2,2,2,1,2,2,2 => 14   1,2,2,2,1,2,2,2,2,1 => 17
  1: 2,2,2,1,2,2 => 11   2,2,2,1,2,2,2,2 => 15   2,2,2,1,2,2,2,2,1,2 => 18
  2: 2,2,1,2,2,2 => 11   2,2,1,2,2,2,2,1 => 14   2,2,1,2,2,2,2,1,2,2 => 18
  3: 2,1,2,2,2,2 => 11   2,1,2,2,2,2,1,2 => 14   2,1,2,2,2,2,1,2,2,2 => 18
  4: 1,2,2,2,2,1 => 10   1,2,2,2,2,1,2,2 => 14   1,2,2,2,2,1,2,2,2,1 => 17
  5: 2,2,2,2,1,2 => 11   2,2,2,2,1,2,2,2 => 15   2,2,2,2,1,2,2,2,1,2 => 18
  6: 2,2,2,1,2,2 => 11   2,2,2,1,2,2,2,1 => 14   2,2,2,1,2,2,2,1,2,2 => 18
  7: 2,2,1,2,2,2 => 11   2,2,1,2,2,2,1,2 => 14   2,2,1,2,2,2,1,2,2,2 => 18
  8: 2,1,2,2,2,1 => 10   2,1,2,2,2,1,2,2 => 14   2,1,2,2,2,1,2,2,2,2 => 18
So this would make the output strengths more consistent and differences more evenly spaced out, most noticable for the HiRes mode, but slightly so for every other.

My solution has an interesting property that it can reduce crispness, giving a look and feel somewhat resembling to an old beamer. Using 8 for FIFO_SIZE seems to give the most pleasant result (with something easy to implement, not needing division), blurring columns together somewhat, washing out the pixel boundaries of the panel. You may try 16, it would make things appear like watched on some old mini television (apart from the absence of NTSC color quirks).
Post Reply