The short, short version: I got interested in fantasy consoles, learned that most of them were just some sort of Lua-based virtual machine with permanent & arbitrary limits, got mad, decided to do it myself, asked an AI to plot a course in digital logic and CPU design.

..which is how I ended up deciding to go with a 1971-ish 6-bit microprocessor. It's a lot harder to go the easy route and crib from an existing design when there simply aren't any. That said, the design is semi-unintentionally similar to a stripped down 6502, by which I mean it was unintentional at first then I leaned more into it after it was pointed out.

The overview of the α600 (PART#ZMA600) is pretty simple: accumulator, XY index register-pair (X high, Y low), 6-bit data bus, 12-bit wide address space, von Neumann memory model.

In the end, it was encoding the instructions that got me. Initially I chased after that "MOS elegance", but something that worked fine in my novitiate mind would quickly fall apart once I began running out of opcode space. Here's what I ended up with (attached txt).

Please, please do comment & suggest. According to the clanker, the design works out, but I'm skeptical.

Tomorrow, I'll start hand-assembling simple programs on paper. Should be fun.

In case you'd rather read from the comfort of your forum:
(danger, really long)



Oh, but I just remembered pastebin is a thing that exists: https://pastebin.com/Jxd3hMQu

Thanks - interestingly minimal, and satisfyingly familiar to someone who knows the 6502.

I think a good next step is to write a bit of software, because that's where you discover how convenient things are. More importantly, how inconvenient or even impossible. (Not that I forsee anything impossible.)

I might suggest a BIT opcode, but the test of that is (perhaps) to write something which polls and responds to a peripheral, and see how that code looks.

It might be interesting to see what kind of routine you could write to handle a BRK - for example how a machine monitor might be able to recover and display the processor state. Maybe it can't, and maybe that's fine.

I find it interesting that you've chosen not to update the flags on operations which change XY. Maybe that makes sense, as the pair is a full address, so it's never a counter. I might wonder if the flags could respond to Y's sign and zero status, which might allow for aligned block operations. But that's just a thought.

Writing something which outputs a string from memory might be interesting. A data-terminated transfer should be easy. But a counted transfer might be a little tricky.

I'm not clear on why the three interrupt vectors are expected to be read at power on - the two words of the reset vector, of course. But not the others.

For a more flexible memory map, I might suggest that all the vectors could be at low memory.

No problem! I apologize for the giant wall of text, though; if it's too much I or a mod can delete it.

As I said originally, the similarity to the 6502 was originally coincidental (accumulator and index block, getting rid of simple ADD/SUB to save space), and even later certain decisions I had made to try and purposefully deviate from their model (ADC/SBC were initially ADC/SBB) were reversed when I realized that I had designed the adder to naturally follow their conventions. At that point, I gave in. I could have had worse models, I suppose; I hear the 6502 did alright.


Agreed. The plan for this week is to make the AI write a state tracker (probably in Python; the clanker loves Python) whilst I do the same on paper, and if we agree, I'll proceed to try and break things. It's as close to proper programming as I can get without an assembler and emulator (I think? It certainly should be simpler to handle?).


In one of the early drafts, I did have BIT, but I dropped it as cramming everything into a six-bit word was very difficult, especially for a first attempt. Considering that a 6-bit microprocessor in 1971 was most likely to be used as some kind of industrial control component (a place where BIT would certainly make lives easier!), I've been thinking about reclaiming some space in Class 1. More on that later.

I'm not confident about my interrupt handling ability at all; I feel that I'm missing critical pieces of the puzzle. I will give it a go, and with a bit of luck everything will hold together.


Well.. my reasoning here was that all the real calculations are run through A then transferred though to the index pair, so the flags are set then. Another reason was that INC/DEC XY have a much simpler inc/dec circuit that's not part of the ALU. I'd like to hear more of your thoughts here! I did come for human guidance, after all.

In particular, the α600 isn't actually capable of block operations as it always trudges along word by word. It could simulate them.. probably. Maybe. I don't know.


As in transferring a certain number of characters? I'll try both ways.


Er.. not read, just exist. Did I mess up? I'll go over the text again.


I've been terribly indecisive, and the current memory map was "decided" upon through the sheer inertia of me getting tired of changing the document every few hours/days to match my current thoughts.

It's always an interesting journey.

One of the historical constraints would always have been the cost: the number of components or the size of a silicon die. These days, with CPLDs and FPGAs, the cost function is very much stepwise and in many cases constant, and that makes something of a difference to the microarchitecture and the instruction encoding.

Another facet is performance, which trades off against cost - a single 6 bit increment/decrement could serve for A, X, Y, and XY, at the cost of extra clock cycles. The 6502 uses the same ALU for everything, except for PC incrementing. The Z80 has (I think) more facilities. So, you need to decide on tradeoffs here too, whether or not it makes a real cost difference.

(It can be an interesting side-quest to use fewer resources, even in the land of FPGA where there are probably always enough, certainly for a 6 bit micro. It's a matter of what you find fires you up.)

Indeed!

I had the AI set to nag me whenever I make decisions that cost me a significant amount of die space, though I am reminded that I haven't had it do an audit in a while. So far, I've only had a loose transistor budget of "more than the 4004, less than the 6502" since I didn't have any other way of gauging what I would need if the Zg/α600 was a real in-era design; I suppose that will come with experience.


It's a tough choice, honestly, and the separate incrementor for XY may simply not be worth it in the end.

That said, INC/DEC XY have been a big part of the programs I've written so far (basic stuff: a small counter, a 6-bit Fibonacci printed to a "TTY" output (read: text file), etc.). Worth the cost? I honestly don't know, but I want to say maybe.

I did hit trouble when writing a 12-bit Fib sequence (https://pastebin.com/cNtRQKPb): the relative branching using signed 6-bit integers is just too short to span the gap between start and end. I ended up breaking the main loop into parts with a short branch and absolute jumps.