Timeline for Think 8086… Is the BIOS permanently stored in memory, or is it copied to RAM?
Current License: CC BY-SA 4.0
29 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 7 at 10:30 | review | Suggested edits | |||
| Feb 7 at 15:45 | |||||
| Feb 6 at 19:24 | comment | added | marshal craft | There are actually many many details to it. Like there are hardware and software straps. Also when it boot up it runs usually microcode first. There are many exact details to an answer to this question. | |
| Feb 6 at 19:22 | answer | added | marshal craft | timeline score: 0 | |
| Feb 5 at 21:57 | comment | added | Joshua | "Context: I'm writing an emulator for a custom CPU"? 8086tiny emulator just copies the BIOS image from disk to RAM at startup before the first CPU instruction runs. The 8086Tiny BIOS makes use of the fact that its memory region is RAM so it doesn't overrun the BIOS data area despite having hard disk support (which would otherwise grow the BIOS data area as to what an 8086 floppy disk thing might expect). | |
| Feb 5 at 21:52 | answer | added | Harper - Reinstate Monica | timeline score: 2 | |
| Feb 5 at 16:49 | answer | added | cjs | timeline score: 2 | |
| Feb 5 at 16:19 | comment | added | cjs |
@Neil You were still wrong that mapping and shadowing came available only with "advanced" '386 processors; that ability something you can add to any simple address decoding circuit, and was used extensively on 1970s and 1980s 8-bit systems, such as the Apple II. Further, it's not entirely clear to me that it can't be done at all on the PC; it wasn't designed explicitly to do that, but you might be able to replace the ROM with RAM using an expansion card and some tricks to toggle D̅M̅A̅ ̅A̅E̅N̅ line. (I've not looked closely enough to determine if this is possible.)
|
|
| Feb 5 at 14:56 | comment | added | Neil | @Gábor I was meaning that the original IBM PC (8086/8088) didn't have the capability to swap ROM for RAM. | |
| Feb 4 at 21:04 | vote | accept | Vinny | ||
| Feb 4 at 19:32 | answer | added | got trolled too much this week | timeline score: 22 | |
| Feb 4 at 17:48 | comment | added | Gábor | @Neil -- it most definitely is possible and this has nothing to do with the capabilities of the processor itself, it can happen in the hardware around it. Here's the relevant part of James Sharman's processor series I mentioned tangentially in my reply: youtube.com/watch?v=yR9cw7QehCg His processor is obviously much less capable than a 8086 but he has solved the shadow copying with a handful of external parts. And that's just one example of the many. | |
| Feb 4 at 15:18 | answer | added | Margaret Bloom | timeline score: 4 | |
| Feb 4 at 14:34 | answer | added | RalfFriedl | timeline score: 7 | |
| Feb 4 at 13:26 | comment | added | Neil | @Mokubai None of this 'mapping' or 'shadowing' is possible on 8086. The hardware wasn't capable of this kind of advanced technology, which only really came available on 80386 or later processors. | |
| Feb 4 at 13:22 | answer | added | Neil | timeline score: 4 | |
| Feb 4 at 13:15 | comment | added | mins | @Mokubai: Ah, I see, "shadowed" is ambiguous, hidden is better. At boot time the ROM is accessed thru the mapping, but it can be later copied by the OS into the RAM, for routine access using interruptions (and also be decompressed in some cases, when the ROM contains compressed code to save space). | |
| Feb 4 at 13:07 | comment | added | Mokubai♦ | @mins The BIOS is mapped into the RAM address space but it can be copied into RAM and run from there if it is "shadowed" (i.e. copied) by the BIOS program itself. For programs that use a lot of BIOS functions, for example to access hard disks in DOS, it can result in a general performance boost. rigacci.org/docs/biblio/online/firmware/shadow.htm | |
| Feb 4 at 13:03 | comment | added | mins | The BIOS is not copied into the RAM, but the BIOS ROM addresses are mapped into the address space of the CPU (many I/O devices are mapped too). The address space is one thing, the actual physical locations are another thing, hidden to the CPU. This means actual RAM ranges are shadowed by these mapped ranges, and cannot be read. See this answer. | |
| Feb 4 at 11:39 | comment | added | Chester Gillon |
What architecture is the custom CPU based upon? Is a custom designed architecture for which a new instruction set architecture (ISA) has been created, or does it use an existing ISA?
|
|
| Feb 4 at 11:23 | answer | added | TrayMan | timeline score: 10 | |
| Feb 4 at 11:16 | answer | added | Gábor | timeline score: 3 | |
| Feb 4 at 10:22 | history | became hot network question | |||
| Feb 4 at 4:41 | comment | added | sawdust | "I'm writing an emulator for a custom CPU ..." - Why not look at a more modern processor, e.g. ARM? An ARM CPU typically has built-in ROM at its restart address, although some vendors allow an external nonvolatile memory capable of XIP (e.g. NOR flash) to replace the ROM. There are also schemes to execute ROM that will initialize system DRAM, copy boot code from an NVM to DRAM, unmap the ROM, and then jump to the code in DRAM. | |
| Feb 4 at 4:13 | comment | added | sawdust | You're creating a chicken or egg problem if you expect a "BIOS is loaded" scenario on CPU reset. Since "the CPU starts executing the BIOS at 0xFFFF0", then the code/contents of that memory at the (re)start address must already be there. That's accomplished by installing ROM (or flash) instead of RAM that is already programmed with machine code that can be executed in place (aka XIP). | |
| Feb 4 at 2:39 | history | edited | Giacomo1968 | CC BY-SA 4.0 |
added 5 characters in body
|
| Feb 4 at 2:37 | history | edited | Vinny | CC BY-SA 4.0 |
added context
|
| Feb 4 at 2:31 | answer | added | Repaird | timeline score: 7 | |
| S Feb 4 at 2:20 | review | First questions | |||
| Feb 4 at 2:42 | |||||
| S Feb 4 at 2:20 | history | asked | Vinny | CC BY-SA 4.0 |