Tip for easily working on serial frame coding.

I am currently developing the reception of serial frames from a file transfer from the PC, using the YMODEM protocol. Nothing too complicated since the protocol is very well documented.

Well, yes, but still… For one, everyone implements the protocol a bit 'however they want'. And then it's better to work, at least for me, with something concrete, namely being able to observe the process unfolding on screen.

Of course, it would be possible to use a logic analyzer with serial link decoding, or to use a serial port sniffer on Windows. From experience, using 'the little software that works well for that' on Windows is such a 'mess' that I didn't even consider it. Instead, I opted for a small module based on a CH347 chip that can be configured for use with several serial protocols. I personally configure it as TWO serial ports. This little gadget, bought for €6.09 on AliExpress (probably even less in USD), has a USB-C port.

I connect its two RX ports to the TX ports of the transmitter and the TX port of the receiver, which allows me to visualize in real time the operation of the two 'talking' systems, directly with the somewhat intelligent utility I installed on my machine, namely WindTerm. This way, I bypass all the usual hassles of Windows while having a super comfortable visualization of what's happening. I really like that!

Since I didn't have anyone around, I shared my 'thought of the day' with DeepSeek :

To bypass Windows headaches for 6 USD — it's a steal, isn't it?

And here's what it replied. 

" Absolutely! For six dollars to bypass Windows headaches, it's practically a steal. It's all about finding those simple, clever hardware solutions that cut straight through the software frustration. Smart move. "

Well spotted, Deep! But yes, 'software frustrations', hmmmm... Hello, Donald? 

MSX Cartridge, Cody Computer, Apple II...

Frontline Report:

Regarding the MSX cartridge, I'm still actively working on it. I'm currently implementing the YMODEM protocol on the internal processor of the Efinix Trion FPGA. The hardware and development software are now very stable. In advance, I've created a small interface card designed to be connected between the FPGA board and the MSX computer, with the goal of making the flash memory of the already-built expansion card for the FPGA board, available via a 'wired connection' on the MSX cartridge bus.

After successfully implementing a minimal 640*480 VGA interface on an Altera FPGA board, I must say that for the past few months, what seemed completely unfeasible to me—because it appeared too complicated—has actually turned out to be much simpler than I imagined.

And by the way, I am currently designing an expansion board—still for the Efinix FPGA board—featuring a 6502 processor, ROM, and RAM.

This time, the goal is to work on a hardware clone of the Apple II and an evolution of the Cody computer.

Regarding the Apple II, I had salvaged a machine in very poor condition from my former workplace. I had tried to get it working again and succeeded. But without knowledge and without the proper hardware environment, I couldn’t get it to do anything more than display its Basic prompt. Which was good, but still.

I then decided to build a clone based on a GitHub repository, the RETRO II : Retro II

But the development was unstable and unfinished. In fact, it never was completed. However, that experience allowed me to understand the Apple II hardware. I then thought to myself, “It shouldn’t be too complicated now” to revisit this study by replacing a large portion of the components connected to the processor inside an FPGA.

And with this expansion board, I also intend to take the Cody Computer concept a bit further. Because I find the work Frederick John Milens did absolutely fascinating. His machine resembles the Commodore 64, and above all, the documentation he provided is absolutely brilliant—it’s what makes the concept truly incredible. A highly relevant starting point for learning computer science—in the way I understand it, of course, which is, first and foremost, about the freedom to think and to create.

For more information about this machine, I invite you to visit the dedicated website: https://www.codycomputer.org

My personal take on this subject: having built this little machine, I feel I can allow myself to make an observation. In its current state, it requires the construction of a specific keyboard for input, as well as the use of an S-video to VGA or HDMI converter. This slightly diminishes its financial accessibility, since you have to add the cost of a custom keyboard plus the time to build it, and also add an external converter. Furthermore, it also reduces the machine's ease of use.

I imagine a 12 or 13-year-old who knows nothing about it, coming from a family where technical aspects are unfamiliar, wondering how to build and get such a machine running. For me, back in the day, I bought a Sharp PC-1500. An all-in-one where you just had to insert four batteries and read some simple technical documentation for a few hours to be able to start creating.

I would therefore like to add a USB port for connecting a standard keyboard, as well as replace the Propeller processor that manages, among other things, the video output of the original machine, with a system allowing direct connectivity to a monitor via an HDMI port.

I assume you understand where I'm going with this, given that I managed to create a 640*480 video card with VGA output, I'm thinking I might be able to push the concept to HDMI and graft it onto the Cody.

We'll see...

And then, I received another FPGA development board. Because I still want to make progress on the Drumulator reconstruction. I know the electronics of this machine well. All the development paths I've taken so far don't seem right to me. I think I want to have a functional machine in an FPGA to properly develop the rest of the hardware.

My last attempt at creating a Zilog-compatible CTC didn't work. Software simulation is a real hassle with the Efinix solution—at least, I haven't been able to get the hang of it. There is the option of using an external logic analyzer, but I'd probably use that more in the final development stage to validate signal timing.

On the other hand, now that I have mastered the internal processor of this Trion FPGA, I plan to use that processor to send test signals to the CTC. This will allow me to display all the information I want directly via the serial port. It's probably not the best solution for verifying a VHDL design, but well, for a bunch of reasons, it's still the approach I'm going to adopt.

I should clarify that I am not sponsored by Efinix. However, and despite a somewhat rocky start with this FPGA vendor's development tools, I must say that over the time, I've managed to get to grips with this development platform. I should say that the ease of integration of their RISC-V Sapphire processor core is, in my view, an undeniable plus. Well, in the past I thought I detected some potentially slightly troublesome features of the Trion FPGAs, particularly regarding clock signals, but I'm prepared for that. I can orient my designs appropriately. And, to top it all off, the development software doesn't require purchasing a license to enjoy the full potential of the IDE in terms of placement and routing and other optimizations.

It's a strategy I don't understand from the other vendors: charging for a license, sometimes an expensive one, to be able to fully use the target components? Well, one thing's for sure, if I do any work with FPGAs, it won't be with those folks. For them, it's all about whether it's profitable in the long run. For Altera, I think not, since the company hasn't existed for a few years now and was taken over by Intel, hum...

The Death of Arduino?

You have likely already heard that Qualcomm acquired Arduino a few weeks ago. Since then, the community has been questioning Arduino’s business model and, more importantly, the community-driven, DIY, and open-source nature of the ecosystem—and rightfully so.

Via the link below, you’ll find an interesting comment from Adafruit Industries, another key player in this ecosystem, which truly respects the "open-source" spirit of the community, regarding this acquisition of Arduino by Qualcomm.

https://www.linkedin.com/company/adafruit/posts/

 

 

In my opinion, Adafruit's remarks are entirely relevant and, I believe, irreversibly highlight the path that Arduino is now set to follow—leading to what we can easily 'predict' will be the more or less swift abandonment of Arduino by the community. Ultimately... to the pure and simple end of the Arduino adventure.

Open question: What comes next? For my part, I've been noting several independent companies operating in the realm of 'open-source' electronics. In reference to this post: Adafruit, obviously, but also SparkFun, DFRobot, Seeed Studio, Keyestudio, and many others.

The common characteristic of these companies is that they rely on existing ecosystems like Arduino itself. Although these companies also often develop their own "personal" ecosystems, the disappearance of Arduino could still lead to a brief period of uncertainty in the DIY world.

My conclusion: The torch will certainly be picked up. By a third party or by the community itself. Alternatively, the moment may be ripe for the emergence of another platform in the same spirit. Potentially both possibilities.

In any case, I feel this moment is more one of renewal rather than an ending. A heads-up to creators of all kinds...

 

Efinix FPGA with the Sapphire SoC.

After my misadventures trying to create an MSX cartridge with the help of an embedded processor, I decided to dive headfirst into the fantastic world of SoCs.

So, of course, I have some experience with FPGA programming, but I have never attempted the experiment of implementing a processor that can be debugged in real-time.

In the past, I have implemented Z80 and even 68000 cores. But each time, it was to run code already developed for the version with a 'real' processor.

Here, the goal is to develop a new application. In fact, it's about porting the routines I already created for the STM32 processor-based MSX card to the embedded processor from Efinix. It is a RISC-V machine with very promising capabilities.

I struggled a bit to understand how the system works and to set it up. It's actually very simple, but when you've never done this kind of thing before and everything has to be figured out on your own, it takes a little time.

After a few tests done solely with the Efinix development board, I had a small extension board made with Flash, SRAM, and an isolated USB serial port. So, I'm resuming my development on this system after a few weeks' break. Naturally, even though I had taken notes during my initial tests, I encountered a few difficulties again, but nothing serious.

A quick and dirty card designed to run at low frequency anyway.

Issues with software instability; random problems with JTAG probe conflicts.
But overall, after two or three PC reboots, everything settled down and is working perfectly fine.

And, so, a little screenshot of the system in operation. I'm just using a slightly modified example program to regularly display text strings in a terminal.

Und fertig!

 

To each their own Halloween! Or the rebirth of an Apple IIe.

Because these days, Google's homepage proudly features an artistic representation of Pac-Man.

By sheer coincidence, it turns out I just rebooted an Apple IIe.

I acquired an Apple IIe a good number of years ago, maybe about ten years now, during the move of a retiring computer science teacher's classroom. While clearing out his cupboard of items he hadn't collected, which were thus destined for the dumpster, a superb Apple IIe stood proudly. I couldn't bring myself to send it to its destruction, so I recovered it and stored it in my garage for years.

Since then, I had the chance to take it out to test it and found it was in very bad shape. On the motherboard, a number of integrated circuits were placed haphazardly, and I didn't know if they were functional. Some had even been placed backwards in their sockets. And yes, here in France, the computer teacher was 'necessarily' a mathematics teacher, as was quite standard in the 80s, completely mediocre in his subject and incompetent in computing. Hence the place that France holds today in the field of computing. But, by luck, the laxity of these national education staff being what it is, this Apple IIe had probably been lying around for about thirty years in its damp cupboard, a fitting image of the French national education system.

Upon inspection, I found that an integrated circuit in one of the disk drives had literally exploded. This certainly had consequences, causing the machine to no longer boot. Hence the 'attempts' at repair by what I could qualify as an imbecile.

I therefore systematically replaced the logic chips and assumed that the specific circuits, like the CPU, the MMU, etc., were functional. This was the case. On the first power-up, the machine booted into Basic.

And there you have it! I had no resources for this machine, no floppy disks, I didn't know what to do with it. I stored it away and, since I hadn't been able to verify the functionality of the disk drives, I put it away again and stored the expansion cards, though I no longer remember where. And that's when the drama occurred.

During a cleanup of my garage, I came across this machine again. Without the expansion cards, it was impossible to attempt anything. So I did some research online and came across Bradley Bell's Github, where he had recreated a number of expansion cards for the Apple II, including the Disk card and the Superserial card.

That's when I told myself it was worth giving it a shot. So, I had these two cards manufactured.

 
I managed to find the specific components at a local retailer who looked at me in a funny way, given that he didn't remember ever taking the box containing the R6551s off the shelf...

I assembled these cards without any difficulty. I replaced the old and unobtainable transistor pairs on the Disk II card with modern Darlingtons, and everything worked on the first tests inside the Apple II.

Afterwards, I spent some time trying to understand how ADTPro works and finally managed to download both the latest version of ProDOS and an image of a version of PacMan.

To do this, I still had to thoroughly clean the disk drives; they were making a real 'saucepan-like' noise when operating.

It's a pleasure to see the back of this Apple IIe with the serial connectivity that allowed the machine to be brought back to life.

Alternatively, in a more fluid way:

It's a satisfying sight to see the back of this Apple IIe equipped with the serial connection that brought the machine back to life.

Not only does this Apple IIe now boot without any problem from the ProDOS disk, but it is also able to boot from the PacMan disk, allowing the game to start.

And there you have it, this weekend, I too have my PacMan.
And I must say it satisfies me more than Google's PacMan logo, even if it's not in color.

Which leads me to think that it would be interesting to add an HDMI card to it, since that type of extension now exists.

 

The A2dvi plus card :

 

 

 

RASPBERRY PI PICO : Hmm!

For a while now, I've been thinking that it could be interesting to use the small Raspberry Pi Pico processors, particularly the RP2350 version.

While searching online for information about the available tools for programming this type of component, I was initially quite disappointed, and this was confirmed later on.

Basically, aside from perhaps manually creating the entire toolchain from scratch, there are only three options left:

• The Arduino IDE
• PlatformIO
• Visual Studio Code with the Raspberry Pi Pico extension

And right here, without even trying anything, I face two problems. It is absolutely out of the question not to have real-time debugging. Immediately, the Arduino IDE is out! I spent a lot of time years ago developing for Atmel processors with that IDE and debugging via the serial port. For a complex project, there's no way I'm going to mess around with that again —no, thank you!

That leaves the two other options. Unfortunately, both are based on microsoft's editor. I knew that attempting anything with 'crosoft' would lead me into a minefield. I was not disappointed.

I tried everything. I also noticed that the documentation online isn't recent, but oh well. Impossible to get my RP2040 probe recognized by the OpenOCD provided with the Raspberry Pi Pico extension for Visual Code. Worse, I tried manually modifying some configuration files, which led me to a complete dead end. 

Not to mention the visual interface, which is awful. Redundant information everywhere—a real, chaotically festive Christmas tree, just as you could wish for! 

And the worst part is that when it screws up, they just open the configuration file directly in the editor. Good luck figuring it out!

You might tell me, "Oh, but when you're used to it..." Well, that's just it—I've never been able to get used to the 'Crossoft' ergonomics. Spending more time disorienting the user than producing something decent, all while amassing fortunes, really irritates me. As a result, I'm not rich. Microsoft's shareholders, however, are!

It was the exact opposite philosophy that guided the IBM teams behind Eclipse. 
The beginnings of Eclipse were somewhat chaotic, but for quite over a decade now, it has been a stable project offered by a number of solution providers similar to Raspberry Pi. That is to say, providers who do not have, or who have no interest in maintaining a significant software team to develop a graphical IDE for Windows. I understand them!

So, I decided it was time to uninstall everything and do a fresh install.

That's what I did. Well, I managed to uninstall Visual Studio Code and all its extensions just fine.
However, when I tried to download Visual Code again from the microsoft website:

Hmm, we can't seem to find that site.

As usual with 'Crossoft', I'm tempted to say!

A sign for me that, after spending several hours trying to use this environment, it was high time to stop insisting. I also tried PlatformIO, with no better results.

I'm surely not the ultimate geek capable of getting absolutely everything to work on any platform, but what interests me is what I can do with the tools. Building or eternally rebuilding my tools just to possibly be able to work with them doesn't interest me in the slightest.

Using Visual Studio Code instead of Eclipse represents, to me, a total lack of professionalism. The goal isn't just to create interesting components—it would be interesting to be able to develop them while focusing only on the essentials!

There's nothing to be done, microsoft will always be 'micro'. And its fortune won't change much about the situation!
 

 

 

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...

ARDUINO NEWS!!!

https://www.cnbc.com/

And now, what will be the future of the Arduino ecosystem, even if Qualcomm claims that the entity will remain independent, while benefiting from the power of Qualcomm chips?...

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.