Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    136,046

Text Kernel Take 2

Sign in to follow this  
cd-w

676 views

I've done a little more work on my text kernel. It still displays only 12 lines of text, but the code is cleaner and it now shows lower-case letters and numbers (the text is from "The Hunchback of Notre Dame"):

 

blogentry-6563-1202927829_thumb.png

 

I can get this up to 14 lines by overlapping the buffer creation code with the display code (there are lots of free cycles in the kernel). The problem is that this requires four versions of the copying and kernel code, which takes up nearly the whole 4K and leaves very little room for the actual text. This could be solved by copying the text into zero page memory and then doing a bank-switch into the kernel code. However, the copying code would require 24 iterations of the following code (24x10 cycles = 240 cycles = 3.2 scanlines), which would negate any savings with this method!

 

lda (TEXTPTR),Y
sta BUFFER+?
dey

 

This is probably as good as I can get the code without pre-computing character pairs (as in supercats method), but this would be difficult with lower-case characters ...

 

Chris

Sign in to follow this  


9 Comments


Recommended Comments

Looks good! Very readable, which is important. Ever since reviewing Dark Mage, I thought it might be fun to try to write up a text adventure. I have yet to come up with any actual ideas, however. ;)

Share this comment


Link to comment
Looks good! Very readable, which is important. Ever since reviewing Dark Mage, I thought it might be fun to try to write up a text adventure. I have yet to come up with any actual ideas, however. ;)

 

Thanks - I have an adventure game idea for this kernel (using the savekey), but I won't make any promises as I still have another two projects to finish first!

 

Incidentally, let me know if you have any ideas for improving the font. I'm not entirely happy with some of the shapes, e.g: g, q, and 4.

 

It would also be nice to get more punctuation symbols, but I'd have to double up some of the letters and numbers, e.g. 1/l/I and 0/O, as the kernel is restricted to 64 characters.

 

Chris

Share this comment


Link to comment
Nice.

The TEXTHEIGHT = 4 threw me off for a bit until I realized that's really half the text height.

 

Yes, it's the text height for a single frame: the kernel alternates between two sets of 4 pixel high characters - actually 4 + 3 as the font is only 7 pixels high. It was a bit of a pain to split the font data into halves, but hopefully it is a job that only needs to be done once ;)

 

Thanks,

Chris

Share this comment


Link to comment

Impressive. Though I like the higher text density that can be accomplished by using pre-formed character pairs, your demo does a good job at building things on the fly.

 

It would seem as though the 64-character limit is rather arbitrary, since you could use characters numbered 0-84 and store three partial character sets per page (4 2/3 pages total), or characters numbered 0-127 with two partial sets per page (7 pages total).

 

I'm not quite clear why interleaving the character-prep code with the kernel code would require having four copies of the kernel. I could see things being tricky if you were using my 26-character approach (which does use four kernel versions since the two players swap positions) but I don't see the difficulty here.

 

Also, I don't think the overhead of copying data from ROM to RAM would be as outrageous as you suggest, especially if text were pre-formatted into lines. If each bank has 128 lines of text, then the code to fetch each line of text to RAM would be:

; Assume y holds line number * 2
 ldx #char23buff
 txs
 ldx #1
lp:
 lda char23_11,y
 pha
 lda char22_10,y
 pha
 ...
 lda char12_0,y
 pha
 iny
 dex
 bpl lp
 ldx #stack_top-2
 tsx

That's about 180 cycles to do 24 characters. To compensate for that, though, your copy routine would save 96 cycles by replacing:

  ldy #6
 lax (TPTR1),y
 lda (TPTR0),y
 tay

with

  ldy char0buff
 ldx char1buff

RAM usage shouldn't be a problem, since you could store the text temporarily at the end of the buffer. The last 7 bytes of text would get overwritten while rendering the last two.

Share this comment


Link to comment
This could be useful:

 

The flicker-text kernel places some restrictions on font design which aren't present in most cases. Most notably, letters that have an imbalance of even and odd scan lines are apt to flicker much worse than those which are balanced. If you tone down the contrast enough you may be able to get away with just about anything, but a good font design can improve things greatly. Not sure what you can do with mixed-case text, though you might test things with both 4- and 5-pixel high lowercase letters. I would expect the 4-pixel letters to flicker much less.

 

BTW, I wonder whether the best approach might be a compromise between my pre-paired letters and your on-the-fly rendering. Pre-pairing the letters as I do requires a bigger font, but it packs two characters per byte in the text storage area. If it were possible to pre-pair most of the characters but provide that each line could have some number of characters built on the fly, that might offer the best of both worlds. Keeping the worst-case timing reasonable might be tough, but nobody said the 2600 was supposed to be easy.

Share this comment


Link to comment
I'm not quite clear why interleaving the character-prep code with the kernel code would require having four copies of the kernel. I could see things being tricky if you were using my 26-character approach (which does use four kernel versions since the two players swap positions) but I don't see the difficulty here.

 

The problem is that it is necessary to construct the *next* set of characters when building during the kernel, as it is too late to construct the current set. This requires double buffering, and so doubles the code required for text copying and display. Since there are already two kernels, I was counting this as four. However, I think I may try this approach again together with the zero page copy routine that you suggested (I didn't think of using pha).

 

The flicker-text kernel places some restrictions on font design which aren't present in most cases. Most notably, letters that have an imbalance of even and odd scan lines are apt to flicker much worse than those which are balanced. If you tone down the contrast enough you may be able to get away with just about anything, but a good font design can improve things greatly. Not sure what you can do with mixed-case text, though you might test things with both 4- and 5-pixel high lowercase letters. I would expect the 4-pixel letters to flicker much less.

 

I tried a 4-pixel high lowercase font at first, based on your earlier advice, but I wasn't happy with the look, e.g. the s and z were squashed. I think the 5-pixel high version looks fine, though I haven't tested it on a real TV yet.

 

Chris

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...