On Feb 17, 6:14 pm, Sheldon Simms <wsspa...@gmail.com> wrote:
I don't think that's really necessary for this purpose, but it
might be useful to implement the CPU emulation as a cycle-by-cycle
state machine for other emulation purposes.
For example, that's the best way I can think of right now to switch
video modes at the exactly correct cycle. It would also let you
correctly implement some of the weird effects you see when switch
video modes in the middle of the displayed portion of a scanline.
Yeah, it's a lot of work though; probably why I haven't done it.
Just thinking about it now, another way would be to use 2 tables (per
CPU type) with contents gleaned from Sather's bus activity tables. One
table would be the cycle offset for the first memory access in the
instruction, which gives the cycle of any potential mode change. The
other table would be the last bus read if any, which gives the cycle
of the video data read.
Either way is a lot of work considering how little (or trivially) this
stuff is used on the II though. ;-)