diff options
Diffstat (limited to 'src/notes.64x34')
| -rw-r--r-- | src/notes.64x34 | 176 |
1 files changed, 176 insertions, 0 deletions
diff --git a/src/notes.64x34 b/src/notes.64x34 new file mode 100644 index 0000000..e886760 --- /dev/null +++ b/src/notes.64x34 @@ -0,0 +1,176 @@ + +64x34 software text mode needs GR.8 style screen, at 320x204. This +requires 8160 bytes for screen memory, plus (I think) 214 bytes +for display list. The initial version will probably use the plain +GR.8+16 display, and only support 32 rows. + +Character cells are 5x6, with glyphs being mostly 4x5 with a blank row +at the bottom and blank column on the left. Probably for lowercase and +capital M/m/W/w, I'll hard-code a bit of logic to copy the right-most +bit into the normally-blank left-most column, so these characters will +be fully-formed, though they'll touch the char to the left. Doing it +this way allows packing one row of pixels from 2 different glyphs into +each byte of glyph-definition table, like COL80 does. + +Depending on the design of the final font, it might also be that I can +avoid storing the bottom row (a few characters might need it to be a +copy of the top row, or I might get away with hard-coding zero). If +I'm not storing the bottom row, each 2 glyphs will take up 5 bytes +of table space (for a 128-character font, that's 320 bytes; for an +ASCII-only 96-char font, only 240 bytes! That fits in one page, so +I can simplify the routine that reads it). If I do store the bottom +row, those numbers become 384 and 288 bytes, respectively. Later on +if there's support for UTF-8 or whatever, it still might be better +to use the 240-byte 96-char fonts, but allow for more than one of +them. + +The renderer needs to be able to handle inverse video. It would also be +nice to support underlining (just force the bottom row of each glyph to +all 1's), but then there needs to be a way for the calling application +to set underline mode. Also it might be hard to read... Theoretically +it'd be possible to do italics too (shift the bottom few rows of pixels +left), but I think it would come out too ugly to want to use. + +Writing a glyph to screen RAM involves a 2-byte buffer for each row of +pixels. Extract 4-bit glyph data from glyph table, synthesize the 5th +bit for MmWw, store in the 2-byte buffer (in top 5 bits), then calculate +how many pixels to shift it, based on the cursor position. When actually +writing to RAM, have to load the old data from each of the 2 bytes, mask +off the appropriate bits, OR in the new bits, store back to RAM. This is +kind of an expensive operation, but we're only doing it for 6 scanlines +instead of 8 like COL80 uses, so maybe it'll be fast enough. + +If the right mask is $00, we don't have to touch the 2nd byte at all. The +left mask will never be $00. (algorithm below does touch the 2nd byte though) + +leftbyte = int(COLCRS*5/8), easy enough to calculate, but table lookup +will be faster. If we get tight on space, try it without the table. + +shift amounts will be stored in a table. Only 8 entries needed, lookup +on COLCRS%8. + +; first, calculate or lookup the start address of the current +; screen line, *SAVMSC + (*ROWCRS * 5), and store in rowptr +; next, calculate or lookup the start address of the corrent +; glyph, extract the relevant 4 bits (top or bottom nybble) and +; store in glyphdata bits 2-6 (all other bits 0). Store 0 in glyphdata+1. +; This is the body of the inner loop... rowptr needs to get 40 added to +; it every time through the loop. + lda COLCRS + tax + lda left_byte_table,x + clc + adc rowptr + sta zptr + adc rowptr+1 + sta zptr+1 + ; (zptr) now points to left byte + ldy #0 + lda (zptr),y + sta olddata + iny + lda (zptr),y + sta olddata+1 + ; olddata holds the old screen RAM contents + + lda #$07 + sta mask + lda #$FF + sta mask+1 + + txa + and #$07 ; a%=8 + tay + lda shift_amt_table,y + tay ; Y now holds the shift amount + beq no_shift + +shift_loop: + lsr glyphdata + ror glyphdata+1 + sec + ror mask + ror mask+1 + dey + bpl shift_loop + + iny ; Y = 0 +no_shift: + lda olddata + and mask + ora glyphdata + sta (zptr),y + iny + lda olddata+1 + and mask+1 + ora glyphdata+1 + sta (zptr),y + +To calculate screen bytes to alter... COLCRS ranges 0 to 63: + +COLCRS - leftbyte - shift amount - leftmask - rightmask +0 0 0 $F8 $00 +1 0 5 $07 $C0 +2 1 2 $3E $00 +3 1 7 $01 $F0 +4 2 4 $0F $80 +5 3 1 $7C $00 +6 3 6 $03 $E0 +7 4 3 $1F $00 +8 5 +9 5 +10 6 +11 6 +12 7 +13 8 +14 8 +15 9 +16 10 +17 10 +18 11 +19 11 +20 12 +21 13 +22 13 +23 14 +24 15 +25 15 +26 16 +27 16 +28 17 +29 18 +30 18 +31 19 +32 20 +33 20 +34 21 +35 21 +36 22 +37 23 +38 23 +39 24 +40 25 +41 25 +42 26 +43 26 +44 27 +45 28 +46 28 +47 29 +48 30 +49 30 +50 31 +51 31 +52 32 +53 33 +54 33 +55 34 +56 35 +57 35 +58 36 +59 36 +60 37 +61 38 +62 38 +63 39 + |