Quote:
how to make m and x appear as data somewhere
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:
Code:
CLC
BIT# $3800
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.
Code:
CLC
BIT# $00
SEC
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.
Quote:
solutions in search for problems
I know how you feel!
![Neutral :|](./images/smilies/icon_neutral.gif)
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