@@saultube44 Thank you for your kind words! I've been pretty busy with work the past couple of months (completing a project) but I'm still trying to design the decoder logic and how the pipeline will function. I'm getting close now.

Hi there. I use KiCad. It works nicely under Linux, so that's a huge plus for me! My biggest issue is that adding variants (e.g. 74AHC chips) to the library is a bit tedious. But it's pretty awesome for free software.

Thank you for your comment! I've already used some GALs because the alternative logic with "pure" 74-series would be cumbersome. (Also, I bought too few of some chips on my last order, so had to use a GAL to compensate.) I've not played with CPLDs. I think Xilinx is stopping manufacture of the common CPLDs, I guess with the reason being that FPGAs have been a thing for long enough now. I remember seeing a FPGA run the game of life at university, supposedly faster than the contemporaneous Pentiums. I'm struggling to get time to play with the project, sadly. My work has hit a crunch point and my energy has been zapped. I will have some significant changes in my next video. I think I'm getting somewhere with the decoding / pipeline design. Anyway, thank you again and hope you enjoy!

@@phodopus42 just reading about AMD knocking the head on the CPLD. The distinction is certainly blurry now with FPGAs available with nonvolatile storage, which was one of the key differences. But historically CPLDs and arguably even today they have different uses; small amounts of logic that doesn’t justify a FPGA or ASIC. Hopefully Atmel erm microchip will keep manufacturing their Altera MAX7000 clones. I made good use of MAX7000s in my 6809 and later 68000 boards. You can even get them in 44 pin PLCC so you can jam one in a breadboard. One would work in your projects, but the software can be a pain to find these days. Project burnout is a thing, which is why I try to have two on the go. Hobbies are about having fun, so don’t feel bad having break. Anyway, take it easy! If you want a look at my crappy channel... You might find something interesting. :)

@@lawrencemanning Nice -- just checking out your videos after a long week at work 😀 I think chip manufacturers can't really justify supporting electronics hobbyists long-term. I can see that DIP as a package is going to disappear at some point, with some chips pretty much impossible to find in that format. I ordered some 74-series from a Well-Known Distributor 2.5 years apart and got DIP chips from the same batch. I guess repairing 80s computers will, in 10-20 years, become like repairing valve-computers is now 😕

P.S. your channel can't be worse than mine 🤣

Thanks. Previously, I'd been using some DIP switches, except that they like to fall out of breadboards because of their short legs 😆

And never little by little - everything happens at once! 😅

Oops, yes it in the wrong order. Thanks for noticing and letting me know 🙂

Thank you for asking 🙂 I have github repo with the source of the GALs here: github.com/phodopus42/video/tree/main/src/pld The wiring is pretty boring. Mostly it's connecting an output XYZ to all inputs called XYZ. I did start a schematic in KiCad. Let me dig out some files and see what I can upload. What would be more helpful? A KiCad schematic or diagrams of the breadboard wiring? Or something else? Hires photos of the breadboards? Let me know.

Thanks!

I didn't realise the 68k did that. I grew up on the 6502, a tiny bit of Z80, then ARM, then joined the masses with x86 (although the only serious assembly I've done in x86 was for hand-optimising SIMD 🤯). It's a neat idea, for sure. I kinda wanted a "RISC-like" architecture in that all registers are treated equal. I guess I have a soft spot for ARM 😆 I have more ideas... too many ideas to implement. Thanks for watching & commenting 👍

​@@phodopus42 > Well with sixteen odd registers to deal with, and the division was not done as strictly as I make out, but we're talking about a sixteen bit instruction (minimally, they can get much bigger) versus your eight bit. But still interesting to see what you end up going with.

Thanks for the recommendation 👍 I've not seen Obsidian before. I'm pretty old school in that I use a notebook and a pencil. Whenever I have an idea, I write it down, even if I just cross it out moments later. I was a bit shocked to find a 15 day gap between entries recently 😥 Work has been absorbing all my energy recently because we have a looming deadline.

So... OK... this got me thinking. Since the start, I've been jumping back and forth between the idea of this ALU register. I never liked it. I ended up settling on a 2-byte opcode for ALU ops to avoid it. I was walking through the pipeline stages for instructions. Loads & stores take minimum 2 cycles (fetch opcode, perform load/store), or 3 cycles if there's an immediate (fetch opcode, fetch offset, perform load/store). ALU ops take 2 cycles because it's a giant opcode. OK, so what instructions only take 1 cycle? Virtually none. And I believe you are completely right. I sketched out the opcodes assuming they are all 2-bytes, and suddenly there is room to breathe! Let me play through the scenarios and I may have an update in the next video. Thank you for a provocative and helpful suggestion 👍 I'd love to see your FPGA design.

This is a very good point! I had forgotten about JSR instructions. I was going to use a register pair r7:6 for the link address (like ARM uses r14). I'd need a way to get the address back to the register file. It sounds like I have some more rewiring to do 😆

Awesome. Thank you 😄

Thank you, interesting thoughts! ARM uses PC-relative a lot because there's no absolute addressing. It works well as long as you can keep your data close to your code. I remember tricks like putting constants at the end of a function so that they are within the accessible range. So I was going for PC-relative instead of absolute addressing. It also makes it easier to write relocatable code, which is a real pain on the 6502, not that it matters with no MMU and a 16-bit address space 😮

@@phodopus42 a quick search tells me that this addressing is only used to load Immediates which don’t fit into the instruction. RISCV can load 24bit immediates, enough for the whole address range of a 68000. JRISC just lets immediates follow in the instruction stream like 6502 does it. With 32 registers in RISCV you load each all constants at the smallest block scope. I can see how 16 register Arm wanted to save registers and memory.

​@@ArneChristianRosenfeldtI think you might be right. If I have 8-bit registers, then a "load immediate" will suffice for loading constants. I do need something for code in ROM to access scratch RAM. The 6502 did this by adding zero-page addressing. That's maybe what I will go with. Thanks again for interesting ideas.

@@phodopus42 high level languages for some reason don’t use a scratchpad, but a stack and a heap. With a base pointer and this pointer (BX in x86?) . 6800 has 16 bit pointers. I may repeat myself here, but RCA showed that 16 * 16 bit did fit on a die, even in somewhat larger CMOS logic.

@@ArneChristianRosenfeldtThere is actually a number of processors that can use the PC as the base register for relative mode addressing. On most cases the instructions to do so are provided just as a matter of encoding orthogonality, not that they are used very often. However there's a critical difference between PC relative and GPR relative modes when talking about Harvard's architecture processors, because the first mode will access program memory while the second one will access data memory

Thanks :) I wanted something more "RISC-like" so that I can avoid complex instructions like the 6502's indirect memory accesses. That's why I ended up with 8 registers. I'm currently designing the data paths and decoder. In retrospect, that's where I should have started. As I've probably pointed out, I'm not an expert here! I am reconsidering the whole instruction set as a consequence. I've been programming some simulators at different levels: a high-level one for the instruction set, and a lower-level one simulating the data paths and control logic. This gives me the advantage that I can try something out without hours of work on the breadboards.

Thanks for commenting and offering ideas 👍 SRAM is definitely the best solution for the system memory, agreed. (DRAM would be faster but is a pain with the refresh cycles. It was used on, for example, the BBC Micro because 32KB of 4MHz RAM back then really needed DRAM.) However, my question was about the storage of registers in the register file. Modern CPUs have many registers (over 100 in typical x86-64 designs, even if only 16 are exposed to the ISA), and will use multi-port SRAM, that is, something that supports reading multiple addresses registers at once (i.e. concurrent dispatch of multiple instructions accessing registers), and even writing the same register as it is being written. This kind of setup is not possible with "ordinary" SRAM -- set an address, wait ~55ns, and you have a value on the outputs. I certainly can't read and write a single value in one "clock" of SRAM (although SRAM strictly speaking doesn't have clock cycles). I went with 74x574 octal latches because I can do precisely this: I can read and write on the same clock because they are edge-triggered. I only need 8 chips, so it's not too bad. You are right about the 6502 -- the zero page is *almost* like a set of 256 registers. Accessing and updating still takes multiple cycles, though. I wanted something that's a) built without microcode, and b) can retire 1 instruction per cycle (in the optimistic case). Variable-byte instruction decoding will be painful, I think. Of course, on an FPGA (or real silicon), it becomes less painful. But this is discrete chips, and wiring 100 connections and finding the 1 single wire that's made a bad connection is starting to drive me nuts 😆 Thanks again for commenting... you've made me have a good think about the design. Sorry if I've misunderstood anything you've explained. I might warm up to the idea of a fixed 2-byte instruction width 🙂 Anyway, I've probably said this before: I am kinda working this out as I go along. I'm definitely no expert in any of this (which should be pretty clear). I wanted to turn my "oh, I wonder if this would work?" into "wow, this circuit actually does something!" I'm slightly surprised anyone is even vaguely interested (!)

@@phodopus42 oh, I guess I should recheck the single cycle per instruction thing of yours. Load and Store need two cycles as does immediate8. So from a single bit to a 4 bit counter it is not much more parts. My motivation for even a second pointer comes from all the bugs in the original 6502, which tried to do 16 bit without it. It seems that you have the hard facts about RAM and I only know theory. SRAM is used for cache because it is faster than DRAM. Consoles used SRAM and ran faster than Homecomputers with DRAM. I agree that SRAM lacks separate in and out ports. It is so weird that each cell resembles a latch, but to save transistors and increase capacity, the latch is connected to the data line via transfer gates. Reading uses a slow connect to neutralised lines not overwhelm the small transistors, followed by highZ read out. Write precharges the lines and stamps this charge into the cell. Yeah, many CPUs (says a book I own, but my only example is JRISC ) have 2 port register files, but none has 1 port. Old DRAM had separate input and output ports for read modify write. Why does google find me tons of dual port RAM where both ports can write at the same time, but none with dedicated read and dedicated write port. The specs and datasheets don’t hint at a multiplexer to assign external requests to the read or write port on an internal block of latches. This would explain why those chips are so slow. Even with serialisation on collision dedicated read and write lines would make the chip faster.

Thank you 🙂 I don't know whether I'm fearless or I just don't know what I'm doing 😆

Sure! Give me a moment... I have to remember how I built it :-D From memory, I use a 555 timer connected to a J/K flip-flop to provide low / high nibble pulses. All 8 bits + this nibble switch go into an ATF16V8, and I get 7 bits for the 7-segment display. The J/K provides positive and negative outputs, so I use that to choose which nibble is connected on the hex display. When I have a moment, I'll upload the PLD file I used to build it and a quick schematic to github. I also built a version with a 24-bit address display and 8-bit data display, soldered (very badly!) onto some perf board.

Here is the repo: github.com/phodopus42/hex-display I hope it's useful! I'm sorry for any mistakes.

@@phodopus42 Thank you very much.

I've done some more testing on this "power down" mode, and it's more complicated than I thought 😿 More on that next time... if I get this new breadboard finished 😆

​@@phodopus42I too keep power consumption foremost in designs, just in case it needs solar power one day.

@@davidgari3240I like CMOS logic. An 80s RISC CPU design without branch prediction or instruction reordering has an extremely low power consumption. In a Micro processor parasitic capacity is low, and so is power consumption. Apply any clock up to 1 GHz . I still don’t know how a CPU knows the clock. Like, is there adrenaline? Direct power from solar can use a Joule thief to launch the next cycle once enough energy was collected. I think that spacecraft work this way. But what happens in an eclipse?

​@@davidgari3240My only concern at present is that my cheap lab PSU has a fan that spins up when I draw a few watts 😅

Thanks 🙂 I got distracted this week with the programmable logic chips. I'll upload the video today. I was hoping the Easter weekend would mean more electronics project time, but I ended up clearing out old junk. I found a bag of 1973 74-series chips from my dad... Not the LS, but original TTL. He said they were expensive at the time 😮

​@@phodopus42 I'm old enough to remember feeling the 40ma heat coming off those original TTL chips.

​@@davidgari3240I found some 74 series chips in my dad's lift - dated 1972. He said they were amazing at the time. He designed some electronics for a particle accelerator. Cool stuff. What did you design and build with them? Sorry for replying late 😕

Thank you! All these ideas float around my head, and I find explaining it crystallizes them 😀

It's still in a drawer :) I will do a wrap-up video to finish the series.

Thank you 🙂

Thank you :) You've encouraged me to look again. My breadboards are looking lonely and unloved ;-)

​@@phodopus42Well seems like there's quite a resurgent in retro computers with projects like the commander X16. I've personally been looking into the 65816, and getting into breadboarding. What ever came of this project, are you still working on it?

@@LoganE01 There is quite a resurgence. I like to think what could have been made in the early 80s with the hardware they had, but some of the hindsight we have now. For example, Acorn's original idea before they made the BBC Micro was to have some kind of dual-CPU system - a bit of that survived in its "second processor" add-ons. My project has been paused. The past year has been tricky and a project like this needs more than 30 mins at a time. (It takes me that length of time to remember what I was doing!) I can totally recommend starting with the 65816 - I was having loads of fun until "real life" got in the way 🙂