General Category > LisaList2
Problems With The Boot ROM "Display Message" Routine
sigma7:
--- Quote from: AlexTheCat123 on April 18, 2022, 02:42:58 pm ---
--- Code: ---SCREENBASE EQU $F8000 ;The base address of the screen memory
SCREENLOCROM EQU $110 ;Where the message routine can expect to find a pointer to the screen memory base address
...
MOVE.L #SCREENBASE,SCREENLOCROM ;Put the screen base address in $110
--- End code ---
--- End quote ---
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
AlexTheCat123:
--- Quote ---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
--- End quote ---
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.
sigma7:
--- Quote from: D.Finni on April 18, 2022, 04:29:32 pm ---General note: whenever you use MOVE.L #$0, you can use MOVEQ instead. This instruction clears the entire long word.
--- End quote ---
Another obscure reason to use MOVEQ...
68K assemblers will sometimes optimize <MOVE.s #0, ea> into <CLR.s ea> to save bytes.
(Where .s is the data size [.B, .W, .L] and ea represents the effective address)
However, there is a 68000 quirk with the CLR instruction in that it will read from the target address before writing 0.
In most cases this is harmless (although it takes more cycles), but in cases where one is accessing hardware, sometimes that dummy read can have unexpected consequences (such as generating an unintended handshake pulse -- as can be observed when the ROMs ProFile code loads boot blocks, or potentially discarding data from the SCC FIFO, etc.).
<SF.B ea> operates the same as <CLR.B ea> and also reads before writing.
So, using <MOVEQ #0, ea> may be helpful to minimize code space, maximize speed, and avoid obscure bugs.
AlexTheCat123:
--- Quote ---So, using <MOVEQ #0, ea> may be helpful to minimize code space, maximize speed, and avoid obscure bugs.
--- End quote ---
Good to know! Thanks for all the help guys!
rayarachelian:
--- Quote from: AlexTheCat123 on April 18, 2022, 06:29:04 pm ---
--- Quote ---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
--- End quote ---
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.
--- End quote ---
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.
Navigation
[0] Message Index
[*] Previous page
Go to full version