6502.org

A 1N5711 is too slow and too pricey. Some part numbers to look for are the aforementioned SD103A, SD101 and BAT48, all of which have recovery times in the neighborhood of 10ns, and are less than one dollar US.

————————————————————————
EDIT: The info I gave came from Digi-Key. Mouser lists the 1N5711 as 100 ps tR and .44 USD in a single piece quantity.

The 1N5711 is 100 ps, so 100 times faster, and is also less than one dollar.

Oh. I'm in Australia, and I was looking at a Jaycar catalogue that I had. That one I asked about was the first Schottky on the list. But the BAT48 is there(unless there's another one that's called BAT46/48).
I was reading that datasheet more "by feel" than anything else. Like I said, it was the only thing that seemed to be in a unit of time.

I had gotten that information from Digi-Key's site. I went over to Mouser and looked it up. The info they have agrees with what you said, the single piece price being .44 USD. Wonder what's up with Digi-Key.

BAT-48 or 1N5711 will work for you. The latter is the faster of the two, but that isn't critical in your application.

Thanks for the help there. Turns out that the 1N5711 is cheaper here, being AUD$0.80, while the BAT46 is AUD$1.50.

The single-cycler is giving odd results. The reset vectors(all of them, actually) are set to $8000, which is the top of the ROM, but it appears to be fetching $8080.

I'm a bit surprised at the 1.50AUD for the BAT46. Oh well, the 1N5711 is faster, not that it matters much.
How are you determining this? Is the clock signal low or high when you check the address and data bus lines for content? Data bus content should be checked while Ø2 is high. The address bus will become valid some time during Ø2 low. Incidentally, you should peruse this article at Dr. Jefyll's website for some insight on 65C02 and 65C816 timing. The animated timing diagrams are quite useful.

I have a DIL LED module that I've wired onto the data bus, and I've been checking that during phase-2 high.
What I do when I run Ittiara on the single-cycler is:
1) Make sure everything's plugged in, and power up.
2) Make sure that the Reset line is low.
3) Give the machine 5 clocks(10 presses of the button)
4) Clock it until VP becomes active, stopping with phase-2 high. Check the data bus lights, and probe the address bus.(It's a makeshift probe for the moment)
5) Give it one more clock(two presses) to get the low byte of the vector. Check the buses.
6) Clock it until SYNC asserts. Make sure that the opcode and address are correct.
7) Keep clocking it and checking the rest of the instruction.
8 ) Go to 6.

This way, the vector being pulled is $80 on both bytes. That line is not shorted to Vcc, because it goes low at other times. It usually appears to start executing the $FFs that are where the program isn't.
It has occurred to me that my ROMs(both of them) could be bad on those bits of those bytes. This seems unlikely, and they nearly always verify correctly. I am still hand-assembling at this point, typing the hex code into the programmer GUI.

I'm not sure which line you're referring to as "not shorted to Vcc," but the single-stepping has given you an excellent clue. You'll do well to get to the bottom of this.

Data line D7 shorted to Vcc could result in $80 on both bytes -- but so too could address line A0 shorted to Vcc. (In such a case the ROM would fetch the high-byte even in the cycle during which it's "trying" to fetch the low-byte. IOW the high-byte would get fetched twice -- $8080.)

I suggest you concentrate on the cycle during which the low byte of the Reset vector is being fetched. All being well, the CPU sends an out address, and this stimulus reaches the ROM in the form of address lines and control lines such as chip-select. Verify these signals at the receiving end, not just at the CPU where they begin the journey.

If the ROM receives the correct stimulus, and assuming its contents are correct, then next you need to verify the ROM output. Once again you should verify that the signals reach their destination (the CPU).

Bear in mind that LED's don't verify that the logic highs and lows are as high and low as they should be. If you're unable to find anything conspicuously amiss re the cycle during which the low byte of the Reset vector is being fetched, then check all the signals again but using a multimeter. Be on the lookout for voltages hovering around 30-70% of Vcc -- they're a sign of trouble. Healthy signals should be close to zero or close to 5V. (The indicator LED's you put on the data bus will reduce the logic high voltage somewhat. Make sure the load isn't excessive.)

I'm using 1Kohm resistors behind the LEDs, and my "probe" is one-sixth of a 74HC hex NOT gate, with the input pulled down with a 10K resistor. I figured that would be a weak pull. I haven't built a proper one yet, because I need another board to build it on(unless I cut off the unused part of the single-cycler board).
Thank you so much for that tip, Dr. Jefyll. I checked that line, and that DMM squealed its little head off. If is shorted, and will have been for a while(ever since I fitted the anti-noise caps). I hope I haven't busted the output driver on the 'C02. That would be expensive, given that I have to get any 65-series replacements from the US, and the shipping is 24AUD from Mouser. And that's the cheapest I've seen.

EDIT: I've just fixed the short, and tested it, and the test program(which is still that one for the VIA) is running correctly, up to the point where it writes into the VIA. There, the chip select does not drop, so there's probably something wrong with the PLDs programming. I'll deal with that one, and try again later.

I'd reduce that 10K to around 3.3K to 4.7K to improve noise immunity. Most anything you would probe would be able to readily supply the couple of milliamps that a resistor in that size would draw on a 5 volt circuit.
You are probably okay as long as it wasn't powered that way for a long time. Over the years, I've done some boneheaded things in digital circuits that accidentally tied two unrelated lines together. I've usually gotten away with it.

I too have gotten away with some boneheaded boo-boos. Damage is unlikely as long as all the circuitry is running from the same supply (eg, 5 volts). But the picture changes drastically when other voltages are present. For example if you accidentally interconnect a 3 volt circuit and a 5 volt circuit then serious trouble can result. And never forget that interconnections can result from a mere fumble, such as when you accidentally drop a metallic tool onto live wiring. Other examples of non-5 volt circuits -- easy to overlook -- are the 12 volts used by RS232 drivers and the 8 volts or more present at the input of a 7805 regulator. Danger, Will Robinson!
The purpose of a test instrument (such as a logic probe) is to reveal the operation of the Device Under Test -- not to alter the operation of said device. So, I'd recommend no pullup at all. An ideal test instrument will give a "candid" picture of what's going on -- not one that's affected in any way (even for the better).

-- Jeff

Been there and done that. One time while I was working above a contactor panel in a subway car, a 1/2 inch drive socket extension rolled out of the area in which I was working and landed in the contactor panel, hitting the 600 volt auxiliary power bus used to deliver juice to the car's electric heating system. Needless to say, I got a real bang out of it! Wasn't much left of the extension either.

Yikes! That's more excitement than I can enjoy.

Returning to the point about the danger of mixed voltages on a single board, Klaus happens to have touched on the matter earlier in this thread. "[...] the insulation was cut by the sharp edges of the pin and a high voltage (~10V) destroyed all GPIO on the raspberry Pi."

Accidental interconnections in an all-3-volt circuit (like the Pi) might be survivable. But with 10 volt wiring added to the mix...

OK, so I fiddled with the programming of the PLD, and now the IRQ problem is back. I've just ordered two of those diodes, and I'll begin typing up the new PLD equations.

Where I'm aiming with this thing is a handheld, powered by LiFe batteries. This is just the prototype, getting the thing working and relatively finalized before I lay out the PCB. I may switch out a few things as I go, as well. For example, I think I may possibly have fried the character LCD display when I tried to hand-run it. If I have(and maybe even if I haven't) I'll use a small graphical display instead.