I never understood why waitstates are so difficult to support.
Then again, I never really looked at the way the code works.
I sort of envision it working as an AM_WAITSTATE(cycles_to_steal) call within cpu-specific memory and i/o regions (this would be for 'simple' fixed waitstates for specific memory or i/o accesses, where the cpu clock divider and specific chip/device states are irrelevant; the ibm-pc is an example of this); and an AM_WAITSTATE_FCT(function_name) for more complicated spots which use different/optional waitstates depending on cpu mode/divider/value_written/etc.
The function would be passed the masked offset within cpu space, data for a write or read, and a cpu and device pointer(for AM_WAITSTATE_DEV?), etc. and would return the number of cycles to steal/waitstates for that particular access.
A good example of a (future)device which needs this is the PHP1500 tms5200-based speech module for the TI99/4(A), since the /READY line from the tms5200 controls the WAIT input for the main cpu; the tms5200 will halt the cpu during all reads and writes from/to it. (the exact number of cycles reads and writes take is determined by the state tables of the tms5200 and its zero or more VSM chips. This is one of those 'un-fun but inevitably needed' things to emulate.)
In addition, devices (and code in /machine/ ?) could 'force' waitstates (along with forcing cpu to catch up before waitstates are taken) using a cpu tag; this is important for the DMA chip in the ibm-pc iirc, and is also important for sprite chips which halt one or more cpus, used in all sorts of places.
This is all theoretical though, as I have NO idea how complex this would be to code. Judging by the fact that it hasn't been done, I guess its in the 'brain-bleeding' difficulty area.
Feel free to correct me if I'm wrong, though.
LN
Last edited by Lord Nightmare; 04/17/09 05:55 PM. Reason: add example
