There's no need to match them. The bypassing problems is not generally one of too few µF, but rather of inductance in the power and ground connections and in their bypass capacitors. Even .01µF capacitors will do more good than 47µF if you put them all the way down to the board with virtually no exposed lead length, since leads add inductance. Page 9 of the 6502 primer deals with this kind of thing, at http://wilsonminesco.com/6502primer/construction.html . There are lots of helpful links there too.

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

Further to what Garth said, "power dips" are avoidable if the Vcc and Gnd buses are substantial relative to the maximum expected current flow, and you use a well-regulated power source.

Be liberal with your bypass capacitors and keep in mind that what you are bypassing is high frequency stuff, which implies that construction methods are important. A good MLCC at each device, with the leads as short as possible, as advocated by Garth (n.b.: I use 0.1 µF, 50 volt X7R MLCCs in my POC units), will do more for you than a bunch of electrolytics.

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

As my habitual counterpoint, I'll quote from one of my earlier posts:

and

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

Alright, so here is the progress I made today: First, I swapped the 65C02 with one that I tested on a breadboard setup, and have in-fact run BASIC on just to rule out a bad processor. Admittedly I hadn't tested the other one yet, but it was brand new so... didn't think to. It will get the breadboard treatment soon enough.

I built a little diagnostic board to interface with the data bus and avoid all of my complex front panel circuitry for the moment. I put a little socket on there for an LED bar for another test I want to perform. For the NOP test, it was not in place, and those three signal lines were tied to ground.
The stains on there are from my first attempt at making a serial board. No reason to let good protoboard go to waste.

This is pretty cool to see. I turned down the sampling rate to see more of the address bus transitions. It's fun seeing 0xFFFF come and go.

I performed the test with the CPU card sitting where you see it pictured, and again and the other end of the backplane, just to verify the results matched. Sure enough, both locations produce the same results during the NOP test.

Edit: yes, my serial card is connected up during this test. Long story short, I'm leeching the 1.2MHz clock off of that card. Hopefully that isn't ruining everything. But that's a problem to tackle another time.

_________________
The Cactus

A good result! I hope you agree that this is not too trivial a test... it is but a starting point.

Of course. As Ralph Wiggum once said, "I'm learnding."

Making that little diagnostic card gave me an idea on another way to perform an integration test between the EPROM and address control cards. I'm also looking at the best way to revise the address control card to include buffers for the LEDs. This diagnostic card might become a bit of a permanent resident, doing that job. Right now, the address LED ribbon cables extend the entire bus about a foot, after going through the LED's 1K resistors. Time for buffers, for sure.


I'm starting to see the merits of front panel switches, LEDs, and control logic all co-existing on one circuit board, rather than my piecemeal approach with ribbon cable tendrils.

_________________
The Cactus

This is an awesome project.

BTW, I love the little cactus drawing on the ROM chip. Nice touch.

_________________
Cat; the other white meat.

I've been making a few improvements.

First off, I decided to throw some 1K terminating resistors on the data and address buses. It got rid of plenty of phantom signals, so I don't know why I didn't try this sooner.


I've updated the debug card to now let me directly control the data and address buses. The address bus LED signals are going through 74245's to avoid having to zigzag back and forth like with '244's.


While I was at it, I overhauled the Address Control card. Replaced the '244's with '245's to make the wiring easier for my eyes to follow. I also touched up the 5V traces to make sure the chips were all getting power. Tests show that this card is working better than ever! At least something I built works.


Let's see, what else have I been doing...

I'm running a few EPROM reads and RAM writes using the front panel logic. Since the status control card isn't present to actually perform tasks like telling the address control card to load the front panel switch value, or deposit a value into RAM, I'm having to manually signal those inputs high or low. I get to be the orchestrator. During such tests, I can successfully read and write values from RAM. The individual clear signals don't seem to work incredibly well, but the individual set signals seem to be just fine. I'll have to check over that card next to see what the heck I'm doing wrong.

I burned an EPROM with zeros for the reset vector, and tried entering a program into RAM by hand to see if I could get something to run. Nothing too fancy, but something I know works fine on an OSI-300.
The rest of RAM was filled with garbage. The majority of ROM was filled with 0xFF's. I tried letting the CPU run, performing a reset first. I watched the lights to see what was going on, only to see that the CPU was jumping around all over the place, probably running on errant instructions in RAM. A few of my values got clobbered...

So, that leads me to believe that my reset circuitry is perchance causing issues, or I'm misunderstanding how that's supposed to work. I'm using a DS1223 to perform the reset automatically on power-up, but I can also pull the line low and let it pulse low, then high. I get the feeling the machine didn't correctly check the reset vector, but I will look into this next. I also intend to burn another EPROM with some simple routine to see if it can handle that -- not sure what yet.

After that for fun, I hooked up a pulse generator to the clock input, because I can use that to adjust the pulse speed to be relatively low.
https://youtu.be/0onkPg9NOp8

_________________
The Cactus

I'm making progress over here, fixing design and construction flaws.

I've got the Memory Protect toggle working now, along with the R/W line indicator (which is mainly useful while depositing bytes into RAM). I've also replaced a handful of the 7400 series chips with the most modern variants I have on hand.

Seems I had original SN7474's in the data control card, which were experiencing "phantom all-clears" as I call them. Whenever I would press the clear switch for any of the 8 bits on the front panel, 90% of the time, more than one if not all 8 bits would clear themselves from the front panel flip-flops. That kinda defeats the whole purpose of having individual clear switches. Turns out newer chips don't seem to have this problem, which is nice.

As well, my 27128 was jumpered incorrectly, due to a holdover from when I was using a 27256. The result was that I could read from the EPROM maybe... 10% of the time, and would get a garbage result another 10% of the time. The remaining 80% was no response. With that pin held low, I shouldn't have been able to get any reads at all, but that seems to be cleared up now.

After trying a handful of short programs, either entered into RAM, or read back from an EPROM, I'm still getting no evidence of computation occurring. I have come to the conclusion that due to how long the bus traces are, I should add in some 74245 bus transceivers to help the 65C02 drive all the devices it needs to. I thought I wouldn't need them because of the helpful Bus Enable pin, but I'm going to play it safe and revise my processor card either way.

During some of my tests of the single stepping circuitry, I'm noticing voltages feeding the Ready line that I find concerning. They aren't 0 or 5, so I know I have some work to do there. I had just overhauled the card's logic too, to pull the Bus Enable Pin high on either single step or normal clocked operation. For the moment for clocked operation, I'm bypassing this circuitry to pull Ready and Bus Enable high.

I've had alot of trouble getting my logic analyzer to work, and it seems to be causing more interference than helping things right now, which is frustrating. Not to mention, it hasn't been correctly responding to capture-on-trigger events, so I can see what's happening on a reset or anything like that.

I filmed a demonstration of my front panel logic, if you're interested in watching me ramble for a bit, during a moment when things seem to actually be working: https://www.youtube.com/watch?v=3Sv3pIyMBEk

_________________
The Cactus

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

The majority of my stockpile of 7400 series chips are from grab bags, so they're older generation components overall (original, S, LS, F, etc). I ordered a handful of HCT's a few days ago to supplement what I'm already using. I'm going to standardize on HCT parts.

I will hold off on adding the '245s to the CPU card.

I'm amazed at how much of the front panel logic for memory manipulation is actually working. It's still all for naught if the processor can't do its thing.

_________________
The Cactus

The first shipment of HCT series parts arrived today, and I swapped out everything that could be replaced. I also discussed the symptoms the Cactus was exhibiting with a friend of mine who sorta follows the project. It came to light that I had some contention on the R/W line from the data control card, preventing the 65C02 from writing to RAM.

So I made a few signal line tweaks, and put the R/W line on a tri-state buffer that would be high-Z while the processor was running and...

I've now run a few simple hand-toggled programs from the front panel.

This is how bad the R/W line was looking after the first set of tweaks. The upper waveform is the R/W output on the 65C02, and the lower waveform is the /WE line on the RAM.

The signal has since been cleaned up due to the subsequent tweaks and modifications. Time to see what else I can get working!

_________________
The Cactus

Great progress!

It gets better!

It took a bit of finagling, but I was able to get the serial card to play nice at TTL levels. The RAM calculation method seems to only detect the first 16K automatically, and you end up in a loop if you let BASIC figure out how much RAM it has on its own. If you tell it 32K is available (yes, I know that's not precisely 32K), then its will let you start entering programs just fine. I tested a few simple BASIC programs, but I know I have some adjustments to make to get RS232 level conversion working.


Would you look at that. Serial & blinkenlights.

_________________
The Cactus