Yeah, I am just going to go back to how I used to do the narration. Seems either too hard to edit or too unnatural to do it a different way.

Anyway the next video is up where the decoder implementation finally concludes and it's all working again:

[021] Instruction Set Decoding! (Part 3) https://youtu.be/-5vtGfNTn1k

I have a week off so I have been recording an episode every day. The next two episodes will be a bit longer but more exciting. I focus on making the processor Turing complete. So that means conditional branches and memory access. But I have a feeling this coming month is going to be crazy with work so I might not get much time to make videos so I should probably hold back and release them slowly. I'm excited though.

So, question: to microcode or not to microcode? So far I have gotten by with just random / hardwired logic. And I could probably complete the processor that way. But the processor is currently only a single cycle machine with a very long propagation delay, which isn't realistic for hardware. I probably want to split it into multiple cycles. So I will need a state machine. Do I build that state machine in microcode or just keep hardwiring it?

I mean, for a discrete logic implementation I can use GALs, so it's not a big deal to keep on with the hardwired logic, and if I keep the processor as simple as it currently is, I think hardwired will be easier / faster to implement. But I suspect it might be easier to bug-fix and/or modify if I go down the microcode path. What do you think?

I'm sure you're right, that maintenance is easier with a microcoded approach.

And microcode is a familiar and regular concept, so it makes sense from a teaching perspective too.

The only thing is, I feel that hardcoded machines are a bit neglected. It's good to know that hardcoded control is possible, and practical, and in some ways cheaper. So, if I were designing a syllabus, I'd probably want to start with hard-coded accumulator machine before introducing a microcoded register-rich machine. (Then again, in practical terms I know nothing about teaching!)

My thoughts Turn to the DARK SIDE the DARK side.
I tend to like simple microcode (rom lookup) as it permits a larger design, than hard wired design, because after something more complex than say PDP8 or a TOY cpu design the number of states grows really fast. A front pannel and Interupt service
adds even more decoding states. Proms for microcoding are to find if you want fast speed. Using 150 ns eeproms
are nice for slower designs. About 35 chips are needed with simple microcoding and random logic. 25 chips if
PALS replace the glue and buffer logic for the control segment of computer.

CMOS 22V10 are a nice size PAL for random logic.
Computers having core memory, often had two logic paths, memory and PC logic and the ALU logic.
This gave a large numbers of don't cares in the decoding logic, as each state was often a complete memory cycle.
DECODE, INDIRECT, EXECUTE,DMA, IDLE might be all the states needed for a computer.

I am kind of partial to the microprogramming route. One thing about that route is the approach / design that you'll need for the microprogram sequencing. I would suggest using as a model for your sequencer the Fairchild 9408. It's fairly simple, as compared to the AMD products, and I've used a verilog implementation of it in several projects, commercial and personal. You can easily implement much of the functionality of the 9408 with several 22V10 PALs.

Standard Flash PROMs have access times that may be too slow. If that's the case, I wrote a small Python program that generates logic equations from a microprogram ROM file that you can run through a CPLD programming tool to generate the SUM-OF-PRODUCTS equations that would represent your microprogram. Using that tool, I've been able to fit the microprogram for my extended 6502 soft-core processor in a large CPLD.

In either case, microprogram or discrete logic state machines, I am following your project with interest. Good luck on your project.

Hi Michael! I read your post and article about microcode the other day I already read the datasheet for the 9408

Yes, I think putting microcode into GALs is a great idea, as I think that will be much faster than ROMs. And you can put the GALs local to where the signals are needed and save wires.

I think I might go down the hardwired rabbit hole a little bit longer. I am actually surprised how far I have gotten with it already. I want to see if I can handle memory and fetch delays without microcode first. My idea was to implement various stall signals in the processor so I can have memory stall the processor when its busy, rather than having the control unit of the processor have multiple states. We'll see tomorrow if that works out or not. It may not.

But then I will transition to microcode. I have an idea for how to convert the logic I have built so far into microcode pretty easily, so it's not wasted effort. And customasm makes a decent microcode assembler. Though, I had lots of success with using JSON too, where I could generate the customasm rule defs from the JSON as well as the microcode ROMs and a simulator.

In other news, I managed to synthesize it and run it on an FPGA today! Program memory ended up being implemented as LUTs, and access to the data RAM is messed up because I haven't yet implemented stalling while memory is busy, but otherwise I got an output of the first few Fibonacci numbers!

Andrew S. Tanenbaum wrote a book in 2000 with a nice micro-coded machine described from the bottom up: the ijvm mic[1..4]

mic1: first implementation, the simplest
mic4: last implementation, the most advanced

mic1,2,3,4 share the same micro-architecture, and have an assembly compiler written in Java.

Nice find, DiTBho. I like Tanenbaum's book a lot: I just checked, and my copy of Structured Computer Organisation is a 3rd edition from 1990, and while it does have a mic-1, it predates the developments you mention. So, a later edition will be better!

The book The Art of Digital Design 2 ed can be found on bitsavers in the pdp/i section.It has random state logic
or micro-code control for a PDP8 clone.

The point here is: if you want something educational, there are well done documented works in the form of books, laboratories, discussions and examples, like the Tanenbaum'ijvm, which I learned from and used during my university "computer science" courses.

(There are indeed well-done educational things, but I think we can still try to create new ones, for our own self-improvement as well as hoping to help others learn. Indeed, if we are to teach, we must learn to teach!)

Took me a little while to find The Art of Digital Design 2 ed on bitsavers but it's very interesting. Thanks for pointing it out oldben! I have learned a ton from it. There's a ton of info on designing a full state machine for a processor, some great tips on making a hardwired design maintainable, and the chapters on microcode are great. I have so many ideas! It also helps me figure out how to introduce it in the video series.

I did indeed manage to get memory working with the stall method, but I still had to introduce a state machine where I didn't want one, and the hardwired logic is starting to get hairy. Especially around the state variables. The and gates I am using are starting to grow more inputs, with every input making them harder to reason about.

But I think that's exactly the problem I wanted to encounter on video to demonstrate why it's a problem and needs a solution. Building a microcode sequencer is going to be a bit of work, so it's good to see what value it has first before building it.

As for building educational content: The community here is small, there's only a few regulars. Ben Eater's content has sparked so many people to build his computer it's incredible. I mean, he's a master educator and his series is masterfully crafted compared to mine. But if I can inspire a few people to try building a CPU from scratch it would be awesome. And that's partly why I am not trying very hard to be masterful in crafting the videos I make -- I want to show anyone can build a computer if they put their mind to it and fumble their way through it, solving whatever the next problem they find happens to be.

So think of it as my small attempt at growing our community. And who knows, maybe a few students going through school will find it helpful but honestly, most of them won't care about this once the class is over. I want to cater to the few that might dive down this rabbit hole and make it a hobby. But I want to help them do that where I can.

So yeah, view the education aspect of my videos in that light: would I help someone on the journey to build a CPU as a hobby project? If the answer is no, please do let me know how I could improve. I also want my content to be interesting to such an individual, so if any parts are boring or I don't need to explain/show them let me know -- but it would be from the perspective of someone getting into this hobby not someone that knows it super well already.

Take it with pliers, I didn't assume your video are "educational" but rather simply your "adventures with softcores".

Vblogs and Youtube are usually for story-telling, if I will ever post something on YT it will be something like "after ten years of planning and designing it's time to experiment, I can't assure you anything, video after video, let's see where it will take us (perhaps no-where)"

That's why I posted about mic[1-4]. That project was explicitly created with the precise purpose of being educational about micro and macro architectures

Yesterday I bought a paper book from a library located in New York.
Paid 35 USD including postage. Not bad

I'm in favour of getting the message out there that CPUs are within reach, as a thing to design. And supporting each other as we design them. And making it easier to get started.

It feels like we could usefully have a resources thread, for books and websites which help in a general way. (If we don't already have one!) Oh, and also videos which help, of course.

Evaluation of FPGA development cards would be nice too, as well as good sources of strange componernts
like 2901's or two or three port ram like used in RISC designs.
Ben.