![Image](http://www.geting.se/image.php/191957-vic20-ntsc-22-24cols.jpg)
![Image](http://www.geting.se/image.php/191958-vic20-pal-22-26cols.jpg)
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.
Moderator: Moderators
Or screen estate, for that matter.carlsson wrote:Or perhaps 46x22 (184x176 pixels, 253 double height characters) if you want as many columns as practically possible.
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.It would be a bit odd screen layout though compared to 40x24.
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.Mike wrote: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.IsaacKuo wrote:I don't know how Sentoria does things, but I don't see why scrolling is such a problem.
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. *That's totally crap. Why should I compare 8 bytes of a bitmap, when 2 bytes of text do the same job?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.
So what? You can write a tiny conversion routine to go from ASCII to PETSCII. That's much tinier than an entire font.Please read carefully. I wrote ASCII, not PETSCII.Nope. The other CBM 8-bit machines already include a full PETSKII character set in ROM.
I would devise the text file to be readable on the VIC-20, and editable on a normal PC.
Obviously you consider development for an unexpanded VIC to be a complete waste of time.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.
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.IsaacKuo wrote: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.
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.So what? You can write a tiny conversion routine to go from ASCII to PETSCII. That's much tinier than an entire font.
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.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 challenge for what?Obviously you consider development for an unexpanded VIC to be a complete waste of time.
I think it's an interesting challenge.
From my last posting above, you can imply I'm talking about implementation on an unexpanded VIC.Mike wrote: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.IsaacKuo wrote: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.
You can map {} to <>. If you need to distinguish them from <>, then make them a different color.Where are '}', '{', '\', '|', '~' in PETSCII?So what? You can write a tiny conversion routine to go from ASCII to PETSCII. That's much tinier than an entire font.
A challenge for working with its particular limitations.A challenge for what?Obviously you consider development for an unexpanded VIC to be a complete waste of time.
I think it's an interesting challenge.
It's one thing to say that you don't feel like developing a particular application for an unexpanded VIC.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.
I wouldn't want to use these work-arounds, because I can do better. Using appropriate glyphs. With user defined characters.IsaacKuo wrote:You can map {} to <>. If you need to distinguish them from <>, then make them a different color ...
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.It's one thing to say that you don't feel like developing a particular application for an unexpanded VIC.
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.But it's another thing to say a particular technique which is useful for unexpanded VIC20 development is "totally crap".
So what? To me, the question is whether it's good enough--not whether it is perfect. Perfect is boring to me.Mike wrote: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.
This depends on your definition of "wins downright".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.