OS/A65 Operation without MMU

Using OS/A65 without an MMU requires some special measures. One of it is to coordinate all running task 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.
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 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.

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