3 ms·
I once implemented a pre-emptive kernel and OS on a very crude hardware, the Hewlett-Packard Graphing Calculator HP48GX, running a Saturn CPU (4Bits with 64bits
by stephc_int13 3y ago
I once implemented a pre-emptive kernel and OS on a very crude hardware, the Hewlett-Packard Graphing Calculator HP48GX, running a Saturn CPU (4Bits with 64bits registers, a weird beast).
It can still be downloaded here : https://www.hpcalc.org/hp48/apps/shell/ https://www.hpcalc.org/hp48/apps/shell/
You don't need MMU or anything of the sort.
The only thing you need is programmable interrupts.
My implementation was using a 64Hz timer, that was also synchronized on the LCD screen "vsync" as it had to be serviced for kernel-level double buffering and different modes of simulated multiple grey levels.
It is much less difficult than it seems, save registers, save context, load context, load registers, return to the current process.
Optimizing the code is just a good knowledge of the CPU constraints and bit of juggling with registers. It was a simpler time, you could benchmark code by counting cycles, instruction by instruction. No cache, no branch predictors, no throttling.
- GlenTheMachine 3y agoI did something similar on the C64 (6502). Programmatically user code could mask interrupts, but as long as it didn’t it worked fine. It saved all the registers and restored them prior to switching execution threads. The unified memory space required that each thread ask for an absolute memory offset to be allocated and then voluntarily stay in that space.
- OnlyMortal 3y agoThe vertical blank interrupt was how many games did their screen updates and played music. Those were good days writing demos and crack intros.