Subscribe to see my tutorial-style videos about programming, computer architecture and electronics. I am passionate about building stuff, teaching and sharing ideas with others. I am doing this for fun and as a hobby. I have some technical background but I am in no way a computer expert. The whole point of this channel is about going out there and learning it by doing. I highly appreciate any constructive comments or shared ideas.
Support this channel: www.paypal.me/carstenherting
Пікірлер
I like the off-the-beaten-track approach! It also seems to work very well for you, which helps :P Very cool video, I wish I had the skills to develop such a computer. Best I can do is an even more minimal CPU(-instruction set), because my brain is not big enough for more ;P
Thanks, man. Actually, building it smaller is always more difficult.
Still too complex to most
That's very neat indeed. I love the use of a /single/ dictionary for all kinds of identifiers. That's quite cool !
I just discovered your channel, and I am subscribed. Wow, you work miracles and are extremely knowledgable.
Is there a discord channel we can discuss subjects like this?
There is a discussion section on my GitHub or just plain old email 😀
There is a company called potato semiconductor that sells ttl 7400 series chips that go up to 1 gigahertz. Another guy built a computer called Magic 1, He goes online by the name Bill Buzzbee.
I wonder what happens if i run Minimal 64 on scratch
😁
Squeezing water from stone is a thing. Most of the hydtogen/water on Earth and Mars is locked into various minerals.
Awesome. Just what i needed. I'm using an Arduino to control 2 stepper motors to set a back gage on a 90 to press brake, and needed a simple way to feed the back gage setting for each bend of the steel into the Arduino so it can spin the servos to the right spot. I was going to use a nice touchpad, but found it has no keypad function and the interface to the Arduino is quite complex and the library is huge. This is very simple and compact.
Bit random but is the value of R27 meant to be zero?
Yes, that is intentionally. There are rare cases where the 377 and 161 registers of the address inputs of the control ROMs differ in propagation delay. A nonzero R27 can then be used to slow down the 377 just a tad to avoid switching spikes. Never used it, though.
@@slu467 thanks
Really clever way to solve this, I did several videos on pal/vga out from various small devices, even attiny13a
Wow!
Very interesting. All this must have been one hell of a lot of work, never mind the OS you wrote to run on it! Endless questions... one or two that spring to mind for now: -It would seem your architecture is somewhat 6502-like, but microcode rather than implemented in 'gates'. A compare / contrast might be nice. -Von Neuman vs Harvard architecture in TTL-based computers... I would be interested in your thought process. (Gigatron for comparison?) More... -I see you have the video RAM in the middle of memory, reasoning? I must take a careful look at your VGA implementation... colour..? (as a first thought I wonder if three banked pages for RGB bit planes, multiplexed??) -Audio..? I know, it's meant to be minimal system... but I wonder if an 'I/O waggle' like the PET or a COVOX-like solution might be interesting? -Flash banking for storage... I wonder if there's room to extend that to RAM for > 64k down the line? -Hmmm... microcode stored in flash so the CPU can rewrite it's own 'brain' on the fly... getting silly? I'm going to have to have a good look at this - many thanks!
Thanks for diving into this. VRAM can't start at 0x0000 nor can it end at 0xffff since the Minimal 64x4 uses a zero page and also a stack in these areas. Not that its impossible to have VRAM elsewhere, its just minimalistic. During development, I hung on to the "Minimal" idea for dear life to not get lost in feature creap. Some things like sound can be added through the expansion port, though.
What did you major in university
You are amazing if you can do this with a nano then you can do much with an esp32 wemos d1.Where can I learn about these things for a complete noob ! Self study though. Thanks
Where can I learn about low level stuff like logic gates , data bus and how computers work at hardware level
Try 'Digital Computer Electronics' by A. P. Malvino
@@slu467 Thank you very much.
Just looking at your design, I think you can add some color at a cost of a couple more ICs. If you used two '166. Route the 8 bit data high nibble into one shift register and the low 4 bits into the other. Tie the serial output of one shift register to the Red, other to Green, for instance. You would have to slow the shift to half current speed to stretch the pixels would by twice as wide. Both '166 would have their [E, F, G, H] registers filled with a single byte/Write. You would encode color in the nibble i.e. byte 1001-1110 would clock out of the first'166 as 1011 would be Red, blank, blank, Red while the lower nibble would come out as Grn, Grn, Grn, blank, Grn. They would combine on the screen as Red+Grn, blank + Grn, Blank + Grn, Red +Blank, if I have it right. Of course if you had 4 '166, you could divide the byte up into 4 slices, but I'm not sure you need intensity. You can only get ~14 bits I/O right? It would be nice to change it on the fly with changing the shift out clock to 1/2 or full speed so you could just ignore the extra hardware when you wanted to just do high rez black and white. I think there is a universal shift register, something like a 74LS194, with all shifts output, but it's only 4 bits.
Great to hear that my minimalistic design inspires you to take it into a colorful direction. I like the fact that you keep the highres since it is essential for the editor and stuff.
Wonderful! this is great. I really want to build this and also write an emulator for it so I can test my understanding of the system before the board gets here. Vielen dank!
Wow, this is mot impressive, informative and very interesting.
AMAZING!!!!
I had a thought, after watching this, your 'oddball' and 8-bit battle videos... not sure if this fits in your oddball aesthetic, but you're using eproms already... The ALU could be replaced with a single 16Mbit (1Mx16) eprom (like ST M27C160-50f1 which seems to be still available on ebay for £2... hopefully not fake) the 16 bits from A and B as address ofc, and since it has 20 lines then lookup tables for 15 2-input operations (carry-in as distinct operation), plus up to 256 single-input operations could be encoded with a control line to usurp the address inputs from the B register and connect to outputs from the control ROM instead. This would allow a whole range of 1-cycle math and logic ops to be encoded, plus drastically reducing the cycles for others... I suggest (2-input µops): add, add+1 (carry set equiv.), sub, sub-1 (carry set equiv.), multiply (low byte result), multiply (high-byte result), and, or, xor, shl-double(x1,2,4 bits), shr-double (1,2,4 bits). And then (1-input µops): shl(1,2,3,4,5,6,7 bits), shr(1,2,3,4,5,6,7 bits), sar(1,2,3,4,5,6,7 bits), rol(1,2,3,4,5,6,7 bits), rol-carry(1,2,3,4,5,6,7,8 bits) not, neg, inc, dec... maybe some flag-based variants like inc-carry, inc-z, inc-n, not-n, not-c, not-z, neg-n etc, although these could also be encoded as conditional execution ops (see below). would probably want a wider control eprom, so maybe using 2 16-bit wide eproms like the one above would work? then the total chip count might actually end up less. also, I'm imagining some flag-controlled optional execution variants of some instructions could be good for when only one or two instructions would need to be bypassed by a branch. That wouldn't need any logic change at all, just microcode. but all in all, I'm very impressed by how much you're doing with so little - mostly in microcode, like using the adder for shifts and rotates (encoding logical and arithmetic right-shifts as well might make sense).
a little extra thought - having only 7 lines be usurped from B would allow a complete set of double-shifts to be encoded, with the shld1 op being in the 1-input set, though it's taking one bit from B...
What an amazing & utterly inspiring design! Inspiring because I can see how it could be extended & possibly simplified by a conversion from 8 to 16 bit wide ( or beyond ) registers, data bus & ALU. A 16 bit wide version would make an amazing host for a Forth system. A 32 bit wide version with simple paged memory would make an amazing host for a vintage UNIX clone. A 64 bit wide version could be useful for secure reproducible computing since it lacks any modern speculative execution pipeline in the CPU. The latter two I would consider building as a multi-board CPU using a back-plane for the data bus & control lines. A neo-retro mini-computer revolution!
Your ideas sound great. That is exactly the kind of development I am trying to spark! Although they won't be "minimal" any more 🙂
@@slu467 The 16 bit wide variant would replace LS & MS 8-bit Program Counter & Memory address register with a single 16-bit. Also if you add a MS byte buffer plus toggle to the instruction fetch then you could fit two 8-bit operators in a 16-bit word, with immediate 16-bit operands following the instruction word - saving yourself an instruction fetch on the data bus & getting a massive increase in performance!
The 32 & 64 bit variants I would use the back-plane to host multiple ALUs with Registers & with 2 or 4 16 bit instruction words using 8bits for the instruction, buffered as in the 16 bit variant above , 4 bit to address which of the up to four ALUs is executing - parallel reads & execution , serial write with Memory register increment & 4 bits to address which of ALUs flags is being taken into consideration by the instruction ( Widen control-rom to select logical AND/NAND NOT for multiple flags ? ) The back-plane keeps things separate & simplistic as possible .Program counter + Memory slot #0, Control Logic + IO slot#1, ALUs 0-3 slots #2-#5. ALUs could use jumpers to select which # ALU.
This would need single word buffers for the Instruction fetch, ALU writes & ALU flags. The removal of the 8/16-bit MS/LB logic & Widening the control-rom to 32bit could offer future expansion for more ALU operators/functions , etc.
It's probably slower than something like an ESP32 but since you made it only using logic chips that makes it quite dope
I think you should be able to remove the dependence of VRam from System Ram, thus releasing the 16Kb that are currently highjacked by VGA output. So instead of writing to physical memory for the VREG to capture it, why not just output both the VGA pixel address and data onto a special port so that the VREG updates from that, avoiding completely the need to reserve these 16kB (from 0x4000 to 0x7fff) of system RAM?. The advantage is of course that you get extra 16Kb of ram for general purposes, which is a whooping 25% of all available ram. The only 2 drawbacks that I can think of are: - The inability to perform "reads" on video ram, but that's rarely needed or even a bad programming practice if some code actually does it. - The slightly slower updating of video ram, but that's probably negligible in real game scenarios given that most of the time the processor will be doing far more demanding computing tasks than just updating bytes to the VGA monitor. Does this make sense?
Have to think about this. I consider reading back from VRAM quite important for doing pixel graphics, e.g. setting random pixels, drawing lines etc. The new pixel has to be ORed into the existing data byte...
@@slu467 In such case things certainly get a bit more tricky. My suggested approach is of course implementing VGA output as a sort of "graphic unit" to which the main cpu only sends commands. So if setting/clearing individual pixels must be supported maybe this can be done by specifying bit masks. That of course makes things more demanding on the side of such "graphic unit" because it must handle internal reads on its own video memory to honour such masks. Anyway, just a thought.
@@RelayComputer Yes, this kind of development is a continuous trade-off. Many different approaches come to mind. I went for minimal effort/complexity on the hardware side.
Awsome, so clean emulator (thanks to clean project) !!! What a time, when we can emulate once our precious dreams in a browser with a script language...
Yeah, it's running at 8MHz in an interpreter...
@@slu467 Kind of... todays JS engines are quite mix of interpreters and JustInTime compliers, so authors of V8 for example can feel somewhat offended ;) But whatever they are and do it stil mindblowing...
Thank you, you made a great work to optimize SAP architecture and squeeze a water from 74 series. Especially for such videos that you explain and share your findings.
I had been complaining for week that the KZread algorithm was giving me nothing I wanted to watch and then today your video popped up! I don’t know HOW I wasn’t already subscribed but I am now. This is a most excellent project and the way you introduced the architecture made it possible for me to understand how it works. Thank you.
Jep, this algo gets in the way sometimes... glad you appreciate my stuff. That is all I could wish for 🙂
Dude I am trying to complete the Ben Eater 6502 and this project of yours is amazing
Wirklich interessantes Projekt. Könnte man die Control ROMs durch einen CPLD ersetzen oder enthalten sie irgendwelche Daten die nicht mit Gleichungen darstellbar sind? Ich würde die CPU gerne in VHDL implementieren und mal sehen ob sie die Performance von cpld6502 erreicht (bei 48 MHz wäre gar kein externer ROM-Zugriff möglich).
Hallo Kobold666, eine Implementierung in VHDL klingt sehr interessant! Bei aller Speed-Optimierung darf man aber nicht das VGA-Timing außer acht lassen. Hier müsste man ggfs. auf eine andere Auflösung wechseln, sollte die CPU zu schnell werden. 74HC ist nur meine Plattform gewesen, um die Logik zu optimieren. Erstes Ziel könnte sein, nur die CPU ohne VGA zu bauen...
Superb description. Thank you very much
What would it take to give it 4 bit colour? I am considering this design, since Ben Eater's design is a bit too restricted for someone who has successfully designed 16 bit systems on a gate level (though never assembled any IRL)
I recommend you free yourself from the desire for 4-bit color 🙂.The Minimal 64x4 uses 16K of its 64K RAM as video RAM. Multiply that by 4 and you run out of memory 😞
@@slu467 I'm probably misunderstanding the architecture but one idea I've had for my own designs is using a separate color register. Everything would still be one bit color but whenever you need to change the color, you could have an instruction to write a new color value to the register. The main problem I can think of revolves around how you would change color while drawing to the display to have more than one color on screen at once.
Given the RAM limitations, you would have to cut the resolution down to 200x120. Then you would need to redo the video circuit to output that, and build a video DAC to convert the data to color signals. It would make it somewhat less minimal at that point, if that’s a trade off you’re willing to make.
@@retrojon_ You are right. That would be a way to build it. But the Minimal is... well, minimal...
@@warrenmiller7195 Yep, but resolution renders native tools (text editor) rather useless. Its all a tradeoff and this minimalistic design went straight for usability, neglecting the fancy looks a bit...
You and Ben Eater are GOATs !
Thanks 🙂glad you appreciate this.
Not including PCB, what is cost of components for 1 board?
I haven't summed it all up but I'd say 50$ give or take. Less if you choose not to socket everything.
I just ordered a batch of boards from JLCPCB - can't wait to dive into it!😊
Great! Let me know how things go and send me a photo of your build if you want to become part of the build gallery in the manual.
@@slu467 I'd be glad to!
This has become one of my favorite channels and love to see new content everytime. It challenges me to understand the internals. I'm working on replicating something similar to use for a project and these vids are fascinating. Thank you for your in-depth coverage. I've learned so much.
You've made my day 🙂was fearing this vid was going way too deep...
@@slu467 Actually I like these deep and detailed ones much better - don't know about everyone else. I need to watch them a couple of times though. Love it.
@@scome98 I second that, this more detailed video was wonderful. The schematic is easy enough to follow but I'd love to see a detailed break down of each functional block.
Awesome. This sort of thing feels tailor made for some of the studying of the design that I’ve been doing!
Glad you find this helpful.
Fantastic, thank you
Wow its amazing
Superb as usual
Awesome as always!
Hallo Slu4! Als Elektroingenieur (Chip-Design) bin ich ein großer Fan Ihrer Videos und Ihres Kanals! Ihr Minimal 64 ist wirklich eine brillante Leistung! Ich denke, Ihr Design übertrifft den Apple I bei weitem!!! Haben Sie schon einmal drüber nachgedacht ein Exemplar Ihres einzigartigen Rechners dem Deutschen Museum zur Ausstellung anzubieten?
Hallo Andreas, vielen Dank für das Lob von dir als Fachmann 🙂Ich selbst komme aus der Physik... der Minimal 64x4 ist "educational" gedach und würde gern möglichst viele Menschen begeistern, aber ich habe das Gefühl, beim DM schlägt man sich nicht selbst vor. Entweder wird man da vorgeschlagen oder die kommen auf mich zu. Dann immer gern. Vielleicht kennst du dort jemanden? LG
This is seriously awesome! I love the care you put into these projects, and the fantastic detailed documentation 🥳
I have a stupid idea What could we do with arduino computer if we add one or two port extender ic's? we get a bunch of harder to adress io pins but we could technically use them for iio while routing one of oruginal ports to some more ram or rom could something like this work to run some more advanced os and actual color graphics? would a external graphic chip work over those extra io or would it be forced to work on main memory bus if we expose it on oryginal io?
I think your idea isn't stupid at all but quite mainstream. Using a graphics chip and eyternal RAM and stuff. I kind of do the stupid thing here by trying to do it all in one 😀
@@slu467 yes but i was thinking more of doing meinstream the stupid way. like bulding a character rom of text and squares and changing color on character and not line basis, byt you probably need more ram and io for that so give minimal os more io and ram but keep video generation in bare arduino outputs and using extra legs for slower stuff like keyboard or even horisontal refresh pulses if we operate with character based graphics like c64 we could technicallt make mandelbrots apear higher resolution than the actual one and in color something like that , overthinking the output with neglecting to upgrade hardware unles absolutely required and upgrades would be the lowest common denominator for the job
This is incredible. I was digging around for fun stuff to put in a PCB order I needed to place, and this fits the bill with aplomb. Cant wait!
I'm aware this video has some time now, but I have a question about the very last part where you "cancel" the interrupt jitter. I'm confused about why the compiler won't optimise away (remove) that first line of code and just generate PORTB=16?
The compiler does not optimize away port accesses, since it doesn't know if there's some "outside" consequences.
@@slu467 If two /different/ values are written consecutivelly to produce a pulse the compiler must respect that. But this is a repeated write of the same exact value to the same port, so I could think this could be optimised because compiled 'c' code does not make any guarantee of timing. Anyway, I suppose the avr library just takes the easier path and just declares port accesses as volatile
I am working on an open source program to hijack a gameboy color over the serial port. This helps a ton! Thanks 😊
3:42 that's pretty cool, unfortunately I only have a usb keyboard
Creative video, thanks :)
This is really top work, and it's been amazing to see the way the Minimal family has developed. One thing I was wondering was if there was any documentation of what all the microcode control signals are? I'm able to guess some based on the schematics and a few are explained in the Reference Manual, but a full list of all 24 signals and what they do/mean would be a very welcome addition to the documentation!
Hi and thanks a lot for your kind words. The documentation has a section 'CPU Architecture'. All control signals are explained there 😁
@@slu467 hmm, well I feel silly. I was so focused looking at the schematics and the assembly bits of the manual that I didn’t think to look in the architecture section! 😅 Thank you for reminding me that there was more than what I was focused on!
Very nice.