Thanks! I think that might help...

Here is the registers card. It's missing some ICs that are still on the way, but otherwise its complete. Wiring is fiddly, but it can be done, and not having to flip the board over helps a great deal. Power and LEDs are wired on the underside though. Debugging is going to be a nightmare...
Juan

Some updates:
A couple orders arrived, so now I have (or so I think) all ICs I need. I finished populating the registers card and made a little test card that plugs into the control ROM sockets. This lets me manipulate control signals to try out various functionality. Also added a couple RS latches that serve as a de-bounced clock.
After some testing and probing a couple of signals with the 'scope, I can say this card works as designed.

The ALU card is also done. This is the most complicated one, quite a lot of wiring in a pretty tight space. I ended up using a colour code for the flags instead of the data bus, as their routing was more complex. Luckily enough, I made no mistakes on the wiring (I buzzed out every single connection) and after some preliminary testing seems to be doing the business.

Also found out that the EEPROMS I purchased from eBay were used (no surprise here though), they didn't even bother erasing them. And what's worse, two out of the ten I bought were faulty, so I've got to buy some more. Given what I paid, not a bad deal anyway.

Next on the list: Interface card
Juan

More updates:

Interface card wired up and tested. I've completed all cards and programmed the control ROMs.
Also made a backplane to connect all cards together.
While it did put up a fight, I finally got it working to the extent that I can test without RAM and ROM. I've tried the reset sequence and instructions with implied operands like NOP, ROR, ROL, INX, DEX and such and so far all of them work. Program counter seems to keep counting properly up to a Mhz or so. I'll make some proper measurement to determine maximum clock speed.

Problems I faced:
-Control ROMS on wrong sockets...
-A couple intermittent solder joints.
-Forgetting about settling time of ROM outputs (luckily nothing a latch couldn't solve).

I got some more EEPROMS on the mail today, so I will start building a memory card so I can test it further. We'll see if I can run the Klaus test on it.
Juan

Looks great, Juan! And impressively rapid progress, IMO. Best of luck with the work to come!

-- Jeff

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

Thanks! To be fair, holidays between semesters help a great deal towards making progress .
While a frame to keep the cards straight gets printed, I have now to decide on the memory map and such. I think I'm going with:

$0000-$7FFF RAM
$8000-$BFFF To be determined
$C000-$FFFF ROM

I think I'll try to keep some similarity with the VIC-20 on this respect.
As a display, I'm going to use a 40x4 LCD, but one step at a time.
Juan

I've made an initial schematic for the memory card, which also carries clock and reset.
I'm using a 555 timer for slow (7-1000 hz) clock, and to single cycle, and an oscillator can as a fast clock.
Reset circuit and address decoding are from Garth's 6502 primer.

Memory and future peripherals will go on a separate bay so to speak, and I'm bringing all 40 pins from the CPU using an IDE ribbon cable into the first card and then into the backplane. I'm not planning to ever go beyond 1 Mhz and I can even divide it down to 500 KHz if the need arises. So I think it should be ok.
Juan

So the fun begins...

I have made the memory card, and it seems to read from ROM fine. But I'm experiencing some glitches that I'm unable to fix.
In particular, a 74HC377 octal flip flop sometimes changing state just after a falling edge of the clock. Attached is a scope screenshot (I know my probing could be better). Shown are: Enable (yellow), Clock (light blue), and one of the outputs (dark blue).

Enable is coming straight from a ROM and thus the pulse when the ROM's address changes after the falling edge of the clock.
I checked solder joints and sockets, tested the IC on my EEPROM programmer, tried a different IC, but no luck.
It may be due to power distribution (using quite long leads from the power supply at the moment), so I added 100 uF electrolytics to each of the cards, but the glitch still occurs.
Any ideas?
Juan

To me, the clock signal doesn't look clean, there is some ringing.
That spike in the signal ca. 150ns after the falling edge might be big enough to trigger the 74HC377 as a 'rising edge' event.
74HC377 input pins would interpret more than ca. 2.5V as a logic HIGH when the 74HC377 is running with a 5V supply.

Maybe the GND distribution in the design isn't too good...
//But of course: what you see on the screen also depends on how\where you had connected the GND clip of the 'scope to your PCB's GND.

To get rid of that spike at the 74HC377 clock input:

0) Check what happens, when soldering a 47pF ceramic capacitor or such between the 74HC377 clock input and GND.

1) If this fixes the problem for this particular 74HC377, remove that capacitor and try inserting a 470 Ohm resistor or such close to the 74HC377 into the CLK signal.
//So the resistor plus the 74HC377 input pin capacitance would form a low pass filter.

2) If inserting that resistor works for this particular 74HC377, inserting resistors into the CLK signal close to all of the 74HC377 chips might be an option.

Thanks for the tips.

The capacitor seems to have little effect, but inserting a resistor in the clock line makes the glitch less frequent.
I'm connecting the ground lead to the GND pin of the IC in question.

I am inclined to think that noise from the ROM outputs (the enable) while they stabilize provokes noise on the clock. Clock sometimes looks pretty clean, but has more ringing when ROM outputs change, so maybe I can try low pass filtering control signals.

I don't think ground distribution is good enough. Ground and power are routed on the underside using wire wrapping wire (see photos some posts above). Maybe I should re-do it with thicker wire.
Juan

Ground distribution is worth reviewing, especially in regard to a project that's acting "funny." But is this (below) the photo you're referring to? The red and black wires don't look like wire-wrap wires, but the colors suggest they are for power and ground.

Recently, ground distribution was discussed in this thread -- it's worth reading. If your black wires are the ground wires then I recommend you add more north-south connections (and also several more paths to the edge connector).

The location and interconnectedness of the ground wires is a lot more important than their thickness.

-- Jeff

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

_________________
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 555's output has a relatively slow transition time between logic states. It may be slow enough to violate the ns/volt rating of some of your silicon, with undefined results.


Indeed. I'm suspecting there is a fair amount of ground bounce going on, which might explain some of the erratic waveforms being seen.

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

I'm avidly following all the ground return information in the various threads here. This looks like a particularly interesting example due to the build technique, with (more or less) the power/ground wired on one side and everything else on the other.

So in such a situation, and with such a grid-like layout of ICs, it would make sense to wire together all the ground pins of all the ICs in a horizontal row (as he does), and also wire together all of the ground pins of all the ICs in each vertical column, too, right? In other words, every IC's ground pin gets wired directly to the the ground pin of the four ICs adjacent to it, side to side and above and below?

And then wouldn't you want to do the same for Vcc as well, because when an IC is pulling a signal low it's sinking current that must return to the source via the Vcc lines? Or am I confused about that somehow?

_________________
Curt J. Sampson - github.com/0cjs

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