OS/A65 Operation without MMU

(c) 1989-96 Andre Fachat

Using OS/A65 without an MMU requires some special measures. One of it is to coordinate all running tasks concerning their memory usage.
The memory handling is built for a system with an MMU - so that it is not really usable for a system without MMU. And 4 kByte as page block size is to big to be really useful. There are two ways of using the given memory management:

Allocating a memory block and accessing it using zeropage pointer and indexed indirect addressing. But for the zeropage (and the rest of Block 0, i.e. $0000-$1000) the programs have to be coordinated by the programmer during assemble time. There is currently no easy way to allocate zeropage address space. Maybe a load time relocator could allocate the zeropage address (or even memory address) space and relocate all refernces appropriately.
Ignore the memory handling for systems without MMU and coordinate the program's memory usage at assemble time. This is what is currently done with OS/A65.

There is one thing that's difficult to handle on a 6502, the stack. It's only 256 byte large (small that is...). And with a multitasking OS the stack has to be used by several programs at the same time. One approach is to copy the stack contents to another place every time a task switch is done. But that's a big speed penalty. Instead I split the stack into 6 pieces, 5 of them for a task and the last one for the system. So on a system without MMU, only five tasks can be running concurrently. With version 1.3.9 we got a new config option, STACKCOPY. With this option the stack of a task is saved in some save area when doing a task switch. This is slower, but allows much more stack space in a task and much more tasks.

There is one other thing that cannot easily be coordinated - the SEND buffer. This buffer is used for communication with the kernel. As OS/A65 originated from a system with MMU, there was no real need not to use an absolute address for the buffer, thus saving registers for other purposes.
For systems without an MMU, the usage of the SEND buffer has to be coordinated between the tasks. Therefore a system semaphore is used.

#define	SEM_SENDBUF	<-1

Before accessing the SEND buffer at $02**, the task has to allocate it with a PSEM operation on the SEM_SENDBUF semaphore. After the system call, it has to be freed with a VSEM operation.

Well, and here we are with the known resource allocation problem. Imagine two tasks communicating via send/receive. Then, if the order in which messages are sent is not fixed and therefore predictable, precautions against a lock have to be taken: task 1 allocating the send buffer to send a message to task 2. The same time task 2 tries to allocate the send buffer to send a message to task 1. If it not tries to receive messages while waiting for the semaphore, it will lock.
Therefore the filesystems, for example, do not release the send buffer while executing a command or open a file. In the meantime another task could send a message to the filesystem, locking the send buffer. But the buffer is needed by the filesystem to send the reply message. The filesystems in their current form are not prepared for this situation, so that they don't release the send buffer.

Be careful when using the send buffer - you are warned!

Another topic is the STDIO library. A part of the routines is now thread-save, i.e. can be used without problems. These routines are *putc, *getc, dezbout, hexout and txtout. The directory routines and the assign routines are not thread-save! They can be used by a single program only. For using them, another system semaphore, SEM_STDIO is defined - the current implementation doesn't know about it, though.

As the whole stuff has been ported from a system with MMU, many things had to be changed. I tried hard, but bugs are surely still there. Also the memory management is kind of bogus for a system without MMU.

Suggested reading: "Operating Systems, design and implementation", Andrew S. Tanenbaum, Prentice-Hall