** New Frontiers in VIC-Hires-Graphics, Part 13

[tokra]

While developing all those graphic-modes, sometimes I took a step back and thought about how I would implement some of the older modes with the new knowledge or what could be achieved instead with the new knowledge. I'll pop up with some ideas here now and then (hopefully).

Let's start with a new PAL-mode:

If you followed the series you may remember the struggle to reach 208x256 on PAL and how after using the zero-page I was able to get to 208x272 even. The MFLI-demo later used the stack (page 1) as well and made it possible to have different background-, border- and auxiliary-colors on every rasterline of a 208x256 picture. But the initial goal to find the maximum displayable resolution somehow got lost. Most display devices can't show more than 208x256 anyway, but there are some that can be adjusted like the Commodore 1084 (which I use) or Boray's Philips monitor so that up to 224x280 is visible. This is the maximum PAL-resolution for VICE as well.

How close can we get with a hires-mode to that maximum resolution? My current idea would allow for up to 224x272 with 8x8 chars, leaving just one character-line. Here's the lowdown:

28x34 chars = 952 bytes video-RAM ($1000-$13b7)
16 non-dynamic areas of 224 x 8 ($13b8-$1ff7 and $0200-$03bf)
2 dynamic areas of 224 x 8 ($01ff-$0040)
leading to the following layout:

Code: Select all

L01 D0
L02 D1 Upd D0
L03 1  Upd D0
L04 D0 Upd D1
L05 2  Upd D1
L06 D1 Upd D0
L07 3  Upd D0
L08 D0 Upd D1
L09 4  Upd D1
L10 D1 Upd D0
L11 5  Upd D0
L12 D0 Upd D1
L13 6  Upd D1
L14 D1 Upd D0
L15 7  Upd D0
L16 D0 Upd D1
L17 8  Upd D1
L18 D1 Upd D0
L19 9  Upd D0
L20 D0 Upd D1
L21 10 Upd D1
L22 D1 Upd D0
L23 11 Upd D0
L24 D0 Upd D1
L25 12 Upd D1
L26 D1 Upd D0
L27 13 Upd D0
L28 D0 Upd D1
L29 14 Upd D1
L30 D1 Upd D0
L31 15 Upd D0
L32 D0 Upd D1
L33 16 Upd D1
L34 D1 Upd D0
 35    Upd D0
 36    Upd D1
 37    Upd D1
 38
 39

L01-L34 are being displayed. L35-L39 are the blank area of the 312 PAL-raster lines. For every 16 rasterlines you can update one of the dynamic areas.

16 rasterlines x 71 cycles per line = 1136 cycles
224 bytes being updated = 1120 cycles with stack/zeropage addressing
Setting the $9004-register every 8 rasterlines = 12 cycles.
This leaves just 4 cycles per 16-rasterline block unused. So this would fit very nicely.

224x272 = 60928 pixels = 95.2% of the C64-standard-hires-resolution (320x200).

Ideas for 224x280 are welcome. This would be 98% of C64 res. I've tried some calculations with 8x16 chars, but these go nowhere since you can't fit two of those 448 byte-areas in the zeropage/stack and you need to be able to do updates all the time the picture is displayed.

[Mike]

I was just pondering about the theoretical maximum limit, when the method remains unchanged, i.e. the range $0000 .. $01FF is dynamically updated with 5 cycles/byte.

You can do 71*312/5 ~= 4430 writes per frame (excluding VIC register updates).

N bytes bitmap require another N/8 bytes for the address generator (which would have to go into the upper 4K of VRAM). The static VRAM goes from $0200 to $03FF and $1000 to $1FFF.

N+N/8=4430+4608 <=> 9*N/8=9038 <=> N~=8033

That are 64264 pixels.

Two ideas:

- update of a dynamic area in the ZP could already begin when its first line has been displayed (you'd then update the bitmap with a 8 byte interleave),

- maybe you could switch screen base and/or character base more often, after each half of a line, and use the other half further down. Maybe that allows for some extra time in the updates, even if it possibly requires some extra text RAM.

[tokra]

Two ideas:

- update of a dynamic area in the ZP could already begin when its first line has been displayed (you'd then update the bitmap with a 8 byte interleave),

This would only work for the zeropage, not for the stack though, and the total number of bytes to be updated would remain the same.

- maybe you could switch screen base and/or character base more often, after each half of a line, and use the other half further down. Maybe that allows for some extra time in the updates, even if it possibly requires some extra text RAM.

Hmm. RAM is very tight anyways, I'm afraid this would add more troubles than solving.

But when I read your post yesterday another idea popped into my head: The lower 1K still has 128 bytes unused (since the 2 dynamic areas from $0040-$1fff and the 2 non-dynamic from $0200-$03bf only take up 896 byte). This leaves only 96 bytes I'd need to update dynamically to gain another character line (128 + 96 = 224). 96 bytes can be updated in one displayed character line (8 * 71 cycles = 568 cycles - updating 96 bytes = 96 * 5 cycles = 480 cycles).

Howver this also increases the needed video-RAM area to 980 bytes (28 x35) - and I still need 14 areas in the upper 4K to have enough areas for the higher resolution. Since 14 x 224 + 980 = 4116 this is just 20 bytes too much to fit. But these should be able to be provided dynamically as well just within the available raster time, leading to the following layout:

Code: Select all

224 x 280 PAL = 960 Chars $1000-$13bf = 14 x 224 byte areas $13c0-$1fff + 2 x 224 byte areas $0200-$03bf = 16 non-dynamic areas
                20 Chars dynamic $13c0-$13d3

D1 = $0120-$01ff
D0 = $0040-$011f
D2a = $0000-$003f (non-dynamic 64 bytes)
D2b = $03c0-$03ff (non-dynamic 64 bytes)
D2c = $0040-$009f (dynamic 96 bytes)

L01 D0 Upd D1
L02 D1 Upd D0
L03 1  Upd D0 (area 1 = $13c0-$149f with $13c0-$13d3 copied from $2000-$2013)
L04 D0 Upd D1
L05 2  Upd D1
L06 D1 Upd D0
L07 3  Upd D0
L08 D0 Upd D1
L09 4  Upd D1
L10 D1 Upd D0
L11 5  Upd D0
L12 D0 Upd D1
L13 6  Upd D1
L14 D1 Upd D0
L15 7  Upd D0
L16 D0 Upd D1
L17 8  Upd D1
L18 D1 Upd D0
L19 9  Upd D0
L20 D0 Upd D1
L21 10 Upd D1  update $13c0
L22 D1 Upd D0
L23 11 Upd D0  update $13c1
L24 D0 Upd D1
L25 12 Upd D1  update $13c2
L26 D1 Upd D0
L27 13 Upd D0  update $13c3
L28 D0 Upd D1
L29 14 Upd D1  update $13c4
L30 D1 Upd D0
L31 15 Upd D0  update $13c5
L32 D0 Upd D1
L33 16 Upd D1  update $13c6
L34 D1 Upd D2c (96 x 5 cycles -> 480 cycles + switch $9004 6 cycles + 13 bytes video-RAM update ($13c7-13d3) 6 cycles each = 564 cycles)
L35 D2 
 36    restore $13c0-$13d3 of area 1 (= 20 * 8 cycles)
 37    Upd D0
 38    Upd D0
 39    Upd D1

L35 is the new character line which consists in itself of two non-dynamic 64 byte areas and one dynamic 96-byte area. The video-RAM is updated just before it's being displayed and those 20 bytes need to be restored in the non-visible 36th line to provide the data when area 1 (L03) is being displayed. You might wonder why $13c0-$13c6 video-RAM updates are so interspersed in the other areas, but this is the only way to fit these. Those areas have 1136 cycles (16 x 71) and need to update 224 bytes (224 x 5) and have two switches for $9005 (8 cycles at least with pre-set x and y-registers). This leaves just 8 cycles in which you can just update a single byte with lda# sta $13c0.

Any objections to my layout? I think this would work for 224x280 on PAL.

[Mike]

Any objections to my layout? I think this would work for 224x280 on PAL.

... should work.

Looks as if I have to prepare a 16-bit version of my line drawing routine.

[tokra]

Another quick idea... this time for the maximum NON-interlaced NTSC-mode. On standard setting NTSC is able to display something like 192x216 (that's what my projector is able to display for example). I've checked with my Commodore 1084-monitor on overscan as well. The maximum resolution is 200x232 there - VICE shows more (up to 256), but I think this is due to incomplete NTSC-emulation. NTSC has just 261 rasterlines and there should be some vertical blank area. Anyway assuming 200x232 is the maximum, the layout is fairly easy:

Code: Select all

200 x 232 = 725 Chars $1200-$12d4   16 x 200 byte areas ($12d8-$1f57) + 4 x 200 byte areas ($00c8-$03e7) = 20 non dynamic areas

L01 D0
L02 1
L03 2
L04 D0
L05 3
L06 4 
L07 D0
L08 5 
L09 6
L10 D0
L11 7
L12 8 
L13 D0
L14 9 
L15 10
L16 D0
L17 11
L18 12
L19 D0
L20 13
L21 14
L22 D0
L23 15
L24 16
L25 D0
L26 17
L27 18
L28 19
L29 20
 30
 31
 32
 33

Just 9 dynamic areas - making this mode fairly low on memory consumption as well.

So, non-interlace hires-graphic-modes are really no big challenge on the NTSC-VIC. Things get interesting when using interlace again. I've crunched the numbers on and off for some weeks now, and think I found the maximum resolution finally. But before I post this idea: What do you think it is?

[Vic20-Ian]

1080p? just with a very very slow refresh

Only kidding, no idea but it is impressive what you have in here.

[darkatx]

You currently had 168x384 but you said that there was a bit of wiggle room in terms of memory.
So I'm thinking that the horizontal is already maxed out but you were able to slap on another line so 168x392?

[Kweepa]

Why bother guessing?
They'll just outdo themselves next month

[darkatx]

Why bother guessing?
They'll just outdo themselves next month

Ain't that the truth...LOL.

By the way, you two may feel your work is under-appreciated but nothing can be further from the truth. Thank-you so much for the great work pushing forward into new frontiers!

[tokra]

Thanks! Much appreciated. Feel free to chip in with ideas anytime. This isn't a closed project.

I've hit a little wall with the mode I thought I had down already. I'm looking to implement a mode that has a maximum number of pixels while still being displayable on most monitors and TVs, without using overscan. Distributing the characters for video-RAM proves to be problematic. Let's see if Mike or myself can find a solution - please stay tuned.

In the meantime just for fun let's check the maximum theoretical number of pixels for NTSC Interlace like Mike caluclated in his post of Apr, 28th:

You can do 65*525/5 ~= 6825 writes per frame (excluding VIC register updates).

N bytes bitmap require another N/8 bytes for the address generator (which would have to go into the upper 4K of VRAM). The static VRAM goes from $0200 to $03FF and $1000 to $1FFF.

N+N/8=6825+4608 <=> 9*N/8=11433<=> N~=10162

That are 81296 pixels.

In PAL we reached 224*280=62720 out of 64264 theoretical = 97.6%

Applying the same ratio for NTSC that would be 79342 pixels. I'm looking for a resolution pretty close to that...

[darkatx]

184 * 432???

[tokra]

I think I've overcome the wall! I was working on a memory-layout for a resolution of 192x416 = 79872 pixels. I've thought about this on and off finding no solution to my character distributing problem that allows me to use just one video-RAM area. I gave up yesterday and formulated a 192x400 mode, but just when I had the memory layout done I realized I don't need a full second video-RAM but just a small part of 48 characters, small enough to fit in the available memory. My initial new memory layout for 192x416 look promising with just 329 cycles out of 34125 of a full interlace picture left. Let's hope it will fit in memory. 32K expansion will be mandatory for this.

[tokra]

This mode (192x416) was demonstrated in the "Retina-Display"-demo at the Nordlicht Party 2012 yesterday and won a shared 1st place in the Wild competition - I really should have voted for myself, I guess

You can find a screenshot, the download-archive and a YouTube-video in the link above.

Anyway, the archive includes the demo with 10 pictures (9 hires, 1 multicolor), the .pgm-converter and the Mandelbrot-program as well. Also included is version of the text2pgm-converter for this resolution (thanks Mike!) and a converted text-screen with a resolution 48x52 4x8 characters.

[tokra]

The LIVE-recording from the Nordlicht Party showing of this demo is now on YouTube.

[Jeff-20]

I simply MUST go to one of these European events.