-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux, AppleWin & Qt #538
Comments
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. |
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>
.
|
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.
|
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.
They could be split into multiple commits if there is an interest in integrating them. Andrea |
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
I think it's OK to just put all the commits into a single pull-request. Thanks. |
I will make a pull request for the changes. My thoughts about this exercise so far are
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 |
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 |
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. |
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! |
Please give it a try. Probably the single most annoying thing is missing audio. |
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:
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 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 I think the first order of business would be to make a pass over the all the Win32 types: I really like the idea of your own 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? |
About Qt vs SDL, I still believe a hard choice is not required. 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. 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 |
Regarding this thought:
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. |
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.
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 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:
Going with SDL2 has a few benefits:
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:
We already know these ones:
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:
Those are my thoughts. |
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.
|
Re Qt etc, what about:
https://www.wxwidgets.org/
http://www.fltk.org/index.php
They supposedly both support OpenGL.
Cheers,
Nick.
|
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. |
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 |
Is this still up to date? I was going to try and build a Mac .app package using this code. |
@audetto said:
From csa2, "Alternatives to Ciderpress", this comment:
It'd be interesting to try AppleWin on Wine on a RPi4. |
I don't know - can anyone else comment? |
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. |
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... |
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. |
@abcbarryn there is audio now. 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). |
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):
|
Perfect, I will try them. |
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
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? |
The real Phasor has jumpers to select: Mockingboard, Echo+ or Phasor(native). 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:
The advantage of this "Phasor(native)" setting is that for all Mockingboard titles/games they'll work correctly. 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! |
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>.
|
It is done now. |
I was wondering if this branch is still alive and will be merged one day? |
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. |
Great, I saw some action around phonemes recently and I remembered I never managed to make it work. |
Now merged to master: 96bbc0c |
That was easy. Works out of the box. Thank you. |
There was something I always wanted to understand related to audio. 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. |
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.
|
It indeed does a good job. In Linux, there is an extra buffer between the system audio and AW (i.e. my reimplementation of What I wanted to do is to add an optional extra |
Hi, I was looking at some audio issues recently in SDL - Linux and stumbled again on this. |
@audetto Congrats on an amazing quality and volume of work over 4 years! I finally upgraded my laptop to Windows 11 so I can play with WSL2 graphics support: |
These days I prefer Got to find a decent name... |
sapple2 -> |
Unfortunately I can't seem to run sa2 on WSL:
Can that final error be made any more specific? |
Try now, the error is more informative. You can still run is with |
Oops, not all subprojects were up-to-date, and I was running an old (one year ago!) version of sa2.
I just rebuilt everything, and the new version confirms what you suspected:
But the switch worked, thanks! Cheers, |
Great. 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! |
Nice work! For the three branch indicators you can use 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 |
The linux build is working and mature. Work on merging to this repo should probably go to a new Issue. |
OK - feel free to create a new issue as and when it suits you.. |
Is this port for Linux available on AUR? |
https://aur.archlinux.org/packages/applewin-git This looks good, but I cannot test it. |
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.
The text was updated successfully, but these errors were encountered: