Hey guys,

On another topic, the question of budgeting for a SBC came up. I mentioned that I had recently built a simple 6502 board for under $100. Ed suggested posting the bill of materials for it here as a starting point for someone considering doing the same.

This is not the exact configuration I built, but very close. Reason being is that I used some parts from my junk box. However, I have added in replacements for those items and computed their cost. Part numbers and prices are from Jameco, though other vendors likely have all of this too.

You'll notice very little in the way of I/O. I do it all through the serial port which is hooked up to my computer using a 5V USB->serial adapter.

NOTE: After uploading I realized a few more things I left off - 74HC11, 74HC00, and 74HC138 (though I did include their sockets). Should only add a couple of extra bucks.

Thanks,
-JP

Adding the schematic and picture as well. These are "as built", so there are differences between it and the BOM. I used a 2764, NMOS 6522 and 6551s, and 74LS logic since that's what I had in my junk box.

I should have used A8-A10 on the 74LS138 rather than A9-A11. It was a design error that I then dutifully wired into the circuit

Coupla points regarding the schematic, Justin... minor stuff, really, but FWIW....

• the reset circuit can be simplified. Just tie pins 2 & 3 of the 'hc14 together; the resistor/cap network is unnecessary.
• as a general rule, no device should drive the data bus except when phase2 is high. To conform, your ROM needs to have inverted phase2 applied to the /OE pin.

The latter point is one that can be compromised, but it's not good practice. Ideally phase2-low should be a neutral time. IOW it should act as a buffer period that occurs after one device stops driving the bus and before the following device starts to do so. Providing a delay between those two events is important as a means of preventing bus contention.

cheers,
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?

Workable, but not the best practice. Consider two consecutive cycles, the first being a read of the VIA, say, and the second being a read of the ROM. The hand-off from the VIA driving the bus to the ROM driving the bus is poorly controlled -- the ROM will get enabled almost immediately after the VIA gets disabled. The "almost" arises from stuff like the address-hold time of the CPU and the prop delay of the decoder. I don't doubt your approach can be successful in some circumstances. But I'd rather see fully 50% of the cycle devoted to the hand-off.

OK, you've got me there -- but was this issue ever verified? IIRC there was a discussion based on one person's unconfirmed report. Seems to me the whole thing might've been a misunderstanding. If there's concrete info I'd be glad to have a reference.

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

I'd have to agree with Jeff on this. Back when I used to fool around with attaching hardware to my C-128 I quickly learned the importance of gating any data bus accesses with Ø2. In one case, I built a TIA-232 interface that plugged into the cartridge port and couldn't get it to work. Troubleshooting eventually led me to qualify R/W on the interface with Ø2 and the problem was solved.

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

Yes, that's exactly what I was implying. To have the hand-off occur almost immediately is better than having it occur immediately.

I'll see if I can hunt up that discussion about chip heating!

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

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

Justin, the FT232 is the SparkFun Breakout board? And (squinting at the picture) it has that 5V solder jumper? After going through all the options with MAX232/233 and what not, I'm considering just cheating with one of those. Any problems with it?

http://shop.myavr.com/Programmer%20and% ... tID=200024

It has RXD / TXD, CTS / RTS & 5V.
It works on my C64 250425, my breadboard 6502 and of course AVR.
And the price is nice

_________________
Marco

The 6526 CIA that replaced the 6522 in the C-64 and C-128 didn't require that R/W be valid prior to the rise of Ø2. I know that because one of my plug-in gadgets had a 6526 on it, in which I qualified R/W with Ø2. The TIA-232 interface that I had built before, which is where the R/W issue first appeared, had an MC6850 on it and I naively assumed that qualifying R/W with Ø2 was de rigueur in all situations. Fortunately, it worked out in the case of the 6526.

BTW, it looks as though you built that C-64 interface on one of those handy Jameco expansion port perf boards. Used more than a few of those over the years.

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

Good eye. Yes, it is the FT232RL board. I mounted it on the SBC for mechanical security. I added wire wrap pins and connected txd, rxd, and gnd. I wasn't sure the polarity of the rts,cts, etc. was compatible with the 6551, but in re-reading the datasheets it should be assuming Sparkfun didn't change the defaults.

Only problem I've noticed is that if I power off the sbc for an extended period of time I have to unplug and replug the usb cable. Could be related to the sleep mode pins.



indeed. Originally I was going to use an NMOS but later changed my mind. The primer is extremely useful - thanks for doing it!