#6502 asm

[commodorez]

Huh. It's not supposed to do that.

The lowest data bit of keyboard seems to oscillate when I press the N key, and sometimes that means the bit appears high when it should appear low. This results in typing an O instead. Every other key seems to be reasonable consistent.

What's also not consistent is that sometimes I get double key presses, which isn't great, but I can't seem to capture the strobe doing that. I need to see what it's doing on the scope in order to get an idea of what I'm trying to fix.

Yay early 1970s keyboards...

[commodorez]

Something bizarre was happening. I think I was causing some RF interference, and was capacitively coupled to the CRT.

Uh... sure. Spooky shit.

[commodorez]

It doesn't look like progress, but it's big progress.

[commodorez]

I made a game manual for Desert Miner.

Thank you to @stealingpotatoes for the cover artwork.

Thank you to 4004, foobles, jbevren, @seat-safety-switch, & ZephyrZ80 for helping me through the tougher parts of 6502 assembly.

[commodorez]

Failures, debugging, and learning!

[commodorez]

So I screwed something up in my screen generation routine, with what looks like an off-by-one error.

What you're seeing here is a memory dump of the 1KB region of screen memory on my OSI-440 video board.

The gray region is supposed to be the overscan portion of the screen, just filled with placeholder graphics.

The area inside of the red box is supposed to be the valid game area. However, we have a problem, and some spaces (0x20) and double quotes (0x22) are present outside of that red box. Whoops.

[commodorez]

Debugged a keyboard test routine I wrote, and it didn't take much to get it working. It's mostly operating as expected, which means that the last version of my Sanders 720 Option Interposer Mk III from 2024 is doing its best to hold back the spurious glitch pulses on the keyboard strobe line. You can see those as double key presses occasionally. But hey, it's way better than it was before!

[commodorez]

Okay, finally making good progress with the random tile selection logic. This is a look at the distribution based on values 0-255 (an 8-bit random number's full range). Obviously it loops past a certain point, but the reason we do this is to see how many of each tile it will render.

And here's a test to show what happens when we actually run the pseudo-random number generator to generate a game map with that logic discussed above.

It's almost starting to look like a video game!