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

[Mike]

So, Torsten and I started out from a well functioning graphics mode of 160x192, and his first approach of a 160x240 mode, which unfortunately monopolised the VIC-20 for display only.

After I had emphasized, that interoperability is quite important to me, Torsten took a step back, and suggested a 160x200 mode instead.

So, here's Part 2: Adding an extra line: 160x200

...

160x200 would be a nice mode for the VIC though, since a "real" 40-char mode using 4x8 chars and 25 lines would be possible. All the other 40-char-modes either just use 24 lines or 4x7 chars.

The number of lines has to be dividable by 16 because of the double-height-chars. Maybe the lower 1K can be utilized in a sensible way by just using 679-767 and the tape buffer. This would however just provide another 8 lines -

Well, one single line ... but there's quite a difference when you can put more words on a line, think about it, even newsletter columns often feature 35..40 letters. [...]

...

Even though, some hours later I had an idea how to realise the mode, and still leave the zeropage "intact":

"Just had another line of thought about that, you'd need to:

- make an interrupt before the 192nd line,
- save the ZP between 240, and 259 (20 bytes in total),
- write characters there to address 864 .. 1023 (i.e. #108 .. #127)
- change to the lower 1K text screen, and char set, and 8x8 characters.
- wait for the 200th line, restore ZP, and VIC registers, and
- exit the interrupt.

But: it's not quite clear to me ATM, what to write into 36867. In theory, it is the 13th text line, since 12 text lines had been displayed beforehand. But it also could be the 25th text line, if the VIC chip takes the info from the raster line. And then, one would not take bytes 240 .. 259 as "text screen", but 480 .. 499 - but they're located amidst in the stack!

Should the latter be the case, it would be better to locate the text screen beginning from $0200 (i.e. 992 .. 1011 for the 25th line). Then still 832 .. 991 would be usable for the bitmap, and one even wouldn't need to save anything.

For now I can't test this on a real VIC-20, and it remains to be seen, whether VICE is able to cope with these wild register changes.

Except we now have a software-assisted "active" graphics mode, this should function. Those 8 lines in the interrupt also wouldn't burn too many cycles. And it would work with NTSC as well.

Greetings,

Michael"

[tokra]

Hehe Exactly like I thought out during lunch break. My notes attached:

512+480

832-991 = Char: 104 - 123 = Room for 20 Chars
992-1011 = 20 Video-RAM Byte

This way the cassette buffer would be used pretty nice. Will try that right now. Let's see if the VIC accepts the change of 36867 in the middle of a raster scan - since it doesn't work with 36865.


[later that day]:

Ok, I tried out some stuff. You really do have to start at Char 240 and not at 480, so there's no way around saving the area from 240-259. Otherwise the implementation worked just as you suggested. I'm not clever enough yet though to code a raster interrupt. It most certainly works like suggested here:

http://www.antimon.org/dl/c64/code/stable.txt

but that's not something I will do tonight Maybe you have more experience with raster interrupts and can expand the code accordingly. You can find it here:

Source: http://www.tokra.de/vic/160200.asm
Binary: http://www.tokra.de/vic/160200.prg

Note May, 20 : start with SYS8192 - you can test the display in VICE by going into the Monitor (ALT+M), then typing

Code: Select all

f 1100 1fff aa

to fill the upper 160x192 with a pattern and

Code: Select all

f 0360 03ff 55

to fill the extra line with a different pattern[/i] and then leave the monitor with

Code: Select all

x

[Mike]

I see!

Maybe you have more experience with raster interrupts and can expand the code accordingly.

Just made a quick look into it. [...] Indeed I already did something with raster interrupts, [...] but I developed my own routines because at that time I couldn't follow through Marko's synchronisation method. Also, I only need one timer.

[tokra]

[3 days later]

Okaaaaay, I have indulged in Marko Makela's raster-routine and think I'm 98% sure of what he's doing there.

I've then instantly applied what I just learned and implemented the 160x200 hires-mode:

Source: http://www.tokra.de/vic/raster160200.asm
Binary: http://www.tokra.de/vic/raster160200.prg

I've put the routine at 8192 - so type this line in before using with BASIC:

Code: Select all

poke44,34:poke8704,0:new

Short BASIC-Test-Program:

Code: Select all

10 sys8192
20 fori=4352to8191
30 pokei,rnd(1)*256
40 next
50 fori=0to159
60 poke864+i,rnd(1)*256
70 next
200 poke198,0:wait198,1
210 fori=0to259:poke37888+i,6:next
220 poke198,0:wait198,1

I've made the assembler-routine as fast as possible to conserve raster-time and as such "unrolled" the saving, creation of the charmap and copying back of the bytes. This was just too tempting since most bytes are within the zeropage and the instructions are smaller and faster there. Also only 16 out of 20 bytes need to be saved - as the bytes from $fb-$fe are free anway. It's also nice that the color-RAM is continuous (as can bee seen in the demo).

By providing 160x200 there now is a "half" C64-resolution on the VIC: Most interesting probably should be a 40x25 char-mode. I'm thinking about a special version of MGBROWSE or maybe even MINIGRAFIK/-PAINT

[Mike]

Tried it out, and it works indeed!

I've made the assembler-routine [...] "unrolled" [...] This was just too tempting since most bytes are within the zeropage and the instructions are smaller and faster there.

Yeah, it's a cool method indeed! I've also used unrolled loops in other places, where speed counts over everything else.

Also only 16 out of 20 bytes need to be saved - as the bytes from $fb-$fe are free anway.

Not for example, when MINIGRAFIK runs. Also other programs might store data there which aren't aware of your interrupt routine.

(Aside: it's one thing if two programs use the same addresses, but are both running in foreground. Then they still can co-exist by, say, pushing the old contents onto the stack, and restoring it after they've finished. But if an interrupt uses a memory address without restoring it, that address effectively is "spoilt" for other programs, as it could change unpredictably from the view of a non-interrupt program.)

By providing 160x200 there now is a "half" C64-resolution on the VIC: Most interesting probably should be a 40x25 char-mode. I'm thinking about a special version of MGBROWSE or maybe even MINIGRAFIK/-PAINT

We sure can discuss a 25-line version of MGBROWSE. There, the extension of one line could easily be included in the binary of the display program.

But if you're going to extend MINIGRAFIK and MINIPAINT you're opening a can of worms:

- You'll need to add new routines to make the bottom 8 lines accessible for the pixel-set, and -query routines,
- NTSC needs to be supported,
- the file format would need to be extended to include 200 lines, and that applies to the built-in display routine as well.

Just because of the points noted above this might double the size of the MINIGRAFIK executable.

- Similar alternations need be done to MINIPAINT as well - even the internally used off-screen bitmap would require a re-design.
- MINIPAINT uses an extra interrupt routine for itself, though for other reasons.

Inthusfar, I need to weigh the necessary work against 8 extra lines, and for me I can't justify the cost.

A moderate implementation could add the 8 lines as plug-in, without direct access by MINIGRAFIK. Still, the extra line could be used a status display, or the like. Or, as hinted above, as 25th line in MGBROWSE.

Greetings,

Michael

[tokra]

Also only 16 out of 20 bytes need to be saved - as the bytes from $fb-$fe are free anway.

Not for example, when MINIGRAFIK runs. Also other programs might store data there which aren't aware of your interrupt routine.

Okay, but this is true for the tape buffer as well. It comes down a question of the program specificaction, namely which bytes will the extension provide to the user for free use. With pure BASIC code there are no conflicts this way.

We sure can discuss a 25-line version of MGBROWSE. There, the extension of one line could easily be included in the binary of the display program.

I'm just thinking about all those plain-text C64 programs. Those use either Screen-40 or Fat-40 now and there is either a line missing or the chars have an ugly 4x7 matrix.

But if you're going to extend MINIGRAFIK and MINIPAINT you're opening a can of worms:

Inthusfar, I need to weigh the necessary work against 8 extra lines, and for me I can't justify the cost.

It's true that the effort wouldn't be small. I'll use this a learning-project for myself. Let's what what else one can do with it.

A moderate implementation could add the 8 lines as plug-in, without direct access by MINIGRAFIK. Still, the extra line could be used a status display, or the like. Or, as hinted above, as 25th line in MGBROWSE.

When you mentioned "extra line for status display" I got a new idea. You don't need to use the tape buffer for character-RAM, but - using a raster interrupt after ther 160x192 resolution - you could put video-RAM at $0200 and point the characters to the standard ROM. This way there would be 8 more lines (= 160 bytes from 752-912) to be used with characters from ROM, e.g. for status-messages and such. I'm thinking about the screen-layout of Maniac Mansion or Zak McKracken. You would only need to save and restore the areas from 768-783, 788-813 and 816-819 (=46 bytes) during IRQ.

If you choose another screen-layout that uses more than 20 columns probably more or longer status-lines are possible.

[Mike]

Okay, but this is true for the tape buffer as well. It comes down a question of the program specificaction, namely which bytes will the extension provide to the user for free use. With pure BASIC code there are no conflicts this way.

I gladly confess MINIGRAFIK even uses some more ZP addresses, particularily those otherwise shared by tape/rs232. Just so you know.

I'm just thinking about all those plain-text C64 programs. Those use either Screen-40 or Fat-40 now and there is either a line missing or the chars have an ugly 4x7 matrix.

The charset of FAT-40 could look better, even though it uses a 4x7 matrix - in MGBrowse, and MINIPAINT the upper case chars are also only of 6 pixels height.

All in all it raises the question, whether a 25th line really is necessary for the screen layout. It is, if you want to preserve a layout taken from a C64 1:1. But with MGBrowse you'll have, well, just one more line.

It's true that the effort wouldn't be small. I'll use this a learning-project for myself. Let's what what else one can do with it.

[...] you could put video-RAM at $0200 and point the characters to the standard ROM. This way there would be 8 more lines (= 160 bytes from 752-912) to be used with characters from ROM [...] If you choose another screen-layout that uses more than 20 columns probably more or longer status-lines are possible.

With 22, or 23 columns you might even get a more balanced format.

One might even sacrifice tape buffer use, and arrange things as follows:

23x10 = 230 characters at top (i.e. 184x160 bitmap with double-height chars)

... the bitmap needs 3680 bytes at the end of the top 4K, leaving 416 bytes free, 230 bytes are already used by the text map, with 186 remaining. With 23 columns this gives 8 extra text lines at 8 pixels height each. Save for 2 bytes the whole upper 4K built-in RAM are used.

The result: a 184x224 split screen, the top 160 lines with graphics, the bottom 64 lines contain 8 standard text lines.

Just a suggestion.

...

(At that stage I wouldn't know what surprise was bound to happen to me on the next day ... to be continued in Part 3.)