MSX Flash cartridge, VGA interface, FPGA...

Since the September term started, I haven't been idle.

The first topic I tackled is the flash cartridge for MSX computers.

To recap, it's been almost two years now that I've been trying to develop a cartridge for MSX computers, originally intended to include only FLASH memory that could be programmed directly via file transfer from a PC/Mac/Linux.

I first developed this cartridge using a fast processor of Chinese origin and of the RISC-V type. Then, two processors, because at the time I was using the concept of copy/pasting to the cartridge, which was seen as a small USB key, the constant interruptions from the PC's USB port ended up causing the MSX computer to behave erratically. I also evolved the concept to allow for a hardware RESET of the MSX computer during the loading phase.

However, although this cartridge worked very well on the MSX machine I owned, a clone created by Sergey Kiselev, the cartridge worked randomly on other machines.

It's true that I was using the speed of the embedded processors to present the Flash content directly to the MSX during read operations from the Z80.

The Sergey Kiselev MSX system. https://github.com/skiselev

And therefore, the timing of the MSX bus signals must be precise.

Having observed these issues, I decided to use a processor from the STM32 family this time, which is twice as fast. I also changed the loading concept. I now use the YMODEM protocol via a serial link, instead of a disk-to-disk file transfer. Furthermore, this allows me to control the file reception process very precisely, including verifying its integrity.

The new cartridge was very pleasing visually because it was much simpler than the previous versions. But... I never managed to get an MSX program to start from its contents. I then realized that I didn't have precise specifications for the maximum operating speed of the GPIO pins on the STM32 processor I used. The configuration software only offers three speed levels named Low/Medium/High: not very precise!

I should have used a logic analyzer to see what was really happening, but after running a few tests, I realized that the processor was capable of changing its output GPIOs very quickly. However, the problem lies in its reaction time relative to its inputs.

Conclusion: perhaps an RP2040 or a more recent processor could have done the job, but I never had the opportunity to evaluate that type of processor, so I moved on to a new hardware concept: the FPGA.

The idea is to connect the flash memory directly through wired logic, rather than providing the data from a processor executing code.

The problem is that FPGAs are relatively expensive compared to RISC-V or ARM microcontrollers. This is also true for CPLDs, which are simpler and could still have been suitable, but to which I would have had to add a file reception and processing processor anyway.

So the resulting idea is simple: implement in an FPGA the logic for multiplexing access to the FLASH memory, allowing accessibility on one hand by the MSX computer, and on the other hand by the cartridge's embedded processor to program the file received from the PC. Also, to implement within it the processor for receiving and processing data from the PC.

Among the range of FPGAs available on the market, one brand offers FPGAs at a very competitive price: Efinix. It should be noted that there is a reason why these FPGAs are more affordable. They don't offer exactly all the features that a more standard FPGA might have. Having worked a bit with these circuits, I know what their limitations are, and I am therefore in a position to know that this does not pose a problem for my project.

An affordable dev board.

So, I ran a few tests with a small Efinix development board. I implemented the RISC-V processor provided as an IP core by Efinix. This processor works very well, and, as an added bonus, its programming and debugging are done in real-time using a specific version of Eclipse.

The only difficulty I encountered was getting the Eclipse environment to recognize the JTAG probe I bought on Aliexpress. The problem was with the JTAG probe itself. I had to perform a small programming operation on it to get it to work correctly.

FTDI Chip USB to MPSSE Cables

I'm not criticizing the AliExpress vendor for their prankster side, but in terms of fair play, there's room for improvement!

Once these tests were completed, I decided to have a small extension board made, providing FLASH and SRAM, because I figured that it would make the cartridge more versatile. It also includes the USB port for communication with the PC, as well as the necessary connectors for programming and real-time debugging of the processor.

The phase of managing the YMODEM protocol should be fairly easy to implement, given that I have already coded this part for the previous version of the cartridge based on the STM32 processor.

For now, I've only compiled the processor's 'blink' test. I still need to at least understand how it works, especially its interrupt handling. But I should be able to manage it.

The development board and its expansion board.

And now, for VGA. What?

Why spend time on a VGA interface?

Well, actually, I've been looking into this for several years. Originally, I never learned VHDL or how to use FPGAs in an academic setting. The way I discovered this environment was probably not the right one. But over the years, I ended up developing my own personal perspective on the subject. Furthermore, I've wanted to create this type of interface for quite some time—a persistent desire to pursue the idea of the Atari STE, without any pretense, of course.

Looking back, I must say that the VHDL/FPGA duo isn't really difficult for anyone who has even a basic grasp of combinatorial and sequential logic. After all, VHDL is just a high-level language suited for representing logical structures.

No, what presented a real challenge for me was that to create your first example, the famous 'blink', you need to have a minimum grasp of a certain number of technical concepts and realities. In fact, the barrier to entry is a bit high for a beginner. This is especially true if you want to embark on the System-on-Chip (SoC) adventure.

Regarding the management of a VGA framebuffer, the problem for me was the type of memory implemented on the FPGA board I had bought at the time: a DE2-70 :

This board is absolutely brilliant and has, I should say had, everything needed to start a somewhat 'complex' development. Yes, because there's no HDMI video output, for example, only VGA.

Except... there is no simple SRAM memory available. There is SRAM, yes, but it's synchronous. So what? Wouldn't that work for VGA? Well, yes, obviously; in fact, it might even be perfectly suited for it. Those familiar with 'burst' operations will know what I'm alluding to. Nevertheless, for a beginner, it doesn't allow for easy debugging, for instance. Could my SRAM access 'functions' be causing issues? Or perhaps my VGA processing core? As you can gather, it multiplies the potential sources of problems, and when you're not comfortable with the concept, it can lead to a lot of frustration. That was my case.

So, a word of advice: to get started with FPGAs, first choose a simple board with LEDs, switches, SRAM, and extensions like an LCD display and HDMI output. You can always acquire a more advanced board later if you wish, but to start with simple projects, use a simple board

Although I managed, a few years ago, to create 'something' that allowed me to display pixels on the screen, I clearly understood that there was something 'stuck' in my concept. Over time, I had even envisioned another way of doing it.

And it is precisely the fruit of my reflections that I have decided to test. Undoubtedly because I felt the time had come to put my ideas into practice.

There's nothing revolutionary in what I'm doing. People working on this kind of subject have undoubtedly encountered the same problems as I have. But well, to be able to envision something, you need to know that you'll know how to do it...

So, I created a small extension board with two SRAM chips for the FPGA DE2-70 board. And I started coding. 

It took me just over a day to already succeed in reading the contents of the SRAM. Random content, since it's not erased when the FPGA board is powered on.

I then tackled the system's input, meaning I arbitrarily and sequentially imposed a color pattern:

At this stage, I must say I was starting to think I was potentially on the right track this time to create my VGA framebuffer. This image indicated to me that I had managed to handle the various system asynchronous timings reasonably correctly.

To confirm the validity of my solution, I still needed to fill this framebuffer from an external source, as a microprocessor would do. To achieve this, I used a development board with an STM32 processor. Admittedly, while this type of processor can be a bit slow to react to changes in the state of its input GPIOs, it is capable of changing the state of its outputs at high speed.

To do this, I connected a GPIO port of the FPGA to an extension connector on my add-on board. After establishing a minimal communication protocol between the processor board and the framebuffer input, I connected this processor board to my add-on board.

I had to make slight adjustments to some timing issues, such as the length of certain memory zones, to achieve a satisfactory result:

This result is achieved by injecting pixel codes directly into the framebuffer from the STM32 board. The visible shift in the image occurs because I pushed the STM32 processor to its limit to prevent on-screen interference. The photo was taken while the image was constantly moving, hence this shift.

In reality, I can completely fill this 640*480 screen between 3 and 4 times per second, despite using an 8-bit interface where each pixel can display 256 colors (requiring one byte per pixel). Furthermore, because I'm using the free version of Quartus, I cannot use different frequencies for my VGA engine core and the display frequency.

Given that the display frequency is about 25 MHz and the memories are rated for 100 MHz access, I could potentially accept input into the framebuffer at 3 to 4 times the current rate. And if the processor had a 32-bit bus instead of 8-bit, I could multiply the speed by another factor of 4. This could potentially give me a refresh rate of about 50 Hz to 60 Hz per second. Not bad for a relatively simple system.

Of course, I still have to implement a graphics processor, to handle internal operations—and thus faster—such as moving blocks, sprites, etc.... That will be the next stage of my development.

It's possible that all of this could be done with an RP2040 or 2050, I'm not sure. I've seen several examples to that on the web. And in fact, I'm currently trying to set up the development toolchain for Raspberry in Visual Studio Code. The Raspberry add-ons not being up to date, for now I can compile 'blink' for the RP2050 and load the executable by copying and pasting into the RP2050's disk space.

However, I can't get the debugger to work. I realized that the installed version of OpenOCD is largely outdated and is missing the description file for the RP2050. I hope that loading the latest version of OpenOCD will solve my problem. Really, for an automatic installation, there's room for improvement.

And so, my Drumulator project? On standby for the moment, I must admit...

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. 

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.