reasons for the existing (weird?) screen modes

[nitrofurano]

From since early 80's i'm curious about all 8bit computers, and the screen modes available from there.

And from other side, i saw the information from http://uzebox.org/wiki/index.php?title=Video_Modes , which screen modes i saw as weird when compared with those 8bit and 16bit computers and consoles from 80's and 90's

Seeing that from 60hz displays (ntsc,brazilian pal-m, etc.) we have 720x480, and 720x576 on 50hz (pal-b/g, secam, etc.), which can mean as unlaced, 360x240 or 360x288 (when used display modes like taking 320x200, 320x256, 320x224, etc., from them - like C64, Atari 400/800, Atari-ST, Megadrive, etc.), or 270x240 or 270x288 (using 256x192, 256x224, 256x240, 256x256 - like MSX, Colecovision, MasterSystem, NES, SNES, etc.), or 180x240 or 180x288 (like 160x200, etc., from c64, vic20, Atari2600, etc.) - these width resolutions from Uzebox which doesn't fit on the usual 320, 256 or 160, like those 240 (from 270?), 144 (from 180?), 288 (from 360?), 170 (from 180?), 120 (from 135? (270/2) ), 360 (from 360?), or seems to provide large side borders

Do these screen mode resolutions are inside Atmega somehow, and impossible to change, or they are just the default ones, and can it be more flexible (just like Amiga screen modes)? What is the logic behind these screen modes, justifying them being just like that?

[nitrofurano]

btw, as far i'm reading http://uzebox.org/wiki/index.php?title=Video_Mode_9 and some kernel video modes in assembly, if 1 pixel per cycle could be possible, we could have a resolution like 1440x240 (or 1440x288), and so we have 720x with (theoretically) 2 cycles, 480x with 3, 360x with 4, 288x with 5, 240x with 6, around 205x with 7 and 180x with 8

(i asked the question above because there are no explanations about it at http://uzebox.org/wiki/index.php?title=Video_Modes - i had no idea the code should blit the video as well, in realtime )

and how many ram memory do we have available for display on Uzebox? i'm seeing that, if we have 256 8x8 blocks, taking 64bytes each, we can get 16kb, how far can be saved if we use attribute clashes like from zx-spectrum, c64 (hires), msx1/colecovision, etc., and how far can a kernel videomode be efficient on it?

[D3thAdd3r]

If you want to understand you have to look at the asm code for whatever videomode you're curious on. The interesting part is there really is no dedicated video chips for Uzebox which all the mentioned systems do have. The software is the missing hardware. This means main processing unit does ALL work to output screen pixels(using carefully timed assembly code). Mode 9 represents the highest tile based horizontal resolution because work must be done in the short time between pixels, no chips help out. Also keep in mind uzebox has 4k ram total..for everything video,sound,etc. Computers from the 80s are very different in some respects so some comparisons are not valid.

[nitrofurano]

yes, i were a bit slow on understanding that Uzebox has something like "1 byte of video memory" - it looks a bit like Atari2600 games using only less than 32 registers for display - the difference seems, while Atari2600 code seems to update display info in each line, Uzebox does this in each pixel...

this happened mostly because information http://uzebox.org/wiki/index.php?title=Video_Modes seems mistake inductive - newbies like me struggle a lot when trying to understand how it works finding as first information like this

otherwise, it's really great that anyone can code their own screenmode (like using tiles in sizes like 4x8, 6x6, etc., or even some more tricky stuff going beyond merelly tiles or sprites - i'm really curious for seeing what people like from demoscenes can do with hardware like this! ), only depending on how skilled the coder is in Atmega assembly - this is really interesting!

[uze6666]

As Lee's mentioned the Atmega does everything in real time, including pixel-per-pixel video rendering. As you correctly pointed out, the cycles per pixels with define the final resolution. And the reference is indeed 1440 horizontal pixels = 1 cycle. However rendering needs time to compute next tile adresses as it renders, this in turns requires many cycles. Hence the relatively low resolutions. More you want to do (i.e: palette-based mode), lower will be the resolution.

I agree the wiki is not very good right now at explaining these things. But being what it is, it's open to everyone to contribute a little bit more now and then. I will consider adding a bit more on this front soon.

-Uze

[D3thAdd3r]

Thanks for pointing out the problems that can be had by those just getting into Uzebox video modes. Surely many new members have had this same hurdle with the documentation. I have attempted to provide some information that will help others understand in the future, under the Help,Tips,&Tutorials section of the wiki. The page can be found herehttp://uzebox.org/wiki/index.php?title=How_Video_Modes_Work. Hope this helps, I'm not an expert on the subject, but have pieced together a reasonable abstract understanding of it all...starting from the initial point of confusion. Might be an advantage when writing "in between" type documentation Let me know anything that doesn't make sense or any points you would like to see covered.

[nitrofurano]

thanks to both Uze and Lee - recently i added this information http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Uzebox at Boriel's Basic Cross Compiler wiki page (hoping that someone(s) can help extending this wonderful (really wonderful, imho) cross-compiler to Atmega/Uzebox as well ) - i just didn't add info about audio because i couldn't understand exactly how it works (i only know those beepers from zx-spectrum and alike, and sound processors like AY-3-8910, SID, etc.)