LisaList2

Advanced search  

News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

Pages: [1] 2 3 ... 12   Go Down

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

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
« Last Edit: April 03, 2022, 10:04:54 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

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-Alpha support bug reports
« Reply #1 on: October 15, 2019, 03:52:08 pm »

Found what was causing crashes on x86_64 macos X:
  • wxSound needs to be local rather than as pointer that's part of the LisaEmFrame class which is new'ed and deleted - it crashed on the delete
  • seems every so often wxWidgets support for strings changes yet again, in previous version I could do wxString x="Meow" and then use x.c_str() to get an ANSI C string that I could pass to things like strncpy. Later it was fn_str(), now it's (char)(x.char_str()) and I have to typecast it. Meh, and this doesn't seem to be documented cleanly - a reading of the docs says all these methods should work, but they don't work everywhere and not properly.
  • long's on x86_64 linux are 64 bit, it seems they are 32 bit on x86_64 macos X - ironically this affects debug enabled code due to the use of ALERT_LOG() macros, and even more so, I spent a few days recasting all the ints to longs to get rid of size warnings, will have to redo it again  ;D
There might be more. Haven't yet done a git push as I'm fixing these, but will do so once I fix every instance of these.

Edit: fixed up code is up on github, and here's a DMG: https://lisaem.sunder.net/downloads/LisaEm-1.2.7-20191015-ALPHA-x86_64-only-macosX10.11.dmg
« Last Edit: October 15, 2019, 09:43:22 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

Lewton

  • Newbie
  • *
  • Karma: +1/-0
  • Offline Offline
  • Posts: 1
Re: LisaEm 1.2.7-Alpha support bug reports
« Reply #2 on: October 21, 2019, 08:04:29 am »

How often are you pushing code up on github, Rayarachelian?
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-Alpha support bug reports
« Reply #3 on: October 21, 2019, 10:36:14 am »

Quote
How often are you pushing code up on github, Rayarachelian?
Since I'm the only one working on LisaEm, right now pushes are around once a week or so - mostly on weekends, and only when something is fixed. I generally don't want to push in-flight work-in-progress incomplete/non-functional code that doesn't compile or work.

Currently I'm working on new features such as the hqx upscaler, using the hq3x upscaler with a double-X lens to fix the rectangular pixel issue, so won't be pushing that until it works or at least mostly works. And if that turns out to not work, or look terrible, I'll remove it as a feature.

I suppose once 1.2.7 reaches prod-release, then I'll stop making changes and start work on 1.2.8 features, and once enough of 1.2.8 works, I'll push that.
After 1.2.8 I suppose there'll be long breaks again while I consider what I want to do for 2.0, etc.

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-Alpha support bug reports
« Reply #4 on: November 11, 2019, 08:13:03 pm »

New Alpha, fixed some bugs, added the HQX scaler as a new display method, Drag and Drop of disk images for floppies and text to clipboard.
https://github.com/rayarachelian/lisaem-1.2.x and https://lisaem.sunder.net/downloads/LisaEm-1.2.7-20191111-ALPHA-x86_64-only-macosX10.11.dmg

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

D.Finni

  • Sr. Member
  • ****
  • Karma: +37/-0
  • Offline Offline
  • Posts: 135
Re: LisaEm 1.2.7-Alpha support bug reports
« Reply #5 on: November 29, 2019, 03:57:50 pm »

I would like to maintain Mac OS X 10.5.8 support for LisaEm, but wxWidgets seems to be the weak link and is causing most of the trouble.

My solution is to keep the old wxWidgets 2.8.x interface from old LisaEm, and combine with emulator bug-fixes and other improvements from your latest GitHub source. The result is here: LisaEm 1.2.7-Alpha for Mac PowerPC 10.4
« Last Edit: November 30, 2019, 08:48:05 pm by D.Finni »
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-Alpha support bug reports
« Reply #6 on: December 01, 2019, 07:34:05 pm »

Well done!
There is some infection point between the wx3.11 and wx3.12 where it stops working on G4/G5. I have a build on my G5 iMac that works. I'll post it up when I get a chance. Newer versions than that commit hash won't build, but it's compatible enough.  I suppose wx3.0.4 should build fine too.
I'll probably do a dual release for the release version of 1.2.7 where it's a fat binary for classic macs that supports 10.4 PPC-32, 10.5 PPC-64, 10.5 i386 and then a more modern 10.11+ for just x86_32|64.

I've got a 10.11 El Capitan Vbox VM that mostly works well enough to build on.

My old 2009 core2 intel 15" mbp w/10.9.5 doesn't seem to be able to build proper binaries and the lldb debugger is terrible there as backtrace and list don't work too well to track down bugs, not sure why. Binaries built on that box all crash.

But binaries built on 10.11VM do work on 10.12, and 10.14 and 10.15 VMs, and on 10.11, clang + lldb work pretty well and I can debug most things, it's just that the display isn't GPU accelerated so I can't tell how well it would do on real hardware, though I do have a 10.14 on a fairly recent Mac that works well.
I wish I could get a working build for as low as 10.7 as supposedly wxWidgets 3.x does go that low. But... it is what it is.
I'll likely test it on FreeBSD, and OpenIndiana (and maybe OpenBSD) as well before the final 1.2.7 release (or maybe I'll leave that for 1.2.8 ), but I don't expect too many issues with those OSs. I tried to get the latest Oracle Solaris 11.4 in a VM, but it's quite crashy, so not going to bother with that. Might be nice to get it working on AIX 4 or 5 as well, but that would be more of a curiosity than anything anyone would likely care about (assuming I can even get wx to compile on those beasts)

Anyway, I've just rewritten the build system using the scripts from 1.3.0 which use a file system layout where the directories are organized like the Lisa's hardware - that was the original intent from the very first versions in 1998, but once I got to ~2007 I gave that up. So bringing it back now. So what's gonna happen next is that the 1.2.x repo on github will go into deprecated mode and I'll have a new repo called just "lisaem" without the lame ass version number. I was saving that for when 1.3.0 was working, but, I can do that in a few days once this stuff is stable.

But more urgently, I gotta write the Cygwin scripts for building on windows. I'm using this VM for that: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines so I have to finish that bit before the end of the month or it will expire.  :P They're usually pretty good about releasing new versions a couple of weeks after they expire, but who knows when they'll end that program. Unfortunately on the pre-built windows versions, the wx-config command doesn't exist, so I'll have to deduce the wx-config --libs and --cflags and --cxxflags outputs from Linux and macos and deal with a bunch of cygpath translations to make shit work right. Originally I relied on wxdsgn off sourceforge, but that's been abandoned ~2011 or so. Too bad, as it was a nice IDE and had pre-built wxWidgets for Windows.

I did manage to script a couple of batch files that do an unattended Cygwin install with the mingw32/64 compilers, so there's that at least.

« Last Edit: December 01, 2019, 07:37:48 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

D.Finni

  • Sr. Member
  • ****
  • Karma: +37/-0
  • Offline Offline
  • Posts: 135
Re: LisaEm 1.2.7-Alpha support bug reports
« Reply #7 on: December 02, 2019, 10:26:42 am »

Well done!
There is some infection point between the wx3.11 and wx3.12 where it stops working on G4/G5. I have a build on my G5 iMac that works. I'll post it up when I get a chance. Newer versions than that commit hash won't build, but it's compatible enough.  I suppose wx3.0.4 should build fine too.
I can tell you more about it from my experience this weekend:
2.8.12 is fine for 10.4 and 10.5
2.9.5 killed 10.4 support, but supports 10.5
3.12 killed support for both 10.4 and 10.5.

I spent probably 3 hours trying to get 2.9.5 to compile on 10.4, ripping out and modifying the code rather ham-fistedly when compile errors came up. These were generally for libraries not in 10.4, like CoreGraphics and CoreText. Managed to get a successful build, but then linking LisaEm with it failed. And probably I've broken one or the other from my attempts.

I noted that removal of support for older OS X operating systems seemed arbitrary and probably could have been maintained in wxWidgets.

Quote
I'll probably do a dual release for the release version of 1.2.7 where it's a fat binary for classic macs that supports 10.4 PPC-32, 10.5 PPC-64, 10.5 i386 and then a more modern 10.11+ for just x86_32|64.
My proposed solution is to maintain two wxui directories. One links to 2.8.12 and is for PPC/Intel 10.4 and 10.5 builds. The other wxui directory links to 3.x and is for everyone else.

So long as nothing you do in cpu68k/, generator/, or lisa/ breaks older wxWidgets support, this seems like a reasonable compromise to me.

I volunteer to maintain 10.4 and 10.5 PPC/Intel builds.


My old 2009 core2 intel 15" mbp w/10.9.5 doesn't seem to be able to build proper binaries and the lldb debugger is terrible there as backtrace and list don't work too well to track down bugs, not sure why. Binaries built on that box all crash.

And early gotcha that I ran into is that OS X back till at least 10.4 comes with a wxWidgets installation, but it's usually out of date. You need to check /usr/bin/wx-config because that's what LisaEm will link with if you don't update it. I used a symlink to point to my newer build of 2.8.12.

But maybe you already know about this....



I wish I could get a working build for as low as 10.7 as supposedly wxWidgets 3.x does go that low. But... it is what it is.
I have a Mac running 10.8 that I could build on. I don't have any 10.7 machines, however. I also have a Mac Pro running 10.11 and another Mac running 10.12 Sierra.

I have a fairly good spread of OS X versions across PPC and Intel.  8)
« Last Edit: December 02, 2019, 10:33:31 am by D.Finni »
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-Alpha support bug reports
« Reply #8 on: December 02, 2019, 07:51:39 pm »

I can tell you more about it from my experience this weekend:
2.8.12 is fine for 10.4 and 10.5
2.9.5 killed 10.4 support, but supports 10.5
3.12 killed support for both 10.4 and 10.5.

I spent probably 3 hours trying to get 2.9.5 to compile on 10.4, ripping out and modifying the code rather ham-fistedly when compile errors came up. These were generally for libraries not in 10.4, like CoreGraphics and CoreText. Managed to get a successful build, but then linking LisaEm with it failed. And probably I've broken one or the other from my attempts.

I noted that removal of support for older OS X operating systems seemed arbitrary and probably could have been maintained in wxWidgets.
Quote

Agreed. I really hate this idea that we have to throw out backwards compatibility. I haven't spent too much time in 10.4 on the G5 so maybe I should revisit 10.4 and seeing if I can get things going there.

My proposed solution is to maintain two wxui directories. One links to 2.8.12 and is for PPC/Intel 10.4 and 10.5 builds. The other wxui directory links to 3.x and is for everyone else.

So long as nothing you do in cpu68k/, generator/, or lisa/ breaks older wxWidgets support, this seems like a reasonable compromise to me.

I volunteer to maintain 10.4 and 10.5 PPC/Intel builds.

Um, ok, so... "Tag you're it" :-D I mean, "I dub thee maintainer of PPC" backports.


And early gotcha that I ran into is that OS X back till at least 10.4 comes with a wxWidgets installation, but it's usually out of date. You need to check /usr/bin/wx-config because that's what LisaEm will link with if you don't update it. I used a symlink to point to my newer build of 2.8.12.

But maybe you already know about this....

Oh yes, I always set PATH=/usr/local/wx-3.x.x/bin:$PATH to avoid issues. But even 3.1.2 is a pain. On linux they've decided to do some sort of automated rescaling so a 4K display reports back as 1080p and it undoes all the scaling stuff I've added. 3.1.1 works great. I'm probably not calling the proper new interface to get the actual size of the display or something, but it moved far away from the way 3.0 and 2.8 did things. So I'm mostly sticking to wx3.1.1

I haven't bothered with symlinks there because I keep a bunch of different ones on hand there. Currently there's 5 of them on my linux box.


I wish I could get a working build for as low as 10.7 as supposedly wxWidgets 3.x does go that low. But... it is what it is.
I have a Mac running 10.8 that I could build on. I don't have any 10.7 machines, however. I also have a Mac Pro running 10.11 and another Mac running 10.12 Sierra.
I have a fairly good spread of OS X versions across PPC and Intel.  8)

Sort of the same here, though as a new macos comes out every year I've given up trying to keep a machine for each, it's a losing battle, so I now just have a VM for every few versions.
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-Beta support bug reports
« Reply #9 on: March 15, 2020, 11:06:56 am »

I renamed this thread to Beta to match the current release state.

Just cut a beta release 2020.03.14 and pushed source to github last night, and uploaded to the downloads page:Most of the non-display bugs are fixed, but lots of display bugs are still there. Once those are fixed, there's one or two more features to add, and then will move to release. I can't say when that will be as the display bugs are many and fugly.

On macos x the display refreshing is really badly broken, so I need to do a lot more work there. The good news is that I was able to create a Mountain Lion ( 10.8 ) VirtualBox VM with XCode 4.6.3 - I had to use macports as brew.sh (aka homebrew) does not support it.
In theory I used the 10.7 SDK, so it might work on macos x 10.7, but as I don't have a Lion machine to test it on, I can't yet tell. This uses wxWidgets 3.0.4 as 3.1.x will not build there.
I think for the final version I'm going to do some shell scripting tricks on MacOS X to glue several binaries together - without using lipo. Instead of launching a Mach-O binary for LisaEm, I'll run a shell script which will detect the OS and what binaries are available and run the latest one that the current OS will support. So if you're on PowerPC it will launch the G4/G5 version. If you're on an older intel it will try to run one that works. If you're on catalina it will launch one with wxWidgets 3.12 or 3.13, etc.
That is assuming the next macos x doesn't remove the shell altogether.  :P
I probably need to write some automation, scripts as well, to cut releases like these, (creating the DMG and populating it, pushing source to gitlab and binaries to the download page) as doing them by hand is getting annoying.
« Last Edit: March 15, 2020, 11:08:40 am 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

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-Beta support bug reports
« Reply #10 on: April 11, 2020, 03:40:13 pm »

New Beta release is pending. Watch this thread, likely this weekend, or Monday the latest with a focus on macos x This will include the new macos version selector script as described above, and a rebuilt script for creating wxWidgets on macos. I guess you can go on a virtual easter egg hunt, where the eggs are bugs and report them here.  ::)
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-Beta support bug reports
« Reply #11 on: April 12, 2020, 11:51:07 pm »

Phrew, that was a marathon of Yak Shaving. This is named 2020.03.31 because that's when the final source code changes were made, it's released today because I spent about two weeks shaving a very big Yak - namely (mostly) automating the dmg creation process and setting up a bunch of macos Virtualbox VMs to be able to create obese binaries for macos x.
This release contains binaries for macos x 10.8, 10.10, 10.11, 10.12 and 10.15 x86_64. On startup it will run whichever matches the OS most closely. This doesn't contain i386 binaries, nor PPC binaries, but the final release likely will. It's likely this will run on 10.7, as it was compiled on 10.8 with min macos SDK 10.7, but I don't have a way to test it there as I don't have a 10.7 VM.
While I do have a 10.9 VM, compiling under it does not produce viable binaries - LisaEm compiles successfully there but immediately crashes on startup, and I'm not sure why. I've peeled off some layers of that onion, but got nowhere, so I'll just rely on 10.8 binaries working on 10.9.x.

It's not necessary to make a bespoke binary for every os, but it's likely a good idea to build one for every major change so that the best combination of binary + wxWidgets library is provided. For example, the 10.8 in this release uses wx3.0.4, but the 10.15 one uses wx3.1.3, so it should pick up the latest fixes. (wx3.1.3 does not compile on macos 10.8 )

To mostly fix the worst display artifacts I had to switch to a double buffered wxDC, which causes display refreshing to be very slow. I'll hack on this some more until I find a better solution, so hopefully this is temporary, but it gets rid of the nasty flashing on macos x.
Next, I'll be continuing on the display artifacts issue, and then will add a couple more features, and that will lead to the final 1.2.7 release if all goes well.
« Last Edit: April 12, 2020, 11:59:50 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

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-RC1 support bug reports
« Reply #12 on: May 31, 2020, 09:21:43 pm »

Edit: 2020.06.05 updated with new links, source + dmg.
RC1 is ready for download here: https://lisaem.sunder.net/downloads/ - here are the relevant direct links:

* https://lisaem.sunder.net/downloads/lisaem-1.2.7-2020.05.27.tar.xz* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC1-2020.05.27-macos-10.10-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC1-2020.05.27-macos-10.11-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC1-2020.05.27-macos-10.12-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC1-2020.05.27-macos-10.15-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC1-2020.05.27-macos-10.5-i386.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC1-2020.05.27-macos-10.5-ppc.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC1-2020.05.27-macos-10.7-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC1-2020.05.27-macos-10.8-x86_64.pkg
* https://lisaem.sunder.net/downloads/LisaEm_1.2.7-RC1_2020.05.27-macosx.dmg

The packages (pkg) will install both the LisaEm.app to /Applications as well as the command line tools to /usr/local/bin/ but these are skinny versions of LisaEm - that is they only hold the executable built from a specific macos x machine. They should run on machines with macos x of the same version or newer.

The DMG has the new "obese" "swole" binaries (on 2nd thought swole is a better word than obese), so if you install from there, you'll be able to move it around between systems, but the binary will be much larger 38MB rather than the 7~12MB skinny versions.

The above are small versions with only one macosx binary each. If you try to run one that's not suitable for your system, it will fail to start. ie. trying to run the 10.5-ppc versions on 10.15 which only wants x86-64.

The command line tools inside the Command Line Tools folder are packages that only install the CLI tools, but you'll need to specifically install the right one for your os. The packages will not block you from installing the wrong versions as there's no test script in them (yet).
These were built using a master script that powers on a vbox vm, waits for it to come up, ssh's into it and builds for that os, then shuts it down and repeats until all are done. The final one also builds the DMG. Since the 10.5-ppc was built on a 10.5 intel VM, and I haven't yet tested it, it might not work.I was hoping that the 10.5 version would work on 10.4, but sadly it does not. I've not been able to get a wxWidgets 3.x to compile properly on 10.4.  :-\

Similarly for some reason I couldn't compile i386 versions on 10.7 and above, only x86_64 builds properly. There's some linking issue vs wxWidgets 3.0.2 and 3.0.4.But this is ok as the last of the actual 32 bit mac os x was 10.6, and while you could run 32 bit binaries all the way to 10.14, it doesn't offer much of an advantage to do so over a 64 bit binary.
Enjoy.  :D
« Last Edit: June 05, 2020, 10:10:49 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: +59/-0
  • Offline Offline
  • Posts: 142
  • ArcaneByte
    • ArcaneByte
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #13 on: June 01, 2020, 10:43:09 am »

Hi Ray,

Trying to boot off an existing ProFile image returns the following error:

"I'm sorry, the emulation has aborted due to a fatal error

cpu68k_makeipclist: But! ipc is null!
Stopped at cpu68k.c:cpu68k_makeiplist:1071 with code :501"

Also, browsing to select a ProFile seems to want to only create a new profile image, potentially overwriting an existing file.
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-RC1 support bug reports
« Reply #14 on: June 01, 2020, 11:41:31 am »

Hi Ray,

Trying to boot off an existing ProFile image returns the following error:

"I'm sorry, the emulation has aborted due to a fatal error

cpu68k_makeipclist: But! ipc is null!
Stopped at cpu68k.c:cpu68k_makeiplist:1071 with code :501"

Ouch, is this on 10.15? Does it also happen with the same image on older betas or 1.2.6?

Also, browsing to select a ProFile seems to want to only create a new profile image, potentially overwriting an existing file.

I think that's normal, although misleading as that field allows you to just set the location, it won't actually overwrite it. If there's no profile at that path, it will prompt you on power on to select what size to create.
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
Pages: [1] 2 3 ... 12   Go Up