There are so many modern computers that are cheaper and easier to use, I'm always puzzled why people coming to retro computers. My own motivation is re-live my professional life and enjoyed the communities of people talking about the nuts and bolts of those days, and re-engineer those past decisions. I guess it is like old cars and model railroad. Automate those experiences and hiding the details of inner working somehow takes away the joys of remembrance and re-discovery. I suspect there are many different reasons and if we take a poll, we probably see a wide spectrum of responses. Plus there are people just like it, but unable to verbalize the reasons. I have bought my Arduino and Pi; turned them on, said 'wow', and put them away. Somehow they are not interesting, I don't know why. So part of me can't verbalize why I like retro and interested in making the old faster and cheaper, but not at all interested in the new, already fast, already cheap ones. (Sigh, a knee-jerk off topic response! (edit: I guess in current parlance, this response is called "triggered"))

Back on topic, I agree it is good to make retro cheap and accessible with cheap & powerful front-end, but personally it felt too black magic to me. This is not a negative response; it is wonderful in the broad sense, but just not for me.
Bill

And I guess, if you got it right, I daresay you could put in a 40-pin ZIF socket and slot in a different CPU like Z80, 6809, 6803, etc. ...

So there's a platform for someone who has the time to make it happen..

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thanks. This can't be done with an original Pico, because the Pico only offers 26 GPIOs on the board. 4 GPIOs are used for internal functions like power management and the LED. The "purple" was chosen, because it offers all 30 GPIOs of the RP2040. Having 16MB of flash was a benefit, that only came to use later for the wear levelling internal drive.

(The ideal number of GPIOs for this project would have been 31, so I needed to drop the SYNC pin. Having this would have offered my a good entry point to come up with a disassembler in when working on bus logs. I was thinking that I might be able to use the GPIO line for RDY with some kind of "multiplexing", but that would only work if I can pull down RDY during the "SYNC cycle" without stopping the CPU, and SYNC would be a low active signal, which it isn't.)

This can be done easily by just changing one line of code: change clockspeed of the RP2040 from 133MHz to 240MHz. Then you'll get ~2MHz on the 65C02 side. It's overclocking, but still something the RP2040 is known to work well with. For example when using the RP2040 for HDMI output, the example code clocks with 252MHz. BTW: The clockspeed is measured during runtime by the system.

I've got a W65C134SBX here. It's a nice little eval board. However it lacks features like the "poor man's logic analyser" that I've got, where you can see what happens the bus during every clock cycle.

Also another fun thing to do was to replace the 6502 with a 65816 and implement a 128k RAM system. That opened my eyes in another thing I was always looking out for. I had the idea of an Atari 2600 where I replace the CPU with a 65802 and an adapter board, so I can do stuff like triggering two strobe registers in to consecutive clock cycles. Or writing two color registers just one clock cycle apart. Once I was building the 65816 expansion, I realized that you just can drop in a 65816 instead a 65802 and it wouldn't make a difference. At least in my system.

This is easy to answer. Yes, a Raspberry Pi Zero is cheaper and more powerful, but you've got no chance of understanding the complete system. On a retro machine this can be accomplished, especially by the ones from the late 1970s. The whole KIM-1 can be self-taught over a weekend, if you already know about the 6502, up to a point where you can write your own code and add own hardware. With later machines, like a VIC-20 it takes longer, but it still can be done, up to a point where you create new graphics modes.

Also: why do people come back to antique cars?

Old cars aren't full of electronic wizardry that tracks you, raids your contact list, decides where you're going to be on the road, and can't replace individual parts without the factory's approval. Oddly enough, broadly similar observations apply to old computers...

But yes, I agree, the idea of something where you can understand every pin and every signal is incredibly appealing to me.

Neil

This got me thinking, since I've got a couple of experts here to discuss this.

To still implement this in a later revision I need to do two things:
1) get some kind of NOT gate. As far as I know, this could be done using a transistor. Can anyone point me out to a solution that would work in this context?
2) I'm doing some kind of feedback loop here, connecting the inverted SYNC signal back to the line that's also used for the RDY pin. Does somebody know if this will stop the processor for good already? Or do I need to build a test setup, once 1) is solved?

Knowing that the inverted SYNC signal would never go high again would make 1) obsolete.

Just came across the PICO-56 project which looks interesting.

Slightly different as it emulates the 65C02 rather than have a real one on-board.

Nice project though.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Yes, it is different and it emulates the 65C02 CPU @ ~3.7-MHz but I wouldn't mind checking it out. It looks like a reasonably economical build. I just ordered a set of PCB's (I got a few Pico's at a $2 introductory price from Micro Center when they first came out).

Speaking of RP2040 projects, I also just ordered a couple blank Apple II VGA PCB's.