74HCT6526 SBC TestBed

[BigDumbDinosaur]

daniMolina wrote:

Updated schematics, with just some minor tweaks.

I still see the 74ABT74 in the clock generator circuit.

Quote:

I want to leave you a question that's been around my head...What are the odds...that an old, NMOS 6526 will work here?

Probably iffy. Aside from the TTL outputs of the real 6526, the fanout of its MPU-facing side is weak. No harm in trying though.

[Chromatix]

The input loads of CMOS devices are much lighter than those of 74LS series, so fanout is generally improved. What matters is whether the inputs the 6526 has to drive accept TTL standard levels. The most important inputs to drive are the data bus pins of the CPU.

On the W65C02S, Vih on the D lines is 70% of Vcc. That's substantially higher than the TTL standard of 2.0-2.4V on Vcc of 4.5-5.5V. So it *might* work at moderate speeds, but it also might not.

You can substantially increase your odds by inserting a CMOS bus transceiver that accepts TTL input levels, ie. a 74HCT245 (or AHCT or ACT, if you prefer), on the data bus immediately in front of the 6526. Use R/W to select the transfer direction, and pass /CE of the 6526 to /CE of the '245 as well.

[BigDumbDinosaur]

Chromatix wrote:

The input loads of CMOS devices are much lighter than those of 74LS series, so fanout is generally improved.

Don't forget about the circuit's parasitic capacitance. That has nothing to do with the type of load.

[Chromatix]

Input capacitance on the W65C02S is specified as one-third that of an NMOS original, on the data bus. That's in addition to the input leakage current being two orders of magnitude lower.

As I said, CMOS loads are lighter than TTL loads.

[BigDumbDinosaur]

Chromatix wrote:

Input capacitance on the W65C02S is specified as one-third that of an NMOS original, on the data bus. That's in addition to the input leakage current being two orders of magnitude lower.

As I said, CMOS loads are lighter than TTL loads.

I was referring to the parasitic capacitance of the board. It's going to be the same whether using TTL or CMOS logic.

[GARTHWILSON]

BigDumbDinosaur wrote:

I was referring to the parasitic capacitance of the board. It's going to be the same whether using TTL or CMOS logic.

yep, and sockets, and memory, and anything else that might be separate from the processor and glue logic

[Chromatix]

Well, at the very least, the capacitive load won't be any worse with CMOS inputs. It should be manageable at moderate speeds (which an NMOS 6526 will be limited to anyway) and provided the input threshold voltages are compatible. People *have* successfully used a W65C02S to replace an NMOS 6502 without inserting TTL-compatible buffering.

But inserting a 74HCT245 buffer will make sure.

[daniMolina]

So, order from Mouser has just arrived and I've had a busy weekend! Bringing my first 6502 into life has been great, just a NOP free run but... anyway... it felt great

The clock generator works and I've been able to run the CPU from ~800Khz up to almost to 4Mhz, beyond that. my clock just becomes FUBAR. I'm blaming that on the poor construction. SMD parts soldered to a DIP breakout board, plugged into a 2 years old low-quality breadboard... Let's hope I can get better results on the PCB which, by the way, it's already ordered and on its way home.

[daniMolina]

Hi all.

Small update after a long time... but amongst plenty of other things, my little projects have been heavily hit by the coronavirus crisis.

Just a bit of context, for all of those who don't know, I live in Madrid, which has been very affected by the disease. Right now, it's the 43th day quarantined at home, and with my wife and I working from home, I had to dismantle my humble workbench. Also, the postal services have been giving only very limited support, and I'm still waiting for a few components to arrive... so pretty much everything has been on hold.

On the bright side of things, the general situation is improving here, the local hospitals aren't that saturated anymore, and, even though there's still a long way ahead, we can see the light at the end of the tunnel. We've also been lucky, as we're all OK. I may have had the disease... I spent like 10-12 days sick, which is very unusual for me, but even if it was the Covid, I never needed medical assistance and only some paracetamol was needed.

Back on topic, I've managed to find some small gaps in both space and time to continue working on this, thanks to some local suppliers, I've got (almost!) all the components I needed.

Right now, I have in place all of the following:

- Nano + 595 shift registers. It works as expected, when BE is pulled low, the 595 are enabled and I can drive the address bus, data bus and R/W from the arduino.
- Memory decoding (139+138). Working as expected, tested driving the address bus with the Nano
- Clock generator (74 + 14). Also working, I've seen a prety nice square wave up to 7 MHz or something. Beyond that, I'm not sure if is the signal, or my oscilloscope, but it becomes a nasty mess.
- Frequency Meter (7Segment leds, PIC). Beautiful, and working! I can go as low as 600 KHz, and up to 16MHz before it stops giving a stable value. This doesn't mean the clock signal is still good at that speed, but anyway, it's a nice achievement.

I needed a couple botch wires for the PIC, as I had mixed two of it's pins on the board... D'oh! And the power jack didn't fit below the arduino... so it's been moved out of the board. Not pretty, but still works

My next steps are,
- Adding the reset circuitry (The SBC can be reset with the reset push button, the Nano also has the ability to reset the SBC, and of course, during startup)
- And then adding the RAM and writing/reading it with the Nano.

Cheers!

[BigDumbDinosaur]

daniMolina wrote:

Just a bit of context, for all of those who don't know, I live in Madrid, which has been very affected by the disease.

It's good to know that you and your wife have weathered the COVID-19 storm.

BTW, you should add your location to your user profile so others know where you are located.

[BigEd]

(One may add a location, if one wishes, but please no-one should feel that it's necessary. It can help when discussing shipping and suppliers to give a hint about location.)

[daniMolina]

This has to be the most repeated advice on this forum... but anyway... here it goes again.

Don't work with real hardware if you're tired, ever!

In an awesome example of "Don't follow your own advice" I've managed to blow up three arduinos and a couple of IC's last night. Just by inserting the arduino with an offset of one pin... well... 12v flowing where 5v should be! Somehow I repeated it again, and then, the third arduino failed, as far as I can tell, out of nowhere (A Zener diode blew up, can't really spot my mistake there)

But today was a new day, I've managed to Frankenstein-up myself a working arduino out of the 3 failed ones, replaced the two burnt ICs (The clock generator... 74 and 14 went up in smoke) and now I'm back again where I was before this little accident.

Back on track, I've added the reset circuitry, and it works as expected
~250ms negative pulse on power up
A nice low pulse when the reset switch is pushed
And the Arduino can also trigger a reset when needed.

SRAM was the next on the line. Soldering the SOJ-32 has been very difficult, partially because I think the footprint I had wasn't 100% accurate. No matter how hard I tried, I couldn't completelly align the chip.

But, in the end, it's all in place. I've done a very quick Sketch for the Nano, and it seems I can read and write the memory.

Close up of the Reset circutry and SRAM. Yes, C4 solder is a mess... but remember..

Don't work with real hardware if you're tired, ever!

[daniMolina]

And finally, some signs on life

Last night I put the CPU in place, and, byte by byte (I´m also working on a small app to upload a whole image at once, of course ), uploaded this code to RAM

Code: Select all

 *=$FFE0
 	lda #$00			 // A9 00
 	sta $0300			// 8D 00 03
 	jmp $FFE5			// 4C E5 FF

 *=$FFFC "Reset Vector"
 .word $FFE0

And it kinda works...

Somehow the byte at FFE1 is being rewritten. Just that one, everything else stays the same, and value at $0300 is properly stored. As it seems to work, I'm thinking I'm causing some incorrect write to RAM when I ask the Arduino to take back the control of the bus. My sequence is as follows.

On power-up. BE is pulled Low, and the Nano takes control of the bus. Via the shift registers for the address buses, directly for R/W and the data bus.

Then, the Nano writes to the ram. As it's driving the address bus, all the addressing logic is in effect. I can write $0000-$7FFF and $C000-$FFFF. I could also write to the peripherals, but they're not in place yet.

When I´m done writing the RAM this happens:
1.- RESET the 6502 (And the 6522, as they share /RES)
2.- Release R/W from the Nano (Set it as INPUT)
3.- Release the Data Bus (Set all bits as INPUT)
4.- Pull BE HIGH. This also puts the shift registers into HIGH-Z mode, so the address bus is released too
5.- After a small delay, RESET is pulled high, and the 6502 starts running.

To halt execution and return control to the nano:
1.- Pull BE low. So the 6502 disconnects from the buses. At this point, the shift registers drive the bus again. Data and R/W are floating right now.
2.- Set R/W and Data as outputs in the NANO.

As the (very tiny) code I'm uploading seems to run fine, I think the spurious write is happening when the Nano takes control of the bus again. This was not something I planned, and won't be needing in the future when I had a proper output from the SBC (The LCD). I'll try some more complex code today, before pulling out the logic analyzer

By the way, I spotted one small flaw in the design. Again, I've been kinda lucky.

I didn't take into account the difference between 65C22N and 65C22S, regarding it's IRQ output. I was aware of it, but it didn't pop into my mind at design time. So both /IRQs from the 6522 and 6526 are connected to the CPU. But then I failed to put the pull-up resistor in the schematic!

Why have I been lucky? Well... I wanted the CIA and VIA interrupts to be independent, so CIA /IRQ is connected to CPU /IRQ, while VIA /IRQ is connected to /NMI. So no conflict between the open collector nature of the CIA, and the totem-pole /IRQ of the VIA (I have a 65C22S, again, lucky I guess... didn't even check it when I bought it!)

In the end, I just need to add a pullup resistor to the /IRQ line. It could've been much much worse.

Today... the 65C22 will be added... and that will be it for now. I don't have the '245 buffer yet, and who knows when I'll be able to get it

Cheers!

[Chromatix]

I think you may need better control of R/W during the bus handover. Are you able to turn on a weak pull-up on that line for the short interval that nobody's actively driving it?

Also, when pulling BE low you should also pull RDY low, to actually halt the CPU.

[daniMolina]

Chromatix wrote:

I think you may need better control of R/W during the bus handover. Are you able to turn on a weak pull-up on that line for the short interval that nobody's actively driving it?

Absolutely, I'm 95% sure this is the source of the problem. I can enable an internal 20k pullup on the Arduino itself. I'll try if that helps, but sounds about right

Chromatix wrote:

Also, when pulling BE low you should also pull RDY low, to actually halt the CPU.

In the current PCB, RDY is pulled high with a 3k3 resistor. I still have a couple of unused pins on the arduino, so I could probably do it. However, I have no plans on handing over the bus back to the arduino on normal operation, so maybe I can live without this for now.

Cheers!


Ninja edit. Exactly as you said, enabling a week pull-up on the RW line before pulling BE Low solved the problem. Final sequence is :

Handover from Arduino to 6502
1.- RESET is pulled down
2.- RW is released by Arduino, but configured with a weak pullup
3.- Data bus is released by Arduino
4.- BE is pulled high.
5.- Pull-up disabled in RW line
6.- Reset is released

Handover from 6502 to Arduino
1.- Pull-up enabled on RW
2.- BE pulled LOW
3.- Arduino takes control of RW and Data Bus

As RDY is not used at all (Always pulled-up), I'm not sure what happens to the CPU. My most logical guess is that it keeps trying to execute, but being disconnected from the bus, it only gets garbage and crashes and goes into an undetermined state. Graceful handover back to the 6502 is hence not possible at this point, requiring a RESET. Good enough for now

Thanks @Chromatix !

And BTW, 65C22 is also in place now ...

at seems to work at 18.5 Mhz! It may not hold up with more complex code, but it's a wonderful start.