linappleii / linapple Goto Github PK

This is kind of a structural change, and it might reflect quite a divergence from AppleWin, but I think we ought to do it. First, a survey of how SDL is used in LinApple by source file:

Okay, so video doesn't handle window creation or management at all and is purely for displaying the Apple II screen. There's some tight delay-until-event-we-want (and ignore all others like CLOSE for example) loops in around DiskChoose/DiskFTP. Frame seems to do a lot of everything, and you'd expect that but you'd also expect it to be delegating tasks to other subsystems.

In game development, what's typically done for single-threaded games is a loop: draw, input, think, flip. The draw is done first because if the 3D hardware hasn't finished in other threads or on the card, your attempt to flip buffers will block until it's done. A lot of games are still written this way despite the prevalence of multi-core CPUs because they're easier to debug.

I'd like to transition to this sort of frame loop in LinApple. Not having it is kinda why I've backed off of working on #5. What I'd like to do is to create stub init/shutdown functions respectively above and below all other parts of main(). As initialization code is identified, that code should be moved to be called from init. Any corresponding shutdown code should be called from that function in reverse order. If initialization code cannot be moved to init for some reason, it should be marked along with what the problem is so that when the problem is addressed, it can be moved.

I think I'd wait to move on to the frame loop until that's done to the greatest extent possible. From there I'd stub in draw, input, and think before the current per-frame code, which should be classified as "think" logic. At that point, I would actually start with the code that is least behaved such as the modal DiskChoose/DiskFTP and implement conditional draw and input code for those modalities (handing essential system events this time…)

Once everything's drawing and inputting and thinking in that order, refactoring shouldn't be too hard to clean it all up in short order.

Famous last words…

Before I go moving this to the linappleii namespace, I just want to open a conversation up about the move. I'm wanting to confirm that @dabonetn and @iKarith are wanting to take over this project.

Hope you're all doing well these days... In a quest to do something useful during the current "corona lockdown" over here, I went along and borrowed AppleWin's debugger sources and ported them to Linux. :) This extends LinApple with a neat debugger/assembler/disassembler...

Apart from the usual VisualStudio vs GNU/Linux/SDL issues, it mainly involved replacing the character generator. I reused the same bitmap we're already using for the Apple II fonts.
Some changes were also necessary in other modules, e.g. to provide the debugger with access to video modes and memory bank information. Several variables, flags and functions had to be exposed to the header files. Those changes are mostly similar or even completely identical to current AppleWin's head - so those changes are not really new inventions.

Also, several changes were necessary to the existing Debug header files: these files were already present in LinApple, though so far mostly unused. Several debugger data structures were extended or renamed since LinApple was forked, so a number of updates were necessary to work with the latest AppleWin debug cpp sources.

All debugger sources live in a separate sub directory (src/Debugger), so debugger/assembler/disassembler sources don't clutter the rest of the emulator. This, also, is identical to the way AppleWin handles this. Exceptions are the already existing debug header files (Debug.h/Debug_Types.h), which were already present in LinApple's "inc/" folder. I left them in the global include directory - since they are included by other sources, outside the debugger itself.

Not surprisingly, the look and features are (almost) identical to AppleWin, of course. I'm still testing and playing with it, but it seems pretty stable to me. If you're interested, you can peek and test the debugger over here:
https://github.com/ThorstenBr/linapple/commits/debugtest

Press "F7" to enter debug view at any time. It should look like the screenshot below...

Obviously it'd be cool to eventually have the debugger as part of standard LinApple. I can clean up and eventually create a pull request when it's ready. Adding the debugger is a larger patch though, so let me know what you think about it...

Stay safe and healthy!

Some (but not all) of the res/*.xpm files are generated but have a broken dependency graph. For example, make clean build/asset.o will fail because it has #include "../res/splash.xpm" but no dependency arc to ensure that gets built first. This kind of thing causes mysterious random failures in parallel builds (make -j8).

As well as fixing this, it would also be nice to keep the source .xpm files and the object .xpm files in separate directories, to make it easier to distinguish the two when debugging problems like this. perhaps move the generated .xpm files to build/?

I'm trying to load the Total Replay image but it won't work. It's distributed as a .2MG file, but converting to .po or .hdv doesn't seem to fix it.

I can load other .hdv files.

My symptoms are the same as here:

Trying to boot with a hard drive enabled drops out to monitor.

Starting ProDOS, attaching the (converted) hard drive image to #7, then doing PR#7 from the prompt results in a lockup with

R 0 0 0 0 1 0 0 1

on the screen.

I found a Usenet thread saying that Linapple currently has a bug related to SmartPort that was fixed in AppleWin.

This is one of the more awful sections of code. Proposing to refactor. We should really have true alphanumeric sorting without respect to case. Admittedly, this deviates from *nix standard which considers case in the sorting. Reason for this proposal is the nature of the usage, which may have hundreds of .DSK images in a given directory, some Uppercase, some lowercase.

Doing it this way paves the way for another feature: progressive search. Type "wa" and the selector will drop down to anything starting with "w" and then "a".

There is a bit of code in here to allow downloading disks over FTP. FTP is quite dated. I think if we wanted to have some functionality like this it may make more sense to set up a service with a REST API that gets called. I don't even really think this is a good idea and I'm doubtful people are actually using this feature.

Minor issue on the splash screen shown immediately after start-up. It says "Press F2 to reset".
F2 does not trigger a reset though - it's Ctrl-F2...

The version of 6821.cpp we use from mame has an explicit license for non-commercial use only. This runs afoul of the GNU GPL which prohibits such license terms. We just need to refresh this using MAME's new license terms. :)

LinApple is currently missing support for international character sets. The (Euro-)Apple II supported various character ROMs (UK, French, German, etc). The ROMs had double size and also contained the standard US character set. And there was switch below the keyboard to toggle between local and US set. (The switch also influenced the keyboard mapping - but that's a separate task...)

The character ROMs also differed for the enhanced and non-enhanced version, which currently isn't properly reflected.

How should support for those ROM variants be integrated? Add a command-line (or config file) option to select an external file? This is what AppleWin does and it is flexible, but it does require users to find, download and install ROMs separately, which I guess, few people actually do. Or just add all ROM variants to the code, which would simplify configuration, since all the user needed to do was set a config option. I'm aware of 4 different language ROMs - so a total of 8 ROMs, considering their enhanced/non-enhanced variants. The ROMs are only a few KB each, so not a space issue at all by todays standards.

I'd be volunteering to provide a patch - including a keyboard binding for the toggle switch ("Ctrl-F9" or similar).

Question is: which configuration option would you prefer?

(Being German, I really need the emulator to greet me with this hilarious "Apple ÜÄ" boot message again, since Apple had decided to map "]" and "[" (and "{" and "}") to German special characters - easily one of the worst design decisions Apple has ever made (imagine how Basic or Pascal code looked when you were writing a program with local language text messages...)

Where in the "src" is the centralized-top text message that appears when you boot the machine? The "Apple //e" text? I want to change it to "TK3000 //e", a brazilian version of Apple IIe.

What file should i edit?

I saw in #8 (here), that @ghedger said:

Other topic: There is an ongoing bug in AppleWin, and thus LinApple, relating to bank switching in High RAM -- these are the $C08x switches. AppleWin is (mis)using the AltZP as a switch for this in a long, complex logic statement. It's been a few months or I'd be more specific. Anyways, it's a case where it "works" for most software, since using the two upper banks of LCRAM in combination with the AltZP was apparently not common, but is nevertheless something I'd like to take a look at when I'm not embroiled in paying projects.

Can you provide some details how to repro this issue?

I see the version number was changed to 2.1.1 in 498b2b2 but I don't know if 2.1.1 was considered "released" at that point, or if it is still yet-to-be-released and some or all of the changes since then will go into it.

I think tagging master with the version number at the time of release (which I assume is coordinated with making Debian packages, in some manner,) would be the minimal way to clarify this.

Using a development branch or branches would be even more orderly, but also more effort.

Hi All,
I've tried to compile lineapple on debian buster (inside a docker container - see attached Dockerfile)

Compilation goes through but I have a segmentation fault trying to execute...
Any idea where to start looking ?

(Interestingly I compiled it and ran with success in a docker container but using a arm32 version of debian stretch)

Dockerfile.txt

( This is one of a series of retropie backports from @dabonetn 's fork.)

This has been done in the retropie fork via XPM embedding. Works great.
It will make the problem of where to put these files go away.

The project currently has two INSTALL files. We need to collapse this down to a single INSTALL.md file.

Choice between video and sound quality has been a bugaboo for LinApple.

A possible solution I've come up with is to shunt the video refresh (VideoRefreshScreen() ) into its own thread using pthreads.

So far, the results are extremely positive: zero audio delays or choppiness on a game that has Mockingboard background music, sound effects, and constant screen changes. The screen is currently garbled at times, indicating some sync problems that need to be dealt with, but no crashes or instability, indicating more work is justified.

What I'm not sure about is the possible impact on the Raspberry Pi and other more lightweight platforms.

My proposal is to make this -- multicore -- a configuration option.

It looks to me as if RESOURCE_INIT_DIR is unused. The only place this is mentioned is in the Makefile, which defaults it to /etc/linapple and adds -DRESOURCE_INIT_DIR=\"$(RESOURCE_INIT_DIR)\" to the CFLAGS. No source code files ever reference RESOURCE_INIT_DIR as far as I can tell.

Is this old code that can be removed?

The banked auxiliary memory (aka ramworks) emulation is somewhat flawed. To demonstrate the flaw follow these steps from a linux command line:

user:~ $ linapple -r4 #enable ramworks emulation

Within linapple at any basic prompt with or without a DOS:

] pr#3
] call -151
* c073:1

At this point the odd columns (1,3,5...79) fetched from aux memory are updated with zeros (inverse @). On real hardware video memory is always fetched from aux bank 0 so there would be no visual difference, but the emulated hardware immediately updates the columns stored in auxiliary memory with nulls upon bank switch.

This causes visual flashes and glitches while running programs that use banked auxiliary memory such as appleworks =>3.0.

As a secondary and likely related issue after switching the aux bank to !=0 the 80 column firmware (incorrectly) successfully updates the display. This should not be the case as real hardware still scans aux bank 0 while the firmware will write to the currently selected bank. Thus video updates will only affect the even columns (0,2,4...78).

I'd provide a patch but I'm unable to grok where the video and aux bank handling is in the code. Additional assistance is available to help resolve the issue.

(edit: removed a typo)

it's always the new guy who comes into the room with the crazy idea.

1. i wanted to remap joystick controls.
2. i wanted to remap keyboard controls. devs in the 80's didn't have any conventions to guide what keys they chose. and i think they didn't have up arrow and down arrow? !!!
3. i wanted to run under macOS.
4. i wanted to be compatible with applewin to exploit their non-Windows-specific features. i saw that applewin code is very Windows-y.

a core would give you 1-3 and change the playing field re 4. it would also remove a lot of code.

https://www.libretro.com/

The Makefile's install target hardcodes ownership changes to root with commands like install -m 755 -o root -g root .... This prevents non-root installs under a different PREFIX "local" to a project, such as one might use for development.

I don't have any particuarly strong opinions about how to fix this. Perhaps we could set a variable that could be overridden? E.g., have INSTALL_OWNER = -o root -g root in the Makefile, allowing make install INSTALL_OWNER= on the command line to override this.

I'm happy to write and test the patch for whatever is deemed the correct solution.

After compiling this version, I have a problem with the display font while using the Apple ][+ rom.
The flash text style has a problem with the characters @ and A-O which correspond with the first row the charset40.bmp if that helps. While this wouldn't normally be an issue as not much uses flash text, Wizardry however does somehow access these characters to display normal text.

Here is a simple output showing the issue and an example of the Wizardry 1 intro screen.

Screen capture while FLASH is alternating black

Wizardry 1

Hi,
How do I save and load basic code written in the emulator ?

Thank you
Eran

The various Apple ][s had different keyboard layouts, and are different than the current PC keyboard layout.

In particular I used to play BOLO with left hand WASD directionality, and right hand spacebar/turret rotate.

God that was fun.

Anyway, this is impossible in the PC layout, the turrent only rotates one direction.

I didn't see if this was possible in LinApple, but I imagine it would be nice.

Another nice feature would be to show a picture of the currently activated/configured keyboard and as you press keys it shows what was depressed on the original keyboard, but I'm getting greedy there. Oh the apple-emu-in-javascript/browser kinda does that.

Attempt to set 'Disk Image 1' to '/home/user/Desktop/linapple/res/Master.dsk' ignored (registry is read-only)

The current master keeps crashing for me with the segfault below in VideoPerformRefresh / SDL_SoftStretch. Maybe related to #76, but not sure...

I can quickly and reliably trigger it by enabling the as-fast-as-possible mode (scroll lock) and then cycling through the video modes with F9 a couple of times:

Thread 5 "linapple" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeda82700 (LWP 4252)]
(gdb) bt
#0  0x00007ffff7b6cba4 in SDL_SoftStretch () from /usr/lib64/libSDL-1.2.so.0
#1  0x0000000000430141 in VideoPerformRefresh () at src/Video.cpp:1798
#2  0x000000000042fa19 in VideoWorkerThread (params=0x0) at src/Video.cpp:1644
#3  0x00007ffff7928569 in start_thread () from /lib64/libpthread.so.0
#4  0x00007ffff617c9ef in clone () from /lib64/libc.so.6

(gdb) up
#1  0x0000000000430141 in VideoPerformRefresh () at src/Video.cpp:1798
1798	      SDL_SoftStretch(g_hDeviceBitmap, &origRect, g_origscreen, &newRect);

(gdb) info locals
addr = 0x945030 ""
pitch = 560
src_locked = 0
frm_locked = 0
update = 0x42da44 <UpdateDHiResCell(int, int, int, int, int)>
anydirty = 1
y = 24
ypixel = 384
srect = {x = 1015, y = 715, w = 0, h = 0}
bStatusShow = 0

Last call from inside linapple was here:

1791 // New simplified code:
1792  // . Oliver Schmidt gets a flickering mouse cursor with this code
1793  if (anydirty) {
1794    // Draw up entire Apple 2 screen
1795    if (!g_WindowResized) {
1796      SDL_BlitSurface(g_hDeviceBitmap, NULL, screen, NULL);
1797    } else {
1798      SDL_SoftStretch(g_hDeviceBitmap, &origRect, g_origscreen, &newRect);
1799      SDL_BlitSurface(g_origscreen, NULL, screen, NULL);
1800    }
1801    if (bStatusShow && g_ShowLeds) {
1802      SDL_BlitSurface(g_hStatusSurface, NULL, screen, &srect);
1803    }
1804    SDL_Flip(screen);  // flip SDL buffers

This is what happens when you load master.dsk with the emulator in Apple II/IIplus mode:

I was worried my video ROM updates had broken something. But it's always been this way. Same for current AppleWin. I knew the Apple II/IIplus had no support for lowercase letters, but I always thought it would just display uppercase letters instead. That's obviously not the case: the lowercase letters are mapped to completely mismatching letters.

I only have an Apple IIe, not an actual Apple II to verify the correct behaviour. Is this really how things were? So even simple basic programs using lowercase letters (developed on a IIe) couldn't run on an Apple II? Or is the emulation broken here?

If that's really how things were, it might be a good idea to adapt master.dsk (to use uppercase letters, at least when detecting a II/IIplus machine).

Hi! Great work on the emulator! I was trying to run this demo: http://fr3nch.t0uch.free.fr/MAD3/MAD3.html which runs fine in AppleWin but fails displaying 'KO' on LinApple. Testing in AppleWin I noticed that if I turn off the '50hz video' setting in WinApple it also fails with the same error. Looking at the source code of the demo I noticed it does a check for what appears to be the refresh rate. I went over the Video.cpp and Video.h source code in AppleWin and the Linux version but see no reference to 50HZ video in Linux. Is this unsupported? Is it complicated to do?

Easier to demonstrate than describe:

• In the ~/linapple/linapple.conf file, make the screen size something like 560 X 384
• Fire up something with sound, preferably Mockingboard + regular sound (e.g. U5 boot)
• Note sound quality
• Quit Linapple and change the ~/linapple/linapple.conf file to make the screen size big, like 1680 X 960
• Fire up same program and notice the latency

I suspect this is SDL 1.2-related and also related to the game loop, and clearly ties in with other observations and suggestions of a deeply structural nature (like upgrading our SDL and cleaning up the game loop).

I usually edit my graphics in vim, either because I'm a SUPREME BADASS or because I'm legally blind and it's more comfortable for me to define my images as text files. You decide what you're gonna believe. :)

This is the fir image I've done in a very long time that was done entirely in a GUI using Inkscape. I'm pretty proud of it for what it is. And it's a vector image that will fit into any Linux desktop environment at any size, and can be rendered to all of the canned icon resolutions macOS uses, up to and including 512x512 or larger. It's a vector image after all.

https://gist.github.com/iKarith/5be384f6a76288e43e819c349941a521

Sadly it doesn't have that pixelated quality of the Apple II screenshot, but those pixels would look terrible when rendered at smaller resolutions, whereas the vector will work no matter what, possibly losing the black lines at very small like favicon sizes. (Just added a 16x16.)

We need a consistent style in the code. @ghedger provided an example (two space indents) which #7 will mostly give us. The project is at a crossroads though and since Greg hasn't joined the project yet we can ignore his preferences. 🙃

As long as what we've got is consistent (it isn't, and won't be after #7 is merged) I don't have any specific need for a particular style of indentation. Except GNU braces are dumb, but nobody else uses them anyway. 😎

I am going to drop an EditorConfig for whatever we go with in there. That's trivial for vim-flavored editor users who use plugin managers and not much more complex if you don't. I might also add verbose vim modelines as hints for anyone not using an EditorConfig-supporting editor, mostly because I know how to write them.

We might want to look at whatever AppleWin uses most consistently and do that—that'd make it a lot easier to pull features from them. They've had a dozen years' worth.

to help do that in an automated fashion, and I propose to do that here as well. Greg and I use vim flavors, which if not having EditorConfig built-in is at least a trivial addition if you use a plugin manager and only a little less so if you don't. Once we have that in place, I don't especially care because I'll do what I normally do and the editor will do magic for me. ;)

I'd propose though that we adopt the most consistent style I see in AppleWin's source code. That's a four-space hard tab, which again as long as there's an EditorConfig file to configure, I don't mind. I also typically add verbose vim modelines (since I don't know how to write them for other editors offhand) as hints for people who don't have a

Given the discussion in #8 I think we should see who is willing to come together for this project. I'm starting this issue to work that out.

Our use of a directory named obj is incompatible with BSD's make. We don't presently explicitly support building on BSD, and we wouldn't be the first project to require the use of GNU make on that platform if we did. This page describes one of the major gotchas.

This can all be solved with the use of autoconf and possibly automake (at the potential cost of my sanity in porting it—something I've already started doing, God help me). Until that's done, I'm just documenting the issue.

The changes from here
https://github.com/dabonetn/linapple-pie
have been integrated into master here
https://github.com/yoyodyne-research/linapple/commits/retropie
in the interest of converging being able to share enhancements.

These were changes for using Linapple with RetroPie:

1. more user-facing joystick configuration
2. exit via 2-button press on joystick
3. building resources into the executable
4. command line options for inserting disks and autostarting

and as mentioned in #8 code was machine-formatted to do the integration.
I'm stacking the help and chooser screen changes atop this.

I was thinking this could be a branch retropie in this repo.
If it could be merged into master as well, then the branches would track and could share, while keeping incompatible differences separate.

BTW (3) is interesting as it sidesteps the question of where to install resources. Master.dsk and linapple.conf are still loose files and could go into XDG_CONFIG_DIR as mentioned in another issue.

Desired feature. Perhaps facilitated with some mass renaming and code temporarily yoinked from SDLCL, a cool and totally underhyped LD_PRELOAD shim for using non-free Linux games for 1.2 with 2.0.

Actually, if it works half as well as I expect it might, I may have to go back and offer @MrAlert a PR that does some macro stuff to make it easier to do that. Far too many open source games and the like still use SDL 1.2 because the API porting curve is just about a vertical cliff. Ryan Gordon's said many times over the years that he really should go and write a shim for porting but never did it. (not that I have room to talk, how many YEARS did I threaten to write SDL_teapot for GL redbook+SDL before someone else did it?)

Anyway, SDL2 wanted for LinApple!

Hi! Legibility of text on file chooser screens can get bad. I did an alternate take on them which only uniformly scales text, aligns all sizes and removes visual clutter.

That's at scale 1.5. Looks ok a scale 2.0. Have not tried weird aspects yet.
I'm on a RetroPie Raspberry Pi, using SDL in fullscreen and windowed. Most ppl will use the former.

The resources where moved to the res/ directory in bbc0fbf. When linapple executes it generates the following errors.

Video: ./splash.bmp was not loaded
Video: Apple text is not available: ./charset40.bmp was not loaded

I've tried setting RESOURCE_DIR in Resources.h to ./res/, res/, and /res/. The only thing that worked was setting the fully qualified path to where I have the project cloned, but that's obvious a no-go.

Since the application cannot even load the font then nothing shows up on the screen.

The Disk Chooser, at present, runs in a constant spin loop where it rewinds the file/size lists and redraws the frame, as far as I can tell, at full speed. It is handled within an event handler called from Frame. This is very poor practice, to have a UI event loop within an event handler.

If a physical USB joystick is connected, about half the time selecting a file is extremely sluggish, sometimes requiring killing and restarting of the emulator. Cause has not been determined; only happens when a joystick is connected.

I propose we instead, building on the earlier DiskChoose refactor, further break up DiskChoose::ChooseAnImage() into

• Initialize: garner sorted list
• Message update

and, when F3/F4/other file choose is hit write to a a global state variable that dictates flow of the main outer message loop.

Loosely, the call cadence for the outer message loop is like this:
main() -> EnterMessageLoop() -> ContinueExecution()

This needs to live under EnterMessageLoop().

Furthermore, there's a homegrown templated data structure called List<>. List<> is defined in inc/list.h, contains comments in Spanish, and behaves like someone's class project. It was someone's valiant stab at a linked list. It has proven to be problematic, eliciting anomalous behavior, frequently double-printing some entries and omitting others, both of which are difficult to reproduce and seen typically in large directories. Now that we have access to C++11 features I suggest we explore replacing List<> with std::list<T, Allocator>.

Awhile back I'd added a package generator for install to Debian-derived Linuxes (e.g. Ubuntu) via dpkg.

sudo make package

Soliciting opinions from more expert-level Linux users on a more appropriate way to handle packaging as my experience here is limited.

It appears one can follow this cadence to get an installable LinApple sans the sudo make package (and subsequent sudo dpkg -i linapple.deb):

make
sudo make install

What are your thoughts?

I started this and discovered some trumping behaviour. Given time i'll see if that's removable.
For bonus points i started putting in --state, which allows a state file to be loaded immediately.

Here, my primary user is RetroPie.

I accidentally hit Shift-F2 rather than Ctrl-F2 - which currently crashes the emulator for me. The assert(!registry) triggers in LoadAllConfigurations:

void LoadAllConfigurations(const char *userSpecifiedFilename)
{
  // At this point, registry should not be set. If it is, it means someone
  // probably tried to load configuration values in a different function.
  assert(!registry);

Commenting out this assertion just makes things worse. I haven't investigated further. But something just isn't right there...

In some files, e.g. Registry.cpp there are uses of VOID, BOOL, etc. Some Googling indicates these are artifacts of win32 programming. What I couldn't tell for sure is if it is safe to just move these to the standard lower-case versions. It looks like VOID can safely be converted, but I'm not so sure about the other keywords.

I've got code loading the various bmp files out of the directory the linapple binary is installed to (no matter where you run it from) and in iKarith/linapple it now loads them all only once (which eliminates an error), but I'm still not doing anything with the registry file in particular beyond the odd merge of @ghedger and @cpressey's trees.

We can write the file out of SDL_GetPrefPath(). What's desired behavior here?

It's not really clear how to create or use the ROM SET archive feature.

In my apple II rom dir (/apple2), I'd prefer to have all of my dsk files for each app/game in one zip archive per ROM SET.

I have not seen a lot of documentation on this feature and I'm hoping for some insight into how it works, and how stuff needs to be organized.

I found this document, http://linapple.sourceforge.net/INSTALL.txt

For linaaple ability to unpack .zip and .gz files on the fly (either from local disks or from FTP) you also need read/write access for linapple working folder (which by default is /usr/local/linapple), for linapple unpacks these files as drive0.dsk and drive1.dsk for drive 1 and 2 respectively.

• How do these files need to be organized to work?

• How do the files need to be named in the archive?

• If you have 2 files do they need to be named drive0.dsk and drive1.dsk?

• If you have more than 2 files how do they need to be named? or does Linapple not support more than 2 dsk files in an archive?

• Does it rename the files in the archive drive0.dsk and drive1.dsk? and if so, does it do it according to an alphabetical sort?

Currently the user specific configuration files are stored in ~/linapple. An easy way to keep cruft out of the user's home directory would be to store it in ~/.linapple instead, but the truly elegant solution is to use the XDG spec.

Based on 2b3cf0c

Traditionally the images have been stored in code as both xpm and bmp files. We should store them in a single format that gets "compiled" when make is run.

The splash image should be in a layered format so that the text can be updated fairly easily when needed.

My vote would be to store the images as Gimp xcf files. We should be able to use imagemagic to convert these to bmp when make is run ... I think.

( This is one of a series of retropie backports.)

This has been done in the retropie fork, via the configuration file. Works well.
Now the Lode Runner doesn't dig on the right when i press the left button!

The project currently has two README files. We need to collapse this down to a singl README.md file.

Would it be beneficial, or even correct, to use the L macro instead of TEXT for string literals? If my reading is correct, the TEXT macro is something that comes from Microsoft and is only useful if you want to support unicode and non-unicode platforms.

it's written as:
"./config/linapple/linapple.conf"
should be:
"/.config/linapple/linapple.conf"