The way you speed up the video but keep your explanations perfectly synced is beautiful! That and the mesmerizing "slotting in" of perfectly fitted wires makes this thing looking like it's developing, almost evolving, so effortlessly and naturally I don't think anyone could have done it better.
Haha YES! I just found your channel and started binge watching this entire series yesterday and finished the last video about an hour ago and was so sad. Then, as I was explaining the series to my wife I go to show her one of the videos and see this! Perfect timing!
Great seeing the comments on the last video incorporated into this video =D Next optimization I'd love to see (that doesn't make the computer significantly harder to understand) is getting the microinstruction counter reset integrated into the control lines so that short instructions can reset the microinstruction counter earlier and move more quickly to the next instruction. So glad to get the new video, thank you for the whole series!
I'm trying to lay things out so there's room for expanding to a 24-bit control word. Using a bit to reset the instruction cycle early is definitely a good idea.
I only count 15 labeled control lines at the moment, a few more you've mentioned (B register out) as possible but not implemented. I'm certainly interested to see what else could be used to help control the modules. There's certainly a number of chip-enable/reset/"special" lines on chips that are currently tied directly to high or low that could be used for less common but still useful operations.
Wouldn't be at all hard to do, as long as whatever is triggering that yellow CLEAR line to the counter can handle a high signal there when the inverter sends it on T4. If not, then one could simply remove the CLEAR line as it exists and wire it in as a micro instruction. Then the EEPROM or whatever is used to handle the microinstructions can simply activate that line at the end of every instruction and forget about the T4 line activating it....
There's definitely some interesting caveats to handling the reset microinstruction counter, but assuming it's done with a bit of EEPROM as mentioned, as soon as the reset was asserted, the microinstruction counter would be reset (unless it was tied in with the clock as well, unnecessary I'd guess, but possible) and the EEPROM output would change to match the new microinstruction counter just like it does when it hits the last microinstruction and resets currently. It may be another part that limits the overall clock speed of the computer, but this design was never made for high speed anyway.
That's.... intended behaviour, isn't it? Whenever the EEPROM outputs CLEAR, the counter resets and the EEPROM then instantly outputs CO MI. This is fine, since it's the start of the fetch cycle, which is the same for all instructions. The end result is CLEAR never actually takes a clock cycle, instead starting the next instruction straight after the previous one had finished. One must be careful to ensure that CLEAR is always enabled alone, with nothing else active at the same time. This is why we still need T5. In the case of ADD, at T4 we execute EO AI. Then we still need T5 to execute CLEAR and begin fetching the next instruction on the next clock cycle. There's technically a one microinstruction overlap between instructions, but practically this shouldn't matter...
Well done! It was exciting to see it all come together with the fetch cycle in this video. I have a Ph.D. in computer science but I've learned so much from this series -- you're so much better than the professor I had for a graduate course in computer architecture!
I have read 3 books on this subject. Paid about £30 for each of them and this is the most info packed learning material I've seen. I already had a lot of info on the topic, but I couldn't understand how micro-programmed cu's work and I'm so glad you're stepping through this for me. Thanks for all of your time!
indeed he should make a book out of it with theory like alu and show it with his pc example. similar to the book OpenGL ES 2 for Android: A Quick-Start Guide :D
I watched your whole serie in 2 weeks. I have to say that your tutorials must be the best on electronics on youtube. It's fantastic how you explain everything from the most basic to something so complex and not get us bored. I will defenantly be trying this out after my panhellenic exams.
Yes! A new part in the series. After binge-watching the series two weeks ago, I started building my own. I am almost halfway and awaiting the final parts from China. Thank you @Ben Eater for the great videos and the inspiration. You rock!
Dear Ben, am now desperate for last videos. Please post asap. Fear life can't go on without the final pieces of the jig-saw. Seriously, I’ve been in IT since 1970. I first worked on IBM’s 360 range of computers - pre virtual-storage. I’ve always ‘known’ (or more precisely - was ‘taught’) that computers were made, essentially, from transistors used as fast low-power switches. But I had never known how. This series of videos has closed that yawning gap in my understanding. I can’t thank you enough. Strange that the control word does not do ‘anything’, simply opening and closing various pathways to and from the bus. Fascinating.
You should make a microopcode o reset the counter at the end. Therefore different insrructions will use a different amount of clock cycles. The microopcode that resets will take no time.
Hi, I have just found your channel via a forum link and must say, I am extremely impressed by your skill to explain everything in a really slow but interesting way. And everyone can understand that :D Keep up the good work and thanks for the videos :)
I have been watching the breadboard computer serie during a couple of days. This is the best explanation I´ve ever seen and heard on how a computer works! Thank You ever so much for uploading.
You're awesome. I did all the theoretical stuff in school and work as a programmer now but after watching your project so far I can honestly say I understand the principles of a CPU. Thanks!
This is truly amazing. I studied all of those things back in the mid 80s but haven't seen someone actually built it and explained it this way, fancy explanation of how it works step by step. I can imagine the work Steve Job and Woznick have invested to build their first computer.
YES! I just found your channel and started binge watching this entire series yesterday and finished the last video about an hour ago and was so sad. Then, as I was explaining the series to my wife I go to show her one of the videos and see this! Perfect timing!
This is a brilliant, informative course of videos. I'm actually started to build this, it's a great demonstration of what you can make with 'glue' logic..... and flashing LEDs!
That is just great! A few months ago I started writing some low level code(X86 assembly), and this videos opened my mind even more! Good job, can't wait for an update!
I loved this series and am going to try and build this myself. I have always wanted to get into breadbording and as I have a good background in programming assembler as well as other languages this will be great to relearn the basics of computer operation at this level. I was taught very early on the structure and logical operation, but never the electronics that went to support this. Thank you for a great series. I will let you know how I get on...
Thanks Ben! it's all coming together. My breadboards are quivering in anticipation of a control logic section. With your video's I now have enough information to get it all wrapped up. Great work - keep em coming.
I am, though, going to setup a microcode that "resets" the micro instruction counter so that I don't have to wait for blank micro instruction cycles. I am also thinking about setting up a hash table that allows me to compress my microcode memory in the EEPROM. Basically, without that, each microcode takes up a specific section of EEPROM memory. Not really a problem, since our instruction set is going to be small (mine instruction words are 8-bit, not 4), but from a design perspective, I like the challenge of "compressing" the microcode translation table so that I can tell the decoder where to find any microcode that I want. On my instruction register, instead of the LS245 + 8 bits, I used a LS373 as the storage, and bus interface. Simplified things quite a bit - and was a challenge to design a different way to handle registers. :) Also, I setup my system to use a single chip 256Kbit ram chip - so I am thinking of providing "paging" instructions as well just for fun. With your EEPROM instructions, handling a RAM chip with I/O pins ended up being not too much of a problem.
Not worth the fuss. Just use a ready-made EEPROM chip, there's plenty of room for microcode. In an actual CPU design in silicon, you could of course omit some unused memory cells altogether from the ROM matrix to save some transistors or space. But when you already have your EEPROM prefabricated for you, the Universe will not suddenly end if you waste some of the cells ;J But trying to compact the code may make it less regularly laid out and it might require a complicated logic to decode the opcodes into addresses in that ROM, so you will effectively end up with a more complicated and more expensive design :q
Thanks a lot. This is so fascinating. I could see in the last video how this was all coming together. One of those "Wow, kewl!" moments. I haven't been this interested in electronics since the '70s and early 80s. :) I still have a stack of Radio Electronic magazines from like... 1980ish? Stuff on building robots I loved and there was a series on building a 68000 computer when those CPUs first came out (used in the Amiga).
Great work, I am thinking of building my own system, I might start next week doing up a set of schematics for what you have built so far. You are inspiring me to do something for nothing more than sheer fun. With the microcode counter reset I would not hardwire the reset to a pin of the decoder. Instead if you use multiple eeproms, use data pin to reset the counter. This will then give you variable length instructions so the simpler ones will be faster and if you needed something like indirect memory addressing (I know that is pie in the sky but hey I am thinking of building a similar system to write my own microcode system) then you can take the full 8 or 16 clock cycles if needed.
@6:12 wow that's very smart. This is how micro instructions get decoded. I can image how many decoders needed to decode 35 micro instructions, say for the PIC MCU. That along with the EEPROM and the address input to EEPROM can interpret instructions via the EEPROM memory then execute the proper micro instruction.
I was waiting patiently for this :) great work. You did quite similar to what I was imagining so I feel like a little genius - had no idea how these things actually work before and now I feel like a can build one myself :)
No one or book ever answered such internal operation or connection. it is all some blah blah in book which never tell real story which you have shown, excellent and genius .
I am so, so proud that Ben saw fit to incorporate one of my suggestions (combining instructions, where they don't interfere with each other). It makes me feel good to know that I've contributed something worthwhile rather than only leeching information like a sponge (not that that's always a bad thing). :)
Excellent tutorial. Made me remember my microcomputers class at the university. How would it be great if I could imagine to bring my term project like this on breadboards.
Coming with no electricity background and working all the way to this lecture I found that I dont have 74LS138, just few 74LS139 from previous lessons. I feel so happy to work my way how to make LS138 from one LS139 + one NOR gate.
Brilliant :) Very much looking forward to the next installment! I'm also starting a microcomputer project, partly inspired by this series; I'm very interested to see what you cook up with the EPROM combinational logic, as I suspect I'll be using something similar to solve memory-mapping :)
The information quality of these videos is *too damn high*! I've designed architectures around Intel 8085 on paper in Uni, and know a fair bit of C++ tricks that operate at register level, but your series has made so many things crystal clear I had thought were already crystal clear previously. Well I do only now realise there was a thin veil of mist. Wish paid, institutional education were such high quality as your videos.
Yay! We taught the computer how to fetch! :D Now it's time to teach it how to chomp whatever it fetched ;) I think I get it now how it works, but I'll still watch next videos to see it happening ;) (and to see if I'm right). My EEPROMs already arrived from China, so I can try it out myself before seeing your solution ;> As for saving cycles, how about resetting the phase counter depending on the instruction? We don't need to wait through 5 steps every time - if the instruction requires less steps, we could reset the counter earlier by asserting the reset signal to it programmatically from the instruction decoder ;) Nevertheless, after you finish this part of the course, I would like to see you explaining somewhere in the future how to fetch and decode multi-byte instructions (e.g. fetch the correct number of operands following the opcode depending on what opcode it is) and do things like conditional jumps, subroutine calls / returns etc.
i understand now why my grandpa would always talk about gigantic computers on walls its because to give data they couldnt store it in smaller sizes and as an example this cpu you have might be the size of one back then because of the problem of the size of data storage
Wouldn't you be able to set an end flag for each instruction which tells the cpu the command has finished and the counter should be reset? it would add a step to each command but would allow you to write longer instructions but not have to count to the max length each time
I wonder if this could be merged with microinstruction jumps... The "end" microinstruction is like an unconditional jump to the first (0th?) phase of the cycle. But perhaps it could be extended to jump to other phases as well? E.g. to skip the part which fetches the operands when there is none for some opcode, or jumping to different alternate routes for different addressing modes, or repeating some sequence of instructions in a loop (think multiplication/division implemented as repeated addition/subtraction in the ALU).
+Sci Twi It's easier to make separate "load" instruction and just don't use it when it don't needed) Multiplication and division is a separate topics, becasuse there's special algorythms for these operations (it takes lots of time as repeated addition/subtraction). I think Ben will tell us about it later.
Start inventing new ones, like my friend Pinkie Pie ;) E.g. her recent invention: "rooftastic" :) "As in, I'm gonna stand on the roof and yell to everypony how rooftastic this is!" ;)
You can make it variable microinstruction by having a control line to reset the microcounter at the last decode. For example, if we call it RC (reset counter), then LDA would be: co mi ro ii ce io mi ro ai rc Haven't seen your other videos yet, but figured I'd throw that out there if it doesn't come up and I forget to say something later.
@@topilinkala1594 that comment was 5 years ago, but if i recall correctly, he stored the current state in a latch, so the reset would only affect the microstate. This means it should be loading in the next decode into the latches within the next cycle and microstate being reset means it would begin at 0......I'm not going to rewatch the video, so I might be wrong here, and if so, then what i said should have been the implement in order to make it work, otherwise, sorry.
If you use the reset input on the 163 as a new control line you could program your microcode to reset the counter when any particular instruction is finished. This would mean that each instruction would only take the minimal amount of cycles. It would also allow you to have instructions that take more than 5 cycles without increasing the amount of cycles that all your instructions use.
Towards the end of the video, you were talking about setting the logic counter length based on the longest command logic chain programmed in the system. Would it be more efficient to include a "Logic Reset" signal as the final microcode instruction for each programmed logic command? Tie that signal output to the counter reset signal in the logic circuit? This way any command programmed would take just as many cycles as needed to complete - no need to wait on the logic counter to complete its cycle based on the longest microcode instruction set.
Any of you guys find that, with the 74ls138, the circuit works better when the 5 green leds are grounded to the circuit? In other words, the green leds would be dark with a moving “on” led vs on at baseline (with a moving dark led) as shown in the video?
Since we already have output module, I wonder how one design an input module and probably the corresponding INPUT instruction. So that we can run an interactive program with this computer.
Would definitely be possible, having an input enable instruction that can read the input and put it on the bus. Programming that in would be the more difficult part, seeing how with this build, we only have 16 addresses to work with. Would be doable yes, but there isn't much you could actually interact with. But, then again, this build is just to learn the basics. If you ever wanted to expand, you could use this as a good guideline. I've certainly learned a lot from watching.
It would probably be possible to make something very similar to the RAM programming interface with a series of switches; beyond that you just need the logic to control when the values are put onto the bus and it works just like any other module in the computer. I imagine the limit to practicality (probably not a real concern, given the nature of this build as a teaching tool instead of a purely functional one) would be that it's hard to program values quickly. If you expanded it you could create a module that would store several values and read them in sequence each time a value was read, but then you'd essentially design a different RAM/ROM module. Definitely a useful exercise to build any of such inputs though. Handling pauses (halt/unhalt) waiting for input could also be important.
All you need for an input mechanism is a DIP switch and a tri-state buffer to select whether or not to put the switch state onto the bus, which would be loaded into the A register by the IN instruction. Given the tiny 16-byte address space, you really can't make any practical programs for this computer, but you could demonstrate that you are actually reading input by writing an Count-By-N program that repeatedly adds the input value to a memory location and outputs the value to the LED display: 0x0: ldi 0x0 0x1: sta [0xf] 0x2: out 0x3: in 0x4: add [0xf] 0x5: jc 0x0 0x6: jmp 0x1
2 years late to the party, but would it be worth having the microinstruction counter reset by the EEPROM as well? Some of those instructions only have a few additional cycles, it would seem like a grand ol' waste to just pulse the clock and have it do nothing.
Another year later to the party: Later in the series he used the last available dataline on the EEPROM for updating the flags register and even mentioned this idea. So you'd need another EEPROM because of the lack of free datalines on the first two EEPROMs. I think you could still nor the entire control word together and feed that into the step counter. You could also get rid of the whole demultiplexer, because each instruction already ends "on time".
6:38 where do you get those nice datasheets? I had to use one for the 74LS138 in my eletronics class, and it was the worst one the teacher could find, there was no clear view of what port did what like yours
You electrically combined the CO and MI signals, so when the IO MI step is to be implemented, the CO signal will also be raised. I think it was necessary to connect CO and MI on separate inverters.
I know there is still more to go. But in the future it would be cool to look at how we can optimise the system by doing calculations on the falling edge of the clock.
i really like this video series. I was thinking would it be possible to have the master reset of the micro instruction counter as part of the control word. When the instruction is done after T3 like OUT it could reset the counter on T4? That would allow for variable instructions with 4 till 16 microinstructions
I was wondering how you could reduce the micro-code length of the ADD instruction further... Merging CE with RO and II reduced it from 6 micro-instructions to 5. I was asking myself whether the last ADD microcode could be merged with the first microcode of any other next instruction. That would mean, merging EO + AI with CO + MI, effectively bringing the number of maximum micro-instructions down to 4. Obviously, there would be conflicting bus usage. But given that CO is seemingly used exclusively with MI (maybe not actually, I don't know the whole instruction set), what if there were a secondary bus going directly from the PC to the memory address register? Would that be feasible? I'm sure it would also be cumbersome to implement this last micro-instruction overlapping onto the next instruction in the control logic. Even though this computer isn't built for speed, this could mean a 5/4 speed increase to the whole computer, which isn't negligible. That is unless Ben Harper's suggestion of having the EEPROM controlling the reset for the instruction conter cycle is implemented. Also, there may be other instructions in the instruction set which need 5 micro-instructions or more. Is this a valid suggestion? I'm not sure what I'm talking about, so I'd be interested in having the opinion of someone who does.
Maximilien Tirard An easier way to save a cycle is to speculatively load MAR in T1. All the memory access instructions load it from the instruction register during T2, that is the value on the bus in T1, and instructions that don't access memory don't care what's in MAR. This is speculative execution, and the cost is extra RAM activity when memory access is not done.
Smart! That's really neat! But wouldn't that cause issues? So you are saying that during T2, when II is reading from RO, MI can kind of steal the value as it's there on the bus, because it's just going to be read from IO in T3 anyways. I was thinking to myself that this could cause a problem, but no! All these latches are edge triggered! II and MI latch on very quickly on the rising edge of the clock, much faster than it would take for the RAM chip to read the new value. If they weren't edge triggered though, this would cause a problem, right? Anyways, super neat suggestion and super neat video!
Lots of things could be improved by adding more data paths. For example, a path directly from the PC to the memory address inputs, bypassing the MAR, would let you fetch an instruction, increment the PC, and load the IR and MAR all in one cycle.
where do you get your DIP Switches, the ones I got have too short of leads for a breadboard. At least I only bought 5, however I want to purchase more so any input would be good.
@8:46 As a circuit, it is very simple but as a concept, it is amazing. Is that how the vector IRQ works? Of course depending on the IRQ priority, then different addresses are jumped to. This can create amazing IRQ features assuming we have decent amounts of memory available for all the said IRQs.
Any chance we can get a parts list for the computer you built? I'd like to learn and build with this playlist, so it'd be best to order all parts at once.
I've got a question. Each control signal is set when the clock goes low because you're using an inverted clock, but couldn't you run into issues because the control signals will be turning off as the clock goes high. For example, lets say I set ram out and register A in high; the value from ram won't be read into register A until the next rising clock edge, but as the clocks edge is rising, the control signals are being turned off because they are running on the inverted clock. What happens if the control signals are turned off before the value can be latched into register A?
There are so many easy improvements you could do, like resetting the counter early, b register out, turning the AU into an actuall ALU (bitwise or/and/xor, ror/rol, and use a multiplexer to select the output with only a few control lines), splitting the instruction register into two bytes for more address lines (not _as_ easy if you want to do it efficiently), but I'm almost glad that you didn't do those things. It really motivates me, and I think a lot of other people to try these things out for ourselves and have fun with it! And also buy your product in the process It's all part of your plan :P
so it basically works like the output display multiplexing-wise? So you write a micro-instruction library with those related to one instruction have a common address number and the counter does the rest?
I love this video series. I'm confused about the use of the demux though. You could put all of your microcode into one ROM (assuming enough data bus width) by using the T-state counter as the low four bits of the microcode address, and the content of the instruction register as the high four bits of the microcode address. I can't wait for figure out why you're demux-ing the counter. One ROM per instruction seems inelegant. If you used ROM's with inadequate data bus width, you could just address multiple ROMs in parallel to gain enough bus width for the control bus, but the multiple ROMs wouldn't be enabled independently so no demux-ing would be needed there. I also feel like incrementing the instruction counter should be the last thing that non-jump instructions do, instead of the first thing that all instructions do. For example, if the program counter is 0x00 and I do a reset, I expect the first instruction executed to be the instruction stored at address 0x00, not the instruction stored at address 0x01, as your current microcode would do. Similarly, if I jump to address 0x80, I'd expect the next instruction executed after the jump itself, to be the instruction stored at address 0x80, not the instruction stored at 0x81. Maybe I misunderstand something.
As the control logic isn't implemented all I can do is guess, but the demux might just be a visualization tool as the 3-pin version would be perfectly suitable to use in the control EEPROM circuit. So you need 4 lines in for the instruction register and 3 lines in for the microinstruction counter (using an un-demuxed version), and enough EEPROMs to make up your control word width (24 bit control word, 3 8-bit output EEPROMS). Because the Counter-Enable is activated before the instruction specific code is executed, a reset or jump would update the Program Counter after it's increment and behave as expected (reset would set it to zero, jump would go the the specified address). For instance a jump could be T0 - Program-Counter to Memory-Address, T1 - Memory-Out to Instruction-Register-In + Counter-Increment-Enable, T2 - Address-Register-Out to Program-Counter-In, T3-T6 - No-op/Reset. After execution the Program-counter is your desired value and the cycle starts over.
For the counter increment logic, I understand that reset/jump will update the PC after its own (earlier) increment, but the instruction at the target address will ALSO increment the program counter before reading the opcode. So assuming we're at PC=0x0 at T-0, and that the instruction at 0x00 is a "LD 14", the decoding for our instruction will increment the program counter to 0x1 BEFORE it reads the "LD 14" opcode. So the program starts with the instruction at 0x1. Jumps will work similar. Your jump instruction to address 0x8 will put 0x8 in PC, then as part of decoding that address it will again increment the PC to 0x9 before fetching the opcode at 0x8. Jumping to 0x8 will never run the opcode at 0x8, and resets will start at 0x1. Is there a flaw in my reasoning (it is really late after all)?
This is actually what I have done in my build. I'm using only 2 ROM's for the control matrix. The lower 3 bits are made up of the un-demuxed (I don't even have the demux at this point, its on order) T state counter and the upper 4 bits are the instruction bit pattern. I put both of these together to come up with a 7-bit address that looks up the control sequence. One ROM is for 8 of the control lines, the other ROM is for the other 8 control lines. Both ROM's are addressed at the same time.
I think I understand what you mean now (although it's late for me too certainly). The program counter is read in T0 then incremented in T1, the incremented value isn't re-read until the next instruction cycle so the change won't affect memory read that also happens in T1. So during T0 you read the PC into the memory address register, then during T1 you read memory using the stored value, not the live value from the PC. In some bad pseudocode: From power-on/reset //PC = 0, T=0 MemoryAddress = PC T++ // T = 1 InstructionRegister = MemoryValue PC = PC + 1 T++ // T = 2 ...then opcode specific stuff happens. So the PC value is stored before being used so any updates to the counter after T0 won't change which value/opcode is loaded from memory during T1.
Ben: Oh, yeah. Thanks for that explanation Ben. That makes a lot more sense now! I went back and rewatched part 1 where he explains the use of the CE vs the MI control lines. Gerald: To make micro-instruction programming easier, I wonder if you can reduce the number of required control signals from the ROMs until only one 8-bit ROM is needed by demux-ing the various bus inputs together into only 3 ROM data bits and bus output enables together using another 3 ROM data bits (since only one thing can output to the bus at once, and presumably it is only useful to input one thing from the bus at once). That alone isn't enough demux-ing to reduce the control signals to 8 bits, but maybe there are some others that can be combined similarly. E.g. if you never need to input enable and jump at the same time, you can run the J control signal though the "inputs" 3-to-8 multiplexer. Similar logic could apply to halt, possibly.
You could have the counter count all the way up to 15 so you can have more complex microcommands (with more steps) and have a microcommand that resets the counter witch will be the final one in each command. Right?
anyone else having trouble with the ls173 on the instruction register resetting without having to go high, the pin seems to stay high and after pullinh reset pin from ground resets this chip. because of that when trying to hook it up to the 74ls00, the reset ic doesnt seem to work.
One thing he has never showed in any of his videos is the magic elf sitting off camera handing him perfectly cut, shaped and stripped jumper wires.
his tone and his ability to enunciate clearly is comforting.
He's the Bob Ross of 8-bit computing.
dzScritches his*
Immortal
His makes no sense... it`s He is.
Lila_Kuh98 learn English please
Immortal
speakspeak.com/resources/english-grammar-rules/various-grammar-rules/short-forms-contractions
Here you have proper English.
The way you speed up the video but keep your explanations perfectly synced is beautiful! That and the mesmerizing "slotting in" of perfectly fitted wires makes this thing looking like it's developing, almost evolving, so effortlessly and naturally I don't think anyone could have done it better.
*mesmerising
Learn proper English.
gotta love the wiring
He obviously keeps it synced with his clock pulses lol.
You're both right. Mesmerising is the British form, while mesmerizing is the American version.
Okay, so I'm not going crazy, the video does speed up and slow down.
Haha YES! I just found your channel and started binge watching this entire series yesterday and finished the last video about an hour ago and was so sad. Then, as I was explaining the series to my wife I go to show her one of the videos and see this! Perfect timing!
:)
Lucky you :q You didn't have to wait through over a year for new videos ;q
Super video! I applauded for $5.00 👏👏
I would like to thank you for this tutorial
I'm a computer engineer student and I found it very helpful to really understand how computer work
Abdullah Albishri Same for me! this is very valuable
Abdullah Albishri same here. My university could really use a lab class that has us build things like this.
Abdullah Albishri also check out his networking tutorial
Great seeing the comments on the last video incorporated into this video =D Next optimization I'd love to see (that doesn't make the computer significantly harder to understand) is getting the microinstruction counter reset integrated into the control lines so that short instructions can reset the microinstruction counter earlier and move more quickly to the next instruction.
So glad to get the new video, thank you for the whole series!
I'm trying to lay things out so there's room for expanding to a 24-bit control word. Using a bit to reset the instruction cycle early is definitely a good idea.
I only count 15 labeled control lines at the moment, a few more you've mentioned (B register out) as possible but not implemented. I'm certainly interested to see what else could be used to help control the modules. There's certainly a number of chip-enable/reset/"special" lines on chips that are currently tied directly to high or low that could be used for less common but still useful operations.
Wouldn't be at all hard to do, as long as whatever is triggering that yellow CLEAR line to the counter can handle a high signal there when the inverter sends it on T4. If not, then one could simply remove the CLEAR line as it exists and wire it in as a micro instruction. Then the EEPROM or whatever is used to handle the microinstructions can simply activate that line at the end of every instruction and forget about the T4 line activating it....
There's definitely some interesting caveats to handling the reset microinstruction counter, but assuming it's done with a bit of EEPROM as mentioned, as soon as the reset was asserted, the microinstruction counter would be reset (unless it was tied in with the clock as well, unnecessary I'd guess, but possible) and the EEPROM output would change to match the new microinstruction counter just like it does when it hits the last microinstruction and resets currently. It may be another part that limits the overall clock speed of the computer, but this design was never made for high speed anyway.
That's.... intended behaviour, isn't it? Whenever the EEPROM outputs CLEAR, the counter resets and the EEPROM then instantly outputs CO MI. This is fine, since it's the start of the fetch cycle, which is the same for all instructions. The end result is CLEAR never actually takes a clock cycle, instead starting the next instruction straight after the previous one had finished.
One must be careful to ensure that CLEAR is always enabled alone, with nothing else active at the same time. This is why we still need T5. In the case of ADD, at T4 we execute EO AI. Then we still need T5 to execute CLEAR and begin fetching the next instruction on the next clock cycle.
There's technically a one microinstruction overlap between instructions, but practically this shouldn't matter...
Well done! It was exciting to see it all come together with the fetch cycle in this video. I have a Ph.D. in computer science but I've learned so much from this series -- you're so much better than the professor I had for a graduate course in computer architecture!
I have read 3 books on this subject. Paid about £30 for each of them and this is the most info packed learning material I've seen. I already had a lot of info on the topic, but I couldn't understand how micro-programmed cu's work and I'm so glad you're stepping through this for me. Thanks for all of your time!
indeed he should make a book out of it with theory like alu and show it with his pc example. similar to the book OpenGL ES 2 for Android: A Quick-Start Guide :D
I've taken assembly language courses before, and this is somehow the first time it's "clicked" how it works.
I watched your whole serie in 2 weeks. I have to say that your tutorials must be the best on electronics on youtube. It's fantastic how you explain everything from the most basic to something so complex and not get us bored. I will defenantly be trying this out after my panhellenic exams.
Yes! A new part in the series. After binge-watching the series two weeks ago, I started building my own. I am almost halfway and awaiting the final parts from China. Thank you @Ben Eater for the great videos and the inspiration. You rock!
Dear
Ben, am now desperate for last videos. Please post asap. Fear life can't go on
without the final pieces of the jig-saw.
Seriously, I’ve been in IT since 1970. I first worked on IBM’s
360 range of computers - pre virtual-storage. I’ve always ‘known’ (or more precisely
- was ‘taught’) that computers were made, essentially, from transistors
used as fast low-power switches. But I had never known how. This series of
videos has closed that yawning gap in my understanding. I can’t thank you
enough. Strange that the control word does not do ‘anything’, simply opening
and closing various pathways to and from the bus. Fascinating.
Thanks!
You should make a microopcode o reset the counter at the end. Therefore different insrructions will use a different amount of clock cycles. The microopcode that resets will take no time.
This was also my idea, but there's one caveat: This requires yet another control line...
Hi,
I have just found your channel via a forum link and must say, I am extremely impressed by your skill to explain everything in a really slow but interesting way. And everyone can understand that :D
Keep up the good work and thanks for the videos :)
Can't get enough of this tutorial, Ben! Kickass teachings which have me checking back for the next video often
After watching the video series non-stop in the past a few days, I finally decided to build one myself.... Thanks!
I have been watching the breadboard computer serie during a couple of days. This is the best explanation I´ve ever seen and heard on how a computer works! Thank You ever so much for uploading.
Another cliffhanger! Thanks so much for these Ben, really enjoying them.
You're awesome. I did all the theoretical stuff in school and work as a programmer now but after watching your project so far I can honestly say I understand the principles of a CPU. Thanks!
This is truly amazing. I studied all of those things back in the mid 80s but haven't seen someone actually built it and explained it this way, fancy explanation of how it works step by step. I can imagine the work Steve Job and Woznick have invested to build their first computer.
Just got done binge watching the series... This is better than Netflix! I'll be anxiously awaiting the next video in the series :)
Thank you for guiding me forward. I am making a 12 bit version of your computer on Minecraft. Your explanations helped me get here thank you.
YES! I just found your channel and started binge watching this entire series yesterday and finished the last video about an hour ago and was so sad. Then, as I was explaining the series to my wife I go to show her one of the videos and see this! Perfect timing!
This is a brilliant, informative course of videos. I'm actually started to build this, it's a great demonstration of what you can make with 'glue' logic..... and flashing LEDs!
That is just great! A few months ago I started writing some low level code(X86 assembly), and this videos opened my mind even more! Good job, can't wait for an update!
I really like your videos. It helps understanding what's going on in a cpu. It's really inspiring. I can't wait to see the new videos. Keep it up!
Hi Ben, what a great set of video's! Can't wait to see the final one on the control. Unit!
Oh, I have been waiting so patiently for this! I can put off sleep for another video from Ben.
I'm glad I wasn't the only one thinking we could combine steps 1 and 2!
I loved this series and am going to try and build this myself. I have always wanted to get into breadbording and as I have a good background in programming assembler as well as other languages this will be great to relearn the basics of computer operation at this level. I was taught very early on the structure and logical operation, but never the electronics that went to support this. Thank you for a great series. I will let you know how I get on...
Why are there 5 dislikes?!! You are so good at explaining everything and teaching us electronics. Who would not like that?
You have taught me so much!
Thanks Ben! it's all coming together. My breadboards are quivering in anticipation of a control logic section. With your video's I now have enough information to get it all wrapped up. Great work - keep em coming.
I am, though, going to setup a microcode that "resets" the micro instruction counter so that I don't have to wait for blank micro instruction cycles.
I am also thinking about setting up a hash table that allows me to compress my microcode memory in the EEPROM. Basically, without that, each microcode takes up a specific section of EEPROM memory. Not really a problem, since our instruction set is going to be small (mine instruction words are 8-bit, not 4), but from a design perspective, I like the challenge of "compressing" the microcode translation table so that I can tell the decoder where to find any microcode that I want.
On my instruction register, instead of the LS245 + 8 bits, I used a LS373 as the storage, and bus interface. Simplified things quite a bit - and was a challenge to design a different way to handle registers. :)
Also, I setup my system to use a single chip 256Kbit ram chip - so I am thinking of providing "paging" instructions as well just for fun. With your EEPROM instructions, handling a RAM chip with I/O pins ended up being not too much of a problem.
Not worth the fuss. Just use a ready-made EEPROM chip, there's plenty of room for microcode.
In an actual CPU design in silicon, you could of course omit some unused memory cells altogether from the ROM matrix to save some transistors or space. But when you already have your EEPROM prefabricated for you, the Universe will not suddenly end if you waste some of the cells ;J But trying to compact the code may make it less regularly laid out and it might require a complicated logic to decode the opcodes into addresses in that ROM, so you will effectively end up with a more complicated and more expensive design :q
I love how Ben's videos often have no dislikes at all.
Aww there is 1 dislike now?
i wonder where that came from? 😈
Syerjchep
Actually it's a psychological behavior.. you see no dislikes, so you feel special to be the first lol
+Truth Seeker yeah, soooo special: "the biggest jerk of the year" sounds like a cool title to have :q
I sometimes dislike by accident, mostly on mobile devices.
11 at summer 2019
I love watching Ben’s videos!
So exciting! We must be so close to a complete computer!
Thanks a lot. This is so fascinating. I could see in the last video how this was all coming together. One of those "Wow, kewl!" moments. I haven't been this interested in electronics since the '70s and early 80s. :) I still have a stack of Radio Electronic magazines from like... 1980ish? Stuff on building robots I loved and there was a series on building a 68000 computer when those CPUs first came out (used in the Amiga).
Dear Ben, we really need the next episode!
Stay awesome
Great work, I am thinking of building my own system, I might start next week doing up a set of schematics for what you have built so far. You are inspiring me to do something for nothing more than sheer fun.
With the microcode counter reset I would not hardwire the reset to a pin of the decoder. Instead if you use multiple eeproms, use data pin to reset the counter. This will then give you variable length instructions so the simpler ones will be faster and if you needed something like indirect memory addressing (I know that is pie in the sky but hey I am thinking of building a similar system to write my own microcode system) then you can take the full 8 or 16 clock cycles if needed.
@6:12 wow that's very smart. This is how micro instructions get decoded. I can image how many decoders needed to decode 35 micro instructions, say for the PIC MCU. That along with the EEPROM and the address input to EEPROM can interpret instructions via the EEPROM memory then execute the proper micro instruction.
I was waiting patiently for this :) great work. You did quite similar to what I was imagining so I feel like a little genius - had no idea how these things actually work before and now I feel like a can build one myself :)
New video! You kept us waiting for part2.
No one or book ever answered such internal operation or connection. it is all some blah blah in book which never tell real story which you have shown, excellent and genius .
I am so, so proud that Ben saw fit to incorporate one of my suggestions (combining instructions, where they don't interfere with each other).
It makes me feel good to know that I've contributed something worthwhile rather than only leeching information like a sponge (not that that's always a bad thing). :)
This video is awesome, you explain things so simple. Keep doing this kind of stuff.
Excellent tutorial. Made me remember my microcomputers class at the university. How would it be great if I could imagine to bring my term project like this on breadboards.
amazing videos and build! really enjoying it!
Wonderful explanation, smooth speaking, beautiful presentation!
I love the way you say "register"
This is very fun to watch.
Just finished binge-watching the whole series. Can't wait for part 3! Like, literally, I cannot wait, I'm going to die of boredom.
Awesome series 😄
Coming with no electricity background and working all the way to this lecture I found that I dont have 74LS138, just few 74LS139 from previous lessons. I feel so happy to work my way how to make LS138 from one LS139 + one NOR gate.
Great video! Thanks for posting. I've been looking forward to this one.
15:02 is about when this thing really started feeling scarily alive to me. It was like a runaway train, but on a very carefully crafted track.
I was doing some small assembly language programs on my Vic20 (back in the day ;-) and now I know what was going on! THANKS!!
Very interesting project. Can't wait for next video. Maybe some similar build with Z80 after this series?
Brilliant :) Very much looking forward to the next installment!
I'm also starting a microcomputer project, partly inspired by this series; I'm very interested to see what you cook up with the EPROM combinational logic, as I suspect I'll be using something similar to solve memory-mapping :)
The information quality of these videos is *too damn high*! I've designed architectures around Intel 8085 on paper in Uni, and know a fair bit of C++ tricks that operate at register level, but your series has made so many things crystal clear I had thought were already crystal clear previously. Well I do only now realise there was a thin veil of mist. Wish paid, institutional education were such high quality as your videos.
Yay! We taught the computer how to fetch! :D
Now it's time to teach it how to chomp whatever it fetched ;)
I think I get it now how it works, but I'll still watch next videos to see it happening ;) (and to see if I'm right).
My EEPROMs already arrived from China, so I can try it out myself before seeing your solution ;>
As for saving cycles, how about resetting the phase counter depending on the instruction? We don't need to wait through 5 steps every time - if the instruction requires less steps, we could reset the counter earlier by asserting the reset signal to it programmatically from the instruction decoder ;)
Nevertheless, after you finish this part of the course, I would like to see you explaining somewhere in the future how to fetch and decode multi-byte instructions (e.g. fetch the correct number of operands following the opcode depending on what opcode it is) and do things like conditional jumps, subroutine calls / returns etc.
I just can't wait for the next part!
YEEEEES! Another Ben Eater 8 bit computer video XD
i understand now why my grandpa would always talk about gigantic computers on walls its because to give data they couldnt store it in smaller sizes and as an example this cpu you have might be the size of one back then because of the problem of the size of data storage
Wouldn't you be able to set an end flag for each instruction which tells the cpu the command has finished and the counter should be reset? it would add a step to each command but would allow you to write longer instructions but not have to count to the max length each time
I wonder if this could be merged with microinstruction jumps...
The "end" microinstruction is like an unconditional jump to the first (0th?) phase of the cycle. But perhaps it could be extended to jump to other phases as well? E.g. to skip the part which fetches the operands when there is none for some opcode, or jumping to different alternate routes for different addressing modes, or repeating some sequence of instructions in a loop (think multiplication/division implemented as repeated addition/subtraction in the ALU).
+Sci Twi It's easier to make separate "load" instruction and just don't use it when it don't needed)
Multiplication and division is a separate topics, becasuse there's special algorythms for these operations (it takes lots of time as repeated addition/subtraction). I think Ben will tell us about it later.
Brilliant! It's getting increasingly harder to comment on your videos Ben, because I'm running out of superlatives. ;-) Thanks!
Start inventing new ones, like my friend Pinkie Pie ;)
E.g. her recent invention: "rooftastic" :) "As in, I'm gonna stand on the roof and yell to everypony how rooftastic this is!"
;)
my brain feels like it's expanding after watching his videos..
You can make it variable microinstruction by having a control line to reset the microcounter at the last decode. For example, if we call it RC (reset counter), then LDA would be:
co mi
ro ii ce
io mi
ro ai rc
Haven't seen your other videos yet, but figured I'd throw that out there if it doesn't come up and I forget to say something later.
That might not work as when you do the RC as part of RO and AI the EEPROM already is back to CO MI. So do the RC on separate step.
@@topilinkala1594 that comment was 5 years ago, but if i recall correctly, he stored the current state in a latch, so the reset would only affect the microstate. This means it should be loading in the next decode into the latches within the next cycle and microstate being reset means it would begin at 0......I'm not going to rewatch the video, so I might be wrong here, and if so, then what i said should have been the implement in order to make it work, otherwise, sorry.
If you use the reset input on the 163 as a new control line you could program your microcode to reset the counter when any particular instruction is finished. This would mean that each instruction would only take the minimal amount of cycles. It would also allow you to have instructions that take more than 5 cycles without increasing the amount of cycles that all your instructions use.
Towards the end of the video, you were talking about setting the logic counter length based on the longest command logic chain programmed in the system. Would it be more efficient to include a "Logic Reset" signal as the final microcode instruction for each programmed logic command? Tie that signal output to the counter reset signal in the logic circuit? This way any command programmed would take just as many cycles as needed to complete - no need to wait on the logic counter to complete its cycle based on the longest microcode instruction set.
Wow! Dude built a rudimentary CPU responding to clock cycles. I just did one logic gate and thought that was the ultimate.
I can't wait for the next video!!
Any of you guys find that, with the 74ls138, the circuit works better when the 5 green leds are grounded to the circuit? In other words, the green leds would be dark with a moving “on” led vs on at baseline (with a moving dark led) as shown in the video?
Since we already have output module, I wonder how one design an input module and probably the corresponding INPUT instruction. So that we can run an interactive program with this computer.
Would definitely be possible, having an input enable instruction that can read the input and put it on the bus.
Programming that in would be the more difficult part, seeing how with this build, we only have 16 addresses to work with. Would be doable yes, but there isn't much you could actually interact with.
But, then again, this build is just to learn the basics. If you ever wanted to expand, you could use this as a good guideline. I've certainly learned a lot from watching.
the book this computer came from had a 2nd design that added the input hardware, lots more RAM, and a BIOS ROM.
It would probably be possible to make something very similar to the RAM programming interface with a series of switches; beyond that you just need the logic to control when the values are put onto the bus and it works just like any other module in the computer. I imagine the limit to practicality (probably not a real concern, given the nature of this build as a teaching tool instead of a purely functional one) would be that it's hard to program values quickly. If you expanded it you could create a module that would store several values and read them in sequence each time a value was read, but then you'd essentially design a different RAM/ROM module.
Definitely a useful exercise to build any of such inputs though. Handling pauses (halt/unhalt) waiting for input could also be important.
All you need for an input mechanism is a DIP switch and a tri-state buffer to select whether or not to put the switch state onto the bus, which would be loaded into the A register by the IN instruction. Given the tiny 16-byte address space, you really can't make any practical programs for this computer, but you could demonstrate that you are actually reading input by writing an Count-By-N program that repeatedly adds the input value to a memory location and outputs the value to the LED display:
0x0: ldi 0x0
0x1: sta [0xf]
0x2: out
0x3: in
0x4: add [0xf]
0x5: jc 0x0
0x6: jmp 0x1
Thanks for the link! Been trying to find a PDF for a while now.
2 years late to the party, but would it be worth having the microinstruction counter reset by the EEPROM as well? Some of those instructions only have a few additional cycles, it would seem like a grand ol' waste to just pulse the clock and have it do nothing.
Another year later to the party:
Later in the series he used the last available dataline on the EEPROM for updating the flags register and even mentioned this idea. So you'd need another EEPROM because of the lack of free datalines on the first two EEPROMs. I think you could still nor the entire control word together and feed that into the step counter.
You could also get rid of the whole demultiplexer, because each instruction already ends "on time".
@@uklu Yeh, I think I saw that one after this comment. In the end he made it reasonably efficient if I remember correctly
6:38 where do you get those nice datasheets? I had to use one for the 74LS138 in my eletronics class, and it was the worst one the teacher could find, there was no clear view of what port did what like yours
Great video, can't wait for next parts. The computer is almost finished. Will you hook it up to a keyboard for easy programming?
I found you through Jameco. Awesome.
You electrically combined the CO and MI signals, so when the IO MI step is to be implemented, the CO signal will also be raised.
I think it was necessary to connect CO and MI on separate inverters.
Михаил Кулагин you should consider all wires "looking ugly" temporary
I know there is still more to go. But in the future it would be cool to look at how we can optimise the system by doing calculations on the falling edge of the clock.
i really like this video series.
I was thinking would it be possible to have the master reset of the micro instruction counter as part of the control word. When the instruction is done after T3 like OUT it could reset the counter on T4? That would allow for variable instructions with 4 till 16 microinstructions
I was wondering how you could reduce the micro-code length of the ADD instruction further... Merging CE with RO and II reduced it from 6 micro-instructions to 5. I was asking myself whether the last ADD microcode could be merged with the first microcode of any other next instruction. That would mean, merging EO + AI with CO + MI, effectively bringing the number of maximum micro-instructions down to 4.
Obviously, there would be conflicting bus usage. But given that CO is seemingly used exclusively with MI (maybe not actually, I don't know the whole instruction set), what if there were a secondary bus going directly from the PC to the memory address register? Would that be feasible? I'm sure it would also be cumbersome to implement this last micro-instruction overlapping onto the next instruction in the control logic.
Even though this computer isn't built for speed, this could mean a 5/4 speed increase to the whole computer, which isn't negligible. That is unless Ben Harper's suggestion of having the EEPROM controlling the reset for the instruction conter cycle is implemented. Also, there may be other instructions in the instruction set which need 5 micro-instructions or more.
Is this a valid suggestion? I'm not sure what I'm talking about, so I'd be interested in having the opinion of someone who does.
Maximilien Tirard An easier way to save a cycle is to speculatively load MAR in T1. All the memory access instructions load it from the instruction register during T2, that is the value on the bus in T1, and instructions that don't access memory don't care what's in MAR. This is speculative execution, and the cost is extra RAM activity when memory access is not done.
Smart! That's really neat! But wouldn't that cause issues? So you are saying that during T2, when II is reading from RO, MI can kind of steal the value as it's there on the bus, because it's just going to be read from IO in T3 anyways. I was thinking to myself that this could cause a problem, but no! All these latches are edge triggered! II and MI latch on very quickly on the rising edge of the clock, much faster than it would take for the RAM chip to read the new value. If they weren't edge triggered though, this would cause a problem, right? Anyways, super neat suggestion and super neat video!
Lots of things could be improved by adding more data paths. For example, a path directly from the PC to the memory address inputs, bypassing the MAR, would let you fetch an instruction, increment the PC, and load the IR and MAR all in one cycle.
Why not use a falling edge detector rather than an inverted clk since it only gets used once?
where do you get your DIP Switches, the ones I got have too short of leads for a breadboard. At least I only bought 5, however I want to purchase more so any input would be good.
12:29 + 15:10 i sense a cut
if you look at the green lights you can see that it skips to T3/T4 instead of going back to T0
@8:46 As a circuit, it is very simple but as a concept, it is amazing. Is that how the vector IRQ works? Of course depending on the IRQ priority, then different addresses are jumped to. This can create amazing IRQ features assuming we have decent amounts of memory available for all the said IRQs.
As the first three steps for the instructions are always the same, could you put them in the same clock tick?
Hey Ben, do you have plans to add a stack register to support subroutine (jsr/rts) ?
You don't need a stack register, you can have a link register instead.
After having completed the program counter logic. Could you show how to make the computer work with Secondary storage devices?
Any chance we can get a parts list for the computer you built? I'd like to learn and build with this playlist, so it'd be best to order all parts at once.
Just wondering if we could shorten the fetch cycle by making the micro-instructions 2-step:
CO MI
RO II CE
I've got a question. Each control signal is set when the clock goes low because you're using an inverted clock, but couldn't you run into issues because the control signals will be turning off as the clock goes high. For example, lets say I set ram out and register A in high; the value from ram won't be read into register A until the next rising clock edge, but as the clocks edge is rising, the control signals are being turned off because they are running on the inverted clock. What happens if the control signals are turned off before the value can be latched into register A?
There are so many easy improvements you could do, like resetting the counter early, b register out, turning the AU into an actuall ALU (bitwise or/and/xor, ror/rol, and use a multiplexer to select the output with only a few control lines), splitting the instruction register into two bytes for more address lines (not _as_ easy if you want to do it efficiently), but I'm almost glad that you didn't do those things. It really motivates me, and I think a lot of other people to try these things out for ourselves and have fun with it!
And also buy your product in the process
It's all part of your plan :P
God I love this channel
very great tutorials!! if you use harvard architecture, i think you can double the speed, no?
Great video
so it basically works like the output display multiplexing-wise? So you write a micro-instruction library with those related to one instruction have a common address number and the counter does the rest?
I love this video series. I'm confused about the use of the demux though. You could put all of your microcode into one ROM (assuming enough data bus width) by using the T-state counter as the low four bits of the microcode address, and the content of the instruction register as the high four bits of the microcode address. I can't wait for figure out why you're demux-ing the counter. One ROM per instruction seems inelegant. If you used ROM's with inadequate data bus width, you could just address multiple ROMs in parallel to gain enough bus width for the control bus, but the multiple ROMs wouldn't be enabled independently so no demux-ing would be needed there. I also feel like incrementing the instruction counter should be the last thing that non-jump instructions do, instead of the first thing that all instructions do. For example, if the program counter is 0x00 and I do a reset, I expect the first instruction executed to be the instruction stored at address 0x00, not the instruction stored at address 0x01, as your current microcode would do. Similarly, if I jump to address 0x80, I'd expect the next instruction executed after the jump itself, to be the instruction stored at address 0x80, not the instruction stored at 0x81. Maybe I misunderstand something.
As the control logic isn't implemented all I can do is guess, but the demux might just be a visualization tool as the 3-pin version would be perfectly suitable to use in the control EEPROM circuit. So you need 4 lines in for the instruction register and 3 lines in for the microinstruction counter (using an un-demuxed version), and enough EEPROMs to make up your control word width (24 bit control word, 3 8-bit output EEPROMS).
Because the Counter-Enable is activated before the instruction specific code is executed, a reset or jump would update the Program Counter after it's increment and behave as expected (reset would set it to zero, jump would go the the specified address). For instance a jump could be T0 - Program-Counter to Memory-Address, T1 - Memory-Out to Instruction-Register-In + Counter-Increment-Enable, T2 - Address-Register-Out to Program-Counter-In, T3-T6 - No-op/Reset. After execution the Program-counter is your desired value and the cycle starts over.
For the counter increment logic, I understand that reset/jump will update the PC after its own (earlier) increment, but the instruction at the target address will ALSO increment the program counter before reading the opcode. So assuming we're at PC=0x0 at T-0, and that the instruction at 0x00 is a "LD 14", the decoding for our instruction will increment the program counter to 0x1 BEFORE it reads the "LD 14" opcode. So the program starts with the instruction at 0x1. Jumps will work similar. Your jump instruction to address 0x8 will put 0x8 in PC, then as part of decoding that address it will again increment the PC to 0x9 before fetching the opcode at 0x8. Jumping to 0x8 will never run the opcode at 0x8, and resets will start at 0x1. Is there a flaw in my reasoning (it is really late after all)?
This is actually what I have done in my build. I'm using only 2 ROM's for the control matrix. The lower 3 bits are made up of the un-demuxed (I don't even have the demux at this point, its on order) T state counter and the upper 4 bits are the instruction bit pattern. I put both of these together to come up with a 7-bit address that looks up the control sequence. One ROM is for 8 of the control lines, the other ROM is for the other 8 control lines. Both ROM's are addressed at the same time.
I think I understand what you mean now (although it's late for me too certainly). The program counter is read in T0 then incremented in T1, the incremented value isn't re-read until the next instruction cycle so the change won't affect memory read that also happens in T1. So during T0 you read the PC into the memory address register, then during T1 you read memory using the stored value, not the live value from the PC.
In some bad pseudocode:
From power-on/reset
//PC = 0, T=0
MemoryAddress = PC
T++ // T = 1
InstructionRegister = MemoryValue
PC = PC + 1
T++ // T = 2
...then opcode specific stuff happens.
So the PC value is stored before being used so any updates to the counter after T0 won't change which value/opcode is loaded from memory during T1.
Ben: Oh, yeah. Thanks for that explanation Ben. That makes a lot more sense now! I went back and rewatched part 1 where he explains the use of the CE vs the MI control lines.
Gerald: To make micro-instruction programming easier, I wonder if you can reduce the number of required control signals from the ROMs until only one 8-bit ROM is needed by demux-ing the various bus inputs together into only 3 ROM data bits and bus output enables together using another 3 ROM data bits (since only one thing can output to the bus at once, and presumably it is only useful to input one thing from the bus at once). That alone isn't enough demux-ing to reduce the control signals to 8 bits, but maybe there are some others that can be combined similarly. E.g. if you never need to input enable and jump at the same time, you can run the J control signal though the "inputs" 3-to-8 multiplexer. Similar logic could apply to halt, possibly.
can you tell me how this 8bit computer compares to say something like the Intel 8080?
You could have the counter count all the way up to 15 so you can have more complex microcommands (with more steps) and have a microcommand that resets the counter witch will be the final one in each command. Right?
anyone else having trouble with the ls173 on the instruction register resetting without having to go high, the pin seems to stay high and after pullinh reset pin from ground resets this chip. because of that when trying to hook it up to the 74ls00, the reset ic doesnt seem to work.