ugBASIC cross-compiler targetting 8-bit systems

I have found a BASIC cross-compiler that runs on Windows and Linux which compiles code for multiple 8-bit targets, that I thought might interest some of you.

It is called ugBASIC and there is a Windows IDE available. Linux users will need to use the command line tools.

Currently supported targets are highlighted in this list with the Sharp MZ series being worked on next.

It does not currently support loading or saving data files on the target machines, but support for custom assembly code routines was recently added which would allow users to add their own code for this.


This looks really interesting. When it generates the code, it must have to include a significant runtime - to support all the BASIC operations, especially the graphics (which look comprehensive).

Would be interesting to know the “hello world” size?

I only have Dragon and Amstrad emulators installed so far, but “Hello world” compiles to a 2kb .bin file for the Dragon 32 and to a 191kb .dsk file for the Amstrad CPC.

I’m guessing the latter is a complete disk image, as I have a couple of other slightly larger test programs that produced the same size file.

1 Like

Looked into it… six hours later, I can say that has some issues in .6502 asm generation, leading to too large 6502 asm files and .prg files (50230 for 64 and 24065 for vic-20 as output of primes.bas)

Also, Sig. Spedaletti should understand that isn’t needed to repeat the Apache license for every routine included in the .asm file, as I understand said license. (whose complicated the analysis of the generated code…)

on runtime there’s many unneeded graphics-related code in the 6502 .asm runtime, whose of course ends unused (whose is what matters here on intfiction); I warmly suggest an alternative text-only runtime.

the grh examples runs fine, and in the end I think that is an excellent compiler when one needs graphic output (after IFComp I’ll see if my old “64 sprites as HUD” stunt can be implemented on this basic, and how fast is…)

HTH and
Best regards from Italy,
dott. Piergiorgio.

This is what i feared. There should either be a way to switch out unused lib routines or, ideally, the compiler should be able to figure out what services are used from the BASIC program and not include bits like graphics when unused.

The whole problem with targeting 8 bit is keeping things as small as possible. You just cant go around “wasting a few k” here and there.

Neverthless, the system looks new and perhaps much of it is WIP. Let’s hope for improvements. Esp for the popular platforms like C64.

Hello everyone!

I am the author of ugBASIC and I’m really happy that it interests this community!

First of all I confirm that the purpose of the ugBASIC compiler is to generate the most efficient executable possible, mainly in terms of time and then, secondly, in terms of space. However, each 8 bit target has very different characteristics, where the concept of “optimization” could have very different meanings.

As for how it’s implemented, there’s actually no separation between code and library, and there’s no real “runtime”. Code and library are “mixed up” together, on demand. This is especially true if you write procedures that take advantage of multitasking. Obviously, if graphical instructions are used, the system must include everything necessary for relative implementation. Since it is optimized for speed, some information could be precalculated and use a lot of memory, since it is more efficient to read a data than to calculate it on 8 bit processors.

Moreover, regarding the size of the executables, it must be said that (on some targets) these do not change with the complexity of the source code or embedded data. For some of these, such as the Commodore 64 for example, the compiler map as much RAM as possible, disabling ROMs and so on. In this way, when reading the executable, it can take advantage of the standard operating system routines as loaders, thus giving even more space to the user’s code. Think of the PRG as a kind of C=64 memory dump. In other words, the 50KB for C=64 remains the same, almost always.

Finally, regarding the vestigial code, you are right. On some targets I have already introduced support for removal it following the developer’s instructions, through specific DEFINEs. These are optimizations of last resort, which serve to save space when needed. I would extend those techniques also on Commodore 64, as well.

In the coming months I plan to introduce support for read and write access to storage media. This is a really challenging goal because, at the time of the 8 bits, the concept of transversal “standard” on each machine was extravagant, so each one introduced its own (proprietary) way of storing data. Since ugBASIC is an isomorphic language, it will not provide an abstract interface, and thus is even more challenging. I also confirm that the target roadmap will be expanded over time: the project is “open source”, so any contribution is welcome!

Thank you again, and I hope it could be useful for your purpose!

ps. Mr. D’Errico is very right, the generated asm code is verbose, with license duplications. In partial defence, the program output is not meant for code analysis but as input for an assembler, who doesn’t care about the presence of a license in the product code; on the other hand, one of the planned improvements will be to remove all comments except those strictly necessary (as the ones by the IDE). I hope to implement this improvement soon.


I’m glad you managed to find us. Your explanation is much better than any attempt I might have made.

I would like to make a suggestion for the changes you intend to make for the asm comments: make the feature configurable.

I have almost no experience with assembly code, but I would like to learn at least a little for the Z80. Comments in the code would help me understand where any section divisions might be and having license info would be helpful if I reused any of it in my own programs.

I would suggest having at least three options. One that includes all comments, one that only includes comments that aid (human) understanding and one that does not include any comments.

A little like the verbose, brief and superbrief commands available in Infocom games. :slight_smile: