The code from this video is on GitHub: bit.ly/2sK7Qlb More 8-bit computer: eater.net/8bit Support me on Patreon: / beneater www.eater.net / ben_eater / beneater
Ben, you're videos are fascinating! When I was in college back in the 80's, I worked with a Data General computer which had user-configurable microcode. I believe the microcode word was 56 bits long. One assignment we had was to create a "new" instruction. I wrote a "bit reverse" instruction to speed up FFT calculations. Anyway, thanks again for sharing these videos. Anyone who really wants to learn how computers work at the lowest level should watch your videos.
Fantastic! Happy Friday. Ironically, I had just finished modifying the EEPROM Programmer code to load the microcode. This version is 10000 times more elegant and ingenious. Thank you once again!
Maybe the reason he did that Arduino thing was to then be able to add functionality, the computer was already working. He will probably do it very soon.
I and others have been saying this for about 5 videos. It's seems like he's setting us up for some kind of reveal or plot twist haha. I'd be surprised if it isn't this refinement tho. He already showed that he reads the comments when he tightened up the fetch cycle from 3 clock cycles to 2, directly siting comments as inspiration. He also stated that you could refine this aspect but it will be done in the future.
I was thinking the same, but then I realized that if he wants any kind of conditional jump, that'll need another control signal. So, he might implement a branch if zero instead of trying to optimize.
There is a way to add this signal without the need for another EEPROM: just add a 4-input AND gate on some of the control lines that usually cannot be turned on together, and let this signal be the "next instruction" signal that will reset the ring counter. So to reset the ring counter, one would simply output all these control signals together to activate the AND gate. Problem solved ;)
Been going through the build playlist. Excellent series, excellent tutoring, and excellent videoing skills. I was just thinking recently that I wish I knew of a tutorial that explained code -> assembly -> machine language. And voila, UA-cam magically delivered. The wonders of computers. Thanks for the video series.
Thanks for these videos. I love coding but never understood how instructions were literally created and programmed. You have solved a mystery of mine that has haunted me for years. Keep the videos coming, they are wonderful.
Another brilliant video. Thanks! Every time you program this computer I always feel a good improvement would be a hex-based keypad of sorts like they e.g. used on the MOS/Commodore KIM-1. :)
I was literally just sitting here thinking about how I can't wait for the next video. I've just started about a month ago and my computer is caught up with the videos :)
Instead of splitting the RAM at address bit 7 you could have split it at address bit 0. That way you'd be storing 16-bit values for the control words into adjacent bytes. In hardware you'd then shift your address inputs one bit to the left and then tie the LSB either low or high depending on which half of the EEPROM you want to use. That'd give a more pleasing layout of data in EEPROM. :-)
Nice video! I have to say all this series is very very good. No matter how long every video is, I watch them start to finish with all my attention :) Do you have any future ideas for the project? How about designing and etching a PCB for it and then a nice enclosure with good-old rocker switches? I'd love to see that :) Keep up the good work!
Luke, Ben enunciates clearly, so I usually watch his videos at 1.25 speed -- still clearly understandable speech. It just takes just over 20 minutes to watch a 30 minute video.
This is nice! I ended up making a permanent version of a chip burner based on this circuit, but ended up using an arduino mega to replace the address shift registers - thankyou again for the inspiration! :) One small thought for this circuit... if you used A0 instead of A7 for the chip identity, you would have 16-bit words for each instruction in your eeprom readback. Doesn't affect the circuit but thought it might be worth sharing :)
splitting program code (static) and memory (volatile) could be advantagous in the sense that you can just pop in an eeprom in as a 'cardridge' with a program preloaded.
You could use the four "data/address" bits from the opcode to distinguish HLT from OUT (and other instructions that need no data). This will leave more instruction codes for other functions.
Thanks Ben. For your next project, may I suggest expanding the RAM to at least 256 bytes and add on a serial receiver module to the bread board to boot load a program from Arduino to directly into RAM, so that we could remove the programming DIP switches. Bootloading would be handy whenever resetting power to the CPU.
256 bytes of address requires 8 bits of address line. given 4 bits for instruction that is 12 bits for instruction? Probably not probably 16 bits. So you need to expand all buses and registers to 16 bits or fetch instruction in multiple takes. anyways you get 256 bytes / 2 bytes per instruction, that is 128 instructions. that is better but is is good enough?
Not necessarily. The 8-bit address bus could be shared with the 8-bit data bus, it just have to be multiplexed. The fetch cycle will get more complicated, because it would have to load the 8-bit opcode first, then the 8-bit operand (if there is any), and the opcode would probably have to be latched in some instruction register, but at least the bus will stay unchanged. We could even expand the address space to 16-bit by adding some latch register to the memory module and latch up one half of the address in it, then assert the other half of the address on the bus. But it totally could be done. Actually, a similar trick is used in 8502 microcontrollers - they use 16-bit addresses, but they share half of the address bus with the 8-bit data bus, so they have to latch one half of the address in a register outside the chip.
Or without much of a redesign, keeping the same 4-bit opcode and 4-bit address system, you could just add another 15 pages of RAM and introduce a page selector.
Well, there's not much space for all those additional instructions if we can have only 16 of them, and 5 are already taken :q Most importantly, we need some jumps, because without them the computer is not even universal yet - it's more like a programmable calculator than a universal computer. But even if we add jumps, the computations cannot be recursive yet since we don't have any call stack. Sure, we could emulate it by doing some fancy arithmetics with addresses in memory, if only we had more memory than the measly 16 bytes :P But adding more memory requires an entirely different format for the instructions. So I think that the most important improvement we need right now is to change the instruction format to 8-bit opcodes followed by optional 8-bit operands. That would extend the instruction space to 256, and the same with address space. (Though a 16-bit address space would be A LOT better :q ). This isn't very hard to do, even with the existing architecture - we just need to use the entire instruction register for an opcode, and expand the fetch cycle so that it made two memory fetches from subsequent addresses, one for the opcode, the other one for the operand.
I know right. I already have a computer engineering degree but Ben's videos blow away any class I ever took and help understanding so much better than that. I'm watching the entire channel from beginning to end and it's one of the most impressive things I've ever seen
I like the idea of making a punch card reader for your machine. I think it would be surprisingly simple. But you have ROM chips. It might make more sense to add an address line so programs can be run from ROM and add dip switches for selecting programs from the ROM.
Another awesome video Ben, many thanks! I kept thinking of the old joke while watching this - "There are 10 kinds of people in the world, those who understand binary and those who don't" My home build is following along when I have time - I'm trying some modifications to give 8-bit addressing for RAM (and an 8-bit Program Counter). Currently working on the RAM module which is using a 256Kbit (32K x 8) SRAM chip - it's overkill but the smallest I could easily find to buy. The main difference for me is going to be the requirement for 2-byte instructions (1st byte instruction / 2nd byte operand or address) but I *think* I've figured out how to do this in the microcode with two CE signals per instruction on different microsteps. Guess I'll find out when I get to that bit! I did get stuck on the EEPROM programming for a while, my 28C64 EEPROMs (again the smallest I could easily source) didn't like your original programmer code so I had to write Arduino code that more closely matched the datasheet timings to get EEPROM writes working reliably. At least having the extra EEPROM address space meant I could have both decimal and hex in unsigned and signed on the 7-seg display. If anyone else is having issues with writing to larger (e.g. 28C64) EEPROMs I'm happy to share the circuit & code. And again, thanks to Ben for such an amazing series, learning so much!
I'm doing exactly the same thing👌 unfortunately I'm Still building mine so I can't help you yet. I'm sure that we aren't the only one's who are doing this tho
jaxey As soon as I catch up to speed I hope to modify my build to have a 16-bit address bus. So I'll have a desperate address bus and data bus. What RAM chips are you using specifically? Are you planning on adding ROM for program space?
I'm attempting to use the LY62256 for SRAM - (www.farnell.com/datasheets/1674430.pdf). Main issue is that in common with most parallel SRAM modules I can find they use the same pins for input and output which means a bit of a redesign from Ben's memory. I'm trying using 2x tristate buffers (74LS245's) so that I can still have LED output for the current memory data and not collide data inputs with current bus value (or bypass the 74LS157 multiplexors on the data lines). I *think* I've got a design pattern that's going to work now, but involves manipulation of the WE and OE lines to the SRAM combined with the control signals (RI/RO, program/run mode and program button). My next step will be to (re)build the module and see if it works. If anyone else is using SRAM with Ben's project and has had to cope with combined input/output pins I'd be interested to know what you did / how you addressed the bus output 'bypassing' the 74LS157's when connected directly.
To answer the ROM part of your question - possibly, although I think it maybe easier to have an external programmer (e.g. similar to the Arduino EEPROM programmer) configured in a way that it can write values directly into SRAM to load the program. Shouldn't be too hard with a Nano/Mini or similar on the board (probably with a couple of shift registers again) to have a button that steps through addresses and enters data in each location then terminates. Gives a quick and easy way to load code to RAM without DIP switches and makes it much easier to edit the code. In fact the code would be extremely similar to the EEPROM programmer, just using a 'live' SRAM chip as the target.
I added a RAM expansion to my build using these: www.nteinc.com/specs/65000to65999/pdf/nte65101.pdf www.ebay.com/itm/INTEL-P5101-8-Integrated-Circuit-SRAM-NTE65101-Equivalent/252002271571?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 They are 256*4 bit with separate input/output pins - pretty much exactly the same pins as the 74LS189 except 4 more address lines. And the outputs are NOT negated so you don't have to use inverters on the outputs. Worked great for me.
The last control bit that is open could be used to reset your counter as an optimization. You could still have the clock feed back as you have it as redundancy
If you used the LSB of the EEPROM as chip select, you could program the instructions sequentially. The high byte would go in the odd spaces, and the low byte would go in the even spaces.
I was thinking the sub flag was being set one micro-instruction too late... Outputting the sum into the bus in the same step as setting the sum type seems dangerous. But then I realised the AI doesn’t happen on the rising edge, it happens the whole time the clock is high, so there is plenty of time for the ALU output to stabilise. I love this series of videos. Binge watch continues.
There is a way to save some space in the code. Instead of the ADD command ending in EO|AI and the SUB command ending in EO|AI|SU. You can very simply change it to just EO and change the OUT command to EO|OI.
That only works if ADD/SUB (EO) are the only commands. Adding other commands like MUL/DIV/INC/DEC/AND/OR/etc. may not use the EO control line. Thus, you could have a counter program that is: 0: LDA 15 1: OUT 2: INC 3: JMP 1 ... 15: 0 Here, the INC command could increment the A register by 1 directly, without using the EO control line. Keeping the OUT command tied to displaying the content of the A register makes it simpler to program, as you are not tied to the state of the ALU and the EO contents.
Is there some way you could use some sort of 8 bit buffer to cache both halves of the EEPROM, thereby reducing the EEPROM count by one? The clock edges are at the wrong time, you'd need a microcode clock that was triggered by the clock edge, but it might be an interesting efficiency extension.
I guess if the spare unused bit from the microcode was connected to the reset for the step counter, the instructions could set it to 0 after they'd completed. Saving the extra counter chip, and also executing code faster, as the instructions would only use the clock cycles needed?
Ben, late question by far. Couldn't you have fed another signal into the NAND gate from your control logic that was something like RT or reset time, then had some instruction called something like RMC or reset Microcode or some such? wouldn't save much time for this, but seems like it would be useful for things like NOP or OUT
Totally realize I'm splitting hairs here but Arduino is technically C++ 11 and up, just without the STL properly implemented. This is why you can use lambda functions but Vector doesn't exist, for example.
What you need after you have expanded your instruction set is some program storage, probably using the same method you are using to store your microcode?
I never thought of using an instruction set where each bit of the instruction activates a wire inside the CPU. For my Logisim CPU, I just have the NOP instruction all zeros and have all the bits going to a NOR gate which then causes the PC to increment.
I'm following along making my own version of the data array, but I'm doing it in C++ for slightly nicer syntax and to add compile-time error checking. Specifically, it: * Automatically puts the fetch part of the cycle in for every instruction * Automatically zeros out the rest of all instructions unless you put something there * Automatically zeros out the remaining uops of instructions you do define * Throws a compile-time error if you try to give an instruction too many uops (instead of giving weird off-by-one errors for later instructions) * Throws a compile-time error if one of your instructions leads to contention on the bus * Throws a compile-time error if you write to the bus without reading, or vice versa Since everything happens at compile time you can see the output instruction table in Compiler Explorer's assembly output. And my compile-time error checking was useful; I'd accidentally made the last uop of ADD be EO|AO, which would have caused contention on the bus instead of working. (Version with compiler errors on a bad uop: godbolt.org/g/taKkJB; fixed version: godbolt.org/g/jdCgcQ)
@@danielrhouck Hi Daniel, a newbie here to C and Arduino! The "fixed version" of your code is no more available... do you think you could re-upload it?
Yes, but faster if you're entering values in subsequent addresses. Perhaps a setup with both, using the DIP's to choose a starting address, but then have a button to push to go to the next address. Of course, you could go really fancy and use the arduino :)
+Richard Smith No, he meant a button to move to the next address in memory so that you didn't have to use the dips to maneuver your way around the binary numbers
The idea of programming the 2 EEPROMs the same and just addressing different parts of them to read the 16 bits is genius. However, instead of using bit 7 to select between the left EEPROM and the right EEPROM (first 8 control lines or second 8 control lines), what about using bit 0 and shifting the instruction and step to bits 1-7 (instead of 0-6 like they are now)? This way the left EEPROM could read the even bytes and the right EEPROM can read the odd bytes. Then when your Arduino code reads back the from the EEPROM, each row of 16 bytes would be one instruction (instead of 2 like it is now) with each 2 consecutive bytes being a single 16-bit microinstruction like the way you drew it out in binary on the graph paper.
I guess this way is a little easier than messing with a hex editor but I couldn't get the arduino programmer to work (bad shift regs I think) so I'm using a real EEPROM programmer and messing with a hex editor and BIN files, at the moment I have upper and lower microcode rom files but thanks to the vid I can reduce it to one and have to mod my IR and control board to pull up bit 8
I'm having a problem with the LDA instruction. It doesn't latch it the value. I see it flash for a second but as soon as the clock pulses falling edge hits, it sets to all 0s. Oddly enough, on the conclusion of the ADD function, the A register latches.
Hi Ben, your videos are really instructive...Clear and easy to follow. I have bought the Breadboard kit and almost completed assembling it. Everything works well , including the first addition program till I try to run the control logic with EEPROM!! The sample addition which when done manually works fine ,but refuses to work with the ROMs!! Some of the control signals come on but nothing much happens. I tried programming it with the dip switch based manual programmer and also tried with the Arduino Programer, using the Sketch taken from the github. Is it that the drive voltages from the RPM are insufficient to trigger the parts on? Could you or one of ourfellow enthusiats suggest a possible solution? Thanks in advance.
This sounds like it might be the same issue that has been well documented over on the ben eater sub reddit. Apparently when the EEPROMs switch addresses the outputs are undefined so you get glitches going out on the control lines. Some folks have used judiciously placed pull up/ pull down resistors and low pass filters on the signals to sort it out. See this discussion here: www.reddit.com/r/beneater/comments/ge4l6f/unstable_8bittested_all_the_modules_separately/
Wonderful video, Thank you I dont know in some Cpu related video, I have heard about sequential logic, "sequence of event updated after each clock pulse" kindly if anybody knows let me know.
@19:52 Instead of two separate loops to write the microcode to the EEPROMs, what about just a single loop with two writeEEPROM lines, one with the the right shifted data and one with the 128 address offset?... Pros/cons anyone.
Not to nit pick but as a C programmer I thought I should mention that the binary literals are a nonstandard GCC extension to the c language and are not portable to all compilers.
The second LED from the right of the instruction register flickered at 30:44 while the computer was halted for some reason. Bad connection somewhere? Edit: It died completely at 30:48. Weird.
How about adding an input button that replaces the dip switches and it increments the input numbers on an input display, then having a separate input button to set the address location so that you can see the inputs rather than LEDs/Switches?
I'm actually building a replica here soon, I've got the parts already ordered, so if you don't get the chance to do it I am planning on implementing this on my model and see how it goes.
Now what needs to happen is to get rid of this 70's interface and add the necessary functionality to facilitate a home made keyboard (aka side project to this :P ) then compile a basic language so that you dont have to do binary then add a bigger screen then I hope you you get 10M subs :P
I’m new to all of this, every bit new. Software (computer coding) to hardware (wiring these cables into the breadboards), where do I start? I’m overwhelmed.
Really, that depends on your appetite for learning. As you can imagine, if you really start from zero, there is an absolutely enormous mass of information to ingest. Just for the basic electronic part, there is a LOT to read and understand. Its a good starting point to watch Ben's videos, in the right order (just go on Ben's channel, click on Videos, and scroll down : the videos will appear in chronological order; Start with "Experimenting with LEDs | Digital electronics (1 of 10)", ua-cam.com/video/poWJTSV4Yio/v-deo.html&ab_channel=BenEater You can also do some Google Searches to get the basics : Ohm Law, to begin with. Then, some good book on electronic for beginners will help as well. You can experiment with free online tools, to build virtual cuircuits and understand what happen; You can play with www.falstad.com/circuit/ and with TinkerCad : www.tinkercad.com/dashboard
Whilst the generalizations are easy to follow ..how actually do the electrons know what to do when RAM is 'read' .I don't actually expect an answer :) Normal non software circuits make sense.
I noticed sometimes when not programmed correctly (during testing) you have multiple output enable signals high, which means more than one module is outputting on the bus. Doesn't this create short circuits that could be harmful? In the video you don't seem overly concerned. Is this not much of a problem in practice?
If the two or more modules output the same value (both 1 or both zero), this is fine. If they output different values (1 and zero), then indeed this creates a short. And yes it can be harmful. He is not overly concerned because he knows what he is doing and certainyl take care of that. Also, nothing tells you that he did not burn a number of 74xxxx while making the videos, off camera :-)
Why not use a 2D array for the opcodes? That way data[0] points to an array of instructions for the 0th instruction, data[1] points to an array of instructions for the 1st instruction, and so on
Trick question, isn't it? The computing model only has 1D memory, and C's 2D arrays are syntactic sugar for 1D arrays. The memory arrangement is the same. Then we have that the RAM is built in 2D form (with columns and rows) but on SRAMs and EEPROMs like those in this computer we can ignore the boundary between them, and choose any arbitrary split of the address bus (in this case, left or right half of control word, instruction opcode, and instruction step). If the question is about why we have 8 steps per instruction, that's a power of two so we don't need complicated logic but can wire the step count directly. Effectively, if we used a 2D C array for this arrangement all we'd gain is having to put a pair of braces on each line. Might prevent a bug if you accidentally changed the number of entries on a line. The lookup difference isn't an advantage because it's not the Arduino that reads instructions.
how people did that firstly , i cant understand that . How would you do that if you dont have the arduino , microprossesor and arduino ide how people creates microprossesors ?? thats exactly what i want to learn i want to learn the firsts of computer science , is there any resources for that? i am not that old to go to a college
There is no sum bit, that's the subtract bit. It negates the B register and feeds a carry-in into the ALU (sum register), which has the effect of turning it into a two's complement sum of A and (-B), i.e. A-B. Ben describes this much more clearly than I ever could in the videos in this series about the ALU.
on comment more: BEN is a FLIGHTrescue Blackbox with SAFTY memory called EEprom a FLIGHTrecorder a serial DATAstream on MAGnetic based or LIGHTinstruction or both ?? SIMulator Software told us to make saftCARE your KI IQ with HANDS or Fingers on ESD or WATERprof Material why HARDcoded???
It is actually wrong to say that you are "erasing" the EEPROM when you are just byte-wise writing FF to each location. With these modern EEPROMs that step is unnecessary and just means that you are writing FF to a location. Whenever you write a byte in the chip the automatic logic sequence inside the chip is actually erasing and writing that byte. The whole concept of "erasing" comes from the old first generation EEPROMs, where you actually had to fully (or sometimes in smaller sectors) erase the contents, with a separate operation than a write, before you could change the contents again.
Did I finally learn what microcode actually is? Wow, that took a while, damn that's way simpler than I thought.
You are like the Bob Ross of computer science.
Happy little typos
Happy little glitches, and let's beat the devil out of this chip :q
we don't make bugs, just happy little features.
Well, this is actually computer engineering.
@@micycle8778 I'd argue more electrical engineering given how 8-bit machines are a little bit dated
Ben, you're videos are fascinating! When I was in college back in the 80's, I worked with a Data General computer which had user-configurable microcode. I believe the microcode word was 56 bits long. One assignment we had was to create a "new" instruction. I wrote a "bit reverse" instruction to speed up FFT calculations. Anyway, thanks again for sharing these videos. Anyone who really wants to learn how computers work at the lowest level should watch your videos.
Fantastic! Happy Friday. Ironically, I had just finished modifying the EEPROM Programmer code to load the microcode. This version is 10000 times more elegant and ingenious. Thank you once again!
Absolutely love this series Ben - always a little bit of a mental stretch and learn something new but building upon your other vids.
You can use the last control world bit as a "last microinstruction" flag, the microinstruction counter will then be resetted the next clock cycle.
^-- This. I was waiting for him to do that, but it never happened.
Maybe the reason he did that Arduino thing was to then be able to add functionality, the computer was already working.
He will probably do it very soon.
I and others have been saying this for about 5 videos. It's seems like he's setting us up for some kind of reveal or plot twist haha. I'd be surprised if it isn't this refinement tho. He already showed that he reads the comments when he tightened up the fetch cycle from 3 clock cycles to 2, directly siting comments as inspiration. He also stated that you could refine this aspect but it will be done in the future.
I was thinking the same, but then I realized that if he wants any kind of conditional jump, that'll need another control signal. So, he might implement a branch if zero instead of trying to optimize.
There is a way to add this signal without the need for another EEPROM: just add a 4-input AND gate on some of the control lines that usually cannot be turned on together, and let this signal be the "next instruction" signal that will reset the ring counter. So to reset the ring counter, one would simply output all these control signals together to activate the AND gate. Problem solved ;)
Been going through the build playlist. Excellent series, excellent tutoring, and excellent videoing skills. I was just thinking recently that I wish I knew of a tutorial that explained code -> assembly -> machine language. And voila, UA-cam magically delivered. The wonders of computers. Thanks for the video series.
Just mind blowing, really easy to follow, your videos actually helps me (open up) new world for me.
Well tonight for the first time I loaded in the entire program and also got 4 as my output! Awesome stuff!
Thanks for these videos. I love coding but never understood how instructions were literally created and programmed. You have solved a mystery of mine that has haunted me for years. Keep the videos coming, they are wonderful.
Another brilliant video. Thanks! Every time you program this computer I always feel a good improvement would be a hex-based keypad of sorts like they e.g. used on the MOS/Commodore KIM-1. :)
I was literally just sitting here thinking about how I can't wait for the next video. I've just started about a month ago and my computer is caught up with the videos :)
branden bass I read the comment ... then see your profile pic XD... well done!
Can't wait to see an assembler build for your machine!
I love bitwise operations! This is an excellent demonstration of how they can make your life so much easier.
this is the best expanation of 1 vs 2's complement I've seen yet, and the implications of each!
Instead of splitting the RAM at address bit 7 you could have split it at address bit 0. That way you'd be storing 16-bit values for the control words into adjacent bytes. In hardware you'd then shift your address inputs one bit to the left and then tie the LSB either low or high depending on which half of the EEPROM you want to use.
That'd give a more pleasing layout of data in EEPROM. :-)
Nothing gained by redesigning the code though.
This is pure gold.. Thank you Ben.
Nice video! I have to say all this series is very very good. No matter how long every video is, I watch them start to finish with all my attention :)
Do you have any future ideas for the project? How about designing and etching a PCB for it and then a nice enclosure with good-old rocker switches? I'd love to see that :)
Keep up the good work!
Luke,
Ben enunciates clearly, so I usually watch his videos at 1.25 speed -- still clearly understandable speech.
It just takes just over 20 minutes to watch a 30 minute video.
Fantastic. Many Thanks to Ben, the murky waters of computer science made shiny and clear!
All 40 videos are very interesting!
I really hope that I'll wait when you connect the display (or monitor). Sorry for my English.
Love your work, keep going 🥇🏆
This is nice!
I ended up making a permanent version of a chip burner based on this circuit, but ended up using an arduino mega to replace the address shift registers - thankyou again for the inspiration! :)
One small thought for this circuit... if you used A0 instead of A7 for the chip identity, you would have 16-bit words for each instruction in your eeprom readback.
Doesn't affect the circuit but thought it might be worth sharing :)
love the idea to program both parts identical
I LOVE ALL OF BEN'S VIDEOS!
This is such an amazing video, thank you.
Great bit (!) of weekend fun. Thanks! Super cool!
Your editing is perfect.
splitting program code (static) and memory (volatile) could be advantagous in the sense that you can just pop in an eeprom in as a 'cardridge' with a program preloaded.
Plus more storage
Superb Ben, thanks....
You could use the four "data/address" bits from the opcode to distinguish HLT from OUT (and other instructions that need no data). This will leave more instruction codes for other functions.
25:43, gotta love that *SNAP*
Thanks Ben.
For your next project, may I suggest expanding the RAM to at least 256 bytes and add on a serial receiver module to the bread board to boot load a program from Arduino to directly into RAM, so that we could remove the programming DIP switches. Bootloading would be handy whenever resetting power to the CPU.
256 bytes of address requires 8 bits of address line. given 4 bits for instruction that is 12 bits for instruction? Probably not probably 16 bits. So you need to expand all buses and registers to 16 bits or fetch instruction in multiple takes. anyways you get 256 bytes / 2 bytes per instruction, that is 128 instructions. that is better but is is good enough?
Not necessarily. The 8-bit address bus could be shared with the 8-bit data bus, it just have to be multiplexed. The fetch cycle will get more complicated, because it would have to load the 8-bit opcode first, then the 8-bit operand (if there is any), and the opcode would probably have to be latched in some instruction register, but at least the bus will stay unchanged. We could even expand the address space to 16-bit by adding some latch register to the memory module and latch up one half of the address in it, then assert the other half of the address on the bus. But it totally could be done.
Actually, a similar trick is used in 8502 microcontrollers - they use 16-bit addresses, but they share half of the address bus with the 8-bit data bus, so they have to latch one half of the address in a register outside the chip.
Or without much of a redesign, keeping the same 4-bit opcode and 4-bit address system, you could just add another 15 pages of RAM and introduce a page selector.
@@scitwi9164 If you read the computer architectures book it digs into this. It's cool!
Well, there's not much space for all those additional instructions if we can have only 16 of them, and 5 are already taken :q
Most importantly, we need some jumps, because without them the computer is not even universal yet - it's more like a programmable calculator than a universal computer.
But even if we add jumps, the computations cannot be recursive yet since we don't have any call stack. Sure, we could emulate it by doing some fancy arithmetics with addresses in memory, if only we had more memory than the measly 16 bytes :P
But adding more memory requires an entirely different format for the instructions.
So I think that the most important improvement we need right now is to change the instruction format to 8-bit opcodes followed by optional 8-bit operands. That would extend the instruction space to 256, and the same with address space. (Though a 16-bit address space would be A LOT better :q ). This isn't very hard to do, even with the existing architecture - we just need to use the entire instruction register for an opcode, and expand the fetch cycle so that it made two memory fetches from subsequent addresses, one for the opcode, the other one for the operand.
Covid: Stay home and boring.
Ben: Stay home and learn something!
I know right. I already have a computer engineering degree but Ben's videos blow away any class I ever took and help understanding so much better than that. I'm watching the entire channel from beginning to end and it's one of the most impressive things I've ever seen
This is amazing!
I like the idea of making a punch card reader for your machine. I think it would be surprisingly simple.
But you have ROM chips. It might make more sense to add an address line so programs can be run from ROM and add dip switches for selecting programs from the ROM.
Brravo ! Excellent !
Another awesome video Ben, many thanks! I kept thinking of the old joke while watching this - "There are 10 kinds of people in the world, those who understand binary and those who don't"
My home build is following along when I have time - I'm trying some modifications to give 8-bit addressing for RAM (and an 8-bit Program Counter). Currently working on the RAM module which is using a 256Kbit (32K x 8) SRAM chip - it's overkill but the smallest I could easily find to buy. The main difference for me is going to be the requirement for 2-byte instructions (1st byte instruction / 2nd byte operand or address) but I *think* I've figured out how to do this in the microcode with two CE signals per instruction on different microsteps. Guess I'll find out when I get to that bit!
I did get stuck on the EEPROM programming for a while, my 28C64 EEPROMs (again the smallest I could easily source) didn't like your original programmer code so I had to write Arduino code that more closely matched the datasheet timings to get EEPROM writes working reliably. At least having the extra EEPROM address space meant I could have both decimal and hex in unsigned and signed on the 7-seg display.
If anyone else is having issues with writing to larger (e.g. 28C64) EEPROMs I'm happy to share the circuit & code.
And again, thanks to Ben for such an amazing series, learning so much!
I'm doing exactly the same thing👌
unfortunately I'm Still building mine so I can't help you yet. I'm sure that we aren't the only one's who are doing this tho
jaxey As soon as I catch up to speed I hope to modify my build to have a 16-bit address bus. So I'll have a desperate address bus and data bus.
What RAM chips are you using specifically? Are you planning on adding ROM for program space?
I'm attempting to use the LY62256 for SRAM - (www.farnell.com/datasheets/1674430.pdf). Main issue is that in common with most parallel SRAM modules I can find they use the same pins for input and output which means a bit of a redesign from Ben's memory. I'm trying using 2x tristate buffers (74LS245's) so that I can still have LED output for the current memory data and not collide data inputs with current bus value (or bypass the 74LS157 multiplexors on the data lines).
I *think* I've got a design pattern that's going to work now, but involves manipulation of the WE and OE lines to the SRAM combined with the control signals (RI/RO, program/run mode and program button). My next step will be to (re)build the module and see if it works. If anyone else is using SRAM with Ben's project and has had to cope with combined input/output pins I'd be interested to know what you did / how you addressed the bus output 'bypassing' the 74LS157's when connected directly.
To answer the ROM part of your question - possibly, although I think it maybe easier to have an external programmer (e.g. similar to the Arduino EEPROM programmer) configured in a way that it can write values directly into SRAM to load the program. Shouldn't be too hard with a Nano/Mini or similar on the board (probably with a couple of shift registers again) to have a button that steps through addresses and enters data in each location then terminates. Gives a quick and easy way to load code to RAM without DIP switches and makes it much easier to edit the code. In fact the code would be extremely similar to the EEPROM programmer, just using a 'live' SRAM chip as the target.
I added a RAM expansion to my build using these:
www.nteinc.com/specs/65000to65999/pdf/nte65101.pdf
www.ebay.com/itm/INTEL-P5101-8-Integrated-Circuit-SRAM-NTE65101-Equivalent/252002271571?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
They are 256*4 bit with separate input/output pins - pretty much exactly the same pins
as the 74LS189 except 4 more address lines. And the outputs are NOT negated so you
don't have to use inverters on the outputs. Worked great for me.
excelent video thank you
He's so remarkable, brilliant person I've ever seen.
I hope I can be like him :)
The last control bit that is open could be used to reset your counter as an optimization. You could still have the clock feed back as you have it as redundancy
If you used the LSB of the EEPROM as chip select, you could program the instructions sequentially. The high byte would go in the odd spaces, and the low byte would go in the even spaces.
I was thinking the sub flag was being set one micro-instruction too late... Outputting the sum into the bus in the same step as setting the sum type seems dangerous. But then I realised the AI doesn’t happen on the rising edge, it happens the whole time the clock is high, so there is plenty of time for the ALU output to stabilise.
I love this series of videos. Binge watch continues.
No, that’s not it, is it? It works because the control bits are set half a cycle before the clock edge. The loads do happen on the rising edge.
Thank you
There is a way to save some space in the code. Instead of the ADD command ending in EO|AI and the SUB command ending in EO|AI|SU. You can very simply change it to just EO and change the OUT command to EO|OI.
That only works if ADD/SUB (EO) are the only commands. Adding other commands like MUL/DIV/INC/DEC/AND/OR/etc. may not use the EO control line. Thus, you could have a counter program that is:
0: LDA 15
1: OUT
2: INC
3: JMP 1
...
15: 0
Here, the INC command could increment the A register by 1 directly, without using the EO control line. Keeping the OUT command tied to displaying the content of the A register makes it simpler to program, as you are not tied to the state of the ALU and the EO contents.
@@msclrhd could you kindly rephrase or expand just a little bit about why it's simpler to program? I'm trying to understand your answer :-)
yay bus contention on 22:45
Keep this up, dude
Looking at the dip switches I can't help but think this little guy needs a 3d printed punch card reader!
Hi, I'm enjoying your videos. I would like to know which order to watch them in though.
Your boards looks so neat. I want to know how you do it; mine are a rat nest of cables.
Therez gonna be another bit here that am gonna use in FUTURE VIDEOS at 4:09....that put the hopes high man.
Is there some way you could use some sort of 8 bit buffer to cache both halves of the EEPROM, thereby reducing the EEPROM count by one? The clock edges are at the wrong time, you'd need a microcode clock that was triggered by the clock edge, but it might be an interesting efficiency extension.
I guess if the spare unused bit from the microcode was connected to the reset for the step counter, the instructions could set it to 0 after they'd completed. Saving the extra counter chip, and also executing code faster, as the instructions would only use the clock cycles needed?
Ben, late question by far. Couldn't you have fed another signal into the NAND gate from your control logic that was something like RT or reset time, then had some instruction called something like RMC or reset Microcode or some such? wouldn't save much time for this, but seems like it would be useful for things like NOP or OUT
Totally realize I'm splitting hairs here but Arduino is technically C++ 11 and up, just without the STL properly implemented.
This is why you can use lambda functions but Vector doesn't exist, for example.
What you need after you have expanded your instruction set is some program storage, probably using the same method you are using to store your microcode?
I never thought of using an instruction set where each bit of the instruction activates a wire inside the CPU. For my Logisim CPU, I just have the NOP instruction all zeros and have all the bits going to a NOR gate which then causes the PC to increment.
i hope he adds an oled display or a colored lcd to it, maybe with hdmi or something and magicly lets something appear there with a programm *g*
I'm following along making my own version of the data array, but I'm doing it in C++ for slightly nicer syntax and to add compile-time error checking. Specifically, it:
* Automatically puts the fetch part of the cycle in for every instruction
* Automatically zeros out the rest of all instructions unless you put something there
* Automatically zeros out the remaining uops of instructions you do define
* Throws a compile-time error if you try to give an instruction too many uops (instead of giving weird off-by-one errors for later instructions)
* Throws a compile-time error if one of your instructions leads to contention on the bus
* Throws a compile-time error if you write to the bus without reading, or vice versa
Since everything happens at compile time you can see the output instruction table in Compiler Explorer's assembly output.
And my compile-time error checking was useful; I'd accidentally made the last uop of ADD be EO|AO, which would have caused contention on the bus instead of working. (Version with compiler errors on a bad uop: godbolt.org/g/taKkJB; fixed version: godbolt.org/g/jdCgcQ)
(Added SUB instruction and program assembly: godbolt.org/g/FUhVEa)
@@danielrhouck Hi Daniel, a newbie here to C and Arduino!
The "fixed version" of your code is no more available... do you think you could re-upload it?
@@andreamazzai1969 Sorry, I don’t still have it. Shouldn’t have trusted the link to exist indefinitely, but I did.
add a 4-bit counter so that when you're programming instructions you can just hit a button to step from one address to another.
You mean a button you hold to allow the input value to count up? Not sure if that is as elegant as dip switches.
Yes, but faster if you're entering values in subsequent addresses. Perhaps a setup with both, using the DIP's to choose a starting address, but then have a button to push to go to the next address. Of course, you could go really fancy and use the arduino :)
+Richard Smith No, he meant a button to move to the next address in memory so that you didn't have to use the dips to maneuver your way around the binary numbers
you saved my ass in networking class
The idea of programming the 2 EEPROMs the same and just addressing different parts of them to read the 16 bits is genius. However, instead of using bit 7 to select between the left EEPROM and the right EEPROM (first 8 control lines or second 8 control lines), what about using bit 0 and shifting the instruction and step to bits 1-7 (instead of 0-6 like they are now)? This way the left EEPROM could read the even bytes and the right EEPROM can read the odd bytes. Then when your Arduino code reads back the from the EEPROM, each row of 16 bytes would be one instruction (instead of 2 like it is now) with each 2 consecutive bytes being a single 16-bit microinstruction like the way you drew it out in binary on the graph paper.
You could use highByte() and lowByte() commands instead of shifting.
Exelent
I guess this way is a little easier than messing with a hex editor but I couldn't get the arduino programmer to work (bad shift regs I think) so I'm using a real EEPROM programmer and messing with a hex editor and BIN files, at the moment I have upper and lower microcode rom files but thanks to the vid I can reduce it to one and have to mod my IR and control board to pull up bit 8
It'd be nice to make the first step that has a zero control word resets the step counter... it's a little optimisation but it's an optimisation!
I'm having a problem with the LDA instruction. It doesn't latch it the value. I see it flash for a second but as soon as the clock pulses falling edge hits, it sets to all 0s. Oddly enough, on the conclusion of the ADD function, the A register latches.
That moment when you realize you're sorta writing a compiler without even realizing it
I really love your stuff man. But
I'm stiiiilll
in a dreeeeaaaam
BEN EATER
(dun dun dun duuuuuuuuuuuuh)
Hi Ben, your videos are really instructive...Clear and easy to follow. I have bought the Breadboard kit and almost completed assembling it. Everything works well , including the first addition program till I try to run the control logic with EEPROM!! The sample addition which when done manually works fine ,but refuses to work with the ROMs!! Some of the control signals come on but nothing much happens. I tried programming it with the dip switch based manual programmer and also tried with the Arduino Programer, using the Sketch taken from the github.
Is it that the drive voltages from the RPM are insufficient to trigger the parts on?
Could you or one of ourfellow enthusiats suggest a possible solution? Thanks in advance.
This sounds like it might be the same issue that has been well documented over on the ben eater sub reddit. Apparently when the EEPROMs switch addresses the outputs are undefined so you get glitches going out on the control lines. Some folks have used judiciously placed pull up/ pull down resistors and low pass filters on the signals to sort it out. See this discussion here: www.reddit.com/r/beneater/comments/ge4l6f/unstable_8bittested_all_the_modules_separately/
Wonderful video, Thank you
I dont know in some Cpu related video, I have heard about sequential logic, "sequence of event updated after each clock pulse" kindly if anybody knows let me know.
Well, now I need an arduino... I'm okay with that.
Everyone needs an arduino.
Everyone needs a drawer full of cheap arduino clones.
You need an Arduino, a raspberry pi, some STM32's... then lots of interface chips, then sensors,... it goes on!
I wonder how easy it would be to design a DSL for designing these microcodes.
@19:52 Instead of two separate loops to write the microcode to the EEPROMs, what about just a single loop with two writeEEPROM lines, one with the the right shifted data and one with the 128 address offset?...
Pros/cons anyone.
I don't know if the Arduino C compiler has optimizations, but any modern compiler for x86 would already combine the loops for you.
Mico Roiice
I'll show myself out now...
Not to nit pick but as a C programmer I thought I should mention that the binary literals are a nonstandard GCC extension to the c language and are not portable to all compilers.
can you add a conditional jump like for example "Jump when less than zero" command in your next video?
Out of the frying pan and into the fire
Cool. Is this for the Alto? Is it faster than Assembler?
The second LED from the right of the instruction register flickered at 30:44 while the computer was halted for some reason. Bad connection somewhere?
Edit: It died completely at 30:48. Weird.
How about adding an input button that replaces the dip switches and it increments the input numbers on an input display, then having a separate input button to set the address location so that you can see the inputs rather than LEDs/Switches?
I'm actually building a replica here soon, I've got the parts already ordered, so if you don't get the chance to do it I am planning on implementing this on my model and see how it goes.
ack, the dipswitches!
Should we build an tiny assembler for this?
Now what needs to happen is to get rid of this 70's interface and add the necessary functionality to facilitate a home made keyboard (aka side project to this :P ) then compile a basic language so that you dont have to do binary then add a bigger screen then I hope you you get 10M subs :P
ROIICE sounds like a beefcake talking about his favorite food item
30:36 whats up with the 3rd blue led coming in an out
How can I make a controller that produced the Manchester code? Fm2.
25:50 - Don't you need to erase an EEPROM before programming it?
if I want the EEPROM to have more than 4 bit of instruction, how can I do that?
you are god!!
I’m new to all of this, every bit new. Software (computer coding) to hardware (wiring these cables into the breadboards), where do I start? I’m overwhelmed.
Really, that depends on your appetite for learning. As you can imagine, if you really start from zero, there is an absolutely enormous mass of information to ingest. Just for the basic electronic part, there is a LOT to read and understand.
Its a good starting point to watch Ben's videos, in the right order (just go on Ben's channel, click on Videos, and scroll down : the videos will appear in chronological order; Start with "Experimenting with LEDs | Digital electronics (1 of 10)", ua-cam.com/video/poWJTSV4Yio/v-deo.html&ab_channel=BenEater
You can also do some Google Searches to get the basics : Ohm Law, to begin with. Then, some good book on electronic for beginners will help as well.
You can experiment with free online tools, to build virtual cuircuits and understand what happen; You can play with www.falstad.com/circuit/ and with TinkerCad : www.tinkercad.com/dashboard
Whilst the generalizations are easy to follow ..how actually do the electrons know what to do when RAM is 'read' .I don't actually expect an answer :) Normal non software circuits make sense.
I noticed sometimes when not programmed correctly (during testing) you have multiple output enable signals high, which means more than one module is outputting on the bus. Doesn't this create short circuits that could be harmful? In the video you don't seem overly concerned. Is this not much of a problem in practice?
If the two or more modules output the same value (both 1 or both zero), this is fine. If they output different values (1 and zero), then indeed this creates a short. And yes it can be harmful. He is not overly concerned because he knows what he is doing and certainyl take care of that. Also, nothing tells you that he did not burn a number of 74xxxx while making the videos, off camera :-)
is it possible to save output data to any storage device?
Why not use a 2D array for the opcodes? That way data[0] points to an array of instructions for the 0th instruction, data[1] points to an array of instructions for the 1st instruction, and so on
Trick question, isn't it? The computing model only has 1D memory, and C's 2D arrays are syntactic sugar for 1D arrays. The memory arrangement is the same. Then we have that the RAM is built in 2D form (with columns and rows) but on SRAMs and EEPROMs like those in this computer we can ignore the boundary between them, and choose any arbitrary split of the address bus (in this case, left or right half of control word, instruction opcode, and instruction step). If the question is about why we have 8 steps per instruction, that's a power of two so we don't need complicated logic but can wire the step count directly. Effectively, if we used a 2D C array for this arrangement all we'd gain is having to put a pair of braces on each line. Might prevent a bug if you accidentally changed the number of entries on a line. The lookup difference isn't an advantage because it's not the Arduino that reads instructions.
how people did that firstly , i cant understand that . How would you do that if you dont have the arduino , microprossesor and arduino ide how people creates microprossesors ?? thats exactly what i want to learn i want to learn the firsts of computer science , is there any resources for that? i am not that old to go to a college
I can't imagine opcodes in production CPUs use EEPROMs to map microcodes. Are they done totally using gate logic?
How does the sum bit know how to do a sum? Like, where does it all start? How is the chip coded?
There is no sum bit, that's the subtract bit. It negates the B register and feeds a carry-in into the ALU (sum register), which has the effect of turning it into a two's complement sum of A and (-B), i.e. A-B. Ben describes this much more clearly than I ever could in the videos in this series about the ALU.
on comment more: BEN is a FLIGHTrescue Blackbox with SAFTY memory called EEprom a FLIGHTrecorder a serial DATAstream on MAGnetic based or LIGHTinstruction or both ?? SIMulator Software told us to make saftCARE your KI IQ with HANDS or Fingers on ESD or WATERprof Material why HARDcoded???
It is actually wrong to say that you are "erasing" the EEPROM when you are just byte-wise writing FF to each location. With these modern EEPROMs that step is unnecessary and just means that you are writing FF to a location. Whenever you write a byte in the chip the automatic logic sequence inside the chip is actually erasing and writing that byte. The whole concept of "erasing" comes from the old first generation EEPROMs, where you actually had to fully (or sometimes in smaller sectors) erase the contents, with a separate operation than a write, before you could change the contents again.