Skip to content

Commit

Permalink
Marginally speed up the tty, but using eight-bit aligned font data ra…
Browse files Browse the repository at this point in the history
…ther than

trying to pack it cleverly. Doesn't appear to make a noticeable difference in
real life, sadly.
  • Loading branch information
davidgiven committed Sep 20, 2020
1 parent fff8e21 commit 17e2354
Show file tree
Hide file tree
Showing 2 changed files with 15 additions and 62 deletions.
50 changes: 9 additions & 41 deletions arch/nc200/supervisor/tty.inc
Original file line number Diff line number Diff line change
Expand Up @@ -288,6 +288,8 @@ tty_rawwrite:
ld e, a
ld d, 0
add hl, de ; hl = a*4 + a = a*5
add hl, de ; hl = a*5 + a = a*6
add hl, de ; hl = a*6 + a = a*7
ld de, FONT
add hl, de
; hl points at font data
Expand All @@ -296,53 +298,18 @@ tty_rawwrite:

ld a, (hl) ; XXXXX???.????????
call draw_single_scanline

ld b, (hl) ; ?????XXX.XX??????
inc hl
ld a, (hl)
srl b
rra
srl b
rra
srl b
rra
ld a, (hl) ; XXXXX???.????????
call draw_single_scanline

ld a, (hl) ; ??XXXXX?
add a, a
add a, a
ld a, (hl) ; XXXXX???.????????
call draw_single_scanline

ld a, (hl) ; ???????X.XXXX????
srl a
inc hl
ld a, (hl)
rra
ld a, (hl) ; XXXXX???.????????
call draw_single_scanline

ld a, (hl) ; ????XXXX.X???????
inc hl
ld b, (hl)
sll b
rla
add a, a
add a, a
add a, a
ld a, (hl) ; XXXXX???.????????
call draw_single_scanline

ld a, (hl) ; ?XXXXX??
add a, a
ld a, (hl) ; XXXXX???.????????
call draw_single_scanline

ld b, (hl) ; ??????XX.XXX?????
inc hl
ld a, (hl)
srl b
rra
srl b
rra
ld a, (hl) ; XXXXX???.????????
; fall through

; On entry, the font data is in A, left justified.
; Font pointer is in HL.
draw_single_scanline:
Expand Down Expand Up @@ -392,6 +359,7 @@ scanline_shift_amount:
ld (L_cursor_address), hl

ex de, hl ; put font pointer back in HL
inc hl ; advance to next byte of font data
ret

; vim: sw=4 ts=4 expandtab ft=asm
Expand Down
27 changes: 6 additions & 21 deletions arch/nc200/utils/fontconvert.c
Original file line number Diff line number Diff line change
Expand Up @@ -37,33 +37,18 @@ int main(int argc, const char* argv[])
/* The glyph data is a 7-element array of bytes. Each byte contains
* one scanline, left justified. */

uint64_t mask = 0;
const uint8_t* p = glyph->data;

printf("\tdb ");
int yy = 0;
const uint8_t* p = glyph->data;
while (yy < LINEHEIGHT)
{
/* We assume the right-most column is blank, and so only store five bits. */

mask = (mask << 5) | ((*p >> 3) & 0x1f);
if (yy != 0)
printf(", ");
printf("0x%02x", *p);
p++;
yy++;
}

/* The encoding expects 8 5-bit values in five bytes, *left* justified. */
while (yy < 8)
{
mask <<= 5;
yy++;
}

printf("\tdb 0x%02x, 0x%02x, 0x%02x, 0x%02x, 0x%02x ; char %d\n",
(uint32_t)((mask >> 32) & 0xff),
(uint32_t)((mask >> 24) & 0xff),
(uint32_t)((mask >> 16) & 0xff),
(uint32_t)((mask >> 8) & 0xff),
(uint32_t)(mask & 0xff),
c);
printf(" ; char %d\n", c);
}

return 0;
Expand Down

2 comments on commit 17e2354

@Kroc
Copy link

@Kroc Kroc commented on 17e2354 Sep 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a lot of cycles saved, so you've bottlenecks elsewhere that's hiding the improvement :)

@davidgiven
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's probably death-of-a-thousand-cuts caused by BDOS dispatch, BIOS dispatch, context switch to supervisor, tty processing, etc. I don't see any obvious low-hanging fruit. I did try buffering outgoing data in the BIOS to save on dispatch time but it didn't help and I had to claim another 256 bytes of TPA for the BIOS, so I don't think it's worth it. I definitely open to suggestions.

Please sign in to comment.