A flash cartridge downloadable from USB, a few days later.

As I indicated in my previous post, I had almost reached the end of creating my USB downloadable cartridge, but unfortunately, the USB protocol generates periodic activity on the USB bus, which is disrupts operation of my cartridge. This involves unplugging the USB cable once the download is complete. This was not the objective that I had set for myself, namely to leave the cartridge connected to the PC while being used in an MSX computer.

So I had to find a solution. In fact it is very simple, use two processors on the card. The first manages USB communication, the second manages loading the cartridge and providing data to the MSX bus.

Yes, two processors. As the entire software aspect is already developed, all I will have to do is manage the communication between these two processors to finalize the project. As in any case the cost of the additional processor is comparable to that of a DIP FLASH, this solution is not that 'absurd'.

And the result of my thoughts is this:

I must say that the result is quite clean. I still have to check the placement of the notches because on the previous version, I realized that the insertion into the case was slightly forcing.

Ah yes, I also added the possibility of choosing the slot in which this cartridge should operate. Like this, the 'concept' is complete.

A flash cartridge downloadable from USB.

Everyone knows the cartridge system of microcomputers from the 80s. The MSX, a machine from that era, is no exception to the rule.

When you don't know anything about this type of machine, and when you finally get one, the first thing that comes to your mind is to see how it works. And so to do this, insert a cartridge, if possible of games, obviously!

This is when the problems start. How to do today when MSX has been commercially dead for more than 30 years. How to find such cartridges. It is of course possible to find them on the second-hand market. But buying 10 cartridges to test 10 games, well, that's not really viable.

The idea came very quickly to see if it was not possible to have a cartridge that could be refilled on demand, by SD card or USB device.

The Carnivore 2 cartridge, which also offers extras, uses a FLASH card to operate. You have to be able to find a compatible flash card, which is not always easy. I was never able to use the one I bought. The FPGA was poorly soldered and the cartridge quickly became unstable.

Straight into the trash :-(

There is the MegaFlashROM_SCC+_SD. It's the only one I managed to use. But to use it, there is a whole procedure to follow which is boring. And if you don't do this every day, you will have to find the documentation each time to successfully re-initialize the cartridge and copy your new game into it. The least we can say is that this solution is not practical at all. In addition, you have to use utilities that are provided in the cartridge while understanding what you are doing. And when you don't know anything about MSX, it's not engaging!

There is also the solution using a USB device like a key. For this, the rookie-drive-nx cartridge seems ideal. But also, after reading the documentation, I have never been able to get a USB device to be accepted by this cartridge: frustrating.

There is also the SD 512 but given the price of my three previous purchases, I decided I was going to discontinue the charges. So I haven't tested it.

Because, in fact, my goal was to test as easily as possible an MSX board that I had just built, Sergey Kiselev's OMEGA computer.

I had been dying to get my Omega board working for a while now. Because I don't want to spend more on a specific keyboard, I took the time to develop a USB keyboard converter to the OMEGA computer. 

I have also made the result of my work freely available on Github at this address: https://github.com/sillycony/USB-keyboard-to-OMEGA-converter.

So... I was looking for a solution to make this machine execute something in a simple way. This is how the idea of ​​creating a cartridge that can be downloaded via USB came to me.

I don't know if this is the easiest solution at the moment because I'm in the design phase and it's not yet finished despite several previous prototypes.

But I know that once finished, the cartridge will be very easy to use. Simply insert it into the cartridge port of the MSX machine while also connecting it to the USB port of your PC. Dragging and dropping your binary file onto the cartridge, which will be seen as a USB key, will be enough to make the ROM for the MSX available in a few seconds.

If the final solution for my cartridge is not ready yet, I am posting about it now because I have almost achieved what I wanted.

But why is the current beta version not satisfactory?

Well it's very simple: because the USB protocol imposes regular requests from the host to the device to check its proper functioning. And it happens every few seconds.

And? Well, the response process requires the processor on the cartridge to respond ;-). And that takes time. Even if the processor used is fast, while it responds to the USB request, it cannot respond to computer access via the cartridge bus. Result: the MSX computer crashes! But, when the USB cable is unplugged, everything works as expected, as shown in the picture above.

I even planned the automatic RESET of the MSX computer while loading a new binary, so that it then restarts on its own on the new game, or new application. It works very well.

I therefore need to dissociate the USB bus management function from that of the MSX bus management. Because I don't use a FLASH strictly speaking, but the flash contained inside the processor. 'Small capacity' flashes in DIP housing and parallel addressing are becoming more and more difficult to find and more and more expensive. 

So I don't have this problem with a processor equipped with the desired amount of Flash. In addition, it makes routing the printed circuit easier.

The final cartridge diagram looks like this:

I know, it's difficult to read. It's just a screenshot. But we can notice two big circuits there. These are the two processors used. The one on the right is in charge of the USB port, the one on the left is in charge of storing the binary of the cartridge and presenting it to the MSX bus. 

This will cost a little more to produce than expected, but as the two processors are the same models, I will be able to take advantage of the quantity order to reduce the final price.

The software is ready and validated. All I have to do is implement each processor with its part and add a small communication protocol between them. The most 'tricky' part consists of creating a new printed circuit board with more components. But I think I can use the design of the current cartridge to facilitate this new implementation.

I must say that this is now the second project that I have carried out with a professional type process with all that this implies of prototyping, extensive testing taking into consideration a whole bunch of parameters including price, ease of realization, reliability etc etc...

I must say that it is a very enriching experience... When I think of what the type of job I had at the French university was, just a few months ago... What mediocrity!

UTC1122, AUTOMATION, RETRO COMUTING, MINIMAL COMPUTING.

Some improvements to the device's I/O circuit board. I also added a precision clock. I'm thinking of modifying the main clock program to use this precision clock.

Doing retro-computing is so much more fun!

 In 2022 one of my projects consisted of placing a Micro-Professor clone entirely in an FPGA.

For this project, I created an external mechanical keyboard. Because the original membrane keyboard did not seem at all effective for working intensively with the machine. I know something about it, I learned the Z80 assembler on the 1P version in 1987. Memories...

The keyboard, along with Wichit Sirichote's version of the mPF1 and my FPGA version.

After publishing information on my FPGA version on the network, and after receiving some comments, especially about the keyboard, I decided to build a new version of it. This time with a processor that is easier to handle, a RISC-V in this case.

This is what it should look like:

This new keyboard will not be dedicated to a particular hardware type. It will provide its data in standard serial form but in RS485. This is to allow a certain immunity to noise as well as possible positioning quite far from the device to which it will be connected.

Another thought on the Microprofessor: When I had made my version, and knowing that I implemented a USB/serial link allowing the program to be loaded at high speed, I quickly realized that I was not using the keyboard to do the development, it was much more practical on my PC with the SDCC 'C' compiler, but I used it more to interact with the program that I had loaded into the system.

Considering that it is entirely possible to write parts of code in Z80 assembly inside a 'C' program, I tell myself that it is much more relevant now to work in this way since this also allows you to become familiar with the 'C' language...

From the beginning, I hated the midi hardware infrastructure (II)

 And first of all, the typology of the pseudo MIDI network.What a horror this thing is...

The 'Barbie game' level! Cables everywhere, an assembly that looks like nothing. A chain going up and a single point to point going down. So we have to start by changing that!

And get rid of those damn 5-pin MIDI sockets that are useless to manipulate!

From the beginning, I hated the midi hardware infrastructure

 Couldn't it be that simple?

It's high time to get started, don't you think?

8 ports MIDI to CV/Gate converter.

And now, the resumption of an old project for which I had not achieved the expected result.

I appreciate simple but effective designs. In this little game, however, I sometimes get fooled by choosing a component that meets the criteria of simplicity and functionality but which may present one or more small drawbacks that I think I can overcome with software.

Most of the time, this is the case. Sometimes, well, it fails miserably. In addition to wasting my time programming, sometimes I even have to abandon the concept altogether! This is the case for my previous version of this type of project.

All is never lost, you learn from your mistakes. And then we return to the subject, this time being careful not to fall into the traps typical of this kind of project. That's what I did here.

The image shown below is the second iteration of the basic concept. The previous prototype just served to validate my new concept.

This new study of a MIDI CV/Gate converter is more complicated than the previous version. There are more components. However, it's mostly 8 times the same type of CV and Gate outputs, with just the control processor. So, it's not very complicated actually.

However, I still improved the basic concept by allowing CV output of three types:
-5V ~ +5V; 0 ~ 5V; 0 ~ 10V.
Likewise, Gates outputs can be positive or negative.

I also added two potentiometers and two additional switches which will allow me to configure the device at a minimum. 

In fact, it's not a bad improvement. While I'm at it, I'm also switching from an ARM processor from STmicro to a RISC-V processor. I got used to these new processors pretty quickly. I have mastered them well and find them very practical to use.

The prototype was more condensed. This was not a good idea in my opinion because it did not allow practical handling of the device. The final version will therefore be larger

All that remains is to have the printed circuit manufactured and to test this new version.