In rev 2 of my 6502 build, I used PHI2 out as a clock source for my memory decoding and clock source for the VIA and ACIA instead of using the crystal oscillator directly, as in my previous build did. I immediately had all sorts of weird behaviors. All my wiring checked out.

It turns out that for some strange reason, IRQs would start executing. And no external IRQ was triggering them.

So I switched back to using the crystal can directly, instead of relying on PHI2 out.

Does anybody have any thoughts on this?

_________________
Fred Segard
A.K.A. The Micro Hobbyist
https://6502sbc.blogspot.com/

It's easy to speculate or simply guess wildly about what's happening, but we'll have much better feedback if you can link us to as much info as possible (schematic, photos, etc) re this rev 2 of your build!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

"Weird behavior" can often be traced back to a (C)MOS input that, for whatever reason, has been left floating rather than connected to something. Flaky connections deserve mention, too. But another popular cause of weird behavior is power supply problems, including bypass capacitor issues. In your case it's this theory that kinda gets my Spider Sense tingling.

Lots of folks were successful using the old style clocking scheme, so I don't feel it's likely your problem originates there. Instead (and no offense intended), I suspect you've built something that works, but only just barely. Due to some unnoticed issue -- power supply, or perhaps layout problems? -- the thing is always teetering on the brink of failure. Switching the clock source just happens to exert a tiny push in one direction or the other. But we'll see!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Well, it's definitely my bad for not fully reading the datasheets. That'll teach me. Everything is back to normal ever since I stopped using PHI2out.


No offense taken. I also changed my power supply, a MeanWell 5V 4A fixed output with 22AWG solid core wires going to my breadboard (compared to a somewhat flaky variable PSU using premade 26AWG jumpers). I already had decoupling capacitors for all the chips. But I added 10µF capacitors on each individual breadboard rails. Power readings (multimeter and scope) are very stable now.

For now, everything is rock solid. I haven't pushed my system beyond 2MHz yet. It is after all still in breadboard format. And when I reattach the TMS9918A, it's top speed is 2MHz anyway. But I'll have to read the datasheet when the time comes to see if I can push the VDP beyond this speed.

PS: I just received a pair of TMS9928A chips. I might put one of them instead othe 18A. Apparently (I saw this on YouTube), you can wire component video to a VGA monitor??? I'll have to test that theory.
https://www.youtube.com/watch?v=oE8g9OF8lyY

_________________
Fred Segard
A.K.A. The Micro Hobbyist
https://6502sbc.blogspot.com/

Well, I'll add my $0.02 as well... My older W65C02 setup uses the Phase 2 clock output for all timing to a W65C22 and W65C51 as well as the 74HC logic and the RAM/EEPROM read/write signals. I have clock speeds running from 4MHz to 10MHz without any issue on multiple boards. So if changing this on your system results in a stability problem, I'd agree with Jeff that something else is on the edge. But hey, you can't really argue with success... so if you've managed to get it sorted out, all good.

_________________
Regards, KM
https://github.com/floobydust

Yes, glad to hear you're having some success! But it doesn't seem as if we learned anything concrete (so far). Do you mind some followup questions?

Were they not stable prior to adding the 10 uF, the better PSU and the 22AWG wiring?

And, just to see what happens, how about temporarily switching back to the old-style clocking scheme using the CPU's Phase 2 clock output? Would that be an awkward experiment, or pretty easy?

-- Jeff

PS- still would like to see a photo!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Did the data sheet for the older parts support using PHI2O?

For what it's worth, I find using the clock as PHI2 is even advantageous with the older NMOS and CMOS designs. The effect of doing this has resulted in higher over clocking speeds, but more importantly, older 65C51s rated at 2MHz will run reliably at much higher frequencies. I have even used older 65C51s with new W65C02s at speeds above 19MHz. I do plan to do more study on this ... but it will have to wait until winter set's in. More time on the weekends then. Actually, I'd love to have someone lese collaborate on the results as the older 65C51s are plentiful, cheap and don't have the TX bug.

_________________
Bill

Hi Bill,

I do recall some earlier posts (from you) that noted very high clock rates with older 65(c)51 chips. I have a collection of original NMOS 6551 (Rockwell and Syntertek) and some older Rockwell R65C51P4 chips along with some new WDC chips (with the TX bug) and some other that Bill Mensch sent some years ago (various unreleased chips, but sans the TX bug).

As for the older NMOS parts, I managed 6MHz reliably with the Syntertek part, but no more. The Rockwell CMOS (4MHz rated) chips will typically survive 5MHz but no more. I wouldn't expect switching from the clock output on the CPU to the same clock driving the CPU to make a significant difference.

I guess my question for you is: Are you running the 65C51 chips with interrupt-driven I/O or polled I/O? I think that could make a difference in chip response times... but I'm sorta guessing

I think most of us (from the 70's & 80's) just used the phase 2 clock out from the CPU as that's what Commodore did on their machines... seemed like it was intended for that, but I'll have to dig out some older datasheets to see what they show.

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Polled I/O. I've actually never tried interrupt-driven serial I/O on a 6502.

I've also never tried drastically over-clocking a NMOS 6551. Might add that into my experiments (if I can find one in my stash).

_________________
Bill

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I also run interrupt-driven exclusively... very nice this way. If you want to try it with a 6551, you can easily try my Micromon code... you need at least a couple KB of RAM at the bottom, a couple KB of ROM at the top and define your base I/O address for the 6551... that's it.

https://github.com/floobydust/Micromon-V1.2

_________________
Regards, KM
https://github.com/floobydust

The reason I have not tried interrupts on serial is because I usually have other uses for my interrupt inputs, which brings us to another point. Does anyone have a hardware/software method to arbitrate interrupts from many devices? A lot of times 2 inputs seems likea huge drawback.

I've been intending to try your monitor Flooby. There just always seems to be other stuff .. my project list is deep and I have to keep re-juggling my priorities.

_________________
Bill

Well, there are some out here that have designed some hardware to handle multiple hardware interrupts... however, I've used software to manage multiple interrupts. Even my Micromon is extendable for this, but I would likely suggest using my current 3.04 BIOS, which supports a NXP SCC2691 UART (for Rxd, Txd, Timer and Break) and extends the interrupt handler for the CF Card as well.

Granted, there is some clock cycle overhead this way, but it's still pretty minimal, especially with a faster CPU clock. You can also change the priority of IRQ handlers by swapping the vectors around... I've tried to keep it simple.

Quick link to the latest BIOS is here:

https://github.com/floobydust/CF-Card-R ... d/Software

_________________
Regards, KM
https://github.com/floobydust