FYI & HTH: ScreenBase varies according to the amount of RAM in the machine, so you probably don't want to change it from what was already in $110
Thanks for letting me know! I didn't know that the Lisa automatically puts the screen base address there; I thought that you had to do it manually.
To clarify this a bit, the display is set to the highest available RAM-32K since the screen size is 32K. Also note that it's set to the physical RAM page, which can differ from the MMU mapping should the running OS choose to do that.
But the Boot ROM itself will set the all RAM in context 0 (seg1=0, seg2=0) to be continuous and then the very last 32KB is set to the video display page. Note that MMU context 0 is special as well. When supervisor mode is turned on due to a trap, or any transition to supervisor mode, the MMU context automatically switches to context 0.
There are also context 1,2,3 which you can get by playing with seg1, seg2 - these are used for when the CPU is in UserMode, however the Boot ROM does not set these up, so your OS needs to set them up.
There is a special SETUP mode which allows you to setup the MMU, this is enabled or disabled through two latches, just like seg1, seg2. however, you have to be careful because not all memory is available in SETUP mode and it's kind of tricky. The Boot ROM is mapped in SETUP mode, so its MMU setup routines are available, which means you can use those addresses to setup contexts 1-3 if you want, though some RAM is also available that way.
Another thing to know is that all of these latches, seg1, seg2, setup, as well as the soft/hard memory error latches can be turned on by just *reading* from memory! This is some sort of cost cutting method that the Lisa engineers did. If you read from one address, you enable a latch, but if you read from the other address associated with that latch, you turn it off. So yes, even reads can behave like writes!
Another thing to know is that in contexts 1-3, it's possible to have a program that starts at address zero - infact UniPlus and Xenix do exactly that. Now, normally interrupt vectors live in low memory, however this is not the case when you're in User mode on the Lisa. You can map memory to this space, and put a program at 0.
When an interrupt or exception occurs, because of the switch to supervisor mode during exception/interrupt processing, the CPU will switch to supervisor mode, which automatically then switches to context zero, handle the exception processing, and then when it exits supervisor mode, it will return to the original MMU context, allowing that user mode program to continue.
(This also means that when doing process scheduling, you should store the current process's context number somewhere so you can schedule between contexts 1,2, and 3 if you're doing pre-emptive multitasking - and you can use one of the VIA timers to drive pre-emptive multi-tasking. However, if you're just doing interrupt handling, you don't need to worry about it, because at the end of the RTE, it will return to whatever process in whatever context it was running in, and you can do either TRAP, or A-Line, or F-Line handling without issue. Normally A-LINE traps are allowed, but F-Line traps are reserved for a PMMU or FPU. But the Lisa does not support these, so it's possible to also use F-Line traps as well on a Lisa - example, I use them inside of LisaEm to handle High Level Emulation code.)
Weirdly enough the CLR opcode does both a read and a write, but luckily if you use it against these latches it won't cause issues since it will do both a read and a write and since the address is the only thing that matters for these latches, it won't hurt anything. But as @sigma7 mentioned, the CLR opcode should never be used with I/O as that will access the same address 2x and this will cause issues for things like VIA6522s.
(Perhaps the CLR and SF.b opcodes might be used in a multiprocessor system as some kind of semaphore/locking mechanism by doing a read before a write if you setup a latch on the bus the right way, not sure, but this won't apply to the Lisa since it has a single CPU, but might have been useful for something like the Big Little Machine. In general though, an increment is used for semaphore locking in most unixy system rather that set/clear.)
These bits of info are useful for when you decide to write your own OS from scratch. Hint, hint.
