I just needed a break from chasing the endless Win 3.1 protected-mode bugs, so I started a side project focused on music playback: an experimental OPL synthesizer that I can eventually plug directly into Daveemu’s SoundBlaster/AdLib paths.

daveemu_opl_play is currently a standalone executable, and I kept it intentionally separate for now. It already supports drag-and-drop MIDI playback (.mid / .midi) and has two rendering modes:

• classic (original OPL-style synthesis path)
• enhanced_synth (richer MIDI-style path built for quality and expressiveness)

The classic mode is the straightforward baseline:

• FM register behavior modeled around OPL2-like operator/channels
• light CPU footprint
• immediate “good enough” compatibility focus

The enhanced mode is intentionally heavier:

• more advanced phase and envelope math
• higher-precision pitch and level shaping
• extra harmonic blending and motion modeling (vibrato, drift, unison spreading, per-family tuning behavior)
• optional per-mode oversampling and gain / filter shaping pipeline

In practice it means I can push the tone much further, but at a CPU cost. On my i9-10850K it can do stable live playback today, which is promising, but I still need profiling and optimization before I can embed this path directly into Daveemu.

If you want to hear it, the newest demo is on my channel:
https://youtu.be/Qz9nQNrje5A

This is a command-line demo path, so no dedicated screenshot is attached for this one. Technically, this is also where I am experimenting with math-heavy operators for quality:

• sin, pow, exp, exp2, and related phase-domain operations for stable tone shaping
• exponential envelope curves for note attack/decay/release behavior
• harmonic shaping, saturation and blending before final mix stage

I am deliberately not exposing implementation internals here, but this gives you the idea: richer math, richer transitions, and a much larger palette for FM-like character at the price of more CPU.

While I was there, I still spent the last days on the Win 3.1 protected-mode TTF issue in WRITE.EXE. For now, there is still no visible progress.

Current notes from the investigation show that:

• the failure is still reproducible with WIN WRITE C:\WINDOWS\README.WRI and there is no fix yet
• the document bytes are read correctly, so the bug likely happens after basic DOS I/O
• quick one-line explanations (single bad flag, single bad font entry) did not hold up
• the strongest signal so far is that documents which request TrueType-family fonts trigger the error, while a control document using only classic fonts opens normally
• the current direction is to compare a good document vs a failing one and trace the late font mapping/validation path to find the first real divergence

This investigation is detailed but unresolved, and I probably need to pause it for a while and come back with fresh perspective.

I also fixed a few annoying regressions in the meanwhile:

• cleaned up a Win 3.1 transition bug where exiting Windows to DOS and launching DEFRAG.EXE caused corrupted screen output
• refreshed several legacy UI pieces, including message boxes and the About window

There is still a long list of smaller and bigger tasks in Daveemu. I’m continuing in order:

• finish the TTF path investigation (or at least get it back under deterministic probing)
• keep polishing the OPL toolchain
• keep chasing UI polish and emulator correctness in parallel

Thanks for sticking with this project with me. It has been a marathon, and I’ll need a lot of patience and CPU time.