Spectrum Computing

djnzx48 wrote: ↑Thu Aug 23, 2018 8:27 am Looks good! Although 1.5K for a font seems quite a lot. Could you somehow use an LFSR to select the pixels that turned on in each character, and so avoid storing them all one by one? The main problem is that it would involve a lot more iterations over each character, unless you somehow got it to only pick from the pixels that actually get drawn, and ignore all the empty space.

Instead of storing an x and y coordinate for each pixel, you could try storing an wrap-around x offset from the previous pixel. Then you could potentially store each pixel using 4 bits or less. Characters like i and j that have 'gaps' in them might pose problems though, and it would slow down as more pixels get drawn. If there aren't many characters using all 15 pixels it might not be too bad.

Mmmmmm....actually, the LSFR idea might not be far off what I had in mind at the start. I hadn't put two and two together. By separating the X and Y components it might be possible to reference a position or offset in a string of X or Y progressions, therefore just needing 2 references for each character. The frame is just then a progression along those strings.

arkannoyed wrote: ↑Thu Aug 23, 2018 8:26 am

Ast A. Moore wrote: ↑Wed Aug 22, 2018 9:09 pm Does it auto-split words and start a new line when it reaches the righthand edge of the screen? I remember it took me a couple of tries to implement that just right in my proportional-width font printing routine. (I haven’t revisited it since, so the code is bit on the ugly side.)

Currently nothing as advanced or clever as splitting words. It uses 3 bytes at the start of a line, bit no. (80,40,20,10 etc), then screen address, followed by the text. the line ends with a control character to indicate that theres either a new print position, or its the end of printing.

If your font (well, your line, really) is 8 pixels tall, you can use the attribute address for tracking the current print position and then convert it into a bitmap address. It’s quite a bit faster and saves you the trouble of working around the crazy screen layout. It also gives you your carriage return/line feed for “free” (well, to a degree). Finally, if you wish to color in the text as you print it, you also get that automatically.

If your line height is not a multiple of eight, then, yeah, you’re in trouble.

I've used the ATTRs address in a few other routines to track the position. Actually with this routine, as long as you stay within a screen third, then just by incrementing E (of the DE screen address) when the global bit marker indicates to do so, gives no issues.

I'm now deep into examining the character code, trying out a few ideas!

arkannoyed wrote: ↑Thu Aug 23, 2018 12:50 pm as long as you stay within a screen third, then just by incrementing E (of the DE screen address) when the global bit marker indicates to do so, gives no issues.

Oh, yeah. Long as you’re not crossing a screen third’s boundary, you’re good.

This is great stuff

Does it matter in what order the pixels get drawn? What I meant was not to store the pixels as an offset from the top left of the character, but a relative offset as the number of pixels to the right of the previous pixel. Then for a 5 pixel wide character, 4 bits is enough to go three lines down, and 3 bits will get you to the next line and a few pixels to the right, which should be enough to encode most characters (the problems would likely occur with characters that are both wide and have a lot of vertical space, like '_' or ','). Going downwards might work, except thin characters like '!', '.', or '|' would pose problems.

If the order of drawing is important, then you can get semi-random ordering with a 4-bit LSFR determining which pixel gets drawn each time round the loop, maybe with an offset for each character in the text so that they don't all draw in exactly the same way.

Your method sounds much better though so I'd just disregard this idea and go with the referencing thing instead.