MSX FLASH cartridge.

So, does this cartridge work now? 

Well, no, it still doesn't work.

Here's a recap of the situation:

I first developed a cartridge version using Chinese-origin RISC V processors. The goal of this cartridge was to enable the downloading of MSX executable files directly into FLASH from any PC, which could later be executed by the MSX computer.

RISC-V prototype with one processor

 

 

 

RISC-V prototype with two processors

RISC-V prototype plus HF port for MSX reset

While my developments were successful on the MSX machine I had, it turned out that I encountered various problems on other people's MSX computers. So, I opted for a faster processor, the STM32F525 type. I also fixed several issues during this new development phase.

ARM STM32 processor 

Everything was working very well, until I tried to start my MSX computer with this new cartridge. And this time, I never managed to get anything to boot. After thorough investigation, I finally determined that the issue is simply that this STM32 processor is not capable of changing its input/output pins state quickly enough to serve the MSX computer.

I could have tried to use more suitable peripherals, such as the external memory management systems available on STM32s, but that requires twisting your mind more than reasonably necessary, without having any visibility on the outcome. 

It's not about mastering the bus like reading from or writing to external memory, or generating a video image. No, here it's about behaving as a slave and serving data with strict timing. 

So I thought about Raspberry products, specifically the RP2350 microcontrollers. This component seemed better suited than the microcontrollers used up until now. So, I installed the development solution based on the Visual Studio Code editor, plus the Raspberry toolchain.

Alas, as soon as I opened Microsoft's editor, buttons of all kinds sprouted all over my face. I found, with just as much detestation, the installation examples that are never updated and don't match the situation, and especially the various and sundry messages from Visual Studio Code that mean nothing regarding the problems encountered – except for those who were bottle-fed this crap from earliest childhood at university.

In short, the whole "it should work, but who knows anyway, he clicks, he clicks, he'll get there, and if he doesn't, he's an idiot and we don't care!" attitude.

Anyway, I uninstalled all that crap faster than the installation took.

There are also ESP boards, but the DIY/hacky aspect of the subject today acts as an absolute repellent for me.

So? Well, if I consider that the only viable solution for connecting memory to the MSX bus is to use good old-fashioned logic, then I'm going to try using a small FPGA, actually condense my first idea into an FPGA to facilitate PCB routing rather than doing it like on my very first cartridge prototype :

 

The very first prototype but not with the right use of USB

Here again, the solution isn't simple either. There are FPGAs of all kinds, but most are unsuitable for my needs. So I fell back on Efinix FPGAs. And there, I'm venturing into the unknown once again.

Indeed, a few months ago, I tried to implement a Z80 system in a TRION FPGA for my attempt to create a new Drumulator, but without success. I had therefore decided to go with another hardware solution, even if it meant reprogramming the Drumulator's software. I actually developed the audio part of the Drumulator with an STM32 microcontroller. I did this development with EasyEDA PRO, and I must say that thing is a real nightmare. Buggy everywhere. I wonder what it will be like in a few months, since EasyEDA has decided to stop developing the standard version in favor of the Pro version. So, discontinuing a functional version to force users onto a buggy one: hmm...

As a result, I redeveloped the analog part of the Drumulator with KiCad.

But, to get back to the MSX cartridge, Efinix FPGAs have all the desired features, plus at a reasonable price. But, and there's always a but, I also need to implement a small processor on the cartridge to manage the transfer from the PC.

And there, I made a decision that I hope won't lead me to a dead end, which is to use the soft-core RISC processor provided by Efinix.  

So for now, I've contented myself with creating the inevitable 'Hello World' for electronics engineers: making an LED blink, but not through logic wired inside the FPGA, but rather via the Sapphire processor implemented within it. Everything is ready for the first tests.

However, since the internal processor also needs to be programmed via JTAG, it's not possible to share the JTAG port already integrated on the development board, which is used for programming the FPGA. Therefore, this other JTAG port needs to be managed with suitable hardware, in this case, an FTDI cable that offers the JTAG protocol. I've ordered one.

I can attempt to make an LED blink as soon as I receive it.

I must admit that my developments over the last few months, or even for almost two years now, have yielded nothing truly conclusive. My latest achievement remains my TMS1122-compatible (UTC 1122) digital clock, which I had to complete in 2023. It works wonderfully. You can find the description of this clock on this blog... somewhere in 2023, I think.

It's high time that all the experience accumulated over these past two years finally leads to something concrete! 

Is it me getting really old, or is the completely idiotic atmosphere prevailing in France and Europe finally getting to me? Probably a bit of both. 

Back to the Future...

What a surprise it was when, upon returning from a few days of vacation, I found signs in front of every newsstand displaying the year 1976 in large print. All over the city where I live—1976, everywhere!

It was a call for testimonies about THE 1976 heatwave :

Indeed, at the age I was back then, I was a good five years too young to realize that the major event wasn’t that fleeting wave of high temperatures, but the tsunami that had just begun in the U.S. with the release of the Apple II.

So, out of curiosity, I stepped into one of those newsstands and absentmindedly glanced at the electronics section—which, by the way, hasn’t existed for years now—and the computer section, still as dull as ever, rehashing the same stories for over two decades. I was about to leave the shop, as disheartened as usual, when my eye caught a rather unusual cover: Retro Bit!

So?

Well, I immediately remembered that I’d been interested in this Italian publication and had tried to order the first issue. But when I saw the exorbitant shipping costs, I gave up. The magazine itself is still very expensive—too expensive for what it offers, really. But does a dream have a price?

Reading this issue of RetroBit (number 6, currently) is enjoyable and effectively immerses the reader in the era it covers—though with some digressions about today’s happenings.

Despite the magazine being written in French, it’s clearly a translation, likely done by AI, as some phrases are downright absurd. But hey, that’s part of its charm…

I remember with deep sadness the early ’90s, when the microcomputing magazines I’d discovered and read for nearly a decade began gradually disappearing.

So it’s with great pleasure that I discovered this new magazine on newsstands. Because let’s face it, things have been heating up lately in the world of retro computing. I already mentioned Commodore’s ‘rebirth’ in my previous post, but we should also highlight the incredible success of the Kickstarter campaign for the ZX Spectrum Next Issue 3!

 And the new version of the Commodore 64 : 

 

Will there be a new 8-bit war?

That would be a grave mistake. Everyone knows what would happen to this budding 'true' revival of the 8-bit micro era.

As my industrial computing professor told me back in 1993: 'You're an 80s guy at heart.' I arrived too late to fully enjoy that golden age - and I certainly don't intend to miss out on the new one coming!

Other sugject :  

I’ve decided to dust off my old FPGA card to experiment with video interface design. As mentioned in a previous post, I developed a small add-on board providing a few megabytes of static RAM. I’d attempted similar projects before but never achieved the desired results. This time, I redesigned the board with more modern components.

Admittedly, I won’t reach blazing speeds due to signal path length, parasitic capacitance, and other inherent challenges—but it should still handle basic 1024×768 resolution just fine.
 

 

Commodore is....

 REBORN!!!

Christian ‘Peri Fractic’ Simpson is the new CEO

08/01/2025
 

 
Back to basics...

Over a decade ago, I invested time in learning FPGAs. At the time, I thought it was a good idea—and I was probably right. Back then, microcontrollers didn’t have the performance they do today, and replacing all or part of legacy hardware could really only be done this way.

I had bought an Altera DE2-70 development board. FPGAs were all the rage, and although prices had become affordable, they started rising again. Even that wasn’t enough for Altera to survive on its own, as it was acquired by Intel a few years ago. Now, Intel itself isn’t in great shape either. The swan song of American tech?
I considered using FPGAs until 2019...

when I discovered GoWin FPGAs, which were much more affordable than Intel's. But then came 2020 and COVID—and boom, GoWin FPGA prices skyrocketed as well. Once again, I was stuck.

Then came Efinix chips. However, while I found GoWin’s development software somewhat clunky, Efinix’s tools are, in my opinion, a complete disaster—unintuitive, slow, and prone to crashing. Whether it's GoWin’s IDE or Efinix’s, neither is a good tool for development. But then again, that’s just my opinion, and I’m not a professional in the field.

My Big Mistake:

Whether using GoWin or Efinix software, I stubbornly tried to develop entirely within their ecosystems. And, true to my habit of persisting in error, I spent months wrestling with these tools. While I managed to get decent results with GoWin’s IDE—though with far more effort than I’d have liked—my attempts with Efinix’s IDE ended in outright failure.

My approach was simply foolish, and here’s why. The learning curve and overall usability of Quartus (Altera/Intel’s development software) had been, by far, the smoothest for me. I’d built solid experience with it and gained a strong command of VHDL. And here’s the kicker: VHDL works flawlessly with both GoWin and Efinix FPGAs. See where I’m going with this?

Yep—the much less stupid strategy would have been to develop on Altera’s platform first, validate the project there, and then port it to GoWin or Efinix. At worst, I’d only have needed minor adjustments for the target platform’s IP blocks.

Better Late Than Never

That’s exactly what I’ve decided to do: go back to an "easy" development environment to build my projects, then port them to my final platform of choice.

Luckily, Intel still provides the necessary software for the DE2-70 board—version 13SP1—so I’ve reinstalled it on my PC. And compared to my decade-old machine, my current computer should compile much faster, making this "old" board even more practical to use.

Tackling Video Signal Generation Again

This time, I’m revisiting video signal generation. While the DE2-70 has multiple types of RAM, it unfortunately lacks SRAM. And since I want my FPGA projects to be as portable as possible, I need to avoid platform-specific IP blocks—especially those handling dynamic RAM (DRAM).

Luck Is on My Side

Because over the past ten years, static RAM (SRAM) has improved significantly in capacity, price, and access time, interfacing SRAM with an FPGA is straightforward—aside from the high number of electrical connections, but that’s manageable.

Since I only need a modest video interface (limited pixel depth and color range), I can now get by with just a few SRAM chips while still achieving good resolution and enough colors.

And here's the small expansion board I plan to build to provide the DE2-70 with enough SRAM for video interface purposes. I've attempted similar expansions before, but the results weren't satisfactory in terms of access time. I believe I now understand why - this time, I'm taking a different approach. 

Here's what the physical implementation should look like:

The GPIO connectors obviously won't be implemented on this side since the board needs to be plugged into the DE2-70's connectors. I've also added a small connector to enable SRAM loading from an external processor board - I remember not including this feature last time and struggling immensely when trying to use a Z80 processor embedded in the FPGA itself.

That approach made real-time debugging impossible, preventing me from running code step-by-step to verify the VHDL video interface behavior. Essentially, I had two potentially buggy systems in the same FPGA code - how could I possibly determine which one was causing issues? This time, I'm not repeating that mistake.

 

Drumulator clone with STM32 processors.

There are times, when you truly don’t know which direction to take. At first, I partially replicated the Drumulator's functionality in a GoWin FPGA. Later, I attempted the same adventure with an Efinix FPGA. That’s when I ran into the challenge of completing the machine—specifically, implementing the entire Z80 interrupt system in this Efinix FPGA. I didn’t succeed.

During this process, I realized that developing something "new" in an FPGA isn’t very practical. The reason? Well, there’s no real-time debugger like you’d find on any microcontroller. So, I tried using a processor instead and went with a very interesting RISC-V processor. Unfortunately, as I progressed, I realized I wouldn’t be able to fully achieve my goal this way.

Then, I came across STMicroelectronics' announcement of a new member of the STM32H5xx family. Looking at its specs, I noticed it was very similar to the previous RISC-V processor—but with every feature doubled: RAM, flash memory, and operating frequency. I figured it was worth giving this microcontroller a shot.

Then, after a period where I could no longer get STMicroelectronics' STM32Cube IDE to work properly on my Windows machines (dealing with installation crashes, missing packages, and other issues), I decided to try again with this new processor. I installed CubeIDE and CubeMX - miraculously, it worked perfectly on the first attempt.

So I embarked on this new adventure, building on the various tests I had previously conducted with the RISC-V processor regarding waveform generation. However, I decided to approach this as two separate projects: first developing the analog section for sound generation and processing, and then - if successful - completing the control panel.

After numerous iterations, here's what the analog board should look like.

This is a first draft. I haven't attempted to route this circuit yet. I may need to make some adjustments to the placement of certain component blocks. And even assuming the circuit works as intended, I'll still need to verify the audio quality - particularly how it handles (or fails to handle) the various interference patterns generated by the processor.

I'm not done yet.

The positive aspect is that with this circuit and the tests I conducted while designing my MSX cartridge (which uses the same processor), I should be able to implement waveform switching relatively simply. This approach eliminates the need for larger PCBs containing multiple memory circuits.

Well, having worked on multiple units of the original Drumulator circuit during repairs, I have to admit the final PCB is significantly more compact and uses far fewer components. It's nothing like the board in EMU's machine.

Of course, there's still the control panel to develop. But even that only requires a few additional elements compared to EMU's version - just some LED drivers, two keyboard multiplexing circuits, and that's about it...

UPDATE 08/01/2025

My Experience with EasyEDA Pro:

I tried using EasyEDA Pro to design the analog section of the Drumulator. After spending some time with it, I’ve concluded that this development tool is absolutely not for me—it just doesn’t suit my workflow at all. The limitations and its general behavior ended up frustrating me to no end. As a result, I’m going back to good old KiCad to redesign the board, with a few minor tweaks. The overall concept remains the same, but I’m changing how some components are physically laid out. Normally, I believe that fewer different elements in a system mean easier debugging and better reliability, but this time, I’m doing the opposite—adding more components to simplify things. Surprising, right?

Tech Rant: The State of Software & Forced Bloat :

And speaking of annoyances, I’m getting increasingly fed up with how systems and applications behave these days. The way they push—or rather, force—users to accept commercial nuisances is beyond frustrating. I’ve already stopped using Firefox except for certain sites that require specific resources. Otherwise, I never use Bing, and Opera and Firefox are now limited to just a few websites.

Unfortunately, I’m stuck with Android on my phone for now, but these so-called "updates" are just excuses to bombard users with checkboxes, tricking them into installing bloatware. And even then, some apps can’t be refused upfront—you have to uninstall them afterward. Needless to say, I won’t be switching to Apple. It’s the same nonsense, just worse and more expensive! This trend is spreading to more and more software.

My Solution? Linux + Minimalist Setup:

So, my plan is to set up a small Linux machine and keep my Windows PC strictly for development tasks. On Windows, I even use a portable browser instead of installing one. As for my phone, the only reason I’m still on Android is one essential app. The second I find an alternative, I’m switching back to my trusty Siemens B615! 

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.

STM32 processors, in fact...

I mentioned in a previous post that I wasn't about to use the STM32 family of processors again. I had been testing with an STM32H5xx processor, using the STM32CubeIDE development software and its 'friend', STM32CubeMX, since for the first time in a long time, the software suite was working for me.

It's true that the new STM32H5xx processor family is interesting for several reasons. On the one hand, these processors are fast, they can operate at up to 250 MHz and, above all, some models offer 512 KB of flash memory and more than 272 KB of SRAM memory.

I then thought that this could allow me to develop a new version of the MSX cartridge that could be loaded via the USB port.

In my previous cartridge version, I used the principle of external mass storage. To simplify, the MSX cartridge behaves like a USB flash drive. Subsequently, the file recovered on a FAT12 file system type media, was recovered and copied in RAW format to the cartridge second processor.

This is what the cartridge looked like:

In fact the right processor retrieved the file through the USB port connected directly to a PC. Then sent the retrieved file directly in RAW format to the second processor which 'provided' the data directly to the MSX computer.

This system wasn't easy to develop for a number of reasons. Most importantly, file transfer from a PC is unreliable. Not because the data could be corrupted, but simply because it's completely impossible to know if the entire file has been transferred!

And that's not practical at all!!!

Additionally, the processors used were a bit more modest in terms of Flash and SRAM resources.

So, I wondered if it would not be relevant to try the adventure again on one of these STM32H5xx processors.

However, I had two 'problems' to resolve. The first is that I no longer have to use file transfer in the file system sense, but rather a transfer in the sense of direct byte transmission. So I chose to use a serial file transfer using the YMODEM transfer protocol.

The Ymodem protocol allows you to receive the name and size of the file, which can be interesting, but above all the transfer is done in specific blocks with possible CRC correction, which suits me very well.

The second problem for me is not having to use what seems to be something downright overly complicated on the system provided by STmicro (see my previous post) : the USB function of the STM32 processor. So, I decided to go straight for a small external USB/serial converter circuit.

This last point will also allow me to set up good galvanic isolation between the PC and the MSX computer.

In short, this change of direction should allow me to make the operation of my MSX cartridge more reliable. Because although I have never had any operational problems with my own MSX computer, it has happened that it did not work correctly on other MSX, without me being able to determine the reason for these malfunctions.

Here is what the first prototype of this new study looks like, based not on a RISC-V processor but on an ARM processor from the STM32H5xx family :

To summarize, this new version offers a faster processor, a more secure and controllable file transfer system, and better galvanic isolation.

I have already carried out some preliminary tests on a study board, namely transmission with Ymodem and programming of the internal flash of the processor.

Additionally, I should be able to install a more convenient status indicator system than the two original LEDs.

This new cartridge should also allow me to automatically reboot the MSX computer without using an external system. It should also be able to integrate different mappers for a total of 256KB of memory. Finally, my system should also be able to be updated using the same file transfer mechanism. I have already successfully performed code relocation tests on this new processor.

Transfer times should remain fairly short, given that I chose a speed of around 230Kbauds, which did not cause me any transfer problems during my tests. A full cartridge should therefore be able to be transferred in around ten seconds, plus the writing time in FLASH, which will also remain very low.

And so, I now think of using this processor in my study on the construction of the Drumulator type drum machine...

A few days later...

The request for a prototype PCB has been made. I'll then be able to work directly on a properly assembled circuit. This will already save me a lot of unpleasant surprises, especially those caused by assembling the processor by hand...