6502 PCB Power On Issues

[djh82uk]

Hi All,

I had been following the series by Ben Eater on the 6502, Im a complete newbie but doing my best to learn.

I had it working on the breadboard at 1MHz, I designed a PCB for it, and had to harvest the parts from the breadboard as I only had one VIA, one 62256 etc.

The board works and displays text on the LCD, however if I power on via the on-board power switch (on the PCB) then it works fine 9/10 times, 1/10 times the screen is blank (just blocks, same as powering it unconnected to anything).

If if leave the on-board power switch enabled, and power cycle it via my bench PSU, it fails 100% of the time with the same issue.

Doing a bit of probing on the scope, I can see that the power draw is consistently 0.047A when it fails, and 0.053A when it works.

The frequency shown on the scope for the Address pins also changes, they are mostly around 100KHz when it fails, and they all differ (as expected) when it works.

I have a reset button that shows 0V at the RESET pin when button is pressed.

Schematic is here: https://github.com/djh82uk/6502-Compute ... -06-30.png

Board is here: https://github.com/djh82uk/6502-Compute ... Board.JPEG

The brown jumper wires are issues I found and fixed for this revision.

Any advice welcome on anything really (but ideally about the problem )

[BigEd]

Well done! Graduating from breadboard to a PCB is a significant step.

Is it possible your computer is fine, but the LCD isn't starting? Can you for example check some voltages of I/Os, perhaps the inputs to the LCD, or check the frequencies of some address lines, or the SYNC line?

One reason I mention this is that some LCD modules have strict needs to warm up between power on and first use, and maybe your firmware doesn't wait long enough.

[Dr Jefyll]

Welcome, djh82uk

djh82uk wrote:

if I power on via the on-board power switch (on the PCB) then it works fine 9/10 times [...]
If if leave the on-board power switch enabled, and power cycle it via my bench PSU, it fails 100% of the time

I believe the trouble is in your reset circuit. Try using larger values for R4 and/or C1. This will increase the delay that occurs between powerup and the time the CPU comes out of reset (ie, the time pin 40 goes high).

What you want is for pin 40 to remain low until after VCC has reached 5V. That way, when the CPU comes out of reset it (and the LCD) are able to function properly.

VCC will reach 5V almost instantly if you begin with the bench PSU already turned on and at 5V, then activate the on-board power switch on the PCB. But VCC will reach 5V more slowly if you do it the other way, because the bench PSU takes a split second to come up to 5V. Because R4 and C1 don't provide enough delay, the CPU comes out of reset during the time the bench PSU is still ramping up and has not reached 5V. This explanation matches the symptoms you're experiencing.

Edit: do you have SW1 (the reset push button) installed as shown in the schematic? I expect your project will start reliably if you power up firstly (by either method), then press and release the push button.

-- Jeff

[djh82uk]

Thanks both,

I've tried both methods of powering up while holding down the reset just now (It is installed as per the schematic), interestingly power-up via PSU still fails, but power-up via switch also now fails.

As in turn on PSU, hold reset, turn on via on board switch, release reset, this exhibits the same failure as powering on via PSU.

I know it's not a huge issue, and I could just use the power switch, but it doesn't sit right with me if there's a bad condition I can fix.

I need to get new boards to fix the two bodge wires anyway, so this is my chance. (also want to add uart/bootloader, but will post asking about that after this).


I haven't actually confirmed reset is working, as the current program only displays "Hello World", so when the board works, and I reset, it just keeps showing the same thing.

The reset pin on both the 6502 and 6522 do both go low though.

On the SYNC pin (it's not connected on my board) I get:

Judging by the hardware counter on my scope
Powering up via PSU - random frequency between 100-200KHZ, Is not stable on trigger and shifts all over the place
Powering up via PSU with reset pressed (and then released) - 330KHZ signal, Is not stable on trigger and shifts all over the place
Powering up via boards power switch with reset pressed (and then released) - 330KHz signal, Is not stable on trigger and shifts all over the place
Powering up via boards power switch (when it falls into the 9/10 success condition) - 330KHz signal, is stable, no shifting.
Powering up via boards power switch (when it falls into the 9/10 success condition), and then resetting - 330KHz signal, Is not stable on trigger and shifts all over the place

I see a similar pattern on the address pins, nice stable signal on success, random frequency and all over the place on failure.

Is it still worth me trying a larger cap/resistor, or is that negated by the failure of reset to work when held before power up?
It does seem that reset circuit is really messing things up.

Scope traces can be seen here: https://github.com/djh82uk/6502-Compute ... leshooting

Hopefully the filenames give enough info of what they are showing.

I'm finding this interesting, but a bit weird.

[BigDumbDinosaur]

djh82uk wrote:

Scope traces can be seen here: https://github.com/djh82uk/6502-Compute ... leshooting

Welcome to 6502-land.

Please note you can attached files, such as schematics or pictures of 'scope traces, to your posts. Doing so makes it more convenient for readers of this forum by not requiring them to go off-site.

BTW, monochrome schematics are more readable than ones with color, especially for old guys with bad vision.

[djh82uk]

Hi, Thanks for the tips.

Converted schematic to greyscale and attached images etc.

Thanks

[SamCoVT]

djh82uk wrote:

As in turn on PSU, hold reset, turn on via on board switch, release reset, this exhibits the same failure as powering on via PSU.

The scope shots on your github show your RESET line could probably do with a larger cap (you have less than 1ms of delay), but the above statement, where the pressing/holding the reset button after the board has clearly powered up, indicates the issue is more likely in your LCD initialization routine.

Looking at your code on the github, it looks like you set the pins on the VIA to be outputs and then immediately start sending commands to the LCD. These character LCDs need a little dance at the beginning, which you can find on page 45 (for an 8-bit interface) of https://www.sparkfun.com/datasheets/LCD/HD44780.pdf.

The first thing you need to do it wait 15ms after Vcc rises over 4.5V. This can either be done by increasing your reset delay or it can be a software delay. I always use a software delay, and I also wait at least 50ms because some of the HD44780 (the chip that runs the LCD) clones need a longer delay.

The "dance" I was referring to is to send the function set command (eg. your first %00111000 command) 3 times (with various delays in between, but I use the same 5 to 10ms delay over and over because you can always use a longer delay) WITHOUT checking the busy flag. This makes it so that if the LCD was ever accidentally in 4-bit mode, it will be guaranteed to be in 8-bit mode. Only the upper 4 bits actually matter during this step, as shown in the datasheet with * for the lower 4 bits.

After that, you can proceed with the code you already have and checking the BUSY flag is fine.

Doing a proper software reset on these LCDs is a little tricky, so it's not too surprising you are having this issue, but it should be easy to resolve.

[John West]

One other possibility, which might be nonsense. I've always used a 74x14 on the reset input, because I can't find any mention of hysteresis in the 65C02 documentation. If it's a standard input, a slowly rising signal (and slowly rising is exactly what you want here) with lots of noise will make the internal reset signal bounce up and down randomly as it crosses the transition level.
It might be that there is a healthy amount of hysteresis on that input, and they've just forgotten to mention it (or I didn't read the datasheet thoroughly enough). But making sure it gets a nice clean edge can't hurt.
I also add a diode across the pull-up resistor, to discharge the capacitor when power is removed. Without it, the input's protection diode will be doing that job, and that's not what it was designed for.

[hoglet]

It's good practice (especially with two layer boards) to give every IC a 100nF decoupling capacitor connected between the VCC and GND pins. The capacitor should be positioned so as to minimise the length of the traces between it an the IC.

This is really quite important for reliable circuit operation.

It's unfotunate that Ben Eater doesn't tend to bother with decoupling capacitors on his breadboards, as many people watch his videos, which are excellent in all other respects.

Dave

[GARTHWILSON]

I think you'll find the primary problem is the reset circuit. Please see the 6502 Primer's page about that, at http://wilsonminesco.com/6502primer/RSTreqs.html . See also my LCD code at http://wilsonminesco.com/6502primer/LCDcode.asm . Getting a reliable reset and setup on the LCD requires doing part of the set-up code three times, as shown there. We wasted a lot of time on LCD problems at work until an applications engineer sent us this information that is not obvious on many of the data sheets.

[BigDumbDinosaur]

GARTHWILSON wrote:

I think you'll find the primary problem is the reset circuit.

John West wrote:

One other possibility, which might be nonsense. I've always used a 74x14 on the reset input, because I can't find any mention of hysteresis in the 65C02 documentation.

Yep! In fact, I think it's a simple timing error with a simple fix.

It has been my experience that most can oscillators take tens of milliseconds to start generating an output following power application, a natural behavior of anything involving a resonant crystal. If one carefully reads the 65C02 data sheet, specifically how it handles reset, one can see that if it comes out of reset before the oscillator reaches full output and is stable, the MPU will not start.

The 'scope traces seem to indicate that the reset hold-down time is much too short. I'm pretty sure that is why the MPU might or might not start, depending on circumstances. The solution is to lengthen the reset period. A device such as the Maxim DS1813 reset generator is a suitable means of doing so and will produce consistently reliable results.

Using an R-C network on the reset line is only practical if the MPU's reset input is Schmitt-triggered. I don't see anything in the current 65C02 data sheet that indicates that is the case. If you want to stick with the R-C reset circuit just insert a 74HC14 between the reset circuit and RESB on the 65C02.

Lastly, I see some questionable design matters.

1. You are mixing logic families. 74LS generates TTL outputs, in which VOH is only guaranteed to reach 2.4 volts, which is below what constitutes a valid logic 1 in CMOS. I suggest you replace your 74LS devices with 74HC.
2. You have BE and RDY connected together, which may lead to some difficult-to-diagnose problems. The problem stems from the fact that RDY is bi-directional in WDC 65C02s—the MPU will drive RDY low if a WAI instruction is executed (intentionally or not). If WAI gets executed, RDY will go low and take BE with it. Driving BE low will cause the MPU to high-Z the buses and RWB, leaving them floating. Depending on what is attached to the buses, allowing them to float may result in noise perturbing other hardware and causing undefined behavior.
   
   Incidentally, RDY should never be directly connected to ground, VCC or the output of another gate. Always use a resistor to limit current flow in the event RDY is driven by the MPU to a state opposite of the circuit to which it is connected.
3. Your circuit shows SOB as floating. SOB should be tied to VCC through a 3.3K resistor.

[djh82uk]

Hi Guys,

Thanks for all the valuable input.

I have attached an updated schematic incorporating the points raised.

namely:
- I did have some 100nf decoupling caps, but not enough for every chip, and likely not close enough to the chips vcc/gnd pins. I have added 3 additional.
- I have pulled SOB high via a 3.3k Resistor
- I have added a DS1813 and removed the RC part of the reset circuit
- I have changed the 74LS08 to a 74HC08 (I misread and thought the 00 was a 74HCT00, hence family mixing seemed less bad, but is now all HC)
- I have disconnected BE from RDY and pulled it high via a 1K Res. (I don't know why Ben Eater had it connected to the RDY, so maybe im breaking his design this way? I am all for best practices though)
- I have also pulled RDY high via 1k but left it connected to the rest of the circuit as before
- I have added another header to breakout the 6522 ports
- I have fixed the mistakes I had on the 62256 (the brown bodge wires in the photo).

Ive snapped way too many eeprom pins, so im torn between going for a ZIF socket (Ive struggled to find any that fit well into a DIP-28 footprint, pins never remotely line up), or trying to figure out where I want to go with UART, but to be honest im struggling with that part a little. Is the UART loading directly to ram and pulling BE low?

Im also still very fresh with assembly for this processor, I have an expanded version of Ben Eaters 8-Bit 7400 series computer, but that has a very simple instruction set. For this I guess my next bit on the software side is implementing an appropriate delay for the LCD.

Longer term I want to delve into graphics/sound and a better way to load programs (UART I guess?)

I don't know how puritan I want to be, whether im ok with Arduino or CPLD/FPGA. Ive done a really basic proof of concept for VGA on CPLD. Ive been putting together a CPLD board that fits into a DIP-40 (with overhang). Pic attached in case anyone interested (Inspiration from a post by Bill Herd on Hackaday).

Thanks All

[BigDumbDinosaur]

djh82uk wrote:

I have attached an updated schematic incorporating the points raised.

Don't know why I didn't notice this before, but are you planning on using a W65C22N or W65C22S? If the former, you need a 3.3K pullup resistor on IRQB. Otherwise, IRQB will float when the 65C22N isn't interrupting and you may get spurious interrupts.

If using the latter, you may find yourself in a bind if you subsequently add another device that generates interrupts. A read of the data sheet will explain why.

[djh82uk]

So I presume I am using the S variant.

The code on the top of the chip reads as "w65c2256tpg-14", but google corrects the second 5 to an S, so maybe just dodgy printing (or my dodgy eyes).

Would the preference be to go for the N variant wit the pullup then (to be able to interrupt from other sources?).

As im a bit stuck until I draw out a new PCB, I managed to find some 0805 cap/resistor combinations. I have 330Nf and 100K. This is giving me a consistent 35-43ms rise time on reset, power on from PCB and power on from the PSU.

Also tried it with a 47k to give me 19ms of rise time, same result.

However, interestingly (to me at least) the signal on the SYNC pin is now stable (same frequency, no shifting)all the time, in all scenarios (reset, psu power on etc), same for the address pins.

Although, the screen works 0% of the time now, even in cases where it would have worked previously.

I was pretty sure that would work as a temp solution, I guess the rise time can't be too long?

From looking at the DS1813, it looks like it maintains reset for 150ms, then has a rise time of 2us once the 150ms are over?

[GARTHWILSON]

Quote:

Would the preference be to go for the N variant wit the pullup then (to be able to interrupt from other sources?).

Note that the S version also has much stronger port output drivers, something I definitely want for some applications. As for interrupt connections, see the applicable page of the 6502 Primer, at http://wilsonminesco.com/6502primer/IRQconx.html . (I think that going through the whole Primer, section by section, will prevent a lot of other problems that may otherwise be turning up in the future too. It was written to answer problems and questions that kept coming up on the forum; and it keeps getting updated.)