LisaList2

Advanced search  

News:

2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: 1 ... 6 7 [8]   Go Down

Author Topic: LisaEm 1.2.7-RC3a support bug reports  (Read 6508 times)

D.Finni

  • Sr. Member
  • ****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 70
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #105 on: November 11, 2020, 04:11:18 pm »

tried monitor last night and it immediately crashed so either the MMU changes broke it, or it's a broken image. Will retest this again when I've got the MMU working again.
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.
Logged

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +19/-0
  • Offline Offline
  • Posts: 354
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #106 on: November 12, 2020, 08:02:10 am »

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.


Code: [Select]
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.
« Last Edit: November 19, 2020, 10:36:14 pm by rayarachelian »
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +19/-0
  • Offline Offline
  • Posts: 354
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #107 on: November 23, 2020, 03:02:25 pm »

Still fixing some more MMU related code, in the last week, I've written three alternate MMU handlers, two of them worked, the other did not, however with the new ones that worked, it broke LOS, so there's some more fixes to apply. One of the MMU handlers completely gets rid of the address ea caching and calculates the RAM address right off SOR on each access. The other uses math as before, but now has a lot of int32 casts around the addition code which seems to be making the big difference.

The ones that worked also fixed Monitor, after which I fixed the yellow contrast bug.

It also seems to be allowing MacWorks 3.0 to install to the hard drive. It didn't work on the first pass, but after I enabled tracelog to try to find the issue, it worked the 2nd time around - this might be some timing bug since TRACELOG slows it down to about 500KHz on my machine, but it did work and allow me to copy the System folder over to the hard drive. At least now I have a 5MB ProFile drive that has MacWorks installed on it for what it's worth.


You still have to boot off the boot floppy (just the same as with lisaem <=1.0) because it will throw error 75 when trying to boot off the hard drive. MacWorks XL 4.5 still throws a sad mac. (On a real Lisa, MacWorks 3.0 does self-boot off the hard drive without the boot floppy, so that's yet another bug somewhere, likely with ProFile/via emulation.)


One thing might be the serial number, not sure about this, but was using it with the magic-zero serial number on the first attempt and then switched to one of my Lisa's serial numbers - perhaps it cares, but not sure why it would, but I did see a message saying it read the serial number after it started booting.

One clue might is that all of a sudden after the new MMU fix, the vectors I use to detect the OS in glue.c have moved for MacWorks and Monitor.
Perhaps these new address changes have something to do with LOS failing. LOS now crashes by executing code that doesn't exist - that is it branches or JMPs or something to a region where no code has been loaded which causes the emulator to bail since there's no basic block for it to work on.

But obviously Monitor crashing on boot was a bug that got fixed so both somewhat closer, and further away. UniPlus behaves exactly the same as before, with a double trap panic, etc. however Xenix is now crashing in the same way that LOS crashes, so that's another clue that the MMU isn't quite there yet.
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +19/-0
  • Offline Offline
  • Posts: 354
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #108 on: November 24, 2020, 06:09:04 pm »

I've fixed LOS from crashing, nothing else has changed/improved than MacWorks 3.0. Going back to the pty issues and mouse click-release issues.
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +19/-0
  • Offline Offline
  • Posts: 354
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #109 on: Yesterday at 12:03:28 pm »

Managed to fix the pty code last nigh, xon/xoff worked well, the output isn't getting cut off anymore.
Serial port A is still broken, however, looking at it now.
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'
Pages: 1 ... 6 7 [8]   Go Up