Nice job on the schematic. I haven't examined it in detail but I did notice you have the IRQ\ outputs of the UART's tied together and (apparently) feeding an input of the 16V8 PLD. Are those IRQ\ outputs open-drain? If so then you need a pullup resistor. And if they're totem-pole, not open-drain, then they shouldn't be tied together -- you need a gate. BTW you haven't told us what equations the 16V8 contains, so in that sense the information is still incomplete.

Regarding troubleshooting, visual inspection and continuity tests are valuable but they're not your only options. An alternative approach is to remove the oscillator and temporarily attach a manual clock generator so you can single-step. [I see Klaus also mentioned this.] The clock generator shown below inverts its output every time the button is pressed. (IOW two presses results in one clock cycle.)
Single-stepping requires patience, and you need to think in terms of the cycle-by-cycle behavior of the CPU. But it's a powerful technique, and it doesn't require an oscilloscope or other fancy test gear.

As for understanding the cycle-by-cycle behavior, that's actually a valuable learning experience -- and you don't need to tackle it all at once. For example, you can begin by verifying that the ROM gets selected -- something that you know should occur shortly after reset even if you don't know the exact cycle count. (In case of any doubt the CPU's VPB output will reveal when the first two ROM access cycles should occur. )

Once the ROM is selected you can verify that the low-bye of the reset vector appears on the data bus and reaches the CPU. Then you proceed to the following cycle when the high-byte should appear. It's all step by step. The cycle after that should be the first opcode fetch (remember SYNC is high for all opcode fetches, so that helps you keep track). Again you'll verify that the data bus carries the expected value. You may also wish to check the address bus, whose value should be the same as what's stored in the two bytes at the reset vector.

Eventually you'll find a result that isn't as it should be... and that's the clue that will reveal a problem. Begin with a simple program such as a loop that simply jumps to itself forever. If that's alright, try adding a LDA that accesses one of your I/O devices to see if the device's chip-select activates properly. And so on.

Remember at the start you'll need to keep the CPU reset pin low while you apply a few preliminary clock cycles. *After* that's done you can bring reset high and proceed as noted above. In order to control reset you may wish to make an extra copy of the push-button circuit. (You could make as many as three, using just a single inverter IC. )

BTW I think the circuit will work with 'hc04 as well as 'hc14. It's a circuit I learned decades ago but I haven't built one recently. The parts values aren't especially critical. The 47K resistor completes a feedback loop that keeps the two inverters in whatever state they're in. Meanwhile the capacitor gets charged to a value that will oppose the existing state. Pushing the button causes the capacitor to override what the 47K resistor says.

Short answer: yes

-- Jeff

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

Those ACIA IRQs are open-collector, according to the datasheet. I'll add a pull-up(I think the PLD has a pull-up in it, but it won't hurt). That is an input. I didn't add pin numbers on that because I'm rather lazy. I had better do that.

The PLD file is attached. They're in WinCUPL, because Atmel.

I have tried manually clocking it with a schmitt trigger NAND gate and a DPDT toggle switch, but this seems a lot neater. I should probably get a small strip-board and build up a single-cycler like that, but with a reset switch on there as well. I know that I have a hex inverter in 74HC, whatever it is.
I could also add a debugging header to it, to avoid stretching the contacts on the IC sockets. Bring out a few signals like SYNC and /VP, and it'd probably help a lot. I could also build a Bus Bug, which would grab basically the whole of the 6502 bus, and put it into a serial terminal on a PC. (The Bus Bug is based on an Arduino and tri-state buffers. Probably not original, but it would work)

EDIT: I nearly forgot: Thank you, Klaus and Jeff for your most excellent help.

Toggle switches are fine -- whatever works for you. But of course pushbuttons tend to be much smaller and easier to mount than toggle switches -- also less expensive.

That sounds like a nice environment for troubleshooting, but is it worth the effort? With luck you won't be spending much time troubleshooting anyway. Simple problems tend to be the most common, especially in a project that's newly designed and built. Also, grabbing the whole of the 6502 bus means adding quite a lot more wiring, and the wiring is somewhat congested already. (Or does a Bus Bug connect via the socket of a memory IC? That would be alright.)

BTW, single-stepping changes what you should expect in regard to problems which are intermittent, such as bad connections. When running with a full-speed clock, even a sub-millisecond lapse in a flaky connection can crash the machine, which is something you're bound to notice. But, when you're single-stepping, the CPU is idle most of the time, and a momentary lapse can go un-noticed (unless you keep a sharp eye on your multimeter or logic probe).

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

Nice circuit, Jeff. The electronics industry will be quite miffed with you for using so few parts to get the job done and thus negatively affecting profits.

One note, the WDC version of the 65C02 and the 65C816 tend to be somewhat fussy about the clock signal quality. I would be inclined to use a 74AC14 in place of the HC14 to get a sharper pulse rise and fall time.

If your Ø2 clock generator circuit runs the oscillator through a flip-flop, as is the case with my POC units, Jeff's circuit will require four pushes of the button to take the MPU through one complete clock cycle. If for some strange reason, you don't feel like doing that much button-pushing, you could rig up the below circuit to toggle the flop's CLK input.


Following power-on, the above circuit will pull CLK low (note, a brief excursion to high will occur at power-on). When the push button is pressed and held, CLK will go high and stay there until the push button is released (R1 limits the discharge current to a safe level when C1 is shorted by the push button). When the push button is released C1 will charge to Vcc via R2 and eventually the voltage at C1 will go high enough to change the Schmitt's output state, causing CLK to go low again. The time-constant of C1 and R2 is 0.1 seconds, so adequate debouncing should be produced. If your hands are real shaky from drugs, old age (my excuse) or both (also my excuse), you can increase C1 and/or R2 to increase the time-constant and thus further delay the change of state when the push button is released.

As CLK does one high/low sequence with each press-and-release of the push button, the flop's Q output will make one transition per push button press (flops normally respond to a high-going input at CLK, so the high-to-low change at CLK doesn't affect Q). Hence, the MPU will be taken through one full clock cycle with two press-and-release push button operations.

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

It's best to not rely on the PLD's internal pullups and instead use an external resistor. In most cases, 3.3K is good for this purpose.

Code:

Name     AddrDecoderv2.1 ;
PartNo   00 ;
Date     25/10/2016 ;
Revision 01 ;
Designer Engineer ;
Company  N/A ;
Assembly None ;
Location  ;
Device   G16V8MA ; /* complex mode, to avoid the possibility of registered mode, */
                   /* as pin 1 is for clocked input in that mode. */

/* *************** INPUT PINS *********************/
PIN 1    = PHASE_2                    ; /* This is the system clock input  */
PIN 2    = A12                        ; /* The address lines used for selection */
PIN 3    = A13                        ; /* ditto                           */
PIN 4    = A14                        ; /* ditto                           */
PIN 5    = A15                        ; /* ditto                           */
PIN 8    = !VIA_IRQ                   ; /* The IRQ line on the VIA is a    */
PIN 9    = !OTHER_IRQ                 ; /* totem-pole output, and the      */
                                        /* ACIAs are open-collector.       */

/* *************** OUTPUT PINS *********************/
PIN 18    = !RAM                       ; /* The RAM chip select             */
PIN 19    = !ROM                       ; /* The ROM chip select             */
PIN 15    = LCD                        ; /* The LCD device select           */
PIN 17    = !IRQ_OUT                   ; /* The IRQ to the CPU              */
PIN 13    = !ACIA2                     ; /* The chip select for ACIA1       */
PIN 14    = !ACIA1                     ; /* The chip select for ACIA2       */
PIN 12    = !VIA                       ; /* The chip select for the VIA     */


ROM = A15;
RAM = PHASE_2 & !A15 & !A14;  <---  Not a good practice!
VIA = !A15 & A14 & A13 & A12;
ACIA1 = !A15 & A14 & !A13 & !A12;
ACIA2 = !A15 & A14 & A13& A12;
LCD = (PHASE_2 & !A15 & !A14 &A13 & A12);   <--- Not a good practice!

IRQ_OUT = VIA_IRQ # OTHER_IRQ;   <--- Won't work as expected!

Some notes and comments.

• As a fairly general rule, chip selects should not be qualified by Ø2 in any 65xx circuit. What should be qualified by Ø2 are read/write operations—especially write operations—to non-65xx hardware, such as the LCD device. During a write operation, the state of the data bus while Ø2 is low is undefined (65C02) or will contain the bank bits (65C816). Only after Ø2 goes high can the data bus be considered to be valid. Not qualifying a write operation by Ø2 on non-65xx hardware may open the door to a possible wild write and a difficult-to-diagnose hardware bug.
  
  In the case of the RAM and ROM, a careful study of the respective data sheets will probably indicate that there is an internal lag from when the device is selected until it will respond to /OE (read) or /WE (write). At low clock rates, such a lag is generally unimportant and can be neglected from most timing considerations. However, as the clock is accelerated the window in which the device can and will respond to an access will shrink and if you gate the chip select on Ø2 high, you may reach a point where the device will not respond in time to read or write as required.
  
  65xx peripheral silicon, such as the 65C51, is clocked by Ø2 and hence must see valid input at D0-D7, chip selects and RWB before the rise of the clock. In that respect, your logic is correct, as it is selecting ACIA1 and ACIA2 strictly on the basis of the address bus state.
  
  
• You have your IRQ logic upside down. Try this:
  
  
  Code:
  PIN 8    = VIA_IRQ;                              /* VIA IRQ output (totem-pole)    */
  PIN 9    = OTHER_IRQ;                            /* open-drain IRQ outputs         */
  ---
  PIN 17   = IRQ_OUT;                              /* to IRQB on MPU                 */
  ---
  IRQ_OUT  = VIA_IRQ & OTHER_IRQ;                  /* low if either IRQ input is low */
  
  Generally speaking, input pins are not negated in assignment declarations. If negation is required at some point it is stated in the relevant logic equation(s) or the output pin is declared to be an inverted output. Hence VIA_IRQ and OTHER_IRQ would be written without the negation symbol. As the IRQ inputs are high when no IRQ is pending, that logic can be directly reflected into the output to IRQB on the MPU.
  
  That said, you can completely avoid using the PLD for IRQ generation and save the pins for a more useful application (described below). A typical circuit in which totem-pole and open drain IRQ outputs are mixed pulls the MPU's IRQB input up to Vcc (3.3K is good here), direct-connects the open-drain devices (ACIAs in this case) to IRQB and connects each totem-pole output (65C22 in this case) to IRQB via a small-signal Schottky diode. The diode prevents one of the open-drain devices from trying to sink the totem-pole output(s) but allows a totem-pole device to sink IRQB. Schottky diodes are necessary to minimize the effects of forward drop. Using a standard small-signal diode may not work, as IRQB might not be sunk enough for the MPU to recognize the low state.
  
  
• The now-freed pins on your PLD can then be used for RWB (input), /RD (output to /OE on RAM and ROM) and /WD (output to /WE on RAM and the LCD). Simple logic will generate the outputs according to the status of RWB and Ø2:
  
  
  Code:
  PIN      = RWB;                                  /* MPU's read/write output          */
  ---
  PIN      = !RD;                                  /* low-true read output (non-65xx)  */
  PIN      = !WD;                                  /* low-true write output (non-65xx) */
  ---
  RD       = PHASE_2 &  RWB;                       /* true if read op & clock is high  */
  WD       = PHASE_2 & !RWB;                       /* true if write op & clock is high */
  
  In the above, RD and WD are outputs to /OE and /WE, respectively, on your non-65xx devices. Note that they are declared as inverted outputs in the pin declarations. Doing so allows the use of simple logic statements to control their state. For example, if PHASE_2 is low then both RD and WD are high, regardless of RWB's state. If PHASE_2 is high and RWB is high then RD will go low.
  
  The result is you can generate chip selects as soon as the relevant address appears on the bus and properly gate read and write operations with Ø2. This gives the selected device all of Ø2 high to accept or output data, rather than part of it.

One more note: WinCUPL is not confined to Atmel devices. CUPL (Compile Universal Programming Language) may be used to write code for industry standard PLDs, such as the 16V8, 22V10, etc., regardless of manufacturer, assuming your PLD programmer accepts a standard JEDEC fuse map.

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

A Bus Bug would need to be wired onto an IC socket that goes between the CPU and the mainboard, because of which signals I'd want to bug. It would be based on an Arduino, and would have to master the reset and clock signals in order to keep up. It's intended to produce a log of everything the computer being bugged is doing. Sort of the reverse of an in-circuit emulator.

I've decided to add a debugging header to Ittiara, and a single-cycler to use it. I plan to also have it display certain signals on some LEDs. Should I set up those LEDs to light up if the signals in question are active, or if they're high?

Also, I have found a logic probe circuit at:[url]circuit-diagrams.net/page/logic-probe[/url]. This seems to be sufficient to me, but I don't actually know. I intend to replace the 4000-series ICs with a 74HC equivalent, but I don't know if it's capable of picking up a short enough pulse. How would I find out?

That is up to you to decide. Whatever is least confusing is best.


That circuit is more than sufficient to get started. However, my logic choice would be 74AC, specifically a 74AC02 (see attached). The 74AC02 is available in PDIP14 or SOIC14, the latter which is about half the size of the PDIP. 74HC is relatively slow by comparison and may not detect really short pulses due to the cascading logic used to drive the Pulse LED. Furthermore, 74AC logic drives much harder than 74HC, which means you can reduce the size of the 1K current limiting resistors to around 470 ohms, making the LEDs brighter. Forward current on the LEDs will be around 10 mA, well within the source and sink ratings of the 'AC02.

It would be prudent to place a Schottky diode in series with the Vcc input so the unit isn't damaged if you accidentally hook up the power leads backwards. Place a 0.1 µF MLCC (X7R type) downstream of the diode to suppress switching noise from the 'AC02. That capacitor should be as physically close to the device as possible.

"Standard" LED colors used in most logic probes are green for Lo, red for Hi and yellow for Pulse.

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

74HC is much, much faster than 4000 series, but 4000 can do more than twice the voltage. 74AC which BDD mentioned is three times as fast as 74HC. The reason they used the 4000-series gate is so you can use it on higher-voltage logic than 74HC (or 74AC) can safely do. If you never go beyond 5V logic, you won't need the 4000-series logic.


It will be a little less, but still more than enough for great brightness with modern LEDs. With a VDD of 5V, if the gate's output is reduced by let's say 0.2V with the LED load, that leaves 4.8V, and you take another 1.7V off for the LED itself (that's for red; green takes 2.3V IIRC, and blue takes more), leaving 3.1V, and that divided by 470Ω is 6.6mA.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I have a little bit of doubt to replace IC1a (the input gate directly after the probe). The 2M2 feedback resistor may cause a CMOS 74xx to oscillate.

The feedback resistor should hold the input gate in an undefined state when the probe is not connected to a signal source. In conjunction with the 1k resistor bridge the LO & HI LEDs would not be lit as they are on the same voltage as the bridge, if the probe is open or connected to an open circuit. A faster technology like 74HC or 74AC may have a greater tendency to force the output into a defined state and oscillate. In this case all LEDs including the pulse LED would be lit when the probe is not connected.

The propagation delay of a 4001 should be 60ns typical, 120ns max. It should be O.K. up to 2MHz.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

That is an intentional feature of this circuit. If the probe is not connected to anything or if the circuit to which it is connected is in the high-Z state the oscillation results in no LEDs illuminating, which is how most probes operate. The web page on which the circuit is presented discusses this aspect of the probe's operation.

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

That's what I get for doing the math in my head in the middle of the night.

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

BDD, regarding your suggestions for the decoding, I plan to implement them, although not immediately(I want to get it operational first).
Can you recommend a part number for the diode? Looking at the Jaycar catalogue that I have, I realise that I don't know what I'm looking for.

I have built the single-cycler, and it does work. I feel that adding a header for it on the mainboard was a good decision, as can just plug it in and use it. I am noticing that the IRQ signal is active all the time, so I'll fix the PLDs programming, and try it again.

Something like a Vishay SD103A should work in this application. It's in a DO35 package, so it isn't going to take up much room. Any small-signal Schottky should do the job. Just look for a short recovery time.

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

Erm... I realise that this is going to sound a bit rude, but I can't get hold of that particular part easily(that I know of, anyway). Would a 1N5711 work? I've seen an ST datasheet(here) that seems to indicate a 100 ps recovery time, although it's labelled with a tau, but isn't actually explained. It's the only thing in seconds.

The PLD appears to have gone insane. I reprogrammed it with the correct IRQ equations, but it looks like the PLD is pulling /IRQ down at all times, regardless of any inputs. It occurs to me that there is an /OE pin on the PLD. It might be that I have left that disconnected. If I have, it might possibly cause this.

EDIT: I've changed the PLD to use simple mode so that neither /OE or CLK break the design. /IRQ now works properly.