How to avoid deploying unused subsystems (video, print) on targets that use only raw hardware?

[lucat77]

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:

• 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 performance-critical parts (the actual playback loop, FX engine, sample mixing) are all written as inline ON CPU6809 BEGIN ASM blocks, so ugBASIC is essentially acting as a smart glue layer and build system.

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!

[spotlessmind1975]

Hi lucat77, and welcome!

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?

Thank you so much for your very interesting message. If I understand your requirement correctly, you would need to produce a binary that eliminates anything ugBASIC doesn't use. This is an ambitious goal, and I'm not denying that it should be possible to achieve.

Theoretically, no flags are necessary because ugBASIC's generation system doesn't include anything that isn't actually used. To test this, I tried compiling an empty source code—that is, one with no instructions—for the pc128op tartlet. The generated file takes up about 1.600 bytes. This is, in fact, a space that could be reduced, as I see it continues to introduce a lot of unnecessary code.

I'm working on it and will let you know!