My 6502 sbc is supposed to take advantage of the fact that there’s never going to be a shortage of pulled 6502’s and 7400 logic.

This means it has to support both NMOS 6502 and 65c02 - new and old. Especially considering that when the Chinese factories relabel the ic’s they don’t care if they mess up the speed rating or NMOS vs CMOS. But hey, 3 out of 4 of my “NMOS” 6502’s turned out not to be 65c02’s XD

However.. in my design the NMOS Ø2 seems loaded into a sawtooth even though it’s only driving a 6522 and the 74hc14 that’s buffering it - it’s basically 45 degrees out of phase.. when leaving the buffer.

Is this normal? I mean.. shouldn’t it be able to drive more than a 6522?
I “fixed” the issue with a 1k resistor(that I’ll try to increase) on Ø2 and rise times are now within spec for the rest of my system.. is this safe?

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Could you sketch what you have? I'm confused, because the point of a buffer is to isolate the driver from the load, so if you have buffered the clock output, it would be the buffered clock which then drives the 6522.

This is what I had in my previous revision - unbuffered ø2 everywhere. This worked fine but had other issues. https://github.com/AndersBNielsen/abn65 ... e/6502.pdf

This revision - yet to be published - the only thing running straight off ø2 is the 6522.. more of an oversight than intentionally not buffering.. A buffered ø2 couldn’t hurt it.
The reason I don’t just run everything off the 2mhz input clock is that bus sharing works best when using ø2.
Maybe my tolerances are just too low.

Either way - the only thing dragging down ø2 seems to be the 6522. Everything else is using the buffered clock or the buffered input clock.

Could this be what a lower speed rating looks like at 2mhz? It’s more of a wave shape than a sawtooth - rising in too slowly to around 4V and then falling fast.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

I've observed the same thing in the past, very slow rise time on phi2. My conclusion was that that's just the way it is. You could use a 74HCT14 instead of the HC part perhaps to get the lower high threshold, or concoct your own circuit to bias it like you've done with the resistor.

But.. is it safe to bias a clock like that? Technically that draws current from it when it’s low, right?

My only other solution seems to be to delay the input clock the same ~50ns as ø2 but it seems crazy to waste another IC just for that. What’s the best way to delay 50ns with the fewest gates?

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

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

Yeah. Sorry about the confusion - I attached the old revision to give an idea of what's involved and what I changed.


Using what people already have on hand is plenty of reason I promise I've read everything you've published about the benefits of using a 65c02. I don't have a problem with supporting WDC, but creating a demand for new IC's when NOS and used IC's are perfectly fine is such a waste in my book. The whole point of this project is using old parts - "reduce, reuse, recycle". When it comes to reliability, speed, power draw, of course a WDC65C02S is better, but it seems I get a lot of masochistic joy out of having the same battles the homebrewers of the late 70's did.. Authentic NMOS pain ..and there's the price.
If I was trying to make a new PC as powerful as possible I probably wouldn't use a 6502 to begin with - and for MCU uses the WDC65C02 can't really compete with modern MCU's anyway. Bang vs $ wise. Not that it doesn't have some niche applications - it's still a contender in the "fewest transistors pr useful instruction" game.

It's funny where people draw the "nostalgia line" about what modern components are allowed and which are not. I try to make this SBC as close "it could conceptually have been made in the late 70's" as possible - even though I cheat with 74HC parts and surplus/used late '90's RAMs and ROMS and I certainly don't hand draw the circuits and take them to the printer. So... For nostalgia reasons it better fits to use old NMOS 6502's - even though it makes a few things harder. If there were still 1-8k ROMS available cheaply I would use them.
I have eliminated two out of four 74hc245's in my new revision with some careful attention to bus contention with a JnotK flip-flop for video sync generation. If I knew I could rely on only 65c02's I could eliminate the last two '245's since the BE pin on the c02 also tristates the address bus - unlike the '02 which always drives it making bus sharing a pain. But - it's just more fun this way.

And just so I don't forget: I owe you a beer, Garth.. or ten more likely! Thank you so much for all the help on your website and this forum! Did you realise your potpourri SBC has the same memory map as suggested in the MCS6500 programming manual on p146?

Back to the slow Ø2:
I don't think it's a defective pullup since it's a problem with all three NMOS 6502's I have on hand - all identical on the scope.. I guess it could be a defective 6522 pulling it down since that's the common denominator or maybe it's a supply issue and the 100nF + 220uF bulk caps aren't enough?
The mislabeled 65c02 I have has a rock solid rail to rail Ø2.

The input clock is already feeding as many things it possibly can but for the bus sharing I can't get it to work reliably without using Ø2/Ø1 timings.
I see some modern dedicated delay lines available but price seems prohibitive ... what's a good alternative? A monostable of some sort? Around 50 ns a 555 probably won't cut it?

For now the external pullup on Ø2 certainly seems like the cheapest solution and I can't think of ways it will damage the old 02's for certain. I hope I'm not wrong?

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

If the timing matters a lot then my personal preference for this sort of thing is to use a faster crystal and divide it down - then it's easy to delay signals fairly precisely by multiple of the crystal's period.


It's likely less than 5mA (5V / 1000ohm).

I have verified this in my own projects. In fact, some of the chips in the 65XX family (notably the older 65C51) perform much better if the system clock is taken off pin 37.

_________________
Bill

Input frequency stability is not the issue (I have a rock solid 2 mhz input divided down from 16mhz) - delay between pin 37 ø0 and pin 39 ø2 is. Since the 6502 drives the databus according to ø2 I have about 50ns of bus contention on both ends if the video circuit drives the databus according to the input clock. Hence I need an effective and cheap way to delay ø0 to make a clone of ø2.

What Garth said about defective pullups got me thinking - my external pull-up in parallel with the internal one can’t be as bad as sourcing 5mA from an address line. If I imagine an NMOS gate correctly the only thing pulling ø2 up is the internal pullup so there’s not much extra strain on the gate. I guess..

In other news I decided to test without the 6522 altogether… no change. I guess that means it’s down to input voltage, decoupling, and the fact that it’s running at 2mhz and might be a 1 mhz part (which do run fine at 2mhz but who knows after 40 years).

And yes: Run things from the input clock whenever possible - not ø2 on pin 39.

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

That's what I meant - you can easily use your faster clock to create a delayed phi0 by increments of around 80ns (the period of the 16MHz clock). You can delay the rising edge but not the falling edge as well if you like... Simply having that higher frequency signal available gives you a lot of options.

Oh now I get it! I can’t imagine the circuit in my head right now but I think I get the idea. Thank you!

Edit: Also I’m subscribing to this guy George on YouTube who explains it quite well

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Hopefully accurately enough! It's a fairly simple technique but it's worked well for me in a variety of situations.

As I suspected your secret weapon was a D-flip flop Your video explains the technique very well but also illustrates (pun intended) the major benefit of “graphing” the signals you’re dealing with in detail.
When I was working out the timings for my VGA circuit I spent a lot of time looking at the datasheet and other people’s diagrams without actually plotting my own signals - foolishly thinking I could keep it organized in my head.. spoiler: I just ended up mushing wires into breadboards and putting what seemed to work on my schematic and here we are where a slow rise matters enough to break my video output XD

As Garth hinted, it’s better to fix the root problem, and most likely the short ø2 high time wouldn’t matter so much if WE was pulsed in the middle of ø2 like you did in your video. Link below .. and then I could use the other half of a 74hc74 to latch my video output 74hc165 more precisely and probably save the two nands I use to latch character ROM output.
( https://youtu.be/Plbbqcv_YQo )

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1