Build your own 6502 Microprocessor Kit | Hacker News Reader

Build your own 6502 Microprocessor Kit

kswichit.com

79 pointsingve26 comments

Interesting. I just got interested in going the 8-bit retrocomputer route, as I've always wanted to learn the low-level hardware stuff... down to the level of the CPU, the data bus, memory bus, I/O support chips, accessing RAM, keyboard interfacing, etc. So, to that end, I just decided to build a Z80 based microcomputer.

Somebody asked "why z80 and not 6502 (or 8085, etc.)" I guess the 6502 is a fine choice, but my subjective perception is that - out of the popular processors from that era - the z80 is the one that still has the most actual commercial applications, and is the one that is easiest to source, find up to date information on, etc. Maybe I'm wrong, but so far it seems going the z80 path is pretty accessible. I was able to source chips from Jameco with no problem (and they're pretty cheap), and the z80.info site has a ton of useful info on homebrew z80 machines[1].

I was also able to pickup a copy of the book "Build Your Own z80 Computer"[2] by Steve Ciarcia, which should help a little.

Anyway.. not to take anything away from the 6502. If it turns out that chips are available, I may take a stab at building one of those after I do this z80 thing. But for now, this feels like the "path of least resistance". But I'd love to hear about anyone else's experience building an 8-bit machine, regardless of which processor you chose.

[1]: http://www.z80.info/homebrew.htm

[2]: https://www.amazon.com/Build-Your-Own-Z80-Computer/dp/007010...

You can't go wrong with either. Both have good support and can be sourced. Do the z80 first then the 6502 and enjoy both. :)

Have you read a book called Code by Charles Petzold [0] by chance? It walks you through how a computer works from low level relays all the way up to building a processor and running an OS. He talks about both the Z80 and 6502, and peppers in a lot of the history along the way. The book has me really itching to play around with one of the two and it sound like the Z80 might be the way to go.

[0] https://www.amazon.com/gp/aw/d/0735611319/

I started it a few weeks ago, yeah. Definitely looking forward to churning through all of it.

To further confuse you: have a look at the 6809, it's a better processor than either the 6502 and the Z80 in many respects.

To further amaze you, look at the Intel i960 (esp manual in "external links"):

https://en.wikipedia.org/wiki/Intel_i960

It was intended to replace 286/386 and mainframes. I know: talk about shooting for the stars. Yet, manual shows it to be a brilliant design [vs i432 APX] that was basically an object-oriented, efficient RISC with error recovery, concurrency, and lock-step added. Just a few, small modifications to make this into a highly-secure, three-or-four-9's CPU. Might be Intel's best work in terms of engineering tradeoffs. Worth somebody imitating imho far as hobbyist clones or RISC-V projects go.

That's not on the same scale as those 8 bitters for a homebrew project. You'd need university scale resources to do a machine based on the i960.

Yeah, probably... Alright, sticking to MCU's, what do you think about the 1802 used in high-integrity space applications and COSMAC microcomputers?

https://en.wikipedia.org/wiki/RCA_1802

It's another old one from my collection. Links to two implementations by modern hobbyists showing it can be done. Not sure if the architecture is worth reviving for education, experimentation or high-reliability but it paid off then esp on SOI processes. Included a stand-by mode, too, despite being 1970's chip. Intersil also still sells them for government or commercial clients for legacy systems presumably.

The 6809 (direct page, anywhere in memory) and the 6502 (zero page) allowed quick addressing of 256 bytes using just an 8 bit address. This handily outperformed the 1802's 16 word register file because effectively that gave the other two a large number of registers (with about the same code density).

I do remember the 1802, there were some interesting hobby projects around it but I never built anything with it. The DMA controller looks interesting, I'm not aware of any other 8 bit CPU that had one.

The i960 looks pretty interesting, but it appears that they aren't manufactured anymore. Is there something roughly equivalent out there?

Otherwise, what is the state of the art in microprocessors for embedded systems and the like? Something like the Cortex M7?

"The i960 looks pretty interesting, but it appears that they aren't manufactured anymore. Is there something roughly equivalent out there?"

No. Closest thing in development with open code that I know about is Cambridge's CHERI processor that combines MIPS, capability-security, legacy compatibility, and FreeBSD. It's not exactly simple but it does some of things i960 intended.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

"what is the state of the art in microprocessors for embedded systems and the like?"

I only know stuff in that space that crosses into my research into high reliability, security, or subversion-resistance. Studying more MCU's for last one given gotta use old nodes. Found a few interesting things, though.

Plasma is a MIPS CPU & SOC in around 4,000 lines of HDL. Already has RTOS and stuff. PULPino is like a RISC-V version of Arduino with 32-bit core & lots of peripheral stuff. Some MCU's, no link on hand, are including I/O coprocessors that give some of benefits Channel I/O and server offloaders have. Another strategy is including HW accelerators for common, high-CPU (or I/O) functions. Outside C & serial, JOP is small, efficient CPU for Java code. Sandia's SSP is similar but highly-assured & rad-hard. AAMP7G is most reliable/secure in embedded with low-power, decent speed, triplicated circuits, mathematical verification, separation kernel, & easy ISA. I'm keeping an eye out for others that include things like DSP's or parallel architectures that aren't just toys. All I'm seeing so far that are being fabbed or used on FPGA's.

http://plasmacpu.no-ip.org:8080/cpu.htm

https://github.com/pulp-platform/pulpino

https://en.wikipedia.org/wiki/Channel_I/O

http://www.jopdesign.com/

https://www.researchgate.net/profile/Victor_Winter/publicati...

http://www.rockwellcollins.com/~/media/Files/Unsecure/Produc...

And it too had more recent version. NXP still has a variant on their web site.

http://www.nxp.com/products/microcontrollers-and-processors/...

(I think this is a variant too) http://www.nxp.com/products/microcontrollers-and-processors/...

If you're interested in a kickass z80 project, I recommend checking out KnightOS, a FOSS OS for z80 calculators

"the z80 is the one that still has the most actual commercial applications, and is the one that is easiest to source"

Wise that you considered this. Any IT work, even hobby projects, can have long-term consequences for the person or the work itself. I often advise people to consider what it might turn into down the road, not to worry per se, but to notice if any tiny choices or efforts now might lead to a payoff later. Hypothetical example, you choosing z80 for software might lead you to reverse engineering, imitating, or porting amazing code onto your very own z80. That experience might get you in embedded work, demoscene, or even improving compiler efficiency. Kind of a variant of network effects maybe except for learning opportunities rather than ecosystem take-up. Hmm, first I thought about it like that. Maybe worth more thought?

Regardless, good luck on your project. I'm sure you'll enjoy it. My own forays into hardware for high-assurance security... despite working at a high-level... have been beyond enlightening. More people play with hardware, higher odds an OSS revolution for HW will show up outside academic teams doing RISC-V, etc. Cheap, FGPA boards & software are already there to enable it. Just need motivated people.

I could be wrong, my gut feeling is that the 8051, by far, has more commercial applications today than any of the old processors. It is still being made in a million different incarnations and used in a million different embedded applications.

When your kit is ready you need software, and CP/M is here:

http://www.cpm.z80.de/

Very cool, thanks for sharing. I was wondering if I'd be able to find something like CP/M "out there", or if I'd have to write my own OS. Of course, writing an OS would be fun in it's own right, and I'd like to take a stab at that some day as well...

The 6502 and Z80 are both still popular in embedded applications, although I think the 6502 as a SoC core far exceeds the Z80 in volume. My monitors, mouse, webcam and keyboard all have a 6502 core in them, as does the NES, whereas the only devices I have that I know for sure contain a Z80 are an S1MP3[1], a Gameboy, and a TI-83.

Personally I prefer the Z80 too mainly because of its more powerful and organised instruction set[2], and the fact that it's the ancestor of the 8086, although the 6502 is definitely a simpler design (which is probably largely responsible for its popularity.)

[1] https://en.wikipedia.org/wiki/S1_MP3_player

[2] http://www.z80.info/decoding.htm

I uncovered a SYM-1 6502 microprocessor kit and power supply. I'll have to check to see if it still works. Back in the early 1980s I recall writing a few programs and storing them to cassette tape through one of the interfaces. And I think I upgraded the memory to 4K! It was quite a lot of fun.

With just looking at the title I thought this was now being offered in kit form:

http://monster6502.com/

Oh boy.

I used to use a similar thing in high school, the Z80 uProfessor, which is based on the Zilog Z80.

(edit: yep, I have used the same "Multitech MPF-1 Kit" board!!)

So many memories!!

I can tell stories about programming things like this.

It is not as easy as you might think.

Here is how we used to do it:

1. Draw a flow chart on paper

2. Translate the flow-chart to assembly source.

3. Keeping the processor data-sheet in your left hand, hand-translate assembly code into opcodes, by hand. Compute relative jumps by hand. Do not use a compiler. Be the compiler.

4. Now that you have your opcodes, get your board.

4.1 Set the starting address (it was 1800_h for me)

4.2 input opcode (two hex numbers, one byte)

4.1 increment address (the '+' key is for that)

4.3 if finished goto 5

4.4 goto 4.2

5. set address back to starting point (like 1800_h)

6. Run your code! (press 'go')

Now... 60% of the times, it fails every time. But I miss doing this kind of exercise :)

You left out...

Erase an eprom with ultraviolet

Drive for miles to a friends place to use his eprom programmer

drive back home, and plug it in

then swear a lot when it still doesn't work..

ah, the memories... (that was with a hand-wired board and an MM57109 before the first microprocessors were available)

My unit was already programmed... I guess I was lucky! :)

...and I was that 'friend' with the EPROM programmer board for the Commodore 64 and a UV eraser. My office (bedroom) was very busy at weekends.

That's the hardcore way. Brinch Hansen used to program constrained hardware in a high-level, type-safe language with hand-coded, equivalent assembly side-by-side. It was a debated approach then but claimed some benefits of both. Recent work uses dependent types, theorem provers, and so on to do low-level stuff with tooling catching assembly-level errors and/or synthesizing it directly from specs without compilers. Also stuff like ATS lang and Ocaml subsets being used on 8-bitters. So, days of hardcore methods like yours are over and unnecessary outside an existential experience reliving history. :)

Or certain subversion-resistant schemes. That's out of scope here, though.

Reply on news.ycombinator.com