On 7/9/06, Patrick McNamara <[EMAIL PROTECTED]> wrote:
So I sat down this afternoon and flushed this out a bit. Here is Timothy's original program (bugs and all, plus my new ones :) ) in the new instruction syntax. This assumes a sync polarity register. Flags are asserted if specified.
One of the reasons I designed this controller is to make the hardware simpler. So having this config register seems to run counter to that. Similarly, with Jared's work-around for the lack of a double-return, I'm inclined to remove that logic too. I'm also thinking about removing the initial starting address register (and hardcoding to zero). We should also look for other ways to shrink the design. The hardware should be just bare minimum for us to do what we need. Convenience to the assembly programmer is irrelevant. I think what we should have is some assembler metadata. In the assembly, we can indicate the polarity of assertion, and the assember does the inversion as necessary. For disassembly, we can store some metadata past the end of the last instruction of the vertical program (inserted after the first instruction that is a JUMP or has the ret flag set and before the first subroutine so the disassembler can look for it). This data will indicate the assembler source metadata so that on disassembly, the polarities will be right. (Or, you can detect the polarities by scanning the program and determining which levels are most common, which is what I did in this one video chip that had to automatically detect polarity with no configuration). _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
