Is this centered on a real NTSC VIC-20?

[Mike]

One question:

These two POKEs,

Code: Select all

POKE36864,PEEK(60900)-3
POKE36866,(PEEK(36866)AND128)+25

should produce a centered 25 column screen on both PAL and NTSC.

In VICE, the NTSC emulation appears slightly shifted to the right. How does this look on a real VIC?

[IsaacKuo]

On a Commodore 1702 monitor, it overflows both on the left and right sides.

I can adjust the horizontal position knob on the monitor to see the left edge or the right edge, but not both at the same time. The right edge does not show the entire 25'th column. It only shows the left half of the 25th column. VICE emulates this effect well.

By adjusting the horizontal position know, 24 columns are just barely usable...since it just barely fits, factors like image tilt come into play. Really, 23 columns is the maximum that's usable; I'd stick with the stock 22 columns.

On an Apple Monitor III, the left and right sides overflow by a much greater amount, and horizontal position is not adjustable. Different monitors will have different centering/size specifics.

[Mike]

That's too bad, because I intended to continue work on (by coding an own version of) Sentoria. It uses a 25 column display with half-wide characters to show 50x28 characters. The last version I know of still had some issues in formatting the text, and display of some characters (it uses ASCII) but further development of it seems to be dormant at the moment.

Unless one uses a monitor that not only allows for horizontal positioning, but also altering the display width, this program has the problems you described. I still wonder, why the display is off center in the normal case (in VICE, at least): subtracting 1 off the register 36864 would yield a centered screen then.

I might continue on that anyway. It's a nice method to include instructions for a game or program on the *.d64, so they can't easily be lost.

Thanks,

Michael

[carlsson]

I can try my NTSC VIC-20 connected to both a 1084 and a TV tonight. Perhaps it won't be genuine because the displays are PAL and may display a larger area of the NTSC signal than a real NTSC monitor/TV would. Isaac's experience is a bit surprising. I thought all NTSC setups with ease would display 24 or even 25 columns.

[TNT]

ral-clan managed to fit 23x27 screen on his NTSC monitor when he was testing my screen routines. Even that had top left corner partially out of view. I don't know if he adjusted his monitor for maximum viewable area, but I wouldn't count on people doing that anyway.

[IsaacKuo]

I still wonder, why the display is off center in the normal case (in VICE, at least): subtracting 1 off the register 36864 would yield a centered screen then.

VICE does a good job of showing more or less what's in the output signal. I think it's actually off by one pixel--showing one less pixel in the chopped off 25th column than is really shown.

However, the output signal is NOT centered in a typical TV display. Maybe this is because the VIC output timings aren't entirely NTSC standard, so the amount of overscan on the left and right are different.

At any rate, on a typical TV or the Commodore 1702 monitor, the stock default VIC20 display fits nicely on the screen. It might not be exactly centered, but it's good enough. I assume that during VIC20 development, the hardware engineers experimented with a variety of TV sets to find what would fit safely on all of them. The end result seems pretty well centered on my TV sets, but there's no inherent reason why this should produce a "centered signal".

The only monitor I use where the default is seriously off-center is my Apple Monitor III. On that one, the default display is shifted to the left by half a character. POKE shifting the display right by half a character nicely centers the display. Of course, the Apple Monitor III was designed around the Apple II/III display. It was never meant to be used with a generic composite signal.

I might continue on that anyway. It's a nice method to include instructions for a game or program on the *.d64, so they can't easily be lost.

For this purpose, what's wrong with assuming a 40 column display? That way, someone can easily read the documentation on any CBM 8bit. Your reader could either invoke a VIC20 specific 40 column displayer, or it could just use the standard KERNAL print routines.

[Mike]

[...]the output signal is NOT centered in a typical TV display. [...] The only monitor I use where the default is seriously off-center is my Apple Monitor III. On that one, the default display is shifted to the left by half a character. POKE shifting the display right by half a character nicely centers the display.

That indeed is, what VICE suggests on NTSC. With PAL, and on all TV's and monitors I've tried, the display was centered.

MINIGRAFIK, for example, takes the default ROM values from $EDE4 following, and subtracts or adds offsets. This way the degree of "excentricity" (whatever it is), is preserved at least. Judging from VICE, the 160x192 mode isn't critical on NTSC.

For this purpose, what's wrong with assuming a 40 column display? That way, someone can easily read the documentation on any CBM 8bit. Your reader could either invoke a VIC20 specific 40 column displayer, ...

When I use a full 160x192 bitmap, I get 40x24 characters, assuming 4x8 pixel characters. Like these here:



(this is the ASCII character set used in MINIPAINT). However, it wouldn't give an edge over the already existing 40-column emulators. The interesting point in Sentoria is, it uses redundancies of natural text that lead to the recycling of character pairs (with 8x8 pixel characters). Only slight caveat is the possibility to run out of available characters, and one would need to build an entire screen, scrolling is not easily possible.

Well, the new text display routines are already there, in MINIPAINT. It doesn't really matter, whether they should print 32, 40, or 50 columns.

... or it could just use the standard KERNAL print routines.

At least one would need to define an ASCII character set in that case.

[IsaacKuo]

For this purpose, what's wrong with assuming a 40 column display? That way, someone can easily read the documentation on any CBM 8bit. Your reader could either invoke a VIC20 specific 40 column displayer, ...

When I use a full 160x192 bitmap, I get 40x24 characters,[...] However, it wouldn't give an edge over the already existing 40-column emulators. The interesting point in Sentoria is, it uses redundancies of natural text that lead to the recycling of character pairs (with 8x8 pixel characters). Only slight caveat is the possibility to run out of available characters, and one would need to build an entire screen, scrolling is not easily possible.

The technique may be useful for an unexpanded VIC. You'd use dynamic character allocation, along with a routine to check for dupes.

I don't know how Sentoria does things, but I don't see why scrolling is such a problem. You just...umm...scroll up the screen matrix. When you scroll, you first read the top line of characters and see if any of them aren't reused further down. If not, then you push them onto the FREECHAR list. This is a simple method of garbage collection.

Now, I'm looking at this from the perspective of just implementing a memory efficient dynamic allocation routine. My FREECHAR list consumes only one byte of RAM (the pointer to the top of the freestack). The actual linked list is stored within the character bitmap zone.

When printing text, you'd always print temporarily to a fresh char block. Then, you can scan the screen to look for duplicates...not the fastest thing in the world, but good enough for mostly static text. Since I'm looking at this from an unexpanded VIC perspective, I'd favor conserving memory over superior speed. Thus, there's no independent storage of a true 40 column character buffer--the comparisons are made on a pure bitmap-to-bitmap basis. Sure, it's slower but it shouldn't be too bad as long as you short-circuit the comparison loops on the first mismatch.

... or it could just use the standard KERNAL print routines.

At least one would need to define an ASCII character set in that case.

Nope. The other CBM 8-bit machines already include a full PETSKII character set in ROM. You get a full 40 columns with the other machines out-of-box. The only machine which needs a special reader routine is the VIC20.

Like I said, if you assume 40 columns then your documentation can be easily read on any CBM 8-bit. Your reader program simply checks to see if you're running on a VIC20. If so, then use your custom 40 column display routine. If not, then simply dump the page to the screen with the KERNAL print routines.

[Mike]

The technique may be useful for an unexpanded VIC. You'd use dynamic character allocation, along with a routine to check for dupes.

Yeah, clear.

I don't know how Sentoria does things, but I don't see why scrolling is such a problem.

Instead of a dumb linear search of matching character pairs, it uses a natural binary tree. This speeds up display by at least 4 times.

You just...umm...scroll up the screen matrix.

That's commonplace. But with the binary tree, I need to reference count all character pairs, provide a routine to delete no more longer used pairs, and then the tree could degenerate to a list, etc.

When printing text, you'd always print temporarily to a fresh char block. Then, you can scan the screen to look for duplicates...not the fastest thing in the world, but good enough for mostly static text.

That's totally crap. Why should I compare 8 bytes of a bitmap, when 2 bytes of text do the same job?

Since I'm looking at this from an unexpanded VIC perspective, I'd favor conserving memory over superior speed.

Victragic wrote a version of Sentoria for unexpanded VIC. He had to cut down a lot of it. The fast binary search needed to be replaced again by a linear search.

Nope. The other CBM 8-bit machines already include a full PETSKII character set in ROM.

Please read carefully. I wrote ASCII, not PETSCII.

I would devise the text file to be readable on the VIC-20, and editable on a normal PC. Thus far I know of no text editor on the VIC, that would handle ASCII text. The proposed viewer could be the very first part of it, but then writing a text editor from scratch is not a trivial task, either.

For a simple round-up, that's the memory Sentoria uses at the moment:

bitmaps for 256 character pairs -> 2048 bytes
screen -> 700 bytes
tree -> 1024 bytes
character definition (96 characters @ 8 bytes) -> 768 bytes (definitions are duplicated in lower, and higher nibbles)

That's already 4.5K, and there's still no program counted in.

Sentoria is a good, fast text display program, with some small issues I intend to improve upon. Constraining myself to an unexpanded VIC would lead to nowhere.

[carlsson]

Here are the visual results of my test:


It turns out not even I can get more than 24 barely visible columns on a NTSC VIC-20, but the image is reasonably centered.

[Mike]

Thanks for the screenshots.

On the premise, that the text viewer should also run satisfactory on the real hardware, that would practically disallow the use of a 25 column display, as I had intended.

What a pity.

O.K., then I'll stick to 160x192, and write a dedicated ASCII text viewer for a 40x24 display.

[carlsson]

Or perhaps 46x22 (184x176 pixels, 253 double height characters) if you want as many columns as practically possible. It would be a bit odd screen layout though compared to 40x24.

[Mike]

Or perhaps 46x22 (184x176 pixels, 253 double height characters) if you want as many columns as practically possible.

Or screen estate, for that matter.

It would be a bit odd screen layout though compared to 40x24.

Odd indeed. But with that bitmap size I'd also need to place the screen matrix into the lower 1K, something I am not a big fan of.

Most probably, the viewer will consist of a BASIC stub, with a few MINIGRAFIK commands that initialise the hires screen, INPUT prompting for file name, and OPEN/CLOSE; and a ML part which does the rest (namely, file I/O, formatting, display, and scrolling).


Edit: This program finally was released in the thread "MG BROWSE, a 40 column ASCII text viewer".

[IsaacKuo]

I don't know how Sentoria does things, but I don't see why scrolling is such a problem.

Instead of a dumb linear search of matching character pairs, it uses a natural binary tree. This speeds up display by at least 4 times.

If you care about speed, then don't do any searching at all. Just use pure free characters when speed matters. Assuming the use of a 2K character bitmap area, you can get 13+ lines of text before you need to start worrying about dupe detection or garbage collection.

You can have a "fast" scrolling mode which only displays 13+ lines of text at a time. This lets the user quickly scroll up/down scanning for something. When the user stops scrolling, your routine may attempt to fill the display upward/downward using dupes of "middle text".

If the user starts fast scrolling again, you simply black out the areas above/below "middle text" to go back to "fast" mode.

When printing text, you'd always print temporarily to a fresh char block. Then, you can scan the screen to look for duplicates...not the fastest thing in the world, but good enough for mostly static text.

That's totally crap. Why should I compare 8 bytes of a bitmap, when 2 bytes of text do the same job?

To conserve memory. You don't need to store those 2 bytes of text; this saves you 512 bytes of memory...a huge chunk of RAM on an unexpanded VIC! You've got 2K consumed by the character bitmaps; .5K consumed by the screen. This leaves you only 1.5K of main RAM. And you want to just consume another .5K on something that's not strictly necessary? It's not like you can cram it into the tape buffer...the only convenient place for 512 bytes of RAM is main memory. *

Anyway, you don't need to compare all 8 bytes. You only need to compare until a mismatch. Even in the case of a successful match, the font may allow only checking 4 bytes. If, say, lines 2-5 match, you may be able to assume the others also match. This depends on the details of the font, of course.

Nope. The other CBM 8-bit machines already include a full PETSKII character set in ROM.

Please read carefully. I wrote ASCII, not PETSCII.

I would devise the text file to be readable on the VIC-20, and editable on a normal PC.

So what? You can write a tiny conversion routine to go from ASCII to PETSCII. That's much tinier than an entire font.

Besides, your custom font isn't going to get you very far on a PET. My suggestion was to design the reader so anyone can easily use any CBM 8-bit to read the documentation.

bitmaps for 256 character pairs -> 2048 bytes
screen -> 700 bytes
tree -> 1024 bytes
character definition (96 characters @ 8 bytes) -> 768 bytes (definitions are duplicated in lower, and higher nibbles)

That's already 4.5K, and there's still no program counted in.

Sentoria is a good, fast text display program, with some small issues I intend to improve upon. Constraining myself to an unexpanded VIC would lead to nowhere.

Obviously you consider development for an unexpanded VIC to be a complete waste of time.

I think it's an interesting challenge.

* (In contrast, the font can be crammed into nybble RAM; a 16 byte x*16 table in zero page can make the required upshifts pretty efficient.)

[Mike]

If you care about speed, then don't do any searching at all. Just use pure free characters when speed matters. [...] Even in the case of a successful match, the font may allow only checking 4 bytes. If, say, lines 2-5 match, you may be able to assume the others also match. This depends on the details of the font, of course.

From my last posting above, you can imply I'm going to trash the 50 column display idea. The 40 column display won't need any searches, it'll just copy the character bitmaps to the right places.

So what? You can write a tiny conversion routine to go from ASCII to PETSCII. That's much tinier than an entire font.

Where are '}', '{', '\', '|', '~' in PETSCII? At least for these I'd need to provide UDGs. Of course, on a C64 or 22-column VIC-20 display I can copy the original charset, and only replace the missing characters. For a 40-column display on the VIC-20 I need to supply the entire character set, which I chose to be ASCII, not PETSCII.

Besides, your custom font isn't going to get you very far on a PET. My suggestion was to design the reader so anyone can easily use any CBM 8-bit to read the documentation.

A non-VIC, 40-column version boils down to KERNAL I/O, and the conversion routine. But that's not the program I'm going to write now.

Obviously you consider development for an unexpanded VIC to be a complete waste of time.

I think it's an interesting challenge.

A challenge for what?

I've written quite a few programs for the unexpanded VIC-20. They can be found here in the forum. But I don't feel obliged to cram each and every program idea into the tight space available on the stock VIC, especially when that leads to code I might not understand anymore 6 months later.