65C816 “STRANGE” OUTPUTS

[BigDumbDinosaur]

Along with its other features, the 65C816 added some “strange” outputs that, at first blush, seem to be solutions in search for problems. I'm referring, of course, to E and MX.

E reflects the status of the hidden e bit in the status register (SR). When e is 1, as it will be following power-on or a hard reset, the 816 is in 65C02 emulation mode, and E is driven high. When the CLC - XCE sequence is executed to switch the 816 to native mode, e becomes 0 and E is driven low. Simple enough.

MX is a little more convoluted, as it is two distinct signals multiplexed onto a single pin. WDC describes it thusly:

Quote:

2.20 Memory/Index Select Status (MX)

The Memory/Index Select Status multiplexed output reflects the state of the Accumulator (M) and Index (X) elect flags (bits 5 and 4 of the Processor Status (P) Register. Flag M is valid during PHI2 negative transition and Flag X is valid during PHI2 positive transition. These bits may be thought of as opcode extensions and may be used for memory and system management.

Can you say “awwwkward?”

Unlike MX, using E is straightforward, since it is not affected by the clock phase the way MX is. Hook it up to something and if that something sees a logic 1 the 816 is in emulation mode. I'll get back to that in a minute, as I did find a use for E in my (still-under-construction) POC V2.0 unit.

In order to use MX, two latches are needed to produce separate outputs corresponding to the m and x bits in SR. One latch would be open during Ø2 low and thus would capture m's status. The other latch would be open during Ø2 high and would thus capture x's status. Realistically, a clock generator producing Ø1 and Ø2 signals would be needed to capture and latch these signals without getting into potential timing contretemps.

In an 816 system with a latch to capture A16-A23, Ø1 would be present, although the technique of inverting Ø2 to produce Ø1 will result in Ø1 lagging Ø2 by the propagation time of the inverter. With that prop time in the picture, it's conceivable the m latch could briefly see x before closing in response to the transition of the clock, and vice versa, leading to possible wrong outputs.

Hardware matters aside, the real puzzler for me was finding a use for either of these signals. However, a use for E soon presented itself.

In the firmware, power-on/self-test (POST) occurs in stages. During the first stage, several critical areas in bank $00 RAM are destructively tested, as the system will be unstable or not run at all if there are memory defects in those areas. Hence I/O isn't possible during stage one POST, since the serial I/O driver makes extensive use of two of these critical area. This means memory test failure can't be announced on the console. I didn't want to add a piezoelectric buzzer just to make noise due to a memory fault, so I had a dilemma.

The solution was to wire E to an unused gate in a 74AC14 Schmitt inverter that handles several other circuit functions. The output of that gate drives a LED that will illuminate when E is high. I originally planned to wire the LED directly to E, but decided I didn't want to impose the load on the 816.

Normally, the LED would be dark, since the 816 is switched to native mode at the beginning of the reset handler. Should a memory fault occur, the 816 will be switched back to emulation mode and halted with STP (SToP). That will cause the LED to illuminate, signaling to Houston that we have a problem. The LED, which is red, is labelled MCE in the schematic and on the board, MCE meaning “machine check exception.”

That leaves MX. Very recently, I had said I couldn't think of any use for that output. Well, more thinking—always a dangerous activity on my part, revealed a possibility.

Missing from the 816's extensive instruction set is a way to determine what the current register sizes are without clobbering at least one of the registers. There is REP and SEP to clear/set SR bits, but no corresponding instruction to report the status of m and x. I've encountered a number of programming applications where it would be useful to know that status without having to touch any registers. So it does appear MX has a useful purpose in life.

The question is how to make m and x appear as data somewhere in a way that can be tested with the BIT instruction. Anyone want to toss in their two cents on this?

[Dr Jefyll]

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: Select all

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: Select all

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! 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

[BigEd]

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.

[Dr Jefyll]

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

[BigDumbDinosaur]

Dr Jefyll wrote:

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

I was going to say it won't work if the accumulator is loaded with $3800 or higher. MX to the rescue!

BTW, when I said “latch” I was speaking in a generic sense, not necessarily meaning a literal latch. Anything that can “latch” MX would work. I could see putting a C-D flop to work on this, one section handling m and the other handling x.

[Dr Jefyll]

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.

BigDumbDinosaur wrote:

I was going to say it won't work if the accumulator is loaded with $3800 or higher.

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

[BigDumbDinosaur]

Dr Jefyll wrote:

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.

That's all well and good, but it doesn't use MX, which is what this topic is all about.

[plasmo]

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

[plasmo]

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

Code: Select all

;Use MX output as bit-bang transmitter
;CPU clock is 14.7MHz
;serial setting is 115200 N81

	.p816
	.ORG $1000

	CLC
	XCE		;switch to native mode
	.i8
	LDX #0
	LDA hello,x	;get sign-on message
signon:
	JSR transmit
	INX
	LDA hello,x	
	BNE signon	;null terminated message
	
	SEC		;switch to emulation mode
	XCE	
	JMP $b400	;return to monitor
; bit bang transmitter	
; Accumulator has the data to be sent
; Use REP #$30 to drive MX low
; Use SEP #$30 to drive MX high
transmit:
	.i8
	PHX
	REP #$30	;START bit, drive MX low
	.i16
	LDX #23		;start bit, 8.6uS
Startbit:
	DEX
	BNE Startbit
	LDY #8		; 8 data bit
bitbang:	
	ROR A		;bang out a bit
	BCC bitLow
;bang out a high bit
	SEP #$30	
	.i8
	LDX #23		;bit duration is 8.6uS
bitH1:
	DEX
	BNE bitH1
	DEY
	BNE bitbang
	SEP #$30	;stop bit
	.i8
	BRA Stop1
bitLow:
;bang out a low bit
	REP #$30
	.i16
	LDX #22		;bit duration is 8.6uS
bitL1:
	DEX
	BNE bitL1
	DEY
	BNE bitbang
	SEP #$30	;stop bit
	.i8
Stop1:	
	LDX #22		;bit duration is 8.6uS
Stopbit:
	DEX
	BNE Stopbit
	PLX
	RTS
	
	
hello:	.byte "Hello World",$a,$d,$0	

[BigEd]

BigEd wrote:

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.

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.