If you look at old issues of Byte magazines you see a huge number of ads for high-end S100 system vendors that sold systems that could run MP/M, a multitasking OS for the Z80
It's hard to imagine getting work done on a shared Z80 machine with everybody sharing the same 64kB of memory. Z80s were already plenty slow and the working memory tight. Sharing that with other users sounds miserable.
You had bank switching. So for example the MP/M system I used (Altos) would allow several terminals (serial) of which each would get a command processor in a bank. I think it had 256KB, maybe 512. You know, I never ever remember thing thing crashing, even with multiple terminals/sessions.
We had shared S100 8080 systems in our EE lab at university. 7 terminals per CPU. Worked just fine for editing programs. But when everyone started a (Pascal) compile run at the same time, things got plenty slow.
Writing my own pre-emptive multitasker in Turbo Pascal on our x86 as a self-taught teenager was a core memory thing.
I recall spending a few days mulling over the exact sequence of instructions to save the state of the previous task without clobbering the flags or any registers.
The result was that I could register functions (procedures) as tasks with their own little stack, and it would switch preemptively between them in a round-robin fashion.
I'm not familiar with Z80 asm but from what I can gather it looks very similar to what I had. I was running in real mode so also had very limited resources for each task, and a hardcoded upper limit on the number of tasks.
While I'm wildly more productive these days, I kinda miss how not having internet made accomplishments so much greater. It's like walking up a mountain on your own vs taking a tour bus to the summit.
Did this on my Atari ST 68000 back in the 90s... I did not even heard about the word "preemptive" at the time (guys, I did not even know the Amiga OS did this natively), it was just an idea. Task switching every 10 or 20 HBL or so. I was so glad to have two routines running, each one changing color index 0 register to red and blue so I can see it realtime.
Funniest 8080-era multitasker was made by Siemens in 1976. Instead of allocating memory from common RAM, they just switched small RAMs mechanically. You only needed to dump registers at each switch. Particularly economical in 8080 which is not good for indexed memory models like Z80.
It wasn't unusual for larger-scale microcomputers to have bank switching in the late 1970s to the mid-1980s.
RAM chips usually have a "chip enable" pin, you might have chips that have 4k of addresses that are 8 bits wide [1] and fill out the 64k address space by having 16 RAM chips, feeding the least significant 12 bits to the RAM chips and the most 4 bits to a multiplexer that goes to the 16 RAM chips. All of the RAM chips are on the bus but only the one with CE set responds.
The same kind of thinking could be applied to extend the address space past 16 bits, for instance you poke at some hardware register and that determines which chip enable pin get sets, there is really no limit on how much RAM you could attach to an 8-bit machine.
A really advanced bank switching scheme for an 8-bitter was on the TRS-80 Color Computer 3
where the 64k address space was divided into 8k blocks and which might be backed by 128kB (minimum), 512kB (max from radio shack) or more RAM and you poked into a table which mapped virtual blocks to physical blocks. That wasn't too different from a modern memory management system greatly scaled down with the exception that systems like that rarely if ever had a true "executive" mode so nothing stopped user mode software from poking to change the memory map. The CoCo for instance had a multitasking OS called OS-9 that did muiltitasking like described in the explained if you had the orginal Color Computer, you could get Level II that supported more memory and if you never poked at those registers, some memory protection.
I think you meant KB here but now im also wondering how many MB you -could- actually scale tp and what the overhead would be due to the numbers of banks to switch between...
"Mechanically" is funnier expression. But kinda true because it switched also trunk lines in some small PBX. 8080 was bloody expensive in 1976 and RAMs were too. I only heard about because I was employed to design something similar for Telenokia.
I actually wrote my first toy multitasker on a Gameboy Advance, although that's ARM7... Great little project. It's a joy to develop on an emulator with good debugging tools.
If you look at old issues of Byte magazines you see a huge number of ads for high-end S100 system vendors that sold systems that could run MP/M, a multitasking OS for the Z80
https://en.wikipedia.org/wiki/MP/M
It's hard to imagine getting work done on a shared Z80 machine with everybody sharing the same 64kB of memory. Z80s were already plenty slow and the working memory tight. Sharing that with other users sounds miserable.
You had bank switching. So for example the MP/M system I used (Altos) would allow several terminals (serial) of which each would get a command processor in a bank. I think it had 256KB, maybe 512. You know, I never ever remember thing thing crashing, even with multiple terminals/sessions.
It would usually be lightweight data entry, and it would work as fast as people could type (which was pretty fast for dedicated data entry workers).
I had after school computer classes on a shared 8080 system running MP/M. Worked very, very well.
We had shared S100 8080 systems in our EE lab at university. 7 terminals per CPU. Worked just fine for editing programs. But when everyone started a (Pascal) compile run at the same time, things got plenty slow.
Often they had bank switching to access more memory.
Writing my own pre-emptive multitasker in Turbo Pascal on our x86 as a self-taught teenager was a core memory thing.
I recall spending a few days mulling over the exact sequence of instructions to save the state of the previous task without clobbering the flags or any registers.
The result was that I could register functions (procedures) as tasks with their own little stack, and it would switch preemptively between them in a round-robin fashion.
I'm not familiar with Z80 asm but from what I can gather it looks very similar to what I had. I was running in real mode so also had very limited resources for each task, and a hardcoded upper limit on the number of tasks.
While I'm wildly more productive these days, I kinda miss how not having internet made accomplishments so much greater. It's like walking up a mountain on your own vs taking a tour bus to the summit.
Did this on my Atari ST 68000 back in the 90s... I did not even heard about the word "preemptive" at the time (guys, I did not even know the Amiga OS did this natively), it was just an idea. Task switching every 10 or 20 HBL or so. I was so glad to have two routines running, each one changing color index 0 register to red and blue so I can see it realtime.
Funniest 8080-era multitasker was made by Siemens in 1976. Instead of allocating memory from common RAM, they just switched small RAMs mechanically. You only needed to dump registers at each switch. Particularly economical in 8080 which is not good for indexed memory models like Z80.
"mechanically" with relays or something? Do you know the model number?
It wasn't unusual for larger-scale microcomputers to have bank switching in the late 1970s to the mid-1980s.
RAM chips usually have a "chip enable" pin, you might have chips that have 4k of addresses that are 8 bits wide [1] and fill out the 64k address space by having 16 RAM chips, feeding the least significant 12 bits to the RAM chips and the most 4 bits to a multiplexer that goes to the 16 RAM chips. All of the RAM chips are on the bus but only the one with CE set responds.
The same kind of thinking could be applied to extend the address space past 16 bits, for instance you poke at some hardware register and that determines which chip enable pin get sets, there is really no limit on how much RAM you could attach to an 8-bit machine.
A really advanced bank switching scheme for an 8-bitter was on the TRS-80 Color Computer 3
https://www.chibiakumas.com/6809/coco3.php
where the 64k address space was divided into 8k blocks and which might be backed by 128kB (minimum), 512kB (max from radio shack) or more RAM and you poked into a table which mapped virtual blocks to physical blocks. That wasn't too different from a modern memory management system greatly scaled down with the exception that systems like that rarely if ever had a true "executive" mode so nothing stopped user mode software from poking to change the memory map. The CoCo for instance had a multitasking OS called OS-9 that did muiltitasking like described in the explained if you had the orginal Color Computer, you could get Level II that supported more memory and if you never poked at those registers, some memory protection.
[1] at least you did in 1979.
> 128MB (minimum), 512MB (max from radio shack)
I think you meant KB here but now im also wondering how many MB you -could- actually scale tp and what the overhead would be due to the numbers of banks to switch between...
I fixed the mistake⦠thanks!
"Mechanically" is funnier expression. But kinda true because it switched also trunk lines in some small PBX. 8080 was bloody expensive in 1976 and RAMs were too. I only heard about because I was employed to design something similar for Telenokia.
Unless you mean that a physically moving part caused the banks to switch then "mechanically" is the wrong word here.
If that is how the bank switching was done then that's fascinating and very very surprising and I would love to hear more about it.
Forgot this is HN where everything is taken literally. Humour is [Flagged].
I myself made a Coin-Operated Telephone server, but in 1978 the processor was already cheaper and faster 8085.
I think the big problem is that "mechanically" gives the wrong idea.
It made me think of https://en.wikipedia.org/wiki/SymbOS which is a quite impressive Z80 multitasking OS.
Accompanying video: https://youtu.be/tMYGlYO3v9U?si=e0UUzCVyMtc6L2-L
So now we can do timeshare Nintendo Gameboy? /s
I actually wrote my first toy multitasker on a Gameboy Advance, although that's ARM7... Great little project. It's a joy to develop on an emulator with good debugging tools.