6502 PCB Power On Issues

[djh82uk]

Thanks, I will definitely have a good read through

[BigDumbDinosaur]

djh82uk wrote:

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).

From where did you get this 65C22?

Quote:

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

I'd be using the S version along with a 3- or 4-input AND gate. One of those inputs can be reserved for devices with open-collector IRQ outputs, and the remaining inputs used with devices have totem-pole IRQ outputs. As Garth explains, the S version has stronger drive characteristics. Also, the totem-pole IRQ output is much less susceptible to spurious interrupts because IRQB is driven high when the cause(s) of the IRQ is(are) cleared.

Quote:

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.

I guess you didn't read my comments about the potential fallacy of what you are doing with reset.

Quote:

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?

Yep. The DS1813 works great. I have used it in all my POC units. I also use it to debounce a "panic button" I have wired to NMIB.

Quote:

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)...

Take a look at this ZIF socket. It's only slightly larger than a standard 28-pin socket.

[BigEd]

Sounds like everything might well be working now, djh82uk, with the exception of the screen. Did you see all the comments - there must be at least 4 now in this thread - about how careful you have to be with initialising it?

It's an important point about electronics: you have to be very diligent about details, about checking things, including things you think you already know are OK.

Edit: oh, and as BDD points out, with the possible exception of allowing the clock can enough time to get going before reset goes inactive.

[djh82uk]

Hi, BigDumbDinosaur, please don't think I ignored that, I had a good number of great replies and so I focused on the hardware side where I feel (marginally) a bit more confident. Now that it looks like the 6502 is coming up in a good state every time and im not getting the variance in the SYNC and Address pins. My intention is to dig into the delay in the screen initialisation. I'm not super comfortable with the assembly so it's going to take me a lot of reading and figuring out. I intend to move onto that after I finish reading that 6502 primer. I plan to do all that before ordering the next board revision to maximise the chance it does not need more bodge fixes.

I get what you were saying on the CAN start up time, I have a 74HC14 lying around but it's SOIC-8 so will take a bit of playing around to get it included. I just wanted to see the result from changing the RC ramp up time. I learn the most when im failing I guess the Maxim part will cover that aspect on the next board version.

I got the 65c22 from ebay from a seller that was often recommended on reddit: toucano76 (I use aliexpress a lot but could not find any at the time)

I had a look at the S variant part of the 6502 primer, but could not figure it out right away, as it shows the open-collector parts on on the AND pins, and the VIA's on the rest. So wouldn't that need both VIA to send an interrupt at the same time? Or does IRQ naturally pull itself high so the AND only passes through a logical low whenever there is an actual Interrupt to service?

That ZIF socket looks, nice, expensive but nice, I think it would be worth it, it takes the strength of 10 men to pull the EEPROM from the current DIP sockets I have.

So if I replace the RC part of the reset with a 74HC14, and dig deeper into the code on the screen initialisation, you think I would be going down the right path?

The rest of the advised changes I have incorporated in the schematic for the next version (SOB, RDY, BE etc). Im not looking to go much further with this revision other than getting the screen working I guess as those other issues may just trip me up further. (So fix screen, add any additional updates to the new board revision, and then order).

I've obviously got a lot more learning to do, but thats good as it would be a pretty boring hobby if it could be figured out on the first try.

Thanks for all your help.

[djh82uk]

Ok, so im still seeing some wierdness.

If I adjust the RC values, I can get it so that it appears that the 6502 is working correctly (no longer doing the wierd shifting signals on SYNC)

However this means that the screen never displays anything.

If I put the RC circuit back to how it was (much faster rise time), then it works again, but only in the scenarios outlined. When it fails I see the wierd sync behavour.

This is using some updated code (below) where I tried to implement delays, it compiles ok, and displays correctly, but only when I have the original fast RC, and so only works some of the time.

When I use the higher values in RC, it never updates the screen despite the delays. (but the chips appears to be running more stable)

I know I should be focusing on the MAXIM DS part or the 74HC14, is it worth me giving up until I can source those parts?

Code: Select all

PORTB = $6000
PORTA = $6001
DDRB = $6002
DDRA = $6003

E  = %10000000
RW = %01000000
RS = %00100000

  .org $8000

reset:
  ldx #$ff
  txs

  lda #%11111111 ; Set all pins on port B to output
  sta DDRB
  lda #%11100000 ; Set top 3 pins on port A to output
  sta DDRA

  lda #%00111000 ; Set 8-bit mode; 2-line display; 5x8 font
  jsr lcd_instruction
  lda 50
  jsr _delay_ms 
  lda #%00001110 ; Display on; cursor on; blink off
  jsr lcd_instruction
  lda 50
  jsr _delay_ms 
  lda #%00000110 ; Increment and shift cursor; don't shift display
  jsr lcd_instruction
  lda 50
  jsr _delay_ms 
  lda #$00000001 ; Clear display
  jsr lcd_instruction
  lda 50
  jsr _delay_ms 

  ldx #0
print:
  lda message,x
  beq loop
  jsr print_char
  inx
  jmp print

loop:
  jmp loop

message: .asciiz "Hello, world!"

lcd_wait:
  pha
  lda #%00000000  ; Port B is input
  sta DDRB
lcdbusy:
  lda #RW
  sta PORTA
  lda #(RW | E)
  sta PORTA
  lda PORTB
  and #%10000000
  bne lcdbusy

  lda #RW
  sta PORTA
  lda #%11111111  ; Port B is output
  sta DDRB
  pla
  rts

lcd_instruction:
  jsr lcd_wait
  sta PORTB
  lda #0         ; Clear RS/RW/E bits
  sta PORTA
  lda #E         ; Set E bit to send instruction
  sta PORTA
  lda #0         ; Clear RS/RW/E bits
  sta PORTA
  rts

print_char:
  jsr lcd_wait
  sta PORTB
  lda #RS         ; Set RS; Clear RW/E bits
  sta PORTA
  lda #(RS | E)   ; Set E bit to send instruction
  sta PORTA
  lda #RS         ; Clear E bits
  sta PORTA
  rts
_delay_ms:          
  sta tmp1      ; 3
  txa           ; 2
  pha           ; 3
  tya           ; 2
  pha           ; 3
  ldx tmp1      ; 3
  ldy #190      ; 2
@loop1:             
  dey           ; 190 * 2
  bne @loop1    ; 190 * 3 - 1

@loop2:             
  dex           ; 2
  beq @return   ; (x - 1) * 2 + 3

  nop           ; 2
  ldy #198      ; 2
@loop3:             
  dey           ; 198 * 2
  bne @loop3    ; 198 * 3 - 1

  jmp @loop2    ; 3

@return:            
  pla           ; 4
  tay           ; 2
  pla           ; 4
  tax           ; 2
  lda tmp1      ; 3
  rts           ; 6 (+ 6 for JSR)

  .org $fffc
  .word reset
  .word $0000

[Dr Jefyll]

Quote:

If I adjust the RC values, I can get it so that it appears that the 6502 is working correctly (no longer doing the wierd shifting signals on SYNC)

It sounds to me as if you'd do well to nail this down a little better. Is the 6502 (and the reset RC) working correctly or isn't it?

Troubleshooting involves breaking the puzzle into pieces. So, forget about the LCD for a while and concoct a simple test that simply lets the 6502 blink an LED or something. Or (since you have a Logic Analyzer), just put it in a dumb little loop that just writes to zero-page then repeats. You'll easily be able to see the activity on the CPU R/W pin.

Once you've proven that the 6502 really is under your control, then you can move on to other issues.

-- Jeff

[djh82uk]

Ok, so I tried some code to alternate the led's on PA0-PA4 so at least I could pick up the transition, but they just sit high. Issue is that all of the PA abd PB pins are wired up to the LCD and the buttons.

They are pulled high on the PCB via a 1K resistor, I guess what I don't know is whether the 6522 can drive it enough to a low level? Or the code is just not working.

Code is essentially this:

Code: Select all

 
  0xa9, 0xff,         # lda #$1f
  0x8d, 0x02, 0x60,   # sta $6003

  0xa9, 0x55,         # lda #$1f
  0x8d, 0x00, 0x60,   # sta $6001

  0xa9, 0xaa,         # lda #$00
  0x8d, 0x00, 0x60,   # sta $6001

  0x4c, 0x05, 0x80,   # jmp $8005

however, one thing I did notice with the LCD code

Putting the scope in single-shot mode on D0 of the LCD. When I get a "success" I see a nice signal on that pin. Whenever I get a "failure", I simply see a transition from low to high and thats it.

This is the same whether pressing reset, power on from PSU, or powering on from the PCB power button.

The only time I see a signal (and get a valid display on the screen), is when using the fast RC circuit (1k / 100nF) and the power switch.

So it does seem like it's the 6502 rather than the display at that point. I did also do some testing on the oscillator startup, and it looks to be consistently around 850us when powered on from the PSU, and 600us when powered on from the PCB switch. That was using VCC as the trigger.

I guess that would be down to the PCB power switch being after the LDO and it's 2 caps (so they are already charged), but via PSU it has to charge them?

[John West]

djh82uk wrote:

The only time I see a signal (and get a valid display on the screen), is when using the fast RC circuit (1k / 100nF) and the power switch.

If a longer reset makes it not work, then it wasn't really working with the short reset. A longer reset should make it more likely to work, not less. I'm increasingly sure that the reset is your problem. Get that 74HC14 or DS1813 in.

And I agree with Dr Jefyll's advice: forget the display for now. Remove it from the board. Get the 6502 working solidly with the simplest program that you can be certain is working or not (blinking an LED is the classic test if you don't have a logic analyser, a tight loop is simpler if you do). Then make sure you have control over the 6522, and it does what you tell it to. Only then add the display.

[BigDumbDinosaur]

djh82uk wrote:

Now that it looks like the 6502 is coming up in a good state every time and im not getting the variance in the SYNC and Address pins. My intention is to dig into the delay in the screen initialisation.

I recommend you follow Jeff's suggestion first and establish that the unit will compute. Since you have a 65C22 in the circuit it should be easy to write some code that will cycle an LED scabbed onto one of the C22's ports.

Once you have leaped that hurdle then you should work on getting the display to function.

Quote:

I get what you were saying on the CAN start up time, I have a 74HC14 lying around but it's SOIC-8 so will take a bit of playing around to get it included. I just wanted to see the result from changing the RC ramp up time. I learn the most when im failing I guess the Maxim part will cover that aspect on the next board version.

The problem here is you are continuing to make the same mistake. The WDC 65C02 does not have Schmitt triggering on any input except NMIB (per a statement by Bill Mensch, the C02's designer). A slowly-rising input on RESB is not going to cause a reliable reset. The proper way to do this is to direct the output of your R-C circuit through a Schmitt-triggered device (inverter, for example) and direct the output of that device to RESB.

Or, you can remove your present reset circuit and replace it with a Maxim DS1813 or similar. Either way, fix this problem first.

Quote:

I got the 65c22 from ebay from a seller that was often recommended on reddit: toucano76 (I use aliexpress a lot but could not find any at the time)

In other words, you don't know the provenance of the parts you were sold.

Quote:

I had a look at the S variant part of the 6502 primer, but could not figure it out right away, as it shows the open-collector parts on on the AND pins, and the VIA's on the rest. So wouldn't that need both VIA to send an interrupt at the same time? Or does IRQ naturally pull itself high so the AND only passes through a logical low whenever there is an actual Interrupt to service?

I'm not making sense of what you are saying.

The S version has a totem-pole IRQ output. Hence it drives IRQB in both directions. The N version has an open-collector IRQ output. Hence it can only drive IRQB low and a pullup resistor is required to return IRQB to the high state after the cause of the interrupt has been cleared.

Quote:

That ZIF socket looks, nice, expensive but nice, I think it would be worth it, it takes the strength of 10 men to pull the EEPROM from the current DIP sockets I have.

You get what you pay for. In my POC V1.0 unit, I actually wore out the ROM socket from so many removals and insertions. Replacing a 28-pin socket is not a trivial exercise. So the cost of the ZIF socket proved to be money well spent.

Quote:

So if I replace the RC part of the reset with a 74HC14, and dig deeper into the code on the screen initialisation, you think I would be going down the right path?

I covered this above.

Quote:

The rest of the advised changes I have incorporated in the schematic for the next version (SOB, RDY, BE etc). Im not looking to go much further with this revision other than getting the screen working I guess as those other issues may just trip me up further. (So fix screen, add any additional updates to the new board revision, and then order).

You are so fixated on the display you haven't addressed the fact that the computer itself is not functioning. Your priority right now should be to get your computer running.

[djh82uk]

Ok, Thanks guys, point taken.

I will order the parts I need and go from there. Again, thanks for your help and patience.

[GARTHWILSON]

Several things:

Expanding on what BDD said: A slowly rising RST\ signal will be trouble unless the RST\ input is a Schmitt-trigger input. I think a couple of the manufacturers had Schmitt-trigger RST\ inputs, but I don't know which ones. My information from WDC is that theirs doesn't (just as BDD heard from them also). After the clock source is up and running, the processor needs a few cycles while still in reset to get itself set up and ready to run. If the RST\ input is not a Schmitt-trigger input, and the RST\ line slowly rises, it gets any electrical noise coupled in from the clock line (which can happen in a few different ways), the RST\ input may be seen by the processor as changing every half cycle, and it won't ever get the contiguous few complete cycles it needs. (I have not looked at the innards of the design to get the details.)

Now what if the processor and even the VIA actually did have Schmitt-trigger inputs. If the thresholds don't exactly match, what if the VIA stays in reset slightly longer? Your reset routine starts immediately by writing to the VIA, with no delays. If the VIA is still in reset, it won't be listening. So as you can see, getting a fast-rising RST\ edge is important in more ways than one. I should probably add this to the 6502 Primer's reset page at http://wilsonminesco.com/6502primer/RSTreqs.html .

The debugging section of the 6502 Primer is at http://wilsonminesco.com/6502primer/debug.html and starts with the basics like power supply, clock, and reset before moving on to other things and methods to debug without expensive equipment.

If you really do have a W65C22S, its outputs are super strong, far stronger than the data sheet lets on. The strength of the processor's outputs is described in the 6502 Primer's logic-family page at http://wilsonminesco.com/6502primer/LogicFamilies.html, and the strength of the VIA's outputs is described in the I/O ICs page at http://wilsonminesco.com/6502primer/IO_ICs.html .

And again, I strongly recommend using the LCD set-up method shown in the code at http://wilsonminesco.com/6502primer/LCDcode.asm (which is also in the 6502 Primer portion of the site) for a reliable LCD initialization that will work every time, not just usually.

BTW, since you have a CMOS 6502 (65c02), you can streamline the code a bit; for example, you can push and pull X and Y directly without going through A. The CMOS processor's many improvements over the NMOS one are summarized at http://wilsonminesco.com/NMOS-CMOSdif/ .

[djh82uk]

Hi Garth,

Im currently working my way through your primer, im finding it really useful, and making notes on the bits I still don't understand properly so I can revisit those areas.

I did find your lcd code, but got a bit confused. Initially by the sections for Forth (ive never really touched Forth, a bit of fortran, pascal, delphi and the usual more modern stuff, Im really not a good coder though), and on the ASM the bit that threw me is the reference to the jsr for WAIT_EIGHTH, I couldn't find that subroutine listed anywhere in the code? (im just looking for WAIT_EIGTH:).

How do you guys assemble/compile your code? Im just using vasm at the moment but im guessing that has it's own way of doing some things? Just that a lot of the asm samples ive found for 6502 seem to be quite different in their format. I mean I guess some are written for mainline 6502 systems like the PET/Apple etc.

Im eyeing up getting one those expensive ZIF sockets for my EEPROM, Im in the UK, and the only place I can really find them is Mouser/Digikey etc, Mouser has 65c02's, 65c22's, 6556's etc, so Im thinking it may be worth biting the bullet and getting one of each as a known quantity. At least I know Im looking at the right datasheet then for that variant. Mine are definitely system pulls, some have hot_glue on them etc.

It's going to cost me a chunk to order all that, and the new boards so will prob be end of the month (I give myself a strict budget), which gives me time to learn more properly and take my time (which I struggle with sometimes).

I got into this as a side project thing initially as im building an 8-bit cpu (initially based on Ben Eaters Breadboard CPU, but quite heavily modified now) on PCB'S, and thought I would tackle this while im stuck waiting for boards/parts from China. I have an easier time with that project, but this seems a jump up in complexity and gotcha's (I guess due to it being so much more capable, higher speeds etc).

Im having fun and enjoying the challenge, plus get to prove to wife that im using expensive things I bought like the Oscope etc, but finding it a bit more stressful than I figured it would be, this was meant to help with stress from work

I truly do appreciate your guys help though, and putting up with my erratic methods.

[GARTHWILSON]

djh82uk wrote:

I did find your LCD code, but got a bit confused. Initially by the sections for Forth (I've never really touched Forth, a bit of FORTRAN, Pascal, Delphi and the usual more modern stuff, I'm really not a good coder though), and on the ASM the bit that threw me is the reference to the JSR for WAIT_EIGHTH, I couldn't find that subroutine listed anywhere in the code? (I'm just looking for WAIT_EIGHTH:).

If you want to use the assembly-language code, you don't need the Forth portion of the file. WAIT_EIGHTH is overkill but was something that was there anyway for other parts of the project. I don't remember what it was, but hopefully just something in the set-up, since at this point I would never have a routine to simply waste that much time, but instead I would have the processor doing something else useful while the required time is passing! WAIT6800, DELAY_ms, and WAIT40 were also there for other parts of the project, written by the other engineer in the company. Any delay routine that gives the adequate period at your clock rate will be fine. There's a really slick delay routine from Bruce Clark a third of the way down the 6502 Primer's program-tips page at http://wilsonminesco.com/6502primer/PgmTips.html, just above the heading "Avoid commonly wasted instructions:" Obviously you need to know the number of cycles you want at whatever clock speed you're running. The delay can range from 8 to 589832 cycles, with a resolution of 9 cycles.

Quote:

How do you guys assemble/compile your code? I'm just using vasm at the moment but I'm guessing that has its own way of doing some things? Just that a lot of the asm samples I've found for 6502 seem to be quite different in their format. I mean I guess some are written for mainline 6502 systems like the PET/Apple etc.

The assembly language syntax was standardized early in the 6502's history; but there may be small differences in the assembler directives from one assembler to another. I have a list of assemblers at http://wilsonminesco.com/links.html#assem . Most of them are free. I've only used a couple of them for 65xx, plus my own that I have built into my Forth system. There's no way for me to be familiar with all of them linked there, but I can comment on a few:

• There's Andrew Jacobs' As65 assembler which has program-structure capability built in, and seems to be a really good one. He was active on this forum but died about seven months ago.
• There's Anton Treuenfels' HXA 6502 assembler which also has program-structure capability built in, apparently modeled after my article on program flow-control macros.
• There's the Cross-32 (C32) assembler (which I use) formerly from Universal Cross Assemblers, now sold by Data Sync Engineering. Also available at http://www.mpeforth.com/cross32.htm. It's not free (it's $99US), but the one assembler is good for lots of different processors, and they even give you the information to adapt it to a processor of your own design. I really like how it handles the 8-/16-bit stuff on the 65816 processor which I think is much nicer and easier than how other assemblers do it.
• The Kowalski assembler, IDE, and simulator seem to be popular here on the forum. It is being improved by forum member Daryl ("8BIT"). See more about it in my my list of assemblers.

Whatever you choose, make sure it has good macro capability, so as you move up and start wanting macros, you don't find that your chosen assembler won't do them, after you've invested time getting familiar with it. I show some examples of how the level of the language can be raised with assembly-language macros in the last 40% of my page on simple multitasking methods, at http://wilsonminesco.com/multitask/ . In most cases, they assemble exactly the same thing you would do by hand if you didn't have the macro capability; so there's no penalty in run speed or memory taken—it's just that you no longer have to look at the ugly internal details every time, and your code becomes much clearer (meaning also you'll tend to write fewer bugs), and more maintainable. Most of the labels will be gone. All of the structure macros can be nested with other structures of different kind; and the only ones that cannot be nested with others of the same kind are CASE and the 16-bit FOR...NEXT (which I doubt you'll ever need to nest with themselves anyway).

[BigDumbDinosaur]

djh82uk wrote:

I did find your lcd code, but got a bit confused...

At the risk of becoming annoyingly repetitious, fix the reset problem and stop fixating on the LCD display. As Garth explained, a slowly rising reset signal is prone to noise and you can take it to the bank that that noise will cause no end of grief. The easiest way to address this matter is with the Maxim DS1813.

Quote:

How do you guys assemble/compile your code?

I use the Kowalski editor/assembler, which runs on Windows 2000 or latter (I run it on XP SP3). Thanks to 8BIT's hard work, the assembler is now syntactically correct, meaning code is entered with the syntax promulgated by MOS Technology and WDC. You can assemble directly from the editor and also simulate, which is handy for testing algorithms.

Whichever development environment you use, you will need to develop some fluency in assembly language, as you will be writing your firmware that way.

Quote:

Im eyeing up getting one those expensive ZIF sockets for my EEPROM...

Although my hobby computing isn't constrained by a budget, the Irishman in me tends to be frugal. Rather than buy a ZIF socket for each machine I build, I put a conventional socket on the board and plug the ZIP socket into it. Doing so adds some parasitic capacitance, but I still managed to get my POC V1.2 unit to run at 20 MHz.

When you move on to the next design, merely remove the ZIF socket from the old unit and use it in the new one. That way, the socket becomes a one-time expenditure.

Quote:

Im in the UK, and the only place I can really find them is Mouser/Digikey etc,

There are at least two other electronics distributors in the UK that sell WDC products: BD Electronics and Coltek. Since both are British companies, you might do better price-wise with them than with Digi-Key and Mouser.

Quote:

Mouser has 65c02's, 65c22's, 6556's etc, so Im thinking it may be worth biting the bullet and getting one of each as a known quantity. At least I know Im looking at the right datasheet then for that variant. Mine are definitely system pulls, some have hot_glue on them etc.

It's somewhat disconcerting to see how much 65xx hardware has been counterfeited. You wouldn't think there is any money in it, but time and again I have seen eBay listings of what are obviously remarked items.

Quote:

It's going to cost me a chunk to order all that, and the new boards so will prob be end of the month (I give myself a strict budget), which gives me time to learn more properly and take my time (which I struggle with sometimes).

One of my other hobbies is large-scale model railroading. I have scratched built a 1.6" scale model of an EMD F7 locomotive, in which I fabricated most of the parts from "raw" materials. As costs can quickly get out of hand if material is wasted, I heeded the ancient dictum of "measure twice and cut once."

It's the same in the homebrew computer hobby. Double-, triple- and quadruple-check your schematic and your PCB layout before ordering parts and having PCBs fabricated. Nothing can decimate your budget faster than making rookie mistakes and wasting parts. As Ed said a few posts back, electronic design is a very detail-oriented activity. "Close enough" might work in carpentry but will not in building a computer. Making assumptions about things will only lead to a DOA unit and wasted parts.

[BigDumbDinosaur]

GARTHWILSON wrote:

Whatever you choose, make sure it has good macro capability...

Amen to that. If nothing else, macros help to take the tedium out of assembly language programming. I can't imagine working with an assembler that doesn't have a good macro language. Indeed, some of the stuff I do with the 65C816, especially in the area of stack-ro-batics, would be mind-numbingly difficult to accomplish without macros to automate things.