Hi everyone,

Just joined the site, very cool site.

I used to use ShapeShifter on my Amiga 3000 back in the day so am familiar with the work of Christian Bauer, very talented.

I just started emulating vintage Macs on OS X/macOS recently with Basilisk II and SheepShaver, and so far so good, colour being the biggest change since my black and white 68030 native A3000.

One of the frustrations I had with Basilisk II is the non native GUI for OS X. It doesn't always let you click the button and I can't say I'm a fan of X11 interfaces on Macs.

As such about a week or so ago I started writing a new GUI following along the lines of the existing GUI in Xcode Swift. I've just finished the first beta version and was wondering if anyone wanted to test it?

My aim is to include the possibility of presets in the interface so that you don't have to reconfigure it each time to use System 7 or Mac OS 8 or different CPUs, RAM, ROM etc.

At the moment it simply does the same as the X11 GUI.

If anyone is interesting in testing it, please let me know and I'll upload a beta. I haven't had much time to test it myself but it seems to work. And unfortunately I won't have much time to work on it in the next week. It's written from the ground up in Cocoa/Swift. Not sure how backwards compatible it is with earlier versions of OS X, it's written in Xcode 10 for High Sierra, but have not locked it to that OS.

Cheers and happy emulating!

Certainly interested in testing. Not sure yet about the presets.

Hi Ronald, thanks, ironing out some last minute bugs, will upload soon!

Here's a screenshot...



Still a bit of debugging to do...

Looks promising.

Thanks!

You can find a beta version here:

<download link removed>

It has not been heavily tested.

Appreciate any feedback.

Cheers!

Oh, one more thing, you need to copy your .basilisk_ii_prefs file to .basilisk_ii_prefs_test

Since I've already spent years fine tuning presets for each OS version for my single runtime shells, I'm not likely to use an external GUI, but if you need any help with appropriate presets, let me know. There's a few things like needing the extra file sharing extension for 7.1 in order to use the shared folder that would be nice to put as tips in the GUI as well (so if you select 7.1 as your target, you get some extra instructions on in-OS configuration that may be needed if you select a shared folder).

I had a quick look. It does look promising but there are still many issues. Next weekend I will have time for more detailed comments.

Hi adespoton,

Yeah I only just read about your runtime shells after I'd finished rewriting the GUI. I might have gone down that road instead of writing 1000+ lines of code lol.

Thanks for the tip!

Hi Ronald,

Yeah I'm aware of a few issues. Sometimes the textfields won't display the prefs contents after a reload, but that seems to be hit and miss.

Main issues I've noticed is I haven't yet converted a new user entry into RAM size back into bytes and haven't implemented the FPU option. Also choosing Maximum for window size returns 0 when you reload. Will fix all these when I have more time.

Look forward to your comments.

Well, I found many more issues. I will report them here later, hopefully tomorrow.

Thanks Ronald, appreciate your help!

Here are some first experiences with your GUI application.
I tested it in High Sierra, I put your GUI in the folder where the BasiliskII application and the old GUI reside, and I started with copying my existing ~/.basilisk_ii_prefs to ~/.basilisk_ii_prefs_test.

1. Closing the window does not quit the application
I am used to dismiss such one-window applications by clicking the red button. Most such applications will then quit. Your GUI app continues running when its window is closed with no way to bring the window back.

2. Lines in the prefs file are duplicated
Saving a change in the GUI should only change the related line in the prefs file or replace the content with the new settings, but often lines are duplicated or even all lines are duplicated as if the new settings are appended to the existing ones. After only a few changes in the settings my prefs file had grown and looked like this: http://ronaldpr.home.xs4all.nl/basilisk ... ntries.txt

3. Volumes list, Finder icons
I am not sure why you use Finder icons before each volume in the list, regardless what kind of volume it is. It seems to indicate a compatible startup volume, but it is used for any volume.

4. Volumes list, "Kind"
There is a column "Kind" that indicates that the volume is a disk image. Isn't that superfluous information? Aren't all volumes in the list disk images?

5. Volumes list, "Not Found"
If a volume is not found, this is displayed in the Kind column. That is useful information, but the further implementation is problematic:

6. Files not found will be removed
When settings are saved, files that are not found will be removed from prefs.

For me that is a problem. I am in the habit of moving files out of the way in the hosts Finder when I do not need them and move them back when I need them, That way I can choose which disk images will be mounted in BasiliskII without the need to change settings. I do not know if many other users handle disk images with BasiliskII or SheepShaver the same way. Both applications will simply ignore incorrect paths to disk images.

Another problem for me is that I often use relative paths (file names only) for files that are in the same folder as the BasiliskII application. Those will also be removed when I save changed settings. The old GUI does not change such entries.

7. Incorrect removal of not found disk images
When not found disk images are removed from the prefs file, only the path is removed. The "disk" entry remains, causing persistent "Not Found" volumes in the list. The whole line should be removed.

8. Incorrect reading and writing of values for CPU type and FPU.
I have not extensively tested this, but I seem to be unable to set all combinations correctly.

These five settings in the GUI
CPU 68020
CPU 68020 with FPU
CPU 68030
CPU 68030 with FPU
CPU 69040

should we written in prefs as:

cpu 2
fpu false

cpu 2
fpu true

cpu 3
fpu false

cpu 3
fpu true

cpu 4
fpu true

9. Does not create a prefs file when none exists
When launched, the GUI app should create a prefs file when none exists. It could be an empty file, but it could also be a file with some default settings. More recent (2011) versions of the old GUI create this file with some preconfigured settings: http://ronaldpr.home.xs4all.nl/basilisk ... refs_1.txt

Personally I would choose other values to be the default for some of these settings but that can be discussed later.

If these settings are copied to ~/.basilisk_ii_prefs, your GUI app will crash at launch. Not sure which lines cause the problem. Maybe it is because items are in a different order.

BasiliskII itself also creates a default prefs file when none exists, but those settings clearly date from years ago. Apparently no one bothered to change those defaults in newer BasiliskII versions: http://ronaldpr.home.xs4all.nl/basilisk ... refs_2.txt

Also with these settings in ~/.basilisk_ii_prefs your GUI app will crash.

10. Miscelaneous
I did not yet try every setting, I did not yet try presets, and I have some thoughts about the interface, but that can be discussed later.

Thanks for going through it!

I won't have time to work on it until next weekend. Will post an update when I have had to time to fix the issues.

Cheers!

Thanks again for testing, have fixed the following:

1. Closing the window does not quit the application
Fixed

2. Lines in the prefs file are duplicated
Fixed

3. Volumes list, Finder icons
Not high priority

4. Volumes list, "Kind"
Not high priority

5. Volumes list, "Not Found"
...

6. Files not found will be removed
Can't duplicate problem

7. Incorrect removal of not found disk images
Can't duplicate problem

8. Incorrect reading and writing of values for CPU type and FPU.
Fixed

9. Does not create a prefs file when none exists
To be implemented

10. Miscelaneous
Have had a better idea than presets, will implement later.

11. Maximum window size
Fixed

12. Memory converting back to bytes
Fixed

Will upload new app to same location shortly.

I will try it when I have time to do it. Again, maybe next weekend.

Hi Ronald,

I've made a few more fixes regarding default prefs files.

It now won't crash with those two example files you uploaded.

Also I've started working on creating a new default if none exists with the following values:

var prefs = ["extfs ", "screen ", "seriala ", "serialb ", "ether ", "udptunnel ", "udpport ", "rom ", "bootdrive ", "bootdriver ", "ramsize ", "frameskip ", "modelid ", "cpu ", "fpu ", "nocdrom ", "nosound ", "noclipconversion ", "nogui ", "jit ", "jitfpu ", "jitdebug ", "jitcachesize ", "jitlazyflush ", "jitinline ", "keyboardtype ", "keycodes ", "keycodefile ", "mousewheelmode ", "mousewheellines ", "dsp ", "mixer ", "ignoresegv ", "idlewait "]
var defaults = ["", "win/640/480", "", "", "slirp", "false", "6066", "", "0", "0", "16777216", "1", "14", "2", "false", "false", "false", "false", "false", "true", "false", "flase", "8192", "true", "true", "5", "true", "", "1", "3", "/dev/dsp", "/dev/mixer", "true", "true"]

Please feel free to edit that as you see fit.

The reason it was crashing was because if it finds a prefs file it assumes that all prefs values will be present. Those two example files were missing some default prefs.

Available here:
<download link removed>

Sorry, I didn't yet try as promised. I will when I have the time to do it.

OK, tried your latest version.

First the issues I noted and that have been fixed:

- Now quits when the window is closed
- I did not see duplicated lines anymore
- Values of CPU type and FPU are now written and read correctly
- When no prefs file exists, it will create one
(However, if saved without changing anything, the resulting prefs file will cause the application to crash.)

Remaining issues:

1. The app crashed on several prefs files I threw at it.
I think that the way it reads the prefs file is fundamentally wrong. Like the old GUI and like BasiliskII itself, it should read the existing settings regardless whether those settings are complete or in which order they are listed. People may have a prefs file that is written by a different application or that is configured manually.
When saving the settings, it can then write te settings back in its own order.

2. If the prefs file contains paths to disk image files that do not exist in that location, that path does not appear in the volumes list and subsequent saving removes the path from the prefs file. The indication "Not found" is useful, but the app should show the path as it is and not remove it without user intervention.

3. A saved path to the Unix Root (extfs) is not read by the app and subsequent saving removes the path from the prefs file.

4. Does not read back all values for refresh rate (frameskip) correctly

5. I can only change RAM sizes choosing from the menu, not when I enter a value manually.

I will save remarks about the interface for later.

A sensible default prefs file could be:



I like the default values for 'extf' and 'rom' that are in one of the latest versions of the old GUI. Maybe you could implement that also:

extfs Put an OS X path here to share it with Basilisk
rom Put the path to your ROM file here

Hi Ronald,

Thanks very much for testing again!

I will let you know when I've completed those fixes.

Cheers!

When this excellent project is done, or even before then, would you be willing to post the source code on GitHub? I've built a copy of BasiliskII that uses a visible file for the prefs (~/BasiliskPrefs.txt), instead of the standard invisible file, and I've patched a copy of the old BasiliskIIGUI to use that visible file. It would be nice to be able to modify your source code so that I could use the same visible file. Thank you for working on this, whatever you decide to do with the source.

Will start working on this again soon, need to transfer from my old Mac mini on High Sierra to my laptop on Mojave to maintain compatibility. Cheers.

Hi Ronald,

Thanks again for testing, really appreciate it.

Sorry, got sidetracked with other projects during the Christmas holidays and then haven't been doing any emulating since then so put the project on hold until now....



I believe I have I fixed all the above mentioned problems except for 2. and 5. I was unable to replicate those problems.

With 2. I have put garbage disk paths into my prefs file and it reads them and saves them and displays them, just saying file not found.

With 5. I can enter any random ram size I want and it will save it and re-read it... so can't duplicate your problem.

With 1. I've completely reworked the way it reads prefs files, checking very carefully each setting and adding your suggested default value if it's missing. And also adding any missing default prefs that are missing. It shouldn't matter what order the prefs file is in since it doesn't expect any particular order it just searches for keyword matches.

I'm sorry to say I have not tested it extensively, but will upload it shortly to the same URL as before.

Cheers!

EDIT: Hold the fort... found some bugs... will update.

EDIT 2: Ok seems to be working again... had to rewrite the method for creating a new prefs file if there wasn't already one.

Hello,

This looks very impressive. Two issues:

1. It doesn't seem to let me add .sparsebundle disk images.

2. When I copied my existing .basilisk_ii_prefs to .basilisk_ii_prefs_test, the new GUI crashed on startup. Maybe that is because my prefs use a .sparsebundle as a disk image? If you want to experiment, here's a copy of the prefs file (without the "." in the filename):

https://www.dropbox.com/s/emkafbmqtrh28 ... s.zip?dl=1

Thank you for your work on this!

Thanks!



Have fixed those issues, thanks for letting me know. The error with the prefs file was to do with keyboard layout... I hadn't added error checking for that since it's nested... anyway fingers crossed not too many more bugs.



You're welcome. As for your previous question about GitHub... not sure yet, but I plan to add an option to choose any prefs file you want, but it will automatically save it with the default "." filename.

New upload available for testing now.