Brilliant! Very interesting seeing this take shape. For the first part of the video I thought you're making an IBM PC on a breadboard, with the PIC mapping you choose. But then you went off the PC path with the PIT address and frequency :)
Thank you very much for taking interest in my videos and your comment! The PIC at the address 0x20 was just an accident as I used the next available decoded address. This computer was never intended as anything close to IBM PC.
I’ve been told that x86 was a tricky CPU to program and my god there right! Excellent video series making it so much clearer both soft and hard ware interactions. Looking forward to the next video.
Thanks a lot! Personally, I find x86 assembly quite readable. Honestly, ARM for example is less easy to read, but this could be due to the fact that I've been doing the x86 for a long time ;-)
Great series. I need to get started in getting the parts and actually doing the project. That said, if you've already gotten to the final stage in your design yourself but haven't recorded your remaining tutorials or published them, could you formulate a parts list of parts required to follow all the existing and planned tutorials? That way we can place one order for everything we need, avoiding excessive shipping and handling fees. Ben Eater was able to partner with Jameco to develop kits for his few tutorial series.
Thanks a lot! No, there is no final stage I had thought of and I'm building everything first time during recording these videos. Of course I had some idea what I wanted to show and what peripherals to include, but the whole series was meant as just some fun for myself. I never really believed that many people would like to watch it, honestly. Therefore, I don't have a list of parts as such. I have an idea for an improvement to this computer in part 8 of this series, after which, if there is demand, I could formulate the part list, schematic or even a PCB, if people wanted to build the computer themselves, but the idea is still work-in-progress in its early stages. Thanks for the insight of how Ben Eater has done it - it could be valuable if this comes to fruition.
This is a really great series - and compared with series about the 6502 or Z80, it also shows that the 8088 is COMPLICATED! (Sorry, I had to shout it). I think I had to watch the entire video four or five times - in small chunks, often rewinding, to get my "ahh!" experience. For those of us that are also (re-)learning 8088 assembly language, maybe it would help if you built the code more gradually, like you build the hardware, adding pieces while explaining. Just a suggestion - I might still have to rewind and rewatch :) It is also a joy to be challenged a bit as a viewer!
Hi Peter! Thanks a lot for your very positive feedback. I started this series for fun and never expected that it would get some serious audience. It was also my first attempt to make any videos, so I probably didn't think everything through. I decided to focus on hardware and not to go too deep into the assembler, because I thought that there is plenty resources on x86 assembly and, honestly, I just wanted to test each added device as soon as possible. Whatever you see on screen is built first time - I never build it before shooting, so it is quite interesting for me if whatever I planned actually works in practice ;-) It is quite tricky to strike a balance and comments like yours are very welcome and valuable. Thanks again!
@@domeu Generally I want to fulfill my promise made in the first video to write a simple game for this computer at some point. But the next two videos will hopefully help me getting the project towards allowing viewers to play with this computer if they wish to build it themselves. More details will be revealed in the next two videos. Promise :-)
Thank for this series.... It would be impossible to jump from Z80 (or similar) to Intel without your videos. Thanks! I had a few questions: 1) Could you elaborate a bit how you do configure the compiler (to generates 8088 code) ? possible treatments on files ? The ROM burning. 2) How could we compile the code from a Linux machine (like Ubunu since it is quite popular) ? -- we don't have M$oft computer here. 3) Some plan to add an UART ? (to have a console terminal) 4) Would you jumps from 8088 (hard to find) to 80286 (this sales) ? Anyway, thanks a lot for your work. It is incredible.
Thanks Dominique! I'm happy to answer your questions: 1) I've been planned to write down detailed instructions of how to configure the compiler on my webpage ( slador.uk ), but haven't yet managed to find the time to do that - I'll try to do this in the near future (June in practice). A few more words on that below in 2). With regards to ROM burning, I'm using one of the so called "universal programmers" - plenty of which you can find on the internet like "TL866II" or "BeeProg" to name a couple. 2) That's actually much easier to compile on a Linux machine than it is on Windows ;-) You just need the compiler (link on my webpage) and "make" which is always there on Linux :-) The instruction of how to install the compiler on Ubuntu is here: launchpad.net/~tkchia/+archive/ubuntu/build-ia16/ Despite the fact I use Windows on a daily basis, I tried to write my Makefile so it works on both. In contrast, on Windows I had to build the compiler myself or, optionally, install it on the WSL. The editor I use (the VS Code) is optional, but also it is available on Linux if needed. 3) Yes, I have my 16550 waiting in my drawer ;-), but that's the future plan, beyond the next two videos. 4) In the second video from now (part 8) I plan to do "an upgrade" to my computer ;-) (I'd like to keep it as a surprise for now, please) and also I have a crazy idea along these lines for the future, but that would require me to depart from breadboards and make a PCB.
@@SladorSoft Thanks for all this valuables information. I'm also a Linux addict (@home & @work). I did figure out that you were using Windows because of VSCode.
@@SladorSoft Along other rough ideas... a PiZero 2 and some Python code could be used to creates device input (keyboard) and output (HDMI)... also some Wifi support... Humm maybe the compiler and ROM burning directly on x86 retro (by latching the buses)
I'm not say "no2 to that. I have a few ideas which recently piled up on my list, which I would like to cover first, but then I probably will do that. My current contraption would need a significant rewiring though, as it now uses the "minimal mode" of the CPU buses while I'd need to switch it to the "maximum mode" to pop the 8087 in.
Hi! Thank you for your kind words. That's true that I never actually showed how I put the flash to my universal programmer and do the flashing, because I thought it wasn't that important for the subject. I felt that it was implied that before any test I had programmed the flash with the current code. BTW - that's why I installed this ZIF socket to be able to remove the chip easily.
@bitlong4669 Yes, well, maybe I should have explained it in more detail. In short, each file whether it is an .asm, .c or .cpp file gets compiled (using its own compiler) into something called the object file (.obj). It is nothing but the machine code of the compiled functions/procedures with some labels like: "here is a code named with this name given by this label (or a function name)". If the source file calls some functions from another source (by using the "extern" keyword in assembler or the function declaration in a C header file), the object file contains just a placeholder for the address of the external function. After this step, there is no difference between an object file compiled from an assembly source or a C source file. Then, the, so called, linker kicks in. It's only job is to put all the compiled object files together and patching the placeholders with the actual addresses of every external functions in the executable. In other words, the linker glues all the functions/procedures together to make the final executable working. It's was a quickest possible attempt to explain the whole compilation process. Forgive me if it's not too clear - it requires a separate video on its own, really. Cheers!
@@SladorSoft ok good. That’s what I thought. I did linked different obj files from C. Didn’t know the assembler obj would link like that, it make sense. One thing though, the function signatures in assembler in videos were in comments like: ;some_function(arg) . Is that how linker knew this is entry point for that function? Or did I miss something.
No, the comments are only for the mere human ;-) When the compiler compiles your source file, it effectively creates a block of machine code with the labels "attached" to it together with the offsets in the file where each label appears among the compiled machine code. It also keeps placeholders for "jumps to subroutine" every time your source code calls to an "EXTERN" label - that means that this code and its label is contained in a different obj file - unknown at this point. Then the linker gets all the obj files together and tries to resolve all the "missing" labels between the obj files and patch their final addresses, effectively "linking" between them (hence the name of the tool). The labels are in general called "symbols". There could be more "symbols" in an obj file than only the labels - static data defined in your source code are also "symbols". You can see them all in the "map" file after building the project. In assembler, all the compiler needs from you are the labels. The C/C++ function names are used to create labels. The C function names may be "decorated" with the preceding underscore. In C++ the encoding of the method names is much more complicated and it's called "mangling", but I guess I already digressed from your question, so let me stop here ;-) Happy to answer any follow up questions.
Short answer is: "yes". Long answer is: "depends"... You need to make sure your microcontroller is able to promptly react on signals appearing on its inputs. If you do it 100% in software you may struggle. Think of, for example, the case where you sent the "INT" signal to the CPU and the CPU acknowledges the interrupt with two "INTA" bus cycles. In both cycles you need to either reply with the IRQ vector on the data bus in one CPU cycle, or at least issue a "not ready" signal on the READY pin until you're actually ready to send the vector out. Then, what's crucial is for your microcontroller to REMOVE the bits on the data bus immediately at the end of the bus cycle, because you may cross-talk with the CPU (or another device) in the next bus cycle. Doing all of the above in software is tricky, because you would need to react in a few microcontroller instructions. The functionality would need to be heavily implemented in interrupts and one interrupt can easily destroy the other one's timing. If you really wanted to implement the PIC in a microcontroller, then my obvious recommendation would be to use the RPi Pico and its PIO, then it's not only easy, but proven working in one of my other videos.
![CPU upgrade - 16-bit Intel x86 breadboard computer [part 7]](http://i.ytimg.com/vi/szF1_Tif2Gw/mqdefault.jpg)
![CPU upgrade - 16-bit Intel x86 breadboard computer [part 7]](/img/tr.png)
![First Run - Building and programming a 16-bit Intel x86 breadboard computer [part 1]](http://i.ytimg.com/vi/VvyUAaRTsww/mqdefault.jpg)
![Memory map and interrupts - Building and programming a 16-bit Intel x86 breadboard computer [part 3]](/img/1.gif)
Great video, as always! Have been looking forward to this for a while now! :)
Very good explanation of the process of building a x86 system! Thanks a lot.
Great video! Amazing debugging capabilities.
Brilliant! Very interesting seeing this take shape. For the first part of the video I thought you're making an IBM PC on a breadboard, with the PIC mapping you choose. But then you went off the PC path with the PIT address and frequency :)
Thank you very much for taking interest in my videos and your comment! The PIC at the address 0x20 was just an accident as I used the next available decoded address. This computer was never intended as anything close to IBM PC.
@@SladorSoftit would bé awesome to transform this into an IBM PC with MDA graphics
I’ve been told that x86 was a tricky CPU to program and my god there right! Excellent video series making it so much clearer both soft and hard ware interactions. Looking forward to the next video.
Thanks a lot! Personally, I find x86 assembly quite readable. Honestly, ARM for example is less easy to read, but this could be due to the fact that I've been doing the x86 for a long time ;-)
This was the first time I was able to understand segments, bloody hell, it must have been fun times programming things on DOS.
Great series. I need to get started in getting the parts and actually doing the project.
That said, if you've already gotten to the final stage in your design yourself but haven't recorded your remaining tutorials or published them, could you formulate a parts list of parts required to follow all the existing and planned tutorials? That way we can place one order for everything we need, avoiding excessive shipping and handling fees. Ben Eater was able to partner with Jameco to develop kits for his few tutorial series.
Thanks a lot!
No, there is no final stage I had thought of and I'm building everything first time during recording these videos. Of course I had some idea what I wanted to show and what peripherals to include, but the whole series was meant as just some fun for myself. I never really believed that many people would like to watch it, honestly. Therefore, I don't have a list of parts as such.
I have an idea for an improvement to this computer in part 8 of this series, after which, if there is demand, I could formulate the part list, schematic or even a PCB, if people wanted to build the computer themselves, but the idea is still work-in-progress in its early stages.
Thanks for the insight of how Ben Eater has done it - it could be valuable if this comes to fruition.
This is a really great series - and compared with series about the 6502 or Z80, it also shows that the 8088 is COMPLICATED! (Sorry, I had to shout it). I think I had to watch the entire video four or five times - in small chunks, often rewinding, to get my "ahh!" experience.
For those of us that are also (re-)learning 8088 assembly language, maybe it would help if you built the code more gradually, like you build the hardware, adding pieces while explaining. Just a suggestion - I might still have to rewind and rewatch :) It is also a joy to be challenged a bit as a viewer!
Hi Peter! Thanks a lot for your very positive feedback.
I started this series for fun and never expected that it would get some serious audience. It was also my first attempt to make any videos, so I probably didn't think everything through. I decided to focus on hardware and not to go too deep into the assembler, because I thought that there is plenty resources on x86 assembly and, honestly, I just wanted to test each added device as soon as possible. Whatever you see on screen is built first time - I never build it before shooting, so it is quite interesting for me if whatever I planned actually works in practice ;-)
It is quite tricky to strike a balance and comments like yours are very welcome and valuable. Thanks again!
still very impatient to know a bit about the future of this project... could you share some news? thx
@@domeu Generally I want to fulfill my promise made in the first video to write a simple game for this computer at some point. But the next two videos will hopefully help me getting the project towards allowing viewers to play with this computer if they wish to build it themselves. More details will be revealed in the next two videos. Promise :-)
Thank for this series.... It would be impossible to jump from Z80 (or similar) to Intel without your videos. Thanks!
I had a few questions:
1) Could you elaborate a bit how you do configure the compiler (to generates 8088 code) ? possible treatments on files ? The ROM burning.
2) How could we compile the code from a Linux machine (like Ubunu since it is quite popular) ? -- we don't have M$oft computer here.
3) Some plan to add an UART ? (to have a console terminal)
4) Would you jumps from 8088 (hard to find) to 80286 (this sales) ?
Anyway, thanks a lot for your work. It is incredible.
Thanks Dominique! I'm happy to answer your questions:
1) I've been planned to write down detailed instructions of how to configure the compiler on my webpage ( slador.uk ), but haven't yet managed to find the time to do that - I'll try to do this in the near future (June in practice). A few more words on that below in 2). With regards to ROM burning, I'm using one of the so called "universal programmers" - plenty of which you can find on the internet like "TL866II" or "BeeProg" to name a couple.
2) That's actually much easier to compile on a Linux machine than it is on Windows ;-) You just need the compiler (link on my webpage) and "make" which is always there on Linux :-) The instruction of how to install the compiler on Ubuntu is here:
launchpad.net/~tkchia/+archive/ubuntu/build-ia16/
Despite the fact I use Windows on a daily basis, I tried to write my Makefile so it works on both.
In contrast, on Windows I had to build the compiler myself or, optionally, install it on the WSL.
The editor I use (the VS Code) is optional, but also it is available on Linux if needed.
3) Yes, I have my 16550 waiting in my drawer ;-), but that's the future plan, beyond the next two videos.
4) In the second video from now (part 8) I plan to do "an upgrade" to my computer ;-) (I'd like to keep it as a surprise for now, please) and also I have a crazy idea along these lines for the future, but that would require me to depart from breadboards and make a PCB.
@@SladorSoft Thanks for all this valuables information. I'm also a Linux addict (@home & @work). I did figure out that you were using Windows because of VSCode.
@@SladorSoft Along other rough ideas... a PiZero 2 and some Python code could be used to creates device input (keyboard) and output (HDMI)... also some Wifi support... Humm maybe the compiler and ROM burning directly on x86 retro (by latching the buses)
I would love to see a video in this style covering the 8087.
I'm not say "no2 to that. I have a few ideas which recently piled up on my list, which I would like to cover first, but then I probably will do that. My current contraption would need a significant rewiring though, as it now uses the "minimal mode" of the CPU buses while I'd need to switch it to the "maximum mode" to pop the 8087 in.
عمل جيد ومشكور على ذلك
Do you plan to publish some new video on the 8086 retro-computer ?
Yes, definitely. It's just taking some time as the next video requires quite a lot of work behind the scenes. Thank you for your patience.
Great video tho again can't see loading the program into specific memory or loader
Hi! Thank you for your kind words. That's true that I never actually showed how I put the flash to my universal programmer and do the flashing, because I thought it wasn't that important for the subject. I felt that it was implied that before any test I had programmed the flash with the current code. BTW - that's why I installed this ZIF socket to be able to remove the chip easily.
Many thanks for the reply - these videos are inspiring
I’m not to clear how .asm files mix with .c files. Can you elaborate on that please.
@bitlong4669 Yes, well, maybe I should have explained it in more detail. In short, each file whether it is an .asm, .c or .cpp file gets compiled (using its own compiler) into something called the object file (.obj). It is nothing but the machine code of the compiled functions/procedures with some labels like: "here is a code named with this name given by this label (or a function name)". If the source file calls some functions from another source (by using the "extern" keyword in assembler or the function declaration in a C header file), the object file contains just a placeholder for the address of the external function. After this step, there is no difference between an object file compiled from an assembly source or a C source file. Then, the, so called, linker kicks in. It's only job is to put all the compiled object files together and patching the placeholders with the actual addresses of every external functions in the executable. In other words, the linker glues all the functions/procedures together to make the final executable working.
It's was a quickest possible attempt to explain the whole compilation process. Forgive me if it's not too clear - it requires a separate video on its own, really.
Cheers!
@@SladorSoft ok good. That’s what I thought. I did linked different obj files from C. Didn’t know the assembler obj would link like that, it make sense. One thing though, the function signatures in assembler in videos were in comments like: ;some_function(arg) . Is that how linker knew this is entry point for that function? Or did I miss something.
No, the comments are only for the mere human ;-)
When the compiler compiles your source file, it effectively creates a block of machine code with the labels "attached" to it together with the offsets in the file where each label appears among the compiled machine code. It also keeps placeholders for "jumps to subroutine" every time your source code calls to an "EXTERN" label - that means that this code and its label is contained in a different obj file - unknown at this point. Then the linker gets all the obj files together and tries to resolve all the "missing" labels between the obj files and patch their final addresses, effectively "linking" between them (hence the name of the tool). The labels are in general called "symbols". There could be more "symbols" in an obj file than only the labels - static data defined in your source code are also "symbols". You can see them all in the "map" file after building the project.
In assembler, all the compiler needs from you are the labels. The C/C++ function names are used to create labels. The C function names may be "decorated" with the preceding underscore. In C++ the encoding of the method names is much more complicated and it's called "mangling", but I guess I already digressed from your question, so let me stop here ;-) Happy to answer any follow up questions.
Could I use a microcontroller as a PIC?
Short answer is: "yes". Long answer is: "depends"...
You need to make sure your microcontroller is able to promptly react on signals appearing on its inputs. If you do it 100% in software you may struggle. Think of, for example, the case where you sent the "INT" signal to the CPU and the CPU acknowledges the interrupt with two "INTA" bus cycles. In both cycles you need to either reply with the IRQ vector on the data bus in one CPU cycle, or at least issue a "not ready" signal on the READY pin until you're actually ready to send the vector out. Then, what's crucial is for your microcontroller to REMOVE the bits on the data bus immediately at the end of the bus cycle, because you may cross-talk with the CPU (or another device) in the next bus cycle.
Doing all of the above in software is tricky, because you would need to react in a few microcontroller instructions. The functionality would need to be heavily implemented in interrupts and one interrupt can easily destroy the other one's timing.
If you really wanted to implement the PIC in a microcontroller, then my obvious recommendation would be to use the RPi Pico and its PIO, then it's not only easy, but proven working in one of my other videos.