Well, things never really go according to plan.

I had in mind to make this thread a step-by-step chronicle of building my first kit computer, an RC6502. I figured I would name the computer "Blue April," since... it's April, I was born in April, and I grew up in the '80s, when exciting computers with "Blue" in their names featured prominently in magazine ads that I gazed at.

The plan was to start with the simplest board (the backplane) and work my way up to the most complicated, meticulously testing as I went. Since I hadn't soldered anything since high-school (and that was stained-glass windows, not electronics), I figured I shouldn't get anywhere near anything more expensive than a resister with a soldering iron until after I had some practice.

All the PCBs I ordered came right away - *except* the backplane! It *still* never showed up (it fell into the black hole that is the USPS Atlanta Peachtree NW Distribution Center) and I ended up ordering a bunch of them from PCBWAY. Meanwhile I practiced soldering on the other boards, but with no backplane to power and connect them to each other I didn't really have a good way to test them.

Anyway, here are some photos of the project, my little workspace, and a couple shots of my home-made EPROM de-programmer, just for fun:









As far as I can tell with my little multimeter, everything is working out OK. The voltage regulator on the backplane seems to be working, the clock module is producing a steady 8Hmz. However, I have encountered a puzzlement. Here is my testing setup:



That's an Arduino running Ben Eater's 6502 bus monitor; on the left of the top (larger) breadboard is a single-step circuit; on the right is the reset button. The main event is the RC6502 SBC plugged into the RC6502 backplane. The SBC has RAM, ROM, and PIA disabled via jumpers; I didn't populate the clock (I'm using the single step circuit) and Arduino parts of the board. Even though there's an Arduino in this photo, I'm not really very interested in them, and I don't want to farm out all the most interesting parts of my computer (I.e., I/O) to a tiny but vastly more complex micro-controller. In the foreground is the RC6502 Project Board, which is not connected to anything; I'm just using its mini-breadboard to put out NOPS on the data bus.

Everything in that picture works as expected; the processor (a W65C02S6TPG-14 I ordered from Jameco) jumps to the end of its address space, jumps to $eaea, and starts reading and executing nops off of the data bus and counting through memory.

If I pull the SBC from the backplane and plug in this CPU module instead (using selfsame CPU):



The address lines fill with gibberish. The CPU board is such a simple one that I can't understand what I might have done to it that made it not work.

The schematic for the CPU module is here:

https://github.com/tebl/RC6502-Apple-1- ... %20CPU.pdf

And the schematic for the SBC is here:

https://github.com/tebl/RC6502-Apple-1- ... %20SBC.pdf

The only differences I spot concerning the CPU are that in the SBC pin 3 (PHIOut) is sent to the bus and pin 36 (BE) is pulled high through a resistor, whereas the CPU module leaves both of them unconnected. I can't see how PHIOut would have anything to do with what I'm seeing; the data-sheet from WDC is somewhat laconic about the BE pin. Does "high impedance status" mean that the CPU is totally cut off from the address / data lines unless BE is pulled high?

I've done what testing I could think of with my multimeter, in terms of continuity testing all the pins on the connector against their corresponding pins on the CPU socket; the resistors are resisting. I'm stumped! I don't have an oscilloscope; short of getting one, is there any other troubleshooting I could try? Should I just try re-making the CPU module? My soldering has improved since then (it was one of the first ones I did), and I also refurbished my soldering iron with better temperature control (it was running WAAAAY too hot).

(Also, all of the photos I included seem to be sideways... I don't spot a way to rotate them inline, but if you click through to the larger version, my orientation descriptions make more sense! )

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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

Well shi..gee that sucks. After I posted last night I continued searching and found this thread: viewtopic.php?f=4&t=6153 (Apparently, searching for "WD65C02 BE PIN" will provide bupkis, but "W65C02" all by itself will get you just what you're looking for... go figure.)

It appears that although the schematic lists U1 as W65C02, and the *actual silkscreen* on the PCB labels it as W65C02, and even though there's a jumper for VP ground (!), a W65C02 will not actually work on the CPU module, due to BE left unconnected. That's frustrating!



Ah, good tip; I'll keep that in mind.

Thanks!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

That did the trick! Woop woop!

Thank you!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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

The RC6502 was originally designed as an Apple 1 Replica, following Tom Owad's book "Apple 1 Replica Creation, Back to the garage." My guess is that it has slowly been modernized piecemeal as hobbyist interest has grown. (Some of the older boards still list 74LS series logic in their BOM, for example.) I think the other pins you mention are managed adequately, although pin 5 is NC rather than jumpered. I guess one might say it is "second-best practice."

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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

All working now? That's great! Thanks for sharing your design and your story.

(For the photos: it should be enough to do a trivial edit on your computer just before you attach: a series of 90 degree rotations is suitably lossless.)

Hi Ed,

Yes, it's working! I made some progress this week; it has an RC Project Platform board hooked up to it now, with an LCD so it can actually do output. I'm planning to write a RAM test program for it over the weekend; I'll post some more photos when that's done. (I'll be sure to spin them around a few times first! )

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Blue April is up and running just fine (as far as I can tell, anyway) at 8Mhz.



Here's a side view so you can see her boards:



I did work on a RAM testing program - I found an algorithm in an old research report called "Random Access Memory Testing: Theory and practice The Gains of Fault Modelling by P.K. Veenstra" from Eindhoven University of Technology Netherlands that seems interesting and is conceptually simple - but it isn't finished yet because I got tangled up with addressing modes. All the indirect indexed modes I want to use only work in the Zero Page, which I didn't realize until just a while ago. Always read the fine print!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

You should still be able to use them. It's only the pointer that has to go in page zero. The location it points to can be anywhere.



This sets up a pointer to location $1230 in the zero page locations 'zp' and 'zp+1'. The final LDA reads this pointer, adds Y to it (in this case Y is 4, giving $1234), then reads from that location. By changing the contents of zp and zp+1, you can access any location in memory.

It's common to either store 0 in the low byte of the pointer and use Y for the 'real' low byte, or to put the low byte of the target address in the pointer and make sure Y is zero.

Yarr. I was trying to keep the pointers in ROM and skip a step (since it's a RAM test, you should really use ZP until after it's tested...

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

RAM test is now working! No new picture, because it looks just like the last one, except the LCD now says "RAM OK"

Turns out that my RAM test has actually been working for a while and doing what it was supposed to do: detecting hardware problems! Of course, my assumption (for a long time!) was that my hardware is a "known good configuration" and that my programming logic was at fault. But actually, the WDC processor I had in there won't pass the RAM test even at 250Khz. I swapped it out for a CMD one, and it works fine at 4Mhz. I'm guessing that this is a clock / timing related issue; I read in the Primer that the WDC chips are fussy about clock signals, and the RC6502 clock signal comes in over the bus.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Oh, that's a result!

That's worth looking into. Meanwhile, here's an alternative theory. It may be that the problem has to do with what's going out of the WDC, not what's coming in. Compared with vintage NMOS and CMOS 65xx processors, modern WDC chips have substantially faster rise and fall times on their outputs. This can result in ringing and other AC performance issues, even at low clock speeds.

-- Jeff

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