Writing self-modifying code. I feel so naughty. #CommanderX16
Off-by-one errors are annoying. Off-by-one errors when working in 65816 assembly are double annoying.
#CommanderX16
Passing arguments via the stack on a 65816 is extremely error-prone.
#CommanderX16
Back from my day job business trip with a few orders to fulfill! But as teased, here's a video showing off TurboWave and TurboTracker using several PCM samples (and a few wavetables)

https://www.youtube.com/watch?v=t2Tmajb0Ww4

#TurboWave #TurboTracker #CommanderX16 #Chiptune #ChipSky #Wavetables
TurboTracker: Mediocre Demosong Using Samples!

YouTube
Looks like I may have found another bug in the #CommanderX16 emulator. Not even going to investigate further. The broken instruction is easy to replicate with a bit of self-modifying code. I kinda love 8 bit bare metal coding.
Just used the 65816 mvn instruction for the first time. A bit fiddly, but useful. #CommanderX16

On another annoying note, I am back on the #CommanderX16 track. I patched the emulator, made some progress with porting my old gen 1 code to the gs and then hit another emulator bug.

Can't figure out how to fix it, at least not with the time I am willing to allocate to the task. So I am doing workarounds while porting now.

This really is not my day.

Finally got around to build the #CommanderX16 emulator myself (with the GS fixes). And now nothing works. Apparently I broke several things during cleanup while I didn't have a working emulator.

There is a lesson in this: Never modify assembly code while you do not have the ability to test it.