STM32 processors, in fact...

I mentioned in a previous post that I wasn't about to use the STM32 family of processors again. I had been testing with an STM32H5xx processor, using the STM32CubeIDE development software and its 'friend', STM32CubeMX, since for the first time in a long time, the software suite was working for me.

It's true that the new STM32H5xx processor family is interesting for several reasons. On the one hand, these processors are fast, they can operate at up to 250 MHz and, above all, some models offer 512 KB of flash memory and more than 272 KB of SRAM memory.

I then thought that this could allow me to develop a new version of the MSX cartridge that could be loaded via the USB port.

In my previous cartridge version, I used the principle of external mass storage. To simplify, the MSX cartridge behaves like a USB flash drive. Subsequently, the file recovered on a FAT12 file system type media, was recovered and copied in RAW format to the cartridge second processor.

This is what the cartridge looked like:

In fact the right processor retrieved the file through the USB port connected directly to a PC. Then sent the retrieved file directly in RAW format to the second processor which 'provided' the data directly to the MSX computer.

This system wasn't easy to develop for a number of reasons. Most importantly, file transfer from a PC is unreliable. Not because the data could be corrupted, but simply because it's completely impossible to know if the entire file has been transferred!

And that's not practical at all!!!

Additionally, the processors used were a bit more modest in terms of Flash and SRAM resources.

So, I wondered if it would not be relevant to try the adventure again on one of these STM32H5xx processors.

However, I had two 'problems' to resolve. The first is that I no longer have to use file transfer in the file system sense, but rather a transfer in the sense of direct byte transmission. So I chose to use a serial file transfer using the YMODEM transfer protocol.

The Ymodem protocol allows you to receive the name and size of the file, which can be interesting, but above all the transfer is done in specific blocks with possible CRC correction, which suits me very well.

The second problem for me is not having to use what seems to be something downright overly complicated on the system provided by STmicro (see my previous post) : the USB function of the STM32 processor. So, I decided to go straight for a small external USB/serial converter circuit.

This last point will also allow me to set up good galvanic isolation between the PC and the MSX computer.

In short, this change of direction should allow me to make the operation of my MSX cartridge more reliable. Because although I have never had any operational problems with my own MSX computer, it has happened that it did not work correctly on other MSX, without me being able to determine the reason for these malfunctions.

Here is what the first prototype of this new study looks like, based not on a RISC-V processor but on an ARM processor from the STM32H5xx family :

To summarize, this new version offers a faster processor, a more secure and controllable file transfer system, and better galvanic isolation.

I have already carried out some preliminary tests on a study board, namely transmission with Ymodem and programming of the internal flash of the processor.

Additionally, I should be able to install a more convenient status indicator system than the two original LEDs.

This new cartridge should also allow me to automatically reboot the MSX computer without using an external system. It should also be able to integrate different mappers for a total of 256KB of memory. Finally, my system should also be able to be updated using the same file transfer mechanism. I have already successfully performed code relocation tests on this new processor.

Transfer times should remain fairly short, given that I chose a speed of around 230Kbauds, which did not cause me any transfer problems during my tests. A full cartridge should therefore be able to be transferred in around ten seconds, plus the writing time in FLASH, which will also remain very low.

And so, I now think of using this processor in my study on the construction of the Drumulator type drum machine...

A few days later...

The request for a prototype PCB has been made. I'll then be able to work directly on a properly assembled circuit. This will already save me a lot of unpleasant surprises, especially those caused by assembling the processor by hand...

Sometimes...

We repair electronic machines for people who are often nice but from whom we don't hear anything once the machine is back on.

And then sometimes we receive a little gratitude indirectly:

https://www.starwaxmag.com/custom-page-detail/125836-tomska

Tomska thanked me in a Facebook post. That's very kind of him : 

The original post is here : Facebook

A thought for Philippe, who looks at my blog from time to time 😉

I love STMicroelectronics :-(

It's been a while since I've looked at this manufacturer's microcontrollers. The reason was simple: over a fairly long period of time, I haven't been able to install their STM32Cube IDE and MX development system without the installation of these tools crashing miserably.

And then recently, I got caught up in an ad promoting the benefits of the STM32H5. It's true: the amount of FLASH and RAM are interesting, as is the maximum operating speed of this circuit.

So, 'for a laugh', I tried installing the IDE and MX. Unbelievably, the installation went smoothly. I was very surprised. But anyway, let's move on...

I wondered if I would be able to produce the classic 'Hello World', namely the flashing of an LED, in less than an hour. To my surprise again, I was able to do so.

At this point you must be wondering where 'the wolf' is hiding?

Well in the USB my friends!

Yes, STMicroelectronics has abandoned the classic USB management, present in the CubeMX graphic configurator, to replace it with the USBx driver.

And what is this thing? Well, a driver that has to do with Microsoft and Azure, and more specifically Azure RTOS. YES!!!

Isn't that fantastic? Microsoft's mess right inside your microcontroller, and for free!!!

And on the ST page, the little explanation of what it is. Without more explanation than that, by the way. Hmm!!! Setting up a 'gas factory', just to implement a 'small' USB communication? I already had the opportunity to implement the MIDI protocol via USB on a small ST processor with the 'standard STmicro driver', a few years ago, with the initialization carried out by CubeMX. Well, all that is finished.

On the ST Github repository, there is also a little explanation that goes well:

Ah, but no, ST doesn't leave you alone in the desert, they provide a package, which cannot be integrated into CubeMX, to "ease developers' life by reducing efforts, time and cost."

I want well to believe them, but in reality, it means more like 'manage on your own' : 

I like it!

It's not today that I'm going to come back to the components of STmicro!!! I think I'll stick with my Chinese RISC-V processors. They're a bit more rugged than the STM32s, but hey, I've already spent a good amount of time working on using the USB port. I don't want to spend months and months on the 'skills upgrade' for the ST microcontrollers...

Well, I still have a blinking LED on my desk, driven by a 250 MHz processor. That's not nothing!

Drumulator : with RISC-V processors.

For now, I'm working on the analog output board of the Drumulator. After testing the feasibility of my concept, with the help of a few off-the-shelf boards, I'm starting to draw up the schematic diagram for the audio section of the Drumulator.

The schematic isn't complete yet, but there are already number of components.

This shouldn't take up too much PCB space, though. One of the dimensions will be dictated by the alignment of the audio connectors.

Drumulator : with RISC-V processors.

And meanwhile, I'm making progress on the subject.

And it doesn't have to be simple! My goal is to make it 'easy' and not too expensive to manufacture. The idea is to design a quality machine that has a good sound.

The options to consider, the best use of available resources, and other considerations mean that it takes a little time to develop. But in the end, I enjoy that moment when, after many development difficulties, I feel that the final solution is taking shape.

Rather than designing a test circuit and then going through the cycle of testing and modifying the circuit, this time I preferred to use already available development boards. Obviously, this makes the development look a bit DIY, but in the end, it goes pretty well.

To facilitate the development of the machine, I opted for a modular design. That is to say that for the moment, I am focusing on the analog part in order to start by producing the audio output board which will be easily connected to the operating core of the machine which will have to copy the operation of the original Drumulator.

So now I'm at the stage of creating the schematic. I'll have to make the board and then run the tests. This is a process that, despite the ease of having electronic equipment made today, still requires a bit of time. But there you go, the subject seems to be off to a good start...

The Cody Computer : processor board assembly

As a reminder, the Cody computer is a small machine that is, in absolute terms, could be considered no more interesting than any other project of this kind.

Over the past twenty years, hundreds of projects like this one, and probably even more technically interesting projects, have seen the light of day. To my knowledge, all of these projects quickly fell into oblivion. I'm thinking in particular of Geoff Graham's Colour Maximite II (https://geoffg.net/maximite.html) project because I followed this project for years, and then, nothing...

All information about Project Cody is available at this address: https://www.codycomputer.org

But then why be interested in Cody?

The main point that caught my attention about this project is the excellent documentation that the author has produced on his machine. 

Beyond the machine's own characteristics, some of which are unsuitable for me, this documentation makes the assembly, use and programming of the machine completely understandable. All the documentation is in a 'small book' pdf that can be downloaded from the project website: https://www.codycomputer.org/TheCodyComputerBook.pdf

Furthermore, Cody comes in the form of an electronic board that could almost fit inside a ZX81 case. But it is of course more powerful than a ZX81. Equipped with a 6502 processor, it would actually look more like a Commodore C64 with less complex electronics. So, I find that it brings together two interesting aspects, the ease of understanding of the machine, and the power of a Commodore 64. Interesting, right?

So I decided to build this small computer to judge how difficult it was to make. My latest experiment in this area concerns the construction of the Omega computer, type MSX, by Sergey Kiselev : (https://github.com/skiselev/omega/blob/master/Mainboard/images/Omega-Keyboard_and_Mainboard-1.1.jpg)

Omega

Assembling this machine is not complicated for someone with experience, but for a first approach, it is still a different 'story' than assembling Coddy's motherboard :

Cody

As you can see, Cody also contains four 'big' integrated circuits like the ZX81 motherboard. Indeed, Cody also contains 3 other small integrated circuits to solder, which does not complicate the machine further, given that there is no HF modulator to install. On Cody, it is a Parallax circuit that manages the video by directly providing the composite video output (CVBS).

In comparison, the ZX81's board :

Cody therefore looks very much like a ZX81 kit to assemble from the time without more difficulty, but with a more interesting result than the ZX81. So to assemble this little computer, I put myself in the mental conditions that were mine when I was a teenager and I didn't know much about electronics.

I obviously had the printed circuit board made at JLCPCB (that wasn't possible at the time) and bought the four main components, namely the two processors, the RAM and the I/O circuit. I already had the EEPROM. The bus driver, a 541 and the CD4051 were taken from my stock of more or less new components...

I assembled the machine, not with the help of the sheet, but by scrupulously following the instructions and the assembly chronology as indicated in the documentation. It takes barely more than an hour of work to achieve this result:

I almost assembled this board in 'brute force' mode. I didn't have the recommended 3.3V regulator. I put another one in CMS version. The resistors for generating the video signal are also not exactly those recommended. There are a few Ohms of difference. I even created one of the resistors by putting in series two resistors that I had, for a result very close to the original desired value. In short, I tried to make a clean assembly, but with certain tolerances of the type that a beginner could make.

I also didn't buy a original 'Prop Plug' to program the Parallax circuit, I figured the FTDI-style USB/Serial adapter would be enough.

After testing the board's power supply, and initially setting up the Parallax circuit and its EPROM that I programmed using the Parallax tools, the machine did not start correctly, or even did not start at all, and displayed some time parasitic characters on the screen: not a good sign and a slight disappointment. I thought it would start without any problem.

First thing, when programming the Parallax circuit with the Propeller Tool software (https://www.parallax.com/propeller-2/programming-tools/), I had a communication error message telling me that the communication was not going correctly with the processor (/RTS used as RESET signal). In fact, and after several tests, I realized that when acknowledging this error, the application was still programming the processor correctly. I was able to verify with the oscilloscope that I was getting a composite video signal at the CVBS output.

The way Cody is built, assuming the Parallax circuit was programmed correctly, and assuming the 65C02 processor was new and should work, all I had to blame was the 74HC541 bus driver circuit. So I replaced it with another circuit, also from my stockpile, and voila!

As you can see, I went into full DIY mode, with a less than rigorous assembly procedure, but still practicing quality welding, and the machine worked almost the first time. The initial malfunction was only due to a defective component in my stock.

This way of doing things, not entirely according to the rules of the art, allowed me to validate the high feasibility of assembling this small machine, even by a relatively inexperienced person. I expected this result, which is why I 'pushed the vice' to really assemble Cody in beginner mode.

Because there's nothing worse than demotivating someone from the start who doesn't know much but is eager to learn. The possibility of error must be present without it leading to an intellectually catastrophic disaster. This is why I particularly appreciate the approach of the author of this little machine.

And now? Cody doesn't have an operating system but programs itself directly in Basic. It's ideal for getting started in the wonderful world of microcomputing. I haven't written a single line of Basic on this machine yet, and for good reason: I haven't built the keyboard.

Personally, I don't find it very useful to build a specific keyboard for this kind of machine. Obviously, the look loses a bit if you use a standard keyboard but hey, that's my opinion. So I'm going to do what I already did for the Omega, I'm going to create a USB interface allowing you to directly connect a standard USB keyboard to Cody, I find it more practical. The user experience is more comfortable, especially if, as a passionate person, you start spending long hours programming on this little machine...

Drumulator : with RISC-V processors.

Well here we are...

First in a long series of iterations on building a Drumulator clone. As a reminder: after trying to create a Drumulator using FPGAs, I gave up following the time wasted on the last used circuits from the Efinix brand.

Additionally, real-time debugging is much easier with microprocessor tools than with FPGA tools. Well, basically, for the type of subject in question here, it ultimately seems much more relevant to me to start on a microprocessor basis than on an FPGA basis.

In addition, this should also allow me to offer more capacity for the machine envisaged, while retaining exactly the same characteristics, including the non-linear 8-bit sampling which gives all its charm to the Drumulator.

To begin this series of micro-developments, I will focus on the sound generator since, ultimately, it is this generator which is the heart of the machine.

On the original machine, it is a whole series of logic circuits associated with static RAM which manages this subject. Moreover, EMU calls this sound generator, a 'sound sequencer'. The goal here being to do the same thing but using the minimum number of circuits and the minimum number of electrical connections, I am therefore going with a converter whose digital data will be supplied by the SPI bus.

In the continuation of this development, I will also try the use of an SPI type wave memory, in order, again, to minimize the need for connections. All this will have the effect of reducing the cost and electromagnetic radiation.

So, for now, my very first test is to set up a reliable SPI link to the digital to analog converter.

I'm not going to detail the whole process here, but basically it involves generating an SPI bus with the characteristics expected by the audio converter. That is to say, the number of bits expected, the different polarities of the signals and the frequency acceptable by the converter, here 10Mbits maximum per second.

So I configured the registers of the processor used to match the needs of the converter. I even made the maximum frequency dynamic to always configure the maximum frequency achievable by the processor according to the configuration of its clocks, but while always remaining less than or equal to 10MBits per second.

The signals seem completely correct and, in any case, present exactly the programmed pattern:

u16  Data = 0x555D;

I will now tackle the generation of interrupts. In fact, the data to be sent to the converter must be sent a certain number of times per second. It seems to me that it is around 22KHz for the Drumulator. I'll look up the actual value later. For the moment, it is a question of generating the same SPI signals not inside an infinite loop in the main() function, but directly by interrupt...