Linux, AppleWin & Qt

[audetto]

Hi,

I would like to share a little project on which I have worked in the last months.
It is a port of AppleWin to a native linux application based on Qt.

It is available here https://github.com/audetto/AppleWin

It is actually 2 ports, one to ncurses and one to Qt as described in https://github.com/audetto/AppleWin/blob/master/linux.md.

I have written 2 frontends to better understand what is emulator code and what is frontend.

I have reached a point where "normal" emulator features are in a usable state and don't feel embarrassed any longer to share it.

The main goal of this exercise is the following: keep merging from AppleWin trivial.
I do not want to spend ages to merge and for this reason very few changes to the AppleWin source files have been allowed. Mostly to fix unavoidable compilation errors in gcc or when the cost of making the code compile was too high (see the #ifdef at the end of MouseInterface.cpp).

What about graphics? It is very similar to linapple (maybe like AppleWin 1.25), lo res in color, hi res in BW. No options, and I don't think I am making good usage of OpenGL.

What's next? Good question!

I don't really know myself. I would definitely like to commit to AppleWin all the "pure c++" changes to make merging even easier, and I will create a branch for this if anyone is interested.

Why Qt? Why not SDL? To be honest I have chosen Qt because it provides so many UI widgets and features that I had no idea how to create in SDL. But at the same time I have realised that timers in Qt are nowhere as precise as in Windows.

More features? Audio? libretro? debugger (there is too much Win32 code in the debugger files to be used as they are)? Android? Depends on time.

Anyway, guess I will stop when the fun stops.

[audetto]

Here is the branch that includes the minimum set changes to compile with gcc.

https://github.com/audetto/AppleWin/tree/gcc

It is just for information for the time being. It needs a little work to ensure it works in VS as well.

[snaxxus]

Thank you!

…

On Feb 10, 2018 1:16 PM, "Andrea" ***@***.***> wrote: Hi, I would like to share a little project on which I have worked in the last months. It is a port of AppleWin to a native linux application based on Qt. It is available here https://github.com/audetto/AppleWin It is actually 2 ports, one to ncurses and one to Qt as described in https://github.com/audetto/AppleWin/blob/master/linux.md. I have written 2 frontends to better understand what is emulator code and what is frontend. I have reached a point where "normal" emulator features are in a usable state and don't feel embarrassed any longer to share it. The main goal of this exercise is the following: keep merging from AppleWin trivial. I do not want to spend ages to merge and for this reason very few changes to the AppleWin source files have been allowed. Mostly to fix unavoidable compilation errors in gcc or when the cost of making the code compile was too high (see the #ifdef at the end of MouseInterface.cpp). What about graphics? It is very similar to linapple (maybe like AppleWin 1.25), lo res in color, hi res in BW. No options, and I don't think I am making good usage of OpenGL. What's next? Good question! I don't really know myself. I would definitely like to commit to AppleWin all the "pure c++" changes to make merging even easier, and I will create a branch for this if anyone is interested. Why Qt? Why not SDL? To be honest I have chosen Qt because it provides so many UI widgets and features that I had no idea how to create in SDL. But at the same time I have realised that timers in Qt are nowhere as precise as in Windows. More features? Audio? libretro? debugger (there is too much Win32 code in the debugger files to be used as they are)? Android? Depends on time. Anyway, guess I will stop when the fun stops. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#538>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AY4qZes49EE1iIUYLdiu6xz09IRZz0T1ks5tTdzlgaJpZM4SBBcf> .

[sicklittlemonkey]

It is a port of AppleWin to a native linux application based on Qt.

Great.

I have written 2 frontends to better understand what is emulator code and what is frontend.

It would be awesome to have a truly cross-platform AppleWin and abstract away the OS dependent parts.

The main goal of this exercise is the following: keep merging from AppleWin trivial.

Fair enough.

I don't really know myself. I would definitely like to commit to AppleWin all the "pure c++" changes to make merging even easier, and I will create a branch for this if anyone is interested.

Sounds good! I hope Tom agrees. Cheers, Nick.

[audetto]

This is a better branch to look at

https://github.com/audetto/AppleWin/tree/gcc_vs

These are most of the changes required and it compiles in VS2017 as well.

1. const char *
2. NULL or 0
3. include
4. HDD, Disk_t
5. unzOpen
6. delete [] vs free
7. remove a static
8. memimage = newloc (required to run under valgrind)

They could be split into multiple commits if there is an interest in integrating them.

Andrea

[tomcw]

Hi Andrea,

I took a very quick look at your Linux/Qt branch. I think if we do this, then we should think about design (eg. front-end, common core and platform specific), and also project structure (source code layout). I appreciate that your current layout is just to minimise your merge pain.

I think we need a solid plan for this before proceeding. Obviously you've taken a stab at this, so perhaps you can share your thoughts?

I'd also like to get Michael's (@Michaelangel007) input, as I know he's looked at SDL in the past (see: #184, #223, #274). But he's currently on sabbatical.

re. patches to compile with gcc

They could be split into multiple commits if there is an interest in integrating them.

I think it's OK to just put all the commits into a single pull-request.

Thanks.

[audetto]

I will make a pull request for the changes.

My thoughts about this exercise so far are

• the first obstacle I found was the types form windows.h (BYTE, DWORD...) but at the same time a simple typedef layer solves this problem
• same thing for some c-runtime functions which have a more portable alternative (xxxprintf, open file, memory allocation), again a compatibility layer can solve this issue
• most of the core emulator files are usable as is, but other mix emulator and frontend code:
  • MouseInterface.cpp is perfect until line 756. The rest should probably be in a different file
  • Disk.cpp and Harddisk.cpp: DiskSelectImage() should probably go to a different file
• options and settings: I don't think I've clearly understood the difference between the Registry and the various IPropertySheet. The boundary between GUI and data is blurred
• Video, Audio & Keyboard I have completely reimplemented and I believe it will probably be the most difficult part to share across platforms, so I would not make it a goal
• then there is the whole question of how you would design the interface: my link-time interface must have caused some eyebrows to rise
  • should the emulator be an object to which are provided the necessary function pointers?
  • a class with abstract methods?
  • can I run 2 emulators at once?

I think that splitting emulator code from frontend could be a start and ensure that one can create a "headless" AppleWin which has no interaction with the outside world (except disk maybe), without pulling in non required code.

Andrea

[audetto]

I've settled for this branch, https://github.com/audetto/AppleWin/tree/gcc_vs2

It is basically everything where I could find some common ground. There are a few more little things, but I did not want to add #ifdef.

Andrea

[tomcw]

FTR, @audetto created PR #539, which was then superseded by PR #541. This latter PR then got merged into master.

[rmacri]

From personal experience with the simulator (logistics) I develop, its very healthy having a codebase that compiles cleanly with both Visual Studio and gcc, each nitpicks differently. In my case I can build with Visual Studio 2018 (32 or 64 bit Windows, full graphical editing/animation), MinGW/gcc (32 bit Windows graphical Windows app as per VS) and plain gcc (Linux batch run only, no UI, made possible by a toolkit layer and my own "windoze.h' stub). No demand for Linux graphical sadly so its not been worth my while even trying Winelib let alone Qt.
The main body of work has very few conditional compiles. Not sure how MinGW would go with DirectSound etc, AppleWin is more demanding library wise. I could write a lot more on same code performance comparison discoveries.

[xandark]

I can't tell you how happy I am to hear that steps are being made to bring AppleWin to Qt and thus to all platforms. Now I'll be able to run it natively on Linux, woohoo!

[audetto]

Please give it a try.
I don't think anyone else has ever tried to compile it. Open an issue there if you have problems.

Probably the single most annoying thing is missing audio.
I've written it, but I have not fully understood QT Audio times so it drifts after a while especially when the emulator goes at maximum speed.

[Michaelangel007]

Catching up on stuff here.

@tomcw Feel free to shoot me an email if there is anything you want me to take a look at. I'm still not sure when my sabbatical is over -- but I can always make time to take a quick look at stuff.

@audetto Thanks for all the work and feedback.

Some quick feedback:

• Qt, while being functional complete. is NOT light-weight. It is for this reason I not in favor of using it -- at all because at the end of the day all we've done is replace C Win32 calls with C++ Qt calls.
• SDL while being more bare-bones allows for the fastest performance. The drawback is we need to write our own "Widget Library". I don't think we are doing anything that complicated in our dialogs and tool-tips so hopefully this shouldn't be too much work.

Regardless if we go Qt or SDL someone has to do all the grunt work of removing all the "Win32ism" deeply embedded in the application. Audetto, it looks like you have started this process? That's great to hear!

Personally, I would like to see a "clean SDL" version of AppleWin that builds across Windows, OSX (er, macOS), and Linux down the road.

One of the reasons we "failed" to merge LinApple is that the debugger got removed. /oblg. Not Cool, Man! 👎

Temporarily stubbing functionality out is OK in the short-term but not long-term. And yeah, I probably should make a pass on cleaning up all the Win32 stuff in the debugger section(s).

Since rewriting a new version from scratch really isn't really feasible and AppleWin has been extremely organic we'll just have to manage the complexity of re-factoring code as it comes up.

I am excited to see people using gcc to compile AppleWin! The sooner we address portability issues, and compile with MSVC, GCC, and Clang the better we are. At some point we probably should put together a C++ usage guide -- if we haven't already -- to keep all the bloated C++ crap to a minimum. (Which I thing we've done a pretty good job of.) Hopefully we shouldn't have any compiler dependency stuff?

I think the first order of business would be to make a pass over the all the Win32 types: BYTE, DWORD,
etc and convert these to standard C++ types: uint8_t, uint16_t, uint32_t wherever possible. Obviously we can't remove all the Win32 cruft but we can phase this out.

I really like the idea of your own windoze.h wrapper! In theory we should be able to switch to Qt or SDL on the back-end but in practice we'll have to see how much coupling we have with Win32.

Also, I'm an older MSVC version (2010) -- if things don't work there I can't test it out. At some point I'll install MSVC 2017 (2018?) -- hopefully we can get everyone on board with at least the same (Windows) compiler.

OK, enough rambling.

@tomcw Tom, was there anything in particular you wanted me to take a look at?

@audetto I don't see your branches anymore? Did they get moved / renamed?

[audetto]

About Qt vs SDL, I still believe a hard choice is not required.
If the "emulator" code is separated into a library then many different frontends can coexist: I wanted to try to create a version for libretro but have not found the time yet.
As I said in the original post, this helps a lot in understanding where to set the boundary.
Maybe a quick look at other projects (VICE, N64...) could provide some inspiration.

Agreed on the Win32 types, I would remove all the Win32 specific Memory Management and String Manipulations: I think here C++ could help a lot using vectors, strings, shared ptr. And after that, all the file manipulations but I don't think there is such a standard set of API to access folders and file attributes.
The version in Linux works as a 64bit app: ensuring it works 32/64 helps as well. I have compiled AppleWin as a 64 bit app, but it required a few changes to more portable version of some Win32 APIs (forgot which ones right now...)

About the debugger: you can't really blame LinApple for dropping it, it is just too much interleaved with Win32 functions. I have done exactly the same: the only alternative being a complete rewrite, but this was against my goal to reuse most of the code.

Another thing which I found difficult was to have a bit-by-bit reproducible runs to debug and compare different versions. I was not able to use existing options to achieve this so I changed some of the "non deterministic" parts to be able to do this. Maybe worth adding such a flag.

Then there is all the NTSC stuff which honestly I did not understand a bit ...

The branch is still present here

https://github.com/audetto/AppleWin

[xandark]

Regarding this thought:

Qt, while being functional complete. is NOT light-weight.

Is that a specific, stated goal of AppleWin? To be light-weight?

I'd like to present the case for Qt. With Qt, one significant advantage is that the GUI style automatically adapts to user's platform and is thematically congruent.

Because Qt has paid, professional developers evolving it constantly, it is terrifically cross-platform and will even adapt to Android, iOS, embedded platforms, and whatever else comes up in the future.

Qt is also modular, and the full stack doesn't have to ship with every Qt shared library.

For example, the 4k Video Downloader utility uses Qt and it ships with just 9 Qt dll's for its particular use case. I've recommended this utility to several friends who use differing OS's and none of them complain about the size of the download; they're just happy to have something that works elegantly for them and is intuitive to use.

[Michaelangel007]

I'm strongly against including Yet-Another-C++-Library such as Qt for the reason mentioned above -- swapping out the "fat" Win32 API for another "fat" Qt API isn't really solving the problem long term.

A light-weight goal isn't a explicit goal but an implicit one. I come from a professional game developer background and detest the bloated C++ style of including everything and the kitchen sink. Qt falls in this category as well -- bloated compile times and a bloated exe.

it ships with just 9 Qt dll's

I rest my case. AppleWin doesn't ship with any .dll's because it doesn't need them; 1 file is easier to manage then X of them.

KISS is the goal here. We should be only including the bare minimum of code to get the job done.

Likewise we should be keeping the C++ usage to a minimum. If we need to use std::shared_ptr then we are probably doing something wrong.

A user should be able to download the AppleWin source and immediately be able to compile it. They shouldn't need to download a billion dependencies.

From past SDL2 experience:

• I'm working on two indie games and SDL2 + OpenGL has been rather trivial to get included and working,
• I'd rather spend my time using and debugging SDL2 -- something that I already know -- vs learning yet-another-foreign-framework such as Qt.

Going with SDL2 has a few benefits:

• The work has already been started with LinApple. We already know this works. My hope is that we can leverage the work LinApple has started.
• SDL2 tries to be as thin as possible -- I love their minimalism philosophy.
• MAME uses SDL2 so we know that it is more then capable.

The problem with frameworks is that they work great for getting something up and running but as soon as you try to do something outside their design they become a hindrance. I can guarantee we won't have that problem with SDL2 due to its design philosophy of being a thin veneer -- I can't say the same for Qt. Is it possible Qt could meet our needs? Potentially. Can I guarantee that with Qt? Nope.

What UI frameworks are other emulators using? SDL? Qt? Their own?

Emulators that we should be looking at include:

• Gameboy (mGBA) -- ?
• PSX -- ?
• Dreamcast -- ?
• C64

We already know these ones:

• MAME -- uses SDL
• Atari800macx -- uses SDL -- I'm actually using emulator to port an Atari game over to the Apple world and like it.

Yes, sadly the debugger is pretty integrated with Win32, so I don't blame LinApple in any fashion for dropping it. Sheldon's NTSC port dropped it too -- that's a sign it needs to be cleaned up and made more portable.

In an ideal world we would have both SDL and Qt versions -- that would provide an apple-to-apples comparison.

I don't speak for the rest of the team but my vote is:

• Qt -- Hell, no.
• SDL -- Most definitely!

Those are my thoughts.

[sicklittlemonkey]

Yes, sadly the debugger is pretty integrated with Win32, so I don't blame LinApple in any fashion for dropping it. Sheldon's NTSC port dropped it too -- that's a sign it needs to be cleaned up and made more portable.

It would be great to abstract this to an interface get/set memory/softswitch/register/breakpoint etc. We could have a separate debugger (process) Window. Cheers, Nick.

[sicklittlemonkey]

Re Qt etc, what about: https://www.wxwidgets.org/ http://www.fltk.org/index.php They supposedly both support OpenGL. Cheers, Nick.

[ryanmusante]

Is this thread still open for discussion?

DXVK is a compatibility layer for Linux that translates Direct3D calls to Vulkan. Is there a way of implementing something similar for AppleWin? DXVK requires MinGW for compiler support yet it is multi platform.

AppleWin could run inside a compatiblity layer as a workaround until or if there was native support for it to function multi platform.

[audetto]

Hi,

when I opened the issue, I had in mind a real native portable application that could work on a Pi as well.

I still keep the fork updated (except the video code which I never fully understood, it is similar to linapple).

Andrea

[abcbarryn]

Is this still up to date? I was going to try and build a Mac .app package using this code.

[tomcw]

@audetto said:

when I opened the issue, I had in mind a real native portable application that could work on a Pi as well.

From csa2, "Alternatives to Ciderpress", this comment:

I just checked again and I tried installing WINE on my Raspberry Pi 4 with no x86 emulator. It works!

It'd be interesting to try AppleWin on Wine on a RPi4.

[tomcw]

@abcbarryn:

Is this still up to date? I was going to try and build a Mac .app package using this code.

I don't know - can anyone else comment?

[audetto]

Is this still up to date? I was going to try and build a Mac .app package using this code.

I've just updated it to the current master from AppleWin.

Same caveats apply: video rendering is naive and there is no audio as of now.

[abcbarryn]

Darn! No audio eh? I may have to play with it anyway though I'll probably keep using the regular copy via Wine for now. Thanks for your efforts. Maybe I can get the audio working, who knows...

[audetto]

To be honest, audio is easy

https://github.com/audetto/AppleWin/tree/audio

(this is an out of date branch implementing audio).

Problem is the reliability, I struggled to understand exactly when QT needs / accepts more samples, so it can drift...

I need to write an exact model for it and resuscitate it.

[audetto]

@abcbarryn there is audio now.
It is in the branch audio2. I am happy with it. Unfortunately I cannot do better than the quality of qt timers.
Unless you resize the main window, it works well and tries to automatically recover from under-runs.

A quick questions to AppleWin users: what is a good title that plays a lot of music, so I can test a bit better (been using karateka so far).
And I wanted to see if Mockingboard can be supported too: what is a good title using it?

[tomcw]

A quick questions to AppleWin users: what is a good title that plays a lot of music, so I can test a bit better (been using karateka so far).
And I wanted to see if Mockingboard can be supported too: what is a good title using it?

Are you aware of the AppleWin-Test project, here?

You can use this to run the same tests I use before releasing AppleWin, and it includes speaker and Mockingboard tests.

Specifically (but far from complete coverage):

• speaker: Archon (archon_i.aws.yaml) and PoP (Prince of Persia.aws.yaml)
• Mockingboard: Cybernoid (Cybernoid*.aws.yaml)
• Phasor: phasor-fugue.aws.yaml
• Phasor speech: phasor-speech.aws.yaml

[audetto]

Perfect, I will try them.

[audetto]

Another milestone in the Linux port.

The AppleWin's NTSC code is now executed natively, which means all the video update are exactly the same.

On one hand it fells great, on the other it feels that at some point I will have reused enough of AppleWin that it will be just AppleWin, except it does not run in wine...

Anyway as long as it is fun it will last...

One thing to note is the CPU consumption

• wine AppleWin.exe: 50%
• qapple (same screen size): 20%
  • of which negligible is the framebuffer blit time
• AppleWin (on a different PC Windows 7), about 5%, if not less

Basically the code emulator is just running AppleWin code. So either my Win 7 PC is just 4x faster or Visual Studio does a fantastic job as optimising the NTSC code.

What is your experience?

How do you measure the speed of AW?

[tomcw]

The real Phasor has jumpers to select: Mockingboard, Echo+ or Phasor(native).
So when the jumpers select Mockingboard then it'll look like like a Mockingboard.

If the jumpers select Phasor(native), then at power-on (or after a reset) it will appear like a Mockingboard, but I/O at $C0Cn (for slot-4) is active, and can be used to software-select one of the 3 card modes.

This "Phasor(native)" jumper setting is what AppleWin has hardcoded for the Phasor card.

So with a Phasor card in slot-4, then:

• on power-on/reset it'll appear to be in Mockingboard mode.
• but $C0Cn can be used to software-select Phasor mode.
• if you boot the Phasor1.dsk it will try to software-select ($C0Cn) Phasor mode; then it'll check it has switched to Phasor mode.
• if you have Mockingboard inserted then this check will fail, and you'll get the error message you saw.

The advantage of this "Phasor(native)" setting is that for all Mockingboard titles/games they'll work correctly.
But additionally you could switch to Phasor mode, and get the benefit of that too.

So why have a jumper setting for Mockingboard mode? Well (in "Phasor(native)" setting) I guess some poorly written software may accidently touch the $C0Cn I/O addresses to select Phasor or Echo+, and then it may not work. So you need some way to always force Mockingboard mode. NB. I don't know of any such poorly written software!

[rmacri]

Its great reading the progress on this. Audio on Linux can be tricky (I was involved in writing an ALSA driver for an 8 channel sound card some 12 years ago). I was wondering if the Linux AppleWin port is going to get the S.A.M. / 8 bit DAC support? Its relatively straightforward as it piggy-backs on the Apple speaker code. Can't wait to try Drum8 on it if it does. Riccardo

…

On 7/07/2020 10:48 pm, TomCh wrote: The real Phasor has jumpers to select: Mockingboard, Echo+ or Phasor(native). So when the jumpers select Mockingboard then it'll look like like a Mockingboard. If the jumpers select Phasor(native), then at power-on (or after a reset) it will appear like a Mockingboard, but I/O at $C0Cn (for slot-4) is active, and can be used to software-select one of the 3 card modes. This "Phasor(native)" jumper setting is what AppleWin has hardcoded for the Phasor card. So with a Phasor card in slot-4, then: * on power-on/reset it'll appear to be in Mockingboard mode. * but $C0Cn can be used to software-select Phasor mode. * if you boot the Phasor1.dsk it will try to software-select ($C0Cn) Phasor mode; then it'll check it has switched to Phasor mode. * if you have Mockingboard inserted then this check will fail, and you'll get the error message you saw. The advantage of this "Phasor(native)" setting is that for all Mockingboard titles/games they'll work correctly. But additionally you could switch to Phasor mode, and get the benefit of that too. So why have a jumper setting for Mockingboard mode? Well (in "Phasor(native)" setting) I guess some poorly written software may accidently touch the $C0Cn I/O addresses to select Phasor or Echo+, and then it may not work. So you need some way to always force Mockingboard mode. NB. I don't know of any such poorly written software! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#538 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXAGRQJ4RL3O433TPVKOLDR2MKSHANCNFSM4EQEC4PQ>.

[audetto]

It is done now.
You can play the SAM Demo disk.

[audetto]

I have an update that I'm working on in another branch (https://github.com/AppleWin/AppleWin/tree/Improve-SSI263-new), which removes this other thread, and just plays back the SSI263 phonemes in a ring buffer (so same as Speaker and Mockingboard).

So it's probably a waste of your time trying to make the current "one-shot" SSI263 playback work, if ultimately I'm going to move to a ring-buffer (which I fully intend to do).

I will complete my testing of this other branch, then (all going well) I'll merge it into master.

I was wondering if this branch is still alive and will be merged one day?

[tomcw]

Thanks for the prompt... yes, it's still in good shape. Since you are asking about it, then I will give it higher priority and take a look very soon.

[audetto]

Great, I saw some action around phonemes recently and I remembered I never managed to make it work.

[tomcw]

I have an update that I'm working on in another branch (https://github.com/AppleWin/AppleWin/tree/Improve-SSI263-new), which removes this other thread, and just plays back the SSI263 phonemes in a ring buffer (so same as Speaker and Mockingboard).

Now merged to master: 96bbc0c

[audetto]

Now merged to master: 96bbc0c

That was easy. Works out of the box. Thank you.

[audetto]

There was something I always wanted to understand related to audio.
It is the role of nNumSamplesError

The way it works in the Speaker vs Mockingboard seems different

In the former the number eventually leaks out to CpuExecution https://github.com/AppleWin/AppleWin/blob/master/source/Windows/AppleWin.cpp#L203 and be handled there.

Mockingboard seems to deal about it internally without the CpuExecution to know anything about it.

https://github.com/AppleWin/AppleWin/blob/master/source/Mockingboard.cpp#L862

SSI263 seems to be similar to the Mockingboard: https://github.com/AppleWin/AppleWin/blob/master/source/SSI263.cpp#L491

Overall it does a pretty good job at keeping the audio aligned with the Cpu and the real time. And even if I change the emulator speed I still get something good.

Due to the way I had to reimplement the Windows audio interface (and use different timers), sometimes I get glitches, and I was trying to understand how the whole thing works to locate the source of potential buffer over / under runs.

[rmacri]

I know it will be better explained but I'll have a go as I remember from a few years ago when I added the S.A.M. DAC support. PC's deal with sound with a fixed clock (eg: 44100) whereas on the Apple the 6502 could toggle the speaker at any arbitrary rate. For tones/music to sound right and not warbly, the PC audio sample clock drives the 6502 emulation speed. For lower frequencies like beeps, the emulation could be simplistic and just use careful 6502 instruction clock timing to pace the emulator, putting the current speaker state into the audio ring buffer 44100 times a second. However many games and music apps like MCS used high speed speaker toggling to achieve PWM and mix multiple tones. These rates do not match the sampling interval we get to put samples into the PC sound buffer. So the emulator tracks the error between the audio sample clock and the emulated time, using this to interpolate the position the speaker cone would be at at those PC audio sample instants. Eventually the error builds up to a point where it can feed back into pacing the 6502 emulator. So PWM audio sounds great, I'm so impressed with AppleWin doing this. This level of emulation isn't needed for the Mockingboard since its tone generators are independent and the PC sample clock is plenty fast for any changes or transitions made to the tones by the 6502. Hope this helps.

[audetto]

It indeed does a good job.
Even if the emulator runs a bit slower or a bit faster than the exact real speed, the audio does not drift ahead or back. It seems to me.

In Linux, there is an extra buffer between the system audio and AW (i.e. my reimplementation of IDirectSoundBuffer), then I run 1 frame at a time (e.g. OpenGL vsync): overall some (rare) glitches every now and then occur.

What I wanted to do is to add an optional extra n ms of latency to avoid under-runs (obviously at a cost of a bit more latency), but have not succeeded yet. AW eats it immediately and goes back to "normal". Which in one way, is exactly what it is supposed to do :-)

[audetto]

I'm currently updating the ring-buffer when a 6522 IRQ occurs, so typically at 60Hz, which is 16.666ms. This is not quick enough to maintain the write cursor ahead of the play cursor. Why am I doing it here? Probably a legacy reason, as in the IRQ handler the AY-3-8913 registers would be updated (so doing it beforehand was a guaranteed time to do it when they weren't changing)... as I said, a legacy reason!

I think with some refactoring of the code, I should be able to drop dwByteOffset; and as you say, get the Windows API to do the bookkeeping.

Hi, I was looking at some audio issues recently in SDL - Linux and stumbled again on this.
Would it be simpler if Windows took care of the write cursor using DSBLOCK_FROMWRITECURSOR?

[sicklittlemonkey]

@audetto Congrats on an amazing quality and volume of work over 4 years!
Is your master branch the latest? Any conclusions about Qt vs SDL etc?

I finally upgraded my laptop to Windows 11 so I can play with WSL2 graphics support:

[audetto]

These days I prefer sa2 which offer better performance and a few goodies: more options, debugger and tape input.

Got to find a decent name...

[sicklittlemonkey]

sapple2 ->
saddle2 :D

[sicklittlemonkey]

Unfortunately I can't seem to run sa2 on WSL:

SDL: 3 drivers
 0: opengl
 1: opengles2
 2: software
Active driver (-1): opengl
 SDL_RENDERER_SOFTWARE: 0
 SDL_RENDERER_ACCELERATED: 1
 SDL_RENDERER_PRESENTVSYNC: 0
 SDL_RENDERER_TARGETTEXTURE: 1
Supported pixel formats:
 SDL_PIXELFORMAT_ARGB8888
 SDL_PIXELFORMAT_ABGR8888
 SDL_PIXELFORMAT_RGB888
 SDL_PIXELFORMAT_BGR888
 SDL_PIXELFORMAT_YV12
 SDL_PIXELFORMAT_IYUV
 SDL_PIXELFORMAT_NV12
 SDL_PIXELFORMAT_NV21
Selected format: SDL_PIXELFORMAT_ARGB8888
That operation is not supported

Can that final error be made any more specific?

[audetto]

Try now, the error is more informative.
If it is about SDL_GL_SetSwapInterval, then the open gl driver does not support vertical sync.

You can still run is with --gl-swap 0, but it will use more resources.

[sicklittlemonkey]

Oops, not all subprojects were up-to-date, and I was running an old (one year ago!) version of sa2.
That's why above you see the old version's output, including perhaps what you suspected:

SDL_RENDERER_PRESENTVSYNC: 0

I just rebuilt everything, and the new version confirms what you suspected:

IMGUI_VERSION: 1.88 WIP
GL_VENDOR: Mesa/X.org
GL_RENDERER: llvmpipe (LLVM 12.0.0, 256 bits)
GL_VERSION: OpenGL ES 3.2 Mesa 21.2.6
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.20
Default GL swap interval: 0
[DSInit] PC=00000000, WC=00000000, Diff=00000000
SDL_GL_SetSwapInterval: That operation is not supported

But the switch worked, thanks!
Hopefully I will show this to the guys at QFest tomorrow.
The sound lag is almost 2 seconds though, whereas qapple wasn't too bad.
Is there no option to tweak the lag like qapple? I will test on a real PC.

Cheers,
Nick.

[audetto]

Great.
I need to make the font resizable.

Re audio. I know. I don't think the qt audio works that well either.

I need to spend some time to see exactly what happens, but sdl does not seem to have the concept of an audio ubffer which AW uses to adapt the speed. And I need to simplify as well AW usage of the windows circular audio buffer.

And, since we have a use case, play audio from the cassette tape!

[Michaelangel007]

Nice work!

For the three branch indicators you can use ^, =, or v. Or the native Apple mouse font glyphs 0x0B, 0x08, 0x0A.
See g_sConfigBranchIndicatorUp

The bookmark indicators use their own glyphs: Numbers with a box around them. Unicode sadly has half-baked support for this. See Debug Font.bmp

[audetto]

The linux build is working and mature. Work on merging to this repo should probably go to a new Issue.

[tomcw]

OK - feel free to create a new issue as and when it suits you..

[ryanmusante]

Is this port for Linux available on AUR?

[audetto]

https://aur.archlinux.org/packages/applewin-git

This looks good, but I cannot test it.