I started with my port of ELIZA, which itself is a port to C from the MITS BASIC port published in Creative Computing Magazine in 1977.  I put a copy of the article in the files section.  My retrocomputer uses circular buffers (FIFOs) for input and output between the applets like ELIZA and the terminal code so there was also a virtual host API shim to adapt the ELIZA port to those buffers.  I figured it would be a good interface to a USB UART API (and it was).

What I didn't have was USB UART functionality that would run on the USB peripheral.  I guessed that ST would have some library that ran on their parts and hoped it would work with the Flashchip part. 

Along with the 'F096 parts, LEDs and buttons I had impulsively purchased from LCSC, I had included a $7USD FCM32F103 development board.  This turned out to be very helpful as their - now discontinued - 'F103 part was sufficiently a clone that it could be programmed by an STLink programmer.

I used STM32CubeMX and STM32CubeIDE to put together a project for the ST32F103 part with the USB peripheral enabled and a CDC Class USB UART library.  It took a moment to understand how the library worked, and a bit more work on the virtual host shim but the ELIZA re-port itself was pretty quick and in a few days I actually had it up and running.  It was at this point I felt that this whole project might actually be possible.

The virtual host shim layer really provides two functions.  It pushes and pops characters to and from the USB library buffers, and it implements a couple of utility functions, like clear screen, that the BASIC port had used.  The clear screen function sends the ANSI escape character sequence to clear the terminal screen.  For this reason the output will look a little wonky in a non-ANSI terminal emulator (like CoolTerm which I use on Mac and Windows).

The major pain point during this test port to the 'F103 was actually programming the part.  The Flashchip development board came with a DAPlink programmer and no matter what I did, I couldn't get it to work.  Programming always failed after I dropped the bin or hex file into the DAPlink folder.

Fortunately I had another ST development board and I could wire a set programming header to its built-in STlink programmer.  This worked.  The programmer saw the chip as a legit ST part and programmed it.

No doubt ST would not be happy about this - and, I suspect, they weren't and that's why there is no FCM32F103 part anymore.  But, to be honest, it sure saved me a lot of time to be able to use their tools.

Technically my use of the ST library on a non-ST part is against the terms of the USB library license agreement and for that reason I don't feel comfortable publishing the complete source code for the whole project (although I will share the code I wrote and the gerbers).