If you saw my recent post about malformed circles, you’ll see that I was pulling my hair out.
I identified the root cause. It turns out that I was writing 0x00000fff, which caused the pixel I was setting to be black, 0x0000. Worst of all, it was also writing the pixel next to it! It was writing 0x0FFF to the pixel to the right, which causes the pixel to the right to be all white. Pretty insidious! Had it not produced anything on the display, surely I would have tracked down this sooner.
I’ve been playing around with a variety of solutions, and compiled the midpoint circle algorithm C code into assembly, and the move.l instruction was created by the compiler, from my faulty C code.
The correct instruction was one that just modified the 16-bit word at the address in question, the move.w #$0fff, (a4) instruction. The other one, the move.l #4095, (a5) was the problem one.
UPDATE: Just to be clear, there’s no problem or bug with the compiler. I used the wrong data type, likely a 32-bit int or similar(or perhaps a uncast constant assumed to be 32-bit), in the C code, which caused the unwanted move.l instruction to be created. This was entirely my fault. For what it’s worth, this is my first time with more than 10 lines of 68K assembly in decades. I wasn’t good back then, either. 🙂
I still have to create a toolchain for my machine. Remember there are no sample programs, no documentation, no faq’s, so I’m still figuring out how all of this works. I don’t have a properly configured C compiler, with memory areas dedicated for stack, heap, and lord knows whatever else I have to configure. I’m happy to be turning the corner from hardware development to something that is actually USABLE from a software developer perspective.