First steps...

[BigDumbDinosaur]

barrym95838 wrote:

BigDumbDinosaur wrote:

... There is a reason why A is used to represent the accumulator in instructions that can act on the accumulator or memory, but it seems that relatively few folks understand it. Call me a gruff old curmudgeon, but I am not much of a fan of assemblers that significantly deviate from the MOS Technology/WDC formal syntax. In my opinion, there's no good reason for doing so.

Well, I'm not as gruff and old as you, so I favor the format with which I learned 6502 assembly, shortly after I got my Apple ][+. Woz grouped the accumulator addressing mode with the implied, simplifying the disassembler and assembler...

That's common practice in machine language monitors, since they do not have symbolic assembler (your image is of a monitor disassembly, not the listing output of a symbolic assembler). Jim Butterfield's Supermon 64, as well as the Commodore 128's resident monitor, do the same thing, since by default, an operand without a radix is presumed to be a hex number. Hence INC A would be understood as INC $0A and would assemble as $E6 $0A.

However, in a symbolic assembler that conforms to the MOS Technology/WDC standard—which standard has existed for some 38 years and was derived from the MC6800 assembler, instructions that can act on either the accumulator or memory are required to have an operand so the assembler can differentiate between the two addressing modes. Hence, ROL A is unambiguously understood as rotate the accumulator, whereas ASL $0A clearly means that it is the content of $000A that is to be rotated. The assembler prohibits the definition of A as a symbol.

[BigDumbDinosaur]

cr1901 wrote:

The other mnemonics are less useful to me, but I can understand why they exist... who typically refers to the accumulator- in either mode- as "C" (although that is technically correct)?

In comments I write into my programs, I always refer to the accumulator as .C when it is expected to be in 16 bit mode—.C is a mnemonic device to remind me which register width is required. If in 8 bit mode, then I always refer to it as .A and .B. The one exception is if I want to zero .B and the accumulator is already set to 16 bits. The I will explicitly comment that I am clearing .B, e.g., with AND #%0000000011111111.

It's important to understand that the .B accumulator doesn't go away when the m bit in the status register is set. Also, if the x bit is clear but m is set and a TAX or TAY is executed, .B gets copied to the MSB despite the accumulator being 8 bits wide.

Use whatever helps you remember, but keep in mind that if you publish your code others may not necessarily understand your thinking.

[BigDumbDinosaur]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

the NXP 28C94 quad UART I'm going to use in POC V2 has the ability to identify why it is interrupting by placing a bitwise code on the data bus when commanded to do so.

Just a clarification: when commanded to do so by driving a dedicated input, IACKN, low.

Correct on /IACKN. There is also an "update CIR" command which is written into register $2A (update CIR) to get the 28C94 to "spill the beans." I'm still familiarizing myself with the device, as its interrupt system is more complex than the 26C92. There are 18 possible interrupt sources, which would mean a lot of polling if you do it the "old fashioned way." Using the device's "bidding" system, it should be possible to eliminate much of the polling.

[cr1901]

Now I'm getting somewhere... I have about half a schematic complete for R1, and I'll probably upload a flowchart tonight.

R1 will run on an 8-bit ISA perfboard card, which gives me access to power without needing to create a power supply, as well as a host environment I am familiar with to upload programs to RAM. The 65816 will run an EPROM monitor which polls for input/output from the PC, but can also use the on-card serial port to talk to the outside world. Serial port is interrupt-driven and will override ISA host commands. It'll be used mainly used for querying status of R1 from the '816's point-of-view, as well as file xfer in ROM monitor mode, and "free for use" otherwise. R1 will (tentatively) contain 8kB of EPROM and 16kB of SRAM. R1 can communicate using the serial port for a small terminal on an external host, or via 5 registers on the computer with the ISA card (BASE can be whatever is free in the PC map). I've modified the address space based on suggestions from the Primer and BDD to minimize the amount of address-decoding logic.

From the PC, the IO map is as follows:

• BASE Data In (Write)/Data Out (Read) (Host ISA PC uses port-mapped I/O to talk to R1)
• BASE+1 Command (Write)/Command Status (Read) (Host ISA PC send command to processor while running ROM monitor/poll routine)
• BASE+2 Control Register (controls a latch whose bits propagate to enable/disable various circuitry on the board- such as the clock/RDY (The latter is probably more kosher), debug IRQ, single step, and ROM monitor vs RAM program mode.)

What I haven't decided yet on is the following:

• Clock circuit (use the Primer? I have a 10MHz 4 pin crystal FWIW)
• Reset circuit (Probably needs to be OR'ed with the ISA reset pin)
• Single step circuit (will be enabled using a bit on the control register)
• Bus arbitration circuit (see below)
• Wait state circuit for ROM (this is the tough one- any help here to minimize glue logic is greatly appreciated).
• Minimal logic ROM/RA switcher (in RAM mode, the vectors need to be stored in RAM in case they are altered)

IO map on the '816 side isn't fully decided yet, but I want R1 to end with having a PIA, VIA, ACIA, RAM, ROM (can be swapped in/out), and '816.

I feel this should be a simple and fun project that bridges my enjoyment for programming the '816 and the ISA bus. Since I'll keep the '816 in Native Mode even without > 64kB of RAM, for slow systems like the XT, the '816 becomes a vastly superior coprocessor . For faster systems, R1 just becomes a unique expansion, interface, and development (EID? ) environment/card.

I haven't fully decided the schematic output, but one thing that will influence my decision: Can ONE port of the PIA be used as a simple bidirectional bus arbiter using the handshake signals- for instance, attaching the 65816 to the ISA bus. In all cases, the x86 PC takes priority in case of conflict with the 5 I/O registers. I'd like to minimize on external latches and use the PIA to its full potential.

[cr1901]

cr1901 wrote:

I haven't fully decided the schematic output, but one thing that will influence my decision: Can ONE port of the PIA be used as a simple bidirectional bus arbiter using the handshake signals- for instance, attaching the 65816 to the ISA bus. In all cases, the x86 PC takes priority in case of conflict with the 5 I/O registers. I'd like to minimize on external latches and use the PIA to its full potential.

I'm bumping this to get some feedback. I know the timing requirements are different between an x86 and 65xx bus, but does anyone think it's possible (feasible) to use a PIA as a latch for the ISA bus?

There's pretty much a guarantee that the ISA bus clock and the clock I use to drive the '816 will be out of phase. If I use the handshaking signals of the PIA to hold the current value being input to one port from the ISA bus, and to arbitrate when to output-enable a TTL buffer attached to the other port (output mode) of the PIA, that resolves some synchronization issues. Idk if it can be done, but I think it's worth a shot.

Since I don't think the PIA's output port can be Z-stated, I still need a 3-state TTL buffer to "block" the PIA's output from reaching the bidirectional ISA data bus. Nevertheless, it does save me glue logic if this can be done.

[Dr Jefyll]

Quote:

Since I don't think the PIA's output port can be Z-stated, I still need a 3-state TTL buffer to "block" the PIA's output from reaching the bidirectional ISA data bus.

If I understand correctly, you want the '816 to write a value to the PIA port output register and have that value drive onto the ISA bus, but only when the ISA reads the appropriate IO address. Otherwise the PIA goes high-impedance and doesn't drive the ISA bus, leaving it free to do its own private ISA business.

The PIA port can be put in the input state, which is high-impedance and won't interfere with the ISA. Unfortunately to do so requires the '816 to write $00 to the Data Direction Register (DDR), and a software command is not appropriate. What you want is for the port to either drive or go high-Z according to a hardware signal, such as from a IO decoder supplied with the ISA address.

A good chip to consider for this sort of job is the 74hc646 registered transceiver. This could tie the IAS and '816 buses together without need for the PIA.

-- Jeff

[cr1901]

If I'm perfectly honest, I'm just looking for a way to use the PIA's handshaking mode- since I bought two by accident, I might as well use them to their full potential.

The 3-state buffer TTL on the PIA's output is what will prevent the PIA's output from driving the ISA bus. I just want to use the PIA's handshake signals to ensure the ISA bus is happy with the xfer in case the PIA needs more time to react (add wait states to the ISA bus for 14MHz and above machines).

From the POV of the IBM PC that houses the ISA card, the PIA is the destination/source of the IN and OUT instructions. It is how the IBM PC communicates with the card, transferring data back and forth. This saves me some TTL logic, and lets me put the PIA to good use.

[BigDumbDinosaur]

Dr Jefyll wrote:

A good chip to consider for this sort of job is the 74hc646 registered transceiver. This could tie the IAS and '816 buses together without need for the PIA.

The 74HC646 also available in 74AC and 74ABT logic, both of which are significantly faster that the 74HC part, as well as producing stronger drive.

sn74abt646a.pdf

74ABT646 Registered Transceiver

(908.25 KiB) Downloaded 108 times

You'd also have to think about how you would handle IRQs from the ISA bus.

[cr1901]

BigDumbDinosaur wrote:

You'd also have to think about how you would handle IRQs from the ISA bus.

Don't need to handle them at all- ISA cards can only send out IRQs, not receive them. And I have no (compelling) reason to send interrupts to the PC from this ISA card. If you're referring to receiving data from the PIA, well doesn't the PIA have an IRQ for when data is received?

I can get away with the following signals: A0-A9, D0-D7, AEN (Distinguish DMA from CPU access), IOW (x86 port IO write) and IOR (x86 port IO read). I may also use the 14.3MHz Oscillator (OSC) that the ISA bus provides by convention as the clock for the card (or maybe halve it for now).

[satpro]

BigDumbDinosaur wrote:

The VPB output could actually be used in several ways. As discussed, its intended purpose is to let external hardware know that the 65C816 is loading the program counter with the relevant interrupt vector. Sufficiently sophisticated logic could alter the apparent vector according to the source of the interrupt. As noted, a priority encoder would be necessary to determine which vector should be loaded. Discrete priority encoders tend to be slow devices (they have a lot of gates), so a CPLD or FPGA would be better suited to the task. Implementation of vectored interrupts could produce a big payoff in performance.

I realize I'm way late to the game on the VPB topic so I apologize, but the SuperCPU is a good example of a use for the VPB signal.

SuperCPU Interrupts.pdf

(718.16 KiB) Downloaded 109 times

SuperRAM Common Memory Map.zip

(683.34 KiB) Downloaded 95 times

[cr1901]

Part I
I'm reading the primer, and I realize: there is no way I can get around wired-OR output. I'm willing to suffer the consequences of this, but is there any way to reliably use Wired-OR in a 10MHz+ system? I have an ACIA IRQ, PIA IRQAB/IRQBB, and VIA IRQ (series Schottky diode) in my design.

Part II
I think I still have my heart set on using the PIA as the ISA bus controller even if requires external components.

The CPU responds to all writes from the ISA bus. Port A is used storing data that comes from the ISA bus. Assuming the active transition is set appropriately, CA1 is attached directly to the AND of address-decoding logic output for the ISA bus and the IOW control signal from the ISA bus.

I.e. if the x86 IO port matches and it's an IOWrite, CA1 will be asserted via active transition, and the PIA will inform the microprocessor that data is about to be latched into a 8-bit latch that feeds into Port A. One problem with this is that the CPU reading the latch from the PIA might happen before the output from the latch is valid, but after the data has been clocked in (tCO- clock-to-output time on datasheets).

EDIT: Ignore following paragraph. I can just use NOPs to delay the read until tCO has passed if necessary.
I could alternatively skip this latch, and have CA2 feed into the IOCHRDY to the ISA bus, which lengthens I/O cycles, but the CPU would have to read data from the PIA very fast (2.5 microseconds) for this to work. I suppose I could pre-empt the IRQ and use WAI while the CPU is not doing anything using one of Garth's tricks, and ignore PIA interrupts if the serial console is in use or a program is running in RAM, etc.

I haven't given much thought to writes yet (though I have ideas). At this point, the ISA bus is simply a one way communications channel with the PC to send data to R1. Other than polling, there isn't currently a way for R1 to initiate a data xfer with the IBM PC, and I don't want to give R1 an IRQ. I may bring out CA2 and CB2 to an external latch and have the IBM PC poll the I/O port until CA2 is deasserted (CPU is not reading ISA bus) and CB2 has been asserted (response available from CPU to ISA bus).

[GARTHWILSON]

cr1901 wrote:

Part I
I'm reading the primer, and I realize: there is no way I can get around wired-OR output. I'm willing to suffer the consequences of this, but is there any way to reliably use Wired-OR in a 10MHz+ system? I have an ACIA IRQ, PIA IRQAB/IRQBB, and VIA IRQ (series Schottky diode) in my design.

I hope I don't embarrass myself by answering while missing something since I'm not re-reading six pages of this topic to remind myself of where we were. If the AND gate is not a possibility so you have to do the wire-ORs on the IRQ\ line, just make sure you have plenty of time in your ISRs between when you turn off the interrupt in the ACIA or PIA or VIA and when you hit the RTI, for the IRQ\ line to float up. You can get a rough estimate of the float-up time by multiplying the capacitance on the line (if you have a way to measure it) by the pull-up resistor value. If you're not using a WDC processor (which has CMOS input thresholds), cut the resulting time in half. If the ISR turns off the interrupt in the I/O IC first and then does a bunch of other stuff before reaching the RTI, you should be fine.

[nyef]

cr1901 wrote:

I'm reading the primer, and I realize: there is no way I can get around wired-OR output. I'm willing to suffer the consequences of this, but is there any way to reliably use Wired-OR in a 10MHz+ system? I have an ACIA IRQ, PIA IRQAB/IRQBB, and VIA IRQ (series Schottky diode) in my design.

I don't suppose using a 74HC02 quad 2-input OR gate or similar would work, would it? Cascading them would get you up to five inputs on one device.

[GARTHWILSON]

Quote:

quad 2-input OR gate or similar would work, would it?

It needs to be AND, so that if any one of them is low, the output is low. With OR, if any input is high (ie, false), the output will be high also.

[cr1901]

GARTHWILSON wrote:

I hope I don't embarrass myself by answering while missing something since I'm not re-reading six pages of this topic to remind myself of where we were.

Yea, it's been mostly a year of "I have ideas, but I don't produce any PoC (sorry BDD for the pun)", right? Story of my life...

GARTHWILSON wrote:

If the AND gate is not a possibility so you have to do the wire-ORs on the IRQ\ line, just make sure you have plenty of time in your ISRs between when you turn off the interrupt in the ACIA or PIA or VIA and when you hit the RTI, for the IRQ\ line to float up.

The thing with this is that I need to arbitrarily extend my ISRs and this reduces the rate I could be idling in a tight loop WAIting for interrupts, due to the potential for a spurious IRQ*. How significant is the rate reduction?

Using a Schmitt Trigger comes to mind as a potential workaround; it will stay low for a small portion of the IRQ line floating back up, but enough time to detect that the IRQ line IS in fact floating back up to "No interrupt" levels.

*Well, I should write a spurious IRQ handlers anyway, but that's tangential.