Alarm Siren wrote:
the only practical use I can think of for MX is some kind of in-circuit debugger
Yeah, MX could be helpful for that. Sampling the data bus when VDA and VPA are high will usually tell you what opcode is about to be executed (exception: at the beginning of an interrupt sequence the CPU fetches an opcode then ignores it), but the opcode alone isn't enough to fully predict the cycles to come. There's no easy answer for predicting cycle variability that results from branches taken and page crossings, but at least MX can predict the variability that results from m and x. Example: LDA takes 1 additional cycle if m=0, and LDY takes 1 additional cycle if x=0.
Otherwise, it does kinda seem that MX is a solution looking for a problem.
Hm, what about the nuisance that results when you generally like to keep m=0 (ie, 16-bit accumulator) but are forced to set m=1 before accessing an 8-bit I/O device, then set m back to 0 again afterward?
You could avoid the nuisance and just always leave m=0 if your hardware was smart enough to deselect the I/O device during the extra bus cycle.
You don't
need MX to do this, but it might be helpful. (The non-MX approach would be to have the hardware simply look for and prevent two succesive accesses to the I/O device.)
ETA: another non-MX approach is to map the I/O device in a way that interleaves some unused locations. For example,
address $xx0 maps to register 0 of the I/O device
address $xx1 maps to nothing
address $xx2 maps to register 1 of the I/O device
address $xx3 maps to nothing
etc
-- Jeff
_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html