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 ?
9 BIT RESOLUTION PER COLOR
9 BIT RESOLUTION PER COLOR
- Attachments
-
- 9BIT VIDEO PORT.JPG (42.49 KiB) Viewed 12026 times
Re: 9 BIT RESOLUTION PER COLOR
SORRY THE VALUE OF THE RESISTOR ARE NOT CALCULATED YET
Re: 9 BIT RESOLUTION PER COLOR
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).
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).
Re: 9 BIT RESOLUTION PER COLOR
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 .
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 .
Re: 9 BIT RESOLUTION PER COLOR
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.
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.
Re: 9 BIT RESOLUTION PER COLOR
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 ?
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
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 )
than you
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 ?
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
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 )
than you
Re: 9 BIT RESOLUTION PER COLOR
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.
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.
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.
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.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
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 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.
Re: 9 BIT RESOLUTION PER COLOR
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
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 (46.04 KiB) Viewed 11959 times
Re: 9 BIT RESOLUTION PER COLOR
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
are you ready to go ?
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
are you ready to go ?
Re: 9 BIT RESOLUTION PER COLOR
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
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 (163.72 KiB) Viewed 11918 times