General Category > LisaList2

LisaEm 1.2.7-RC4 support bug reports

<< < (27/34) > >>

pcamen:
I'm contemplating upgrading from macOS Catalina to Big Sur on my primary Mac.  I haven't seen any discussion here about Big Sur support for LisaEm, and it isn't starting for me presently on Big Sur (it just doesn't start).  Is Big Sur support for LisaEm in the works possibly? 

rayarachelian:

--- Quote from: pcamen on March 07, 2021, 05:54:04 pm ---I'm contemplating upgrading from macOS Catalina to Big Sur on my primary Mac.  I haven't seen any discussion here about Big Sur support for LisaEm, and it isn't starting for me presently on Big Sur (it just doesn't start).  Is Big Sur support for LisaEm in the works possibly? 

--- End quote ---

Just made a bunch of  fixups to the unstable branch and was able to compile this in a macos 11.0 big sur virtualbox vm and get it to run the H Boot ROM.
I haven't yet setup an 11.1 VM, but hopefully that won't matter.

If you want to go through the trouble of compiling it yourself from the unstable branch, it should come up for you. That said RC3 or RC3a will likely not work as is.
The future RC4, or a build from this branch should work with Big Sur.

rayarachelian:
About UniPlus, I've previously added a patch to do the right exception on the 68010 MOVEC opcode it uses to test if it's on a 68010. It then threw profile synchronization error messages up, which I've addressed by patching the profile drive to skip some assertions about CMD/BSY timing - which is very tightly controlled based on CPU cycles and would break when running faster than 5MHz if the VIA timers don't match the CPU exactly. It currently does read a couple of sectors from the profile and then just stops.

There was also some VTIR synchronization it did, also with very tight timing loops that I've previously fixed.

On top of that, last week I added High Level Emulation code for UniPlus when it tries to read or write from the ProFile. I've tested the reads and they work the same as without the HLE code.

In both cases at some point it switched MMU contexts to context 2 and got stuck executing some opcode which Generator is unable to disassemble. It shows up like so:


--- Code: ---A 0:0000002a 1:00000026 2:0006d600 3:00fe1d0e 4:00fe0000 5:00007ff8 6:00068b38 7:000000fc SP:00fa07f8 PC:00000020 SRC:

2/00000020 (1 1/0/0) : 60fe 0000                  : ....     : 1048 : dc.l $60fe0000  SRC:clk:000000000a0400d3 +8 clks
D 0:00000014 1:00000022 2:000fffff 3:0000000b 4:0000ffff 5:00000073 6:00000010 7:000001d9 ......c imsk:0 pnd:3 (1/0/normal cx:2)SRC:
A 0:0000002a 1:00000026 2:0006d600 3:00fe1d0e 4:00fe0000 5:00007ff8 6:00068b38 7:000000fc SP:00fa07f8 PC:00000020 SRC:

2/00000020 (1 1/0/0) : 60fe 0000                  : ....     : 1048 : dc.l $60fe0000  SRC:clk:000000000a0400dd +8 clks
D 0:00000014 1:00000022 2:000fffff 3:0000000b 4:0000ffff 5:00000073 6:00000010 7:000001d9 ......c imsk:0 pnd:3 (1/0/normal cx:2)SRC:
A 0:0000002a 1:00000026 2:0006d600 3:00fe1d0e 4:00fe0000 5:00007ff8 6:00068b38 7:000000fc SP:00fa07f8 PC:00000020 SRC:

--- End code ---

But it turns out that this is actually an on-purpose infinite loop. I thought perhaps this was some bug with the MMU, or CPU or some other thing, it's not. When I ran that opcode through ODA, it said this was bra.s to itself. I verified this in EASY68k by assembling this, and got the same opcode.

So it thinks this is a 4 byte opcode, but really it's a two byte opcode that's actually just a short branch to itself.


--- Code: ---00020000  60FE                       2  START: bra.s START

--- End code ---

So this is on purpose, for whatever reason. It could just be the idle loop of the kernel when it doesn't yet have any spawned processes to exec (i.e. init), however there is a bug in Generator - at least in the disassembly side where it doesn't properly disassemble this opcode.

I did see similar loops, but only after panic messages were sent to printf in the pro.c code, and they use the same 60 FE opcode (these are emitted by "while(1);" C code. So this is unlikely to be a panic.
Another reason is that pressing the power switch when looping like this, it prints "Shutting down" and then shuts down, though that's probably in an ISR somewhere.

I've added some code to detect these infinite loops and increase cpu clocks, which has the effect of causing the next timer interrupt to fire sooner.

I also saw uniplus copy a lot of data using MOVEM, and in one case using a direct A register with an offset but no pre-decrement nor post-increment, but looking at the code, it appears to be doing the right thing, though found a bug in the debug output where it would print the wrong register, so that was a false positive for a bug. i.e.:

--- Code: ---255787 1/000245de (1 1/0/0) : 48e8 fcfc 0004             : H.....   :  687 : MOVEMRM.L  {0xfcfc}: D2-D7/A2-A7,$0004(A0)  SRC:clk:000000000ceba933 +16 clks

--- End code ---

So not sure what else is wrong with emulating uniplus yet. It's closer, but not yet there.
The only odd thing I see is that the keyboard type interrupts to floppy size message, it should say Microdiskette with 1 head, but the Keyboard Type message interrupts it. Not sure if this is an issue or not, nor why it shows up there.  (see screenshot below).

anonymous:

--- Quote from: pcamen on March 07, 2021, 05:54:04 pm ---I'm contemplating upgrading from macOS Catalina to Big Sur on my primary Mac.  I haven't seen any discussion here about Big Sur support for LisaEm, and it isn't starting for me presently on Big Sur (it just doesn't start).  Is Big Sur support for LisaEm in the works possibly?

--- End quote ---

I have found a way to get LisaEM working in big sur fairly easily. First, download this version of LisaEM 1.2.7 beta: https://lisaem.sunder.net/downloads/LisaEm-1.2.7-Beta-2020.02.25-x86_64-only-macos-X-10.12-and-higher.dmg. You can test this while on Catalina by replacing your LisaEM app with this new app. In my experience, it works with minor display glitches, but nothing major, and the experience is still great. After replacing and testing the beta app, you can upgrade to big sur. However, it will not work immediately. You need to install sdl2 on Big Sur. The easiest way is using homebrew: run these three commands in the mac terminal. If an error comes such as "brew not a command," then you need to install brew: https://docs.brew.sh/Installation.

brew install SDL2

brew install SDL2_image

brew install SDL2_ttf

anonymous:

--- Quote from: pcamen on March 07, 2021, 05:54:04 pm ---I'm contemplating upgrading from macOS Catalina to Big Sur on my primary Mac.  I haven't seen any discussion here about Big Sur support for LisaEm, and it isn't starting for me presently on Big Sur (it just doesn't start).  Is Big Sur support for LisaEm in the works possibly?

--- End quote ---

I have found a way to get LisaEM working in big sur fairly easily. First, download this version of LisaEM 1.2.7 beta: https://lisaem.sunder.net/downloads/LisaEm-1.2.7-Beta-2020.02.25-x86_64-only-macos-X-10.12-and-higher.dmg. You can test this while on Catalina by replacing your LisaEM app with this new app. In my experience, it works with minor display glitches, but nothing major, and the experience is still great. After replacing and testing the beta app, you can upgrade to big sur. However, it will not work immediately. You need to install sdl2 on Big Sur. The easiest way is using homebrew: run these three commands in the mac terminal. If an error comes such as "brew not a command," then you need to install brew: https://docs.brew.sh/Installation.

brew install SDL2

brew install SDL2_image

brew install SDL2_ttf

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version