6502 From the beginning

[rob42]

Hello. I'm very pleased to have found this Forum and I'd first like to thank Garth for all that he's done for what seems to be a very active community. I'm sure that there are many others that also deserve a "thank you", but as I'm very new to the world of the 6502, I'm ignorant of who the leading people are.

I'm currently planning a computer build, having been inspired by the wonderful videos that Ben Eater has produced.

I have a very basic setup right now. It's simply a 6502 on a breadboard, with the address lines hooked to 16 LEDs and a Rasp Pi Pico. The data bus is also hooked to the Pico, which I've coded to provide the clock signal, as well as to monitor the address lines and provide the `NOP` instruction that Ben initially hard wired with 8 resister (11101010). I can run this as slow as 0.385Hz which I'm pleased with.

Clearly, that's not a practical speed, but the point is, that I'm learning and I need to be able to control what I'm seeing. I've not tried to single step this yet, as I've no machine code to run, but the CPU is doing something, which brings me to my question: what is it doing?

I can see that the code that I'm presenting to the data bus, is in fact echoed to the address bus, twice, from T-State 10: once the low order byte, and again in the high order address byte. This is the first 20 clock pulses, as recorded by my monitor app, running on my Pico:

Code: Select all

MPY: soft reboot
Freq: 0
Running...
T-State: 1 ........................................
ADD BUS: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 | 0xFFFF
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 2 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 | 0x00FF
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 3 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 | 0x00FF
W: Reading from DATA BUS...
0 0 0 0 0 0 0 0 | 0x00
T-State: 4 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 | 0x0001
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 5 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 | 0x0100
W: Reading from DATA BUS...
0 0 0 0 0 0 0 0 | 0x00
T-State: 6 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 | 0x0100
W: Reading from DATA BUS...
0 0 0 0 0 0 1 0 | 0x02
T-State: 7 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 | 0x0100
W: Reading from DATA BUS...
0 0 1 1 0 1 1 0 | 0x36
T-State: 8 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 0 | 0x01FA
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 9 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 0 | 0x01FA
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 10 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 0 | 0xEAEA
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 11 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 1 | 0xEAEB
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 12 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 1 | 0xEAEB
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 13 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 0 | 0xEAEC
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 14 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 0 | 0xEAEC
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 15 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 1 | 0xEAED
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 16 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 1 | 0xEAED
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 17 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 0 | 0xEAEE
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 18 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 0 | 0xEAEE
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 19 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 1 | 0xEAEF
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 20 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 1 | 0xEAEF
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA

Please Note: It could very well be that I've not coded my app correctly and as such, it's as likely as not, that the clock sequence, is not showing as it should, but it'll only be either showing as twice as fast as it should, or half as fast as it should. Your feedback on this point would be welcomed.

This bit progression, simply continues and does something rather interesting after around 6K clock pulses, which I'm sure that anyone with any 6502 experience, will know about and fully understand.

As this is clearly not simply random noise, the code that is running this sequence, has to have come from the CPU and as such, I assume it's documented? My feeling is that it's running some kind of a 'memory' test routine, or maybe it's trying to find a 'boot loader'?

Finding out what is going on here, I feel is the next step I need to take and as such, I'd appreciate any information that would show me what's happening.

There's a tonne of information about the CPU and how to code it, but finding this specific info, is proving more of a challenge than was the coding of my monitor app!

I'm looking forward to this new area of electronics and related computer build, as I plan on recreating what the homebrew guys did (back in the day) and build my very own 6502 computer.

With thanks, in advance.

Rob.

[Dr Jefyll]

rob42 wrote:

As this is clearly not simply random noise, the code that is running this sequence, has to have come from the CPU and as such, I assume it's documented?

Hello, and welcome!

I think each message saying "W: Reading from DATA BUS..." should say "W: Writing to DATA BUS." And, each message saying "R: Writing to DATA BUS" should say "R: Reading from DATA BUS."

The first part of your sequence seems to contain inconsistencies, and I won't try to speculate why -- afraid I don't have time ATM. But plainly it ends with a reset or an interrupt.

I've listed the latter part of your sequence below, and this part 99% makes sense. States 8 and 9 appear to be the vector fetch following a reset or an interrupt. Together they indicate $EAEA, and indeed, as expected, that's where execution commences. (But the reason I say 99% makes sense -- not 100% -- is because I don't believe both fetches came from 0x1FA -- I believe that's not accurately reported.)

At $EAEA (and all other locations!) we have $EA, which is NOP -- a 1-byte instruction that takes 2 cycles to execute. And indeed we see that. (I have added comments.)

Hope this helps,

-- Jeff

Code: Select all

T-State: 8 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 0 | 0x01FA    <- fetch vector lowbyte
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 9 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 0 | 0x01FA    <- fetch vector highbyte
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 10 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 0 | 0xEAEA  <- execute the NOP at address EAEA
R: Writing to DATA BUS...                      
1 1 1 0 1 0 1 0 | H:EA
T-State: 11 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 1 | 0xEAEB  <- pre-fetch the next byte but ignore it
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 12 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 1 | 0xEAEB  <- execute the NOP at address EAEB
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 13 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 0 | 0xEAEC  <- pre-fetch the next byte but ignore it
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 14 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 0 | 0xEAEC  <- execute the NOP at address EAEC
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 15 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 1 | 0xEAED  <- pre-fetch the next byte but ignore it
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 16 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 1 | 0xEAED  <- execute the NOP at address EAED
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 17 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 0 | 0xEAEE  <- pre-fetch the next byte but ignore it
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 18 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 0 | 0xEAEE  <- execute the NOP at address EAEE
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 19 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 1 | 0xEAEF  <- pre-fetch the next byte but ignore it
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA
T-State: 20 ........................................
ADD BUS: 1 1 1 0 1 0 1 0 1 1 1 0 1 1 1 1 | 0xEAEF  <- execute the NOP at address EAEF
R: Writing to DATA BUS...
1 1 1 0 1 0 1 0 | H:EA

[rob42]

Thank you for the very fast reply.
Indeed, your comments do help me to better understand this startup sequence and I'll need time to get this into my way of thinking (it's early morning here, and I need to sleep).

Also, thank you for your comments regarding my monitor app. From what I can gather, it seems that my clock timing output is correct, which I thought it could be, but I was unsure.

As for the the way I have coded the data bus read/write, it may seem a little odd, but the 'R' means that the 6502 is reading the data bus, so my app is 'writing 11101010', and vice-versa. Possibly, this makes no sense to anyone else and as such I'll consider either changing this or coding in some better description.

Thank you for your time, the information and the constructive criticism.

Enjoy your day.

~ Rob.

[Dr Jefyll]

rob42 wrote:

I can run this as slow as 0.385 Hz

This is too slow for a 6502 to operate reliably. (Or did you mean to say 0.385 MHz ?)

A 65C02 can run as slowly as you like, but an ordinary (ie, NMOS) 6502 may get erratic at low clock rates. This -- or a flaky connection or other fault with your data reporting -- could perhaps explain the inconsistencies in the first portion of your trace.

Hope you get some sleep soon!

-- Jeff

[BigEd]

Welcome, Rob!

Indeed as Jeff notes you're seeing the reset sequence of the 6502. It doesn't start out in life by reading an instruction - it starts out by finding out where that first instruction is. Other microprocessors do it differently.

You'll see various commentary that the reset sequence is very like an interrupt sequence. In your case, your setup notices accesses to page 0100, which is the stack, and what's happening is the 6502 is making the three stack accesses which an interrupt would need (in order to later recover the state of play when the interrupt routine finishes.)

As Jeff notes, the original NMOS 6502 and the later CMOS 65C02 have some differences. Among those differences are whether those three stack accesses are writes (as would be normal for an interrupt) or reads (which makes the reset sequence non-destructive.)

I'd recommend having a play with visual6502 simulations - they should match very closely what an NMOS 6502 will do, cycle by cycle. In fact, half-cycle by half-cycle.

[rob42]

@Jeff

Dr Jefyll wrote:

This is too slow for a 6502 to operate reliably. (Or did you mean to say 0.385 MHz ?)

I do mean 0.385Hz. In fact, I'm as surprised as anyone, that the CPU does not simply do random stuff, at this clock speed, and I've run it much faster to compared the monitor traces of different run speeds, just to be sure that I'm getting the same results. I will, however, do this again, just to be sure that I didn't miss something, which is as likely as not, given that I had no real idea about what I was looking at. This is now becoming clearer, as I learn.

That said, when I get to the stage where I'm addressing other ICs (such as memory chips) it could possibly be a different story and I'm looking forward to trying that. I've had to do things the way that I am, right now, as I don't have a EPROM programmer and I'm unsure as to which one my limited cash supply should be invested in. The same goes for the EPROMs. I see many different ICs for sale, but I don't know if I'm looking at the correct ones and I can't afford to buy things that will not do what I need them to do. I can't follow exactly what Ben Eater did, because I don't have the exact same CPU as Ben used. I don't see that as being a disadvantage, per se, but more that I'll learn more by deviating and building my own circuits, in my own way, then, when they don't work, figuring out why they don't work and finding a fix.

To be clear, I have a Rockwell R6502BP, which I understand to be a 3MHz (as denoted by the 'B') NMOS(?) CPU with a 2008 date code.

The way I have things right now, I can run this up to about 500Hz before the signal noise becomes to great. All I really have right now, is a proof on concept, and I'll build a proper timing circuit as and when I need to.

The other build guide I'm studying, is the one called "6502 PRIMER: Building your own 6502 computer" by Garth Wilson (thank you very much, Garth), which I'm sure you are all quite aware of.

I also see that there's also a huge amount of information in these Forums, for which every single member has my thanks.

A very special "thank you" goes out to Mike Naberezny, for very obvious reasons.

Thank you, once again, Jeff, and I love your avatar, btw

---

@BigEd

Thank you for your reply and the welcome.

Your comments are also very useful and I take on board your suggestion of finding and using a 6502 sim; good call.

All in all, I have much to learn. I'm coming at this from a coding background (Python) which makes me think in those terms, rather than a hardware/electronics background, which I'm finding to be a very different discipline. The nature of capacitors and capacitance, for example, had me very confused, at first, and I'm still not sure that I fully understand the topic. Other things, such as logic gates, transistors, resistors and resistance, as well as TTL, are much clearer to me.

---

I originally thought that I'd be able to devise some kind of a software solution, rather than investing in EPROM equipment, but maybe I'm simply creating issues for myself by trying to do things that way, even if it's possible, which I'm not entirely sure about. I'm guessing that there's going to be threads about EPROM programmers and the like, so I'll have a good look around and see what I can find.

My best regards to all and I'll be back here again later today.

~ Rob.

[GARTHWILSON]

rob42 wrote:

To be clear, I have a Rockwell R6502BP, which I understand to be a 3MHz (as denoted by the 'B') NMOS(?) CPU with a 2008 date code.

That's a fake.  See our sticky topic, "65xx parts sources, genuine and fake."  The R prefix means it's made by Rockwell; but Rockwell quit making the 65c02 years before 2008 (maybe around year 2000?) and the NMOS 6502 undoubtedly before that.  You almost certainly have a 65c02 (which is good), as the NMOS had a specified minimum of 100kHz to guarantee that it wouldn't lose internal states and lose its way, kind of like DRAM that needs constant refreshing.  65c02's have always been able to stop; but only the ones from WDC could stop in either phase.  Ones from other manufacturers, like Rockwell, Synertek, and California Micro Devices, could only stop with phase 2 high, not low. In the clock-generation page of the 6502 primer, you can see the way shown to allow single-cycling without violating that timing, where there's the paragraph starting with "You may someday want to single-cycle".

[rob42]

GARTHWILSON wrote:

That's a fake.... 

Ah, okay. Thank you for that.

I've removed it from my board, so that I could get a good picture. That way you can check the markings and know that I've got the identification correct, or tell me where I'm wrong.

It was off of eBay and was real inexpensive, so there's that. If it won't hinder my progress, I'll continue to use it, but otherwise I'll replace it.

From what you said, it could be that I have a more 'usable' chip than what I though, yes?

[BigEd]

A 'C02 is probably more useful, so stick with it!

An NMOS '02 is handy if you're looking for some kind of historical authenticity, or you really like to code with undocumented opcodes.

[rob42]

BigEd wrote:

A 'C02 is probably more useful, so stick with it!

An NMOS '02 is handy if you're looking for some kind of historical authenticity, or you really like to code with undocumented opcodes.

Thank you; I will.

What I want to do (which is a ways down the road, yet) is to have a old school type of homebrew computer, that folks like us built back in the very early days. It's akin to having, say, an E-Type Jaguar, but with modern electrics and running gear: it'll look and feel like the old classic, but it'll be way more usable.

The final design is very much in flux, right now, as I have very little know-how, but with help and guidance, I see no reason why I can't make this happen. After all, this is 2024, not 1974, and as such I have infinitely more resources on which I can draw. I do so admire what those guys did and I am one of the few who fully appreciate that what I'm using today, on which I'm typing out this post, could not be possible without the work and dedication from those guys: my hat goes off to them.

[John West]

The way to be sure is to try executing one of the new 65C02 instructions and see what it does. Once you've got it reliably executing instructions, try opcode $8f. On the 65C02 that's BBS0, which will take a zero page address and an 8 bit offset, read from memory, and either branch or not depending on the value it read. On the NMOS 6502, that's the undocumented instruction SAX abs, which will store the result of ANDing the A and X registers. Feed it $8f, $ea, $ea, $ea, $ea, ..., and see if it writes to memory. I expect it won't.

That chip appears to be laser-etched: the top right of the logo is dark and the bottom left is light, which is what I'd expect from an indentation being lit from the top right. I'm pretty sure that wasn't happening when Rockwell were making 6502s.

[plasmo]

rob42 wrote:

I originally thought that I'd be able to devise some kind of a software solution, rather than investing in EPROM equipment, but maybe I'm simply creating issues for myself by trying to do things that way, even if it's possible, which I'm not entirely sure about. I'm guessing that there's going to be threads about EPROM programmers and the like, so I'll have a good look around and see what I can find.

Since you already have a Pi Pico monitoring 6502 addresses and feeding instructions to 6502 and you've gone down the path of understanding every cycle of 6502 instruction executions (a daunting task, BTW, and Dr. J is your best help), you actually don't need an EPROM programmer. All you need is a setup with RAM & 6502 & IO that uses Pi Pico to feed the initial set of instructions which are written into RAM, then engage RAM & disengage Pi Pico and watch it runs by itself. The process is a bit convoluted akin to starting a gas-powered car, but quite a bit have written about starting up 6502 with the topic of 'bootstrap'

Once you've kicked started 6502 with Pi Pico, you can use the 6502 to program EPROM. That would be a fun & useful first project with your new hardware.

Welcome to 6502.org!
Bill

[BigDumbDinosaur]

Welcome, Rob!

GARTHWILSON wrote:

rob42 wrote:

To be clear, I have a Rockwell R6502BP, which I understand to be a 3MHz (as denoted by the 'B') NMOS(?) CPU with a 2008 date code.

That's a fake.  See our sticky topic, "65xx parts sources, genuine and fake."  The R prefix means it's made by Rockwell; but Rockwell quit making the 65c02 years before 2008 (maybe around year 2000?) and the NMOS 6502 undoubtedly before that...

According to information I have, 2000 was the last year Rockwell produced any 6502-family chips.  That R6502BP is indeed a fake.  You should be aware that the 65C02 is a commonly-counterfeited part that regularly turns up on eBay sites.  As Garth notes, we have discussion around here on where to obtain parts and how to avoid being gypped by unscrupulous sellers of fake 6502 parts.

In any case, an NMOS 6502 cannot run that slowly—it is a dynamic design that will lose state at subnormal clock rates.  All 65C02s of which I am aware can be safely stopped on Ø2 high.  Only the WDC 65C02 can be safely stopped on either clock phase, which is possible because it is a fully static design.

[BigDumbDinosaur]

John West wrote:

That chip appears to be laser-etched: the top right of the logo is dark and the bottom left is light, which is what I'd expect from an indentation being lit from the top right. I'm pretty sure that wasn't happening when Rockwell were making 6502s.

I noticed that as well.  The markings are wrong for a genuine Rockwell part, and I have never seen the real McCoy with laser markings.

[rob42]

Thanks guys, for all these responses. I'll take them one at a time:

John West wrote:

The way to be sure is to try executing one of the new 65C02 instructions and see what it does. Once you've got it reliably executing instructions, try opcode $8f. On the 65C02 that's BBS0, which will take a zero page address and an 8 bit offset, read from memory, and either branch or not depending on the value it read. On the NMOS 6502, that's the undocumented instruction SAX abs, which will store the result of ANDing the A and X registers. Feed it $8f, $ea, $ea, $ea, $ea, ..., and see if it writes to memory. I expect it won't.

I'm not too sure if I've done this correctly, but here goes...

Running at 5Hz: for the first 21 cycles, I simply have 0x00 being presented to the data bus, while the CPU settled into its 4 reads, 3 writes cycle. Given that, it was then easy to time my app to present 0x8F at T-State 22 and 23, after which 0xEA all the way.

This is my monitor trace. I've done a little rework on my code, so that the output is clearer to read. As I'm unsure about what I should be seeing, I'm hoping that you'll come back and tell me what you see, and if ti's what you expected to see, or maybe tell me what I've done wrong, if I have in fact, messed this up in some way.

Code: Select all

>>> %Run -c $EDITOR_CONTENT

MPY: soft reboot
Freq: 5
Running...

T-State: 1 ........................................
ADD BUS: 1 0 1 0 1 1 1 1 1 0 1 0 0 0 0 0 | 0xAFA0
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 2 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | 0x0000
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 3 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | 0x0000
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 4 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 | 0x0001
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 5 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 | 0x0100
Writing: 0 0 0 0 0 0 0 0 | 0x00

T-State: 6 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 | 0x01FF
Writing: 0 0 0 0 0 0 1 0 | 0x02

T-State: 7 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 | 0x01FE
Writing: 0 0 1 1 0 1 0 0 | 0x34

T-State: 8 ........................................
ADD BUS: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 | 0xFFFE
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 9 ........................................
ADD BUS: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 | 0xFFFF
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 10 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | 0x0000
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 11 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 | 0x0001
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 12 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 1 0 1 | 0x01FD
Writing: 0 0 0 0 0 0 0 0 | 0x00

T-State: 13 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 1 0 0 | 0x01FC
Writing: 0 0 0 0 0 0 1 0 | 0x02

T-State: 14 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 1 | 0x01FB
Writing: 0 0 1 1 0 1 0 0 | 0x34

T-State: 15 ........................................
ADD BUS: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 | 0xFFFE
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 16 ........................................
ADD BUS: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 | 0xFFFF
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 17 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | 0x0000
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 18 ........................................
ADD BUS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 | 0x0001
Reading: 0 0 0 0 0 0 0 0 | 0x00

T-State: 19 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 0 | 0x01FA
Writing: 0 0 0 0 0 0 0 0 | 0x00

T-State: 20 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 0 0 1 | 0x01F9
Writing: 0 0 0 0 0 0 1 0 | 0x02

T-State: 21 ........................................
ADD BUS: 0 0 0 0 0 0 0 1 1 1 1 1 1 0 0 0 | 0x01F8
Writing: 0 0 1 1 0 1 0 0 | 0x34

T-State: 22 ........................................
ADD BUS: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 | 0xFFFE
Reading: 1 0 0 0 1 1 1 1 | 0x8F

T-State: 23 ........................................
ADD BUS: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 | 0xFFFF
Reading: 1 0 0 0 1 1 1 1 | 0x8F

T-State: 24 ........................................
ADD BUS: 1 0 0 0 1 1 1 1 1 0 0 0 1 1 1 1 | 0x8F8F
Reading: 1 1 1 0 1 0 1 0 | 0xEA

T-State: 25 ........................................
ADD BUS: 1 0 0 1 1 1 1 1 1 0 0 1 0 0 0 0 | 0x9F90
Reading: 1 1 1 0 1 0 1 0 | 0xEA

T-State: 26 ........................................
ADD BUS: 1 0 1 0 1 1 1 1 1 0 0 1 0 0 0 0 | 0xAF90
Reading: 1 1 1 0 1 0 1 0 | 0xEA

T-State: 27 ........................................
ADD BUS: 1 0 1 1 1 1 1 1 1 0 0 1 0 0 0 1 | 0xBF91
Reading: 1 1 1 0 1 0 1 0 | 0xEA

T-State: 28 ........................................
ADD BUS: 1 1 0 0 1 1 1 1 1 0 0 1 0 0 0 1 | 0xCF91
Reading: 1 1 1 0 1 0 1 0 | 0xEA

T-State: 29 ........................................
ADD BUS: 1 1 0 1 1 1 1 1 1 0 0 1 0 0 1 0 | 0xDF92
Reading: 1 1 1 0 1 0 1 0 | 0xEA

T-State: 30 ........................................
ADD BUS: 1 1 1 0 1 1 1 1 1 0 0 1 0 0 1 0 | 0xEF92
Reading: 1 1 1 0 1 0 1 0 | 0xEA

T-State: 31 ........................................
ADD BUS: 1 1 1 1 1 1 1 1 1 0 0 1 0 0 1 1 | 0xFF93
Reading: 1 1 1 0 1 0 1 0 | 0xEA

T-State: 32 ........................................
ADD BUS: 0 0 0 0 1 1 1 1 1 0 0 1 0 0 1 1 | 0x0F93
Reading: 1 1 1 0 1 0 1 0 | 0xEA

Thank you very much, John.

---

plasmo wrote:

Since you already have a Pi Pico monitoring 6502 addresses and feeding instructions to 6502 and you've gone down the path of understanding every cycle of 6502 instruction executions (a daunting task, BTW, and Dr. J is your best help), you actually don't need an EPROM programmer. All you need is a setup with RAM & 6502 & IO that uses Pi Pico to feed the initial set of instructions which are written into RAM, then engage RAM & disengage Pi Pico and watch it runs by itself. The process is a bit convoluted akin to starting a gas-powered car, but quite a bit have written about starting up 6502 with the topic of 'bootstrap'

Once you've kicked started 6502 with Pi Pico, you can use the 6502 to program EPROM. That would be a fun & useful first project with your new hardware.

Welcome to 6502.org!
Bill

That's a very good suggestion and would be (as you say) a fun & useful first project. I would, in fact, like to remove the Pico from the loop entirely, once I no longer need it to monitor the 6502 and provide its ϕ₀(IN) signal.

I will certainly find and read what others have posted on the topic of 'bootstrapping'.

Thank you so much, Bill, for this and the welcome.

---

BigDumbDinosaur wrote:

According to information I have, 2000 was the last year Rockwell produced any 6502-family chips.  That R6502BP is indeed a fake.  You should be aware that the 65C02 is a commonly-counterfeited part that regularly turns up on eBay sites.  As Garth notes, we have discussion around here on where to obtain parts and how to avoid being gypped by unscrupulous sellers of fake 6502 parts.

In any case, an NMOS 6502 cannot run that slowly—it is a dynamic design that will lose state at subnormal clock rates.  All 65C02s of which I am aware can be safely stopped on Ø2 high.  Only the WDC 65C02 can be safely stopped on either clock phase, which is possible because it is a fully static design.

Thank you very much for your input and the welcome.

It seems that I've fallen into the same trap as I'm sure that many others have done before me. To be fair to the seller from whom I got this CPU, maybe he's not as 'up-to-speed' on these facts as he should be, and he's unaware that he's selling fakes.

I will indeed use better suppliers, moving forward.

Again, thank you.

---

I'd just like to finish this post by again thanking you all for your time, as well as the information and help. I can see that this a fantastic community and I hope to be able to contribute, in some way, when I feel that I have something to offer.

My intention is to document this project so that it can be used by anyone else wishing to build this kind of gadget. I know that that are loads of builds that have already been documented, but they're unique, in one way or another, and mine will also have its own personality.

My best regards to you all.

~ Rob.