First! Love this project. It's an amazing demonstration of the capabilities of the Pico, at the same time beautifully illustrative of how technology has progressed since the 6502 first appeared.
I'm far from an engineer (humanities guy), but somehow you can explain all those digital electronics intrincacies in such a clear and simple manner, I'm impressed!
Loving this series - the interfacing of the 6502 direct to the PIO on a Pico is _exactly_ something I'd been idly mulling over the last few days, and here it is!
I think I would be tempted to have the 7430 feed a 74137 to split the I/O space into 8 blocks of 32 bytes, the last one being used by the Pico. That would reduce propagation delays to just 2 chips. You would still be using just 3 logic chips as /WE and /IRQ can be generated with a quad nand. It’s a great series so far and it good to see how much you have pushed the Pico PIO / DMA trick to get such fast random access from the Pico RAM.
So glad you did this. So many projects divide the memory space into big chunks, most of which are wasted. Using the top 256 bytes of memory for the Pico and VIA is brilliant.
Well done! It might be possible to re-arrange the gates to reduce the critical paths length. This may cost an additional gate however, so changing the chips for faster ones was definitely the best option!
Wild suggestion here, but you should release this as socketed DIY PCB....Maybe even a socket for the Picos, and have 4, or more Picos (2 mandatory). It could be like a 6502 Pico super computer. Also I'm sure the sound could be socketed for some new old stock sound chip, or maybe even made from the Picos themselves. Either way really great idea here for learning about computers, Picos, and the 6502.
@@GodmanchesterGoblin yeah I started following this project because I was wanting to make a ultimate NES kind of doing everything you see here but with a Nintendo and upgrading it's capabilities but that's way too ambitious for my skill set right now and I'm taking it slow trying to understand this stuff.
Can anyone re-assure me? : I think I see bus contention on the first half of the RAM write cycle. When I had assumed that the 6502 transacts the bus on the rising edge, I thought the cunning plan was to replay what had just been programmed into the RAM address in the face of the still-oncoming data - hopefully *the same* (!) but now having had a re-visit of Ben Eater's bus timing video for 6502, I see that the zero mark is the falling edge (of phi_2). So, doesn't the ¬WE of the RAM get cancelled (raised) at one gate delay (U6a) from this fall and then, because the other bus controls of the RAM are tied open, it begins to output on the address which the CPU presently, but not 'too' slowly, begins driving address #and# data for? If you went and single-stepped it like this, couldn't it burn out if you stopped the clock in the wrong half? I haven't delved hard into what the Pico-based clock generator does for its part, but I suppose that could be a very uneven duty cycle only just acceptable to spec on the low period, which might fix things good and well. Otherwise, is there any harm tying U7, pin 10 (U7c output: post-invert of 6502 R/¬W ["RWB"]) to RAM ¬OE (instead of a short to ground)? Bi-directional busses are an absolute terror : I suppose wiring double a data bus (even if only 8 bit) is likewise a board and chip packaging nightmare, so hardly ever done - definitely not the 'commodity' approach - so unavailable (plus we only have so much Pico!)
I think that I am missing something. There’s a nice simulation of the gates but I cannot find the source on your GitHub - I assume there’s some kind of file and that some software is required for the simulation. It all seems magical to me at the moment but I’d prefer to understand it.
It's easy to recreate in your favorite simulator. Also, git never forgets. github.com/picocomputer/rp6502/tree/3d5e5b288b1c95bb1d743bef5801223825f4d838/sch
