** New Frontiers in VIC-Hires-Graphics, Part 6 (sort of)

[tokra]

Ok, this is not really Part 6 of the series, but rather a continuation of the ideas brought up since then. So this is *live* if you will - feel free to jump in anytime

I've been thinking further about the idea that came from AmiDog's suggestion in this topic: http://sleepingelephant.com/ipw-web/bul ... php?t=4532

My initial idea of splitting the area to 208x80+208x96+208x80 wouldn't work as the basic video-area would have to be 208x176 which is too large memory wise to fit into an area visible to the VIC together with the necessary character display. So the maximum area the VIC can see still would be 208x144 expanded by raster copy to 208x208 as such nicely using all but 14 bytes of the 4 K area. (338 character bytes for video-ram, 3744 bytes for graphics)

To still get 208x256 the display needs to be split differently:

a. 208x96 upper 4k - 156 double-size characters
b. 208x32 upper 4k - 52 double-size characters
c. 208x96 upper 4K - 156 double size characters (using same chars as a.)
d. 208x32 lower 1k - 52 double-size charactes

This means:

$1000-116b: 364 byte video ram (= 728 characters displayed)
$1300-1fff: graphics areas a+b (208x128) + swap-area for c

$0000-00df: graphics area d1 (28 characters)
$016c-$019f: 52 byte video ram (= 104 characters displayed)
$01a0-$03ff: graphics area d2 (76 characters)

Interestingly enough the memory layout leaves some free areas:

$00e0-016b: 140 bytes
$116c-$12ff: 404 bytes

Especially the latter area may well be used for simple parts of the viewer program itself.

The switch-area of 208x96 would 2496 bytes, so a raster time of (2 * 256 + 2496 * 4) * 2 = 20992 cycles. Memory usage would be (257+ 7488) * 2 = 15490 bytes.

It's probably best to put the graphics-data itself neatly at $a000-$b9ff and then have the viewer-creation program pull the data from there. The viewer creation itself would be the most difficult part. I'm thinking about doing it in BASIC first to see how it works. It would have to do the following (pseudo-code)

Code: Select all

viewer-pointer = $viewer-raster-start;
write "ldx #00" to viewer-pointer;
viewer-pointer += 2;
for value = 0 to 255
  for address = 0 to 2495
    if (peek($a000+address)==value) then
      write viewer-pointer, "stx $1300+address;
      viewer-pointer += 3;
      if ($viewer-pointer == {right-moment-for-raster-switch}) then
        write viewer-pointer, "{raster-switch-graphics-routine}"
        viewer-pointer += bytelength{raster-switch-graphics-rotine}
      end if
    end if;
  next address;
  writer viewer-pointer "inx";
  viewer-pointer++;
next value;

write "ldx #00" to viewer-pointer;
viewer-pointer += 2;
for value = 0 to 255
  for address = 0 to 2495
    if (peek($ad00+address)==value) then
      write viewer-pointer, "stx $1300+address;
      viewer-pointer += 3;
      if ($viewer-pointer == {right-moment-for-raster-switch}) then
        write viewer-pointer, "{raster-switch-graphics-routine}"
        viewer-pointer += bytelength{raster-switch-graphics-rotine}
      end if;
    end if;
  next address;
  writer viewer-pointer "inx";
  viewer-pointer++;
next value;

Going through an area of 2496 bytes for 512 times might not be very fast, but I can't think of a better idea right now.

Comments anyone? Mike?

[tokra]

Talking to myself here - I just noticed that the memory layout could be a little simpler:

$1000-$119f: 416 byte video ram (= 832 characters displayed)
$1300-$1fff: graphics areas a+b (208x128) + swap-area for c

$0000-033f: graphics area d

This leaves the following free areas:

$0340-$03ff = 192 bytes
$11a0-$12ff = 352 bytes

This has the benefit of a continous video-ram, so less juggling in the lower 1k.

One could add another single-char line by "yet another raster-split" to the bitmap leading to a resolution of 208x264 (which I will dub YARS-mode) like this:

$1000-$119f: 416 byte video ram (= 832 characters displayed)
$11a0-$11b9: 26 byte video ram (= 26 characters displayed)
$11c0-$128f: graphic area e (206x28) at very bottom
$1300-$1fff: graphics areas a+b (208x128) + swap-area for c

$0000-033f: graphics area d

This would make good use of another 234 bytes.

Things might be easier if one wasn't bound by the 208 maximum x-resolution. I checked my Commodore 1901 monitor and 208 is at the very edge of visibility. Y-wise it could go up to 280 pixels, but I realize most monitors/TVs won't have the ability to squeeze the picture like the 1901 has. My projector will do 224 barely in x and 272 in y. VICE can go up to 224 in x and 280 in y. Judging by carlsson's result (http://www.sleepingelephant.com/ipw-web ... 61&start=9) 26 columns (= 208 pixels) seem to be the maximum visible width for most devices. I think 264 in y should be no problem for most displays.

I'd like to hear from others on this (PAL only):

POKE36867,66 (for 33 lines = 264 pixels y) or
POKE36867,68 (for 34 lines = 272 pixels y) or
POKE36867,70 (for 35 lines = 280 pixels y)
and play around with POKE36865 every time until it's centered.

and then the same with

POKE36866,26 (for 26 columns = 208 pixels x) or
POKE36866,27 (for 27 columns = 216 pixels x) or
POKE36866,28 (for 28 columns = 224 pixels x)
and play around with POKE36864 every time until it's centered.

What results do you get on maximum visible resolution?

[Mike]

You should at least add another degree of freedom by arbitrarily choosing the values to put into the shared space.

As one of the areas is scanned by the raster beam (say here: the top one), you'll have:

- to ensure everything is put in place as the raster beam arrives, and
- deferring updates for the bottom area until the raster beam has passed.

I suppose that requires at least a simple model of the VIC fetching memory running parallel to the construction of the display program.

In those parts of the screen "below" the raster beam, there then will always be "holes" in the shared space, which are accessible, but still not initialised to the correct value. The necessary value for those which are the nearest to the approaching raster beam should be used first.

But as the raster beam advances during the initialising session it might happen, that another hole (with another value) now is in danger to be reached by the raster beam, so you'd need to switch values, hop upwards (on the screen, but decreasing the address), and fill that hole - i.e. the above-mentioned criterion needs to be re-evaluated quite often, maybe after each store.

That has the smell of a combinatorial problem.

[tokra]

Too bad - I forgot that the display will not be filled sequentially anymore, which is really one of the reasons 208x240 works. I can start overwriting characters once they have been displayed. There is hardly any raster-time left for the better sta-commands over the whole switched display areas, so I guess that idea is out

I have another idea right now how to increase resolution, but this will need some calculating and it's Saturday and sunny, so not today

[tokra]

Ok, I've been busy today. Here is:

208x248

Although just another 8 lines were added this was probably the most complicated I've done yet, although it uses all the same already known principles.

How does it work? It always bugged me a little that the lower 1K wasn't used to full potential in 208x240: A full 128 byte were unused from $0380-$03ff. So I thought it may be possible to use the available space for character defintions and fill the rest "actively" with correct raster timing. This comes down to the following memory layout:

Code: Select all

; Video-Ram Top: 4096-4433 = 338 double height chars
; Char-Ram  Top: 4448-8191 ($1160-$1fff) = 3744 Byte = 29952 pixels (208 * 144 res)
; Swap-Char-Ram Bottom1: 4448-6111 ($1160-$17df) = 1664 Byte = 13312 pixels (208 * 64 res)
; Low 1K Video-Ram: 338-389 ($0152-$0185) = 52 double height chars
; Low 1k Char-Ram: 0-335 (Char 0-20) ($0000-014f), 416-911 (Char 26-56) ($01a0-$038f)
; Extra Line 1K Video-Ram 390-415 ($0186-$019f) = 26 standard height chars
; Extra Line 1K Char-Ram 1 912-1023 (Char 57-70) ($0390-$03ff)
; Extra Line 1K Char-Ram 2 0-95
; mapped to ($2000-$240f) = (8192-9231)

This way only 96 bytes have to be provided to the VIC actively, I could even use the standard lda-sta-memory copy routine providing for an easier addressing mode - it fits into the available raster time nicely.

Altogether the VIC does the following with its raster time
1664 * 2 * 6 for switching the top and lower 208x64 res = 19968 cycles
96 * 2 * 8 for switching the 12 chars in the lower 1K = 1536 cycles
for a total of 21504 cycles. Not counted are the graphics-mode switches and JMPs - another 50-100 cycles probably leaving just a few hundred cycles left to the 22152 it takes the VIC to display a full picture.

Binary: http://www.tokra.de/vic/208248-24k.prg
Source: http://www.tokra.de/vic/208248-24k.asm

Classic BASIC-example:

Code: Select all

10 sys10262:rem clear graphic
20 fori=0to1663:poke10888+5*i,rnd(1)*256:next
30 sys10259:rem clear color ram only
40 sys10256:rem show graphic, wait for keypress, turn off graphic
41 print "hello"
50 fori=0to2079:poke6112+i,rnd(1)*256:next
60 sys10259
70 sys10256
80 print "hello again"
90 fori=0to1663:poke19208+5*i,rnd(1)*256:next
100 sys10259
110 sys10256
120 print "hello three"
130 fori=0to831:poke8192+i,rnd(1)*256:next
140 sys10259
150 sys10256
160 print "hello four"
170 fori=832to1039:poke8192+i,rnd(1)*256:next
180 sys10259
190 sys10256
200 print "bye"

Line-drawing example (does window roses - try entering numbers between 4 and 30)

http://www.tokra.de/vic/fensterrose.prg