(Inspired by Garth's text for the 6502, and because I have to figure it for the Übersquirrel, I've but together this list. I'd be grateful for corrections (which I'm sure are necessary) and comments, etc. Then at some point, we can hopefully get rid of the next line.)

*** THIS TEXT IS UNDER REVIEW AND SHOULD NOT BE TRUSTED ***

(Last change 7th Sep 2015: Replaced link to VDA backgrounder)

This is a list of all the pins on the 65816 processor, what they do, and what you can do with them. It is inspired by Garth Wilson's What Do I Do With the "Mystery" Pins, SYNC, RDY, S.O., Φ1, MLB, BE, and VPB? for the 6502 (http://wilsonminesco.com/6502primer/MysteryPins.html). Since there is some overlap, it is recommended that you read that text first -- some things are covered in more detail there and not repeated here. The information is taken from the WDC Data Sheets and various forum discussions, see the link list at the bottom of this text. (Image source: viewtopic.php?f=4&t=2883)

The pins are referenced by number, not by name, so you can systematically go through each one when installing a 65816. A "B" at the end of the pin's name means that it is asserted by going low, that is, the default state is high. At the end of each description, there is recommendation for simple, slow systems -- the "when in doubt" usage. Follow these recommendations at your own risk.


PIN LIST

01 VPB "Vector Pull" (Output). Is asserted (goes low) whenever any of the hardware vector addresses are being accessed during an interrupt request, the same behavior as with the 65c02 (where things get tricky depending on the manufacturer, see Wilson). You could use this signal to select and prioritize interrupts from several sources. VPB is also asserted during the execution of BRK and COP; it goes low during cycles 7 and 8 of the interrupt acknowledgement sequence. Note that if you are replacing a 6502 from a company that is not WDC with a 65816, you might have to use trickery because this is GND for other versions. -- In a simple system, leave this pin unconnected.

02 RDY "Ready" (Bidirectional). As an output, it is pulled low by the processor after WAI is executed, signaling that the 65816 is WAiting for an Interrupt. It is then pulled high again when an external RES, ABORT, NMI or IRQ interrupt is active. As an input, a low level will halt the processor, which can be used for things like single stepping, slow memory access, or DMA. After the return to the active high state, the processor will continue running after the next PHI2 negative transition. The processor will not stop after a WAI instruction if RDY has been forced to a high state. The STP instruction has no effect on RDY. If RDY is to be driven by another chip, use a Schottky diode, with the anode connected to RDY. -- If you are not going to use it, pull it up with a 3.3k resistor. Do not apply to VDD (+5 V) directly: If RDY is tied to VDD and WAI is executed, the 65816 will attempt to sink VDD, which is bad.

03 ABORTB "Abort" (Input). When asserted by a negative level, the current instruction is aborted (actually, it is completed, but the results are not saved, so it isn't really an abort), a bunch of interrupt stuff is done, and then control is transferred to the address saved in the Abort Vector at 00:FFF8 (emulation mode) or 00:FFE8 (native mode). For more detail, see BDD's Investigating 65c816 Interrupts (http://sbc.bcstechnology.net/65c816inte ... rupt_abort). This pin could be used for handling page faults in complicated memory systems, but that's rare, and the timing requirements are tricky. -- Normal people pull it up with a 3.3k resistor or tie it to VDD.

04 IRQB "Interrupt Request" (Input). If the disable interrupt flag of the processor is clear (CLI instruction), a negative level on this pin will start the interrupt sequence. In emulation mode, three bytes are pushed to the Stack -- the two bytes of the Program Counter (PC), high byte first, and the Status Register (P) -- and control passes to the interrupt vector at 00:FFFE-FFFF. In native mode, four bytes are pushed to the stack: the Program Bank Register (PBR) and then PC and P as with emulation mode. Control then passes to the vector at 00:FFEE-FFEF. When these vectors are accessed, the VPB pin goes low (see above). You can use the WAI (WAit for Interrupt) instruction to make sure the interrupt will be recognized immediately. For more detail, see BDD's Investigating 65c816 Interrupts (http://sbc.bcstechnology.net/65c816interrupts.html . -- Connect this pin to your interrupt lines.

05 ML "Memory Lock" (Output). Is asserted low during the execution of the read-modify-write (ASL, DEC, INC, LSR, ROL, ROR, TRB, TBS) instructions, which tells other players on the bus that it can't be used right now. Potentially useful for multiprocessor systems. -- Leave unconnected.

06 NMI "Non-Maskable Interrupt" (Input). A high-to-low transtion -- not a low level -- starts an interrupt sequence that cannot be blocked after the current instruction is completed. The current address and the Status Register are pushed on the stack just as with the IRQB sequence. However, the vectors are different: In emulation mode, control is passed to 00:FFFA-FFFB and in native mode to 00:FFEA-FFEB. Here, too, you can use the WAI (WAit for Interrupt) instruction to ensure immediate service. For more detail, see BDD's Investigating 65c816 Interrupts (http://sbc.bcstechnology.net/65c816interrupts.html . -- If you don't use this interrupt, tie it high by connecting it to VDD.

07 VPA "Valid Program Address" (Output). Together with the Valid Data Address (VDA) line (pin 39, see below) they tell the other hardware that the address is okay. This can be used to handle DMA schemes or caches. VPA is asserted during both the opcode and operand fetch steps. A table is used to explain them: The important part: when both are are zero, the address bus is in an undefined state and may change states more than once before becoming valid. This can cause non-65xx devices to misbehave. When both of them are asserted (high, "opcode fetch"), this is the equivalent to the 6502's SYNC line. Put simply, when either are high, the address bus is valid. This can be handled with an OR (or NOR) gate. BDD has a detailed discussion of what to do with these lines at http://sbc.bcstechnology.net/page007.html , and Dr. Jefyll offers a second description at viewtopic.php?f=4&t=3404&start=15#p40104. -- A careful design will qualify the address with a logical VDA OR VPA.

08 VDD "Supply Voltage" (Input). Where the power comes from. Connect to 5V directly.

09-20, 22-25: Address pins A0-A15 (Outputs). Same job with the 6502. The Address Buffer can be switched off ("set to the high impedance state") externally by the BE pin. -- Connect to address bus.

21: VSS "Ground" (Output). Connect to ground.

26-33: Data pins D0-D7/Address pins BA0-BA7 (Bidirectional). The 65816 can access 16 MByte of data, which requires 24 address pins. However, only 16 (9-20, 22-25; see above) are dedicated to the address. The other eight share double-duty with the data bus. Roughly: With the 6502, when PHI2 (Clock, pin 37) is high, the data is driven on the data bus (fans of Star Trek Next Generation will remember that "Data always takes the high road"). When PHI2 is low, neither the processor nor the system drives the data bus. This means there is "dead time" between individual reads and writes that is nominally half of the cycle. The bus is relinquished to the system. With the 65816, there is no more dead time: When PHI2 is high, the processor drives the data bus as usual. During PHI2 low, the processor drives the Bank Address to on these pins. This happens even in emulation mode, though only zeros are fed to the system.

(Note the address and data buffers can be switched off externally by asserting BE ("Bus Enable", pin 36) so that other devices can use the busses. See below for further discussion.)

There is a standard circuit in the 65816 data sheet for dealing with this situation:

For the data bus, use a buffer such as the 74ABT541, gated to high-Z-state when PHI2 is low. For the bank address, use a latch such as the 74ABT573 or 74ABT245 when PHI2 is high. If you only access the "original" 64 KByte bank, you don't need the latch. Note that this all becomes slightly more complicated because of the VDA/VPA pins. See the discussion about qualifying this circuit with those signals in this thread.

34 RWB, R/W "Read/Write" (Output). When high, the processor is reading data from memory or interface devices. When low, it is writing to them. This pin remains high during reset and is affected by the BE pin, see below. RWB should be qualified by O2 in systems using non-65xx devices, as D0-D7 are never valid data during O2 low. Many non-65xx devices have separate /RD and /WD inputs that require some additional logic on RWB. -- Connect to R/W on chips and glue logic, but note the discussion on VDA/VPA and the data pins.

35 E "Emulation Pin" (Output). Reflects the state of the processor's emulation bit (E). In other words, it tells you if the system is in emulation or native mode. Can be used, for instance, change the system memory map between emulation and native modes, or to power an LED showing the processor's state (if it remains in that state long enough). -- Leave unconnected.

36 BE "Bus Enable" (Input). When BE is low, the Address and Data buffers are disabled, as is R/W, letting other parts of the system access the busses. This is an asynchronous signal. Rarely used. -- Attach to VDD through a 3.3k resistor.

37 O2 "Clock", "Phase 2" (Input). The clock input for the processor. The 65816 is a bit fussy about the quality of the signal, so when in doubt, run it through a 74ABT74 flipflop to sharpen the waveform. -- Attach clock signal to this pin.

38 M/X "Memory and Index lines" (Output). Tells you if the the Accumulator (M) and Index Flags (X) are set -- like E, this gives you information about which mode the processor is in. Most people don't care, and it's hard to think some real-world use for this pin anyway. -- Leave unconnected.

39 VDA "Valid Data Address" (Output). See discussion pin 7, VPA.

40 RESB "Reset" (Input). Asserted (pulled low) for at least two clock cycles sets the 65816 back in emulation mode and starts the reset sequence. -- See http://wilsonminesco.com/6502primer/RSTreqs.html for a discussion of the circuit required.


LIST OF ADDITIONAL CHIPS

What this all means is that in contrast to a 6502, the 65816 will need some additional glue logic. Definitely required:

74ABT245 - Octal transceiver with direction pin, 20 pin DIP, as a latch for the Bank Address Bus
74ABT541 - Three-state octal bus, 20 pin DIP, as a buffer for the Data Bus
74ABT04 - Inverter, 14 pin, for connecting PHI2 to latch for Bank Address Bus

Recommended for some situations, but not necessarily showstoppers:

74ABT74 - D-type Flip-Flop, 14 pin DIP, to sharpen PHI2 waveform
74ABT32 - OR-gate, 14 pin DIP, for address qualification with VDA and VPA.

The ABT family is chosen for its speed.


LINKS

Comparing the 6502 pinout to that of the 65816: viewtopic.php?f=4&t=2883
Managing the 65816 Multiplexed Bus: viewtopic.php?f=4&t=2438
Replacing 6502 with 65816 in a Commodore: http://www.baltissen.org/newhtm/02to816.htm
DUART VPA/VDA problems: http://sbc.bcstechnology.net/page007.html
Mystery Pins of the 6502: http://wilsonminesco.com/6502primer/MysteryPins.html
Wikipedia: Interrupts in 65xx Processors: https://en.wikipedia.org/wiki/Interrupt ... processors

Well, you sure have been busy!


It should be noted that VPB is asserted during the execution of BRK and COP, as well during the processing of hardware interrupts. VPB goes low during cycles 7 and 8 of the interrupt acknowledgement sequence.


Actually, ABORTB is level-sensitive, which is somewhat unfortunate, in that some tricky timing is needed to correctly use it. WDC states that ABORTB should be toggled over a period not to exceed one Ø2 cycle. Otherwise, the abort interrupt handler itself may be aborted and it is likely that the aborted instruction will end up changing a register or memory. Some analysis suggests that bad ABORTB timing caused by faulty hardware logic may cause the MPU to "auger in."


It should be noted that WDC's circuit may not work as expected due not being qualified by VDA and VPA. The state of the MPU's D0-D7 pins is undefined when the expression VDA | VPA is false (where | means logical OR)—that is, during an invalid memory cycle. If the MPU is in such a state the above circuit will potentially latch garbage when Ø2 goes high. Complicating matters, if the MPU is being held in a wait-state due to RDY being negated, WDC's circuit will repeatedly unlatch and latch as the Ø2 clock cycles. Either of these conditions may trigger anomalous system behavior.

Also, the use of the inverter on Ø2 to condition the E input on the latch causes the latch to close slightly after Ø2 goes high, due to the inverter's prop time being added to the latch's internal response time to E's change of state. This may create a timing "race" condition in which D0-D7 may be driven with data slightly before the latch closes. This can be avoided by generating a two-phase clock from a D-type flip-flop (mentioned below), with one of the flop's Q outputs driving E and the other Q output driving the MPU's Ø2 input (as well as the Ø2 inputs of any 65xx I/O devices in the system).


RWB should be qualified by Ø2 in systems using non-65xx devices, as D0-D7 is never valid data during Ø2 low. Also, many non-65xx devices have separate /RD and /WD inputs, which will require some additional logic on RWB. Note that 65xx I/O devices, which are clocked by Ø2, do not need this qualification and will, in fact, not operate unless RWB and chip selects are valid prior to the rise of Ø2.


My POC V1.1 unit uses a 74AC74 flop, which has performed satisfactorily at 12.5 MHz. Note also my remarks above about using a two-phase clock to control bank latching.

Hope I didn't muddy the waters too much!

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

Very ambitious, Scot. This could end up being quite a long thread!

Trickery? A board could simply have jumper options to accommodate differences like this. Hmmmm... What might be handy is if you were to supply a chart that notes the various functions for pin 1, 5 and 36. (These seem to be the ones that vary between manufacturers.)

It seems to me the WDC circuit will latch invalid bank addresses just fine. Is that a problem? VPA=VDA=0 tells us when to inhibit memory and IO due to an address that can't be trusted. Every address is 24 bits, and the bank address is simply the MS 8 bits of that. I don't see any advantage if the WDC circuit were qualified by VDA and VPA as you suggest.

[Edit:] IO and memory are expected to retain their contents, which is why they require VPA/VDA's protection against invalid accesses. But there's no requirement for the latch to retain its contents. Updates are continuous, each relevant only to the current bus cycle. I guess that's what I should've said in the first place!

cheers,
Jeff

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

Oh, I don't doubt that the WDC circuit will latch whatever shows up on D0-D7. We're thinking in terms of memory and I/O, but what if the glue logic itself reacts in some unanticipated way to a bogus bank address? That is something the designer might want to contemplate.

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

Regarding bank addresses, "latching whatever shows up on D0-D7" is the full extent of that circuit's job description, isn't it? It seems to me that as long as the circuit succeeds in doing that then it's satisfactory.

If your concern is glue logic then it was confusing to instead criticize WDC's circuit (which can't be expected to prevent dummy bus cycles -- we're stuck with 'em!). But I'm happy to agree we need to keep our eyes open for unanticipated reactions.

I hope no-one overestimates the prospect of using VPA and VDA to qualify the enable input of the latch, keeping it low during dummy cycles (VDA=VPA=0). Although that will prevent an invalid bank address from appearing in the latch during a dummy cycle, what will appear instead is the leftover bank address from the previous cycle.

That means the bank address is running a reproduction of the previous cycle -- while other signals such as R/W and A15 - A0 are running the actual cycle (the dummy). Even if those other signals were also reproduced, it's still doubtful whether you'd want that cycle overlaid, glue-wise, on the dummy cycle. (For example, if the previous cycle triggered a wait-state, do you want that behavior for the dummy? Probably not.) To be attractive, the idea of qualifying the latch with VPA/VDA needs to offer a desired behavior and compare favorably with alternative remedies which are quite simple. I certainly wouldn't view it as a magic bullet or a routine precaution. [Edits...]

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

Thanks to everybody for the additions, I've included them as far as I understand them . The whole VPA/VDA is a serious pain in the rear, and by now, I'm wishing they had done something different -- you know, like adding eight address pins.

Just out of curiosity, has anybody ever used the E and M/X pins to, say, have a LED go on that shows which modes the processor is in? I'm wondering if it would even be worth the effort, given how fast they would probably switch.

Thanks again!

Urk! I know you're being somewhat humorous here, Scot, just as you were when you mentioned "trickery" in regard to the VPB output. But it's a mistake to view VPA/VDA as a pain, and I feel partly responsible since I'm among the references you cited.

VPA/VDA is merely the messenger, not the creator, of a potential problem that pertains to all 65xx processors -- not just the '816. I agree it'd be nice if the '816 had eight more address pins, but VPA/VDA signals would still be just as worthwhile. The potential problem is dummy cycles, and they occur on the '816 as well as the '802 and both NMOS and CMOS 6502's. The dummy cycle potential problem has been around since Day One. I emphasize "potential" because actual manifestations are fairly uncommon. Otherwise the 65xx family would've been a failure.

BDD is one of the unlucky few who got bitten, and in the link you provide he explains how he successfully resolved the issue. VPA and VDA were part of the solution, not the problem. (The solution was to use them to qualify I/O accesses.)

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

The finer "granularity" of the VDA and VPA combination can be useful in various (possibly arcane) ways over and above telling the circuit when a bogus bus condition exists. Complex logic could be used in conjunction with these signals to help police the use of verboten instructions or using instructions with dubious operands, detect attempts to get instructions and operands from places where they should not be gotten, detect attempts to address memory where it should not be addressed, etc. The E output could be used to detect inadvertent switching from one mode to another. Combine all that with judicious use of ABORT and it would be possible to set up a protected execution environment.

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

An LED triggered by the state of E would be feasible, assuming the '816 stays in either mode for at least a fraction of a second. Not sure what value that might be, however.

M/X would change state too fast in many cases to make an LED feasible. Also, M/X's meaning depends on the clock phase. Both E and M/X are really intended for use with logic that triggers specific events. I have an idea where E might be useful but have yet to think of a use for M/X.

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

I think VDA and VPA are overestimated. They could be useful in many complex systems, but the effort is not worth it. The same goes for E and M/X. I typically don't want to spend the real-estate on the PCB to do something with these bits and my CPLD and GAL designs always lack of input pins. So I'm happy ignoring all these signals. For a simple and normal 65xxx systems this worked very well up to now. Only once I used VDA connected to the active high enable input of a 74HCT138 decoder as I was desperately debugging a IDE interface only to find out that the IDE device did not like the order of how I sent the command bytes. The WDC document describes in all the details what addresses are present on the address bus for every cycle, so you just avoid the addressing modes that might create a conflict when accessing IO devices. With memory this is definitively not going to cause any issues as all "undefined" cycles are read cycles and neither ROM or RAM care about spurious reads. The only case I can think of is when you want to write enable an EEROM, but since I have decided to use my IML (or "blind loader" how Michael called his implementation) mode to load a ROM image into a system, this is again not of any importance. And if it is, avoiding possibly disturbing cycles for that purpose is easy. For the 65C816 there are no "verboten" opcodes as it makes use of all 255 possiblities and one exception that does nothing. As for the 65C02, invalid opcodes are treated as NOPs and the 65C02 lacks VDA, VPA, E and M/X alltogether.

My guess is that when BDD said "verboten" it is in relation to setting up a protected execution environment (as BDD wrote later in the paragraph). Because in a protected environment (e.g. one with a multitasking operating system) you would define some instructions as privileged, and make those illegal for user level programs.

-Tor

I don't know but in that case priviledged opcodes would be a better name. Still then this would be a rather complex system and as I said these signals might be usefull but not in a normal system.

You could also use VDA and VPA to implement a Harvard architecture, separate address spaces for code and data. And VPB could be used to implement a vectored interrupt scheme.

And you can use E to change the system memory map between emulation and native modes, something that I actually have planned to do in order to map ROM into the $C000-FFFF region in emulation mode, and RAM in native mode.

Correct. Whatever term is used to describe these instructions, they would either be instructions that should never be executed (STP immediately comes to mind) or should not be executed when the system is operating in user mode.


Use of VDA and VPA is as simple as connecting them to an OR (or NOR) gate, which is all that is needed to qualify bus cycles. It certainly isn't complicated. In a pinch, a couple of fast Schottky diodes and a pull-down resistor will work as a "gate."


Why would you want to intentionally avoid useful addressing modes as an alternative to implementing VDA and VPA? Also, you may consciously avoid addressing modes that generate bogus bus cycles, since you know your hardware has the potential to malfunction in such cases. However, if someone else acquires one of your devices he or she may not know that.

With some non-65xx I/O devices there could be quite a bit of configuration required following reset (the 16550 and 26xx NXP series UARTs immediately come to mind). The most efficient way to carry out that configuration is to use indexed addressing to read a data table of registers and the values that are to be loaded into them, followed by indexed addressing to write to the registers. With the '816, such programming demands VDA and VPA qualification, since indexed addressing generates at least one bogus bus cycle per instruction.

So VDA and VPA are hardly overestimated and do assist in resolving a problem that, as Dr. Jefyll noted, is potentially present in all 65xx MPUs.

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

I'm still not convinced, because this

will result in a highly complex system. In my opinion the out of the box 6502/816 is not suited for a protected OS. In addition this would not only require inhibiting privileged instructions but also some sort of memory protection scheme, which, especially for the stack, will be very tricky. Without a dedicated supervisor mode stack pointer it is in my opinion near to impossible. If you are interested in building a protected OS you should rather look at other "legacy" architectures which are as well fun to play around with. For this I have my DCJ11A based SBC.



As I said, my designs lack of PINs, no matter how I design a system, I always end at the point where I have to remove functionality in order to match the capabilities of the GAL/CPLD and VPA/VDA are one if the first signals that are eliminated.



Today memory size and ROM image size is mostly of no concern, so the very few bytes that avoiding these addressing modes could incur are not relevant. And even then, by using tricks like not using X=0 as the first address but instead using X=$80 and using "sta <address>-$80, X" you can avoid spurious access to IO registers even when using these addressing modes. I don't think that this will be overlooked by others. Keep in mind that the good old 6502 showed the same invalid cycles and has none of these output signals and still everybody could work with that. Just look at the way IO registers were accessed in a Apple II system.

I think that the percentage of cases where VPA/VDA are required or useful is very low.