Work in progress by David Ludwig: BasiliskII port to SDL2

[emendelson]

This looks like something of potential interest, still a work in progress, though the pre-release version already works well:

https://github.com/DavidLudwig/macemu/releases

The author sent this note to the BasiliskII mailing list:

Hello!

I've been spending the better part of my afternoon trying to cobble
together a port of Basilisk II to SDL2. I've been able to put together a
somewhat functional port, although there are some bugs.

If anyone is interested in it, I've posted a pre-built Mac OS X binary at
https://github.com/DavidLudwig/macemu/releases

Code for this port is up at https://github.com/DavidLudwig/macemu

Feature-wise, the main thing is probably the support of Mac OS X's "Spaces"
feature. If and when Basilisk II is launched in full-screen mode, it'll
attempt to work with OS X's desktop manager, to create a separate desktop
for Basilisk II. On devices with multi-touch enabled trackpads (MacBooks,
etc.), this allows one to do a multi-finger swipe from an OS X desktop, to
a Basilisk II desktop.

There are new bugs, some of which I am aware of, many of which I probably
am not. I'll see if I can get some of the known ones fixed, when I next
have a free weekend for computer work. I'll attempt to list a few of the
known ones on Github.

Cheers!
-- David Ludwig

[DLudwig255]

Hey, look, I made the news!

I also posted a Windows build, a few days ago, if anyone is interested. They're up at https://github.com/DavidLudwig/macemu/releases

Cheers!
-- David L.

[chris]

Hi

The windows build just shuts down for me - open it, it closes.

Using Windows 10 64b - just dropped you version over my old working one.

[DLudwig255]

Hi

The windows build just shuts down for me - open it, it closes.

Using Windows 10 64b - just dropped you version over my old working one.

I'll see if I can toss in some diagnostic-collecting code in a future release. It probably won't make it in until Prerelease 5 (I just uploaded Prerelease 4).

In the meantime, if you could try the latest release, that'd be helpful. I doubt it'll work though, given that Prerelease 3 did not.

[DLudwig255]

A new release of this port is out: Prerelease 4

Here is what is new:
* fixed issue #1: 2 and 4 bit color modes were not working
* added "idlewait" support, which reduces host CPU usage, and host machine power consumption

Copies of this are available for download at: https://github.com/DavidLudwig/macemu/releases

Bugs do still remain. I will try to list these on my Github page, at https://github.com/DavidLudwig/macemu/issues . New bug reports are welcome, either here, or directly on Github.

[rickyzhang]

A new release of this port is out: Prerelease 4

Here is what is new:
* fixed issue #1: 2 and 4 bit color modes were not working
* added "idlewait" support, which reduces host CPU usage, and host machine power consumption

Copies of this are available for download at: https://github.com/DavidLudwig/macemu/releases

Bugs do still remain. I will try to list these on my Github page, at https://github.com/DavidLudwig/macemu/issues . New bug reports are welcome, either here, or directly on Github.

Great work! I can imagine that you need to handle three different platform (4, if you support PPC as well). This will drive people banana.

I understand that SDL 1.2 may fade out in some time. But I wonder what new features in SDL 2 provides.

[DLudwig255]

Great work! I can imagine that you need to handle three different platform (4, if you support PPC as well). This will drive people banana.

I understand that SDL 1.2 may fade out in some time. But I wonder what new features in SDL 2 provides.

Thanks!

In terms of platform support, I have been focusing primarily on OSX + 64-bit Intel hosts, using the latest, released version of OSX (Sierra). Secondarily, I have been looking at 32 bit Windows. Eventually, I will at least look at Linux on some combination of 32 and/or 64 bite ARM and x86. I might even take a look at Emscripten support, but am unsure of that.

SDL 1 development is, in many ways, dead, in favor of SDL 2. The code is occasionally updated, but very rarely, and from what I have seen, not for 'major' or modern' systems.

SDL 2 does have some nice, new, features, some of which I suspect could be folded into Basilisk II, or SheepShaver for that matter, (audio recording, multiple windows, and updated full screen code being among them), but I doubt that it alone would give much noticeable changes to end user. Forward compatibility of host OSes, I do think it would give.

[Cat_7]

Hi,

Great work! It feels like the Basilisk windows build is really fast.
I found one issue for now:
-the shared drive on a windows host shows up with the name "T" where one would expect the drive being called My Computer.
-Basilisk doesn't read CD roms. I have some source code from the erstwhile developer of Basilisk 142 that allows reading CDs in Windows 64 bit without the need for the 32 bit driver.

I'll send you a PM with a dropbox link to the sources. If you want, you can merge it in.

Best,
Cat_7

[24bit]

Thanks for your work, which I do appreciate much!
I tried your build for OSX on my Sierra Hackintosh, Lenovo T420, 1600X900, SSD.
To me it looks like the screen is flickering both window mode and full screen.

I did run Speedometer out of curiosity, JIT disabled in Ronalds 2014 build.

New SDL build:



Ronalds 2014-03-01 build:



BII´s cpu performance looks a bit low, but not bad for work in progress.
Speed will be a smaller issue, as modern cpus become faster with every generation.
Compatibility is the one to be concerned of.

[rickyzhang]

SDL 2 does have some nice, new, features, some of which I suspect could be folded into Basilisk II, or SheepShaver for that matter, (audio recording, multiple windows, and updated full screen code being among them), but I doubt that it alone would give much noticeable changes to end user. Forward compatibility of host OSes, I do think it would give.

One thing I come up in my head is that support hi-res screen. I'm not an expert in UI. But I think if we can zoom 2x in SDL drawing, that can solve the problem that Game and font size is way too small in nowadays hardware.

Is this feature available in current BII?

[adespoton]

Two of the three things that I felt were a death knell for BII and SheepShaver were lack of SDL2 support and the need to re-sync against a modern version of WinUAE. Thanks David for tackling the first

I don't think JIT and overall performance are really going to be much of an issue; with the SDL2 build, PR4 seems as fast as BII was on Windows 98 back in the day.

[rickyzhang]

I don't think JIT and overall performance are really going to be much of an issue; with the SDL2 build, PR4 seems as fast as BII was on Windows 98 back in the day.

I agree with you. JIT is not that important any more given current CPU single thread speed. The max of M68k CPU 68060 runs in 75Mhz, while my i7 CPU runs in 3 or 4Ghz in one core. It is 50 times faster. That gives a programmer a good excuse to write more inefficient code.

The difficult part of maintaining BII is keep its software build stack up-to-date. Making it them build and run in Virtual machine like vagrant and docker should save us a lot of time. I'm always amazed at the host OS support matrix of BII. Even a big corporation can't even provide such support like this. It is better focus on one host with fixed build toolchain.

[DLudwig255]

I've made a new, prerelease of the SDL2 port of Basilisk II: Prerelease 5

Here's what's new:

• retain guest OS' aspect ratio. This prevents stretching of the guest Mac's screen. Black bars are drawn on the sides of the screen, if the aspect ratio does not match the host OS' screen.
• experimental, and mainly OSX-only for now: resize-able windows! In windowed mode, windows can be resized. The guest OS' screen will not, however, change, however this can make the window a bit more readable on high-resolution screens. (Issue #21 (fix windows support) and Issue #22 (res-change reverts resize) are to-be-fixed)
• apply anti-aliasing, when scaling the window. This requires that either OpenGL or D3D support be available. If not, anti-aliasing will not be available.
• Win32-only: output diagnostic data (stdout and stderr) to a log file, BasiliskII_log.txt. This file is, currently, placed in the executable's current-working-directory, which'll probably be the same directory that BasiliskII.exe is in.
• bug-fix: 512x384 sized windows could not get created
• lots of internal fixes and updates, mainly relevant for those compiling for Linux
• applied latest changes + bug-fixes from cebix's repository

It's up at: https://github.com/davidludwig/macemu/releases

Issues/bug-reports at: https://github.com/davidludwig/macemu/issues

[rickyzhang]

I tested pre5. I like the scaling function. It works quite well. Thanks for your work! We can come up a better interface how to get scaling up factor and resolution from user later.

But I want to raise another issue that preference native Cocoa UI was completely removed in Mac OS X and also GTK UI was broken through automake build in Mac OS X and Linux. That may be a deal breaker to ask normal user to RTFM to setup manually in ~/.basilisk_ii_prefs file.

I remembered someone started an initiative to renovate UI (in Lua?). But I haven't heard from him any more.

If we do need a preference UI, we'd better find a UI technology that can

• last long enough
  with cross platform capability
  easy to access for current build chain

[DLudwig255]

I have considered re-writing the preference GUI, but would be hesitant to do so until I had reasonably finished the SDL2 port.

Here's what I had in mind, roughly, and none of which is guaranteed to happen, or even be all that good:

• minimize dependencies. If any are introduced, include them in a checkout of the BasiliskII + SheepShaver source, and build them alongside either application.
• integrate GUI code into the emulators themselves. (Is this done already? I am unsure.)
• consider using SDL2 itself to build a gui.
• mostly use an immediate-mode type of GUI api, something akin to https://github.com/ocornut/imgui or https://github.com/vurtun/nuklear. These are relatively simple to implement and work with (in my opinion, at least). They're not perfect by any means, but can be fairly easy to work with, and I think something like this could be accomplished without a monumental amount of work. Utilizing an existing one might make sense too, but would increase the amount of dependencies, potentially in a cascading fashion (lib A requires libs B and C, which require libs D and E, and so on; which I'd like to avoid, if possible).
• For file-dialogs, consider using https://sourceforge.net/projects/tinyfiledialogs/. It's a pretty small dependency, which seems easy to integrate into an app. There's probably not much of a need beyond simple, file-selection dialogs, which makes me think this would work.
• No Lua, probably, at least not at the start. Apologies if there are Lua fans. I like Lua, and have worked with it somewhat extensively, but it would, in my opinion, introduce a non-trivial amount of additional code.

All of this is just thought, at this point. I have no concrete plans to try this, but have considered giving it a shot. If I did, it probably wouldn't happen for a while, though, at least multiple months.

[adespoton]

I've always been a WxPython fan, but TCL/Tk has lasted as a cross-platform GUI for 30 years; WxPython is a newcomer as it only reached platform parity around 20 years ago

WxPython also has the benefit that other than Windows, every OS comes bundled with Python, so the packager just needs to package in the Wx libraries for everything to work. Clickable apps will, of course, need a further step; py2exe for Windows, and the equivalent for OS X (Linux is generally happy with launching from a .pyc file).

We could also use Qt for the front end; since it's commercial and used in for-profit Linux distros, it likely won't be going anywhere any time soon. Not as simple to develop as Tk or Wx, but the widget set and placement tends to look and behave just like the native widgets on each platform.

It would be nice to build the GUI inside SDL2 using its native bindings feature; this will, of course, require more work. Or just do the UME-SDL thing and create an old-school interface right inside the display window.

[rickyzhang]

Being a product manger and talking about exciting features and future plans are always fun things to do. Because there is nothing to commit.

I'd say if we are not going to have new preference UI available by the time we merge SDL2 back to upstream macemu repository, we'd better fix original GTK preference UI.

Some features like create a blank image and setting up parameters provided by preference UI sometimes are considered to be a deal breaker for beginners.

[DLudwig255]

I'd be willing to put in time to investigate why the GTK UI might not compile with the SDL2 port, however, I am hesitant to spend much time redesigning, or significantly augmenting it, beyond, perhaps, tweaking it a bit, say with regards to differences in parameters.

I.e. I might agree with you, although, I am unsure what the definition of "fix" is, here. That seems like it could be interpreted somewhat broadly.

[DLudwig255]

To add, I speak in terms of willingness to spend my own personal time on such. Others are, obviously, welcome to work on whatnot as they please! :-D

[rickyzhang]

@Dludwig255
That's so true. I don't have too much UI front end programming experiences. Otherwise, I will look into the GTK issues. I like your scale up feature in SDL2. I can't wait to merge it to upstream.

I'm thinking about an alternative plan to replace current preference UI. One of the easiest way is to write a HTML5 + a simple JavaScript to handle file operation in local:

• When HTML page loads, check and load the preference file.
  When user finish all the question in HTML form, generate preference file.
  When generate a blank image or start BII emulation, just print out the command and ask user to run it in terminal.

It is easy to do all these in HTML. But the only concern is that web browser change frequently unless we use the standard HTML or javaScript otherwise it may have portable problem.

[uyjulian]

A web-page Javascript configurator is accessible to more people then my Lua-based FLTK configurator (which requires certain libraries/programs to be installed).

The config file format is a simple key-value format, so it should be simple to implement.

[DLudwig255]

I could see an HTML app helping with profile configuration, however, unless it also helps with disk creation, I'm not sure how helpful it would be.

My current thought would be to end up with a desktop/laptop UX that works something like the following:

1. user opens Basilisk II, such as by double-clicking on its icon in Windows, OS X, etc.
2. Basilisk II detects nothing, so it displays something along the lines of this:

3. If and when the user clicks on one of the New buttons, it takes them to a UI, or a set of UIs, that guide them through importing a ROM file, creating a disk, etc.

This is all pretty preliminary, mind you, and IMO, beyond the scope of updating things to use SDL2 (rather than SDL1).

[adespoton]

For disk creation, don't you just need to write out a file of null values of a specific size? We could go the simple route and have a few pre-created zipped null files included at standard sizes -- or even a few zipped pre-formatted empty images. Every platform we're targeting can unzip a file, so the JS would just need to trigger decompression.

Using zip.js, this should be feasible:
https://stackoverflow.com/questions/344 ... t/34439627

Of course, if we include node.js, we can write a null file directly (up to 1023 MB):
https://stackoverflow.com/questions/309 ... cific-size

[DLudwig255]

Precreated images might make sense. I do see a lot of those floating around already, though. The extra importing step(s) do concern me a bit, in terms of UX. A working Basilisk II setup is, as far as I am aware, a set of files, including, at minimum:

1. rom file
2. prefs file
3. disk file(s)

[rickyzhang]

@DLudwig255
I'd suggest you build BII under Linux with gtk. You can take a look of preference UI.

@adespoton
For blank image creation, we can print out a basilisk command with proper option in HTML that ask user to run basilisk binary to create that image.

All we need is to add new options to BII source code that take in size parameter and surface image creation in command line.