I've started working on a 32-bit math library. I wanted to get an "uptime" command working, but to do this, I needed this library. I've done some tests with the DIV command, and confirmed that it will cause an overflow if the resulting value will not fit in a 16-bit value.

I've got 32-bit addition, subtraction, compare, right and left shifts. I still need to get division working. I think the existing 16x16 MPY command will be OK, but as I type this I can see cases where a 32x16 routine would be handy. I can't see any reason for a 32x32 routine, since all results will exceed 32 bits. If some wierd case pops up which needs this, I can do this work later.

So I figured out what was causing the color problem. It turns out that when the ISR hits, it reads the VDP status register. Doing this cancels any command that may be in progress (in this case, set write address). So what happpens is that at the start of a screen write, instead of resetting the write pointer, writing continues from the last frame, overwritting the color tables and other stuff in VDP memory.

Disabling interrupts while VDP commands are being written seems to have fixed the problem.

I'm not sure what was going on, but the loss of keys is tied to the size of the emulator window. At small sizes, no keys are lost. At fullscreen, lots of keys get lost.

I've added code to prevent repeated keys due to held keys. Works nicely.

The color problem has not been fixed...

It looks like its time to start working on a shell.

So, I've got the keypress buffer working, it's a 16-deep circular queue. Seems to work OK, but the key scanning is really slow, I miss lots of keys typing at a normal speed. Even after scanning at 60 Hz, I miss events. There must be some kinda design flaw I'm not seeing, since I can't be that slow.

Another point, I don't have a good way to separate keypresses, so there's just a series of repeated scan codes if keys are held down too long.

Oh crap, I just thought of something. The scanning routine takes a while, and the ISR may be restarting before the scan is complete. I really hope that's not the case.

Crap, that's the problem. I ran a test by cutting down the scan to only two columns. In that case, all keys are seen. So I need to redo the scanner to be faster somehow.

One other annoyance. After a few seconds, the screen colors get corrupted. Ocassionally, a sprite will be turned on, I suspect a buffer overflow somewhere.

So I've got a working interrupt handler, keyed off the VDP. This generates 60 IRQs per second. In the ISR, a clock counter is updated and the keyboard scanned every 4 IRQs (15 times per second, or 66 msec).

I'm working on a queue to store scanned keys. This is simple enough, but I'm trying to squeeze out every drop of speed and size I can get, so this may take a while.

Initial testing shows that I can refresh the screen at about 30 FPS, which is pretty good.

I'm looking into the idea of using the 9901 to scan the keyboard. The problem is that it looks like I would need to increase the IRQ rate to cycle through the keyboard columns. I wonder if I can use hardware to cycle columns for me.

The caps lock seems to be caused by a problem with MESS. I've dug into it a bit, but I'm not really interested in working on that right now. Too similar to what I'm doing at work. I'll just live with the broken caps for now.

The keyboard scanner can now display human-readable, ASCII. I'm ignoring the lack of caps lock for now since I don't use it anyway.

I've got a working keyboard scanning routine working, but there are a few drawbacks. The alpha-lock key cannot be scanned, and I don't have a translation to ASCII working yet. There's the start of some code to do the ASCII conversion, but it's got some work left to do. The lack of alpha-lock troubles me more though. Maybe I need to check the MESS code to see how that's implemented. Maybe it's different than actual hardware.

I've noticed that there is a bug in the memcpy routine, here's an example of the test I ran. The first test varies the copy length, the second the destination address

I expect to see output like this:
ABCDEFGHIJ ABCDEFGHIJ
ABCDEFGHI BCDEFGHIJ
ABCDEFGH CDEFGHIJ
ABCDEFG DEFGHIJ
ABCDEF EFGHIJ
ABCDE FGHIJ
ABCD GHIJ
ABC HIJ
AB IJ
A J

I actually see this:
ABCDEFGHIJ ABCDEFGHIJ
ABCDEFGH ABCDEFGH
ABCDEFGH CDEFGHIJ
ABCDEF CDEFGH
ABCDEF EFGHIJ
ABCD EFGH
ABCD GHIJ
AB GH
AB IJ
(empty) (empty)

I did another test, and using byte-copies with the screen buffer slows the system back down, losing us our 20% bump. So I need to get memcpy (and memset, which uses a similar method) working.

word memcpy test 2, don't append "\n"
ABCDEFGHIJ
ABCDEFGHJ
CDEFGHIJ
CDEFGHJ
EFGHIJ
EFGHJ
GHIJ
GHJ
IJ
J

So it looks like the lowest-order bit is being ignored for word copies.

After fixing memcpy, test runs for 0-A00 time
TIME Description
83.64 first pass, working memcpy

Been a while since I updated this...
The print routines are working fine now, and I can print strings, signed or unsigned decimal or hex to the screen or a buffer. Unfortunately, I don't have format specifiers, so everything prints as %X or %d, but I can't do %8X, or even %08X

I started working on a keyboard driver, and have verified that I can read the appropriate CRU bits. Looks promising. Even though there is a keyboard scanning routine in the firmware, I don't want to use that unless absolutely necessary.

During keyboard testing, I noticed just how slow the screen_write function is. Since I intend to do a lot of printing, I need this to be as fast as possible. Or at least reasonably quick.

To that end, I'm running a speed test here. This is the time, in seconds it takes to count up to 0xA00. Time is taken on a non-maximied screen, started when "2" is pressed on the TI program selection screen.

TIME Description
106.17 Baseline
57.23 No copy from VDP for screen scroll
83.13 First attempt with screen buffer, non-working

The savings seems to be in the scrolling section. By using word copies instead of byte copies, I seem to gain a bit of speed. Unfortunately, what was a reasonably well laid out bit of code will be mangled by maintainng the screen buffer. Oh well. I'd rather have the 20% speed-up.