80 columns on stock NTSC VIC20?

[IsaacKuo]

Has anyone done an 80 column display on a stock VIC20? I have a stock NTSC VIC20 and an Apple Monitor III to try this with (Apple Monitor III has loooooong persistence pixels).

The basic idea is to use interlace mode for a 400 line resolution and turn the monitor sideways. The characters are 5x8 pixels each. Display performance should be good because no bit-twiddling is required. Printing a character is simply two 2 byte copies (assuming the "in between" lines are left blank).

I'm not sure how many lines of text can be managed within stock memory...I don't have any expansion carts so I'll have to go with stock even if it means a one line display.

I've never done any sort of interlaced display on a VIC20 so I don't know quite how it works. I imagine that the interleaved lines will not be contiguous in memory--thus two 2 byte copies are required rather than one 4 byte copy.

[Mike]

The ingredients are:

* a bitmapped mode with 200 lines -> 25 normal characters height

this must fit in 2K, one field in $1000 .. $17FF, the other in $1800 .. $1FFF. The VIC chip only sees memory inside the VIC-20. Expansion RAM or ROM cannot be accessed by the VIC chip.

You need a text screen as address generator. This needs part of the 2K range, for both fields. It cannot be reused, since the address generator overlays part of the first bitmap, and wouldn't fully address the second bitmap either.

To display 8x8 pixels, you need 9 bytes. 1 byte in the address generator, 8 are in the bitmap. (One could use double-height chars, then this would be 17 bytes for 8x16 pixels. But you wanted 200 lines.)

2048 Bytes/9 ~= 227 characters.

227 ~= 225 = 25 x 9

I.e. the resulting mode is 9 characters wide, 25 characters high.

Turning the monitor sideways, switching on interlace, and switching the bitmap base registers every frame will give 9 lines at 80 characters.

In theory, it is possible to have the text screen in the lower 1K, giving one more line. But this doesn't go well together with BASIC and KERNAL.

I don't know if there's a way to discern whether the even, or odd field is displayed. If this is done wrong, the characters are distorted.

Michael

P.S.: VICtragic has written a text display program named "Sentoria". It displays 50x28 characters, without turning the monitor sideways. There is a trick involved using redundancies of letter pairs in natural text. With 1400 characters it fits more text on the screen than above method (which "only" does 720 characters).

[IsaacKuo]

* a bitmapped mode with 200 lines -> 25 normal characters height

this must fit in 2K, one field in $1000 .. $17FF, the other in $1800 .. $1FFF.

I don't understand this limit. Here's my guess at how things would fit:

$1000 .. $13FF 4096..5119 program
$1400 .. $17FF 5120..6143 Character Memory 1 (bitmap)
$1800 .. $1BFF 6144..7167 Character Memory 2 (bitmap)
$1C00 .. $1DFF 7168..7679 128x4x8 custom font data
$1E00 .. $1FF4 7680..8179 20x25 Screen Memory

To get the required interlaced resolution, the Character Memory base is switched each refresh (poke 36869,253 or 254).

The 20x25 Screen Memory matrix is in the default location, but only 20 characters wide. It's just a fixed matrix something like:

Code: Select all

..Y.@
..Z.A
....B
....C

....V
....W
....X

Every other column is left blank, for a "double-spaced" look. This lets descenders occupy the "bottom" pixel without touching the next row of characters. The blank lines could be used along with the spare 6 characters for underlining or a typewriter style cursor.

EDIT--added...errr, each character set actually requires 2K, not 1K...so I made some weird math errors...so I'm confused...it's been a long time.

[IsaacKuo]

Okay, I understand the problem now that I have my head on straight.

My head hurts trying to figure out how to pack things in, so I'll just first play with interlace and maybe implement a small display in BASIC. Then I'll see if I'm up for anything more complex than that.

[Mike]

Of course, noone forces you to use a full character set of single height characters with 2K size.

I calculated the maximum number of lines, when nearly all the internal RAM is used for display, either 9 lines (without using the bottom 1K), or 10 lines (using the bottom 1K). But then the display program must reside in expansion RAM.

Since you don't own a RAM expander, your memory config:

Code: Select all

$1000 .. $13FF 4096..5119 program 
$1400 .. $17FF 5120..6143 Character Memory 1 (bitmap) 
$1800 .. $1BFF 6144..7167 Character Memory 2 (bitmap) 
$1C00 .. $1DFF 7168..7679 128x4x8 custom font data 
$1E00 .. $1FF4 7680..8179 20x25 Screen Memory

is probably the best bet. But 1K of character data only allows for 128 characters, which leads to 5 columns at 25 characters.

The 3 remaining characters can be used for filling the non-text portion of the screen (and gaps), cursor display, and something else, as you suggested.

[IsaacKuo]

Thanks! 5 rows is good...this is just a stunt and not useful, after all.

Playing around with my VIC, it's immediately clear that the 5x8 characters are ridiculously skinny. The aspect ratio of each pixel is roughly 1:4, so the result is like a 5x32 box. Each pixel is as tall as the entire character is wide!

So, it's just a stunt with no useful purpose at all.

I did come up with another way to do it, albeit extremely flickery.

With interlacing, each character is essentially 16 rows tall. The two fonts are defined to stack 3 identical 5x8 letters on top of each other (plus a blank line). Each refresh, you swap in one of three character banks. Then, on each of the "off bank" scanlines, you black out the unwanted scanline.

So, you use two 1K fonts,and there are three 512byte character matrix banks. This consumes 3.5K, leaving 512 bytes for the program.

In order to get 80 columns, the screen size needs to be increased to 27 rows (up to 30 will fit on my NTSC screen). This gives a true screen size of 19x27, and a virtual screen size of 81x19. It will be insanely flickery, with a true refresh rate of only 10hz. Even my Apple Monitor III can't cure flicker on that level.

[Mike]

That one could actually work better than you might have expected ...

The VIC-I reads out the text screen in every scanline, not only once per character line. I.e. it's possible to change the text screen mid-character.

This would be the resulting address scheme:

Code: Select all

*      1st text, 1st charset
    *  1st text, 2nd charset
*      1st text, 1st charset
    *  1st text, 2nd charset
*      1st text, 1st charset
    *  2nd text, 2nd charset
*      2nd text, 1st charset
    *  2nd text, 2nd charset
*      2nd text, 1st charset
    *  2nd text, 2nd charset
*      3rd text, 1st charset
    *  3rd text, 2nd charset
*      3rd text, 1st charset
    *  3rd text, 2nd charset
*      3rd text, 1st charset
    *  3rd text, 2nd charset

Separating even, and odd fields, we get:

Code: Select all

Odd field:

*      1st text, 1st charset
*      1st text, 1st charset
*      1st text, 1st charset
*      2nd text, 1st charset
*      2nd text, 1st charset
*      3rd text, 1st charset
*      3rd text, 1st charset
*      3rd text, 1st charset

Even field:

    *  1st text, 2nd charset
    *  1st text, 2nd charset
    *  2nd text, 2nd charset
    *  2nd text, 2nd charset
    *  2nd text, 2nd charset
    *  3rd text, 2nd charset
    *  3rd text, 2nd charset
    *  3rd text, 2nd charset (this byte in the charset is always 0)

There's a slight irregularity in the 3rd raster, as 5 is odd. This scheme is repeated for all text lines (which then will become 3-character-columns).

You'll still have a refresh rate of 30 Hz!

This will operate with normal 8x8 chars. With 1K charsets, you can display 128 different characters. This allows the whole ASCII charset!

Only 27x19 = 513, one byte too much. So, "only" 18 lines.

Playing around with my VIC, it's immediately clear that the 5x8 characters are ridiculously skinny.

Indeed. But all in all an interesting idea. VICE currently doesn't include the emulation of the interlace mode, and I don't own a NTSC VIC-20.

But here's enough information around to implement this mode, including the necessary raster IRQ method which allows the mid-character text screen switch. Any takers?

Michael

[carlsson]

Does interlace really work in that way? I have a NTSC VIC-20 but only a PAL monitor. I get a steady picture in B&W, no matter if I enable the "interlace" bit or not. As far as I understand, the difference is that the VIC-20 sends out either 25 half frames or 50 full frames (or are those 30/60 on NTSC?). It could have an effect on flickering Zenith TVs. Anyway I don't think you get the interlace effect you have on e.g. an Amiga.

All the US people who have proper NTSC monitors and TV's, please confirm or deny this once and for all. The VIC-20 interlace mode has been rumoured for years, but nobody really has proven it exists or how it works.

By the way, I realize my video capture card accepts NTSC composite video in colour. I could try to connect my NTSC VIC-20 to that one and see if the capture device acts different with or without interlace. Perhaps it can't recreate what you'd see on a real monitor though.

[Mike]

The VIC chip always sends out half frames.

A full frame has 525 lines on NTSC, 625 on PAL at 30 or 25 Hz.

In non-interlaced mode, even and odd fields are layered on top of each other, as the half frame is always ended after a whole line (262 or 312).

In interlaced mode, the chip sends a correct NTSC signal, 262 and a half line per frame. A frame that begins at the begin of a raster is shown as odd field. When it begins at the middle of a raster it is shown as even field, signalling the TV set to put it neatly between the raster lines of the odd field.

By the way, I realize my video capture card accepts NTSC composite video in colour. I could try to connect my NTSC VIC-20 to that one and see if the capture device acts different with or without interlace. Perhaps it can't recreate what you'd see on a real monitor though.

It could even act as flicker fixer.

[IsaacKuo]

All the US people who have proper NTSC monitors and TV's, please confirm or deny this once and for all. The VIC-20 interlace mode has been rumoured for years, but nobody really has proven it exists or how it works.

I can prove it exists and it works as advertised. I too was skeptical. Back in the day, I had never known about this capability. When I dusted off my VIC-20 this week I had to check it out.

I used a sufficiently ancient NTSC B&W monitor to confirm that it produces a well behaved NTSC interlaced signal just like an Amiga. When using a B&W monitor, patches of color have a distinctive slow upward checkerboard crawl.

My old Mitsubishi HDTV recognizes and flickerfixes the interlaced signal nicely--but it's too big to turn on its side.

[carlsson]

Hm, ok. I know some Thorn EMI game has a mode where you can press F7 or something to enable interlace mode for TV's that flicker.

[IsaacKuo]

Only 27x19 = 513, one byte too much. So, "only" 18 lines.

Well, if you're going to hit the CPU for raster effects, you might as well twiddle that one extra byte also.

But I've since realized that you can afford to significantly overflow 512 bytes if you overlap with the font data and accept a much smaller character set.

For example, starting with a 24x30 character field requires 720 bytes. You start the fields at 5K, 6K, and 7K (so the chroma field fits within nibble memory). This leaves enough space in the fonts for a character set of 38. The resulting combined character field is 90x24.

A more practical application may be to chop each character into two characters instead of three. This only gets you to 60 columns, but the characters are a bit fatter, so they may be more legible.

Or forget about chopping the characters at all. A 30x24 display with a 16x8 pixel font may be pleasant in and of itself. Turning the monitor sideways means each character is roughly 1.5 times taller than it is wide, which already makes it more pleasant looking. By using interlace and making vertical lines 3 pixels wide, the vertical lines are about the same thickness as the horizontal lines. This may be what I try to implement first. It requires no special coding skills; even a tiny BASIC program can accomplish the required font switching per refresh.

Hmm...it may be worth doing even without interlace. Using the C64 font rotated sideways gives you 2 pixel thick vertical lines. The result is that the vertical lines are 1.5 times thicker than the horizontal lines. That's a pleasant look. It's no technical feat, of course, but the resulting 30x24 display may simply be more aesthetically pleasing.

[Mike]

How about you try to actually implement these ideas?

As I wrote above, I don't own an NTSC VIC-20. I could do the coding job within two hours for a functioning prototype in each of these cases, but since I don't have the means to test the result ...

[IsaacKuo]

At the moment, I'm only doing simple tests on my VIC since I haven't found my serial cable yet. Until then, I have no mass storage since I can't connect my 1541 (which may or may not be working). So I'm just doing what's possible with type in programming. This means I can't really make a fancy custom font since I have no practical way to save/load it.

I've played around with plain displays and 60hz register flipping to confirm various capabilities. My next step is to implement the simple non-interlaced 24x30 sideways display since I can develop/debug it on VICE. I just need to take the ROM font, rotate by 90 degrees, and "fatten" by 2 pixels.