(no subject)

I got it to print 37901./0/ BASIC BYTES FREE.

The right 32-bit numbers are being added to the mantissa, but somehow the right numbers aren't being written to the buffer on odd-numbered digits and there's an off-by-one.

Well, that was a Sunday afternoon well-spent, I guess. It's midnight so I should go to bed.

(no subject)

I got 38911 to show up. Next up: keyboard handling.

The original plan was to make a stub keyboard handler so I could move on to parsing BASIC statements, but I think instead I'll get the final version working, and instead make a stub line parser that just repeats the line back to me in a different color.

I've learned how interrupts work on the DCPU-16, which supports a clock that can interrupt at 60Hz. I'm a bit worried about the fact that the clock speed is going to be so much slower than a C64 that there might not be time every frame to do the same kind of calculations.

(no subject)

OK, I need to make a decision about how I'm going to do the screen.

See, the C64 didn't poke ASCII values directly to the screen. It shuffled around the order, so that the letters and numbers would be in the first 64 characters, which was important for that multicolor background mode that nobody ever used ever. But this means that to get a letter A on the screen, you'd POKE 1024,1 instead of 65.

The reason this is important is because the default font in the LEM-1802 display does map exactly to ASCII. So I have two choices here:

On the one hand, I could port the code as verbatim as possible, and install a new C64-esque font into the LEM1802 display. I'd be able to take the opportunity to get full PETSCII graphics capability, and the shift-C= to go into lowercase mode. well, shift-ctrl anyway. It would eat up 512 bytes of memory for both modes, since the fonts are so low-res.

On the other hand, I could try to fudge the code as I port it, in the hopes that I can get it to recognize real ASCII without breaking it in some subtle way.