MSX FLASH cartridge.

I just received a few prototypes of my new FLASH cartridge for MSX computers.

In the past, I created several prototypes based on the copy/paste file principle under Windows.

This approach caused issues with the low-level connectivity of the USB bus, which meant that after developing the very first cartridge prototype equipped with a processor that handled all the operations, I had to switch to using two processors. That's when I created the second iteration of my cartridge.

With this second prototype, I was able to observe in situ all the transfer issues caused by the asynchronous nature of USB transfers. In particular, it's never possible to know whether a transfer was successful or not. Worse, there's no way to determine if a transfer is complete or not, hence the impossibility of controlling anything.

So, I had to change my approach and opted for a more reliable protocol. I decided to use the Ymodem protocol instead, which allows for full control over the sequence of operations. On Windows, I relied on the Hterm tool, as it provides a stable implementation of the Ymodem protocol.

I also chose a new STM32H5xx-type processor, which has more built-in resources than the RISC-V circuits I used before, greatly simplifying the schematic.

The result of this new design is as follows:

Now that I have the new cartridge in front of me—so much simpler than previous iterations—I have to admit I’m wondering whether I’ll actually manage to implement all the planned functions.

I also need to integrate a software reset system I’ve been designing. This last point is critical because it should allow rebooting the MSX computer without touching the ON/OFF switch.

Moreover, since the very beginning of this cartridge’s development, I’ve absolutely refused to rely on a configuration phase—for example, toggling between programming mode and usage mode by selecting an option at the MSX’s startup.

To me, it’s utterly unbearable to have to press a key within an extremely tight timeframe (inevitably shorter than the LCD screen’s video signal detection delay) just to choose a mode. The result? You have no idea what you’re doing. Frankly, this approach is just idiotic!

Now, the only remaining step is to port my earlier tests from the dev board to this final version. After that, I'll need to confirm the hardware implementation works flawlessly.