Don't pre-allocate a 1GB array for the disk image

[mike2fs]

Using Chrome on Samsung Chromebook Plus ( described below) the initialisation text appears, but gets stuck at the 4/4 point. Tried rebooting Chromebook, but issue still occurred. Tried using Firefox for Android, and app worked OK,but dragging files from outside of the window did not load into the emulator download folder, so I don't currently have a useful work-around.

I can debug/test fixes is required.

Chromebook version details:

100.0.4896.133 (Official Build) (32-bit)

Revision | a02d6b77a0bc7f483260d4f8ff911e32b3944bea-refs/branch-heads/4896@{#1129} Platform | 14526.89.0 (Official Build) stable-channel kevin Firmware Version | Google_Kevin.8785.334.0 Customization ID | SAMSUNG-KEVIN1 ARC | 8414072 JavaScript | V8 10.0.139.15 User Agent | Mozilla/5.0 (X11; CrOS aarch64 14526.89.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.133 Safari/537.36

[mihaip]

Does the Chrome console (View -> Developer -> JavaScript Console) show any errors?

[mike2fs]

Here is the console log: system7.app-1652731570045.log

[mihaip]

It looks like the relevant error is:

emulator-worker-chunked-file.ts:11 Uncaught (in promise) RangeError: Invalid typed array length: 1073741824
    at new Uint8Array (<anonymous>)
    at J (emulator-worker-chunked-file.ts:11:22)
    at n.preRun (emulator-worker.ts:334:21)
    at callRuntimeCallbacks (5e9aa57f-4754-403b-8158-ace19b695efd:1462:11)
    at preRun (5e9aa57f-4754-403b-8158-ace19b695efd:1115:3)
    at run (5e9aa57f-4754-403b-8158-ace19b695efd:7896:3)
    at runCaller (5e9aa57f-4754-403b-8158-ace19b695efd:7852:19)
    at removeRunDependency (5e9aa57f-4754-403b-8158-ace19b695efd:1222:7)
    at receiveInstance (5e9aa57f-4754-403b-8158-ace19b695efd:1362:5)
    at receiveInstantiationResult (5e9aa57f-4754-403b-8158-ace19b695efd:1373:5)
J @ emulator-worker-chunked-file.ts:11

This is caused by code that tries to pre-allocate a 1GB Uint8Array for the Infinite HD disk image. On 32-bit systems the maximum length is smaller (though based on the source it should be ~2GB).

There may be an alternate file system we can use (WORKERFS) which does not require the contents of the file to be copied into memory, it will need additional investigation.

[mihaip]

Fixing this would also allow the boot disk image to be larger (at least for Mac OS 9, 100MB is very tight).

One alternate idea is to bypass the Emscripten Unix file system compatibility layer, and instead more directly go from emulator disk reads/writes to the chunked file system. That would remove the need to preallocate an array the size of the disk.

In Basilisk II (and presumably SheepShaver) this should be doable by registering a new disk factory in sys_unix.cpp. Then a disk_generic subclass can be implementing that turns the read and write methods into to workerApi.* JS calls.

In the case of Mini vMac it can be done by modifying vSonyTransfer at https://github.com/mihaip/minivmac/blob/68e5181a44100f5738f465748a6322f4d125aeb9/src/OSGLUESC.c#L260-L289.