Hi All.

It's been a while, but the 6502 bug bit me again.

Now, technically, this is not my first build but my second. I still haven't moved from breadboard and didn't want to strip down my first effort - which does work (and I wanted to keep it that way). This was a Ben Eater "clone".

This time I have used an ATF22V10C for address decoding. So, my 2nd build has the VIA in zero page ($F0 - $FF), has a larger ROM (which I only use 32K of - SST39SF010A) and a full 32K of RAM. I've also included a ZIF. It's sort of a deluxe version of my first build. My memory map is as follows...


When I build, I use an Arduino Mega like Ben does in his videos to monitor how the system is performing. However, I'm running into an issue I just can't wrap my head around and am reaching out for any assistance that can be offered.

The system has no yet output (like serial, for example) so I have to look at the Arduino Mega monitor output to establish what my WDC 65C02 is doing. I also have a WDC 6522 and have it wired up to 8 LEDS. I wrote a simple program to store 10101010b in PORTA and EOR it with 11111111b in a loop - this gave alternate LEDs blinking and worked as intended. When I "upgraded" this for a running LED (Knight Rider style!) it didn't work. I ended up rewriting some code to test why it didn't work. In essence, incrementing an 8-bit number and displaying it on the LEDs connected to the VIA.

Here's both the code and the monitor output. $00 is loaded into A and then stored in PORTA - but the monitor shows $FF is actually stored - and ALL the LEDs light up, which suggests that is the case. What is striking is that it NEVER gets to execute the INC instruction ($E6) at location $800A. Instead, for some reason I cannot fathom, it jumps over it and the code goes haywire after that. Resetting just results in the same output in the monitor. PHI2 is around 1Hz to facilitate reading what's going on.
So, why does it write $FF although we start with $00 and why doesn't it execute the INC - any ideas?

CODE:
MONITOR OUTPUT: (running off into oblivion)

Thanks in advance for any ideas as to why or additional diagnostics to check other things.

Dave

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

In following your capture, after the write of "FF" to PORTA, I would expect the next read to be from $800A, but instead its reading from $800B, which is the operand for the INC opcode. You may want to verify your write to RAM signals are working. Maybe after the write of $00 to VAL, lda #$A5, then read VAL to ensure it returns $00. if it returns $FF, that points to the write signals not working right. Did you qualify the R/W with PHI2?

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

OK - I don't have a schematic as I've been building as I go (referring to the Ben Eater videos as he connects CPU, ROM, RAM, VIA etc.). I can sort one, however.

I did "test" the RAM. Once I had the 65C02 and ROM working (validated by the monitor) I rewrote the code to include JSRs which, if I understand correctly, need RAM in order to store the return address. Furthermore, I did some "lda ($80),y" loops holding y at zero and doing 16-bit addition to increment $80 & $81. The monitor showed the correct memory addresses were being accessed.

Now, in full transparency, I'm probably reaching outside of my skills here ("a little knowledge is a dangerous thing" kind of scenario) but I like to challenge my understanding, otherwise I won't improve.

Here is my ATF22V10C logic...

I also have to admit that the negating of the definitions (!WE = CLK & !RW) and the pin mapping of just Pin 23 = WE left me unsure if it was the right way around, but I copied this from other sources online (one being yours, Daryl) so I figured it must be right. I checked the !CS for ROM/RAM/VIA and they all worked as expected.
However, the logic around RAM0, RAM1, ROM0 & ROM1 to weave in zero page VIA ($00F0 - $00FF) and more IO in page &FE is all mine - so I take full responsibility for that!

Looks like you have an unplanned interrupt. Try disabling them early on in your code and see if your LEDs start blinking again.

Edit: actually, on closer inspection, it's an unplanned BRK opcode. Check your RAM address decoding and timing?

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

It doesn't look like an interrupt - it looks like a BRK instruction. You can see the reset vector fetch at the top of the trace, and there's no CLI in sight.

There are three mysteries:
* why is it writing $ff to $00f1 just after it has loaded $00 from $0080?
* why is the next instruction being fetched from $800b?
* why isn't that instruction behaving like a BRA? It's fetching from $800b again on the second cycle, and then somehow makes a leap to $81ff.

Once it's at $81ff, it's fetching a BRK and everything from that point looks like it should.

I can't think of anything that would make a 6502 fetch the opcode twice, and I can't think of anything (except a JMP or JSR) that would make a 6502 jump from $800b to $81ff. So that makes me wonder - how's the power supply? If you have an oscilloscope, take a look at it. It is possible to do impressive things on breadboards, but they also make it easy to get things wrong.

But if it's failing the same way every time, it's probably not a noise problem. In that case I have no clue.

Are you certain that the Arduino is connected to the 6502 correctly? Does every address line go to the right place? It's worth checking them again. If your first board is still working properly, I'd try moving the Arduino over to it and check that it's reading things correctly. There is nothing harder than debugging a system with a tool that you haven't realised doesn't quite work.

It's also worth getting the Arduino to look at SYNC. Knowing which cycles are the opcode fetches makes these traces that little bit easier to read.

I've managed to now produce a schematic. This is my first, so apologies if it doesn't follow some convention I'm ignorant of.
I'm in the process of doing another round of checking all the connections are correct and do, indeed, follow my schematic.

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

Thank you, BDD, for your observations. I appreciate your input.

1. Your reset circuit is not compatible with the 65C02, as RESETB on WDC MPUs does not have Schmitt triggering.  See Garth’s 6502 primer site, specifically the reset page, for examples of working circuits. OK - I have a D1813 somewhere - I'll dig through my parts and press it into service. I was copying the Ben Eater reset circuit.
    
2. Your clock generator is likely not producing a signal that meets WDC’s requirements due to the use of 4000-series logic.  I recommend you use a single 74AC74 or 74AHC74 flip-flop, driven by the oscillator, to generate Ø2.  The flop will produce the required rise/fall time, as well as a symmetric output.  See here for some working examples of clock generators. Can I put a 74LS74 (I have 1 in my parts bin) on the 4000 series output to bring it into line with WDC's requirements?
    
3. The MPU’s RDY pin *must not* be directly connected to VCC.  RDY is a bi-directional pin that goes low when the C02 executes a WAI instruction (intentionally or otherwise).  Should that happen in your circuit, RDY will be effectively shorting VCC to ground.  RDY should be pulled up to VCC with a 3.3K (typical) resistor. I'll fix that straight away before I ever power it up again!
    
4. IRQB, NMIB and (optionally) SOB should be tied to VCC through 3.3 K resistors as well.  Even though you currently aren’t using any of those pins, you may wish to in the future.  With them permanently tied to VCC, you have a problem if you decide you need them. Again, I'll address this straight away.

This illustrates something about Mr. Eater’s circuits that has been discussed here in the past.  In his expositions, he has, on several occasions, either omitted a detail that is actually quite important to achieving reliable operation or has presented something that is known to be at odds with correct operation.  The reset thing is one of those details.

BTW, a push button should not be wired in a way that allows it to directly short out a charged capacitor.  Although the 0.01 µF capacitor in your reset circuit doesn’t hold much of a charge, the instantaneous current flow upon being shorted by the push button is higher than one might suppose, and could eventually lead to contact sticking.  In a circuit in which a push button, relay contact or semiconductor could effectively short out a charged capacitor, I add some low series resistance to limit the maximum current to a safe level.
 

Please reread what I posted about recommended logic families for clock generation. 

WDC MPUs are somewhat fussy about clock quality, even at low frequencies.  Ø2’s rise/fall time should not exceed 5 nanoseconds, and should be at CMOS levels.  That means Ø2 high should be at least VCC × 0.7 and Ø2 low should be no more than 0.3 volts above ground.  The VCC × 0.7 requirement is not reliably achievable with 74LS logic (VOH with 74LS logic is theoretically 3.4 volts, unloaded, with a guaranteed VOH of 2.4).  Hence the 74AC/AHC recommendation (74ACT/AHCT will also work).  Slow clock edges and/or insufficient voltage swing may result in unreliable operation or outright failure.

Here is the clock circuit I have used in several of my POC designs:

Attachment:

File comment: Clock Generator

clock_gen_2phase.GIF [ 16.88 KiB | Viewed 139 times ]

The above would replace the 4000-series devices you have in your present clock generator.  The Ø1 output wouldn’t normally be required in a 65C02 circuit.

I recommend that you not use 74LS logic with WDC devices.  Although the WDC 65C02 seems to be fairly forgiving about what it will accept as valid input, Jeff’s (Dr Jefyll) tests confirmed that the 65C02 and 65C816 are not TTL-compatible—their perception of where a logic transition occurs is slightly above VCC × 0.5.  That threshold is well above the guaranteed VOH output of a typical 74LS device.

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

_________________
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?

Thanks, BDD, for expanding further. Garth, I will (re)reread your primer.

When I did my first build, I watched all of Ben Eater's videos but put my "spin" on things as I went along. That didn't work out well. A bit too much hubris on my part, methinks. So, I started from scratch and followed his videos meticulously until I HAD to diverge to get a FTDI rather than MAX232 solution for serial comms. That has given me a 6502 with 16Kb RAM / 32kB ROM that worked. I even wrote my own monitor. However, it is on breadboard still and I'm petrified of using it in case a pull a wire or something. Hence, I want to build another and, yes, do it "my way" this time around. As an engineer (civil engineering) I have a reasonable grasp of maths & science but I don't have a foundation in electronics so still struggle with some concepts. But, I'm hoping exposure to the wealth of experience and advice on this forum will bring me along. A PCB of my system, designed by me, the way I want is my dream outcome.

But, it's a double-edged sword. The skills and expertise I see exercised on this forum are sometimes so mindbogglingly staggering to a man such as myself with humble understandings on such matters that I can get lost very early into some of the threads. Yes, OK, the first thread. Consequently, I feel intimidated and shy of asking basic questions that I haven't been able to self-serve by Googling. I'm conscious of being a pain in the you know what! I should remind myself that this forum is all about sharing and giving back - and not be overly sensitive. After all, there's no such thing as a stupid question, right? Right?

Anyhow, I have some rereading to do.

It's probably fair that some of the posts here can drop into esoterica very quickly, and that's probably because some of us have been doing it since the 6502 was first released, and are still finding things interesting.

But you're in a community that won't shout at you for 'stupid' questions; instead we'll try and guide you. We'll show you generally accepted 'best practices' which most of us can usually agree on; we'll show you the usual pitfalls. Please feel that you are being encouraged, not criticised for 'doing it wrongly'.

As an example, I am completely allergic to prototype boards and rarely use them, and then only briefly. In fact, I designed a PCB that mimics a proto board layout, and incidentally accepts either SOIC or DIP parts. And has built in spaces for decoupling capacitors... in many of my work projects, I don't prototype at all; we go straight to a printed circuit board, expecting that it will require several iterations before it's a product. But it's cheaper for the company to quickly populate a PCB than to wait multiple days of engineer time trying to find that wire in the wrong place, or the missing capacitor, or the bad contact.

As hobbyists we have the luxury that our time costs us nothing, of course... but it's sometimes nice to know that what you have built is actually what you designed, and that the common problems have already been designed out.

Neil

Yes, please bear with it: you will get some advice which is overly careful and strongly worded, which will make things seem more scary and difficult than necessary. Unfortunately, the more nuanced advice that's suitable for a first self-build is harder to come by here.

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