dosforge 0.9.57

dosforge v0.9.57

Build, browse, and mount DOS-friendly disk images on Linux & Windows.

Features
^

Image creation

Floppies (.img / .ima / .vfd) — 360K, 720K, 1.2M, 1.44M, 2.88M, with optional system-format (/S) for any supported DOS.
VHDs (fixed Microsoft Virtual PC) — 32 MiB → multi-GiB, FAT12 / FAT16 / FAT32, IDE or MFM controllers, configurable BIOS HDD presets (Phoenix Type 1–47, custom CHS, Xebec).
Boot mode auto-coerces output settings — pick the OS, get a valid combo.
DOS coverage (real install media, not synthesized)

FreeDOS (FAT16 / FAT32)
MS-DOS 1.x, 2.x, 3.3, 3.31, 4, 5, 6.22, 7.10 (Win95)
IBM PC-DOS 1, 2, 3, 5, 6, 7, 7.1 SGTK, PC-DOS 2000
Compaq DOS 2.11, 3, 3.31
DR-DOS 5, 6, 7
IBM PC 8088/V20 umbrella (DOS 3.3 or 5.0) for vintage 10 MiB MFM presets
4DOS shell on top of MS-DOS 7.10
Three ways to drive it

CLI — scripted one-liners (dosforge create …, dosforge mount …, etc.)
TUI — full-screen Textual interface (Linux, macOS, WSL)
GUI — native Tk interface (Windows only)
Image tools

Mount VHDs read/write on Linux (via qemu-nbd) — browse & edit live in a file manager.
Extract any file or directory from a VHD/IMG via mtools, no admin needed. Accepts /CONFIG.SYS or C:\CONFIG.SYS.
Grow VHDs in place — preserves system files, CONFIG.SYS, AUTOEXEC.BAT, and every user file (mtimes intact). Supported on FreeDOS, MS-DOS 7.10, MS-DOS 6.22, and Compaq DOS 3.31 fixed VHDs. Optional headless boot probe verifies the grown image boots before the atomic swap.
dosassets/ — the one folder you'll care about

Linux: ~/dosassets/ (or any path you pass with --boot-assets).
Windows: \dosassets\ (it's at the
root of the install — never inside _internal).
Drop the raw .7z / .zip install media, the extracted .img / .ima / .dsk, or a pre-extracted directory — dosforge auto-detects all three.

Get started

Linux

curl -L -o /tmp/dosforge.tar.gz
https://github.com/flynnsbit/dosforge/releases/latest/download/dosforge-0.9.44-linux.tar.gz
tar -xzf /tmp/dosforge.tar.gz -C /tmp
cd /tmp/dosforge-0.9.44 && sudo ./install.sh
dosforge # launches the TUI

Windows

Download dosforge-0.9.44-windows-x64.zip (or -cli- for headless).
Extract anywhere — C:\Apps\DosForge\ is a good default.
Drop your DOS install media into C:\Apps\DosForge\dosassets.
Run dosforge-gui.exe for the GUI or dosforge-cli.exe for the CLI.
Releases: https://github.com/flynnsbit/dosforge/releases (https://github.com/flynnsbit/dosforge/releases)

Pull requests, issues, and 86Box / DOSBox-X compatibility reports very welcome.

Highlights

• IBM 8088 + PC-DOS 3.x (--boot-mode ibm8088 --ibm-dos-version pcdos3)
  now supports FAT16 partitions up to 32 MiB.

  v0.9.56 enabled FAT16 for the standalone pcdos3 + compaq3 boot
  modes. This release extends the same historical correction to the
  IBM 8088 builder's parallel DOS-version dropdown
  (IBMDOSVersion.PCDOS3), which until now was hard-capped at
  16 MiB FAT12-only.

  Build behaviors:

  • dosforge create --boot-mode ibm8088 --ibm-dos-version pcdos3 --format fat16 --size 32M --disk-controller ide
    -> 31.99 MiB VHD, MBR partition type 0x04 (FAT16 <32MiB)
  • dosforge create --boot-mode ibm8088 --ibm-dos-version pcdos3 --format fat12 --size 16M --disk-controller mfm --bios-drive-type phoenix:1
    -> 10.16 MiB VHD, MBR partition type 0x01 (FAT12)
  • --size 64M -> IBM PC-DOS 3.x IBM 8088/V20 profile images must not exceed 32 MiB.

dosforge 0.9.56

dosforge v0.9.56

Highlights

• PCDOS3 + COMPAQ3 now support FAT16 partitions up to 32 MiB
  (historical correction).
  • Prior dosforge versions restricted IBM PC-DOS 3.00 and the
    Microsoft MS-DOS 3.00 Compaq OEM build to FAT12-only with a
    16 MiB cap, citing "FAT16 was added in PC-DOS 3.10."
  • That comment was historically inaccurate. FAT16 was
    introduced in PC-DOS 3.0 (August 1984), and its FORMAT.COM
    already picks FAT12 for partitions <=16 MiB and FAT16 for
    16-32 MiB partitions automatically. Compaq's OEM MS-DOS 3.00
    shipped the same Microsoft kernel and FORMAT.
  • You can now build:
    • dosforge create --boot-mode pcdos3 --format fat16 --size 32M
    • dosforge create --boot-mode compaq3 --format fat16 --size 32M
  • FAT12 (<=16 MiB) is still the default and remains
    1984-authentic for small XT-IDE drives.
  • 32 MiB is the 1984 partition-table addressing cap; >32 MiB
    still requires compaq331 (FAT16B) or msdos5 / msdos622.

Fixed

• Stale _BOOT_MODE_MEDIA_RULES comments + _validate_create_request
  messages now describe the correct PC-DOS 3.0 FORMAT.COM behavior.

Tests

• tests/test_size_cap_snap.py splits PCDOS3 + COMPAQ3 cap tests
  into FAT12 (16 MiB) + FAT16 (32 MiB) variants. The
  TestFormDiskCapParity drift-prevention test continues to
  enforce that every formlogic._BOOT_MODE_MEDIA_RULES max_mb
  has a matching disk-side cap branch.

Verified

• pcdos3 + FAT16 + 32M + IDE -> 33,546,752-byte VHD with
  MBR partition type 0x04 (FAT16 <32MiB), COMMAND.COM dated
  1984-08-14.
• compaq3 + FAT16 + 32M + IDE -> same.
• Regression: pcdos3 + FAT12 + 16M + XT-IDE still snaps to
  (306, 4, 26) = 15.54 MiB.
• Over-cap rejection: pcdos3 + FAT16 + 64M -> ValidationError
  with the corrected guidance.

dosforge 0.9.55

dosforge v0.9.55

Fix: _effective_size_cap_bytes drift -- COMPAQ3, DRDOS6, DRDOS7

User-reported follow-up to v0.9.54: same "16M means 16M" bug for
compaq3 (Microsoft MS-DOS 3.00 Compaq OEM) -- 16M is rejected,
15M works.

Root cause

v0.9.54 added branches in _effective_size_cap_bytes for PCDOS3
and COMPAQ2 to mirror formlogic's max_mb constraints, but
missed three other modes that formlogic also pins below the FAT
format hard cap:

BootMode	formlogic max_mb	v0.9.54 disk-side cap	Bug?
COMPAQ3	16	none (used FAT12 32 MiB cap)	yes -- same 16M-rejected as PCDOS3
DRDOS6	32	none (used FAT16 2 GiB cap)	yes -- bumps past 32 MiB on XT-IDE
DRDOS7	2048	none (matches FAT16 cap)	no, but added for symmetry

When formlogic's advertised cap is tighter than the FAT format
cap, the disk-side _effective_size_cap_bytes must mirror it or
_xtide_geometry will bump past the cap and the create gets
rejected by downstream validation.

Fix

Three new branches in _effective_size_cap_bytes:

• COMPAQ3 -> 16 MiB (same 1985-era partition cap as PCDOS3).
• DRDOS6 -> 32 MiB (IBM-3.3-class BPB, no FAT16B in DR-DOS 6.0).
• DRDOS7 -> 2 GiB (FAT16B BIGDOS; identical to FAT16 hard cap
  but added explicitly for symmetry with formlogic's max_mb).

Drift-prevention test

New TestFormDiskCapParity.test_every_formlogic_max_mb_has_disk_side_mirror
iterates formlogic._BOOT_MODE_MEDIA_RULES, builds a probe request
for every rule with an explicit max_mb tighter than the FAT format
cap, and asserts that _effective_size_cap_bytes returns the same
number of bytes the form advertised. Going forward, adding a new
max_mb cap in formlogic without mirroring it in disk.py will
fail this test instead of silently breaking create.

Verified end-to-end on Windows

Direct repro of the COMPAQ3 bug:

$ dosforge create --path test.vhd --media-type vhd --format fat12 \
    --size 16M --boot-mode compaq3 --disk-controller xtide
Created and prepared test.vhd
VHD size: 16,294,400 bytes (15.54 MiB)

(Picks the (306, 4, 26) whitelist geometry under the 16 MiB cap,
identical to PCDOS3 behavior after v0.9.54.)

Tests

16 tests in tests/test_size_cap_snap.py (up from 12 in v0.9.54):

• 3 new _effective_size_cap_bytes cases for COMPAQ3 / DRDOS6 / DRDOS7.
• 1 new TestFormDiskCapParity that catches any future drift between
  formlogic and disk.py automatically.

Files changed

• src/dosforge/disk.py -- added COMPAQ3 / DRDOS6 / DRDOS7 branches
  in _effective_size_cap_bytes.
• tests/test_size_cap_snap.py -- 3 new per-mode tests + 1 parity test.
• pyproject.toml + src/dosforge/__init__.py -- 0.9.54 -> 0.9.55.

Carried forward

• v0.9.54 16M means 16M (PCDOS3 / COMPAQ2 + XT-IDE)
• v0.9.53 Show log grows window
• v0.9.52 Windows-path ECHS-doubling fix

dosforge 0.9.54

dosforge v0.9.54

Fix: "16M means 16M" cap-vs-snap contract for create form

User-reported bug: form auto-fills 16M as the max size for IBM
PC-DOS 3 + XT-IDE + FAT12 (correct), but clicking Create fails
with "PC-DOS 3.x images must not exceed 16 MiB" until the user
drops to 15M.

Root cause

The form's _state_aware_max_mb returns 16 (MiB) for PCDOS3, so
the size field shows "16M". The user submits with size = 16 MiB
= 16,777,216 bytes.

_validate_xtide_request calls _xtide_geometry, which finds the
smallest MartyPC XT-IDE whitelist entry that fits above the
request: (1024, 2, 17) = 34,816 sectors = 17,825,792 bytes
(~17 MiB). It writes that bumped value back to
request.size_bytes and returns.

Then validate_size_for_ibm_dos(17 MiB, PCDOS3) rejects: 17 > 16
MiB cap.

With 15M, the smallest fits-above entry is (306, 4, 26) =
15.54 MiB, which is under the 16 MiB cap. Passes.

Audit -- two paths had this pattern

1. XT-IDE auto-snap (_xtide_geometry via
   _validate_xtide_request, disk.py:1879) -- the bug above.
2. Custom payload autosizing
   (_apply_custom_payload_autosizing, disk.py:1968) -- same
   pattern. Combining --custom-payload-path with a cap-tight
   DOS (e.g. PCDOS3 16 MiB, MSDOS33 32 MiB) and a payload >= cap
   silently bumped request.size_bytes past the cap, producing
   an unbootable VHD that the chosen DOS can't read past its
   partition cap.

Other paths checked + confirmed correct:

• AT-IDE CHS cylinder snap (align_size_for_normal_chs)
  already accepts max_bytes and snaps DOWN when the ceil would
  exceed the cap. No bug.
• BIOS drive-type preset fails explicitly with a clear
  "preset exceeds cap" message instead of silently bumping.
• Custom CHS does no snap at all.

Fix

New helper _effective_size_cap_bytes(request) in
src/dosforge/disk.py. Combines per-boot-mode caps (PCDOS3
16 MiB, COMPAQ2 16 MiB, MSDOS33 / MSDOS331 32 MiB,
COMPAQ331 / IBM8088+PCDOS5+MSDOS5 504 MiB, IBM8088+DOS33 32 MiB,
IBM8088+PCDOS3 16 MiB) with the FAT format cap (FAT12 32 MiB,
FAT16 2 GiB, FAT32 2 TiB). Single source of truth on the disk
side, mirrors _state_aware_max_mb on the form side.

_xtide_geometry -- snap-down support: new optional
max_size_bytes parameter. When the smallest fits-above
whitelist entry would exceed max_size_bytes, fall back to the
largest whitelist entry that fits <= max_size_bytes. Only
raises ValidationError when even the smallest whitelist entry
exceeds the cap (i.e. XT-IDE fundamentally can't make a disk that
small for the chosen DOS). Both _resolved_xt_class_geometry
and _validate_xtide_request now pass the cap.

_apply_custom_payload_autosizing -- cap check: after
computing required_size, refuse to bump past
_effective_size_cap_bytes(request). Raises a clear
ValidationError naming the boot mode, cap, and payload size when
the cap is exceeded so users know to either trim the payload or
pick a different DOS.

Verified end-to-end on Windows

Direct repro of the user's bug:

$ dosforge create --path test.vhd --media-type vhd --format fat12 \
    --size 16M --boot-mode pcdos3 --disk-controller xtide
Created and prepared test.vhd
VHD size: 16,294,400 bytes (15.54 MiB)

(Picks the (306, 4, 26) whitelist geometry under the 16 MiB
cap, just like manually entering 15M did pre-fix.)

Tests

• tests/test_size_cap_snap.py (new) -- 12 tests covering:
  • _effective_size_cap_bytes for PCDOS3 / COMPAQ331 / IBM8088
    (DOS33 + PCDOS5) / FreeDOS.
  • _xtide_geometry snap-down at PCDOS3 cap (the user's bug).
  • _xtide_geometry below-cap input still snaps UP (no
    regression).
  • _xtide_geometry with max_size_bytes=None preserves
    original behavior.
  • Whitelist invariants (at least one entry <= 16 MiB so the
    snap-down can succeed).

All 12 new tests pass + existing
test_disk_validation.py, test_disk_windows_vhd.py,
test_martypc.py, test_formlogic.py regression-free.

Files changed

• src/dosforge/disk.py -- new _effective_size_cap_bytes,
  _xtide_geometry snap-down logic, _apply_custom_payload_autosizing
  cap check, added FAT12_MAX_BYTES import.
• tests/test_size_cap_snap.py -- new test file.
• tests/conftest.py -- registered new test in Windows
  allow-list.
• pyproject.toml + src/dosforge/__init__.py -- 0.9.53 -> 0.9.54.

dosforge 0.9.53

dosforge v0.9.53

Fix: "Show log" now grows the window to make room for the panel

User-reported Windows GUI bug: clicking the Show log button in
the bottom status bar packed the log panel underneath the content
area but didn't grow the toplevel window to accommodate it. The
panel ended up clipped or pushed off-screen until the user manually
dragged the window taller. The hide path had the symmetric problem
(window stayed oversized after collapsing).

What changed

StatusBar.show_log and _toggle_log (in
src/dosforge/_gui/widgets.py) now call a new
_adjust_window_for_log_change helper that:

1. Forces a Tk layout pass and reads the log holder's required
   height (Text widget at height=8 lines + scrollbar + padding).
2. Reads the toplevel window's current geometry.
3. Grows or shrinks the window height by the panel's required
   height when toggling.
4. Caps the grown height at 95% of the screen height so the window
   never disappears off the bottom (taskbar / dock stays visible).

The log panel itself is unchanged — same 8-line scrollable Text
widget, same Show log / Hide log / Copy log buttons.

Behavior matrix

Action	v0.9.52	v0.9.53
First click "Show log"	Panel packed but clipped	Panel packed + window grows to fit
Click "Hide log"	Panel removed, window stays tall	Panel removed + window shrinks back
User has manually resized window taller before clicking show	Same broken (panel clipped if not tall enough)	Window grows the panel-height delta
Screen too short to fit panel	Window pushed off-screen	Capped at 95% of screen height

Files changed

• src/dosforge/_gui/widgets.py — added
  _adjust_window_for_log_change; wired it into show_log and
  _toggle_log.
• pyproject.toml + src/dosforge/__init__.py — 0.9.52 → 0.9.53.

Cross-platform note

Same widgets.py is used on both Windows and Linux GUIs. Tk's
winfo_screenheight + geometry work identically on both, so this
fix applies to Linux GUI users too (the Linux GUI is an optional
secondary launch surface; TUI is primary on Linux).

Carried forward

• v0.9.52 fix Windows-path ECHS-doubling of MBR start_chs
• v0.9.51 Windows GUI Combobox wheel + focus polish
• v0.9.50 stamp release artifacts with correct version

dosforge 0.9.52

dosforge v0.9.52

Fix: Windows path FreeDOS FAT32 / MS-DOS 7.10 boot for VHDs > 504 MiB

User-reported 86Box symptom: freshly built Windows-side VHDs hung at a
blinking cursor right after POST. Affected:

• FreeDOS FAT16 and FAT32 (any size that pushed footer cylinder count

  1024 — typically anything ≥ 512 MiB at 16h/63s).

• MS-DOS 7.10 (OSR2) FAT16 (showed "Missing operating system" — same
  underlying bug, different MBR-boot-code failure path).

Root cause: ECHS-doubled start_chs invalid for the BIOS that

actually runs

src/dosforge/disk.py (Windows VHD path, _create_and_prepare_vhd_no_kernel)
contained an ECHS bit-shift loop:

partition_chs_heads = footer.heads
if footer.heads > 0 and footer.cylinders > 1024:
    heads = footer.heads
    cyls = footer.cylinders
    while cyls > 1024 and heads < 256:
        heads *= 2
        cyls = (cyls + 1) // 2
    partition_chs_heads = min(heads, 255)

For a 1 GiB VHD with footer (2081, 16, 63), this loop runs twice and
produces partition_chs_heads = 64. _lba_to_chs(2048, heads=64, spt=63) then encodes start CHS as bytes 20 21 00 → (cyl=0,
head=32, sec=33).

The MBR boot loader (440-byte _BUILTIN_MSDOS_MBR_BOOT_CODE) reads
the partition's first sector via INT 13h AH=02 DH=32 (head 32).
86Box's AUTO IDE — and every modern emulator/BIOS preset that
reports the disk's raw geometry rather than auto-translating —
rejects head 32 as out of range for a 16-head disk. The carry flag
gets set, the MBR's JC short-circuit fires, MBR halts at its
blinking-cursor loop.

For MS-DOS 7.10 the same bad CHS triggers the secondary "no
bootable VBR found" path in OSR2's MBR loader → "Missing operating
system".

Why this is a Windows-only regression

The Linux path was given exactly this fix two weeks ago in commit
3951021 (v0.6.3). Quoting that commit's rationale:

parted writes the partition entry with its own BIOS-canonical CHS
values that don't correspond to the VHD footer geometry. On 86Box
AUTO IDE, the mismatch causes the BIOS to pick LRG translation as
a fallback; INT 13h reads then land on the wrong sectors and the
disk fails to boot with 'Missing operating system'.

Validated empirically: 4 of 8 boot-success VHDs from the v0.5.2
smoke matrix went from 'Missing operating system' to bootable
after the manual equivalent of this patch.

The Linux fix introduced _rewrite_mbr_partition_entry_for_footer
which uses footer.heads / footer.sectors_per_track directly (no
ECHS doubling) and runs after parted clobbers the partition table.
That commit explicitly noted "The defensive ECHS-translation logic
at the existing core_mbr.write_single_partition_mbr call site was
unreachable on Linux because parted clobbers the partition table
after that call runs" — meaning the Linux author knew the Windows
code path still had ECHS doubling, but didn't fix it because Linux
tests had already moved past the issue.

The Windows path slipped through v0.6.3 → v0.9.51 because:

1. Most Windows smoke tests in v0.6 / v0.7 / v0.8 era used VHDs
   ≤ 504 MiB, where the ECHS loop is a no-op.
2. FreeDOS FAT32 testing on Windows didn't exercise sizes ≥ 512 MiB
   until the v0.9.30+ Grow VHD UI made it easy to grow past that
   threshold.
3. v0.9.37 fixed the related end_chs LBA-marker bug (FE FF FF
   clamped to footer geometry) but only on the end_chs side, not
   start_chs.

Why the original ECHS rationale (v0.6.2) was wrong

The June 4, 2026 commit f429eb8 introduced ECHS doubling with the
rationale *"AT BIOSes apply ECHS bit-shift translation for any drive

504 MB"*. That model was correct for pre-1996 AT BIOSes which
auto-translated in hardware. But:

• Post-1996 BIOSes + modern emulators (86Box AUTO IDE, QEMU IDE)
  present raw disk geometry to DOS and expect the OS to handle
  LBA explicitly via INT 13h AH=42 for transfers.
• The MBR boot code we install does INT 13h AH=02 (CHS) for the
  one-shot VBR chain read, trusting the BIOS to honor the disk's
  raw geometry.
• ECHS-translated CHS is therefore invalid on every modern target.

The Linux v0.6.3 fix matched empirical behavior (booted 4/8
previously broken VHDs); the Windows path just never caught up.

Fix

src/dosforge/disk.py — removed the ECHS-doubling loop.
partition_chs_heads now uses footer.heads directly, matching the
Linux _rewrite_mbr_partition_entry_for_footer behavior.

partition_chs_heads = footer.heads
partition_chs_spt = footer.sectors_per_track

XT-class layouts (compaq2, msdos33+MFM, ibm8088+dos33+MFM)
take a separate code path (_rewrite_mbr_for_xt_class) and are
unaffected.

Verified end-to-end on Windows

Fresh FreeDOS FAT32 1 GiB VHD before vs. after:

Field	v0.9.51 (broken)	v0.9.52 (fixed)
Start CHS bytes	20 21 00 (head=32)	00 21 02 (head=0)
INT 13h AH=02 result	"invalid head" error	LBA 2048 read OK
86Box AUTO IDE	Blinking cursor	Boots into FreeDOS
MS-DOS 7.10 FAT16	"Missing operating system"	Boots into DOS

Files changed

• src/dosforge/disk.py — removed partition_chs_heads
  ECHS-doubling loop in _create_and_prepare_vhd_no_kernel;
  expanded the comment to document the cross-platform consistency
  requirement.
• pyproject.toml + src/dosforge/__init__.py — 0.9.51 → 0.9.52.

Cross-platform parity

After this release, both Linux and Windows paths encode the MBR
partition CHS using the VHD footer's actual geometry. No ECHS
bit-shift translation on either side.

Carried forward

• v0.9.51 Windows GUI Combobox wheel + focus polish
• v0.9.50 Stamp release artifacts with correct version
• v0.9.49 MartyPC-Xebec preset auto-defaults to FAT12
• v0.9.48 MartyPC compatibility expansion
• v0.9.47 IBM 8088 'DOS Version' picker + PC-DOS 5.x boot mode
• v0.9.37 end_chs LBA-marker fix (companion to this start_chs fix)

dosforge 0.9.51

dosforge 0.9.51 — Windows GUI: Combobox wheel + focus polish

Quality-of-life fix for the Windows GUI (Linux GUI benefits too).

What's fixed

In the New Disk view, ttk.Combobox dropdowns no longer behave
weirdly on Windows:

• Wheel-over-dropdown now scrolls the page. Previously, rolling the
  mouse wheel over (or past) any dropdown — DOS Version, Disk Format,
  BIOS preset, etc. — would either cycle the dropdown's value or "get
  stuck" inside it instead of scrolling the form. Tk's default
  <MouseWheel> class binding on TCombobox is now removed, so
  the page-level scroll handler always wins.
• Clicking outside a dropdown releases focus. Previously, after
  picking a value from (e.g.) the DOS Version dropdown, focus stayed on
  that combobox even after clicking another field — its highlight ring
  lingered and subsequent wheel events could still mutate its value.
  Now any click outside a Combobox transfers focus to the toplevel, the
  same way a native Win32 ComboBox loses focus when you click off it.
• Selecting a value defocuses immediately. As soon as
  <<ComboboxSelected>> fires, selection_clear() runs and focus
  moves to the toplevel — the visible highlight no longer survives the
  dropdown closing.

Scope

Only src/dosforge/_gui/widgets.py (new apply_combobox_polish helper),
src/dosforge/_gui/__init__.py (wires the helper into the Tk root
during DosForgeGUI.__init__), and src/dosforge/_gui/create_view.py
(adds <<ComboboxSelected>> defocus on every _Combo instance) were
touched. The TUI, CLI, and disk/boot pipelines are unaffected.

Tests

New tests/test_gui_combobox_polish.py smoke-tests the helper against a
hidden Tk root (skips cleanly on truly headless runners). All
existing targeted-sweep tests still pass.

Upgrade

No data-format changes. Drop-in replacement for v0.9.50.

dosforge 0.9.50

dosforge 0.9.50 — First Public Release

Build, browse, and mount DOS-friendly disk images on Linux & Windows.

Features
^

Image creation

• Floppies (.img / .ima / .vfd) — 360K, 720K, 1.2M, 1.44M, 2.88M, with optional system-format (/S) for any supported DOS.
• VHDs (fixed Microsoft Virtual PC) — 32 MiB → multi-GiB, FAT12 / FAT16 / FAT32, IDE or MFM controllers, configurable BIOS HDD presets (Phoenix Type 1–47, custom CHS, Xebec).
• Boot mode auto-coerces output settings — pick the OS, get a valid combo.

DOS coverage (real install media, not synthesized)

• FreeDOS (FAT16 / FAT32)
• MS-DOS 1.x, 2.x, 3.3, 3.31, 4, 5, 6.22, 7.10 (Win95)
• IBM PC-DOS 1, 2, 3, 5, 6, 7, 7.1 SGTK, PC-DOS 2000
• Compaq DOS 2.11, 3, 3.31
• DR-DOS 5, 6, 7
• IBM PC 8088/V20 umbrella (DOS 3.3 or 5.0) for vintage 10 MiB MFM presets
• 4DOS shell on top of MS-DOS 7.10

Three ways to drive it

• CLI — scripted one-liners (dosforge create …, dosforge mount …, etc.)
• TUI — full-screen Textual interface (Linux, macOS, WSL)
• GUI — native Tk interface (Windows only)

Image tools

• Mount VHDs read/write on Linux (via qemu-nbd) — browse & edit live in a file manager.
• Extract any file or directory from a VHD/IMG via mtools, no admin needed. Accepts /CONFIG.SYS or C:\CONFIG.SYS.
• Grow VHDs in place — preserves system files, CONFIG.SYS, AUTOEXEC.BAT, and every user file (mtimes intact). Supported on FreeDOS, MS-DOS 7.10, MS-DOS 6.22, and Compaq DOS 3.31 fixed VHDs. Optional headless boot probe verifies the grown image boots before the atomic swap.

dosassets/ — the one folder you'll care about

• Linux: ~/dosassets/ (or any path you pass with --boot-assets).
• Windows: \dosassets\ (it's at the
  root of the install — never inside _internal).
• Drop the raw .7z / .zip install media, the extracted .img / .ima / .dsk, or a pre-extracted directory — dosforge auto-detects all three.

Get started

Linux

curl -L -o /tmp/dosforge.tar.gz
https://github.com/flynnsbit/dosforge/releases/latest/download/dosforge-0.9.44-linux.tar.gz
tar -xzf /tmp/dosforge.tar.gz -C /tmp
cd /tmp/dosforge-0.9.44 && sudo ./install.sh
dosforge # launches the TUI

Windows

1. Download dosforge-0.9.44-windows-x64.zip (or -cli- for headless).
2. Extract anywhere — C:\Apps\DosForge\ is a good default.
3. Drop your DOS install media into C:\Apps\DosForge\dosassets<mode>.
4. Run dosforge.exe for the GUI or dosforge-cli.exe for the CLI.

Releases: https://github.com/flynnsbit/dosforge/releases (https://github.com/flynnsbit/dosforge/releases)

Pull requests, issues, and 86Box / DOSBox-X compatibility reports very welcome.

dosforge 0.9.49

Full Changelog: v0.9.48...v0.9.49

dosforge 0.9.48

dosforge 0.9.48 — MartyPC compatibility expansion

CI green on Linux + Windows.

This release expands dosforge's MartyPC support from "one geometry
that happens to work" (Phoenix Type 1 / 10 MiB Xebec) to first-class
coverage of every controller MartyPC actually emulates.

What's new

martypc-xebec:N BIOS drive-type preset family

MartyPC's IBM/Xebec Fixed Disk Adapter (crates/marty_core/src/devices/hdc/xebec.rs)
does strict CHS whitelist matching against exactly 4 hardcoded
geometries. dosforge now exposes all 4 with dedicated slugs:

Slug	CHS	Size
martypc-xebec:1	306×4×17	10 MB
martypc-xebec:2	615×4×17	20 MB
martypc-xebec:13	306×8×17	20 MB
martypc-xebec:16	612×4×17	20 MB

phoenix:1/2/13/16 keep working (same CHS); the new slugs exist so
your command line documents the target emulator unambiguously.

--disk-controller xtide (new controller class)

MartyPC's default machine config since v0.4.0 uses the XT-IDE
controller (crates/marty_core/src/devices/hdc/at_formats.rs), with
a whitelist of 127 AT-class geometries ranging from 10 MiB to
~520 MiB. dosforge ships the full whitelist verbatim and auto-picks
the smallest fit:

dosforge create \
    --media-type vhd --boot-mode msdos5 \
    --format fat16 --size 32M \
    --disk-controller xtide \
    --path ~/vhd/msdos5-martypc.vhd
# Auto-picks 1024×4×17 = 34 MiB (smallest whitelist fit ≥ 32 MiB)

Constraints (validated up-front, no silent fallbacks):

• No FAT32 (XT-class DOS doesn't understand FAT32).
• No msdos71 / pcdos71 (their FDISK rejects 8088-class geometries).
• Custom CHS must land exactly on a whitelisted entry — otherwise
  MartyPC silently fails to mount the disk.

New documentation

• docs/martypc-compatibility.md — full Xebec + XT-IDE geometry
  reference, build-recipe examples, and troubleshooting notes for
  "it mounted but won't boot".
• dosassets/compaq2/readme.txt — added martypc-xebec:1 variant
  alongside the existing phoenix:1 recipe.

Validation

• 379 tests green across formlogic, size, disk_validation,
  disk_mfm_autogeometry, core_modules, cli, legacy_dos_install,
  boot_assets, e2e_matrix, dos_profiles, pcdos5, and the new
  test_martypc.py (32 dedicated tests).
• Skeleton mirror in sync.

UI updates

• TUI + GUI "Disk controller" dropdown gains
  XT-IDE (XT-class, MartyPC default) as a third option.
• BIOS preset dropdown gains the 4 MartyPC-Xebec entries.
• "BIOS preset" label/text updated to reflect the new vendor
  (Phoenix / AMI / MartyPC-Xebec).
• CLI --disk-controller help text points users at
  docs/martypc-compatibility.md.

Compatibility

No breaking changes. Existing phoenix:N slugs, MFM controller
behavior, and IDE defaults are untouched. v0.9.47 builds remain
byte-identical when rebuilt under v0.9.48 without the new flags.