9 BIT RESOLUTION PER COLOR

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
nono34
Posts: 24
Joined: Mon Jun 04, 2018 9:56 am

9 BIT RESOLUTION PER COLOR

Post by nono34 » Sun Nov 04, 2018 11:02 am

HELLO
I THINK THAT IT IS POSSIBLE TO GET 9 BIT RESOLUTION ON TWO PORT PIN
IN EFFECT THE PORT OF THE AVR GOT A HIGH LEVEL A LOW LEVEL AND A "TRISTATE" INPUT PIN IF THE TRISTATE IS FIXED WITH RESISTOR DIVIDER
I THINK IT CAN BE POSSIBLE TO GET 3 LEVEL STATE FOR EACH PIN OF THE AVR

TAKE A LOOK AT FOLLOWING SCHEMATIC
THE VALUE OF THE RESISTOR ARE CALCULATED YET

WHAT DO YOU THINK ABOUT ? :D :roll:
Attachments
9BIT VIDEO PORT.JPG
9BIT VIDEO PORT.JPG (42.49 KiB) Viewed 2289 times

nono34
Posts: 24
Joined: Mon Jun 04, 2018 9:56 am

Re: 9 BIT RESOLUTION PER COLOR

Post by nono34 » Sun Nov 04, 2018 11:04 am

SORRY THE VALUE OF THE RESISTOR ARE NOT CALCULATED YET

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: 9 BIT RESOLUTION PER COLOR

Post by Jubatian » Sun Nov 04, 2018 8:35 pm

I don't think Uzebox's main problem is low color count, you can actually do neat colorful stuff with it, even gradients if you put some thought at it. For example my Lisunov Li-2 demo for Mode 52 (scroll down for the finished demo) has a sky, and also Flight of a Dragon also does it in a real game, just for how gradients can be tricked. Otherwise many of us pulled off really nice looking games.

The main problem is creating the video frame code which produces these colors. Going above 8 bits is not really possible as you can not write more than 8 digital outputs in one operation, so you can't switch from one color to another without a visible transition on the display (this transition could of course be minimized to 1 cycle, which is barely noticeable). If you use the tri-state option, that also means two port writes to get the color you need: you would have to set the direction and the port values.

Tri-stating also has an use in the current system: a cheap fading, the only possible way to fade in and out when using a 8 bit video mode (the most common Mode 3).

nono34
Posts: 24
Joined: Mon Jun 04, 2018 9:56 am

Re: 9 BIT RESOLUTION PER COLOR

Post by nono34 » Mon Nov 05, 2018 1:40 am

HI jubatian
nice plane demo

notice that this schematic is for one color it as to be repeater for other color

yes for this mode you have to use the data direction register before send the color byte

if effect the color must be coded in two byte for all tree colors but you will have at least near 24 BIT COLORS table

the trick is to see if the time for adressing the ddr register is one cycle or more i think it is faster than output port reaction , to be confirmed.

and of course it depend also on how many cycle clock are "free " between each pixels or " port adressing"

nevertheless it is sure that data storage will be multiplicated by two .

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: 9 BIT RESOLUTION PER COLOR

Post by Jubatian » Mon Nov 05, 2018 8:39 pm

Thank you!

It wouldn't necessarily increase data storage requirements if you created paletted modes. However another big problem here is the time it takes to calculate a pixel. In the most common Mode 3 (by the older kernel) this is 6 cycles, allowing for 240 pixels horizontally (pixels are not square, they are "fat"). To get a square pixels mode, you would have to output a pixel every 5 cycles, or even better, alternating between 4 and 5 cycles. Loading a pixel value from the code memory takes 3 cycles (an LPM instruction), outputting it takes 1, and of course somewhere you have to calculate addresses for tiles. Many modes get around this somewhat by various tricks, but creating a nice useful video mode is an art of its own.

So before making hardware, you should possibly make some sketch on how you plan to actually realize a video mode for it, whether it is viable at all.

nono34
Posts: 24
Joined: Mon Jun 04, 2018 9:56 am

Re: 9 BIT RESOLUTION PER COLOR

Post by nono34 » Wed Nov 07, 2018 7:10 am

OK
BUT unfortunatly i am not operational at all
not with avrstudio and not with the scketchs

i have just flash an atmega644 WITH ARKANOID. IT WORK ok with oscillator ttl at 28mhz and also with ttl oscillator at 32mhz (screen is shifted but a 3/4 of the screen is visible correctly) and stable

but i good some idea



1) do you use interleaved video mode ? :shock:
if yes the odd line are see instead of the even line are black and it is the oposite at the next picture

2) do you think that it is possible to interleave even and odd pixels ? on the same line :roll:
if you have the first pixel on and the second off you will have near the double of time for treat each pixels
and you have just to shift by one the pixel to be display for made the interleaving mode.

3) may be you can mix the 1 and 2

4) do you think you can make sketchs for that idee (you will have finish before i get ready to start :lol: )

than you

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: 9 BIT RESOLUTION PER COLOR

Post by Jubatian » Wed Nov 07, 2018 9:59 am

nono34 wrote:
Wed Nov 07, 2018 7:10 am
OK
BUT unfortunatly i am not operational at all
not with avrstudio and not with the scketchs
You don't necessarily need a development environment for this, just examine whether whatever you have in mind could possibly be realized. It means mostly figuring out how would you generate the pixels for the display, for example a simple tile generation loop can be found in Mode 1: videoMode1.s, line 180 - 222, producing one pixel every 6 clocks, resulting in the up to 240 pixels horizontal resolution.
nono34 wrote:
Wed Nov 07, 2018 7:10 am
i have just flash an atmega644 WITH ARKANOID. IT WORK ok with oscillator ttl at 28mhz and also with ttl oscillator at 32mhz (screen is shifted but a 3/4 of the screen is visible correctly) and stable
Guess you have SCART then, as TVs probably wouldn't like NTSC with a frequency shifted up by about 10%. For SCART RGB they may care less, just syncing to whatever comes.
nono34 wrote:
Wed Nov 07, 2018 7:10 am
1) do you use interleaved video mode ? :shock:
if yes the odd line are see instead of the even line are black and it is the oposite at the next picture
No, that would give up to 448 lines vertical resolution. Uzebox uses progressive scan like most of the eight-bitters of the 80's, on an old CRT TV set, you would see the faint scanlines.
nono34 wrote:
Wed Nov 07, 2018 7:10 am
2) do you think that it is possible to interleave even and odd pixels ? on the same line :roll:
if you have the first pixel on and the second off you will have near the double of time for treat each pixels
and you have just to shift by one the pixel to be display for made the interleaving mode.
On Commodore 64 this technique is called MCI mode, you can read some about it on this summary site. It would be possible to do this on the Uzebox, but it may be not that good for games.

On the Uzebox, you could also blank out the pixels you don't intend to render in the current frame (costs only 1 cycle), the overall end result then would be a stable, but darker image, and such a mode would be just fine for games (no color blending tricks). I don't know whether NTSC color encoding would interfere this case: it may not as black pixels are indifferent to chroma (luminance is zero), but the AD725 may still mess around with the color carrier signal. On SCART, it would look nice. Such a mode would also be a little difficult to emulate correctly as it would either flicker or would require costly gamma aware blending (which CUzeBox doesn't have), although without gamma awareness the result would only be darker than the real thing, not messing up color.

But in overall this is actually a spiffy idea which could be pulled off! Especially if the AD725 turns out to work with it all right.

nono34
Posts: 24
Joined: Mon Jun 04, 2018 9:56 am

Re: 9 BIT RESOLUTION PER COLOR

Post by nono34 » Wed Nov 07, 2018 10:46 am

HI
Yes i got a scart tv

here another idea for avoid the CPU to send dummy pixel one onto two
a integrated ic the 7474 synchronysed on the clock can clear automaticly a pixel onto two "in fact it divide the clock by two"
a clear pin permit to control the starting dividing
like this just a control signal on the clear at the begining of the line allow to clear let pixel one or let pixel two

the transistor short circuit the analog signal one time onto two

like this the the cpu will have about 12 CYCLE CLOCK FOR A PIXEL
Attachments
CLOCK644.JPG
CLOCK644.JPG (46.04 KiB) Viewed 2222 times

nono34
Posts: 24
Joined: Mon Jun 04, 2018 9:56 am

Re: 9 BIT RESOLUTION PER COLOR

Post by nono34 » Thu Nov 08, 2018 2:48 am

HI JUBATIAN
By the way this idea is for a picture at 25 frame per second
in the same logic at 50 frame per second you can display a pixel onto 4 let allow the cpu to get 6x4=24 cycle for compute a pixel
what do you think about

of course another external circuit schematic must be done for reset 3 pixel onto 4 for allow the cpu to be free :lol:


are you ready to go ?

nono34
Posts: 24
Joined: Mon Jun 04, 2018 9:56 am

Re: 9 BIT RESOLUTION PER COLOR

Post by nono34 » Fri Nov 09, 2018 7:08 am

HERE IS THE IMPROVED COLOR SYSTEM AT TREE WIRES
UP TO X^Y LET 3^3=27 (TREE WIRE AT TRI STATE) LET 28 POSSIBILITY INCLUDING THE 0
THE DIVIDER GOT 100 OHM BUT MY BE OTHER VALUE WILL WORK TO

HAVE FUN
Attachments
IMPROVED COLOR.JPG
IMPROVED COLOR.JPG (163.72 KiB) Viewed 2181 times

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests