audetto
commented
4 years ago Big disclaimer: I am the author of https://github.com/audetto/AppleWin
When I started this project a few years ago I looked first at linapple (which one? I don't remember) and started comparing the code to AW to see which features where missing / modified. This quickly became a pointless exercise because it would have become obsolete in no time.
I then started on the above stated objective to compile the linux version from exactly the same source code as AW in order to get free maintenance and being able to leverage the fantastic work of the AW community. I have to say that with a few exceptions the goal has been achieved and most of the time the merge is a no-op.
- https://github.com/audetto/AppleWin/tree/master/source/linux/duplicates I had to duplicate these files as they were too Win32 centric
- there are 1 or 2
#ifdefin the normal source code to remove Win32 code I could not be asked todummy-out - serial, ethernet, debugger are completely missing
Why using AW at all? Probably because when I started, I did not know any other good candidate. What about MAME or https://github.com/sosaria7/appleinpc, the latter is win only but the structure of the code looks more portable / modern than AW.
The SDL2 port of my repo is almost as good as the Qt one (except configuration which I will make fully available via cmd line switches): audio, keyboard, mouse and joystick are "easy" as I have already learnt how to do them in Qt.
One thing I was considering was to create yet another port to https://www.libretro.com/ which would leverage on the rest of the retroarch framework (writing the 4th frontend will be definitely easier than the 1st!)
What would I do if I had plenty of power and resources? I would definitely restructure AW to be more modular (objects vs global variables), less Win32 centric (a lot of the Win32 functions used now have STL equivalent) and with a stronger separation between guest code (A2) and host code (Win32) so that the Win32 would become just another frontend.
Jumping on another emulator? Only if the community behind it is very solid (and beating AW is really hard here).
leonbottou
webspacecreations
In the course of doing a kind of survey of open source Apple II emulators / utilities, I stumbled across this thread started back in 2018 (https://github.com/RasppleII/a2cloud/issues/37), which in turn led me to this repository. Based on how many different branches and codebases are available, it's clear that a lot of effort is being spent by notable contributors, but it kind of feels like the proverbial wheel continues to be reinvented. Rather than posting in a thread that hasn't been updated in over 2 years, I'd like to present some musings based on where the various forks / codebases are today.
I'm primarily looking for solutions that will work under Pi/Raspbian, but in the course of surveying the landscape, I've looked at AppleWin on Windows, since development on that repository is proceeding rapidly. AppleWin is VERY good, albeit limited to Windows. The linapple/applelin forks all derive from some early version of AppleWin and, in turn, this linappleii repository also derives from an old version of AppleWin. This would make a lot of sense if AppleWin was not being actively maintained, but it looks like it's getting more frequent updates than many / all of the Linux-compatible forks. So, what's the objective? I see a few:
AppleWin that runs on non-Windows operating systems This was already discussed starting back in 2018 with ongoing contributions to the discussion (https://github.com/AppleWin/AppleWin/issues/538). In fact, there's a repository that represents to do this very thing (https://github.com/audetto/AppleWin).
The stated objective of this (audetto/AppleWin) repository is to stay feature concurrent with AppleWin (basically adding a non-Windows compatibility layer). That may change, but for now, it appears to be an achievable objective. I can really only fault two things about this approach: 1.) it's not as good as if AppleWin committed to inbuilt support for non-Windows platforms and 2.) it's using Qt, which introduces a LOT of dependencies and bloat. Even there, however, the project dev has an SDL branch (https://github.com/audetto/AppleWin/tree/sdl).
Backporting new features to Linapple(ii) The problem here is that linapple (and all its myriad forks) have proceeded in fits and starts and many haven't been touched in a LONG time. Even looking at the current linappleii, it appears it's still on SDL1.2 and not SDL2. I doesn't bother me personally, but it speaks to a considerable gap in the ability to add new features to close the gap with AppleWin.
Becoming a better Linapple for Retropie This isn't a bad objective, since Retropie arguably gives a larger segment of the population exposure to the Apple II. The problem is that Apple II on Retropie is pretty abysmal. Specifically, the objectives of a Retropie user are completely different than a "retro computer user." More specifically, Retropie users don't typically have an attached keyboard and the Apple II was never designed as a turnkey gaming console. Even assuming you manage to streamline disk image loading enough to be usable with a gamepad, gameplay is the bigger problem. Keyboard was often assumed to be the primary input and key mapping for games on the Apple II is all over the board. Without some kind of centralized repository of per-game controller mappings, the Apple II on RetroPie is doomed to be a lousy experience for most users. However, I AM very pleased to see the linappleii is supporting command line switches as this has benefits beyond Retroie.
Making a universal GSPlus I have ZERO affiliation with GSPlus and, until the last few days, assumed that any of the numerous linapple derivatives were best suited for pre-IIGS software and IIGS software should be run on KEGS/GSPort/GSPlus. That is before I stumbled across KEGS-Universal (https://github.com/leonbottou/kegs-universal) and its corresponding port to an older version of GSPlus (https://github.com/digarok/gsplus/pull/31). The "universal" designation means that the emulator has been modified to support ANY Apple II ROM II, II+, IIe, IIc, IIc+, and IIGS.
For the Apple II purists, I'd point out that this approach seems to be the only "modern" emulator that supports the custom drive firmware of the IIc & IIc+. Another advantage "out of the gate" is that it already uses SDL2 and modernizes components of GSPort, which itself modernized components of KEGS. The repository owner dismissed these "universal" changes back in mid-2019 on account of significant code divergence since the initial commit a year prior, but it also represents an opportunity.
The advantage of revisiting the idea of a "Super II" is its value proposition: 1.) You aren't simply trying to reinvent on Mac / Linux what AppleWin is already doing (you aren't playing a constant catch-up game). 2.) You are building something new (IIc,IIc+ compatibility and complete platform coverage in a single emulator), not simply improving something that already exists 3.) With GSPlus, the SDL2/GUI interface is already solved. It means that limited resources can be focused on the things that matter... like accurate emulation and peripheral support 4.) By centralizing on a single platform for all things Apple II, there's much greater chance of knowledge transfer (i.e. a IIGS expert might have a meaningful insight for someone looking at a IIe problem, or vice-versa).
The main disadvantage (that the current state of GSplus is 1.5 years beyond the codebase the Universal changes were committed to) is relatively minor in comparison to the state of Linapple(ii). I'm guessing that porting the Universal changes to the current GSPlus codebase is far from trivial (otherwise the owner would have allowed / done it), but I'm guessing that it would be a lot easier to either backport new features from GSPlus to "GSPlus-Universal" or fix whatever new issues the "universal" patch might create with the latest codebase than it's going to be to switch Linapple to SDL2 and address whatever other non-trivial issues (e.g. GUI) still have to be solved in Linapple(ii)... or just part ways completely and focus on other improvements the GSPlus contributors haven't considered.
I believe that the GSPlus-Universal / Super II approach represents a unique opportunity to draw a larger pool of contributors and centralize work that is too valuable to be spread across multiple repos and forks.
That's my humble feedback looking at the current state of code affairs. In terms of actionable feedback, upon compiling the latest linappleii code on Pi4/Raspbian, emulator drops into monitor upon boot (even when specifying a disk at command line) and speaker generates a steady humming (may be picking up another linapple config file; not yet sure). Key mappings with the Alt/Ctrl and F keys wreaks havoc on Linux/Raspbian/ PC keyboard. Also, I'm happy to try to help code where possible/useful.