3 ms·

Simple MMU for the Z80 (2015)

PaulHoule 4y ago
I have been thinking about a revival of the 24 bit age and I've had a lot of interest in chips like the 65C816, Z800, 80286, etc. The trouble with all of them is that the MPU model is awkward when combining: (1) applications that access more than 64K of RAM, and (2) memory protection. In the case of the 80286 and MS-DOS it was particularly bad because applications were not allowed to change the segment registers so you would have to make OS calls to switch segments. 8088 users were already used to running application that used more than 64k and they weren't going to go back. (An interesting possibility would be that the 286 supports 4 segments so you could have two data pages, a stack page and a separate code page that are all 64k.) With CP/M on the other hand there was no expectation that applications need more than 64k so you could build a powerful multitasking OS that has a rich userspace. (In fact there was MP/M back in the day) The source code of CP/M is available now and if you put ZCPR3 on it feels like a mainframe.
- retrac 4y ago
  Yup. These days the move to the 80386 is associated with the shift to virtual memory, paging, process isolation, etc. But in 1985, for most customers, all of these features were secondary considerations. (The mainstream PC operating systems would not exploit them for half a decade or more.) The killer feature was the flat 32-bit addressing. Data structures could be more than 64 KB without special (complicated and slow) handling. Large programs didn't have to be unnaturally segmented. A pressing issue at the time, when a typical full-screen colour bitmap was larger than 64 KB, and GUIs were becoming prominent.
  - PaulHoule 4y ago
    I didn't think the 8086 programming model was that bad. There were several different memory models for compiled languages and I think it was outright fun to work with the segment registers in assembly language. It was tragic though that no "Multitasking DOS" emerged in the 1980s. My 1987 AT clone was more powerful than the largest PDP-11 but the big PDP-11 could support 32+ terminals. It was annoying as hell that I couldn't download files from a BBS while doing something else -- I tried to make a TSR that did that but couldn't make it work.
    - icedchai 4y ago
      DESQview doesn't count? I thought it supported the 8086, though a 286 or 386 was preferable. (I was using an Amiga at the time!)
    - VogonPoetry 4y ago
      There was and it ran on quite well on 286 systems. It started out as Concurrent CP/M-86 but evolved into Concurrent DOS. It was able to run simple MSDOS programs and eventually ran from a FAT filesystem. This OS came from Digital Research. The wikipedia page has a lot more info. https://en.wikipedia.org/wiki/Multiuser_DOS https://en.wikipedia.org/wiki/Multiuser_DOS.

I have been thinking about a revival of the 24 bit age and I've had a lot of interest in chips like the 65C816, Z800, 80286, etc. The trouble with all of them is that the MPU model is awkward when combining: (1) applications that access more than 64K of RAM, and (2) memory protection. In the case of the 80286 and MS-DOS it was particularly bad because applications were not allowed to change the segment registers so you would have to make OS calls to switch segments. 8088 users were already used to running application that used more than 64k and they weren't going to go back. (An interesting possibility would be that the 286 supports 4 segments so you could have two data pages, a stack page and a separate code page that are all 64k.) With CP/M on the other hand there was no expectation that applications need more than 64k so you could build a powerful multitasking OS that has a rich userspace. (In fact there was MP/M back in the day) The source code of CP/M is available now and if you put ZCPR3 on it feels like a mainframe.

retrac 4y ago
Yup. These days the move to the 80386 is associated with the shift to virtual memory, paging, process isolation, etc. But in 1985, for most customers, all of these features were secondary considerations. (The mainstream PC operating systems would not exploit them for half a decade or more.) The killer feature was the flat 32-bit addressing. Data structures could be more than 64 KB without special (complicated and slow) handling. Large programs didn't have to be unnaturally segmented. A pressing issue at the time, when a typical full-screen colour bitmap was larger than 64 KB, and GUIs were becoming prominent.
- PaulHoule 4y ago
  I didn't think the 8086 programming model was that bad. There were several different memory models for compiled languages and I think it was outright fun to work with the segment registers in assembly language. It was tragic though that no "Multitasking DOS" emerged in the 1980s. My 1987 AT clone was more powerful than the largest PDP-11 but the big PDP-11 could support 32+ terminals. It was annoying as hell that I couldn't download files from a BBS while doing something else -- I tried to make a TSR that did that but couldn't make it work.
  - icedchai 4y ago
    DESQview doesn't count? I thought it supported the 8086, though a 286 or 386 was preferable. (I was using an Amiga at the time!)
  - VogonPoetry 4y ago
    There was and it ran on quite well on 286 systems. It started out as Concurrent CP/M-86 but evolved into Concurrent DOS. It was able to run simple MSDOS programs and eventually ran from a FAT filesystem. This OS came from Digital Research. The wikipedia page has a lot more info. https://en.wikipedia.org/wiki/Multiuser_DOS https://en.wikipedia.org/wiki/Multiuser_DOS.