Is this centered on a real NTSC VIC-20?

[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.

[IsaacKuo]

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.

From my last posting above, you can imply I'm talking about implementation on an unexpanded VIC.

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?

You can map {} to <>. If you need to distinguish them from <>, then make them a different color.

You can map '|' to CHR$(125) -- this one is really obvious.

You can map '\' to CHR$(191) (one of the quadrant chars)

You can map '~' to CHR$(168).

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?

A challenge for working with its particular limitations.

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.

It's one thing to say that you don't feel like developing a particular application for an unexpanded VIC.

But it's another thing to say a particular technique which is useful for unexpanded VIC20 development is "totally crap".

I don't understand why you insist that your way is the only correct way.

[Mike]

You can map {} to <>. If you need to distinguish them from <>, then make them a different color ...

I wouldn't want to use these work-arounds, because I can do better. Using appropriate glyphs. With user defined characters.

But I am not coding a viewer with KERNAL I/O for all CBM machines, for me the aim now is to produce a 40x24 character display for an ASCII text viewer, using 4x8 pixels half-wide character definitions, on the VIC. And in that case, I'd need to supply the entire character set, as I already wrote.

It's one thing to say that you don't feel like developing a particular application for an unexpanded VIC.

I'd be very surprised by an implementation of the above specification on an unexpanded VIC-20 that works with arbitrary ASCII text, supplied as SEQ file on a floppy.

But it's another thing to say a particular technique which is useful for unexpanded VIC20 development is "totally crap".

You might try implementing the 40x24 screen, matching double-glyphs instead of double-chars, on the unexpanded VIC. It still won't be able to display arbitrary ASCII texts.

With the 50x28 display, this method had been interesting, as it allowed for the big screen size, and one could hope, that relevant texts would not over-stress the algorithm. But with 160x192 I can employ a bitmap, that's always guaranteed to work (even if I need a memory expansion to put it to use), and then the bitmap approach wins downright against the dynamic method, because that one can fail - given a "malign" text.

[IsaacKuo]

You might try implementing the 40x24 screen, matching double-glyphs instead of double-chars, on the unexpanded VIC. It still won't be able to display arbitrary ASCII texts.

So what? To me, the question is whether it's good enough--not whether it is perfect. Perfect is boring to me.

What's good enough? Well, in this case the point is to display documentation. That doesn't mean arbitrary ASCII text, that means something human readable. And one important way good text documentation is made readable is with the use of whitespace. Good documentation uses blank lines and indentation. Is it necessary to display fully packed 40x24 text? No way! Not even close!

If I see a reader program switch to a "fast mode" by reducing the current number of displayed lines when necessary, then I'm impressed. If I see it then gradually increase the number of displayed lines as far as it can, then to me that's more interesting than a program which merely uses dumb brute force.

But with 160x192 I can employ a bitmap, that's always guaranteed to work (even if I need a memory expansion to put it to use), and then the bitmap approach wins downright against the dynamic method, because that one can fail - given a "malign" text.

This depends on your definition of "wins downright".

I am completely unimpressed by a "superior" method that merely throws resources at the problem to solve it with dumb brute force. I think a clever method like Sentoria wins some points because it cheats in a clever way. Yes, it can fail, but that just makes it more interesting to me.

You seem to place a higher value on watertightness. I think that the leaky seams around code which cheats to be interesting in its own right.

Instead of insisting on something which is "perfect", I'd rather try to figure out what is "good enough".

[Mike]

I'd rather say, I try to fit the program/game/algorithm to the available memory. I don't regard the unexpanded VIC as unpenetrable barrier.

Of course, writing a program with bigger memory consumption, that is slower, and doesn't function correctly is downward silly.

Even when there is plenty of memory available, there is at least one good incentive for a program to conserve memory - namely if it is used as function library. Any memory it doesn't use for itself is available to the program relying on it.

In case of MINIGRAFIK, the version 3.2 occupied 470 bytes. I thought long, and hard, whether adding multicolour support, and screen load/save were worth doubling the size of MINIGRAFIK. In the end I decided to do so. All the (new) built-in features of it are used in some program.

Conversely, thus far I didn't add a command to set the screen colours, and it's quite improbable I'll add it in the future, too. It might have looked like '@OR <nr>,<value>'. But the savings in the BASIC program using it would have been minimal to none: just added bloat that serves as a trivial transscription of up to 3 POKEs to the addresses 646, 36878, and 36879.