Though I didn’t go quite that far, I did end up something that is quite flexible: What I effectively wanted was a Dockerfile I could use to build a disk image out of a base OS and a set of programs. While I could just boot the native version of Basilisk II and manually copy things over, if I made any mistakes, or wanted to repeat the process with a different base OS, I would have to repeat everything, which would be tedious and error-prone.
#Basilisk ii bin cue software#
I wanted to have a sustainable and repeatable way of building a disk image with lots of Mac software installed. Building Disk Images, or Docker 1995-style There is also basic prefetching support, so that sequential reads are less likely to be blocked on the network.Īlong with some old fashioned web optimizations, this makes the emulator show the Mac’s boot screen in a second, and be fully booted in 3 seconds, even with a cold HTTP cache. Using content addressing makes the large number of identical chunks from the empty portion of the disk map to the same URL. Manually chunking (as opposed to HTTP range requests) allows each chunk to be Brotli-compressed (ranges technically support compression too, but it’s lacking in the real world). Filesystem requests from Emscripten are intercepted, and when they involve a chunk that has not been loaded yet, they are sent off to a service worker who will load the chunk over the network. After some false starts, I settled on an approach where the disk image is broken up into fixed-size content-addressed 256K chunks. However, it seemed like this goal was fundamentally incompatible with the other goal of putting as much software as possible onto it - the more software there was, the bigger the required disk image.Īt this point I switched my approach to downloading pieces of the disk image on demand, instead of all upfront. There was some low-hanging fruit, like actually compressing it (ideally with Brotli), and dropping some unused data from it. Streaming Storage and Startup TimeThe first thing that I looked into was reducing the time spent downloading the disk image that the emulator uses. I wondered what it would take to extend the Basilisk II support to have a macintosh.js-like experience in the browser, and ideally go beyond it.
#Basilisk ii bin cue download#
However, it’s an Electron app, and it feels wrong to download a ~250MB binary and dedicate 1 CPU core to running something that was meant to be in a browser. macintosh.js comes closest to that - it packages James’s Basilisk II port with a large (~600MB) disk image and provides a way of sharing files with the host. They’re great for quickly launching a single program and playing around with it, but they don’t have any persistence, way of getting data in or out of it, or running multiple programs at once. However, none of these setups replicated the true feel of using a computer in the 90s. The Macintosh Repository is experimenting with in-browser emulation via either Basilisk II or vMac.RetroWeb Vintage Computer Musem, also based on James’s PCE.js work.OldWeb.Today, which extends James’s Basilisk II work to support a working networking stack.The Internet Archive’s Mac Emulation, which is partly based on James’s PCE.js work.James Friend’s in-browser ports of the Basilisk II and PCE.js emulators.Some research into browser-based alternatives uncovered a few options: As far as I could tell, that was still the state of the art, at least if you were targeting late era 68K Mac emulation. I had earlier experimented with Basilisk II, which worked well enough, but it was rather annoying to set up, as far as gathering a ROM, a boot image, messing with configuration files, etc. My heritage being of the classic Mac line, I was curious what the easiest to use emulation option was in the modern era. Projects like v86 make it easy to run your chosen old operating system in the browser.
Between increasing CPU power, WebAssembly, and retrocomputing being so popular The New York Times is covering it, it’s never been easier to relive your 80s/90s/2000s nostalgia.
0 kommentar(er)
