PHP Classes

File: docs/proposals/OtherEmulatorConsiderations.md

Recommend this page to a friend!
  Packages of Matthew Asham   Binkterm PHP   docs/proposals/OtherEmulatorConsiderations.md   Download  
File: docs/proposals/OtherEmulatorConsiderations.md
Role: Auxiliary data
Content type: text/markdown
Description: Auxiliary data
Class: Binkterm PHP
Bulletin board system based on the Web
Author: By
Last change:
Date: 5 days ago
Size: 3,140 bytes
 

Contents

Class file image Download

Other Emulator Considerations

> Draft Notice: This document is a draft, was generated by AI, and may not have been reviewed for accuracy.

Overview

This document assesses the effort involved in adding support for additional emulators (such as MAME, PCem, QEMU, etc.) to the DOS door multiplexing bridge.

What's Already Done

The emulator-adapters.js file implements a clean adapter pattern with a base EmulatorAdapter class. Adding a new emulator means creating a new adapter class and registering it in the factory function createEmulatorAdapter(). The bridge, PHP session management, DOOR.SYS generation, and WebSocket multiplexing require no changes.

Adding a new emulator requires only: 1. Create a class extending EmulatorAdapter in emulator-adapters.js 2. Implement launch(), write(), onData(), onExit(), close(), getName() 3. Register it in createEmulatorAdapter() 4. Add relevant .env variables for executable path and options

The Hard Parts for MAME Specifically

Serial communication is the core challenge. The entire system is built around a serial port abstraction ? DOSBox uses a TCP nullmodem, DOSEMU uses a PTY. MAME would need to expose its emulated serial port similarly:

  • MAME supports `-comm` network socket communication for some drivers, but it is not universal
  • The specific approach depends on which machine driver is being emulated (e.g., `ibmpc`, `ibm5150`)
  • MAME's documentation on serial socket communication is sparse

MAME is machine-centric, not OS-centric. DOSBox boots a DOS environment and any game can run within it. With MAME you'd be emulating specific hardware (e.g., ibmpc). You'd need to determine which MAME driver(s) to target and how to get a bootable DOS environment loaded within them.

Drop file injection. Currently DOOR.SYS is written to a session directory that DOSBox mounts as a drive. With MAME, a per-session disk image with the drop file baked in would likely be required, which is more complex than a simple directory mount.

Effort by Emulator

| Emulator | Effort | Notes | |---|---|---| | PCem / 86Box | Low?Medium | TCP serial interface, directory mounts similar to DOSBox | | QEMU | Medium | Serial socket is straightforward; per-session disk image needed | | MAME (PC driver) | Medium?High | Serial I/O varies by driver; disk image complexity; sparse docs |

What a MAME Implementation Would Need

  1. A `MAMEAdapter` class in `emulator-adapters.js`
  2. A mechanism to generate a per-session disk image (or use MAME's `-rp` rompath with a writable overlay)
  3. Resolution of MAME's serial socket interface for the target hardware driver
  4. New `.env` variables: `MAME_EXECUTABLE`, `MAME_DRIVER`
  5. Registration in `createEmulatorAdapter()`

Recommendation

If the goal is simply to support an alternative DOS emulator, PCem or 86Box would be considerably easier targets than MAME, as they use TCP serial and directory mounts analogous to DOSBox. MAME is an arcade and hardware emulator first ? DOS PC support exists but integration is rougher and the tooling is less suited to this use case.