I went ahead and wrote the higher-level wrapper for displaying stuff on the screen, which is pretty close to the highest ROM service routine layer that the rest of the system will use to output messages somewhere the user can see them - you give it the start address of the string to be displayed (which is zero-terminated), the X and Y co-ordinates of the row/column you want it to appear at, and an attribute byte which determines whether it's displayed normally, inverse, or with underline or strike-through (or any combination). And then it takes all of that and sets things up so that the dirty-row refresh IRQ logic can detect it and draw it to the bitmap.
I did a quick calculation using the profiler results and determined that it draws at a rate of about 300 cycles per character, or approximately 9.73 cycles per pixel, which is pretty good. However, as you'll recall, I thought I could further improve the drawing logic, and I had an idea that if I could get the CPU consumption down to below 10,000 cycles for a line refresh, I could double the draw rate by calling the routine twice per IRQ instead of just once. So I sat and had a ponder about that, and saw a couple of things I could do.
Firstly, quite a lot of time was being spent identifying the dirty-row attribute byte (the first attribute byte of each row) and isolating the dirty-row bit - and subsequently clearing it if it was set. So I traded space for speed, and re-allocated the dirty-row bit to its' own byte - at a cost of a 25-byte table, I could eliminate a fairly sizable chunk of logic and speed the process up nicely. Then I noticed that there was a bit of code which appeared three times, albeit with slight differences, and I spent half-an-hour reworking a good chunk of the whole routine to avoid this (near) duplication and make more efficient use of registers. Taking a breather after that, I fired-up the new code to get an idea of what progress I'd made:
Gonna have to have a little tracing session with the XVIC monitor here, wouldn't you say...?


No comments:
Post a Comment