How to avoid deploying unused subsystems (video, print) on targets that use only raw hardware?
Posted: Sat Mar 21, 2026 5:36 pm
Hi everyone!
I'm Luca, and I've been using ugBASIC to prototype a tracker player for the Thomson MO6, also known as the Olivetti Prodest PC-128 in Italy — my very first computer at age 10, and now the subject of an interesting challenge.
What is this project?
The idea is simple: export a song from Furnace Tracker in a custom binary format (2 channels, mono PCM DAC) and have the MO6 play it back — similar in spirit to what the Tiuna export does for the Atari 2600. Each channel uses a 256-byte wavetable (like Music 3 Voix does in the 80s https://dcmoto.pages-perso.free.fr/prog ... index.html), with support for a couple of effects: pitch slide and arpeggio.
The MO6 has no dedicated sound chip, so everything goes through the DAC at $A7CD — which makes the timing constraints very tight and the whole thing quite a fun challenge.
Why ugBASIC?
ugBASIC has been invaluable for this project. It let me:
The problem I'd like to discuss
The generated main.asm — and consequently the .bin — includes the full ugBASIC runtime: video subsystem EF936x, SN76489 audio init, banking infrastructure, variable init stubs, and more. In my case none of that is needed, since the program uses only the DAC directly and has no graphics at all.
Result: a .bin that overflows the resident memory window and crashes on load.
My current workaround is keeping the song binary small enough to stay within limits while I continue prototyping. The long-term plan is to produce a clean hand-written main.asm for the release build, with only what's actually needed.
But I'm curious: is there any mechanism in ugBASIC — a flag, a pragma, or a target configuration — to suppress deployment of unused subsystems (video, audio chip init, etc.) for a target? Something like a minimal/bare-metal mode for targets where the program manages all hardware directly?
Thanks for any insight — and thanks to Marco and the whole community for building such a useful tool for retrocomputing exploration!
I'm Luca, and I've been using ugBASIC to prototype a tracker player for the Thomson MO6, also known as the Olivetti Prodest PC-128 in Italy — my very first computer at age 10, and now the subject of an interesting challenge.
What is this project?
The idea is simple: export a song from Furnace Tracker in a custom binary format (2 channels, mono PCM DAC) and have the MO6 play it back — similar in spirit to what the Tiuna export does for the Atari 2600. Each channel uses a 256-byte wavetable (like Music 3 Voix does in the 80s https://dcmoto.pages-perso.free.fr/prog ... index.html), with support for a couple of effects: pitch slide and arpeggio.
The MO6 has no dedicated sound chip, so everything goes through the DAC at $A7CD — which makes the timing constraints very tight and the whole thing quite a fun challenge.
Why ugBASIC?
ugBASIC has been invaluable for this project. It let me:
- debug incrementally without writing everything in pure assembly from day one
- understand the hardware constraints of a platform I knew nothing about
- use PRINT to inspect variables in real time
- generate a .k7 cassette file immediately and test on the real machine (or emulator)
The problem I'd like to discuss
The generated main.asm — and consequently the .bin — includes the full ugBASIC runtime: video subsystem EF936x, SN76489 audio init, banking infrastructure, variable init stubs, and more. In my case none of that is needed, since the program uses only the DAC directly and has no graphics at all.
Result: a .bin that overflows the resident memory window and crashes on load.
My current workaround is keeping the song binary small enough to stay within limits while I continue prototyping. The long-term plan is to produce a clean hand-written main.asm for the release build, with only what's actually needed.
But I'm curious: is there any mechanism in ugBASIC — a flag, a pragma, or a target configuration — to suppress deployment of unused subsystems (video, audio chip init, etc.) for a target? Something like a minimal/bare-metal mode for targets where the program manages all hardware directly?
Thanks for any insight — and thanks to Marco and the whole community for building such a useful tool for retrocomputing exploration!