LisaList2

Advanced search  

News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

Pages: 1 ... 7 8 [9] 10 11 12   Go Down

Author Topic: LisaEm 1.2.7-RC4 support bug reports  (Read 53826 times)

stepleton

  • Sr. Member
  • ****
  • Karma: +109/-0
  • Offline Offline
  • Posts: 384
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #120 on: February 20, 2021, 09:07:18 am »

(I've been using the last Windows release I've been able to get my hands on, which is RC3a-2020.08.24. So this may be old news.)

As a feature request (or maybe just advice on how to use a feature that's already there): is there a way to disable the emulator's requirement that there be boot media, and that the boot media look bootable?

I've got a copy of the ROM and I'd like to boot into the ROM now and then, in order to get into service mode and poke around, even if I don't have a disk attached anywhere. It's useful for experimenting with short machine code snippets.

Also, for some of my homebrew operating environments (which boot off of file images that use my bootloader_hd bootloader), the emulator doesn't think the drive is bootable, even though I mark the first tag with $AAAA in the usual spot.
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #121 on: February 20, 2021, 11:29:45 am »

(I've been using the last Windows release I've been able to get my hands on, which is RC3a-2020.08.24. So this may be old news.)

As a feature request (or maybe just advice on how to use a feature that's already there): is there a way to disable the emulator's requirement that there be boot media, and that the boot media look bootable?

Nope that's not been addressed. I'm pretty sure I put those guards in on purpose, but they should only be for ROMless. Can you clarify a bit? Where are you seeing this error message and for what? The ProFile, or a floppy?
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #122 on: February 20, 2021, 12:12:44 pm »

So it's been a while, and I might as well mention some status bits.

Newly discovered bugs in lisafsh-tool:

Yesterday was talking to James Denton and he noticed that LisaFSH tool seems to chop off the first few bytes off a file - I suspect this is because they're in the meta data block. i.e. the metadata is the first 0x34 bytes and the rest is the actual start of the file, or something like that. (This is similar to unixen file systems where if your file data is small enough it's included in a portion of the inode, but in this case it's not in the extent file, but rather in the metadata block.)

There's another bug in LisaFSH tool where it doesn't see all the directory blocks (I think I just fixed this one, but need to test it some more.) It will still extract all the files, but names will be file-xxxx instead, and doing dir will not show the whole disk.

There's a few other old issues such as the extracted files have junk at the end because when I wrote this, I didn't know the exact file size, though I'm pretty sure Natalia Portillo has discovered the size fields and I need to add those to the code.

Bigger problems with LisaEm itself:

But there's a bigger issue that's been blocking me for about two months now. I've mostly implemented XModem code for the TerminalWx code bit. (Unfortunately I should have either pushed an RC before this or opened a branch, so now it's kinda difficult to segregate this code and do an RC release without finishing it.)

Potentially the Lisa has a maximum need for something like 16 terminal consoles. (2 for Serial A, B, 3x expansion slots, each with the possibility of 4 serial ports for the Quad Tecmar Serial Port Card or its modern Sapient clone, one more for interfacing with BLU and yet another as a console for Xenix/UniPlus/LPW.)

So I implemented the TerminalWx as a pair of 16-member arrays that use null pointers (one set for the TerminalWx window, the other for the wxFrame). I won't actually open 16 windows, but rather as one is needed a terminal is constructed at these pointers are populated with a pointer to the relative object.

Event handling:

But this causes an issue for the event handling. Events in wxWidgets are handed via macros like so:

Code: [Select]
wxBEGIN_EVENT_TABLE(TerminalWxFrame, wxTerm)
EVT_TERMINAL_INPUT(TerminalWx::OnTerminalInput)
EVT_MENU(wxID_CUT, wxTextCtrl::OnCut)
EVT_MENU(wxID_COPY, wxTextCtrl::OnCopy)
EVT_MENU(wxID_PASTE, OnPaste)
EVT_MENU(wxID_SELECTALL, wxTerm::SelectAll)   
EVT_MENU(ID_FileCapture,OnFileCapture)
EVT_MENU(ID_TextUpload, OnTextUpload)
EVT_MENU(ID_XMODEM_UP,OnXmodemUpload)
EVT_MENU(ID_XMODEM_DN,OnXmodemDownload)
EVT_TIMER(ID_Timer,OnTimer)
wxEND_EVENT_TABLE()

So how do I tell it which of the 16 window frame event handler is to be registered? I think I might be able to extract a window ID from the event and use that as a sector, and call back the member from one of the objects in the array, but not 100% sure yet.

That's one issue.


OnXModemUpload member function is defined, but not recognized:

But this more immediate compile time error one is very maddening. It's saying it doesn't have a member function OnXmodemUpload even through it's both in the header where the class is defined and in the cpp file where it's implemented! I've even copypasta'ed the member name, and it still throws the same error. Anyone seen anything like this? What's the fix?

In the .h file I have
Code: [Select]
class TerminalWxFrame: public wxFrame
{
    public:
        TerminalWxFrame(wxWindow* parent,wxWindowID id = -1, int port=-1);
        virtual ~TerminalWxFrame();
...
        void OnFileCapture(wxCommandEvent& event);
        void XModemSendBlock(void);
        void XModemReceiveBlock(void);
        void OnTextUpload(wxCommandEvent& event);
        void OnXmodemUpload(wxCommandEvent& event);
        void OnXModemDownload(wxCommandEvent& event);
...
}

And in the .cpp file I have the actual implementation of the OnXModemUpload method (I used to have the unused macro there but removing it didn't help):
Code: [Select]
void TerminalWxFrame::OnXModemUpload(wxCommandEvent& event) //WXUNUSED(event))
{
        if (xferproto) {wxMessageBox(_("Cannot start XModem upload as another file transfer operation is in progress"),_("Cannot Upload now"), wxICON_INFORMATION | wxOK); return;}

        wxString openfile;
        wxFileDialog open(this, wxT("Upload File with XModem:"), wxEmptyString, wxEmptyString,
                                "BLU files (*.dc42;*.blu;*.bin)|All (*.*)|*.*)",
                                (long int)wxFD_OPEN,wxDefaultPosition);

        if  (open.ShowModal()==wxID_OK)  {
            wxString filename=openfile.GetPath();
            upload=fopen(CSTR(filename),"rb");
            if (!upload) {wxMessageBox(_("Could not open file for upload"),_("Cannot Upload"), wxICON_INFORMATION | wxOK); return;}
...


However, gcc (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0) is throwing this, and I've no idea how to go about fixing it.

Code: [Select]
src/host/wxui/z8530-terminal.cpp: At global scope:
src/host/wxui/z8530-terminal.cpp:652:6: error: no declaration matches 'void TerminalWxFrame::OnXModemUpload(wxCommandEvent&)'
  652 | void TerminalWxFrame::OnXModemUpload(wxCommandEvent& event) //WXUNUSED(event))
      |      ^~~~~~~~~~~~~~~
src/host/wxui/z8530-terminal.cpp:652:6: note: no functions named 'void TerminalWxFrame::OnXModemUpload(wxCommandEvent&)'
In file included from src/host/wxui/z8530-terminal.cpp:81:
src/host/wxui/include/terminalwx_frame.h:11:7: note: 'class TerminalWxFrame' defined here
   11 | class TerminalWxFrame: public wxFrame

So... uh, wtf's going on there?
« Last Edit: February 20, 2021, 12:14:52 pm by rayarachelian »
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

stepleton

  • Sr. Member
  • ****
  • Karma: +109/-0
  • Offline Offline
  • Posts: 384
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #123 on: February 20, 2021, 01:41:47 pm »

Nope that's not been addressed. I'm pretty sure I put those guards in on purpose, but they should only be for ROMless. Can you clarify a bit? Where are you seeing this error message and for what? The ProFile, or a floppy?

Hey, sure... I've got a Windows box with a pretty conventional install of RC3a-2020.08.24. It's configured to look for the H boot ROM in a particular location, to pretend to be a 2/5, and also to have a ProFile .dc42 image hanging off of the parallel port. I've attached my lisaem.conf to this email.

Now, the ProFile .dc42 image itself is homebrew, but I know it's good (for booting at least) because LisaEm 1.2.6.2 over on my Linux box will boot it. I made the image by using the drive image generator script that comes with my hard drive bootloader. (My Lisas can boot the drive image too.) The drive image puts $AAAA in the right place inside the first sector's tag, so I don't know why the check in romless.c doesn't like it.

Precise steps:
1. Start up LisaEm
2. Select "Power Button" under "Key"
3. Lisa pops up a "ROMless Boot" dialogue asking for a boot device (even though I have a ROM file listed in the config), and I select the ProFile on the parallel port
4. A new alert box says "No bootable OS found" etc., and after that, an alert saying that the power-on failed, and that's the end of the line

I can't share the drive image I'm using just yet (hopefully soon!), but I can share the first two blocks of it, which is just the bootloader. I've attached a hexdump of the raw image data (not the .dc42), so 2*532 bytes, with the tags in the first 20 bytes of each 532-byte half.
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #124 on: February 20, 2021, 02:20:48 pm »

Hey, sure... I've got a Windows box with a pretty conventional install of RC3a-2020.08.24. It's configured to look for the H boot ROM in a particular location, to pretend to be a 2/5, and also to have a ProFile .dc42 image hanging off of the parallel port. I've attached my lisaem.conf to this email.

The most likely issue is that if it went to the romless code, it means the path to the ROM isn't being recognized somehow, so it should never go there - it's possible this is a logic bug, and I'll look through the code to see if that's the case, but it shouldn't ever complain about the ProFile from there if the ROM exists.

Now, if you have a recognized ROM, and the storage file for ProFile doesn't exist, it will prompt you to create it. But if it exists, and even if it's not bootable, it shouldn't care at all and it will turn on.

I might be wrong and I promise I will look, but from what's in L1 cache (i.e. wetware brain memory cells), most likely something's not right about the path to that ROM.

In terms of the ROM, if it's a split ROM dump it should rename it and stitch it back together into a single file.
I see the filename for your ROM is 341-0175-H.BIN - but I suspect this is just the "low" side of the ROM, if so, it's not going to recognize the high part and therefore won't do the right thing. I see bitsavers has ROMs with this convention. It also would need a matching 341-0176-H.BIN for the high part.

So the solution for now would be to rename those files to something like "boot-h.hi" and "boot-h.lo" as in here: https://github.com/rayarachelian/lisaem/blob/09afe9e998752d4458d8c9d1fdab2c562a4c628e/src/lisa/cpu_board/rom.c#L421 - the critical thing is the extension should end with ".lo" and ".hi" and then it will derive the name from that and merge them together into boot-h.bin.

(Bitsavers didn't exist when I wrote this code, so there's no handler for -0175/176-X and I don't think the CPU boards I had had the part number on them - or maybe they did but I didn't notice.) :)

I'll make a note of this and add some code for this case.

I can't share the drive image I'm using just yet (hopefully soon!), but I can share the first two blocks of it, which is just the bootloader. I've attached a hexdump of the raw image data (not the .dc42), so 2*532 bytes, with the tags in the first 20 bytes of each 532-byte half.

Yeah, no worries, I understand not wanting to release vaporware/unstable things, and also the need to secrecy. ;)
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

stepleton

  • Sr. Member
  • ****
  • Karma: +109/-0
  • Offline Offline
  • Posts: 384
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #125 on: February 20, 2021, 02:38:22 pm »

D'oh, you called it! I just had half of a ROM sitting there in that file. No wonder! It works fine with the ROM from my Linux installation. Sorry for wasting your time!

(using it now) This is brilliant! It's nice to have the emulator working on this other machine.

Yeah, no worries, I understand not wanting to release vaporware/unstable things, and also the need to secrecy. ;)

Much more boringly --- it's just because I need to get an IP release from my employer first. Shouldn't take too long, I hope!
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #126 on: February 20, 2021, 03:46:31 pm »

No worries. :)
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #127 on: February 26, 2021, 04:26:15 pm »

So I think there may have been some unicode fuckery that snuck into that class somehow, maybe an invisible non-space space char or something similar. I retyped the method name a few days ago by hand, exactly as it was before, but no copy paste, and into both the .h as well as the .cpp files and it compiled.

More importantly I found a couple more bugs around UniPlus and the vertical retrace. UniPlus very early on tries to run a 68010 only MOVEC opcode which needed special handling in LisaEm to work properly with the illegal opcode. Once that was fixed, I saw the kernel locking up in a very tight loop turning on the VTIR, then checking to see if the vertical retrace happened.

Originally, because it said so in the HWG, when the VTIR is enabled, I reset the video state machine timing, so it would always be in the same state when the VTIR was set, however, this was causing uniplus to hang. So I added a guard variable around it - so if you set VTIR repeatedly within something like 100 CPU cycles again, it will ignore it and let the state machine run its course.

That allows UniPlus's kernel to get a bit further, but now it fails with a profile state error. So looks like it doesn't like my profile emulation. Oh well.

Anyway for now I'll finish off the terminal stuff and testing and then release RC4. I'll come back to the profile emulation in 1.2.8 and hopefully that will get UniPlus going. Not sure what's up with Xenix after the kernel starts up. It sort of works and shows the console and cursor, but doesn't get any further than that. If you type stuff in, it will echo it as it should, but that's it. So it's waiting for something, not sure what. Not VTIR I expect.

Now with UniPlus since the kernel source is available, it will be somewhat easier to debug, and also a lot easier to intercept the pro.c code in the kernel with high level emulation code.

So that's where we are for now.


« Last Edit: February 26, 2021, 04:42:53 pm by rayarachelian »
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

jamesdenton

  • Administrator
  • Sr. Member
  • *****
  • Karma: +60/-0
  • Offline Offline
  • Posts: 142
  • ArcaneByte
    • ArcaneByte
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #128 on: February 26, 2021, 04:40:27 pm »

Awesome progress, and I appreciate your attentiveness to some of the issues I brought up recently. Thanks!
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #129 on: March 05, 2021, 02:16:25 pm »

For the impatient, I've copied the current code into an unstable branch here: https://github.com/rayarachelian/lisaem/tree/unstable

This isn't a release, it's a nightmare with big nasty sharp teeth and big claws.

Do the usual git clone and then do
Code: [Select]
git pull --all; git checkout unstable and then build it yourself.

It's more of a checkpoint before I start working on getting the UniPlus HLE stuff started on. After that's done, I'll come back to the TerminalWx stuff (which you shouldn't expect to work though it will compile and you can use as a console to talk to LisaTerminal.)
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

pcamen

  • Newbie
  • *
  • Karma: +0/-0
  • Offline Offline
  • Posts: 3
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #130 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? 
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #131 on: March 07, 2021, 11:13:55 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? 

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.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #132 on: March 12, 2021, 07:00:13 pm »

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: [Select]
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:

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: [Select]
00020000  60FE                       2  START: bra.s START

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: [Select]
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

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).
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

anonymous

  • Newbie
  • *
  • Karma: +0/-0
  • Offline Offline
  • Posts: 2
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #133 on: March 16, 2021, 10:10:43 am »

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?

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

Logged

anonymous

  • Newbie
  • *
  • Karma: +0/-0
  • Offline Offline
  • Posts: 2
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #134 on: March 16, 2021, 10:14:32 am »

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?

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
Logged
Pages: 1 ... 7 8 [9] 10 11 12   Go Up