how it works

gdox connects a supported dvd drive to xemu. when xemu requests part of the game, gdox reads that part directly from the disc.

the disc stays in the drive for the entire session. nothing is copied or installed first, and no firmware flashing or physical drive modification is required.

analogy

think of the disc as a book with most of its page numbers hidden from a normal dvd drive. gdox makes the full page range available for the session. xemu asks for a page, gdox reads that page from the physical disc, and returns it. the whole book is never photocopied, and nothing is written in it.

technical details

implementation details

data path

xemu read → localhost NBD → RAM cache → partition offset → SCSI sector read → optical drive.

drive interface

an optical drive is a block device. data is addressed as fixed-size logical sectors rather than files. gdox issues SCSI/MMC commands through the operating system's SCSI passthrough interface or through USB Mass Storage Bulk-Only Transport. reader backends hide those transport differences and provide the same random-access sector interface to the rest of the application.

disc layout

an original xbox disc contains more than the dvd-compatible area exposed by a normal drive. a supported reader backend makes the complete logical address space available, either through compatible reader firmware or a reversible change in volatile drive state. the operation is read-only: gdox does not write to the disc or flash the drive.

partition mapping

gdox scans the sector stream for the XDVDFS volume descriptor, determines the start of the game partition, and presents that location as virtual sector zero. every virtual sector request is translated back to its physical location on the disc. the filesystem is read only for metadata; files are not extracted. compatibility changes, when required, are applied as an in-memory overlay on the virtual view.

read requests

an NBD read contains a byte offset and length. gdox validates the range, maps it to the required virtual sectors, applies the partition offset, and checks a bounded page cache in RAM. cache misses become physical sector reads; the requested bytes are then returned to xemu. there is no sequential background reader, so unused parts of the disc are never copied.

virtual dvd drive

the partition is exported by a small read-only fixed-newstyle Network Block Device server bound to localhost. xemu's QEMU core connects directly to that private NBD export and treats it as a dvd drive. NBD is used only as local block-device transport; no kernel NBD device, filesystem mount, or temporary disc image is created.

shutdown

when xemu exits or the disc is ejected, the block-device export stops, the RAM cache is discarded, and the reader backend restores any temporary drive state.

software stack

  • Rust for the application, reader backends, parser, cache, and NBD server
  • eframe/egui for the desktop interface, clap for the command-line interface, and tracing for diagnostics
  • rusb/libusb, USB Bulk-Only Transport, and SCSI/MMC for drive communication
  • XDVDFS for partition and title metadata
  • read-through RAM caching and NBD for the virtual disc
  • xemu/QEMU for xbox emulation