Async CDROM functionality broken when booting from HDD

[ericmackrodt]

• Version of v86: latest-22-g0eec2965
• Browser/OS: Chrome and Zen (Firefox) on MacOS 15.3.2 (M1 Mac)

Hello,

First I want to congratulate @chschnell, @JoeOsborn and @copy for the incredible work getting the PR that allows booting with both the CD and HDD drives. It's an amazing advancement for the emulator.

The emulator does boot from the HDD with the CD in the drive and the CD image is accessible from within the OS, if the cd is not set to async.

Here's my current config that is doing that, the hard drive image fresh from qemu:

 const initOpts: V86Options = {
      wasm_path: "/v86.wasm",
      memory_size: 64 * 1024 * 1024,
      vga_memory_size: 32 * 1024 * 1024,
      screen_container: emulatorContainer,
      preserve_mac_from_state_image: true,
      hda: { url: "/hdd.img", async: true },
      cdrom: { url: "/98install.iso" }, // cd is not async (also, same image used on qemu to install Windows 98 SE)
      bios: {
        url: "/bios/seabios.bin",
      },
      vga_bios: {
        url: "/bios/vgabios.bin",
      },
      autostart: true,
    };

Keep in mind that, when I boot the machine fresh from qemu, it re-detects the hardware/devices and reboots before I can go to My Computer to check the cd rom state.
But that works perfectly.

Unfortunately I found a couple of issues when it comes to booting from the HDD while having a cd image configured as async.

Scenario 1: Booting the machine with async cdrom image.

If I do the exact same as above, but with the cdrom set to async: true:

 const initOpts: V86Options = {
      wasm_path: "/v86.wasm",
      memory_size: 64 * 1024 * 1024,
      vga_memory_size: 32 * 1024 * 1024,
      screen_container: emulatorContainer,
      preserve_mac_from_state_image: true,
      hda: { url: "/hdd.img", async: true },
      cdrom: { url: "/98install.iso", async: true }, // cd is async
      bios: {
        url: "/bios/seabios.bin",
      },
      vga_bios: {
        url: "/bios/vgabios.bin",
      },
      autostart: true,
    };

The emulator starts and, in the networking tab from the browser's dev tools, I can see the chunks of the ISO are being downloaded, but after the drivers are re-detected and the machine rebooted, I see the label of the cd drive is just Cd and if I try to browse it's files, it's blank:

Scenario 2: Save state with ISO and load state with cd being async.

Now, if when I had the cd not as async and, after the machine rebooted and I can browse the files in the CD, I:

• save the state of the emulator
  • I get a state file that is over 700mb as the CD image is being stored in state.
• change the CD to async: true in the initial config
• refresh the page
  • upon loading the page, v86 starts downloading the chunks for the ISO
• try to load my state

I get the following error:

Failed to restore state: TypeError: $block_cache$jscomp$1_state$jscomp$3$$ is not iterable
    at $AsyncXHRBuffer$$module$src$buffer$$.set_state (libv86-debug.js:726:57)
    at $IDEInterface$$module$src$ide$$.set_state (libv86-debug.js:9254:30)
    at $IDEChannel$$module$src$ide$$.set_state (libv86-debug.js:8538:15)
    at $IDEController$$module$src$ide$$.set_state (libv86-debug.js:8369:36)
    at $CPU$$module$src$cpu$$.set_state (libv86-debug.js:11028:142)
    at $restore_state$$module$src$state$$ (libv86-debug.js:2256:21)
    at $v86$$module$src$main$$.restore_state (libv86-debug.js:6151:10)
    at $V86$$module$src$browser$starter$$.restore_state (libv86-debug.js:5789:12)
    at filereader.onload (App.tsx:161:24)

Scenario 3: Configuration mismatch during state restoration

• If I start the emulator without the cdrom:

const initOpts: V86Options = {
    wasm_path: "/v86.wasm",
    memory_size: 64 * 1024 * 1024,
    vga_memory_size: 32 * 1024 * 1024,
    screen_container: emulatorContainer,
    preserve_mac_from_state_image: true,
    hda: { url: "/hdd.img", async: true },
    // cdrom: { url: "/98install.iso", async: true },
    bios: {
        url: "/bios/seabios.bin",
    },
    vga_bios: {
        url: "/bios/vgabios.bin",
    },
    autostart: true,
};

• then I wait for the drivers to be redetected and the machine to reboot
• save the state
• reconfigure the cdrom by uncommenting cdrom: { url: "/98install.iso", async: true },
• reload the state that was saved on v86 without a cd-drive configured

The machine freezes with a black screen and I get the following error:

Failed to restore state: TypeError: Cannot read properties of null (reading '0')
    at $AsyncXHRBuffer$$module$src$buffer$$.set_state (libv86-debug.js:723:82)
    at $IDEInterface$$module$src$ide$$.set_state (libv86-debug.js:9254:30)
    at $IDEChannel$$module$src$ide$$.set_state (libv86-debug.js:8538:15)
    at $IDEController$$module$src$ide$$.set_state (libv86-debug.js:8369:36)
    at $CPU$$module$src$cpu$$.set_state (libv86-debug.js:11028:142)
    at $restore_state$$module$src$state$$ (libv86-debug.js:2256:21)
    at $v86$$module$src$main$$.restore_state (libv86-debug.js:6151:10)
    at $V86$$module$src$browser$starter$$.restore_state (libv86-debug.js:5789:12)
    at filereader.onload (App.tsx:160:24)
filereader.onload @ App.tsx:164
FileReader
handleRestoreState @ App.tsx:175Understand this error

This specific issue happens regardless if the cdrom setting is async: true or async: false before trying to load the saved state.

Scenario 4: Load state saved with different ISO from initial options.

Now, if I go back to the settings and:

• remove async: true
• change the cd image to something else:

 const initOpts: V86Options = {
      wasm_path: "/v86.wasm",
      memory_size: 64 * 1024 * 1024,
      vga_memory_size: 32 * 1024 * 1024,
      screen_container: emulatorContainer,
      preserve_mac_from_state_image: true,
      hda: { url: "/hdd.img", async: true },
      cdrom: { url: "/CDROM32.iso" }, // different image
      bios: {
        url: "/bios/seabios.bin",
      },
      vga_bios: {
        url: "/bios/vgabios.bin",
      },
      autostart: true,
    };

• Refresh the page
  • The machine will start loading and the CDROM32.iso will download
• Load my state

The CDROM that will be available for browsing will be "98install.iso" from the saved state, not the newly configured CDROM32.iso in initial options.

Scenario 5: Load state containing ISO when initial options have no cdrom option

Now, what's fascinating is, if I comment out the cdrom in the settings:

const initOpts: V86Options = {
      wasm_path: "/v86.wasm",
      memory_size: 64 * 1024 * 1024,
      vga_memory_size: 32 * 1024 * 1024,
      screen_container: emulatorContainer,
      preserve_mac_from_state_image: true,
      hda: { url: "/hdd.img", async: true },
      // cdrom: { url: "/CDROM32.iso", async: true },
      bios: {
        url: "/bios/seabios.bin",
      },
      vga_bios: {
        url: "/bios/vgabios.bin",
      },
      autostart: true,
    };

• then refresh the page
  • there's no image to be downloaded, so it would be an empty drive
• load my state
• the 98install.iso label from the image in the saved state is present in the D: drive momentarily and then turns back to an empty drive.

If I double click d: while the label is still there, I get an error saying: "D:\ Directory name is invalid", which is not the normal error for an empty cd drive.
But if I click ok and then double click again, then I get the normal "D:\ is not accessible" error. (If I had waited until the label disappeared, then I would've gotten this straight away).

So basically, if the state has an image in it, it needs any image (not async) in the initial options so you can navigate the image that is in the state.
If there's no image in the initial options, machine understand that there's no cd in the drive and it goes back to an empty drive.
If there's an image set as async in the initial options and I load my state, v86 crashes.

Scenario 6: State saved without CD-ROM in drive then try to set_cdrom async.

• If I setup the machine with the hdd image fresh from qemu without the cdrom setting:

 const initOpts: V86Options = {
      wasm_path: "/v86.wasm",
      memory_size: 64 * 1024 * 1024,
      vga_memory_size: 32 * 1024 * 1024,
      screen_container: emulatorContainer,
      preserve_mac_from_state_image: true,
      hda: { url: "/hdd.img", async: true },
     // cdrom: { url: "/98setup.iso", async: true },
      bios: {
        url: "/bios/seabios.bin",
      },
      vga_bios: {
        url: "/bios/vgabios.bin",
      },
      autostart: true,
    };

• Then, after the drivers are re-detected and the machine reboots, I save the state.
  • I'll get a small, 70(ish) mb, state as there's no ISO.
• Then I refresh the page
• Load the state
  • the state loads perfectly
• Then, similar to earlier, If I try to load my image using emulator.set_cdrom({ url: "/CDROM32.iso", async: true });
  • The chunks of the image will start being download

This sets the label of the cd to Cd and if you try to browse it's files, it shows no files:

(these are the same images as before, because it is the same thing)

If I try this without async emulator.set_cdrom({ url: "/CDROM32.iso" });, it does work and the cd image is loaded correctly.

If I save the state now, I get the huge state file like the one I got when I save the state after booting the emulator with a cdrom image non-async, and all of the scenarios from the beginning can be replicated with this state file.

I have tested all of this on Windows 98 SE but I'm sure it can be reproduced one way or another on any operating system.

I would love to be able fix this issue and submit a PR but this work is too low level and goes beyond my skill-set. What I can do is, if deemed useful, I can write some tests for this scenario in the test suite and if someone attempts to fix these issues they can run those tests to verify if they were fixed.

As for my own project, I'm okay with using images in a non-async manner for now.

[chschnell]

I was able to reproduce the first scenario (empty disk) with a Windows95 setup (never tested async CD access before).

For me it works (kind of) when I specify size (image size in bytes) and fixed_chunk_size together with async, like so (see hda and cdrom):

<!DOCTYPE html>
<script type="module">
//import { V86 } from "./libv86.mjs";
import { V86 } from "./libv86-debug.mjs";

const v86_config = {
    wasm_path: "v86.wasm",
    memory_size: 64 * 1024 * 1024,
    vga_memory_size: 32 * 1024 * 1024,
    screen_container: document.getElementById("screen_container"),
    preserve_mac_from_state_image: true,
    hda: { url: "w95-oakcd.img", async: true, size: 242049024, fixed_chunk_size: 1024 * 1024 },
    cdrom: { url: "windows95b.iso", async: true, size: 1248139430, fixed_chunk_size: 1024 * 1024 },
    bios: { url: "seabios-1.16.2-0.bin" },
    vga_bios: { url: "vgabios-1.16.2-0.bin" },
    autostart: true,
};

const emulator = window.emulator = new V86(v86_config);
</script>

<div id="screen_container">
    <div style="white-space: pre; font: 14px monospace; line-height: 14px"></div>
    <canvas style="display: none"></canvas>
</div>

I boot from hda, and I get a couple of blue screens when accessing the CD-ROM, but they are not critical and I can just continue by pressing ENTER. So there is some issue there (never had these blue screens), but other than that reading the CD asynchronously works:

The other issues all seem to point to get/set_state() of the IDE objects when using async buffer class AsyncXHRBuffer. I don't know how this is supposed to mix.

[chschnell]

The blue-screens under Windows 95 are specific to the OAK CD-ROM driver I'm using.

I've now run tests with FreeDOS 1.4 and ReactOS 0.4.15, they handle asynchronous CD-ROM I/O just fine.

Just in case this isn't clear already:

• When using synchronous I/O the entire disk image is loaded into RAM upfront and every byte is always present at run-time.
• With asynchronous I/O the image is loaded in chunks into RAM in an on-demand basis, chunks are loaded lazily only when the guest actually accesses them at run-time.

What I was able to trace so far:

• Whenever the guest reads from the CD-ROM a chunk that is not loaded yet, the chunk's download is started in the browser's background and the guest is told that the device is BUSY until further notice.
• Here is where it goes wrong with the OAK driver under Windows 95: Upon detecting that BUSY flag it resets the CD-ROM device and simultaneously shows that blue-screen. Other guest OSes understand the BUSY flag in the IDE status register and play along fine.
• While the Windows 95 guest is blocked and waiting in the blue-screen, enough time passes to let the chunk download in the browser's background complete.
• After pressing ENTER and leaving the blue-screen, Windows 95 re-issues the identical read command that previously failed, and now that the chunk is available it continues without error.

Makes sense, though I wasn't able to find out why OAK resets the device when it detects the device's BUSY state (a very normal case when reading, CD-ROMs are laggy). A simple solution might be to use a different ATAPI CD-ROM driver than the one from OAK under Windows 95/98.

---

I've also noticed that an async CD-ROM device "breaks" when a guest is internally performing a "soft reset" or "reboot". That needs to be debugged. EDIT: this was incorrect, see my next post

---

Coming back to using an async CD-ROM image with a v86 state image: Since it is rather unlikely that all chunks of the CD-ROM image have been downloaded when you export your v86 state image, you'd need to deploy your state image together with the CD-ROM image anyway (for the missing chunks). I'd suggest to use synchronous CD-ROMs with state images, then both images are combined in one.

[chschnell]

A few more pieces to this puzzle:

• only under Win95+OAK I need to specify size and fixed_chunk_size for some reason when using an async CD-ROM, other guest OSes are fine with just async (as it should be)
• an async CD-ROM does not "break" when rebooting as I thought earlier, this is an unrelated issue specific to ReactOS (clicking on "My Computer" after reboot hangs, but also with a synchronous CD-ROM so that's something else)
• Debian 12 is as unhappy with the async CD-ROM as is Win95+OAK (see boot logs at the end of this post), whenever a chunk is missing it logs an error and resets the CD-ROM device. But it works robustly, running tree on the CD-ROM works but gets interrupted shortly whenever a new chunk needs to be fetched
• when I do not set the BUSY bit then I do not get blue-screens under Win95+OAK, of course this doesn't solve anything (I always read an empty disk this way), but it's a clue
• a different ATAPI CD-ROM driver (VIDE-CDD.SYS instead of OAKCDROM.SYS) for Win95 makes no difference and shows the same problem

So from the 4 guest OSes that I've tested with an async CD-ROM image mounted while booting from harddisk (sync or async):

• Win95 and Debian12 show a very similar faulty behaviour (but both are robust across reboots),
• FreeDos 1.4 works without any issues including reboots, and
• ReactOS 0.4.15 works without issues unless it gets rebooted (which breaks it somewhere else).

Note that all guest OSes boot from an asynchronous ATA harddisk without any issues.

All this underlines that there is a problem specific to asynchronous I/O with ATAPI devices (CD-ROMs). The information available so far indicates that the way we signal to the guest that we're BUSY in the ATAPI READ command implementation is somehow incorrect (but works for ATA READ).

Debian 12 boot logs with async CD-ROM image mounted

Jun 15 09:27:01 debian kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jun 15 09:27:01 debian kernel: ata2.00: BMDMA stat 0x5
Jun 15 09:27:01 debian kernel: ata2.00: cmd a0/01:00:00:00:10/00:00:00:00:00/a0 tag 0 dma 4096 in
                                        Read(10) 28 00 00 1d bf fe 00 00 02 00 res d0/00:02:00:00:10/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
Jun 15 09:27:01 debian kernel: ata2.00: status: { Busy }
Jun 15 09:27:01 debian kernel: ata2: soft resetting link
Jun 15 09:27:01 debian kernel: ata2.00: configured for MWDMA2
Jun 15 09:27:01 debian kernel: sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
Jun 15 09:27:01 debian kernel: sr 1:0:0:0: [sr0] tag#0 Sense Key : Aborted Command [current] 
Jun 15 09:27:01 debian kernel: sr 1:0:0:0: [sr0] tag#0 Add. Sense: Scsi parity error
Jun 15 09:27:01 debian kernel: sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 1d bf fe 00 00 02 00
Jun 15 09:27:01 debian kernel: I/O error, dev sr0, sector 7798776 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
Jun 15 09:27:01 debian kernel: ata2: EH complete

Jun 15 09:27:01 debian kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jun 15 09:27:01 debian kernel: ata2.00: BMDMA stat 0x5
Jun 15 09:27:01 debian kernel: ata2.00: cmd a0/01:00:00:00:10/00:00:00:00:00/a0 tag 0 dma 4096 in
                                        Read(10) 28 00 00 00 02 00 00 00 02 00 res d0/00:02:00:00:10/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
Jun 15 09:27:01 debian kernel: ata2.00: status: { Busy }
Jun 15 09:27:01 debian kernel: ata2: soft resetting link
Jun 15 09:27:01 debian kernel: ata2.00: configured for MWDMA2
Jun 15 09:27:01 debian kernel: sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
Jun 15 09:27:01 debian kernel: sr 1:0:0:0: [sr0] tag#0 Sense Key : Aborted Command [current] 
Jun 15 09:27:01 debian kernel: sr 1:0:0:0: [sr0] tag#0 Add. Sense: Scsi parity error
Jun 15 09:27:02 debian kernel: sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 02 00 00 00 02 00
Jun 15 09:27:02 debian kernel: I/O error, dev sr0, sector 2048 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
Jun 15 09:27:02 debian kernel: ata2: EH complete

Jun 15 09:27:02 debian kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jun 15 09:27:02 debian kernel: ata2.00: BMDMA stat 0x5
Jun 15 09:27:02 debian kernel: ata2.00: cmd a0/01:00:00:00:10/00:00:00:00:00/a0 tag 0 dma 4096 in
                                        Read(10) 28 00 00 00 02 00 00 00 02 00 res d0/00:02:00:00:10/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
Jun 15 09:27:02 debian kernel: ata2.00: status: { Busy }
Jun 15 09:27:02 debian kernel: ata2: soft resetting link
Jun 15 09:27:02 debian kernel: ata2.00: configured for MWDMA2
Jun 15 09:27:02 debian kernel: ata2: EH complete

Jun 15 09:27:02 debian kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jun 15 09:27:02 debian kernel: ata2.00: BMDMA stat 0x5
Jun 15 09:27:02 debian kernel: ata2.00: cmd a0/01:00:00:00:10/00:00:00:00:00/a0 tag 0 dma 4096 in
                                        Read(10) 28 00 00 00 04 00 00 00 02 00 res d0/00:02:00:00:10/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
Jun 15 09:27:02 debian kernel: ata2.00: status: { Busy }
Jun 15 09:27:02 debian kernel: ata2: soft resetting link
Jun 15 09:27:02 debian kernel: ata2.00: configured for MWDMA2
Jun 15 09:27:02 debian kernel: sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
Jun 15 09:27:02 debian kernel: sr 1:0:0:0: [sr0] tag#0 Sense Key : Aborted Command [current] 
Jun 15 09:27:02 debian kernel: sr 1:0:0:0: [sr0] tag#0 Add. Sense: Scsi parity error
Jun 15 09:27:02 debian kernel: sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 04 00 00 00 02 00
Jun 15 09:27:02 debian kernel: I/O error, dev sr0, sector 4096 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
Jun 15 09:27:02 debian kernel: ata2: EH complete

[chschnell]

A bit of progress: I think I have a fix for Debian (and maybe for other guests that use DMA, too).

Two methods of IDEInterface need to be considered here, depending on whether the guest is using our IDE controller with or without DMA:

• atapi_read()
• atapi_read_dma()

Also what happens at the bottom of atapi_handle() plays a role.

It looks like Debian is using DMA while FreeDOS, ReactOS and Win95 do not.

I think I was able to fix it in atapi_read_dma(), so an async CD-ROM with Debian 12 now works without errors or warnings!

The situation with atapi_read() is unchanged though, FreeDOS and ReactOS work while Win95+OAK throws non-critical blue-screens. Unfortunately nothing I've tried helps here, the idea that fixed it in atapi_read_dma() doesn't work here at all. Currently not sure what else to try here.

So this is only a partial fix, which also needs more testing with other guests that use DMA.

[ericmackrodt]

Hi @chschnell , thanks for looking into it.

Right now I have this, based on what you showed earlier:

try {
    const response = await fetch("/clean_state.bin");
    const stateBuffer = await response.arrayBuffer();

    const initOpts: V86Options = {
      wasm_path: "/v86.wasm",
      memory_size: 64 * 1024 * 1024,
      vga_memory_size: 32 * 1024 * 1024,
      screen_container: state.emulatorContainer,
      preserve_mac_from_state_image: true,
      hda: { url: "/hdd.img", async: true },
      cdrom: {
        url: "/" + isoFile,
        async: true,
        size: 673538048,
        fixed_chunk_size: 1024 * 1024,
      },
      initial_state: { buffer: stateBuffer },
      bios: {
        url: "/bios/seabios.bin",
      },
      vga_bios: {
        url: "/bios/vgabios.bin",
      },
    };

    state.emulator = new window.V86(initOpts);

    if (state.emulator) {
      setTimeout(async () => {
        const response = await fetch("/clean_state.bin");
        const stateBuffer = await response.arrayBuffer();

        if (state.emulator) {
          state.emulator.eject_cdrom();
          state.emulator.stop();
          state.emulator.restore_state(stateBuffer);
          state.emulator.set_cdrom({
            url: "/" + isoFile,
            async: true,
            size: 673538048,
            fixed_chunk_size: 1024 * 1024,
          });

          state.emulator.run();
        }
      }, 5000);
    }
  } catch (error) {
    console.error("Failed to initialize v86:", error);
    setLog(
      `Error initializing v86: ${
        error instanceof Error ? error.message : String(error)
      }`
    );
  }

When the machine first loads, I do get the error:

libv86-debug.js:723 Uncaught (in promise) TypeError: Cannot read properties of null (reading '0')
    at $AsyncXHRBuffer$$module$src$buffer$$.set_state (libv86-debug.js:723:82)
    at $IDEInterface$$module$src$ide$$.set_state (libv86-debug.js:9254:30)
    at $IDEChannel$$module$src$ide$$.set_state (libv86-debug.js:8538:15)
    at $IDEController$$module$src$ide$$.set_state (libv86-debug.js:8369:36)
    at $CPU$$module$src$cpu$$.set_state (libv86-debug.js:11028:142)
    at $restore_state$$module$src$state$$ (libv86-debug.js:2256:21)
    at $v86$$module$src$main$$.restore_state (libv86-debug.js:6151:10)
    at $V86$$module$src$browser$starter$$.$done$jscomp$4$$ (libv86-debug.js:5582:56)

But then after 5 second timeout, when my state is restored and stuff, the cd seems to load fine.

I did the initialization using the functions and this worked:

const initOpts: V86Options = {
      wasm_path: "/v86.wasm",
      memory_size: 64 * 1024 * 1024,
      vga_memory_size: 32 * 1024 * 1024,
      screen_container: state.emulatorContainer,
      preserve_mac_from_state_image: true,
      hda: { url: "/hdd.img", async: true },
      // cdrom: {
      //   url: "/" + isoFile,
      //   async: true,
      //   size: 673538048,
      //   fixed_chunk_size: 1024 * 1024,
      // },
      // initial_state: { buffer: stateBuffer },
      bios: {
        url: "/bios/seabios.bin",
      },
      vga_bios: {
        url: "/bios/vgabios.bin",
      },
    };

    state.emulator = new window.V86(initOpts);

    if (state.emulator) {
      setTimeout(async () => {
        const response = await fetch("/clean_state.bin");
        const stateBuffer = await response.arrayBuffer();

        if (state.emulator) {
          state.emulator.eject_cdrom();
          state.emulator.stop();
          state.emulator.restore_state(stateBuffer);
          state.emulator.set_cdrom({
            url: "/" + isoFile,
            async: true,
            size: 673538048,
            fixed_chunk_size: 1024 * 1024,
          });

          state.emulator.run();
        }
      }, 5000);
    }

So, right now if I do the initialization via the functions instead of the constructor and set the size of the ISO and chunk sizes, it does work.