keith
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.
What was the C code that produced the unwanted move.l instruction? As long as your pointer type is uint16_t (or unsigned short), then *p = value should produce a move.w.
Thanks Steve for taking the time to comment. I’ve got to take a look at my code to see exactly what I did — I probably used a 32-bit pointer, with thoughts of needing 32-bit ADDRESSES vs 16-bit data.
I updated my post to be more clear.
Not sure if you remember our past emails, but I did overcome the SDRAM memory controller issue, and even added 4MB 10ns SRAM for a framebuffer. This machine is coming along! It’s a 66mhz 12MB ram, flash-rom based 68K.