Well, TRAP #0 is especially designed to suppress multitasking and switch off the scheduler - It's the QDOS way to avoid expensive mechanisms like mailboxes and semaphores you'd otherwise need to sync jobs with each other.
@Derek Jobs will only be blocked from concurrent access to the screen when the Pointer Environment is loaded. "Standard" QDOS will happily allow concurrent jobs to access (and garble) the same (or overlapping) screen channels without blocking anything.
Using preemptive multitasking
-
- Font of All Knowledge
- Posts: 4780
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Using preemptive multitasking
Thanks for the clarification, I will have read all the books againtofro wrote: Thu Jun 26, 2025 6:22 am @Derek Jobs will only be blocked from concurrent access to the screen when the Pointer Environment is loaded. "Standard" QDOS will happily allow concurrent jobs to access (and garble) the same (or overlapping) screen channels without blocking anything.
Regards, Derek
Re: Using preemptive multitasking
I forgot a lot, but this is a QDOS characteristic I remember well.tofro wrote: Thu Jun 26, 2025 6:22 am @Derek Jobs will only be blocked from concurrent access to the screen when the Pointer Environment is loaded. "Standard" QDOS will happily allow concurrent jobs to access (and garble) the same (or overlapping) screen channels without blocking anything.

Re: Using preemptive multitasking
The whole 68K family never had anything directly comparable to the Intel 80286+ "protected mode", but that does not mean "RAM conflict can happen quite easily". The 68K from the very beginning supported supervisor and user modes to do a similar thing. Maybe you refer to the concept of protected virtual addressing via MMU, which is available from MC68030 upward, and was used by the QL compatibles Q40 and Q60 - but only under Linux.ecdhe wrote: Wed Jun 25, 2025 11:34 pm Just like RAM conflict can happen quite easily as the 6800X doesn't support protected mode.