65816 E, MX pins

[Alarm Siren]

Been looking at the 65816 in more detail.... I'm curious what function the E and MX pins could serve. I don't really understand why it would be useful for the address decoding logic (or whatever) to know the information provided by these pins. Can any one enlighten me?

[BigEd]

E is emulation mode, that's useful so the glue logic could, for example, present a different ROM or different set of vectors if the machine is acting as a 6502 or as a native mode '816.

MX bits... maybe they'd help a logic analyser to make sense of the instruction stream, because to do that you do need to know whether a register or memory reference is going to be one byte or two. Outside of debugging, I'm not sure.

[Dr Jefyll]

BigEd wrote:

MX bits... maybe they'd help a logic analyser to make sense of the instruction stream, because to do that you do need to know whether a register or memory reference is going to be one byte or two. Outside of debugging, I'm not sure.

I suspect E and MX are all primarily intended as debugging aids.


For me E is a "free" one-bit output port. Yes there's the non-trivial encumbrance of having to enter and leave Emulation Mode in order to turn it on and off! But sometimes that's acceptable. Here's an example.

In a few posts in another thread I describe a "blind loader" technique for loading the RAM of a ROM-less computer under control of a microcontroller or remote host system. Usually the final step is to let fly and run the code, using the STEP / nRUN signal to switch from single-step to free-run mode. And one design option is for that signal to originate from E, thus reducing the number of connections from the microcontroller or remote host. (This bootup scheme also allows single-stepped code execution, including that which'd perform a one-time exit from Emulation Mode -- the default following reset.)

[jds]

I can't think of a user for MX apart from debugging, even then I'm not sure how useful it is. I'd have guessed that E would be useful if you were creating a system that was an upgrade of a 6502 based system, so you could alter the memory map or otherwise change the environment when in emulation mode to remain backwards compatible. Probably the only system that this is relevant for is the Apple IIgs, and looking at the schematics it appears that neither pin is actually used.

[White Flame]

Datasheet wrote:

These bits may be thought of as OpCode extensions and may be used for memory and system management.

I wonder if MX is supposed to be used in tandem with VDA to ensure atomicity of 16-bit data reads/writes on the 8-bit bus. It still seems like it'd be a real pain to use, though, with its weird 2-phase output.

[Alarm Siren]

Yea. I could vaguely see a use for E - as BigEd suggested you could present different ROM depending on whether you're in native mode or not, though I see little practical use since emulated and native modes use different vectors anyway - so you could just point them somewhere else depending on mode. But MX is just... weird. Why would glue logic (or anything else for that matter) need to know whether the registers are in 16-bit or 8-bit mode? Since all memory access cycles are, from the point of view of the glue logic, seperate 8-bit operations regardless of whether they're part of a larger 16-bit operation internally.

[Dr Jefyll]

Alarm Siren wrote:

Yea. I could vaguely see a use for E - as BigEd suggested you could present different ROM depending on whether you're in native mode or not, though I see little practical use since emulated and native modes use different vectors anyway

Yeah, I was thinking that, too.

White Flame wrote:

I wonder if MX is supposed to be used in tandem with VDA to ensure atomicity of 16-bit data reads/writes on the 8-bit bus.

Hmmm. I was gonna dismiss this notion, but now... dunno. Certainly it seems like a lousy way to address the issue of atomicity of 16-bit data reads/writes. It'd make much more sense to let the MLB output take care of that, since MLB also manages the atomicity of read-modify-write operations on the bus. As the doc says, "Memory Lock indicates the need to defer arbitration of the next bus cycle" -- which is exactly the protection we also need for atomicity of 16-bit reads & writes.

But the infamous Table 5-7 indicates MLB is active for read-modify-write operations only. Seems like they dropped the ball on that one, but maybe I'm missing something. Or maybe Table 5-7 is wrong. I have found typos there, but only tiny ones (so far).

[handyandy]

I agree with BigEd regarding the E bit. Anyone who has dropped a 65802 in a legacy 6502 computer would see the utility of mapping an additional native rom in bank zero. Then there are emulation mode rom routines in legacy machines that break in native mode even with MX set to 8 bits. Some legacy machines use the native mode vectors in rom for other uses or have no useful data in those locations. I was lucky to have an Apple IIe clone to play with and could map ram in where rom was and write my own vectors in to my own native code specifically COP, IRQ and BRK. If I were to take the next step and design a 65816 board for a legacy Apple IIe I would use the E bit in native mode to map in a flash ROM for bank 0 and include pointers there to jump long to code in higher memory (ram or rom).

I could see use of the MX bits for use in a cache system i.e. say M and/or X is 16 bits; read/write 16 bits at a time from/to ram via a buffer. The cpu would "walk" each 8 bit buffer. I've seen somewhat of this design in 68008 sbcs and Lee Davison's IDE interface.

MLB is for use in multi-processor systems according to the 65816 datasheet. How many of those are there?

Cheers!
Andy

[Druzyek]

Dr Jefyll,
What are you using the pullups for on the data bus in your schematic? Is the microcontroller going through them? Do you Z state them when the CPU is running?

[Dr Jefyll]

Druzyek wrote:

Dr Jefyll,
What are you using the pullups for on the data bus in your schematic? Is the microcontroller going through them? Do you Z state them when the CPU is running?

Hi, Druzyek. I posted my reply in the original thread -- thought it made more sense to put it there. Cheers! viewtopic.php?p=58408#p58408

[A0CBM]

I'm not real knowledgeable about the 65c816, but I am trying to learn. I remember in the past looking at the schematic of the dynamic ram refresh circuit of the Apple IIE and it required a clock that twice the system clock. Is it possible that the MX signal could be used for refreshing D-ram? Or is that not needed when using SIMMs.

[AndrewP]

E I've found useful for working out how many cycles an RTI instruction will take (that's so I can tell at what point the stack manipulation part of the RTI is done). M/X I've not found a (non debug) use for. I would have found a pin telling me that memory access is due to stack manipulation useful . I.e. VDA, VPA and VSA would be cool. Alternatively a pin telling me that the Bank Address BA is all zero would be pretty useful too.

..but if wishes were fishes...

[Dr Jefyll]

A0CBM wrote:

I remember in the past looking at the schematic of the dynamic ram refresh circuit of the Apple IIE and it required a clock that twice the system clock. Is it possible that the MX signal could be used for refreshing D-ram?

Unfortunately, MX is not a reliable clock source because it remains permanently high when m and x are both 1; also permanently low when m and x are both 0.

There will be a waveform on MX when m =0 and x =1, or vice versa. But it will be at the same frequency as the system clock, not double. That's because it's the system clock (ie, Phi2) that causes MX to switch between outputting m and outputting x.

-- Jeff

[plasmo]

It is possible to hook up MX directly to serial port transmit pin and bit-bang serial data out. Given a fast 65816 (14MHz), it is also possible to drive WS2812B directly with the MX pin thus serves as controller for RGB strip lighting.

viewtopic.php?f=4&t=6806&start=15#p89486

Bill

[Greg816v2]

I was planning on using E to bank out the ROM that needs to appear in bank 0 on startup and replace with RAM when entering native mode. As I understand the vectors still need to appear at the top of bank 0, so I'll just write what I need to the RAM.