General Category > LisaList2
LisaEm 1.2.7-RC4 support bug reports
rayarachelian:
Eh, so 6 weeks forwards, 3 weeks back.
Had to roll back some of the profile HLE code. In my zeal to get UniPlus working, I hadn't noticed for quite a few days that I broke LOS from booting, and then had to do a lot of bisecting to figure out exactly where the bugs were, and roll them back. Pushed to unstable.
The new HLE (High Level Emulation) checkbox in preferences works for the Boot ROM phase of loading LOS (before the Welcome screen).
I'll also be adding LOS+MacWorks HLE support in the next few days/weeks. Will re start again on UniPlus, but I guess I'll have to keep testing against LOS.
rayarachelian:
I've added HLE ProFile hard drive acceleration to both MacWorks XL 3.0 and LOS 3.1, both seem to be working.
Pushed to the unstable branch on github.
Next up, restarting on ProFile code tests of the BLU image of UniPlus that Jason sent my way, to get it to boot up all the way.
rayarachelian:
So seeing some weird issues in both UniPlus and Xenix around the stack. In one case when booting off Xenix, IRQ#2 gets triggered from the COP, but rather than use an RTE to get out of the Interrupt Service Routine, the last thing that unwinds the stack is an RTS, this causes the value of 2100 to be loaded into the high word of the PC and 0001 into the low word of the PC - these come from the SR being pushed on the stack during the IRQ. RTE would have successfully restore the stack properly.
This happens after the kernel has started up and reported about most of the hardware, but before
So either Xenix isn't ready at this point to receive an IRQ from VIA1/COPS421, or the wrong value has been loaded into the IRQ vector.
Using the ROM HLE code works fine with LOS and MacWorks, but in UniPlus, instead of showing the boot loader ":" prompt, it throws error 75, but looking at the tracelog, I see another odd address error issue come up, similar to the one that happens in Xenix.
I've verified that MOVEM, LINK, UNLK opcodes and other mechanisms are working as expected. It's possible/likely there's some side effects from the HLE ProFile routine, but not sure yet. Maybe it's relying on some register values that are normally thrown away, or an IRQ happens when it's not expected (but in Xenix case above, the IRQ mask was 1 and the IRQ triggered was 2, so this indicates to the "hardware" that the OS is ready to receive an interrupt.
In the UniPlus, during the loader startup (standalone/ boot prompt) when HLE is enabled, I see the stack overwriting some code around 0060000, and ofc when that's executed, the emulator crashes. This doesn't happen with HLE turned off, so certainly something's up with A6/A7 which are used in stack frames. I suspect debugging this will be easier since I can turn tracelog on, record what happens, turn HLE on, repeat, and diff and see where it varies. Fixing whatever this is might help on the Xenix side too.
Obviously all this stuff works on a real physical Lisa, so it's something that's different in the emulator than in the hardware that's at fault, as usual. Most likely the symptoms are showing up way after the thing that's different happened, so it's hard to track down (for now.) It's probably some stupid unused register being used side effect, or an off-by-one, etc.
I'll probably timebox this to another week or two of debugging/exploring; if I make progress there, great, if not, I'll go back to the terminal window stuff, etc.
rayarachelian:
--- Quote from: rayarachelian on April 22, 2021, 08:29:14 am ---UniPlus, during the loader startup (standalone/ boot prompt) when HLE is enabled, I see the stack overwriting some code around 0060000, and ofc when that's executed, the emulator crashes. This doesn't happen with HLE turned off, so certainly something's up with A6/A7 which are used in stack frames. I suspect debugging this will be easier since I can turn tracelog on, record what happens, turn HLE on, repeat, and diff and see where it varies.
--- End quote ---
The ROM Profile read function D1 is the sector number to read, looks like D1 is actually preserved by the ROM call if the sector is read successfully. UniPlus's loader uses the old value in D1 to load the next sector, LOS's does not, so instead it wound up reading the same sector over and over again, and of course this led to a later crash. :)
tl;dr don't rely on the comments in the source code. they're not always completely true.
One dumb bug fixed, 99+/-whatever more to go.
--- Code: ---0| ;-----------------------------------------------------------------------------
1F70| ; First initialize and then ensure disk is attached by checking OCD line.
1F70| ; Assumes ACR and IER registers of VIA set up by caller. For boot, these
1F70| ; are cleared by power-up reset.
1F70| ; Register usage:
1F70| ; D0 = scratch use A0 = VIA address for parallel port interface
1F70| ; D1 = block to read A1 = address to save header
1F70| ; D2 = timeout count A2 = address to save data
1F70| ; D3 = retry count A3 = scratch
1F70| ; D4 = threshold count A4 = unused
1F70| ; Returns:
1F70| ; D0 = error code (0 = OK)
1F70| ; D1 = error bytes (4) <--- not true, this returns the same D1 value (sector #) when there's no error.
I was setting this to zero thinking error bytes are zero to signal no error along with D0.
1F70| ; D2 - D7 and A1 - A6 are preserved
1F70| ;-----------------------------------------------------------------------------
--- End code ---
rayarachelian:
More work on MacWorks around allowing 4MB of RAM - there's now a preferences checkbox, but likely this should be kept off for now (at least in this version).
Added more code to the uniplus partition resizer.
Added a few more disk conversion tools, plus added options to turn on/off interleave5/deinterleave5 options for some of them.
--- Code: ---raw-to-dc42 -d aphid.image # convert a Cameo/Aphid image to LisaEm, likely
dc42-to-raw -i lisaem-profile.dc42 # copy a LisaEm image to Cameo/Aphid maybe.
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version