rickyzhang wrote:
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.
Any user that feels comfortable taking text output and running it on the command line can probably manage creating their own disk images. The idea with a UI is to do all that for them, which we should be able to do using zip.js or node.js. We could even roll in a basic perl or python interpreter (or LUA), that can use its sys library to generate and place a null file without user interaction.
Or we could just go the UME route, and leave it to platform-dependent front ends, and integrate only the configuration into an SDL interface, with command line flags to set things that way as well from the front end UI.
Guys, before we discuss the implementation details.
Should we go for
a. HTML
b. maintain GTK
c. do something more fancy as DLudwig255 suggests
Besides the direction, what's more important is to find someone actually who are able to and willing to commit.
Although HTML looks easy, I have zero experience in writing a HTML form that can save a file locally (without server download). It is quite different from write a PHP from server and generate a dynamic HTML to client.
There is an App for that!
https://github.com/rickyzhang82
I've always avoided GTK when possible, even on GNOME WM. HTML5 has the benefit that it will likely stay the same for years to come and present native widgets on all platforms. node.js makes the job much easier, as it handles all the file management and presents a simple C-like interface.
That said, I'm not going to be able to commit to either developing it nor maintaining it, just providing guidance, so it's probably best to go with whatever solution is preferred by whomever is willing to do that.
Pre-release 7 is now out. To note, I've changed how I name the Git/Github tags for these, and now prefix them with "SDL2-".
Here's what's new:
MacOSX: enabled VOSF
performance tweaks (in SDL2 texture and surface management code)
fixed multiple mouse-grabbing bugs
added an "sdlrender" preference, which can force the use of a specific, SDL2, rendering backend, such as "software" or "opengl". Setting to nothing, or to "auto", will let SDL2 choose.
lots of Autotools fixes, including the ability to use either SDL1 or SDL2. SDL2 will be used, if both are available. To force the use of SDL1, pass --with-sdl1 to the configure script.
@DLudwig255, thank you again for this work. I downloaded your code and finally figured out that I needed to include SDL2 in the "External" folder, and was able to build successfully under High Sierra.
One question: as far as I can tell, the --config <filename> option doesn't seem to work, at least not for me. I have a self-contained BasiliskII setup that uses a bash script to launch the executable with a --config parameter. When I copy your unix executable into that setup, it launches, but it opens the disk (and the other configurations) from the hidden prefs file in my user folder, not the prefs file specified in the bash script.
Am I doing something wrong here? Or is there an easy fix in your code?
Thanks for this build ! I love the way it's possible to have it running fullscreen on a OS X space of is own.
Is network implemented ? Also it doesn't seems to like foreign keyboards (French here), even though my .basilisk_ii_prefs file point to the keycode file.
I need to chime-in as well: Great work, thank you!
Do you intent to also integrate optional TUN/TAP functionality on the network side?
Would be great to be able to connect to external AppleShares and capable printers.
Let me know if you need helping hands on the testing side. J
I cannot make it boot, not even to the blinking floppy disk screen. It just opens a blank screen, and it closes.
Here are the contents of the log file:
Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using SDL/directsound audio output
Using SDL_Renderer driver: direct3d
FATAL: EMUL_OP called with bogus opcode 00005243
d0 000001ba d1 000068b8 d2 00000000 d3 0005001a
d4 00000000 d5 00000000 d6 00000000 d7 00000202
a0 00803378 a1 00803760 a2 fdc78000 a3 008b34ce
a4 00809ae6 a5 008b35a2 a6 008b358c a7 0017ff7e
sr 2708
What is the problem? Is it my ROM, or i am not noticing of something obvious? Also, i think that a readme explaining the contents of the prefs file would be nice. I am having a hard time figuring everything out!
I am finding that since the macOS 10.13.3 update, if the "Unix" shared folder is enabled, Basilisk II crashes during boot. If I turn that feature off, everything works. So perhaps you should try disabling the shared folder and see if that solves your issue.
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.
adespoton wrote:I've seen a number of similar reports to that -- I wonder if BII doesn't like APFS or is taking some sort of shortcut that APFS doesn't understand?
afpfs-ng-OSX could be used as workaround here. I therefore chose "General Macintosh Emulation" as the category to place a related poll: viewtopic.php?f=1&t=9588.
adespoton wrote:I've seen a number of similar reports to that -- I wonder if BII doesn't like APFS or is taking some sort of shortcut that APFS doesn't understand?
afpfs-ng-OSX could be used as workaround here. I therefore chose "General Macintosh Emulation" as the category to place a related poll: viewtopic.php?f=1&t=9588.
adespoton is talking about APFS, not AFS, for the Unix share.
The nice thing about it, assuming attributes transfer and resource fork handling can be sorted out, is that it's emulator-agnostic. So it'll work everywhere that supports TCP/IP. Unfortunately, this doesn't include Mini vMac which only supports LocalTalk. But hey... maybe Paul could do something to provide AFP support via the app instead of setting up an entire SLiRP stack
adespoton wrote:... So it'll work everywhere that supports TCP/IP. Unfortunately, this doesn't include Mini vMac which only supports LocalTalk. But hey... maybe Paul could do something to provide AFP support via the app instead of setting up an entire SLiRP stack
Or hope for MaddTheSane to get CAP working at some point in the future. He forked it and it seems he made the libs compile earlier this month: https://github.com/MaddTheSane/CAP/tree/madds.
adespoton wrote:I've seen a number of similar reports to that -- I wonder if BII doesn't like APFS or is taking some sort of shortcut that APFS doesn't understand?
I don't think it's APFS, since it was working with me with APFS earlier. It started crashing at about the time I installed the 10.13.3 update, although I don't know whether that's correlation or causation.
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.