For this vibe coding session, I decided to test Copilot Pro, taking advantage of the few free trial days. And to put all the chances on my side, I started directly from Olivier P’s repository: 👉 OlivierP-To8/BootFloppyDisk


My objective

With ChatGPT, I hadn’t managed to create my own code nor to use Olivier’s project to generate a working disk image for the MO5. Yet, in theory, everything seemed simple: I take the same source, copy it into my repo, compile it, use Olivier’s tools… no reason for it to break.


First success

That’s exactly what I asked Copilot to do: retrieve Olivier’s example, compile it, then generate the disk image.

And then… a technological miracle: it worked on the first try.

Copilot struggled a bit to replace the text from Olivier’s sample, but after a few attempts, it finally succeeded. A first, very motivating win!


Second objective: handling keyboard input

Right after that, I jumped into a more interactive test.

The idea was simple:

  1. display “What is your name?”
  2. allow the user to type their name
  3. display “Hello ”

And that’s exactly where things started to get complicated…


Where everything got stuck

After several iterations, Copilot managed to:

  • correctly display messages
  • capture keyboard input
  • store the result in a buffer
  • confirm in debug that the characters were properly stored

But it was impossible to display the name. After “Hello “, the screen stubbornly remained empty.

I could type a name, I could verify it was in memory… but the display simply refused to show it.


Copilot’s final analysis

After a few hours circling around the problem, I asked it to generate a summary. Here is what came out of it.


✔️ What worked

  • display of static messages
  • keyboard input with echo
  • correct storage in the buffer
  • debug verification: the buffer does contain the entered characters

❌ What didn’t work

  • the buffer display loop after “Hello “

🔬 The critical discovery

By going as far as analyzing the source code of the Maurice emulator (written in Rust), Copilot discovered that it only supports:

  • K7 cassette reading
  • K7 cassette writing
  • motor control
  • light pen

And most importantly:

Standard SWI calls $02 (PUTCHAR) and $0A (GETCHAR) are not implemented in the emulator.

Which explains why the system display routines produced absolutely nothing.


🔧 Attempted solutions (unsuccessful)

  • standard SWI (swi + fcb $02)
  • direct calls to ROM routines (jsr $D52D)
  • addresses supposedly intercepted by the emulator (jsr $F1B0)
  • CWAI approach (blocks the program)
  • direct reading of I/O ports

All of them led to the same result: the name never displayed.


🎯 Copilot’s conclusion

According to Copilot, the bug most likely came from DCMOTO / Maurice, not from the assembly code itself. It even recommended testing the program on a real Thomson MO5, which would confirm that the issue lies in the emulator.


Wrap-up

A bit disappointed with the result: the request seemed simple, almost “basic”, and yet… Without a fully compatible emulator, some features become simply impossible to validate.

So it was time to try another development agent

To be continued. 🚀