| PLEX86 | ||
|
8086 memory space was: The Soul of Barb's New Machine 1152
8086 memory space was: The Soul of Barb's New Machine 1154 Ok, let me go a little further. How are you going to load the code memory from the I-O device? You can't write to code memory using the DS... 8086 memory space was: The Soul of Barb's New Machine 1155 Indeed. It's a very old idea. I fear that it's been neglected too long because of the... The 8080 had a way to derive stack access, but not the Z80. Nor was the M1 a reliable code-data separator, since M1 was not butterted for all code fetch cycles, only the first byte of a multi-byte instruction. M1 existed primarily to handle a memory timing problem with Z80s, where the first code byte fetch (the "M1" cycle) had a shorter access time. Better Z80 systems had a provision for an M1 only wait state generator to handle this. M1 was also used to decode interrupt acknowledge and handle interrupt priority daisy-chaining. 8086 memory space was: The Soul of Barb's New Machine 1153 And what about (curse, spit) segmented architectures *wasn't* "interesting"? Also, as we all recall from Intel's marketing material - Nobody would ever program... Theoretically one could decode M1 with some additional logic to get an I-D, but then there's the problem of writing to the I space. Z80s had no instruction to do this, so more MMU logic would be needed to overlap I-D for code page loading or programs with a unified address space. It was easier just to build a simple MMU (TI had an all-in-one chip for this, the 74LS612, to extend 16-bits to 24-bits) to map 4K pages out to more address bits (a la the PDP-11 approach) and overall more useful. The Z180 MMU was essentially a segment model, with low and high regions mapped to different base addresses, not as useful as a page-oriented MMU. There was never any intent to separate spaces. Intel had a separate 8-bit line line for that, the still thriving 8048-8051 family which does use separate I-D spaces. Besides, peripherals were in the I-O space, not memory, so only the system controller (8228, 8288 etc.) was affected. Jack Peachicken
|
||||||||