LisaList2
General Category => LisaList2 => Topic started by: D.Finni on November 30, 2019, 08:46:13 pm
-
This is a hybrid release called 1.2.7-ALPHA_2019.11.11 osx-ppc for Power Macintosh computers running Mac OS X 10.4 and 10.5. It combines the latest version of LisaEm source on Git, with the old wxWidgets 2.8.x wxui interface from the 2007 release of LisaEm.
This means it has the technical improvements and bug-fixes to the emulator proper, but not any of the UI changes.
I built this on a Power Macintosh G3/450 running Mac OS X 10.4.11 and XCode 2.5 (gcc version 4.0.1). It is compiled with wxMac-2.8.12.
This version of LisaEm will also run on Intel 10.5 under Rosetta.
Download Here (http://dserver.macgui.com/lisaem-1.2.7-ALPHA_2019.11.11-osx-ppc.dmg)
and please let me know if it works for you on OS X 10.4 or 10.5.
-
This is a hybrid release called 1.2.7-ALPHA_2019.11.11 osx-ppc for Power Macintosh computers running Mac OS X 10.4 and 10.5. It combines the latest version of LisaEm source on Git, with the old wxWidgets 2.8.x wxui interface from the 2007 release of LisaEm.
Nice! I did manage to get one of the wx3.11 git commits to compile on 10.4 and 10.5 PPC in both 32 and 64 bit. There didn't seem to be too much interest in PPC versions as per the poll here: https://lisalist2.com/index.php/topic,50.0.html, but cool! But yeah, I do have a G5 iMac and a couple of Mac Minis (G4 + intel core 1 running 10.5 or 10.4.)
-
Although I have Macs running newer versions of OS X, my main Mac runs OS X 10.5.8, so I have a vested interest in maintaining LisaEm support. ;)
Now I'm adding features that I've wanted for a long time. I've added a few keyboard shortcuts, Command-I for insert disk, Command-R for Run (though I saw you eliminated this menu item), and Command-S for Power On (S for Start in this case).
I also got rid of the "lame sound" where it wrote a temp file to disk, then played from that.
Next I'd like to modify LisaEm so that the Lisa is automatically powered on when I launch the application. I added a call to handle_powerbutton() in what I thought was a likely place, but this resulted in a hang and crash.
Could you show me what lines to add and where to have the Lisa start powered up?
-
Although I have Macs running newer versions of OS X, my main Mac runs OS X 10.5.8, so I have a vested interest in maintaining LisaEm support. ;)
Yup, similar situation here, my "mac" (short for machine) is an Acer Predator 17" running Ubuntu 18.04, but my goals for LisaEm are to have it be widely compatible. In that sense, I'd hate to not provide 10.4 support, but that may wind up being the case. 10.4 is interesting since it still supports OS9. At the same time, after a while wxWidgets will keep diverging and at some point (now-ish) I'll use features from wx3.x that will cause macos 10.4 support to end.
I guess I should also think about doing backups of these machines in some way that I can restore them without install media. Do you know if 10.5 and 10.4 have issues with Apple's cert expiring? I guess I can find a linux PPC boot CD and then dd a disk image out for now...
Now I'm adding features that I've wanted for a long time. I've added a few keyboard shortcuts, Command-I for insert disk, Command-R for Run (though I saw you eliminated this menu item), and Command-S for Power On (S for Start in this case).
Right, I eliminated "run" in favor of the power button and where Run was is now Pause as those menu items for run/pause were a bit annoying. It's a bit odd that the power button is on the keyboard menu, though technically that's correct since it shows up as a keyboard press to the COP421.
I also got rid of the "lame sound" where it wrote a temp file to disk, then played from that.
Great! wx3.x does seem to support playback from RAM instead of having to create a wave file in memory, write it to /tmp and then tell it to open it. :)
Actually I was very strongly considering moving to openal, though seeing that Catalina and Mojave dropped support for it made me hesitant, though actually I may add it in anyway and just rely on brew to install openal - or if that fails to just include it in the source code. After things settle down, I'll likely create a homebrew cask for it as well.
Next I'd like to modify LisaEm so that the Lisa is automatically powered on when I launch the application. I added a call to handle_powerbutton() in what I thought was a likely place, but this resulted in a hang and crash.
Could you show me what lines to add and where to have the Lisa start powered up?
I think the order of OnInit instantiation of LisaEmFrame vs LisaWin vs App is the issue there. 1.2.7 does have a command line option to power on start. Take a look at that code, though it does do some funny things like, after parsing the command line options, it sets some vars and once it's fully initialized it looks at those vars and does things like insert a floppy (and null out that var), turn on the Lisa (and null out that flag), go full screen, etc. So it's a way of getting around the chicken and egg by delaying startup behavior until things are instantiated.
The code isn't very clean C++ which is why you're running into issues, some of that is because I don't really that much about abstracting things the right way, some of it is because eventually I want to expose a C interface to the outside world for scripting, which is why you see both C and C++ code that do the same thing. That will get better in future releases, and will allow an external, say python or lua or some other thing to remotely control LisaEm and do interesting things. But it's still a mess currently.
I really had a great design with 1.3.0 but I couldn't get the emulator guts working properly. It's too bad. That code splits up the emulation core from the UI very nicely and there's not so many hooks between them... And it could have potentially allowed me to move away from wx to say qt or something entirely different.
I don't want to discourage you. Ideally, I'd like to have the same source code everywhere and not have different behavior/menus. But I do appreciate and welcome the help.
-
I don't want to discourage you. Ideally, I'd like to have the same source code everywhere and not have different behavior/menus. But I do appreciate and welcome the help.
Yes, I would like to standardize on menus too, even if we do keep the separate wxui versions for maintaining compatibility with older systems.
-
Yes, I would like to standardize on menus too, even if we do keep the separate wxui versions for maintaining compatibility with older systems.
Hey @D.Finni, so would it help your efforts (both on the G4/G5 front and future UI) if I split up lisaem_wx.cpp into multiple files?
I was thinking of something like this for a future release since that file's pretty huge and includes multiple classes rather than one per file?
I'll likely keep the window and frame classes together since I don't really have sub-windows in LisaEm, so they're kind of joined together.
- wx_windowframe (app, lisaem_win, lisaem_frame constructors/destructors, events, etc.)
- wx_menu
- wx_render (for aa, aag, raw, 2x3y, hq3x, etc.)
- wx_skins
- wx_sound
- wx_print
- wx_emuloop (timer, pause, emulate a frame, etc.)
- wx_keyboard
- wx_mouse
- wx_hidpi (maybe or maybe not)
That way when I push new code you could do `git diff` and see what changed and make mirror changes as needed.
Ultimately for 2.0 I'll do the split process thing where the UI is one process and the core is another and they just talk over ipc/shmem, but until then for 1.2.7 or 1.2.8 this might be a useful thing? (although for PPC, I don't know if it's worth splitting up the UI from the core as most of those systems are single core, so splitting them up would slow things down rather than help.)
The idea here is that we can multiple cores, each allocating a chunk of shared memory (2MB-4MB per Lisa with some control block and an individual shmem id, then they can communicate to the UI process which will do the video rendering and other stuff like playback of sounds or scripting, or whatever. (And then other UI's outside of wxWidgets could be implemented if so desired, i.e. Qt or GTK, or native macos or whatever.)
Eventually if I can get MacWorks going again, we could even do a bunch of really fun things like run a bunch of LisaEm's on the same box and have them talk over an internal localtalk network or something like that, maybe even run a local/ether talk bridge locally to the outside world like CAP/atalk, or to Shoebill, BasilliskII or PearPC or whatever.)
-
Yes, I would like to standardize on menus too, even if we do keep the separate wxui versions for maintaining compatibility with older systems.
Hey @D.Finni, so would it help your efforts (both on the G4/G5 front and future UI) if I split up lisaem_wx.cpp into multiple files?
I was thinking of something like this for a future release since that file's pretty huge and includes multiple classes rather than one per file?
[...]
That way when I push new code you could do `git diff` and see what changed and make mirror changes as needed.
Yeah, I think that'll work nicely.