Quote:
When you mentioned triple-byte increments, I misunderstood, maybe, and pictured an operation performed byte-serially in three pieces. Doing it that way means if there's no carry you can take an early exit and save cycles (or one, at least). If the triple-byte value lives in 8-bit external RAM, that idea seems like a win. But I think you're anticipating Direct Page will be in on-chip RAM, is that right? So you can grab 24 bits at once? If 16 bits at once is easier, you could still break the 24-bit operation down into two pieces.
Yes, the increment is byte serial. I modified the core to skip the store on a RMW instruction if the high-byte didn't change.
I think I'm scrapping the triple-byte increment mode, in favor of a couple of 24 bit counters I/O devices located in zero page. I coded the counters at the MPU level. Leaving the cpu alone. With the CPU clock so fast, 24 bit counters rather 16 would be more useful. It's also possible to trigger a count cycle in software, so the counters could be used as interpretive pointers as well. I have the one counter operating as a down counter to generate periodic interrupts. It takes 19 bits to divide down to 100Hz from the cpu clock.
Quote:
But I wonder whether, deep in its heart, FT816 wants to be a native 24-bit machine. (Or 32/24-bit.) I mean with downgraded 8/16-bit modes to match the 65816.
I have to resist temptations on that one. The thought of full 24 bit registers did cross my mind.
I've managed to find some free opcode space in the 65816 instruction set - it's the branches. A branch displacement of $FF is a no-no, so the branch opcodes could be reused if the displacement is $FF, to mean something else. I've though of using them as prefix codes and maybe stealing some from Michael's cpu core.
Login
Register
FAQ
Search
