Talk about a blast from the past! When I was a teenager (pre-internet), I remember fighting with DOS and reading deep into manuals to squeeze out every free byte of RAM for my games. It could be quite intricate, and it took a while. It was almost like a game itself to find the right combinations.
I agree it felt like dark wizard magic. Now I just use some configuration files from Phils computer lab. It was finally able to get some games working I never did.
this is neat. this was the explainer i needed 20 years ago. this is a summary of my decades of confusion and learning and 'eventually sorta getting it'. its great to see this all summarized in this way. it really is the top of the pyramid for an explanation of all of this history.
I'm very glad it's valuable to you, and that makes it worth having produced. I was able to get around pretty well to do the things I wanted to do, but I didn't have as much info at the time either; no WWW yet.
Great video. This is so nostalgic. I fondly remember messing with himem.sys, TSRs etc. as a kid. At the time, I didn't really know much about real vs. protected mode though. I hope to see more like this.
yeah, exactly my thoughts now, but at the time it was a pain in the ass to free up enough convetional memory for really old games. also had selection menus at boot for different configs, depending on which game i will play. the problems was restarting whole PC when you needed different config for another game.
It's kinda weird to see the use of the kibi- & mebi- prefixes in a DOS video since these weren't a thing then and primarily a construct by the hard drive industry given (il)legitimacy by the IEC to redefine the kilo-, mega- etc. prefixes.
I also find they're pretty awkward to vocalize. But they're the best way to avoid any ambiguity, to my knowledge. Time will tell if I'll persist with this approach.
Redefine? Kilo is an SI prefix that always meant 1000. Programmers tried to redefine it because 1024 is "close enough" to 1000, and it's fine for casual speech, but this attempt had no legitimacy at the SI.
@@thewhitefalcon8539 Everyone understood that a kilobyte was 2^10. Much of the industry still abides by this. HDD manufacturers liked to over advertise their capacity. RAM companies did not.
@@majorramsey3k Everyone understood that kilo was 1000. Much of the industry still abides by this. RAM manufacturers liked to confuse people. HDD companies did not.
@@thewhitefalcon8539I think KB and MB were defined distinctly, at least at the later point when KiB and MiB were defined. Anyway it’s news to me that DOS had a limit of 640 KiB not 640 KB.
In this context (IBM PC compatibles), the 80186 is quite uninteresting; it has a couple of new instructions, and the same 16-bit data bus as the 8086, but no new addressing capability. It was also rather rare, with some other chips like NEC V20 being far more common.
First time I've ever heard someone unironically say "mebibyte", but good high-level explanation of a low-level topic. High level because questions segment/offset and selector/offset weren't discussed, nor why some things require you NOT run EMM386 but might work if you had an EMS card installed, how DOS could see memory above 1MB in real mode, why load order mattered as much as memory locations for where drivers went in memory when running memmaker, etc? That sort of thing … For how "simple" it is, MS-DOS memory management was a BIG topic. Might be too low-level for your audience though.
The evolution of the x86 CPUs and the DOS memory model around it makes the topic big, as I found when I was researching this. It was a lot of work to maintain accuracy and reduce the details down to an introductory video. The details you mentioned could be interesting topics for videos of their own. I agree with your assessment of the video as a high-level explanation, and appreciate it, because I was going for that. As for my audience, my content is targeted at people who appreciate low-level computing topics; see my OS development and disassembly stream videos. I've gotten a big influx of subscribers and comments on this video lately. No idea what the source of it is, but I appreciate it. I haven't 100% found my focus for this channel yet, but I am still working on content for it.
Windows 3.1 still ran fine in 286 mode. It would even default 286 mode if you did not have much RAM, and at least with not much memory, it would actually run faster in the 286 mode (I know that because we had a computer with 2 MiB RAM). But you did not get the full features, like virtual memory and pre-emptive multitasking of DOS applications.
@@ctvxl note that I specifically said DOS applications. Windows applications used cooperative multitasking until Win95, like you said, but DOS programs in 386 mode were running virtualized in Win 3.1, and they were executed with preemptive multitasking. This might sound a bit weird, like the DOS programs being executed in a sense in a more "modern" way, but DOS programs were not implemented with multitasking in mind, so the solution needed to be a bit more involved.
@@fintux Yes, true. Dos apps running in Windows 3.1 were indeed virtualized and preemptively multitasked against each other. I actually had forgotten that. I learned about it many years ago when I became MCP certified on Windows 95. The course I took explained that factoid when comparing multitasking in Win 3.1 to 95. It's been a VERY long time :)
Personally I don’t mind the use of MiB and similar terminology to be clear that you’re talking about base 2. Even if it is the HDD manufacturers’ fault we live in a world where MB and KB is ambiguous now.
@@SnakebitSTI Really? Back in the 1970s 8-bit micro era of computing a computer with 32kilobytes of RAM had 32,768 bytes of RAM. The processors (6502, 8080, Z80, etc) could access up to 64 kilobytes, or 65,536 bytes of memory. Then you had floppies[1] of 180 kilobytes, 360 kilobytes, 720 kilobytes, 1.44 megabytes all with the capacity based on 1 kilobyte = 1,024 bytes, 1 megabyte = 1024 kilobytes. The manuals for the GEC 41xx processors of the 1980s refer to accessing 64 kilobytes (65,536 bytes) of memory (in four 16 kilobyte (16,384 byte) segments). In every case (in the computing world) it was understood that 1 kilobyte = 1,024 bytes. That is until HDD manufacturers came along and decided to use the base-10 prefixes to bytes, despite bytes not being a base 10 unit - a byte is of 8 bits and can store a value between 0x00 and 0xff (0 and 255). [1] the unformatted, raw, capacity was higher, but bits _[sic]_ of that raw capacity is needed to mark the sectors, etc. Thus a 2Mb floppy only gave 1.44Mb when formatted, a 4Mb floppy only gave 2.88 Mb formatted to IBM/DOS capacity; a 4MB floppy gave 3.2Mb formatted capacity on QL quad density drives.
1:58 you forgot the 186 2:33 the 286 was only mostly compatible, it didn't roll over at the 1MB limit like the 8086/8088 and 186, which is why the A20 gate was needed 3:00 the 386 can run real-mode apps in protected mode using virtual 8086 mode
Popped up recently for me too. I don't think HIIMEM or 286 can do UMB mapping though, that needs EMM386/QEMM and the v86 capability of the 386. I might be misremembering, but I think expended memory or LIM EMS (Lotus Intel Microsoft) was originally intended to allow bigger 123 spreadsheets RAM on an ISA card was mapped into (original spec, a 64k page frame of 4x 16k pages) similar to the way 8 bit home computers mapped extra ROM and RAM.
The difference between the 8086 and 8088 is that the 8086 has 16 of it's address pins duplexing as data pins, while the 8088 only has 8 of them duplexing as data pins, but they are otherwise identical. This means that the 8086 is capable of accessing it's memory 16-bits at a time instead of 8-bits like the 8088. What I'm curious about is whether or not any motherboards actually implemented this. Given that the 8086 was more popular among business-oriented machines, I'm guessing somebody did, but I'm not familiar with any specifically.
From my experience the memory area above 640 Kb was only available as RAM when a memory manager program like 386MAX or QEMM was installed. DOS 5.0 and higher has a similar memory manager included. Plus you could only do this on a 386 or higher CPU. There were some DOS games that needed this because they needed 600 Kb+ of RAM to run. These memory manager programs also supported the EMS memory interface in software by reserving a 64 Kb UMB area. They also scanned the entire upper memory area to map all free UMB's which included unused areas that were reserved for the system BIOS Typically these programs would load device drivers and TSRs into these recovered UMBs.
The first KB was not occupied by the BIOS. It was RAM and was the BIOS Data Area (BDA); the values were populated by the BIOS. The first KB was actually the Interrupt Vector Table (IVT), then came BDA values for items such as COM/LPT port addresses, memory size, keyboard buffer, soft reset behavior, etc. MS-DOS boot sector would load initial code to 0:7C0, and would use 70:0 as the DOD data area.
I don't go into that level of detail in the video, but had intended all those things, not only BIOS code, to be included in what I call BIOS. What you say is true, of course. Thank you for specifying.
I still rember doing multiconfig on clients computer so they choose according type of memory for specific game or application. I was also quite good (better than memmaker) in fitting drivers and dos in high memory.
I remember back in the day having a 20MB 386 that was tricked out, and having to have a multiple choice config / autoexec depending on what I needed as I didn't have enough base / umb / himem to get all of the drivers in and be able to run a half decent dos game. one config also had a 16MB ram drive that copied games I would play into it and run the game from ram. it was a long copy time, but games ran fast.
No mention of how DOS keeps track of blocks of RAM - there is a 16-byte area in front of each allocated chunk, with links forward and backward to the next and previous allocations. Being in real mode, any program can follow these links and work out what else is going on in the machine.
You completely forgot to mention unofficial "unreal" mode, where you first switch the CPU to protected mode, extend the segments to 4GB and switch back to real mode. Boom, you can now access full 4GB of RAM from real mode, with real mode DOS, drivers, TSRs, etc. all functioning normally.
A wise man once said: "640 kB or memory should be enough for everybody!" A wise man said: "I'll be glad to accept the invitation to your island Mr. Epst**n!"
What does the address space look like if you did not have 1MB of Memory , specificaly if you only had 156k of memory; where does the BIOS, expansion ROM and Video?
They are still located between 640K and 1Mib. Their addresses -- as accessed by the DOS kernel, the BIOS and device drivers -- do not change and are still valid, regardless of how much physical RAM is installed. If you had 156K of RAM, there is simply no valid address between 156 and 640. They are empty, and any attempt to access them will result in an error, and possibly a frozen computer.
Adding to @dutchcanuck7550's response, this is a common scenario for machines of this era. Rather than configuration differences changing the addresses of resources, you might end up with "holes" in the address space, or an area of it where the memory map of a device is repeated in more than one place. Broadly, a CPU with address and data buses lets you select an address and read or write from it. The CPU doesn't know or care what's at the other end of the address, it just asserts the signals on the address and data lines. There may be a logic circuit, called the address decoder, in between the CPU's address lines and the various components of the computer. The circuit routes the signals of the address lines based on the selected address. One address may connect you to RAM, another to a video card, and so on. The decoder understands that other devices are not to be addressed, so activation signals don't go to them. That way, the data bus can be shared across multiple devices; only the addressed device will assert or receive the data. The address decoder could even change the map, removing one device from it and putting another in its place. The address decoding logic is specific to the architecture of the computer we use. A "memory mapped device" can refer to something that may or *may not* be purely memory in the address space. For example, a video card may have both its video memory and its registers in the address space. Writing a value to a register might make the card change the video mode. Both storage and decision-making logic elements are involved. A computer has "memory mapped I/O" when *all* resources are mapped into the address space. I believe the C64 is an example. Again, the CPU doesn't know or care what's on the other end of its address and data buses. I'd prefer another term like "address mapped device", but "memory mapped" is the convention we have. The memory map is not the only way a CPU can do I/O to devices. The 6502 has no dedicated I/O; memory mapped I/O is the only option. I8088 and Z80 have dedicated I/O ports which can be connected to peripherals. A CPU with dedicated I/O ports can also do memory mapped I/O, so a computer could have some combination of the two. Fortunately, complete logic diagrams of many computers are available for study. IBM PC: archive.org/details/IBMPCXTTechnicalReference1502237/page/n531/mode/2up Commodore 64: www.monkeyspeak.com/c64_hardware_details/ Garth Wilson has a complete primer on the 6502 CPU, including a complete circuit for a minimal 6502 computer. I have built one very similar using his work. All the material on his web site is very valuable: wilsonminesco.com/6502primer/addr_decoding.html @BenEater has a few videos on address decoding and visualizes it well. th-cam.com/users/results?search_query=address+decoding
Your content is super accurate. But are you using voice changers or robotic voice - it is so boring to listen to it - so many times turned off the video.
Isn't this mebibyte stuff just made up by HDD manufacturers? Why not just use megabytes like everyone else. No one thinks a megabyte is 1000 kilobytes!
@@SnakebitSTI That's incorrect. A kilobytes was always defined as 2^10. Everyone in computer science fields knew this definition. That's why the Commodore 64 is not called the Commodore 65.536
mebibyte ??? 👎👎👎 perhaps somehow correct, but well, this crazy wording was invented for people who cannot get their mind around that 1kb are 1024 bytes and not 1000 bytes
IDK I feel like the only people who care about this are HDD manufacturers. I don't think it's inaccurate to say Megabyte. Every knows you don't mean 1000 kilobytes. I don't know the history of the terms, but even if it is historically accurate I still think it's stupid. You wouldn't go around saying cracker when you mean hacker.
@@thewhitefalcon8539 because the term mebibyte was only introduced in 1998! Just because the prefix mega usually means 1 million doesn't mean it can't have a different definition in different fields. Everyone knows 1 megabyte is 1024 kilobytes. It's a widely accepted definition and has been for long before the term mebibyte even existed. HDD manufactures like this redefinition because it allows them to advertise HDD sizes that are smaller than what many people who are unaware of this new terminology realise. Not to mention that the term has been introduced from the top down.
Anybody interested in making old games work, even if via DOSbox or a VM. "This application requires at least 570,000 bytes of conventional memory available."
Talk about a blast from the past! When I was a teenager (pre-internet), I remember fighting with DOS and reading deep into manuals to squeeze out every free byte of RAM for my games. It could be quite intricate, and it took a while. It was almost like a game itself to find the right combinations.
I agree it felt like dark wizard magic. Now I just use some configuration files from Phils computer lab. It was finally able to get some games working I never did.
this is neat. this was the explainer i needed 20 years ago. this is a summary of my decades of confusion and learning and 'eventually sorta getting it'. its great to see this all summarized in this way. it really is the top of the pyramid for an explanation of all of this history.
I'm very glad it's valuable to you, and that makes it worth having produced. I was able to get around pretty well to do the things I wanted to do, but I didn't have as much info at the time either; no WWW yet.
Great video. This is so nostalgic. I fondly remember messing with himem.sys, TSRs etc. as a kid. At the time, I didn't really know much about real vs. protected mode though. I hope to see more like this.
yeah, exactly my thoughts now, but at the time it was a pain in the ass to free up enough convetional memory for really old games. also had selection menus at boot for different configs, depending on which game i will play. the problems was restarting whole PC when you needed different config for another game.
@@andrejrockshox So true, i had once 5 different boot floppies to play certain games :D
I'm glad you enjoyed it. Is there anything in mind you'd like me to cover?
What a nice stroll down memory lane, pun intended.
Loved the video. Thanks for sharing your knowledge
It's kinda weird to see the use of the kibi- & mebi- prefixes in a DOS video since these weren't a thing then and primarily a construct by the hard drive industry given (il)legitimacy by the IEC to redefine the kilo-, mega- etc. prefixes.
I also find they're pretty awkward to vocalize. But they're the best way to avoid any ambiguity, to my knowledge. Time will tell if I'll persist with this approach.
Redefine? Kilo is an SI prefix that always meant 1000. Programmers tried to redefine it because 1024 is "close enough" to 1000, and it's fine for casual speech, but this attempt had no legitimacy at the SI.
@@thewhitefalcon8539 Everyone understood that a kilobyte was 2^10. Much of the industry still abides by this. HDD manufacturers liked to over advertise their capacity. RAM companies did not.
@@majorramsey3k Everyone understood that kilo was 1000. Much of the industry still abides by this. RAM manufacturers liked to confuse people. HDD companies did not.
@@thewhitefalcon8539I think KB and MB were defined distinctly, at least at the later point when KiB and MiB were defined.
Anyway it’s news to me that DOS had a limit of 640 KiB not 640 KB.
"What about one eighty-s-"
"Shhh, we don't talk about 80186."
In this context (IBM PC compatibles), the 80186 is quite uninteresting; it has a couple of new instructions, and the same 16-bit data bus as the 8086, but no new addressing capability. It was also rather rare, with some other chips like NEC V20 being far more common.
"The 186 never existed."
"Yeah it did, there were a few computers that had----"
*"THE 186 NEVER EXISTED."*
Used with the Acorn BBC Master as a co-processor.
The Master 512
First time I've ever heard someone unironically say "mebibyte", but good high-level explanation of a low-level topic. High level because questions segment/offset and selector/offset weren't discussed, nor why some things require you NOT run EMM386 but might work if you had an EMS card installed, how DOS could see memory above 1MB in real mode, why load order mattered as much as memory locations for where drivers went in memory when running memmaker, etc? That sort of thing …
For how "simple" it is, MS-DOS memory management was a BIG topic. Might be too low-level for your audience though.
The evolution of the x86 CPUs and the DOS memory model around it makes the topic big, as I found when I was researching this. It was a lot of work to maintain accuracy and reduce the details down to an introductory video. The details you mentioned could be interesting topics for videos of their own. I agree with your assessment of the video as a high-level explanation, and appreciate it, because I was going for that. As for my audience, my content is targeted at people who appreciate low-level computing topics; see my OS development and disassembly stream videos.
I've gotten a big influx of subscribers and comments on this video lately. No idea what the source of it is, but I appreciate it. I haven't 100% found my focus for this channel yet, but I am still working on content for it.
Windows 3.1 still ran fine in 286 mode. It would even default 286 mode if you did not have much RAM, and at least with not much memory, it would actually run faster in the 286 mode (I know that because we had a computer with 2 MiB RAM). But you did not get the full features, like virtual memory and pre-emptive multitasking of DOS applications.
Windows 3.1 used cooperative multitasking. Win 95 was the first Microsoft OS to use preemptive
@@ctvxl note that I specifically said DOS applications. Windows applications used cooperative multitasking until Win95, like you said, but DOS programs in 386 mode were running virtualized in Win 3.1, and they were executed with preemptive multitasking. This might sound a bit weird, like the DOS programs being executed in a sense in a more "modern" way, but DOS programs were not implemented with multitasking in mind, so the solution needed to be a bit more involved.
@@fintux Yes, true. Dos apps running in Windows 3.1 were indeed virtualized and preemptively multitasked against each other. I actually had forgotten that. I learned about it many years ago when I became MCP certified on Windows 95. The course I took explained that factoid when comparing multitasking in Win 3.1 to 95. It's been a VERY long time :)
@@ctvxl yeah, I had to relearn that recently myself, too :)
Really enjoyed this, and learned a lot! Thank you!!
Personally I don’t mind the use of MiB and similar terminology to be clear that you’re talking about base 2. Even if it is the HDD manufacturers’ fault we live in a world where MB and KB is ambiguous now.
@@SnakebitSTI
Really?
Back in the 1970s 8-bit micro era of computing a computer with 32kilobytes of RAM had 32,768 bytes of RAM.
The processors (6502, 8080, Z80, etc) could access up to 64 kilobytes, or 65,536 bytes of memory.
Then you had floppies[1] of 180 kilobytes, 360 kilobytes, 720 kilobytes, 1.44 megabytes all with the capacity based on 1 kilobyte = 1,024 bytes, 1 megabyte = 1024 kilobytes.
The manuals for the GEC 41xx processors of the 1980s refer to accessing 64 kilobytes (65,536 bytes) of memory (in four 16 kilobyte (16,384 byte) segments).
In every case (in the computing world) it was understood that 1 kilobyte = 1,024 bytes.
That is until HDD manufacturers came along and decided to use the base-10 prefixes to bytes, despite bytes not being a base 10 unit - a byte is of 8 bits and can store a value between 0x00 and 0xff (0 and 255).
[1] the unformatted, raw, capacity was higher, but bits _[sic]_ of that raw capacity is needed to mark the sectors, etc. Thus a 2Mb floppy only gave 1.44Mb when formatted, a 4Mb floppy only gave 2.88 Mb formatted to IBM/DOS capacity; a 4MB floppy gave 3.2Mb formatted capacity on QL quad density drives.
I can't get used to it. In DOS years it was kB, MB and so on. For me MiB stands for Man in Black )
1:58 you forgot the 186
2:33 the 286 was only mostly compatible, it didn't roll over at the 1MB limit like the 8086/8088 and 186, which is why the A20 gate was needed
3:00 the 386 can run real-mode apps in protected mode using virtual 8086 mode
Popped up recently for me too.
I don't think HIIMEM or 286 can do UMB mapping though, that needs EMM386/QEMM and the v86 capability of the 386.
I might be misremembering, but I think expended memory or LIM EMS (Lotus Intel Microsoft) was originally intended to allow bigger 123 spreadsheets
RAM on an ISA card was mapped into (original spec, a 64k page frame of 4x 16k pages) similar to the way 8 bit home computers mapped extra ROM and RAM.
8:45 "Extended Memory - XMS maps extended RAM to UMBs". What UMBs does XMS use? or does it use conventional memory?
The difference between the 8086 and 8088 is that the 8086 has 16 of it's address pins duplexing as data pins, while the 8088 only has 8 of them duplexing as data pins, but they are otherwise identical. This means that the 8086 is capable of accessing it's memory 16-bits at a time instead of 8-bits like the 8088. What I'm curious about is whether or not any motherboards actually implemented this. Given that the 8086 was more popular among business-oriented machines, I'm guessing somebody did, but I'm not familiar with any specifically.
From my experience the memory area above 640 Kb was only available as RAM when a memory manager program like 386MAX or QEMM was installed. DOS 5.0 and higher has a similar memory manager included. Plus you could only do this on a 386 or higher CPU. There were some DOS games that needed this because they needed 600 Kb+ of RAM to run. These memory manager programs also supported the EMS memory interface in software by reserving a 64 Kb UMB area. They also scanned the entire upper memory area to map all free UMB's which included unused areas that were reserved for the system BIOS Typically these programs would load device drivers and TSRs into these recovered UMBs.
this is a great video, subscribed
The first KB was not occupied by the BIOS. It was RAM and was the BIOS Data Area (BDA); the values were populated by the BIOS. The first KB was actually the Interrupt Vector Table (IVT), then came BDA values for items such as COM/LPT port addresses, memory size, keyboard buffer, soft reset behavior, etc. MS-DOS boot sector would load initial code to 0:7C0, and would use 70:0 as the DOD data area.
I don't go into that level of detail in the video, but had intended all those things, not only BIOS code, to be included in what I call BIOS. What you say is true, of course. Thank you for specifying.
I still rember doing multiconfig on clients computer so they choose according type of memory for specific game or application.
I was also quite good (better than memmaker) in fitting drivers and dos in high memory.
I remember back in the day having a 20MB 386 that was tricked out, and having to have a multiple choice config / autoexec depending on what I needed as I didn't have enough base / umb / himem to get all of the drivers in and be able to run a half decent dos game.
one config also had a 16MB ram drive that copied games I would play into it and run the game from ram. it was a long copy time, but games ran fast.
No mention of how DOS keeps track of blocks of RAM - there is a 16-byte area in front of each allocated chunk, with links forward and backward to the next and previous allocations. Being in real mode, any program can follow these links and work out what else is going on in the machine.
@2:02 I swear it sounds like you're saying 'meba byte'.
"We'll never need more than 640K " - some guy that was completely wrong.
if you're referring to Bill Gates, there's no evidence that he ever actually said that
Nobody who used a computer in that time would call a megabyte "mibibyte".
I used computers then and called it a megabyte at that time. I use computers now and chose the term mebibyte in this video.
@@chillruns6221 How about you get back in touch with reality and stop using idiotic made-up crap that were meant to fix a problem that never existed?
You completely forgot to mention unofficial "unreal" mode, where you first switch the CPU to protected mode, extend the segments to 4GB and switch back to real mode. Boom, you can now access full 4GB of RAM from real mode, with real mode DOS, drivers, TSRs, etc. all functioning normally.
To get Falcon3.0 with expansion packs running.. you needed to know all this shiet in this video - front and back.
A wise man once said: "640 kB or memory should be enough for everybody!"
A wise man said: "I'll be glad to accept the invitation to your island Mr. Epst**n!"
no, el 8088 es una variante del 8086, mas economica, el 8086 es de 1976 y el 8088 es de 1979
When I worked on my first PC, knowing it could have 640k of RAM, it seemed, and it was, an inexhaustible ocean of RAM.
What does the address space look like if you did not have 1MB of Memory , specificaly if you only had 156k of memory; where does the BIOS, expansion ROM and Video?
They are still located between 640K and 1Mib. Their addresses -- as accessed by the DOS kernel, the BIOS and device drivers -- do not change and are still valid, regardless of how much physical RAM is installed. If you had 156K of RAM, there is simply no valid address between 156 and 640. They are empty, and any attempt to access them will result in an error, and possibly a frozen computer.
Adding to @dutchcanuck7550's response, this is a common scenario for machines of this era. Rather than configuration differences changing the addresses of resources, you might end up with "holes" in the address space, or an area of it where the memory map of a device is repeated in more than one place.
Broadly, a CPU with address and data buses lets you select an address and read or write from it. The CPU doesn't know or care what's at the other end of the address, it just asserts the signals on the address and data lines. There may be a logic circuit, called the address decoder, in between the CPU's address lines and the various components of the computer. The circuit routes the signals of the address lines based on the selected address. One address may connect you to RAM, another to a video card, and so on. The decoder understands that other devices are not to be addressed, so activation signals don't go to them. That way, the data bus can be shared across multiple devices; only the addressed device will assert or receive the data. The address decoder could even change the map, removing one device from it and putting another in its place. The address decoding logic is specific to the architecture of the computer we use.
A "memory mapped device" can refer to something that may or *may not* be purely memory in the address space. For example, a video card may have both its video memory and its registers in the address space. Writing a value to a register might make the card change the video mode. Both storage and decision-making logic elements are involved.
A computer has "memory mapped I/O" when *all* resources are mapped into the address space. I believe the C64 is an example. Again, the CPU doesn't know or care what's on the other end of its address and data buses. I'd prefer another term like "address mapped device", but "memory mapped" is the convention we have.
The memory map is not the only way a CPU can do I/O to devices. The 6502 has no dedicated I/O; memory mapped I/O is the only option. I8088 and Z80 have dedicated I/O ports which can be connected to peripherals. A CPU with dedicated I/O ports can also do memory mapped I/O, so a computer could have some combination of the two.
Fortunately, complete logic diagrams of many computers are available for study.
IBM PC: archive.org/details/IBMPCXTTechnicalReference1502237/page/n531/mode/2up
Commodore 64: www.monkeyspeak.com/c64_hardware_details/
Garth Wilson has a complete primer on the 6502 CPU, including a complete circuit for a minimal 6502 computer. I have built one very similar using his work. All the material on his web site is very valuable: wilsonminesco.com/6502primer/addr_decoding.html
@BenEater has a few videos on address decoding and visualizes it well. th-cam.com/users/results?search_query=address+decoding
Bah humbug, I think no one needs more than 64k 😂
You keep talking in past tense but they are megabytes if you are speaking in past tense.
Your content is super accurate. But are you using voice changers or robotic voice - it is so boring to listen to it - so many times turned off the video.
You just have to know your config.sys and autoexec.bat files.
I remember using this - it was a nightmare!
QEMM
Isn't this mebibyte stuff just made up by HDD manufacturers? Why not just use megabytes like everyone else. No one thinks a megabyte is 1000 kilobytes!
I agree, I'd rather put a pen in my eye than pronounce mebibyte. A Megabyte is 2^20 bytes.
Bigger number looks bigger, that’s why
When you buy 9 TB disk, you think is 10 TB :)
@@nmmm2000 They shouldn't be labeling a 9TB drive as 10TB.
@@SnakebitSTI That's incorrect. A kilobytes was always defined as 2^10. Everyone in computer science fields knew this definition. That's why the Commodore 64 is not called the Commodore 65.536
Mebibyte... Ugh.
mebibyte ??? 👎👎👎 perhaps somehow correct, but well, this crazy wording was invented for people who cannot get their mind around that 1kb are 1024 bytes and not 1000 bytes
Saying MiB instead of MB kinda makes you sound like you have a speech impediment, although I know you try to be as accurate as possible.
IDK I feel like the only people who care about this are HDD manufacturers. I don't think it's inaccurate to say Megabyte. Every knows you don't mean 1000 kilobytes. I don't know the history of the terms, but even if it is historically accurate I still think it's stupid. You wouldn't go around saying cracker when you mean hacker.
@@hamesparde9888hard drive manufacturers also don't think it's a problem that mega means million. Why should we trust you over them?
@@hamesparde9888nowadays "black hat hacker" is common
@@thewhitefalcon8539 because the term mebibyte was only introduced in 1998! Just because the prefix mega usually means 1 million doesn't mean it can't have a different definition in different fields. Everyone knows 1 megabyte is 1024 kilobytes. It's a widely accepted definition and has been for long before the term mebibyte even existed. HDD manufactures like this redefinition because it allows them to advertise HDD sizes that are smaller than what many people who are unaware of this new terminology realise. Not to mention that the term has been introduced from the top down.
@@thewhitefalcon8539 It's interesting that memory manufactures don't use this new redefinition. 🤔
What memory management?
Who in their right mind cares about DOS 6.22 in the year 2023?
If you don't already know the answer to that question, what happened with the algorithm to present this video to you?
Anybody interested in making old games work, even if via DOSbox or a VM.
"This application requires at least 570,000 bytes of conventional memory available."
the good old days of messing with autoexec.bat and config.sys to to free up memory to maybe run a game
Disqualified for actually saying (!) "MibaBytes" or something