AKAI PC-S56USB card full metal bracket?

Quite simply, way too expensive. 

I am going to make this part using a printed circuit board. Given the price of the metal version, I have no other choice, otherwise the final product will be way too expensive.

AKAI PC-S56USB card.

To properly finalize the development of this board—which is a modern clone of the original AKAI card—I need to create the metal mounting bracket for the rear panel of the S5000 rack.

In theory, the card can sit securely in the machine without this metal cover. For now, that’s the case for me. Indeed, the card retention system inside these AKAI units (S5000/S6000) is so well designed that expansion boards simply can't move around. Still, for the sake of proper finishing and EMC compliance, it's better to carry things through to the end.

So, I had to dive into 3D modeling. Since I didn't want to spend a fortune on professional software solutions, I naturally had to fall back on open-source options. That's how I (didn't really) choose FreeCAD. I'm using version 1.1.4.

Well, there’s certainly a lot to be said about using this software. While it isn't overly complicated, nothing about it is straightforward either. Overall, it feels like an archaic solution, inherited from 3D engines and design philosophies from the early 2000s. You’ll find plenty of criticisms about it online, and in my opinion, they are quite justified.

However, its saving grace is that it exists and gets the job done—especially for small projects like this one—without wasting too much time. Assuming, of course, that spending three days to design a simple plate with a few holes can be considered 'not too much time'. Keeping in mind as well that I'm not an engineer and have no background or training in any of this.

So, after a few days of learning, here's what the card should ultimately look like:

 

and the back of the card :

I still have to double-check a few dimensions, because the assembly is pretty precise. Then I'll have a few prototypes made. To do that, I'll need to find the right material and make sure the part's design works well with the supplier's cutting capabilities. It's going to be another learning curve, but it helps me build my skills and will open up new possibilities—especially for 3D-printed plastic parts, now that I can model 3D objects fairly well.

Drumulator become Drumix.

Yes, because I'm making enough modifications to the original system that I'll christen this future machine with a name all its own! It will be: Drumix (the terrible)!

After a few printed circuit board tweaks, here — in ray tracing, no less — is what the output board will look like. Huh? What? Just the output board?

Yes, for now. But hey, the processor and logic board should be fairly 'easy' to make.
I've already been able to test that whole part with a prototype board connected to the FPGA board with the Trion FPGA I'm going to use. It's only a matter of time now.

Because these past few days I've been working on the MSX cartridge. The goal being to automate the process of loading ROMs into FLASH. That is to say, once the download is complete, the MSX computer reboots by itself onto the cartridge, without having to do that extremely tedious little game of power OFF and ON!
To achieve this rather easy-looking goal, I need to juggle with:

• Kicad for 4-layer boards and 0603 SMD components.
• Electronic implementation of the FPGA with all its constraints.
• VHDL programming for all the switching logic and the download sequencing.
• RISC-V Sapphire programming of the processor embedded in the FPGA.
• Getting familiar with the whole development toolchain and finding the programmers.
• Modifying the generic programmer from Aliexpress to work with the FPGA.
• Getting lost in the sometimes baroque workings of the MSX.
• Programming in C with the MSXgl library to create the download page executed by the MSX.
• Debugging the whole thing without getting too lost in this labyrinth.

Well, you have to admit that all of this is fun. Except that I also have my USB card for the Akai S5000/6000 to finish. I just have left to create the metal mounting plate for the back panel of the Akai RACK. There you go, and no doubt various other things that also take up time. 

I forgot, I have a superb 4-layer FPGA board in a BGA package to assemble. There too, quite a 'sport' ahead. But, I might have something to practice hot-air soldering on. I'm trying to repair a Vivlio TOUCH LUX 5 e-reader whose screen was broken by excessive pressure on the device. And, I've finally just discovered the real reason why the machine won't restart. There's clearly a solder ball on the processor that has come loose. By pressing on the processor at the same time as the power button, well after two seconds, the machine starts up. No choice, it has to be re-soldered with hot air.

Yay for sports!

'So', wie die Deutschen sagen...

A little more than two weeks later, the prototype board for the audio outputs of the new Drumulator is practically finished. The weeks go by so fast it's scary. I haven't only been working on this board. I have other projects going on in parallel, but oh well, routing PCBs isn't my favorite activity.

So, as I was saying in the previous article (I think), although I've fully kept the spirit of the original Drumulator's outputs, I removed the analog multiplexing in order to give each output its own audio converter. The price of quality 12-bit converters has dropped so much that it allows for improving the analog quality of the outputs. No DC-blocking capacitor on the output. The symmetry of the signal with respect to ground is actively preserved.

Although this approach improves the overall audio quality, this simplification doesn't necessarily simplify the creation of the PCB. However, since I particularly enjoy properly separating and delineating the different parts of a function when laying it out on the PCB, well, my goal is achieved.

I do like a certain aesthetic when creating PCBs. A purely subjective aspect, I admit. But after all, that's still what sets manual routing apart from A.I. routing. For now....

So here, at least in 3D representation, is what the analog board of the new machine should look like — provided, of course, that it works as expected once it has been tested.

I may still have a few tweaks to make before sending the prototype board off for manufacturing. But I have to say that I'm finally making progress. 

It's been a really long time now since I "took on" the Drumulator. Without any suitable formal training, several obstacles stood in my way. The lack of expertise in FPGA development on the one hand, and the absence of what I'd call "logistical" hands-on experience when conceptualizing a relatively large project. 

On these aspects, I've made a lot of progress over the past few months. Argh!: a little personal pleasure ;-)

Bak to the Drumulator.

It has been a while since I last posted about the Drumulator. On the one hand, I'm working on other projects in parallel. A project that seemed fairly simple at first glance—namely, implementing the Drumulator on an FPGA—wasn't quite as simple as it seemed. And worse still, as I made progress on the subject, I realized it was becoming increasingly difficult, to the point of reaching a breaking point: a total state of blockage due to my lack of expertise in FPGA programming.

I remained in this state for a very long time, which could be estimated at several years—in fact, far too many years, since I must have been stuck for about five years. Until the end of 2025, when, thanks to the contribution of AI used as a teacher, I was able to unlock my understanding of VHDL and thus make great progress.

The side effect of this new approach to FPGA programming is that I spent the first half of this year working on finalizing the digital part of the Drumulator, and as a result, I also resumed development of the MSX cartridge that I had attempted several times to build using fast microcontrollers, but with unreliable operation.

I also undertook training in 4-layer PCBs, because double-sided boards don't allow proper use of the range of FPGAs I'm currently using, the Efinix Trion FPGAs. And to complete my training on the subject, I decided to make a 4-layer PCB using a BGA-format FPGA. I've actually received the PCB. All that's left is to embark on the adventure of hand-assembling this board.

All of this is to say that I've been quite busy during this first half of 2026.

Since the start of the 'school year', I've therefore studied (again) the analog part of the Drumulator.

Thanks to my new 'skills' in FPGA development, I was able to consider a different way of operating this analog part. Also taking into account the final cost of the board, its ease of integration not only for the Drumulator but also possibly for another machine of this type, the simplicity of assembly, the quality of the audio processing, and finally the possibility of operating with a simple 5V power supply such as a USB charger, well, I ended up with something that has nothing to do with the original Drumulator circuit, while scrupulously respecting its spirit.

I no longer use multiplexing at the output of the audio converter. Each output now has its own converter. I also no longer use per-channel volume control via an external digital-to-analog converter. The volume will be calculated directly in the digital domain by the FPGA. Furthermore, I'm using 12-bit linear audio converters, rather than 8-bit companded ones as in the original. A simple conversion table directly converts the signal, and does so very simply since 8 bits only gives 256 values to process. Finally, the output capacitors on the audio path have been removed thanks to the 0V centering servo.

Moreover, all the filters present at the output have been kept strictly identical, in order to provide the exact audio feeling of the original Drumulator. This produces a circuit with a lot of components, but one that should be fairly easy to route. For information, here is the 3D rendering of both sides of the board before placement and routing.

 

We're still going to have to be patient to make the best possible circuit...

Back to business, but not empty-handed : Akai S56usb clone.

What do you mean, a clone of Akai's S56usb USB card?

As often happens, it's a long story that began in the early 2000s with the purchase of an AKAI S5000. 

The machine seemed very interesting to me and had the advantage of being remotely controllable by a windows PC. Well, as a remote control, it's really just a replication of the machine's control panel on your PC. A sort of front panel – not hardware-based like on the S6000, but software-based. This was on Windows XP. Obviously, Akai never updated their software, which was called Aksys I believe, and they had no reason to, since the machine hasn't been available since 2002. Too bad.

In fact, I 'believe' Aksys could also directly control some features and edit the S5000's samples. Still, considering just the 'remote control' functionality, it was already excellent.

However, a few years ago, a French compatriot developed the equivalent of the Aksys software for Windows 10 & 11. 

Not as pretty as Akai's interface, but it gets the job done, and that's what counts.

He also set up a Discord account dedicated to the development of his software : http://s56sys.free.fr/index.html. While browsing his Discord, I realized that there were people interested in his application, but that unfortunately, not all S5000 owners had acquired the USB card enabling communication with the PC. This card having become rare, it can be found, but at a fairly steep price – typically between $140 and $180, according to my Internet research.

S56usb Akai card.

Beyond the price, the real problem is the availability of this USB card. A little nudged by the software developer, who was able to give me some information on the various signals on the card's S5000 connector, I ended up taking on the challenge of reverse-engineering this card.

Knowing that I had the pinout for the S5000 bus connector – which was supposedly valid – and that I also had an original card, I figured it shouldn't be too difficult to determine the entire wiring of the card, given that it's a double-sided board with no internal copper layers.

However, the card has an address-decoding PAL that doesn't just decode addresses. I've always had my doubts about the role of that PAL.

Be that as it may, I went ahead with reverse-engineering the card. As expected, it didn't take me long to draw up the schematic in KiCad – a few hours, and then a few more hours of verification. Which didn't stop me from making a glaring mistake. But hey...

With that done, I still had to figure out the equations governing the PAL. This component doesn't just handle address decoding and other read/write signals to and from the S5000 – it also generates two timing signals based on a simple RC cell. I don't know exactly what these two signals are for, but I imagine they advance a state machine. In any case, I went with that assumption and took on the PAL with a 'brute force' approach using a Pi Pico.

The Pi Pico I had was the version 1, with the pull-up issues. I had to tinker a bit to get a working setup. Once that was done, I cycled through all the binary possibilities on the input pins, sending the output pin readings via serial link to my PC for analysis. From that point on, it wasn't difficult to recover the logic equations.

 

Except, of course, for the two input signals coming from the two RC cells. Because, in fact, I had to look at all the outputs potentially affected by these two signals, as well as the other incoming signals involved in this setup, to choose the right configuration. Actually, I went at it by dichotomy. Between that or wasting tons of time with the logic analyzer, I tried the first option. A GAL makes that kind of thing easy to play around with.

Anyway, after a certain amount of time, the card finally ended up being recognized by the S5000 and the PC.

So I was able to test the communication with my PC running Windows 11 and confirm that practically everything works. The only issue at the moment concerns file transfer from the sampler to the PC. It doesn't work and triggers a USB time-out error on the S5000. Since transfer from the PC to the S5000 works fine, and having observed the same behavior with the original USB card, I concluded that it's a software issue on the PC side, not a problem with my USB card.

So I reported it to the software developer on Discord. He's given me an appointment in a few weeks' time, to give him time to fix the bug. Because it seems to me that when I shared my findings with him, he had a pretty good idea of where it might be coming from. So I'm hopeful that he'll sort it out. Especially since he plans to add sample editing functions, which would undeniably be a plus, bringing the application closer to Akai's original one.

I do enjoy interesting and productive ways to get back to business...

How to go on vacation with peace of mind!

I would simply say: with as few nagging concerns as possible. 

And the best way to achieve that is to finalize certain projects that are at a conclusive stage. 

Since December 2025, I've been working on two main subjects: an FPGA-based Drumulator emulator, and porting an MSX cartridge design to FPGA. Both have been important because, first, I really had to level up my VHDL skills. Implementing the ZILOG CTC controller in VHDL — complete with the full vectorized interrupt system — was a genuine challenge. But without it, I couldn't have implemented even the Drumulator's Data potentiometer. 

That's the software side of things. 

On the hardware side, I also had to design a PCB for the MSX cartridge, this time for the larger FPGA — an Efinix TRION T20. And that meant tackling my very first four-layer PCB design.

What's more, TRION FPGAs are somewhat trickier to implement than Gowin FPGAs, for instance. That said, it really depends on the specific chips and other factors that can certainly nuance that view — but for this MSX cartridge, it definitely held true. With the physical space constraints of a cartridge, plus the fpga size and the number of passive components needed, sticking to two layers was simply out of the question.

I actually reached out to a PCB specialist who quoted me over €1,500 just for the design work. No doubt he was a pro, but that was way out of my budget — even when considering more affordable options from Asia.

So I had no choice but to tackle it myself!

It took a fair amount of time to lay out the board in KiCad, assemble it, and start testing. But at least I had the satisfaction of seeing the FPGA communicate with the JTAG probe almost right away.

After that came the implementation of the internal Sapphire processor, and finally the interfacing with the MSX bus.

A professional would say none of this is particularly remarkable. And I'd agree. But when you're a weekend hobbyist with no formal background in the field, the road is obviously a bit less 'smooth sailing.'

But there it is! I finally got my first MSX machine to boot on my new cartridge. And I have to say — it makes me absolutely thrilled!

It took a few hours of work just to be able to take this photo — and then I had to adapt the VHDL code I'd written during my tests with the Efinix development board to this new hardware. Unsurprisingly, it didn't work straight away, but thanks to Efinix's debugging tools, I finally managed to get the cartridge up and running:

In step '1', the MSX computer places address addr_IN = 0x4000 on the bus. This is the first address where a valid cartridge signature is expected. In step '2', the MSX reads from the cartridge with SLTSL_IN = 0 AND RD_IN = 0, and finally in step '3', the cartridge returns 0x4241 — which is the signature, i.e. 'A' and 'B' in ASCII.

You may notice that in step '2', the address used to access the internal FLASH on the cartridge is not 0x4000 but 0x2000. That's simply because the FLASH has a 16-bit data bus. Bit '0' of the MSX address is ultimately used to select which of the two bytes should be presented on its data bus. This is also why the FLASH returns 0x4241 — both bytes are read out as a single 16-bit word.

So, a bit of internal address translation going on.

I should also mention that during my initial tests, I used small delays to handle FLASH writes. These aren't standard components — writing to them requires a specific procedure and wait times. To keep it short, this time I'm using the FLASH's #READY/BUSY signal directly for all operations, so I'm getting as close as possible to the FLASH's maximum speed. And I have to say, writing — and thus transferring data from the PC — is now significantly faster.

From time to time, I also work on other little projects — like the CODY computer, for instance.  

I just find this tiny machine really interesting and very affordable, and since all the sources are available, it's a great source of creative fun and distraction that brings me back to my 80s computing pleasures. And that's precisely what this little computer is all about. So I adapted a USB keyboard adapter for it.

I used a solution that could definitely be improved, especially by using a Pi PICO. And since I've just managed to get the PICO development environment up and running, I think I'll do a little study on replacing it with that chip.

Finally, I was able to type things on the keyboard and run the first little program that works.
 

I also sent out a USB expansion board for an AKAI sampler to be fabricated. I honestly have no idea whether it'll work, because Akai used some pretty odd tricks on their original board. But at least this time, the backplane connector should be correctly wired — because despite double-checking everything, I still managed to reverse the ROWs. So the whole thing was upside down. You don't get to be a "Sunday tinkerer" for nothing!

I should get the board back when I return from vacation. I'll still have a few days to test it. And if it doesn't work — well, so be it. I'll have done what I could with this board and Akai's rather baroque design choices.

December 2025 was a big month for me. That's when I really started picking at artificial intelligence about VHDL, and it helped me make huge strides on the subject.

But beyond the technical side and the knowledge I gained, what really mattered was the freedom to learn. 
I don't know how things work in other countries, but Western societies tend to be pretty rigidly class-based. France is a perfect example — it still runs on a kind of "Ancien Régime" model where, if you're a nobody (which I am), you're effectively locked out of higher education. I'm oversimplifying, but the core truth is there: the education system is basically a class-filtering machine that only lets the upper classes access the kind of studies that lead to a "normal" professional life.

"The big shots land the fancy seats
Right on
The rest get Saint-Maur, Châteauroux Palace
Nowhere to go"

(Saint-Maur and Châteauroux are prisons, for real.)

InFrench original : 

"Les cadors on les retrouve aux belles places
Nickel
Les autres, c'est Saint-Maur, Châteauroux Palace
Plus d'ciel"

(Song by Alain Souchon ‧ 1988)

Artificial intelligence currently lets you break out of that situation. Which is a huge pleasure for me, because it makes me more creative. But for how long? That's a whole other debate.

Msx Cartridge, first run.

The MSX cartridge saga continues...

As a reminder, here is what the cartridge should look like once finished. I had the printed circuit board manufactured with a request to have all passive components in 402 packages placed, because doing that by hand: why not, but actually, no!

On the other hand, I had to solder the FPGA myself. Even though it's a 144-pin package, this type of package is very easy to solder. I've already had the opportunity to do it before; a little practice is enough to carry out the operation without difficulty. I also asked for the flash to be placed on the board.

The FPGA functionality tests did not reveal any particular design issues. I just had to remove a resistor on one of the JTAG signals — a useless resistor that I had added without much thought on my original schematic.

The first programming of the FPGA therefore went without a hitch — see previous articles for more details. The famous 'Hello World' worked on the very first try.

So the next step was to program the Sapphire RISC-V processor core provided by Efinix into the FPGA, in order to implement the whole file-reception program from the PC, as well as the routine to write that file to the Flash.

When I do feasibility tests, the code I write is never very clean. Rewriting it for the final implementation allows me to follow a cleaner structure.

To check that the application code for the processor was starting to work properly, I simply programmed the UART for communication with the PC, the processor's internal timer to generate a one-second interrupt, and the timer interrupt routine to send a CRC-16 character (actually the character 'C') to the PC. Indeed, it's upon receiving this character that the Ymodem transfer protocol can start transmitting.

Because, no, I'm not using the Windows copy-paste file system over USB media. That system isn't designed to be controlled — it either works or it doesn't, with no visibility. So I preferred a more controllable transfer method.

And that's when the real trouble began. Although the code running on the processor started correctly and displayed the program prompt along with a few occurrences of the CRC-16 character, the program would stop without any intervention from me.

For a main loop consisting of while(1); that's a problem.

So I spent an evening eliminating possible causes for this malfunction. Then I remembered a small electrical issue I'd encountered during my initial tests a few months ago — a minor problem with ground loops and/or noise. This issue was obviously causing disturbances on the JTAG link, which in turn would crash the processor.

I inserted a USB isolator dongle on the USB hub and plugged the JTAG dongle into it.

And this time, no more problems. The processor runs its program without any issue.

So, my very first 4-layer PCB I designed, even if it's not the pinnacle of the art in this field, isn't causing any issues so far. The code I developed on the Efinix evaluation board works as well. Up until now, the most complex systems I had produced were circuits around Gowin FPGAs, which are simpler to implement. For this MSX cartridge, the whole circuit is nevertheless a bit more complex.

I must say I'm quite pleased with the result :

The Cody Computer : With an USB keyboard?

From time to time, I've mentioned the little computer designed by Frederick John Milens. The main reason for my interest in this small machine is that all the source code is provided, it's very simple to build, and for learning what microcomputing is, or what it was, or what it might well become again, it's an absolutely brilliant tool.

I repeat myself, but for me, the only "small issue" with this machine is its keyboard. In my opinion, it's really not very practical, and it adds an unnecessary extra cost to its construction.

So much so that I didn't actually build the keyboard. As a result, in the few months I've owned this little computer, I've never been able to type anything on the keyboard to test its functionality. Until now, I only had its startup screen. That's already a good sign that it's working, but still, a bit frustrating.

So, a few months ago, I developed a small electronic board to adapt a standard USB keyboard to the Coddy. For the interface, two approaches are possible. The first is to connect directly to the keyboard connector, thus simulating the keyboard hardware with I/O ports on a microcontroller.

This principle works, but obviously, since the computer's keyboard scanning and the microcontroller's I/O matrix scanning are asynchronous, there are rare occasions where a key press is missed.

The other solution is to present to the computer, one way or another, the key code directly returned by the USB keyboard. But this solution, although more reliable than the first, requires having full access to the computer's resources, because it involves not only some hardware modifications but also system software changes.

Since the designer of this computer provides absolutely all the source code, I opted for this second solution.

The hardware principle used is simple: a USB-to-serial converter translates the codes from a standard USB keyboard into codes available on a serial port. A small microcontroller retrieves these serial codes and presents them in parallel on the computer's data bus.

A tri-state buffer allows placing this code on the data bus using an additional selection signal generated from the Coddy's VIA selection signal, discriminated from the VIA by taking into account an extra address signal. Basically, I'm using one of the VIA's memory maps to place the I/O registers that provide the keyboard code.

And that's it.

From a software perspective, it's "simply" a matter of hooking into the existing system code by adapting certain routines according to the new hardware.

Said like that, it sounds simple, but in fact it's not really, because even though all the source code is available, you still need to understand how it works and its subtleties. And adapt to the 6502 assembly language, which I had never used since until now I've always worked on Z80 or 68000. This caused me some initial confusion. But then again, when you know assembly language, switching from one processor to another isn't difficult.

And so, after a few hours of studying and testing, I finally have a keyboard connected to the Coddy. 

And, compared to my previous article where I showed the very first signs of character reception but where the whole processing of commands entered via the keyboard was not yet functional, now it is fully working.

And now?

Well, not everything is actually functional. The "break" that allows stopping a running program hasn't been implemented yet. This system uses certain hardware lines from the original matrix keyboard to generate the Break. I haven't implemented it for now. After the few hours I spent on the BASIC assembly source, I don't think it will be very complicated to implement.

My interface is a bit complicated. I use a small USB-to-serial conversion module, then my decoding and data presentation board that interfaces with the Coddy's data bus.
I think there's a way to do it much more efficiently by using a Pi Pico with the TinyUSB library.

Since I managed to set up (without difficulty) the Pi Pico development environment with Visual Studio Code, I should be able to greatly simplify all this into something better!

And yes... Unlike my first attempts at installing Visual Studio Code with the Pi Pico package for VSC, I was able to complete the installation without any problem whatsoever. It just goes to show that some Microsoft solutions work almost intuitively!

And I almost forgot to thank Frederik for a very handy little detail in his code: PUTHEX.
This routine allows displaying in hexadecimal at the cursor position any data previously placed in the A accumulator.
A very handy little utility for real-time debugging.

 

Some headway despite the heatwave.

Despite this intense heat, I managed to make some progress on my developments. And to kick things off, a magnificent failure. Well, it's still progress, I suppose. This concerns the USB expansion board for the Akai S5000/S6000 sampler. My first prototype doesn't work at all. Mind you, that does make it easier to find the cause. I did indeed make a beginner's mistake on the PCB. It's so obvious, even though I checked my schematic several times, that I'm simply not going to reveal it. So I've corrected my circuit. Now I just need to get it re-fabricated.

There's no visible difference on this new board, except that I've moved the USB-C connector out a bit more, because once the current board is installed in the sampler, I realized it was missing just a tiny millimeter to properly plug in an external cable.

Luckily, I do have some genuine progress to report, particularly with the MSX cartridge. I won't recount the whole development story of this project here, but suffice it to say that I recently moved over to FPGA. For that purpose, I switched to an Efinix TRION FPGA. These FPGAs are new to me and are a little trickier to implement than the GoWin FPGAs I used before, but they're also less expensive.

Given the tight space constraints of an MSX cartridge, and since I'm using a 144-pin device, I had to opt for a four-layer PCB. The first spin of this board isn't perfect, but it's still well enough laid out to allow programming the FPGA through its JTAG port.

The image below shows the result of programming the FPGA via JTAG. In reality, it's a little more involved than that. Using the JTAG interface alone, you can program the FPGA's internal RAM 'on the fly'—which is great for development. However, it also means that whenever the FPGA is reset or powered off for any reason, that RAM is wiped, and the FPGA then expects to find an external EEPROM holding the configuration bitstream to reload its internal RAM and boot up. This is called SPI ACTIVE mode, because the FPGA itself initiates and manages the copying process from the external EEPROM.

So how do you program that EEPROM when you haven't added a dedicated connector for an external SPI programmer? The answer is simply to use 'SPI over JTAG' mode. And that's where the magic happens. During programming, the bitstream is written directly into the SPI EEPROM through the JTAG port. Once that's done, a simple reset of the FPGA is all it takes for it to fetch its configuration from the EEPROM—and that's exactly what this image illustrates.

Here's what my development setup looks like:

I should also mention that to program this FPGA, I'm using a commercial interface I bought myself on Aliexpress JTAG probe. Although it comes with the FTDI chip, it doesn't quite meet the specific requirements for programming the Efinix FPGA. One signal is missing from the output connector, but luckily that signal is available on the internal connector on the PCB. You just have to route that signal to the external connector, and the interface works flawlessly in JTAG mode with the Efinix programming software.

View of the programmer interface:

I'm quite pleased to have gotten this far from the initial study I did on an Efinix test board. It feels like years have passed since my successful tests back in December 2025, even though it's only been just over six months. Since then, I've made a lot of progress with VHDL and have other developments underway. Needless to say, I'm once again having to go back to the drawing board when it comes to implementing the Drumulator in FPGA. Plus, with the constraint I've imposed on myself to use as few American components as possible—would that force me to find other solutions? No, it encourages me to do so. And this constraint actually opens up potentially more interesting avenues. I have a few tests to run regarding the digital-to-analog conversion of the Drumulator, and I hope to be able to decide on the new direction to take based on the results of those tests.

My MSX development system in December 2025:

Despite a few hiccups that come with electronics development—especially since I'm more of a weekend hobbyist than a fully certified engineer—I'm pretty happy with the result. But still, I feel it's not going as fast as I'd like. I hope to ramp up my efficiency over the coming months.

Today's thought: US tariffs applied to France. Thank you, Donald Trump.

Today's reflection: US customs duties.

I really enjoy retro-computing. The question I hadn't really settled until now was: with retro components or with modern components? After the Z80 disappeared, the only 8-bit family left was the 6502, still manufactured by Western Design Center (WDC).

I'm currently spending some of my free time on the little Cody computer and the Memo-1, both based on the W65C02S from WDC. On the other hand, I also took an interest in the Commander X16, also based on the W65C02S, because I found that machine interesting.

To keep going with the subject and especially to build the Memo-1 board, I just placed an order for a few W65C02S processors and peripheral circuits from Mouser.

And this morning, the big surprise. Between the shipping costs and the taxes already paid, which already came to €28 for a total component price of €67.35—i.e., fees equivalent to 41.5% of the product amount—UPS has just billed me €49.14 in customs duties. The total fees for this order therefore amount to €77.14, or 114.53% of the value of the goods.

To be perfectly clear about that last sentence: I paid €77.14 in shipping, taxes, and customs fees for a component total of €67.35.

This is quite simply armed robbery. That reminds me exactly of Apple's business practices, which is why I have never bought any Apple products.

- My decision is simple: components of this kind from the United States—It's over.
- Retro-computing with retro components—It's over.
Period.

Americans are definitely no longer my friends!

Thanks to whom?
Thanks, Donald! 

Memo-1

In the series "other distracting activities during the heatwave," I looked into the very simple development by a "local guy"—that is, a Frenchman—who created a small computer based on the 6502 processor, with the particularity of being able to connect to the French Minitel. I always appreciate seeing this precursor of networked computing, the Minitel, being put to use. The capabilities of this machine were very limited. The major consequence was that for more than fifteen years, very simple and highly standardized "digital" applications were developed, which enabled French businesses to rapidly increase their efficiency. Imagine: a very simple interface whose learning curve—just a few dozen minutes—was enough to acquire the reflexes needed for a significant boost in usage efficiency. No stress for the user, the "graphical" interface never introduced any uncertainty. And what about security? Point-to-point connections with no possibility of hacking, unless one broke into Transpac distribution points, which were moreover equipped with non-standard hardware to even attempt sniffing a communication. How things have changed. Using Microsoft's online typewriter, um... yes... why not! And will this still be useful with AI?

I suggest you take a quick look at his YouTube page: Memo-1

I grabbed a few screenshots from his YouTube page.

Charming little board, isn't it?

As usual, its format is proprietary. The author took as an example the format of the old cardboard programming cards that were found on virtually all programmable computers of the era, notably the 80-column IBM cards. The problem with all these cards in incompatible formats is that once the board is assembled and tested, well, you put it away and move on... to the next one. As a result, you accumulate these boards and end up forgetting about them. And when you take them out of the drawers again, you still have to find or rediscover the specific connectors, the power supply, the USB-to-serial converter, etc.

So, for the past few months now, I have decided to take the boards I found interesting and remake them in the Euro RACK format. That way, it will "just" be a matter of getting a RACK with a backplane board and a standard power supply, and the boards can be inserted into the available slots, remaining easily accessible at all times, and, of course, stored in the same place. I have always found the TI99/4A's bus expansion system particularly interesting.

Gorgeous!

So I took the MEMO‑1 schematic and redrew it, replacing the expansion connector with a backplane bus connector. I also added a real‑time clock connected to the VIA via the I²C bus, which will need to be implemented using the VIA's I/O ports. This will require some specific programming that can be done later. As for the backplane bus pinout, I adopted the EuroBEEB format, since that system also used a 6502. This results in a board that is fairly easy to build and has a compact form factor.
 

On the original MEMO‑1 system, the expansion connector is designed to accept a cartridge. This will obviously not be possible with the backplane bus. It will therefore be necessary to design another small board that brings the essential signals to the front face of the rack, fitted with a cartridge connector. 

Regarding the Cody computer, which I also mention in this blog, I intend to convert it to a rack format as well. Since Cody has even fewer components, this shouldn't be very difficult, even if I incorporate the USB keyboard adapter.

These two systems, as well as the EuroBEEB board, are all based on the 6502, or its more modern version, still available from the Western Design Center. For now, I have nothing planned based on the Z80 processor, since it is no longer in production. However, since I have used Z80 cores in FPGAs in the past, I might be able to perform the same kind of conversion for Sergey Kiselev's CP/M-compatible board : Easy_z80 .

CODY computer

Between two "high-tech" developments, back to pure 80s style. This is about adapting a USB keyboard to the computer developed by Frederick John Milens, which I have already mentioned on this blog.

And no, for now I haven't done anything at all with this machine. I just built one copy because I think the whole package created by Frederick is absolutely brilliant. And I mean it. For anyone who wants to acquire the basics of digital electronics and fundamental computing, the machine, along with its documentation, is absolutely brilliant.

Moreover, the creator of Cody uses a whole ecosystem that is easy to get to grips with and completely free. Since all the sources are provided on GitHub, it is relatively easy to modify all or part of the design. And that is what I am going to present here.

As for me, I did not build the machine's keyboard. It is an extra cost and I prefer to use a basic USB keyboard. This is a purely personal choice. I am not interested in taking the retro concept all the way to the end. For me, the spirit matters above all.

So, to adapt a USB keyboard to this machine, the tactic I use is that of the cuckoo. Yes, the one that steals other birds' nests to build its own.

The idea is therefore to slightly modify the computer's hardware as well as the software that runs the machine. 

The concept of my build is very simple.
I use a USB keyboard to serial port converter module.
I use a small processor to convert this serial code into parallel code, which I then present on the Cody's data bus using a bus driver circuit. 

I am modifying Frederick's BASIC, written in 6502 assembly, to take into account not the scanning of its matrix keyboard, but rather the data coming from my small adapter board. Since the source is well documented, it is easy to make this type of modification. Although I have never used 6502 assembly before, I must say it is incredibly simple, even compared to the Z80. I am using TASM to assemble the source.

My system.

There are no modifications to be made in the Cody SPIN source, because the VIA that normally handles the keyboard matrix has a 256-byte address range, whereas only 16 are actually used. So I took bit A4 of the address bus to differentiate between an access to the VIA or to my board. This is the only physical modification I made.

In the ASM 6502 source, I added a constant representing the base address of my board. From then on, the function that retrieves a valid key code from the matrix keyboard boils down to:

KEYDECODE LDA KBD_CTRL     ; Reads the controller output into A
                         STA KEYCODE        ; Stores A into KEYCODE
                         RTS

Moreover, the KEYTOCHR function no longer does anything and returns immediately since there is no code conversion to perform, as I am doing this conversion directly on my small processor board.

Note that since I don't really know how the two special modifier keys are used, I may have to modify my system accordingly. 

But for now, this is enough for me to validate that my setup works.

The final procedure therefore consists, from a software standpoint, of assembling the BASIC source using TASM, recompiling the Cody SPIN project using Parallax's Propeller Tool, and loading the result into the Cody board. What's great about the Propeller chip is that all tests can be run in RAM, before saving the final code to EEPROM. Parallax's tool is remarkably easy to use.

I am using a RISC-V processor and its associated development IDE, MounRiver Studio. I have completed a number of projects with these tools and I must say that the latest version of the IDE is even more efficient, practical, and pleasant to use. In short, I don't regret the time I spent a few years ago discovering these processors.

Anyway, once everything is set up, it is fairly easy to achieve the expected result. I only spent a few hours of pure hobby time developing this adapter.

Validation of my concept.

And there you have it, the basics are working. All that remains for me to do is to complete the software part to fully emulate the original keyboard.