_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Wire them to the /SO input? (Set Overflow)

Oh, wait.. !

It's true you could latch m and x externally then use a pair of VIA pins or similar to read back the outputs of the latches. I don't think the timing would be a such a challenge as you suggest, and btw an edge-triggered flipflop could capture m and x just as a latch could.

But m and x can be read in an alternative way (not a necessarily better or worse way; that determination will vary depending on prevailing priorities and circumstances). Use software.

The example below could be refined, and I think code like this has been discussed in the past. But, off the top of my head, here's how you can test m, for example:
If m=0 (ie, 16-bit memory & accumulator) then the '816 will interpret the code as I've shown it, and the carry flag will remain cleared. But if m=1 (ie, 8-bit memory & accumulator) then the '816 will interpret the code in the following way, and carry will be set.


The trick works because the BIT includes an immediate operand whose length will be 8 or 16 bits, depending on m. This means that the $38 may or may not appear as its own separate instruction -- SEC. To test the result, all that remains is to do a BCC or BCS, according to your own needs.

Edit: There are several immediate instruction involving A that will work, but I chose BIT because it leaves A unchanged. CMP also leaves A unchanged, and that was actually my first choice... until I remembered that CMP updates carry, thus interfering with what I'm trying to achieve. Doh!

For testing test x (instead of m), the same technique applies using immediate instructions involving X or Y. But the instructions BIT X and BIT Y don't exist, and CPX and CPY would interfere as noted, so the available options are somewhat less convenient. For example you could LDX# $3800. X would get bombed, of course. But carry would still get the desired result.

I know how you feel! I, too, am bugged by the fact the MX pin lacks a raison d'etre that's clear and solidly convincing.

At least the E pin is somewhat better off. I and others have used it to signal to the outside world that power-on initialization is complete. E could trigger a change in clock speed or RDY behavior following a low-speed copy of a laggardly boot ROM to RAM. And/or it could trigger a change in address decoding following such a copy. Those are two examples that come to mind. And using E to control a status LED is perfectly valid too, of course. Got to find problems for these solutions!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I can imagine MX being used to show status on a front panel, but I can't immediately think of a use for a hardware gadget which responds to them.

( Oops, my hastily written example code needs some tweaking! )

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The hastily written code has now been hastily edited, and will work properly now (I hope). Instead of BIT# $3800, the original version used CMP# $3800.

It's a tad confusing. The contents of A prior to the CMP would actually be immaterial. It's true that if A's contents vary then the result written to carry will vary. But the goal is for that instruction to not affect carry at all. (That's why I had to go fix what I'd written!)

Edit: Alright, "immaterial" is putting it too strongly. We could get the wrong answer or the right answer. But even the right answer would be for the wrong reason. Contents of A isn't supposed to be a factor!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Since you can do
sep #$30
rep #$30
which turns MX output high or low with single instruction in 3 clocks, it should be possible to use MX as bit-bang serial transmitter or like Sheep64 had suggested, a WS2812B LED driver.

Hmmm, that's interesting enough to break out my CRC816 board and try it...

Bill

Here is a bit-bang transmitter using MX output. The part that tripped me up is REP #$30 instruction set index registers to 16-bit mode so I need to use the assembler directive ".i16" to force 16-bit addressing. Similarly, SEP #$30 instruction set index registers to 8-bit mode, so I need to use the assembler directive ".i8" to force 8-bit addressing. Once I figured that out, the bit-bang transmitter worked pretty well.

The routine to bang high bit is not symmetrical to routine to bang low bit, so I measured the bit duration with scope and adjust the constant to get 8.6uS bit duration. Crude, but it works.
Bill

OK, a possible use: some kind of instruction-set enhancing gadget, or some instrument which needs to parse (disassemble) the instruction stream, may well need to know the state of the M and X bits, as well as the E bit.