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.

I really don't know where I'm going with this!

Implementing an FPGA isn't very complicated in itself. Whether on the hardware or software side, all it 'takes' is the right learning and a little (or a lot of) motivation to get there. No, it's rather what comes after that gets tricky. The potential of these types of circuits is so vast that you can consider using them in a huge number of applications. The problem then boils down to development cost. It's tempting to pack as much logic as possible into the FPGA. As a result, you quickly find yourself needing a chip with a good number of I/Os, and therefore a large pin count — and thus, a BGA package.

The development cost of a PCB designed to host a BGA-packaged FPGA is not the same as that of a board equipped with a small microcontroller. Nor are the risks of malfunction.

Considering that my field is more on the 'mixed' side — that is, both digital logic and analog — I find it risky to dive into the design of large PCBs containing a BGA package. I prefer to go the module route. That is, to focus specific efforts on the most precise sub-assemblies possible.

I'll take my process of putting the Drumulator into an FPGA as an example. Designing a relatively large PCB with a BGA seems inappropriate for an amateur-style build. So I decided to create an FPGA module tailored to my needs. I should mention that I've already built this kind of module with GoWin FPGAs, but in a 144-pin package. As a result, I didn't implement any memory on that module at all. However, with the goal of providing a complete computing core, I need memory.

So I went with an implementation using a TRION FPGA coupled with static RAM, an EEPROM for storage, a real-time clock, and a battery for backing up the memory and time.

Obviously, I couldn't get away with a two-layer PCB this time. This time, it's four layers. To keep manufacturing costs acceptable, I'm also forced to use through-hole vias, which complicates the board design.

But anyway, after a certain amount of time, I managed to produce the design for the board I want to build.

 

I have to admit that it took me a while to route the entire board. I think I've done a better job than I did with the MSX cartridge. I suppose that's normal — it takes experience, and experience only comes through iteration.

That said, on this board, I paid particular attention to the connections between the FPGA and the SRAM. The traces are short, and I matched the lengths of all bus signals, so that a fairly high operating frequency can be used.

As for the available I/O connectors, generally speaking, the traces on the 'component' side will be fairly fast since they won't encounter any vias. That should compensate for the signal integrity loss caused by longer trace lengths. The other signals will have at least one via along the path, and some of them two, though the latter case is very rare.

I have no idea how I'm going to actually assemble this board. The PCB manufacturer I work with doesn't stock Efinix FPGAs. So either I find another supplier capable of assembling these FPGAs, or I mount them myself. In which case, I'll need to get a hot plate to solder the main components.

Moreover, I don't know whether the wiring as it stands will actually allow the JTAG programmer to work properly. To figure that out, I need to wait until I implement the MSX cartridge, so I can verify that the power supply I've set up is correctly matched to the FPGA, and that the JTAG connections are properly made.

So, designing this board has already been an adventure. I was really skeptical about whether I'd even get to the end of it. Assembling this board is going to be a new adventure. But hey, if I really want to move beyond the 'Sunday tinkerer' phase, I have to take it to the next level. And since I've now gained a good command of VHDL coding, I no longer have a choice — I have to go for it.

 

And now for something completely different!

While waiting to receive the printed circuit board for the MSX cartridge, I started working on making a compatible USB card for the AKAI S5000/S6000 samplers.

The reason is that I know someone who is developing a new version of AKSYS that works perfectly under Windows 10 & 11. It turns out that not all Akai S5/6000 machines were shipped with this card. That's a shame.

So I studied the card I own and looked into whether it might be possible to create a new version.

It turns out that it is.

On the one hand, a USB component compatible with the one on the original USB card still exists today. And on the other hand, I was able to retrieve the logic equations of the PAL chip that is on this card.

For now, these equations seem to be correct, since I was able to repair another original but faulty USB card using a GAL programmed with my equations. So I am hopeful that this will work, even though the decoding performed by the original PAL is quite unusual.

The card's schematic is also unusual. Without going into too much detail, some functions are implemented by first latching a kind of register — registers made out of resistors and capacitors.

In short, the read and write functions are not direct but require going through other operations first.

In any case, I have completed the schematic and then the PCB for this card :

So, I have no idea whether this new card will work or not. The only way is to test it and compare the signals with the original card if it doesn't work.

Next steps after the first tests....

New batch of triple output PSU, for not only the PROPHET-VS!

A few years ago, I developed a regulated power supply with three outputs: +5V, +12V, and -12V, primarily intended to replace the one found in the Prophet VS.

The characteristic of this power supply is that it is fundamentally a high-performance switching power supply, but not directly connected to the mains voltage; instead, it is powered by a step-down transformer providing 18V AC or, better yet, 24V AC. Consequently, this power supply does not present the dangers inherent in using switching power supplies that are directly connected to the mains.

As a result, the overall efficiency of this power supply is much better than that of a purely linear supply. The 5V output comes exclusively from the switching power supply section, whereas the two analog-dedicated supplies, i.e., +12V and -12V, are derived from high-quality linear regulators, followed by filters to suppress any residual harmonics. The voltage supplied to the linear regulators is just above the input voltage required for their operation.

With all these precautions, the power supply runs globally very cool and is capable of delivering 1A on each of its outputs.

Additionally, a special connector provides everything a processor-based system needs in terms of RESET and faulty voltage indication, thanks to the addition of a specific component that performs monitoring and control operations with precision. This component is a MAX707CSA+T. Note that a CR2032 battery holder is available, providing a backup power pin on this connector.

Finally, three connectors — including one specific to 3.5-inch floppy disk drives — are provided to facilitate connections.

In fact, this power supply can be used both for repairing synthesizers, as in the case of the Prophet VS in this example, and for powering any device operating on 5V requiring high-quality symmetrical power supplies for an analog section.

A new batch of these power supplies has been produced.

 

 

 

 

 

The Z80 CTC: what a poem this thing is!

Over the past few days, I've returned to implementing the Drumulator in an FPGA. I won't go over the whole story again, but after multiple attempts and failures to produce a viable VHDL code for the Z80 CTC, I finally managed to create a 'minimal' version earlier this year (2026), thanks to a 'great' collaboration with AI that began in December 2025.

I knew that even if this time I managed to boot the Drumulator system on the Efinix FPGA board, my code wasn't very good—especially regarding clock domains, not to mention the rather poor operation of the entire channel clock management circuitry.

Confirmation that my 'CTC' wasn't working correctly came when I tried to implement the management of the Drumulator's data potentiometer."

The operation of this system is very simple to understand. The Drumulator initializes a pulse on the 74LS221 circuit. This pulse lasts for a 'certain time', corresponding to the charge of capacitor C77, charged by the current flowing through the potentiometer. This pulse acts as a gate, allowing the CLK.D clock to trigger one of the CTC counters — in this case, counter n°2, since it is connected to the CLK/TRG2 input.

However, this requires a specific programming of CTC channel 2, in counter mode. But that's not enough. The designers at EMU exploited the CTC's characteristics to the fullest. Thus, they fully utilized the operating behavior of the CTC's RESET system.

Last week, I completely rewrote the CTC code, this time fully managing the different clock domains and implementing the entire logistics chain for configuring the channel clocks. Apart from a small issue regarding the trigger edge of the Write signal, everything worked from the start.

But since the CTC is (in my opinion) now properly programmed, every little inaccuracy comes at a cost!

The first issue was initializing the counters to ZERO. I hadn't looked closely at the documentation on this point — well, because it didn't seem like the most important thing. Except that handling ZERO is important. In fact, it's very simple. The counter counts from 256 down to 0. Except that 0 triggers the counter reload and possibly the generation of the channel interrupt. The counter must therefore be 9 bits, not 8, and when you load the value 0x00, you actually need to load 0x100 — easy!

The other problem concerns the CTC's RESET system. Again, it's very simple once understood, but because it's not intuitive, it takes a little time to grasp how it works. It's a rather strange behavior — in any case, it doesn't match at all what one would expect from a 'standard' RESET. Since explaining it here would be a bit long, those who are curious can refer to the CTC documentation.

Since I now have a fairly good command of the Efinix debug tools, I was able to use them to trace the RESET behavior and finally understand where my misunderstanding lay. Now, it's understood."

And the result is:

The Drumulator is in tempo adjustment mode. This is done using the potentiometer stuck between the black and yellow terminals of the breadboard,

It works very well. However, on my breadboard, I powered the logic circuit not with 5V but with 3.3V. As a result, the trigger thresholds are no longer exactly the same. I was able to easily correct the operating range so that the minimum and maximum value ranges correspond correctly to the extreme positions of the potentiometer wiper, simply by adjusting the CLK.D clock that triggers counter n°2. 

Now I have all the technical aspects of the Drumulator implemented. I even have the metronome output! I don't think I will handle synchronization because everything is done via MIDI now. I'm also not going to implement the cassette interface since no one uses it. I'll consider using another backup system instead of the cassette.

I think I'll stop my FPGA-based investigations on the Drumulator for a while. Now I need to create an FPGA core for this Drumulator. I've started designing the printed circuit board. But before moving on to the physical realization of this circuit, I will now finalize the MSX cartridge. It is with this cartridge that I will see whether my Efinix FPGA implementation has been done correctly.

I've been tinkering with FPGAs for years. But I hadn't acquired the general mindset to adopt for programming them. AI was a very good trigger, showing me the way of what needed to be done and what was best to avoid. With this help, I accomplished in 4 months what I hadn't managed to do in over 10 years. Beyond the pleasure of (a small) success, it is also and above all the pleasure of the intellectual groundwork progression that this gave me!