After my experiments with Augment, I had an idea in mind for a few days.
Create my own C library to make development on the MO5 easier.

Nothing huge.
Just something to avoid rewriting the same bits of code over and over again.

Augment had already generated a few utility functions.
But the ones that felt truly fundamental to me were these:

char mo5_getchar(void)
{
    asm {
        swi
        fcb $0A
    }
}

void mo5_putchar(char c)
{   
    asm {
        ldb c
        swi
        fcb $02
    }
}

In my head, everything started from there.
Those two functions as a base, and then rebuilding the rest around them.

I set myself a simple goal: a “light” / simplified version of:

  • mo5_stdio
  • mo5_ctype
  • mo5_string

A solid foundation to start with.

Back to the old-school way

For this mission, there was no way I could rely on Augment.
I had burned all my credits the previous weekend while developing my RAG server.

Nothing left.

No credits

So no choice: code the old-school way

  • type the code by hand
  • think
  • mess up
  • fix
  • repeat

I reused what Augment had already provided and started implementing my libraries one by one.
Each time, I tested them in a small test project running in the DCMOTO emulator.

Things were moving forward pretty well… well… almost…

getchar(), my first wall

I wanted to wrap mo5_getchar() into a cleaner getchar().
On paper, it looked trivial.

In practice: corrupted buffers, weird characters, inconsistent behavior.

In short, it smelled bad.

After a while, I gave up and went for the simplest solution:

#define getchar mo5_getchar

It’s not pretty… but it works…

Pride… then discomfort

Once my libraries were functional, I was quite happy with the result.
Happy enough to start writing a few small tutorials to show them in action, and even to imagine the content of my next article, about how I had single-handedly managed to provide the community with THE essential libraries for the MO5!

But while coding, one thought kept coming back:

It’s still strange to have to rewrite these basic functions…

During my first searches about C development on the MO5, I had only found examples:

  • in BASIC
  • in assembly

Not really any C examples.

Still… something felt off…
It felt like too much…

cmoc, the silent traitor

I went digging into the installation directory of cmoc.
And there… surprise!

Inside cmoc/include, I found several .h files.
No stdio.h, no ctype.h, no string.h.

But one file stood out: cmoc.h.

I opened it… and then… smack.

Many of the functions I had painfully rewritten were already there:

  • putchar
  • memset
  • strcmp
  • memcpy
  • strlen
  • isprint
  • and even printf

😑

So I tried simply including:

#include <cmoc.h>

A few tests later, the verdict was clear:
my homemade libraries had become completely useless… redundant… obsolete before they even existed…

Back to official functions

I rewrote my samples using the functions provided by cmoc.
And honestly… it’s much better this way.

Reinventing the wheel can be fun.
But when a wheel already exists, tested and documented, you might as well use it.

There’s still one thing missing though:
I couldn’t find a real getchar().

There is readline(), but it waits for the user to press Enter.
No way to read a single character (for example: “Press Y to continue”).

I also ran into a few instabilities when using printf(), but that most likely comes from my own code.

Lesson of the day

I should have had this reflex from the start: a C developer checks the .h files first.
That’s the basics.

I let myself be carried too much by the AI.
It answered my need, but without the right context, it preferred to rebuild everything instead of reusing what already existed.

What I take away from this

My first lesson was that vibe coding with AI is expensive (I spent my 40,000 credits in three half-days).

This experience brings me another lesson: without precise context, AI tends to reinvent the wheel (when it doesn’t hallucinate).

For classic developments, like .NET microservices, AI has very good context because it’s “standard” development.
For my MO5 project, which is clearly a niche project, it’s a very different story.

You therefore have to explicitly provide the context, and in detail.
If you don’t clearly tell the AI that something exists, it won’t find it: documentation is limited, sometimes nonexistent.
Parallel research is therefore essential in order to guide the AI properly.

My RAG server project makes even more sense now.
I’ll be able to enrich it with this experience, so that next time, the AI can directly use the existing libraries.

In the end, running out of credits on Augment turned out to be a very good thing.
It forced me to investigate on my own and discover these “hidden” functions (or at least unknown to the AI… and to me).

And ultimately, it allowed me to avoid reinventing the wheel.

In summary for Day 7:

  • Less magic
  • More reality
  • And a good C developer slap 😉

The code associated with this article is available here:
https://github.com/thlg057/mo5-tuto