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.
I did something similar as a teenager using DOS Microsoft C to implement the Amiga's exec.library and other bits and pieces on the x86. I managed to get preemptive multitasking working in 8086 real mode, along with a serial and tty device. Later on I implemented bits and pieces of dos.library in an emulator that let me run some m68k Amiga shell binaries (like the Aztec C compiler) from a Linux command line. That was invaluable practice for learning about different execution contexts, interrupts, locking and such for Linux kernel programming. I had even written a very simple C compiler with a friend that I used to mangle C code into endian swapping code that ran natively on my 486 so that the Amiga code could call into native code to do Linux syscalls and such.
The experience of figuring these things out was tonnes of fun! There's nothing like following threads of assembly with a debugger or disassembler in the Amiga's ROM to get a better idea of how the code worked. And since systems were so much smaller in the 1980s, a single person really could understand virtually everything about the system with enough time and effort.
The biggest challenge for me was that the ROM Kernel Manuals were very expensive back then, so I wasn't able to get copies until far too late in my Amiga years (with Commodore being in its death throes).
Motorola and Intel were great back then as they would ship out printed copies of all the documentation for various CPUs and support chips for free upon request!
Ah, that brings back memories. I was using Intel iRMX on a commercial system in the mid 80s, and wanted to write a multitasking program on my IBM XT.
So I wrote a pre-emptive multitasking iRMX clone in C and a bit of assembler. Ended up using it to develop a mildly successful POS system running on a single PC with several VT100 terminals attached.
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.
Multiuser machines could get away with surprisingly little memory; They had some major advantages over home computers:
Users were all connected via CRT terminals over serial, so you didn't need to waste any memory on screen buffers. This also reduced CPU usage as the user wouldn't get any CPU time until they pressed a key, and the scheduler might queue up multiple key presses before even switching to the user's task (while still showing immediate feedback)
They also had superior IO. Home computers were connected to slow floppy drives (at best, some were still using tape) so they typically tried to keep the whole working set in memory. But multi-user machines had relatively fast hard drives and could afford to shuffle the working set in and out of memory as needed, with DMAs handling the actual transfer in the background.
As others have pointed out, these machines had bank switching. But I doubt such machines were ever configured with more than 256k of memory, with 128k being more typical. Wikipedia claims 32k was the absolute minimum, but with very little free memory, so I suspect 64k would be enough for smaller offices with 4-6 users.
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.
I’d note those competed with minicomputers, my high school had a PDP-8 circa 1981 when I was taking a few classes there while still in elementary school. The PDP-8 could support three terminals of interactive BASIC or could be brought up in a single user mode where you got more memory and could run bigger programs like the Crowther & Woods ADVENTURE. A bigger school has a PDP-11 with about 20 terminals. By 1985 or so my school got a VAX-11/730 which is basically like a modern computer.
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.
Low effort humour is discouraged, it's in the site guidelines and since it wasn't amusing, just confusing, perhaps you should skip the humour and consult them.
Uh. I seem to be suffering from the Mandela effect; it is not in the site guidelines. It's definitely the overall policy officially or otherwise though (one which I'm entirely happy with despite having a juvenile sense of humour myself).
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.
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.
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.
I did something similar as a teenager using DOS Microsoft C to implement the Amiga's exec.library and other bits and pieces on the x86. I managed to get preemptive multitasking working in 8086 real mode, along with a serial and tty device. Later on I implemented bits and pieces of dos.library in an emulator that let me run some m68k Amiga shell binaries (like the Aztec C compiler) from a Linux command line. That was invaluable practice for learning about different execution contexts, interrupts, locking and such for Linux kernel programming. I had even written a very simple C compiler with a friend that I used to mangle C code into endian swapping code that ran natively on my 486 so that the Amiga code could call into native code to do Linux syscalls and such.
The experience of figuring these things out was tonnes of fun! There's nothing like following threads of assembly with a debugger or disassembler in the Amiga's ROM to get a better idea of how the code worked. And since systems were so much smaller in the 1980s, a single person really could understand virtually everything about the system with enough time and effort.
The biggest challenge for me was that the ROM Kernel Manuals were very expensive back then, so I wasn't able to get copies until far too late in my Amiga years (with Commodore being in its death throes).
Motorola and Intel were great back then as they would ship out printed copies of all the documentation for various CPUs and support chips for free upon request!
Good times!
Ah, that brings back memories. I was using Intel iRMX on a commercial system in the mid 80s, and wanted to write a multitasking program on my IBM XT.
So I wrote a pre-emptive multitasking iRMX clone in C and a bit of assembler. Ended up using it to develop a mildly successful POS system running on a single PC with several VT100 terminals attached.
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.
Multiuser machines could get away with surprisingly little memory; They had some major advantages over home computers:
Users were all connected via CRT terminals over serial, so you didn't need to waste any memory on screen buffers. This also reduced CPU usage as the user wouldn't get any CPU time until they pressed a key, and the scheduler might queue up multiple key presses before even switching to the user's task (while still showing immediate feedback)
They also had superior IO. Home computers were connected to slow floppy drives (at best, some were still using tape) so they typically tried to keep the whole working set in memory. But multi-user machines had relatively fast hard drives and could afford to shuffle the working set in and out of memory as needed, with DMAs handling the actual transfer in the background.
As others have pointed out, these machines had bank switching. But I doubt such machines were ever configured with more than 256k of memory, with 128k being more typical. Wikipedia claims 32k was the absolute minimum, but with very little free memory, so I suspect 64k would be enough for smaller offices with 4-6 users.
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.
I’d note those competed with minicomputers, my high school had a PDP-8 circa 1981 when I was taking a few classes there while still in elementary school. The PDP-8 could support three terminals of interactive BASIC or could be brought up in a single user mode where you got more memory and could run bigger programs like the Crowther & Woods ADVENTURE. A bigger school has a PDP-11 with about 20 terminals. By 1985 or so my school got a VAX-11/730 which is basically like a modern computer.
Yes, at my first job, we had a VAX 11/785 which ran an entire engineering department. About 30-40 terminals.
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).
Often they had bank switching to access more memory.
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.
Low effort humour is discouraged, it's in the site guidelines and since it wasn't amusing, just confusing, perhaps you should skip the humour and consult them.
Uh. I seem to be suffering from the Mandela effect; it is not in the site guidelines. It's definitely the overall policy officially or otherwise though (one which I'm entirely happy with despite having a juvenile sense of humour myself).
I think this essay is where it originated: https://paulgraham.com/hackernews.html
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.
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.
Accompanying video: https://youtu.be/tMYGlYO3v9U?si=e0UUzCVyMtc6L2-L
What are the 5 NOPs for before the RETI?
Also curious about this
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.
I was thinking more about the sharp sm83 chip. Gameboy Advanced is just too modern by comparison...