I used the Monitor 12.3 image that's a 400K floppy. None of the Twiggy Monitors would boot. Got a hang with an hourglass cursor.
Ok thanks, will retry. i was using that same one so must be the MMU changes that's breaking it.
So there's a bit of a puzzle I'm trying to solve with the MMU. The docs on the surface seem pretty forward, but they're not when it comes to the stack. I wrote a small test program that fills RAM with the same value as the address, and then I set MMU segment 125 to be a stack segment of length 32. And this should be mapped from the top. So segment 125 maps to the range 0x00fa000000-0x00fbffffff.
For normal RAM segments the space is allocated to the start, that is fa000000. But if it's a stack, it starts at 0x00fbffff and grows downward by SLR pages. each 512 bytes.
So the goal here is to get LisaEm in service mode to match what this code does on a real Lisa and then retry UniPlus and see if it gets any further.
The bug there for those who missed it was that there's a memory fill routine that because of the incorrect stack mmu segment setting overwrites it's return address, which then winds up executing from address 0. After looking at it, I saw that this was because two MMU segments pointed to the same physical space, and realized LisaEm's stack segment implementation is incorrect.
The mmu test code looks like this incase anyone's curious. It just fills memory, sets segment 125, and goes back to the boot ROM, which throws an error, likely I should have cleared D0, but the error is good because then I can hit Apple-S to go to service mode and poke around memory:
So I put this on a CF card and fed it to the floppy emu, and booted off it, and then went in service mode to poke around memory. I then modified that 720 and 600 and reran it, and no matter what I do, I always get the same window of memory that works. Changing the SOR from 600 to 400 or 500 works and I see a different set of values there. But any other addresses outside that single page cause a bus error which means the size value in SLR isn't honored at all.
00020000 Starting Address
Assembler used: ASy68K Assembler v5.15.04
Created On: Thu Nov 19 21:37:07 2020
00000000 1 ;------------------------------------------------------------------------------------
00000000 2 ; mmu-stack tester - tiny program to fill most of Lisa RAM with it's own address
00000000 3 ; and then set mmu segment 125 so we can see the physical addresses and test
00000000 4 ; access via Service Mode.
00000000 5 ;------------------------------------------------------------------------------------
00000000 6
00000000 7
00020000 8 ORG $20000 ; starting address note spaces at start
00020000 9
00020000 10 START:
00020000 203C 00020080 11 MOVE.L #$20080,D0 ; start ~0x40 bytes after this code.
00020006 12 FILL:
00020006 2040 13 MOVE.L D0,A0
00020008 2080 14 MOVE.L D0,(A0)
0002000A 5880 15 ADDQ.L #$04,D0
0002000C B0B8 0110 16 CMP.L ($110),D0 ; fill RAM until screenbase
00020010 6FF4 17 BLE FILL
00020012 18 ;--------------------------------------------------------------------------------------------------------------------------------
00020012 19 ; uniplus sets mmu like this:
00020012 20 ;
00020012 21 ; mmu[1][122].slr:0c00,sor:0000 00f40000-00f5ffff::-->(00000000) type::unused:0c00
00020012 22 ; mmu[1][123].slr:0c00,sor:0000 00f60000-00f7ffff::-->(00000000) type::unused:0c00
00020012 23 ; mmu[1][124].slr:0c00,sor:0000 00f80000-00f9ffff::-->(00000000) type::unused:0c00 v- so is this a bug somewhere else?
00020012 24 ; mmu[1][125].slr:07fc,sor:05dd 00fa0000-00fbffff::-->(0003ba00) type::rw_mem:07fc <- this is normal RAM, not stack!!!
00020012 25 ; mmu[1][126].slr:0900,sor:0000 00fc0000-00fdffff::-->(00000000) type::io_spc:0900
00020012 26 ; mmu[1][127].slr:0f00,sor:0000 00fe0000-00ffffff::-->(00000000) type::siospc:0f00
00020012 27 ;
00020012 28 ; 2x of 7d (125)=0xfa => 0x00faxxxx == sor:00fa8008 slr:00fa8000
00020012 29 ; 400=rostack, 500=romem, 600=rwstack, 700=rwmem, 900=iospace, c00=bad page, 0f00=sio/rom
00020012 30 ;--------------------------------------------------------------------------------------------------------------------------------
00020012 247C 00FA8008 31 MOVEA.L #$00fa8008,A2 ;MMUSADRB,A2 ;SET MMU BASE REG PTR - use fa here as fc will cause crashing in ROM - fa8008 is SOR
00020018 267C 00FA8000 32 MOVEA.L #$00fa8000,A3 ;MMUSADRL,A3 ;SET LIMIT REG PTR - fa8000 is SLR
0002001E 303C 0300 33 MOVE.W #$0300,D0 ;SET BASE VALUE should be 300*200=60000
00020022 323C 0600 34 MOVE.W #$0600,D1 ;MEMLMT,D1 ;SET to stack, only 32 pages.
00020026 287C 00FE0084 35 MOVE.L #$00fe0084,A4 ;return value is monitor entry
0002002C 4EF9 00FE008C 36 JMP $00fe008C ;WRTMMU and return to A4
00020032 37
00020032 38 END START ;need spaces before end keyword for it to work.
No errors detected
No warnings generated
SYMBOL TABLE INFORMATION
Symbol-name Value
-------------------------
FILL 20006
START 20000
When I went to try this on another Lisa that has the "H" ROM, to eliminate whether this is an issue with the "F" ROM not honoring SLR properly, unfortunately either the display on my floppyemu died, or the entire floppy emu died. Grrrr. So now, worst case, I'll have to either enter these bytes by hand on the keyboard or make a physical floppy... Or I can use the 2nd floppy emu that I got for a Mac SE instead...
Funnily enough I do have a few of the nokia LCD screens that it uses because when I got the floppy emu, it came with a dead display so I ordered a few of them, but I'll have to go solder the header pins on another... Meh....
This is the exact reason I wrote this emulator - because I got tired of dealing with failing Lisa hardware and irony of ironies, the floppy emu I got so I don't have to deal with failing floppies also failed...
Limiting the stack to a single page and trying UniPlus with LisaEm now causes a different crash on an undocumented opcode - similar but different to the last time, which I'll investigate further as well. Hmmm, come to think of it, I should check that opcode on a real Lisa to see if it also causes a crash - maybe that's actually not supposed to crash. Wouldn't that be quite the find!
Somewhat in parallel I'm working on the xon/off (software flow control) SCC handling and mouse issues in LOS. I haven't yet attempted to fix the contrast issue.
Edit 2020.11.12 8pm:
I manually typed in the above (now slightly cleaned up code) into my H-ROM 2/10 and got exactly the same results. I confirmed that it only allocates a single 512 byte page of stack and no more. It's not the F-ROM vs H-ROM, either the above code is wrong, or the Lisa MMU can only allocate a single 1 page stack for a segment. Edit: this was caused by an error in the tester code.
Tried that illegal 4e7a opcode that UniPlus tries to execute and got an error 48 (Illegal Instruction), so not quite sure what it's for, but throwing an illegal instruction trap is the right thing to do.
Edit 2020.11.19: so going over this code again, it turns out I've swapped the pointers to SLR and SOR, and that's what it wasn't working properly. I've modified the tester code, and optimized it a bit, and tried it again, and got proper results that match what the HWG's say. However, trying the same in LisaEm resulted in physical memory underflows, which are errors in emulation, which I'll fix. So this exposed a pretty huge bug.
The good news is that it allocates the right number of pages at the right virtual addresses. The bad news is that the physical location of the RAM is wrong.
The weird thing, the SLR that was used by UniPlus is incorrect, it's 7xx, which is not a stack segment, but rather a normal RAM segment, even though it was used as a stack. So that will require a lot more investigating, That could be on purpose or caused by some other issue elsewhere, will find out after I fix this.