The TI-83+ does not have bank switched RAM, but it's sister products the 83+ SE, 84+, and 84+ SE do. Regardless, you can achieve preemptive multitasking on z80 without banked RAM, you just need PIC.

Sure, but I think SymbOS specifically requires bank switching capability:

http://www.symbos.de/symmodul.htm?0

(relevant sections passed through google translate de->en)

Memory Management

SymbOS supports up to 1024 KB of RAM, depending on what was connected to a memory expansion. The memory manager splits the entire RAM into individual blocks of 256 bytes, which can be assigned completely dynamically. A big feature here is the fact that SymbOS applications are always executed in a secondary 64K ram bank. Thus, each program is allowed to allocate and address up to 63KB in one piece. Screen memories and operating system routines are all in the first, severed ram bank. They are virtually invisible and do not stand in the way of the application. Of course, an application can also reserve more than 63KB for itself.

Banking Management

If an 8-bit CPU is to manage a memory of up to one megabyte (which is theoretically at least 20 bits for the address bus), then it can possibly become very complicated. This is where the bank switching administration of SymbOS comes in, which regulates everything independently and transparently. Completely unaffected, e.g. System routines located in a completely different bank are called by programs as if they were in the same 16-bit address range. Using the so-called transfer ram area (the top 16KB of a ram bank) both the operating system and the application can access the same memory from two different 64K banks. Copying memory areas between any two RAM banks is also possible without any problems.

Yeah, fair enough. You could probably get it running on one of the models I mentioned above.

> you just need PIC.

Or a relocator. This can be a bit tricky but it's been done on many architectures.

Do you have any links/pointers to systems that did this?

Wrote my own for 68xx and 65xx chips in ancient times.

https://en.wikipedia.org/wiki/Relocation_(computing)

If you have access to the symbol table it is an easy problem to solve, if you don't it can get quite difficult all the way to impossible if the original code makes use of tricks such as jumping into the middle of an instruction. But if the code is 'well behaved' then it can usually be done.

Many games used tricks like this to relocate themselves to memory that was otherwise not usable for programs, for instance to live in secondary screen space. This ensured the game would be wiped on reset. Crude but effective.

For fun, I took a "happy medium" approach in KnightOS. Programs are written with RSTs (basically the z80 version of traps) next to each instruction with a relative address, then the kernel looks up the return address on the stack, partially decodes the next instruction, and then modifies the code in RAM to update the address to the correct one. It's basically just-in-time PIC.

https://github.com/KnightOS/kernel/blob/master/src/00/restar...

Heh, that's cool. How do you remember which ones you've modified so you don't do it twice?

It also modifies the reset (trap instruction) in place and makes it a no-op.