MSX Cartridge: Some Progress.

The saga of this cartridge :

Initially, I developed a cartridge based on a single RISC-V microcontroller, downloadable via USB using disk transfer mode. It worked, but the constant interruptions generated by the USB bus from the PC eventually crashed the MSX computer.

I therefore split the management of the USB bus and the handling of data to the MSX into two separate processors. This worked very well on my machine, but very inconsistently on the machine of the person testing my cartridge.

I then suspected issues like ground loops, power supply, etc. So, I developed a new cartridge with galvanic isolation. The result was no better.

I redesigned the cartridge, this time incorporating isolation precautions from the start, switched to the YMODEM protocol over a serial connection, which allows me to properly manage the sequence of operations, and chose a new processor from STMicro, a fast STM32. Alas, even on my own MSX computer, the cartridge refused to boot.

Following all these tests, which spanned two years after all, I determined that, in fact, trying to serve data at a frequency above 2MHz is not a good solution.

I could have tried the RP2040, but I already attempted to set up the development environment without success. For me, it's a bloated system that uses Microsoft's VS editor. Being allergic to Microsoft tools, I decided to go with an FPGA.

The idea this time was to use an internal processor within the FPGA to manage file download and FLASH programming, and also, crucially, to use the FPGA's internal logic to redirect the different data/address/control buses to the three elements: the internal processor, the MSX bus, and the bus to the FLASH. I figured that at least this way, the flash memory would be directly connected to the MSX bus.

I therefore chose FPGAs from Efinix because their prices are very affordable. I created an expansion board for the Efinix development board, containing the serial port, the flash memory, and also some SRAM. I also created an adapter board for the MSX computer bus. I connected everything, programmed the VHDL part to manage the various physical buses. I programmed the FPGA's internal processor to handle file reception via the YMODEM protocol. I loaded everything onto the development board.

I then downloaded a Zanac ROM into the system and started the MSX.

And voila: 

Right from the first startup of the MSX, I successfully got the cartridge to boot. I then connected a USB keyboard through the adapter I also made to allow for this kind of thing, and was able to play without any problems. No issues, no crashes. I haven't shut down the system for a few days now, and I can still launch the game.

Something that seemed completely out of my reach just a few months ago has been achieved without much difficulty in the end. Result achieved just a few days before my year-end holidays. So, I can really switch my brain to OFF mode and have some truly relaxing holidays.

Happy Holidays and a Happy New Year to everyone.

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!