Linux and Mac support

[maximilien-noal]

Hello

Thank you for this very impressive emulator.

I already started working on replacing WPF with AvaloniaUI, to make it work with Mac and Linux too.

One issue is sound, it seems that TinyAudio would have to use OpenAL on macOS (I don't have a mac to test this), and ALSA on Linux (I use Linux daily, but I barely know anything about ALSA's API)

I've seen a lot of examples for both, but it's a lot of work.

Some other NativeMethods classes are also Windows specific.

For now, I labelled them with

[SupportedOSPlatform("windows")]

and return null on non-Windows OSes in Audio.CreatePlayer...

Anyway, I'm trying to see right now if I easily and quickly can add an AvaloniaUI client. Should be relatively simple.

If you are interested to see the action, it's happenning at Aeon-Staging. :)

[gregdivis]

Thanks!

I wrote most of Aeon over ten years ago, starting it on a whim after I got annoyed that I couldn't resize the window in DOSBox (seriously). At the time I just wanted to see if a similar emulator would be fast enough in .net, and ended up taking it a lot farther than I thought I would. I kind of revived the project a couple years ago and started making a few improvements and moving to .net core.

Anyway, I'd love to see it taken cross platform. I honestly just have almost no time to work on this anymore, so I'm happy to see someone else able to use it for something. AvaloniaUI looks interesting, I'll be sure to follow your progress there.

As for TinyAudio, that was something I threw together with the eventual goal of getting Aeon more cross platform. Before that, I just had it call into DirectSound directly from the audio emulation layer -- so it's a bit better :) I had every intention of adding ALSA support to it at least, but never got to it (I also have no experience with it). If you know of something better to use, by all means give it a try. I pulled that stuff into its own library so it would be easier to replace.

I tried to keep Aeon.Emulator itself OS independent at least. If you can figure out the UI, sound, and gamepad/input, it should be pretty portable. Well, to a point. I can't imagine it working on a big endian architecture as written.

-Greg

[maximilien-noal]

:)

I'm glad to report the following update:

• Works with no sound backend and no controller support (Windows only)
• Debugger Window is still TODO (should not be a problem)
• Palette display window works
• Copy/Paste bitmap from/to clipboard needs testing, surely does not work as is.
• Command line display is not working...? (edit: fixed)
• GraphicsPresenter8 and other presenters need to copy bytes a little differently wih Avalonia, this is different from WPF. Without it, some Linux configs (namely proprietary nvidia drivers) don't display anything. This is the important issue to fix before saying it's working at all. Issue/explanation here : WriteableBitmap: doesn't display anything on Linux (and I don't know about other platforms) AvaloniaUI/Avalonia#7881
• Some minor layout issues, and some styling was not ported at the moment (Triggers and Style Selectors à la WPF don't exist in Avalonia)

Still, it looks promising (testing Dune here):

-Maximilien

[maximilien-noal]

Guess I have this partially fixed :

What was wrong :

• The simple for loop didn't show anything, GraphicPresenter8 has to use a row/column approach (too for loops)
• I don't have access to ILockedFrameBuffer.RowBytes but a value of 2560 in this instance is clearly wrong and leads to an error. I have 320 * 200 pixels to copy, that's 320 pixels per row. More than that would be Aeon's scalers
• The value had to be converted to ARGB (a real fix would use the format told by ILockedFrameBuffer).
• The image wasn't scaled, using any of Aeon's scaling option made the image smaller. The fix was to set the image itself to Stretch="UniformToFill" instead of "None".

Once this Presenter is fixed, all others will have to be fixed in a similar way, too.

Guess this will break the WPF client...

Avalonia's WriteableBitmap is always such a headache...

[maximilien-noal]

Fixed.

(I intend to provide PR once everything is fixed, even sound, but it might take a while, but that's far, far into the future)

And I'll stop spamming for now. :)

[gregdivis]

Very cool! Impressive progress so far! WPF's WriteableBitmap was not very great to deal with either, which is why I ended up cheating and using InteropBitmap instead. Of course, that makes more headaches now with portability, but it seemed like a good idea at the time :)

[maximilien-noal]

Thank you ! :)

Another massive update (well, not in number of lines, but the number of headaches beforehand...) -> TinyAudio uses OpenAL instead of WasApi on non-Windows OSes.

maximilien-noal/TinyAudio-Staging@14b369d

As usual, I test this with Dune.

• SoundBlaster OPL works well.
• Restarting the emulator, (by launching a new game) not so well... :D
• MT-32 is untested. I did not implement the "useCallback" mode in OpenAlAudioPlayer.cs. Probably doesn't work.
• Native General Midi usage by Aeon is still Windows only (direct calls to WinMM).
• SoundBlaster PCM hangs the emulator. This of course doesn't happen on Windows.

I'm glad to have working MIDI music, but sound is clearly a massive headache... Why won't PCM work ??

OpenAL seems to have a lot of undocumented areas... One that is documented however, is that several instances are permitted, so I don't have a clue at the moment about the PCM issue.

[maximilien-noal]

Welp, here's why...

/// <summary>
/// FIXME:
/// We must use a multiple of 16 or else _al.BufferData will return InvalidValue...
/// But at the same time, refusing too small buffers makes PCM not work at all, since we constantly do not buffer anything more...
/// </summary>
private static int GetRemainingLength(ReadOnlySpan<byte> input)
{
    int value = input.Length - (input.Length % OpenALBufferModulo);
    return value;
}

[gregdivis]

Heh, that is...inconvenient :)

Sound is indeed a headache. There's just so many ways for that to break down.

Let me know if there's anything I can do to help!