Back in the 1980s I ran a chemistry laboratory instrument that was controlled by a PDP-8. To start that up you used the front panel switches to input a program that enabled the paper tape reader on a connected ASR-33 Teletype machine. The rest of the operating system and the instrument software was loaded through multiple paper tapes that had to be read in one-by-one. Our software library was a box full of 35mm film cans each holding a single paper tape. When the instrument was finally decommissioned the PDP-8 went to the university's technology museum. (PS: After reading what I just wrote I realized how very old I am.)
Hardware engineer here. Usually, reset lines are active low, so to reset a chip, the reset line is pulled to ground. I believe that to be an artifact of when BJT transistors were still used, and NPN transistors were both faster and had a larger current capacity than PNP transistors. So pulling a line low was easier than pulling it high. You can check old 74 series logic data sheets and see that the current sink number was typically a lot larger than current source.
An added benefit is in case of a power dip. A power dip can throw a CPU (or any other digital logic chip for that matter) into an unknown state. If the reset line dips, the CPU would reset and go back to a known state.
Yes, bipolar NPN-transistors. But also the n-channel enhancement mode field effect transistors that was the basis of early µ-processors, before symmetrical CMOS took over in the mid 1980s.
Just sat down and watched through this with my ~20 year old son who is just starting out in an IT sys-admin career. I think it took us a good hour of pause-restart to get through the whole video, but I think he now has a better understanding of some fundamentals that are not normally taught in modern computer courses. Thanks Dave!
That was my first surprise interview question to the candidates while hiring to PSS in the late 90's. People would come prepped with all sort of things about SQL, Exchange etc but when initially confronted with this "basic" challenge, many would just freeze and needed few seconds to boot up and come back to life:) . At least for me it was a great way to understand how much deep the person could go for troubleshooting in the future if needed.
As an apprentice, I asked our top software engineer where does the H8 microcontroller know where to get my code from? He called hitachi and ordered a ton of documentation for me. I believe he mentioned that I’m the 16 year old kid in the R&D office. They were kind enough to send me a complete hardware emulator and i let nobody touch it until i graduated. I believe that thing was very expensive but the products that little boy designed are still in operation today. I saw one during a visit to a pharma company and said i wrote the software as a child haha. Luckily i added an easter egg that showed my name on the 7 segment display
I don't know how you could wrap your head around this stuff at 16, you must have been exposed at a very young age. When I was 16, I was able to make only stupidly simple programs in quickbasic and visual basic and was learning the basics of electronic circuits. I couldn't grasp basic concepts like why i needed to use pointers, it was hard to find documentation or books that explained it in a way that clicked. Years later, I found Ben Eaters 8 bit breadboard computer videos and built one. Everything finally started to click, but already mid 30s working full time, just didn't have the time or energy to take programming further. Maybe my brain just wasn't made for it. I still don't understand how people that young were able to make sense of very advanced programming concepts. Maybe I'm just fucking retarded
@@mikeb1596 fuck, you're WAY ahead of me. I could program Madlibs in BASIC as a tween, but I was too lazy/scared to try graphic programming. That's as far as my programming journey ever took me.
@@mikeb1596 Well, it's all just a matter of exposure. My dad showed me Pascal at the age of 11 (somewhere around 1995). He only showed me the basics and at that time I barely understood english so I couldn't make much sense of it at first. However my first english words which I actually could type quite fast were things like "implementation", "interface", "record" and such things ^^. The help that shipped with Turbo Pascal 7 (in the fantastic Turbo Vision TextMode based IDE) was all I had. So I just made myself familiar with the most basic stuff at that time. So console input / output, file input / putput and some basic graphics with the horribly slow BGI drivers under dos emulation on a win95 PC. I got a few books on some system internal stuff which helped a lot. I saw my dad only a few days every couple of month. So each time he showed me some small tricks and details (like memory segment B800 which is the textmode screen buffer). You can do a lot with just those basic stuff. Later I naturally switched to Delphi (since it is based on Pascal) and since I now had a 96k modem I actually had occational internet access. Though dailup connection was quite expensive so I didn't have that much time. Though I found the excelent NeHe (Neon Helium) OpenGL tutorials. They had example code in 20 different languages, including pascal / delphi. So at the age of 16 I already had a quite good foundation on the hardware and some of the software interfaces. Though I have to say that back in the old days, the hardware was a lot simpler so it was way easier to understand how it works. Though back in the day I usually was just scratching on the surface. I had an apprenticeship as an electro mechanic at the german postal service "Deutsche Post". After the 3 and a half years a friend of mine who continued to work for the postal service as a service technician ask me if I could write a "simple" software that would replace an excel script that used VBA to receive text over a serial interface that was meant for dot matrix printer which was used to capture error messages. That PC was connected to a radio that could be operated over another serial port. The script was simply playing wav files according to the system error and broadcast it on the radio. Of course that system was horribly limited, especially since error messages also had a "solved" message so when errors piled up it couldn't keep up. I wrote a delphi program that received and parsed the messages, put them in a nice color coded list view and automatically matched the solved messages with the actual errors. It queued the messages up to be broadcast on the radio. Over the years the system grew. The radio had some handshake messages so we could detect if there was other chatter on the radio. So we implemented some timeouts to ensure we don't interrupted human communication, The radios even had 5 buttons which could send a 5-tone sequence that the radio could detect. So we even added the ability for the technicians to acknowledge an error or to make the system repeat the last one. I actually used a text-to-speech system to "read" the error on the radio. I setup a quite extensive config that allowed the technician to specify replacement messages. Tons of special cases were added. Like when an emergency halt button was pressed, the system usually generates tons of errors and in that case they should be suppressed and stuff like that. AFAIK this program is still in use to this day :) I wrote the initial version in 2008 (just checked my history txt) and the lates update was in 2019. At that time they got a new radio system and while it was mostly compatible, the busy detection suddenly failed because it was signalled differently. At that time I hadn't used delphi in years since I completely switched to C#. Though it's kinda amazing that the same piece of software is used for over 15 years on a daily basis. Fun fact: other parcel stations which had the same (old) system asked around 2010 if they could also get this software. Since I just made that in my free time to help out my old buddy, he ask me to integrate a simple "license" system. We didn't charge any money, but we wanted to make sure that we know how many stations were using it. That's one of my old software stories :) It was a fun time back then. Systems were so much simpler (and a lot more insecure). Nowadays we struggle with writing shaders or high end graphics stuff. That's how I ended up using Unity for about 12+ years now. Though you learn something new every day. There are so many programming languages out there and so many systems, frameworks and technology that it's impossible to keep up with all of that.
Thanks Dave, very informative. As a Software Engineer, I totally failed an interview question "What are the steps that occur when a computer boots up". Next time I will have a much better story to tell.
first time watching one of your vids, immediately got the feeling that this was a man, probably towards the end of his career, educating the younger generations in a very entertaining and engaging way! I don't even know why I'm commenting but I'm sure I'll like that video.
This brings back memories. Back when the first IBM PCs first shipped I wrote a little TSR to make duplicationg diskettes much faster. I had to deal with low level issues like the 64k DMA transfer limit. Mucking around with the hardware at a very low level was a lot of fun!
Having been in IT since the days of the first PCs, I enjoy watching your videos. They're very informative and entertaining. Thanks for the time and effort you put in to bring them to us. Your mention of The Friendly Giant brings back memories of the occasional sick day when I was in my early elementary school years. I remember flipping around the TV dial (yep, I remember dials on TVs), and finding this program on the regional PBS station. Good memories from a bygone era. Also, love, love, LOVE the LEDs you have set up in your gadgets and gizmos. Thanks again!
The mention of the "Stone Virus" reminds me of one of the earliest books about computer viruses and AI, "The Adolescence of P-1", by Thomas Ryan, 1977 AKA from way back.
If you *really* want to know how to build and bootstrap a microcomputer, Ben Eater's series on building a breadboard computer might be for you. Goes to a level of detail that should satisfy most anyone - both in terms of hardware and software.
An additional interesting thing about the original IBM PC was that if no bootable disk was found it would load Cassette Basic from ROM. Thus, early compatibles, not having Cassette Basic could give the error 'Cassette Basic not found ", rather than the later error of "No Bootable Devices Found".
Thanks this brings me back memories. I remember during my high school days, the computer lab teacher would remove me from the class as I was one of only kid in school who understood about boot sector viruses. He just excepted me from the classes, as I also gave him grief whenever I ask questions or propose better code. So I sat in a corner and help fix the schools virus issues. I have a known disk that has no viruses and write protected. I then would get most of my classmates disks, go through them and using DEBUG to copy back the boot sector to its original address. I also can easily when there is boot sector virus, when you open the PC case, you can see drive A: head will move differently when an infected disk is booted, you can clearly see that will go the beginning cylinders initially but moves to end to load most of the real boot sector.
One reason BIOS Booting went: BIOS -> Boot Drive -> MBR -> Active Partition -> Partition Bootloader -> OS Bootloader, was simple size constraints. You needed quite a bit if space to store a bootloader that is capable of properly reading and writing a full filesystem. There was just no way to fit even partial reading before the Partition Bootloader. UEFI has much more storage space. So now we can write the OS bootloader directly into it. Sidestepping the whole MBR Relay Race.
Ahh the memories of the "sneaker Net" I used it for a long time, (late 70's through early 90's) and still find uses for it on occasion today for things like family information and such.
Canadian nostalgia to my early 1980's childhood:, both the friendly giant, "Look up, waaay up," and I have to assume a throwback to Stampede Wrestling with Ed Whalen's famous line. You better "batten the hatches and lock the doors, because it's stampede wrestlin' time once more!"
I remember booting an HP1000 by switching its register buttons. The software was loaded from an HP2645 terminal by a cartridge. That minicomputer was used to control a Westinghouse OMR (Optical Mark Reader).
For years I have thought that this subject would make a great reference book. So much happens at boot time and knowing that can really help you speed things up. thanks for taking this on!
Thanks Dave, another great tutorial. We used to refer to the IBM PC power switch as the BOSS -- Big Orange Shutoff Switch. Could you possibly make a session on PROM, EPROM and BIOS--What they are, where they are and how they are made. Keep up the good work.
In the early days of PDP8s and 11s we would usually key in an actual program - typically 10-15 instructions long - that could read from a card reader or paper tape reader. So we’d load up cards or tape with a bootstrap program that could then read from a hard drive if you had one.
Yes. I only got to play with a salvage vintage PDP/8 back in the 1980's as a teenager. It had a boot sequence called a RIM loader that had to be keyed in octal using the front panel. This would fire up the paper tape reader which would be loaded with the bootstrap tape. That would enable and run the mag tapes one of which had a rudimentary OS on it. Only then would the terminals flicker to life and also enable the hard drive to run DEC OS or whatever. That HDD behemoth was less than 1MB, weighed a ton and took up half a rack.
@@Drew-DastardlyErr. In my lab, only after the first keyed-in bootstrap routine could control be transferred to a teletype thingy with a punced card or tape reader. Only then would life be reluctantly granted to the monitors and keyboards. PDP 11-45? That was around 1978. I recall editing paper tape with sticky tape and a paper punch. Splicing just like movie film. Obviously one needed to have a thorough knowledge of ASCII code to do the job. I just was a maths student not the actual computer manager!
The good ole days. Never looked back. But i do remember fondly how I learned to even get these contraptions to work. The lights still mesmerize me though.
A video discussing disk partitioning and how that dovetails with this piece would be interesting. Especially given the myriad of historical disk partitioning schemes. MBR and GPT would obviously be mandatory, but it might be fun to look at others, both historical and extant. After that, the one that really begs for your elucidation is the dark world of FILE SYSTEMS. Oooooo... Scary. Lions and tigers and bears.... FAT8/16/32, NTFS, ReFS, ISO9660, and maybe even some of the Linux options like Ext2/3/4, XFS, ZFS, etc.
@@maxstr If I'm not mistaken I think the modern UEFI systems today are required to boot from NVME and it will read from that PCI Express lanes instead of the SATA Bus lines. It doesn't recognize it as a SATA unless if you're specific NVME or SSD is connected to the SATA ports. Also you may have to modify the BIOS settings to select that particular drive to be the drive to boot from. It may not automatically do it for you. You might have to configure the BIOS.
@@maxstr At the abstract level, an NVMe device is a storage controller, just like an AHCI SATA controller or many other types. It can accept commands to read and write blocks and do other things. If the BIOS or UEFI has drivers to support the device, it can expose it through its storage APIs. In fact, I have an older motherboard here with an M.2 slot that supports PCIe drives. If you plug an NVMe drive into it and boot an OS with an NVMe driver, it will see the drive normally, however UEFI is unable to boot from it as it doesn't have a compatible driver. Once, I was reading something about modifying BIOS images to add drivers to them. I didn't go through the process, but I did manage to download an NVMe EFI driver and extract it. I started the built-in EFI shell, loaded the driver and the NVMe drive showed up in the list, as expected.
@maxstr Late reply. IIRC, the pre-UEFI BIOS points to sector 0 of the boot device to execute the bootloader. It doesnt care what type of device; they all get presented to the system as block devices. What happens next is based on your bootloader.
Back in the 80's I worked on the Docutel ATM's that were controlled by a computer with front panel switches like the Imsai, that had Core memory. to load the Operating system we would insert a loader board into a Bus Slot and manually enter a 15 instruction boot program into memory then plug in a cassette tape recorder with the program on a cassete into a audio jack on the loader board, then start play on the player then press run on the panel switches to run the boot loader program. Once the tape had played the recording (OS), I would stop the boot loader power off the computer remove the loader board power back on the computer press stop on the front panel switches. enter a memory start address into the program counter register then press run to start the OS. If the system didnt start correctly, we stop the the cpu examine memory loacations by using a memory dump listing and fixing loations with the wrong values then change the program counter back to the program start location and try agin. My How things have changed since then !
I love the detail you've gone into on how a computer boots up. It was also a blast from the past, I remember getting the "Your PC is now Stoned!" message!
Dave, these kinds of videos are great for even IT profesionals. Like you, I came up on computers that pre-dated DOS, but as an IT executive now, I find my staff is unaware of this level of detail about how computers operate which sometimes prevents them from theorizing about why computers may be misbehaving in particular ways. Thanks for another great video. Sure wish I could have worked with you back in the early 80s and onward.
Great video! I miss the IBM PC keyboard. The tactile click of it was great - but a little noisy.. The Friendly Giant reference brings back memories too!
Clarity. This structured and interesting video was mostly stuff I knew already, but it nicely filled in some gaps in my knowledge, for which I am very grateful.
Hi Dave, great video! Not trying to be an arrogant prick but i'm pretty sure there's a mistake at 5:24. The reset vector on a 8088/8086 can't be FFFF:FFF0h because on those CPU's there's no A20 line and setting CS to FFFFh and IP to FFF0h would immediately wrap both registers to 0000h. Starting from the 286 CPU i'm sure setting CS and IP like that would make the A20 line set the physical address to the end of the HMA area minus 16 bytes. So on a 8088/8086 the vector MUST be by setting CS at F000h (start of the last real mode segment) and IP to FFF0h. The alternative would be setting CS to FFFFh and IP to 0000h. Both methods point to the same physical 20-bit address of FFFF0h. I'm absolutely 100% convinced that you are aware of this and that it was just a mistake.
FFFFFFF0 is not FFFF:FFF0, nor did I claim it! You can use segment-offset to reach FFFFFFF0 without any overflows or A20 line, right? Or at least I thought so!
Back in the dark ages, I was the "computer expert to call" at the local talk station. I remember one early morning when the activation date for a truly nasty virus hit. I had said that as long as you had a reliable antivirus running with current signatures, you should be good to go, but here is what it will do to you if you aren't protected... and described the virus's actions. That is when a guy with an 80286 based system called in to say "I think I got that virus. My computer turns on, but doesn't run the bios." The nasty that he had (and did not have an antivirus to detect) basically totally wiped out his BIOS code which was flashable. So the virus had written junk into what had been booting his machine. I told him since the bios was soldered on to his motherboard, he would need a new motherboard in all probability.
Is that true? I thought most 286 systems still used mask ROMs or maybe UV EPROMS. Either way they can't be programmed from the PC. I'd be interested to know more about what this system was.
@@eDoc2020 Early IBMs had the burned rom that was safe. However, there were a lot of stuff from overseas that had discovered the BIOS from folk here, and that they needed to be able to update them with a flash from a bootable floppy disk. (Phoenix among others.) And the clone motherboard manufacturers needed to be able to update the bios so that they could add new bootable devices.... It had to be able to init all the new stuff that was coming out, and of course, fix any bios related bugs. Some of the early bios systems from the far east were rather humorous... The error on one I had to fix... "Disk not setting OK" for a failure to load a floppy disk... Early Dells needed a chip change for an update. That got REAL expensive for them....
When I started working as an assembly language programmer at the very start of the 1980s, the system I worked on had a 4 step boot procedure. 1., toggle in the paper tape reader bootstrap on the front panel, 2., run that and read in the card reader bootstrap from 8-level punched paper tape, 3., run that and load the operating system from a deck of punch cards. 4., once that was in, you entered the start address on the front panel, hit the run button, and it was up and running. Back then, I knew the card reader bootstrap code by heart - it was half a dozen or so 16-bit words which, of course, I remembered in hex. Sadly, I can't remember it now.
OMG listening to you brings back so many memory's, I used to write in assembly language still got many books on my book selves... started with 8088, think that's right.... thought I was big time when I moved up to 286, 386 machines.... I still have a hole punch for 2.88 floppy's from the 1.44....
Great video. My favorite way to understand the low-level concepts is to look at old electromagnetic pinball machines -- all mechanical/relay logic, literally "hardwired"! When they start a game, the "bootstrap" is a sequence of events making sure everything is in the right state. From there, it's easy to see how digital versions evolved which could read punchcards or ROMs and "bootstrap" themselves into a usable state
My grandpa was one of the first coders for Payless shoes in the early 70s. He got sent by the company to mit I believe at the time to learn it for a year or so. I remember him teaching me all this stuff when I was little and am still thankful I can understand this old tech. Thanks to my grandpa
I just understood what happens after Living on Earth for 27 years. Thank you very much for sharing your knowledge, I don’t think thank other than a few people who works such industries will ever have the chance to learn more about these systems, over time I felt that the fundamental concepts are being erased. Have a nice day sir , I am from Sri Lanka 🇱🇰
An interesting thing about UEFI which Dave did not explain in this video (he probably knows about it), you can also interact with the UEFI from your operating system, for example to 'tell it' to automatically go into the UEFI-menu after rebooting or to change the bootorder. On Linux with SystemD you could do the first thing by giving the option firmware to the reboot command, on Windows there also is a command for that but I don't know that by heart because I don't use Windows, I have tried it out though it works fine and it is easy enough if you remember the more difficult syntax.
Don't quote me, but I believe that's as simple as a defined setting either in sram or a file on the uefi partition. ie, the uefi just checks if it's got a voicemail from the OS or not. Or, the way windows checks for the dirty flag to run chkdsk. It's not... "interactive" as it were.
@@mikebarushok5361 UEFI is definitely not MINIX. There are rumors that the firmware running on the management engine (ME) in some chipsets runs MINIX, but that's a separate microcontroller.
@@myne00 boot order is done through UEFI variable manipulation. UEFI provides a set of routines at boot time to the OS (UEFI runtime services) and one of those routines allows the OS to modify UEFI variables, including boot order and boot flags. The UEFI partition contains the bootloaders that the bootselector runs. ye olde CMOS settings are still in (battery-backed) SRAM, although some platforms let you ditch the battery and RTC.
Hey @DavesGarage, I appreciate your expertise and would love to see a video where you explain the specific purpose behind the 'Apply' button and why it was created. It's a common oversight, and I think many users could benefit from understanding that clicking “Apply and Ok” is redundant. The 'Apply' button was created to allow changes to be saved without closing the dialogue box, a detail often missed in instructions. Your experience would make for a valuable and insightful video that I could direct others to. Thanks in advance for considering this request! .
Dibs on the rocking chair, as long as I can bring along my Strat (my SG is a bit smaller/lighter if drive space is limited). Thanks, Dave ... as always!
This does bring back days of my first gig as a new IT tech for a radio station. Your challenge should you choose to except it: Get this telephoney system (an 8086 with a MFM 10 meg Hard drive) working again even though the HD was completely full running DOS 6.00 I was able to boot off a 1.2 meg 5.25 floppy and copy everything to a group of floppy disks on a 2nd 3.5 floppy drive. Load DOS 6.0 on a 286 with a whopping 100 meg IDE HD copy everything back over... transplant the IDE telephony 3 line card into the new computer and to my complete surprise... It worked. and continued to work for another couple years until the World Wide Web was a popular thing and this gizmo fell out of use.
Ahhh the good O'l days, miss them to some degree. My poor old Amiga is still sitting in the cupboard with it's 500 Meg hard drive, and a SCSI 500 Meg drive was so massive for one of those I couldn't fill it after 10 years use & it never failed me either, such exceptional technology for the time.
Dave. Hi from this far part of the world! I love your educational series. Seeing your videos is like attending a great university class or course. I will kindly propose to you doing a video explaining how the OS decides if it is going to run in 32 or 64 bits mode. As I understood, this happens after the OS is loading from the designated disk, but how does that works? It will be great to know your take on that. Have a very nice day and keep that super nice work!
It's decided the same way as going into protected mode. And that is a story by itself as the 80286 had a bug that prevented it to back into real mode without a reset.
Coming across this channel at the perfect time. I’m in the middle of trying to figure out if both my RAM sticks are bad (tested both separately), or if it’s something else :/ Anyway, while doing this, I find myself wondering how in the hell computers do exactly what this video is about. This is my third video and the channel has earned a new sub!
I didn't have one of those early computers. But I remember the SS-100 and SS-50 bus being mentioned in Byte and Creative Computing. I loved those mags.
The Bootstraps saying comes from the story 'The Adventures of Baron Munchausen'. It is full of tall tales where the Baron is a hero in bizarre adventures. In a story he tells of how he was stuck knee deep in mud. Asked how he freed himself he replied 'he pulled himself up by his bootstraps.' An example of how crazy his tales where.
Great stuff Dave. I grew up with the 6502 (a Commodore 64) and move to DOS PCs. I now have a friend with an Altair 8800 … you’ve tied them all together in my mind.
It’s funny that you say “as simple as setting dip switches.” My son is a computer science major in college, and has no idea what the inside of a computer looks like, as opposed to his father, who used to build custom PCs for customers back in the 90s. I think if you asked my son to set dip switches, his head might explode.
Dave, thank you I started an Internship a couple months ago that makes hardware, specifically Linux boards, and even within the first 5 seconds of the video you asked the questions that I had and still haven't fully learned. Same thought process exactly.
I only now just found your channel via this video. I liked and subscribed. Looking at your history, I’ll be busy a long time binge watching many of your previous videos. I’ve been programming since 1976. Thanks for some really great content! This is going to be fun.
In the late 70s at CEGEP (Quebec Junior College) I built an Imsai 8080 from a kit. Many soldering hours later it turned on but we had no memory. After I graduated I was told they bought memory and it worked. 10+ years earlier I watched the Friendly Giant .... and Mr. Dressup, Chez Helen, and Romper Room.
AAah, the Friendly Giant! As a kid from the 70s and 80s, growing up with a PC-XT Compatible as my first PC I enjoyed the switch-flipping and the Friendly Giant montage at the end. I'll be sharing this video with my Cybersec. students!
Holy sh*t man! THAT IS GOOD CONTENT!!! At 3 mins in I was amazed that so much info was crammed in on your video! At 7 I had to rewind a couple times to understand correctly but was even more amazed that in less than half of the video you had so much interesting facts that helped me deepen my knowledge, polish it where I was rusty and learn a ton of new things in between!! Instasubscribed! I follow many great channels but not even one amazed me like you did with the sheer amount of info! And you do this for free?? F'cking amazing! MS started declining the day you left. Did you see W11 or edge? Man, they need like 10 of you to get things right again!
I hope this channel can discuss the Intel Management Engine (ME) running MINIX at a lower level than the OS. Why is it there? Is it true that it continues running in low-power mode even with the system turned off (but still plugged in)? Supposedly it has TCP/IP access and the computer can be woken up and accessed remotely. It sounds like we don't actually have privacy at all as long as there is an ethernet cable plugged in. AMD has it too, I think it's called, Platform Security Processor (PSP). Andrew Tanenbaum, creator of MINIX, wrote An Open Letter to Intel about this.
The last time I was at the Living Computer Museum in SODO they ran through the startup on an Altair. I was the only one who was there for the presentation. I miss that museum. :(
Kinda similar, for my own custom CPU core (and ISA) on an FPGA (personal hobbyist project), the general boot process is sorta like: RESET pulse, with CPU resetting major control registers to default values; CPU starts at 0000_00000000, which holds the ROM (48-bit VA, 32-bit PA); The start address branches to the actual entry point; It sets up some initial registers, then runs "sanity checks", which verify that most of the core CPU instructions/features are working; It then sets up the console for text display; It does a RAM test, followed by a small L1/L2/RAM benchmark, and cache integrity check; It then sets up the SDcard, reads partition table, and reads the first FAT32 partition; It looks for a file named "bootload.sys" in the root directory, and if found loads it; In my case, this file is an LZ4-compressed PE/COFF variant (albeit lacking the MZ header or stub); The 'PE\0\0' turned into 'PEL4' to signal this, everything past first 1K of headers is LZ4 compressed; If 'PE\0\0' or 'MZ', it is loaded as an uncompressed image. Otherwise, this format imposes an Offset==RVA constraint to simplify loading. The PE image is loaded into RAM (decompressed during load); The checksum is then verified Custom algo, as the original PE/COFF checksums were unacceptably weak The original PE/COFF checksum algo kept missing errors from common LZ decompression issues. It sets up various registers, and jumps to the entry point. At this point, the "kernel" does the rest (more sanity tests, setting up console and FAT again, sets up virtual memory, and eventually reaches a command-line). The "OS" design is a little odd, mostly Unix-like shell and POSIX-like APIs, but some amount of DOS/Windows inspired stuff as well... ( So, almost sorta like a Cygwin-like OS. ). Also, EXE's/DLL's are checked first in CWD, then using PATH (more like in Windows). Well, nevermind some parts inspired by the Doom and Quake engines, etc... The LZ4 compression is mostly because reading stuff from the SDcard is slow, and LZ decompression is faster than reading more data. I also have my own LZ compression format (RP2) that I use a lot as well, which compresses "general data" slightly better than LZ4 (at a similar speed), but LZ4 seems to get better compression for machine-code with my ISA. Not using Deflate mostly as it is too slow for this use case (comparably, LZ4 is a lot simpler and faster). One other major change was that the PE/COFF ".rsrc" section was mostly replaced with a variation of the Quake WAD2 format (but using RVA's as offsets and with a different header, and contents are still able to be addressed from C code). I didn't really "get" the design for the original resource section, and a WAD2 variant seemed simpler and made more sense. Still mostly being used to store BMP/DIB images and similar though... Header design is partly backwards compatible, so the original section format could be restored if needed. Granted, even BMP is tweaked: There is a ' BMP' format (vs 'BM'), which differs mostly in that the headers are 32-bit aligned (and image data is aligned to a 64-bit boundary). Along with a hack to allow indexed-color images to encode a transparent color (I had a use-case for 4 and 8 bit BMP images with a transparent color, ...).
@@SimonBuchanNz Yeah, there is a lot going on in there. In my case: Didn't need the MZ stub, since my binaries aren't going anywhere near DOS, and can't load on Windows anyways (different OS, and entirely different architecture, with a 0xB264 Machine Type, and the PE32+ format, in my case), so I left them off. Still keeps most of the other PE/COFF structures intact though (of the parts I am using). Can note that my ISA is still little-endian, so this much is still the same at least. The Global-Pointer entry in the Data-Directory was unused on mainline targets, but I used it to both give an address to initialize the global pointer (my ISA uses this), as well as to define a separately relocatable section (the data/bss sections may be relocated elsewhere for each program instance). This does add a little wonkiness to applying base-relocations though. In the ABI, a mechanism is used to daisy-chain all the global-pointer sections for all of the PE images in a given program instance, so from any of the images, it is possible for them to access a table through this register and reload their own global pointer (this also allows for multiple program instances in a shared address space). Import/Export is always by name in my implementation (import/export by ordinal is not supported). The original resource-section design just didn't really make sense to me, so I basically just used the top-level to point to a WAD header, which points to a WAD directory. So, in this case, each resource/lump is identified with a 16 character name, with a key into a table of FOURCC's for the lump types. These WAD entries are exposed to C land with symbols of the form "__rsrc__lumpname". A file is given to the compiler which tells it how to import and convert the resource files and associates them with lump names. In all though, I felt PE/COFF was a better fit for what I wanted to do than ELF was, so I went with this (and the handling of shared objects in ELF quickly takes a detour into absurdity, IMHO). Early on, had considered an LZ4 compressed Mach-O like format, but then in design realized it would have little real advantage over just using inline LZ4 compression on PE/COFF. The compiler first generates an image in uncompressed form, and then compresses it (emitting the LZ compressed version if it is sufficiently smaller). The loader design as can be noted in this case, is to read in the compressed image 1K at a time, and then decompress it into the target address (using the destination as the sliding window); continuing to load and decompress blocks until the image is loaded. After this, it then applies base-relocs and similar. Note that the LZ compression and decompression needs to respect the 1K chunking for the image to decompress correctly (so, this use of LZ4 is non-standard in this sense). If not for the file-offset==RVA constraint, it would be needed to first decompress the image to a temporary location and then copy the section contents to their final load addresses. Adding this constraint can sidestep this issue (and even for uncompressed images, one would either still need to either use a temporary location, or have access to a file-system driver capable of "fseek" or similar; rather than being able to just use a naive FAT chain walk or similar). As for "Why should LZ compression matter"? Mostly it was a case of running an SDcard in SPI mode at 5MHz was "not exactly fast". And my Verilog simulations run upwards of 1000x-1500x slower than real time. So, shaving down the loading time is a lot more obvious when every second in simulation is a good part of an hour in real-time (though, I have since boosted the SDcard to 12.5MHz ... or around 1.5 MB/s).
Fun fact. Many years ago, I was in a band called Ctrl Alt Del and we received a cease and desist letter from Microsoft lawyers, about the name. Our manager advised us to just change our name...
Wow you made me nostalgic for 1975 when i built my Altair. I had no idea what i was doing. Five years later i was writing code for the phone company. That was a weird and fun time for me.
Software Engineer here, who was fascinated with these boot sector shenanigans when I was a kid on my 286. Stoned, Keypress, Brain, and various others were common in those days. I didn't know what a virus was since I came from the 8 bit world... My love of these things in a curious way led me to become a software engineer and get a Master's degree in Cyber Security. Anyone else follow a similar path?
I always figured the first bit of code loaded was from a specific address that was hardwired for the ecu to read from. Never thought about the ecu being fast enough to read before the power supplies could get stable. I would have stumbled a lot back then, but what a time to be alive it would have been.
As I was once told, the term bootstrapping is associated with Baron von Münchhausen (who was a pathological fantast) who once told a story that he was stuck in a swamp and managed to pull himself out by his own bootstraps.
You Touched on this already, Dave, but I love that phrase “to pull oneself up by one’s own bootstraps”. Well in the 19th century that phrase is meant to denote an impossible task (conjuring a funny image in one’s mind). Then in the mid to late 20th century, I think the phrase more implies a relatively difficult task accomplished. So it is like a major achievement to pull oneself up by one’s own bootstraps. Or verb bootstrapping means the same thing.
Great video and excellent explanation. Can you maybe explain how software is actually executed? For me it's always magic how some electric circuits can print "Hello World" onto a computer screen.
If you want to go real deep, there's a really great playlist by Ben Eater where he builds an 8-bit computer on a breadboard using basic logic gates, explaining every step on the way up starting from transistor physics.
Thank you. Very interesting. Like your content. I'm sitting here with my two granddaughters, one using a chromebook and the other one using a Windows gaming pc. When they are not both on their phones. We have a lot to thank you early, guys, and all the hard work. To make it all happen.
@5:30 as far as I knew, the "top - 16 bytes" of the 1MB memory on an x86 is 0xFFFF0 which is normally shown as either: F000:FFF0 (or less usually FFFF:0000) Addressing FFFF:FFF0 would result in code being run from somewhere else in the F000 segment.
The 8086 and 8088 started at CS:IP = FFFF:0000 - physical address FFFF0 The 80286 started up at F000:FFF0 - same physical address For the 80386, the startup physical address was FFFFFFF0 - not normally accessible in Real mode, so the processor would have had to initialise the CS descriptor with a special base address to make this happen.
You know what's funny about that term "boot(ing)" Back when we (my parents' family with us as kids) got our first computer, I was just 8. I didn't know the "bootstrap" explanation back then and I thought this "booting" was some odd way of meaning something like, "Kicking it into motion with the toe area of your boot"! Heh....
Back in the 1980s I ran a chemistry laboratory instrument that was controlled by a PDP-8. To start that up you used the front panel switches to input a program that enabled the paper tape reader on a connected ASR-33 Teletype machine. The rest of the operating system and the instrument software was loaded through multiple paper tapes that had to be read in one-by-one. Our software library was a box full of 35mm film cans each holding a single paper tape. When the instrument was finally decommissioned the PDP-8 went to the university's technology museum. (PS: After reading what I just wrote I realized how very old I am.)
Did it have core memory?
Happens to all of us. Sounds like you lived a good one.
@@AlistairGale I think it used core, but after 40 years I can't be sure.
We went to the same school. I was fat fingering the same pdo-8 in 1973
I still have the papertape of my PDP-8 University work. 1978. Yeah, life was good. (M67).
Hardware engineer here. Usually, reset lines are active low, so to reset a chip, the reset line is pulled to ground. I believe that to be an artifact of when BJT transistors were still used, and NPN transistors were both faster and had a larger current capacity than PNP transistors. So pulling a line low was easier than pulling it high. You can check old 74 series logic data sheets and see that the current sink number was typically a lot larger than current source.
was about to comment that :)
Also, with active-low, the device can be held in reset (or a similar sane state) as the power rails are coming up on startup.
@@mg30ebay modern machine. powergood on atx is low until psu delivers fine power. tie it to reset and the psu does all that for you. "for free" :)
An added benefit is in case of a power dip. A power dip can throw a CPU (or any other digital logic chip for that matter) into an unknown state. If the reset line dips, the CPU would reset and go back to a known state.
Yes, bipolar NPN-transistors. But also the n-channel enhancement mode field effect transistors that was the basis of early µ-processors, before symmetrical CMOS took over in the mid 1980s.
Just sat down and watched through this with my ~20 year old son who is just starting out in an IT sys-admin career. I think it took us a good hour of pause-restart to get through the whole video, but I think he now has a better understanding of some fundamentals that are not normally taught in modern computer courses.
Thanks Dave!
Very welcome! For me its these little fundamental pieces of knowledge that can be the hardest to come by!
That was my first surprise interview question to the candidates while hiring to PSS in the late 90's. People would come prepped with all sort of things about SQL, Exchange etc but when initially confronted with this "basic" challenge, many would just freeze and needed few seconds to boot up and come back to life:) . At least for me it was a great way to understand how much deep the person could go for troubleshooting in the future if needed.
As an apprentice, I asked our top software engineer where does the H8 microcontroller know where to get my code from? He called hitachi and ordered a ton of documentation for me. I believe he mentioned that I’m the 16 year old kid in the R&D office. They were kind enough to send me a complete hardware emulator and i let nobody touch it until i graduated. I believe that thing was very expensive but the products that little boy designed are still in operation today. I saw one during a visit to a pharma company and said i wrote the software as a child haha. Luckily i added an easter egg that showed my name on the 7 segment display
That's so cool!
Now that's a story to tell your children 😊
I don't know how you could wrap your head around this stuff at 16, you must have been exposed at a very young age. When I was 16, I was able to make only stupidly simple programs in quickbasic and visual basic and was learning the basics of electronic circuits. I couldn't grasp basic concepts like why i needed to use pointers, it was hard to find documentation or books that explained it in a way that clicked.
Years later, I found Ben Eaters 8 bit breadboard computer videos and built one. Everything finally started to click, but already mid 30s working full time, just didn't have the time or energy to take programming further. Maybe my brain just wasn't made for it. I still don't understand how people that young were able to make sense of very advanced programming concepts. Maybe I'm just fucking retarded
@@mikeb1596 fuck, you're WAY ahead of me. I could program Madlibs in BASIC as a tween, but I was too lazy/scared to try graphic programming. That's as far as my programming journey ever took me.
@@mikeb1596 Well, it's all just a matter of exposure. My dad showed me Pascal at the age of 11 (somewhere around 1995). He only showed me the basics and at that time I barely understood english so I couldn't make much sense of it at first. However my first english words which I actually could type quite fast were things like "implementation", "interface", "record" and such things ^^. The help that shipped with Turbo Pascal 7 (in the fantastic Turbo Vision TextMode based IDE) was all I had. So I just made myself familiar with the most basic stuff at that time. So console input / output, file input / putput and some basic graphics with the horribly slow BGI drivers under dos emulation on a win95 PC. I got a few books on some system internal stuff which helped a lot. I saw my dad only a few days every couple of month. So each time he showed me some small tricks and details (like memory segment B800 which is the textmode screen buffer). You can do a lot with just those basic stuff.
Later I naturally switched to Delphi (since it is based on Pascal) and since I now had a 96k modem I actually had occational internet access. Though dailup connection was quite expensive so I didn't have that much time. Though I found the excelent NeHe (Neon Helium) OpenGL tutorials. They had example code in 20 different languages, including pascal / delphi. So at the age of 16 I already had a quite good foundation on the hardware and some of the software interfaces. Though I have to say that back in the old days, the hardware was a lot simpler so it was way easier to understand how it works. Though back in the day I usually was just scratching on the surface.
I had an apprenticeship as an electro mechanic at the german postal service "Deutsche Post". After the 3 and a half years a friend of mine who continued to work for the postal service as a service technician ask me if I could write a "simple" software that would replace an excel script that used VBA to receive text over a serial interface that was meant for dot matrix printer which was used to capture error messages. That PC was connected to a radio that could be operated over another serial port. The script was simply playing wav files according to the system error and broadcast it on the radio.
Of course that system was horribly limited, especially since error messages also had a "solved" message so when errors piled up it couldn't keep up. I wrote a delphi program that received and parsed the messages, put them in a nice color coded list view and automatically matched the solved messages with the actual errors. It queued the messages up to be broadcast on the radio. Over the years the system grew. The radio had some handshake messages so we could detect if there was other chatter on the radio. So we implemented some timeouts to ensure we don't interrupted human communication, The radios even had 5 buttons which could send a 5-tone sequence that the radio could detect. So we even added the ability for the technicians to acknowledge an error or to make the system repeat the last one. I actually used a text-to-speech system to "read" the error on the radio. I setup a quite extensive config that allowed the technician to specify replacement messages. Tons of special cases were added. Like when an emergency halt button was pressed, the system usually generates tons of errors and in that case they should be suppressed and stuff like that.
AFAIK this program is still in use to this day :) I wrote the initial version in 2008 (just checked my history txt) and the lates update was in 2019. At that time they got a new radio system and while it was mostly compatible, the busy detection suddenly failed because it was signalled differently. At that time I hadn't used delphi in years since I completely switched to C#. Though it's kinda amazing that the same piece of software is used for over 15 years on a daily basis. Fun fact: other parcel stations which had the same (old) system asked around 2010 if they could also get this software. Since I just made that in my free time to help out my old buddy, he ask me to integrate a simple "license" system. We didn't charge any money, but we wanted to make sure that we know how many stations were using it.
That's one of my old software stories :) It was a fun time back then. Systems were so much simpler (and a lot more insecure). Nowadays we struggle with writing shaders or high end graphics stuff. That's how I ended up using Unity for about 12+ years now. Though you learn something new every day. There are so many programming languages out there and so many systems, frameworks and technology that it's impossible to keep up with all of that.
Thanks Dave, very informative. As a Software Engineer, I totally failed an interview question "What are the steps that occur when a computer boots up". Next time I will have a much better story to tell.
I wonder if the interviewer was the other commenter here talking about how this was their interview question 😂
@@SimonBuchanNz Or the secret NZ author of the Stoned boot sector virus
I actually did not know about the reset line, and thought the bios chip somehow prepared the CPU directly.
first time watching one of your vids, immediately got the feeling that this was a man, probably towards the end of his career, educating the younger generations in a very entertaining and engaging way! I don't even know why I'm commenting but I'm sure I'll like that video.
This brings back memories. Back when the first IBM PCs first shipped I wrote a little TSR to make duplicationg diskettes much faster. I had to deal with low level issues like the 64k DMA transfer limit. Mucking around with the hardware at a very low level was a lot of fun!
Ah yes, mucking about in the Interrupt table and learning all the nuances of the Intel instruction set ...
Having been in IT since the days of the first PCs, I enjoy watching your videos. They're very informative and entertaining. Thanks for the time and effort you put in to bring them to us. Your mention of The Friendly Giant brings back memories of the occasional sick day when I was in my early elementary school years. I remember flipping around the TV dial (yep, I remember dials on TVs), and finding this program on the regional PBS station. Good memories from a bygone era. Also, love, love, LOVE the LEDs you have set up in your gadgets and gizmos. Thanks again!
The mention of the "Stone Virus" reminds me of one of the earliest books about computer viruses and AI, "The Adolescence of P-1", by Thomas Ryan, 1977 AKA from way back.
If you *really* want to know how to build and bootstrap a microcomputer, Ben Eater's series on building a breadboard computer might be for you. Goes to a level of detail that should satisfy most anyone - both in terms of hardware and software.
I had the same thought. It was a fascinating series.
An additional interesting thing about the original IBM PC was that if no bootable disk was found it would load Cassette Basic from ROM. Thus, early compatibles, not having Cassette Basic could give the error 'Cassette Basic not found ", rather than the later error of "No Bootable Devices Found".
Thanks this brings me back memories. I remember during my high school days, the computer lab teacher would remove me from the class as I was one of only kid in school who understood about boot sector viruses. He just excepted me from the classes, as I also gave him grief whenever I ask questions or propose better code. So I sat in a corner and help fix the schools virus issues. I have a known disk that has no viruses and write protected. I then would get most of my classmates disks, go through them and using DEBUG to copy back the boot sector to its original address. I also can easily when there is boot sector virus, when you open the PC case, you can see drive A: head will move differently when an infected disk is booted, you can clearly see that will go the beginning cylinders initially but moves to end to load most of the real boot sector.
One reason BIOS Booting went: BIOS -> Boot Drive -> MBR -> Active Partition -> Partition Bootloader -> OS Bootloader, was simple size constraints.
You needed quite a bit if space to store a bootloader that is capable of properly reading and writing a full filesystem. There was just no way to fit even partial reading before the Partition Bootloader.
UEFI has much more storage space. So now we can write the OS bootloader directly into it. Sidestepping the whole MBR Relay Race.
You make such great, compendious videos that still somehow only take up 15 mins of my time.
I don't know how you do it but I'm glad you do.
Compendious is a great word.
I've never heard the word "compendious" before. Thanks for helping me learn a new word today! 😊
He talks fast for my slow mind. I am old.
Ahh the memories of the "sneaker Net" I used it for a long time, (late 70's through early 90's) and still find uses for it on occasion today for things like family information and such.
Canadian nostalgia to my early 1980's childhood:, both the friendly giant, "Look up, waaay up," and I have to assume a throwback to Stampede Wrestling with Ed Whalen's famous line. You better "batten the hatches and lock the doors, because it's stampede wrestlin' time once more!"
I remember booting an HP1000 by switching its register buttons. The software was loaded from an HP2645 terminal by a cartridge. That minicomputer was used to control a Westinghouse OMR (Optical Mark Reader).
For years I have thought that this subject would make a great reference book. So much happens at boot time and knowing that can really help you speed things up. thanks for taking this on!
Thanks Dave, another great tutorial. We used to refer to the IBM PC power switch as the BOSS -- Big Orange Shutoff Switch. Could you possibly make a session on PROM, EPROM and BIOS--What they are, where they are and how they are made. Keep up the good work.
Up to the 2Mbit bios, don't forget the eeprom also retained the uv window under american megatrends foil label.
In the early days of PDP8s and 11s we would usually key in an actual program - typically 10-15 instructions long - that could read from a card reader or paper tape reader. So we’d load up cards or tape with a bootstrap program that could then read from a hard drive if you had one.
Yes. I only got to play with a salvage vintage PDP/8 back in the 1980's as a teenager. It had a boot sequence called a RIM loader that had to be keyed in octal using the front panel. This would fire up the paper tape reader which would be loaded with the bootstrap tape. That would enable and run the mag tapes one of which had a rudimentary OS on it. Only then would the terminals flicker to life and also enable the hard drive to run DEC OS or whatever. That HDD behemoth was less than 1MB, weighed a ton and took up half a rack.
Never done that on a PDP-11
They always just booted into RSTS/E on power up.
@@Drew-DastardlyErr. In my lab, only after the first keyed-in bootstrap routine could control be transferred to a teletype thingy with a punced card or tape reader.
Only then would life be reluctantly granted to the monitors and keyboards.
PDP 11-45? That was around 1978.
I recall editing paper tape with sticky tape and a paper punch. Splicing just like movie film. Obviously one needed to have a thorough knowledge of ASCII code to do the job. I just was a maths student not the actual computer manager!
The good ole days. Never looked back. But i do remember fondly how I learned to even get these contraptions to work. The lights still mesmerize me though.
Always like the Friendly Giant outro. Brings back memories. Thanks Dave.
Your UA-cam channel is the greatest thing to happen to me in a while. I bought an ESP32 and am so excited to program it with VS Code.
A video discussing disk partitioning and how that dovetails with this piece would be interesting. Especially given the myriad of historical disk partitioning schemes. MBR and GPT would obviously be mandatory, but it might be fun to look at others, both historical and extant.
After that, the one that really begs for your elucidation is the dark world of FILE SYSTEMS.
Oooooo... Scary. Lions and tigers and bears.... FAT8/16/32, NTFS, ReFS, ISO9660, and maybe even some of the Linux options like Ext2/3/4, XFS, ZFS, etc.
I'm curious how the BIOS knows how to boot from an NVME drive, since it's a PCI device rather than a SATA drive
@@maxstr If I'm not mistaken I think the modern UEFI systems today are required to boot from NVME and it will read from that PCI Express lanes instead of the SATA Bus lines. It doesn't recognize it as a SATA unless if you're specific NVME or SSD is connected to the SATA ports. Also you may have to modify the BIOS settings to select that particular drive to be the drive to boot from. It may not automatically do it for you. You might have to configure the BIOS.
@@maxstr At the abstract level, an NVMe device is a storage controller, just like an AHCI SATA controller or many other types. It can accept commands to read and write blocks and do other things.
If the BIOS or UEFI has drivers to support the device, it can expose it through its storage APIs.
In fact, I have an older motherboard here with an M.2 slot that supports PCIe drives. If you plug an NVMe drive into it and boot an OS with an NVMe driver, it will see the drive normally, however UEFI is unable to boot from it as it doesn't have a compatible driver.
Once, I was reading something about modifying BIOS images to add drivers to them. I didn't go through the process, but I did manage to download an NVMe EFI driver and extract it. I started the built-in EFI shell, loaded the driver and the NVMe drive showed up in the list, as expected.
@maxstr Late reply. IIRC, the pre-UEFI BIOS points to sector 0 of the boot device to execute the bootloader. It doesnt care what type of device; they all get presented to the system as block devices. What happens next is based on your bootloader.
Back in the 80's I worked on the Docutel ATM's that were controlled by a computer with front panel switches like the Imsai, that had Core memory. to load the Operating system we would insert a loader board into a Bus Slot and manually enter a 15 instruction boot program into memory then plug in a cassette tape recorder with the program on a cassete into a audio jack on the loader board, then start play on the player then press run on the panel switches to run the boot loader program. Once the tape had played the recording (OS), I would stop the boot loader power off the computer remove the loader board power back on the computer press stop on the front panel switches. enter a memory start address into the program counter register then press run to start the OS. If the system didnt start correctly, we stop the the cpu examine memory loacations by using a memory dump listing and fixing loations with the wrong values then change the program counter back to the program start location and try agin. My How things have changed since then !
I love the detail you've gone into on how a computer boots up. It was also a blast from the past, I remember getting the "Your PC is now Stoned!" message!
I like this episode's musical choice. I'm not big on classic rock, but dark synthwave I can get behind any day.
Hey David, I’m working on my bachelors for CS. Love hearing your take on all these topics
Dave, these kinds of videos are great for even IT profesionals. Like you, I came up on computers that pre-dated DOS, but as an IT executive now, I find my staff is unaware of this level of detail about how computers operate which sometimes prevents them from theorizing about why computers may be misbehaving in particular ways. Thanks for another great video. Sure wish I could have worked with you back in the early 80s and onward.
Great video! I miss the IBM PC keyboard. The tactile click of it was great - but a little noisy.. The Friendly Giant reference brings back memories too!
Clarity. This structured and interesting video was mostly stuff I knew already, but it nicely filled in some gaps in my knowledge, for which I am very grateful.
Hi Dave, great video!
Not trying to be an arrogant prick but i'm pretty sure there's a mistake at 5:24. The reset vector on a 8088/8086 can't be FFFF:FFF0h because on those CPU's there's no A20 line and setting CS to FFFFh and IP to FFF0h would immediately wrap both registers to 0000h. Starting from the 286 CPU i'm sure setting CS and IP like that would make the A20 line set the physical address to the end of the HMA area minus 16 bytes.
So on a 8088/8086 the vector MUST be by setting CS at F000h (start of the last real mode segment) and IP to FFF0h. The alternative would be setting CS to FFFFh and IP to 0000h. Both methods point to the same physical 20-bit address of FFFF0h.
I'm absolutely 100% convinced that you are aware of this and that it was just a mistake.
FFFFFFF0 is not FFFF:FFF0, nor did I claim it! You can use segment-offset to reach FFFFFFF0 without any overflows or A20 line, right? Or at least I thought so!
Freaking love this. Great work. Technology has come so far in such a short period. Thank you.
The Friendly Giant stuff is great...thanks Dave!
Back when I was a pc repair tech this was like the only thing that ever stumped me, like after the reset switch but before all the things
Back in the dark ages, I was the "computer expert to call" at the local talk station. I remember one early morning when the activation date for a truly nasty virus hit. I had said that as long as you had a reliable antivirus running with current signatures, you should be good to go, but here is what it will do to you if you aren't protected... and described the virus's actions. That is when a guy with an 80286 based system called in to say "I think I got that virus. My computer turns on, but doesn't run the bios." The nasty that he had (and did not have an antivirus to detect) basically totally wiped out his BIOS code which was flashable. So the virus had written junk into what had been booting his machine. I told him since the bios was soldered on to his motherboard, he would need a new motherboard in all probability.
Is that true? I thought most 286 systems still used mask ROMs or maybe UV EPROMS. Either way they can't be programmed from the PC. I'd be interested to know more about what this system was.
@@eDoc2020 Early IBMs had the burned rom that was safe. However, there were a lot of stuff from overseas that had discovered the BIOS from folk here, and that they needed to be able to update them with a flash from a bootable floppy disk. (Phoenix among others.) And the clone motherboard manufacturers needed to be able to update the bios so that they could add new bootable devices.... It had to be able to init all the new stuff that was coming out, and of course, fix any bios related bugs. Some of the early bios systems from the far east were rather humorous... The error on one I had to fix... "Disk not setting OK" for a failure to load a floppy disk... Early Dells needed a chip change for an update. That got REAL expensive for them....
When I started working as an assembly language programmer at the very start of the 1980s, the system I worked on had a 4 step boot procedure. 1., toggle in the paper tape reader bootstrap on the front panel, 2., run that and read in the card reader bootstrap from 8-level punched paper tape, 3., run that and load the operating system from a deck of punch cards. 4., once that was in, you entered the start address on the front panel, hit the run button, and it was up and running. Back then, I knew the card reader bootstrap code by heart - it was half a dozen or so 16-bit words which, of course, I remembered in hex. Sadly, I can't remember it now.
Seeing that switch brought back so many old memories.
Like when there were actually beep codes.
OMG listening to you brings back so many memory's, I used to write in assembly language still got many books on my book selves... started with 8088, think that's right.... thought I was big time when I moved up to 286, 386 machines.... I still have a hole punch for 2.88 floppy's from the 1.44....
Great video. My favorite way to understand the low-level concepts is to look at old electromagnetic pinball machines -- all mechanical/relay logic, literally "hardwired"! When they start a game, the "bootstrap" is a sequence of events making sure everything is in the right state.
From there, it's easy to see how digital versions evolved which could read punchcards or ROMs and "bootstrap" themselves into a usable state
My grandpa was one of the first coders for Payless shoes in the early 70s. He got sent by the company to mit I believe at the time to learn it for a year or so. I remember him teaching me all this stuff when I was little and am still thankful I can understand this old tech. Thanks to my grandpa
Great explanation I love hearing the reasoning behind everything.
I just understood what happens after Living on Earth for 27 years. Thank you very much for sharing your knowledge, I don’t think thank other than a few people who works such industries will ever have the chance to learn more about these systems, over time I felt that the fundamental concepts are being erased. Have a nice day sir , I am from Sri Lanka 🇱🇰
9:42 It should be said that some BIOSes support mouse operation and large hard disks.
Dave, you are a blessing and a legend! Thank you man for all the knowledge that you share so freely. I watched the Friendly Giant as a young boy.
An interesting thing about UEFI which Dave did not explain in this video (he probably knows about it), you can also interact with the UEFI from your operating system, for example to 'tell it' to automatically go into the UEFI-menu after rebooting or to change the bootorder. On Linux with SystemD you could do the first thing by giving the option firmware to the reboot command, on Windows there also is a command for that but I don't know that by heart because I don't use Windows, I have tried it out though it works fine and it is easy enough if you remember the more difficult syntax.
Don't quote me, but I believe that's as simple as a defined setting either in sram or a file on the uefi partition.
ie, the uefi just checks if it's got a voicemail from the OS or not.
Or, the way windows checks for the dirty flag to run chkdsk.
It's not... "interactive" as it were.
In windows the command "shutdown /r /fw /f /t 0" will restart and enter the firmware interface. Not all PCs have the capability though.
Isn't there also the fact that when you are in the UEFI settings your machine is running the MINIX operating system.
@@mikebarushok5361 UEFI is definitely not MINIX. There are rumors that the firmware running on the management engine (ME) in some chipsets runs MINIX, but that's a separate microcontroller.
@@myne00 boot order is done through UEFI variable manipulation. UEFI provides a set of routines at boot time to the OS (UEFI runtime services) and one of those routines allows the OS to modify UEFI variables, including boot order and boot flags. The UEFI partition contains the bootloaders that the bootselector runs.
ye olde CMOS settings are still in (battery-backed) SRAM, although some platforms let you ditch the battery and RTC.
Hey @DavesGarage, I appreciate your expertise and would love to see a video where you explain the specific purpose behind the 'Apply' button and why it was created. It's a common oversight, and I think many users could benefit from understanding that clicking “Apply and Ok” is redundant. The 'Apply' button was created to allow changes to be saved without closing the dialogue box, a detail often missed in instructions. Your experience would make for a valuable and insightful video that I could direct others to. Thanks in advance for considering this request!
.
I want more of this kind of content ;) Seriously, this is great stuff....
I start at Dos 5.0 at 15 years old.. It 's change my Life. Lovo your videos. Cheers 🎉🎉
Dibs on the rocking chair, as long as I can bring along my Strat (my SG is a bit smaller/lighter if drive space is limited). Thanks, Dave ... as always!
This does bring back days of my first gig as a new IT tech for a radio station. Your challenge should you choose to except it:
Get this telephoney system (an 8086 with a MFM 10 meg Hard drive) working again even though the HD was completely full running DOS 6.00
I was able to boot off a 1.2 meg 5.25 floppy and copy everything to a group of floppy disks on a 2nd 3.5 floppy drive.
Load DOS 6.0 on a 286 with a whopping 100 meg IDE HD copy everything back over... transplant the IDE telephony 3 line card into the new computer and
to my complete surprise...
It worked. and continued to work for another couple years until the World Wide Web was a popular thing and this gizmo fell out of use.
Ahhh the good O'l days, miss them to some degree. My poor old Amiga is still sitting in the cupboard with it's 500 Meg hard drive, and a SCSI 500 Meg drive was so massive for one of those I couldn't fill it after 10 years use & it never failed me either, such exceptional technology for the time.
Dave. Hi from this far part of the world! I love your educational series. Seeing your videos is like attending a great university class or course. I will kindly propose to you doing a video explaining how the OS decides if it is going to run in 32 or 64 bits mode. As I understood, this happens after the OS is loading from the designated disk, but how does that works? It will be great to know your take on that. Have a very nice day and keep that super nice work!
It's decided the same way as going into protected mode. And that is a story by itself as the 80286 had a bug that prevented it to back into real mode without a reset.
I love the demo of the old machines. There's something beautiful about them to me.
Coming across this channel at the perfect time. I’m in the middle of trying to figure out if both my RAM sticks are bad (tested both separately), or if it’s something else :/
Anyway, while doing this, I find myself wondering how in the hell computers do exactly what this video is about.
This is my third video and the channel has earned a new sub!
Dave should be a professor at university teaching new generation of engineers. His manner of explaining things are exceptionally good!
I find this absolutely fascinating and I love learning about it, thankfully I was born in Scotland and can study for my BSc Cybersecurity for free!
I didn't have one of those early computers. But I remember the SS-100 and SS-50 bus being mentioned in Byte and Creative Computing. I loved those mags.
Wonderful blast from the past.😊😊😊😊
That IBM switch is indeed pretty sweet!
1:15 - Dave, you're a better man than I . I wouldn't have even THOUGHT of tempting fate by quickly toggling the Big Red Switch that way. :)
The Bootstraps saying comes from the story 'The Adventures of Baron Munchausen'. It is full of tall tales where the Baron is a hero in bizarre adventures. In a story he tells of how he was stuck knee deep in mud. Asked how he freed himself he replied 'he pulled himself up by his bootstraps.' An example of how crazy his tales where.
Great stuff Dave. I grew up with the 6502 (a Commodore 64) and move to DOS PCs. I now have a friend with an Altair 8800 … you’ve tied them all together in my mind.
It’s funny that you say “as simple as setting dip switches.” My son is a computer science major in college, and has no idea what the inside of a computer looks like, as opposed to his father, who used to build custom PCs for customers back in the 90s. I think if you asked my son to set dip switches, his head might explode.
I love the style. It gets in the way. You can make it better so that it is fluid in identity and emotion never needing to break the user's attention.
Dave, thank you
I started an Internship a couple months ago that makes hardware, specifically Linux boards, and even within the first 5 seconds of the video you asked the questions that I had and still haven't fully learned. Same thought process exactly.
I only now just found your channel via this video. I liked and subscribed. Looking at your history, I’ll be busy a long time binge watching many of your previous videos. I’ve been programming since 1976. Thanks for some really great content! This is going to be fun.
In the late 70s at CEGEP (Quebec Junior College) I built an Imsai 8080 from a kit. Many soldering hours later it turned on but we had no memory. After I graduated I was told they bought memory and it worked. 10+ years earlier I watched the Friendly Giant .... and Mr. Dressup, Chez Helen, and Romper Room.
AAah, the Friendly Giant!
As a kid from the 70s and 80s, growing up with a PC-XT Compatible as my first PC I enjoyed the switch-flipping and the Friendly Giant montage at the end.
I'll be sharing this video with my Cybersec. students!
Dave you have very nice pedagogical tools.
Holy sh*t man! THAT IS GOOD CONTENT!!!
At 3 mins in I was amazed that so much info was crammed in on your video! At 7 I had to rewind a couple times to understand correctly but was even more amazed that in less than half of the video you had so much interesting facts that helped me deepen my knowledge, polish it where I was rusty and learn a ton of new things in between!! Instasubscribed!
I follow many great channels but not even one amazed me like you did with the sheer amount of info! And you do this for free?? F'cking amazing!
MS started declining the day you left. Did you see W11 or edge? Man, they need like 10 of you to get things right again!
I hope this channel can discuss the Intel Management Engine (ME) running MINIX at a lower level than the OS. Why is it there? Is it true that it continues running in low-power mode even with the system turned off (but still plugged in)? Supposedly it has TCP/IP access and the computer can be woken up and accessed remotely. It sounds like we don't actually have privacy at all as long as there is an ethernet cable plugged in. AMD has it too, I think it's called, Platform Security Processor (PSP). Andrew Tanenbaum, creator of MINIX, wrote An Open Letter to Intel about this.
The last time I was at the Living Computer Museum in SODO they ran through the startup on an Altair. I was the only one who was there for the presentation.
I miss that museum. :(
Now we're talking Dave.
Great video.
Kinda similar, for my own custom CPU core (and ISA) on an FPGA (personal hobbyist project), the general boot process is sorta like:
RESET pulse, with CPU resetting major control registers to default values;
CPU starts at 0000_00000000, which holds the ROM (48-bit VA, 32-bit PA);
The start address branches to the actual entry point;
It sets up some initial registers, then runs "sanity checks", which verify that most of the core CPU instructions/features are working;
It then sets up the console for text display;
It does a RAM test, followed by a small L1/L2/RAM benchmark, and cache integrity check;
It then sets up the SDcard, reads partition table, and reads the first FAT32 partition;
It looks for a file named "bootload.sys" in the root directory, and if found loads it;
In my case, this file is an LZ4-compressed PE/COFF variant (albeit lacking the MZ header or stub);
The 'PE\0\0' turned into 'PEL4' to signal this, everything past first 1K of headers is LZ4 compressed;
If 'PE\0\0' or 'MZ', it is loaded as an uncompressed image.
Otherwise, this format imposes an Offset==RVA constraint to simplify loading.
The PE image is loaded into RAM (decompressed during load);
The checksum is then verified
Custom algo, as the original PE/COFF checksums were unacceptably weak
The original PE/COFF checksum algo kept missing errors from common LZ decompression issues.
It sets up various registers, and jumps to the entry point.
At this point, the "kernel" does the rest (more sanity tests, setting up console and FAT again, sets up virtual memory, and eventually reaches a command-line).
The "OS" design is a little odd, mostly Unix-like shell and POSIX-like APIs, but some amount of DOS/Windows inspired stuff as well... ( So, almost sorta like a Cygwin-like OS. ).
Also, EXE's/DLL's are checked first in CWD, then using PATH (more like in Windows). Well, nevermind some parts inspired by the Doom and Quake engines, etc...
The LZ4 compression is mostly because reading stuff from the SDcard is slow, and LZ decompression is faster than reading more data.
I also have my own LZ compression format (RP2) that I use a lot as well, which compresses "general data" slightly better than LZ4 (at a similar speed), but LZ4 seems to get better compression for machine-code with my ISA. Not using Deflate mostly as it is too slow for this use case (comparably, LZ4 is a lot simpler and faster).
One other major change was that the PE/COFF ".rsrc" section was mostly replaced with a variation of the Quake WAD2 format (but using RVA's as offsets and with a different header, and contents are still able to be addressed from C code). I didn't really "get" the design for the original resource section, and a WAD2 variant seemed simpler and made more sense. Still mostly being used to store BMP/DIB images and similar though... Header design is partly backwards compatible, so the original section format could be restored if needed.
Granted, even BMP is tweaked: There is a ' BMP' format (vs 'BM'), which differs mostly in that the headers are 32-bit aligned (and image data is aligned to a 64-bit boundary). Along with a hack to allow indexed-color images to encode a transparent color (I had a use-case for 4 and 8 bit BMP images with a transparent color, ...).
Having spent a bunch of time with the PE/COFF format, yeah, it gets pretty bonkers once you get past the standard section mapping stuff.
@@SimonBuchanNz Yeah, there is a lot going on in there.
In my case:
Didn't need the MZ stub, since my binaries aren't going anywhere near DOS, and can't load on Windows anyways (different OS, and entirely different architecture, with a 0xB264 Machine Type, and the PE32+ format, in my case), so I left them off. Still keeps most of the other PE/COFF structures intact though (of the parts I am using). Can note that my ISA is still little-endian, so this much is still the same at least.
The Global-Pointer entry in the Data-Directory was unused on mainline targets, but I used it to both give an address to initialize the global pointer (my ISA uses this), as well as to define a separately relocatable section (the data/bss sections may be relocated elsewhere for each program instance). This does add a little wonkiness to applying base-relocations though.
In the ABI, a mechanism is used to daisy-chain all the global-pointer sections for all of the PE images in a given program instance, so from any of the images, it is possible for them to access a table through this register and reload their own global pointer (this also allows for multiple program instances in a shared address space).
Import/Export is always by name in my implementation (import/export by ordinal is not supported).
The original resource-section design just didn't really make sense to me, so I basically just used the top-level to point to a WAD header, which points to a WAD directory.
So, in this case, each resource/lump is identified with a 16 character name, with a key into a table of FOURCC's for the lump types. These WAD entries are exposed to C land with symbols of the form "__rsrc__lumpname". A file is given to the compiler which tells it how to import and convert the resource files and associates them with lump names.
In all though, I felt PE/COFF was a better fit for what I wanted to do than ELF was, so I went with this (and the handling of shared objects in ELF quickly takes a detour into absurdity, IMHO).
Early on, had considered an LZ4 compressed Mach-O like format, but then in design realized it would have little real advantage over just using inline LZ4 compression on PE/COFF. The compiler first generates an image in uncompressed form, and then compresses it (emitting the LZ compressed version if it is sufficiently smaller).
The loader design as can be noted in this case, is to read in the compressed image 1K at a time, and then decompress it into the target address (using the destination as the sliding window); continuing to load and decompress blocks until the image is loaded. After this, it then applies base-relocs and similar. Note that the LZ compression and decompression needs to respect the 1K chunking for the image to decompress correctly (so, this use of LZ4 is non-standard in this sense).
If not for the file-offset==RVA constraint, it would be needed to first decompress the image to a temporary location and then copy the section contents to their final load addresses. Adding this constraint can sidestep this issue (and even for uncompressed images, one would either still need to either use a temporary location, or have access to a file-system driver capable of "fseek" or similar; rather than being able to just use a naive FAT chain walk or similar).
As for "Why should LZ compression matter"? Mostly it was a case of running an SDcard in SPI mode at 5MHz was "not exactly fast". And my Verilog simulations run upwards of 1000x-1500x slower than real time. So, shaving down the loading time is a lot more obvious when every second in simulation is a good part of an hour in real-time (though, I have since boosted the SDcard to 12.5MHz ... or around 1.5 MB/s).
An exceptionally great presentation Dave. Thank you.
Fun fact. Many years ago, I was in a band called Ctrl Alt Del and we received a cease and desist letter from Microsoft lawyers, about the name.
Our manager advised us to just change our name...
Wow you made me nostalgic for 1975 when i built my Altair. I had no idea what i was doing. Five years later i was writing code for the phone company. That was a weird and fun time for me.
Software Engineer here, who was fascinated with these boot sector shenanigans when I was a kid on my 286. Stoned, Keypress, Brain, and various others were common in those days. I didn't know what a virus was since I came from the 8 bit world... My love of these things in a curious way led me to become a software engineer and get a Master's degree in Cyber Security. Anyone else follow a similar path?
I still love the Friendly Giant intro/exit scene.
I love your intros Dave it's like watching 60 minutes or something.
That was a very intriguing explanation, thanks for putting this together!
That's a pretty nice switch you got there Dave.
I will forever remember you as the task manager Dave
I always figured the first bit of code loaded was from a specific address that was hardwired for the ecu to read from. Never thought about the ecu being fast enough to read before the power supplies could get stable. I would have stumbled a lot back then, but what a time to be alive it would have been.
Funny that I made my first boot sector virus in 1990. All good memories coming back with your video
dave your content is so killer. you've mastered this format
Questions I've asked myself my entire life! Seriously!
Never has something so over my head been explained so interestingly. If you know what I mean.
Great as always, the outro has me looking forward to next time.
As I was once told, the term bootstrapping is associated with Baron von Münchhausen (who was a pathological fantast) who once told a story that he was stuck in a swamp and managed to pull himself out by his own bootstraps.
You Touched on this already, Dave, but I love that phrase “to pull oneself up by one’s own bootstraps”. Well in the 19th century that phrase is meant to denote an impossible task (conjuring a funny image in one’s mind). Then in the mid to late 20th century, I think the phrase more implies a relatively difficult task accomplished. So it is like a major achievement to pull oneself up by one’s own bootstraps. Or verb bootstrapping means the same thing.
Great video and excellent explanation. Can you maybe explain how software is actually executed? For me it's always magic how some electric circuits can print "Hello World" onto a computer screen.
Great suggestion!
If you want to go real deep, there's a really great playlist by Ben Eater where he builds an 8-bit computer on a breadboard using basic logic gates, explaining every step on the way up starting from transistor physics.
Hi Dave. I love your stories of old gear and you getting them operational.
Speaking of old working gear, do you have a working platter drive?
Thank you. Very interesting. Like your content. I'm sitting here with my two granddaughters, one using a chromebook and the other one using a Windows gaming pc.
When they are not both on their phones. We have a lot to thank you early, guys, and all the hard work. To make it all happen.
Finally! Someone answers the questions apparently only I have been asking!
Go through how the front panel works on old Aitair/Imsai ... I did that back in the '70s and was amazed.
@5:30 as far as I knew, the "top - 16 bytes" of the 1MB memory on an x86 is 0xFFFF0 which is normally shown as either:
F000:FFF0 (or less usually FFFF:0000)
Addressing FFFF:FFF0 would result in code being run from somewhere else in the F000 segment.
The 8086 and 8088 started at CS:IP = FFFF:0000 - physical address FFFF0
The 80286 started up at F000:FFF0 - same physical address
For the 80386, the startup physical address was FFFFFFF0 - not normally accessible in Real mode, so the processor would have had to initialise the CS descriptor with a special base address to make this happen.
You know what's funny about that term "boot(ing)" Back when we (my parents' family with us as kids) got our first computer, I was just 8. I didn't know the "bootstrap" explanation back then and I thought this "booting" was some odd way of meaning something like, "Kicking it into motion with the toe area of your boot"! Heh....
Funny thing is the on Amiga you got something called the _kickstart_ as the booter. Kicking away for games to start.
i remember you as Task Manager Dave. Great video again thank you.