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...

Drumulator : with RISC-V processors?

When you want to recreate an existing machine, is it better to recreate the hardware to install the original software, or to create new hardware but with the need to also recreate the software system?

After years of various tests, I chose: I recreated absolutely everything.

I recreated the Drumulator hardware in a number of FPGAs. Since these circuits are very expensive, I changed FPGAs several times, ending up with GoWin FPGAs in 2021. However, these GoWin FPGAs have increased significantly in price after 2022, making these circuits much less interesting. After further research, I finally found the Efinix brand FPGAs.

It took me some time to get used to these new circuits. But I managed to implement the Drumulator processor core. Unfortunately, if the system seems to work well, a few moments, quickly, the display shows anything. Despite having tested the entire Z80 interrupt management system, I am still unable to understand what is happening. Especially since I took the VHDL source code that allowed me to implement this Drumulator in the Altera and GoWin FPGAs.

Seeing time passing without being able to get out of this impasse, I decided to abandon this way of doing things and recreate the machine from scratch. In fact, and to repeat a remark from a former electronics professor who told me in the early 90s, "you are really a guy from the 80s technos", that is to say that I am rather very comfortable with microprocessors, well I will use one or more small fast RISV-V type processors. They are really not expensive and allow to perform fast tasks, knowing that they are capable of operating at 144MHz.

I have already had the opportunity to make a timer compatible with the TMS1121/1122 in this way. Indeed, it took me a little time to make the software because, contrary to what one might think, it is not at all obvious to move from a type of operation imposed by the programming system of the time, namely assembler, to an advanced language of the C type. It is mainly a problem of structuring the code and data.

But hey, I got there.

Not to mention that the development software allows real-time debugging with display of variable, register and memory values, all in a very dynamic way.

All this is not possible with FPGAs and especially the associated software which are, at least for Efinix, very slow and not practical at all, from my point of view.

In addition, the idea being to create a system as simple as possible, with a printed circuit board as simple as possible. The use of these small RISC-V processors will allow me to synthesize the machine into several parts which will, therefore, be more easily modifiable or even upgradeable.

The heart of the machine being the sound generation sequencer, I will start by recreating this part inside a RISC-V processor.

The operating principle of this sequencer is very simple. A certain number of times per second, the sequencer compares a base register of a sound address, with the value of the end address of the sound considered. As long as these two registers are not equal, the sequencer retrieves the data from the current register, in fact the base one which is incremented at each reading, sends this data to the converter while selecting the assigned physical output, thus increments this register. The operation is repeated as long as the base register has not reached the value of the end of sound register. This is also repeated for the eight outputs in the same period of time. And so on.

The experiment here will consist of checking that I can actually perform all these operations in the allotted time, knowing that I want to use components operating on SPI bus so as not to have to route a large number of tracks on the printed circuit.

This means that I will use an SPI DAC but also an SPI type sound memory. I must therefore perform an initial SPI reading of the memory then an SPI writing in the DAC. This process must be repeated eight times in the same amount of time, all a certain number of thousands of times per second.

Will this be possible?

In principle this should be possible. The SPI buses will be configured at 10Mbits/s due to the characteristics of the SPI components. This will give a transfer possibility of one Mbyte or 500K words (of 16 bits) for each component. Knowing that the sampling frequency is a little more than 20KHz, 22Khz I think, the transfer capacity must be 22,000 * 16 (8 words in SPI reading and 8 words in SPI writing) or a transfer of approximately 352,000 words of 16 bits per second. We are well below 500,000. This should therefore work without problem, knowing that purely processor operations on address pointers are very simple.

To return to the long-overlooked policy of small steps, the first operation consists of configuring the SPI port of a RISC-V processor to allow it to communicate at around 10Mbits with a 12-bit audio converter.

For this I will take an audio board that I developed two years ago now, containing everything necessary for the development of the eight outputs of the Drumulator:

As for the development board, I will use a test board that can be easily found on the Internet:

I have already tried to do this type of operation with the DAC board using an ARM circuit from STmicro. But there is nothing to do, I can't get used to the development environment as well as the different ways of using ST libraries depending on whether you want to work at a low level, i.e. close to the hardware, or at a higher level. I really prefer simple environments and development software that is not too graphical, which requires you to program the necessary registers with full knowledge of the facts without potentially being 'fooled' by the development software. In short, with ARMs, I did not achieve a satisfactory result. I hope to achieve this with this RISC-V processor.

EMU : STOP!

Since my last post about trying to repair the EMU1, I've done a whole bunch of new tests. I also replaced a few integrated circuits. The result is that I haven't progressed one bit.

I still can't load the loading utility from the floppy disk. Whether it's from the actual floppy drive, or whether it's using the HxC emulator.

I now believe that I have carried out all the tests that I could. The problem in this story is that I absolutely don't know the loading program written in the boot EPROM.

It is not impossible, for example, that the motherboard must be correctly mounted in the machine so that information coming, either from the digital/analog conversion boards, or from the control panel, allows the program to exit a loop in order to actually process the data read from the floppy disk.

From what I have done as tests on the motherboard, I know that all the logic for shaping the signals coming from the floppy drive works. As well as serial reception by the SIO/2. Selection by a few PIO output ports also works. Finally, I know that the RAM does not have defective memory.

So I was finally able to test the signals concerning the triggering of DMA when reading floppy disks. And here too, everything seems correct to me. However, the machine obviously tells me that the data coming from the floppy drive is not reliable. I don't understand the reason.

However, the fact remains that the data bus signals are horrible! I also worked on this aspect, managing to obtain very square signals. However that wasn't enough, I always get into a loop trying to read the data without ever getting out.

So, given the time spent doing all these tests and the results obtained, it is high time to stop wasting it like this.

I reassembled the machine. I'm now opting to throw it into scrap metal because in its current state, it's worth absolutely nothing.

No final decision yet...

Regarding the FPGA of a Drumulator, I'll stop there too.

I twice managed to integrate the Drumulator's processor core into two different brands of FPGA. I have been trying the same thing on TRION type FPGAs from Efinix for months now without achieving anything usable.

In fact, right now I know the heart is starting well. It shows me the message 'bAd.' at startup, but immediately, by displaying anything.

This is all the more strange as the interrupt system works well since the message is displayed correctly. But afterwards, the processor seems to go 'I don't know where'. And this is not very easy to test with a standard logic analyzer due to the difficulties in triggering signal sampling.

In addition, I must add that the development software is a bit 'boring': not flexible and above all really very slow. This thing is a real pain, even with a powerful PC. So as in addition, the development tool tends to annoy me a little, and the pseudo-integrated simulation system is not helping the matter, and given the time I have already spent trying to integrate the heart of the Drumulator into this FPGA, I will stop.

Also, I don't know the intricacies of the system of this machine. In fact, it is extremely difficult to move forward when something goes wrong. Indeed, there is virtually no way to know for sure where the problem is coming from. After a while, this type of situation is simply no longer bearable.

The idea was to build a hardware environment compatible with the Drumulator in order to be able to run the machine system there. It seemed 'easier' to do. Observations made, I now say to myself that it would undoubtedly be less complicated to develop everything using equipment that is more practical to use.

I've been working a lot lately on small RISC-V microcontrollers. The development software, which was not very practical a few years ago, has been superbly improved in recent months. And above all, working in this way allows you to carry out debugging in real time. And that’s super interesting.

And as these small microcontrollers operate internally at 144MHz, this provides quite acceptable processing power for this type of machine. And after all, I did this to recreate a programmable clock whose behavior is identical to that proposed in the Texas Instruments TMS1122 of the time!

So I'm still a little sorry for this situation because these two projects made me consume a lot of time without achieving any result. Not to mention the psychological aspect of it, because it is not easy to persevere when there is no sign of improvement. It's even more difficult to abandon a whole job to start again with another method.

But hey, to move forward, you still have to make choices, at some point...

The positive point of all this was to realize that I have lost a progression methodology that I had when I was very young. I know the reasons of this degradation...

EMU1 : no real progress lately :-(

 In fact, I still cannot read the contents of the EMU1 boot disk.

On the other hand, I accumulate the validations of parts that have become or verified functional.

Basically, and following major problems of a really diverse and varied nature, I now know that:

• The SIO/2 serial converter is functional.
• The PIO is also functional on its new circuit support.
• the RAM is free of defects because I can check its operation with the small test program I created.

At this point, I don't know if it's the floppy drive that's the problem. So I put an HXC floppy emulator back into service.

And, good and bad news: the floppy disk still does not read, but, and this is the interesting fact, I obtain exactly the same result as with the 'real' floppy disk drive of the machine.

I was also able to find an image of a system disk for EMU1 on the Internet. I was able to check the content of this image to see that it is indeed an EMU1 image.

I can at least conclude with good confidence that the floppy drive part, real or virtual, is not to be blamed.

How to progress now?

By chance, and passing through Paris, I obtained two replacement integrated circuits which are used to extract the clock and data from the signal coming from the floppy disk drive.

I like to go from time to time to one of the last 'old-fashioned' component resale shops in Paris. Okay, it's not RadioShack but it looks like it:

I have already had the opportunity to talk about this store on my blog. Since then, the window has been somewhat redesigned

On the other hand, the interior has not changed and has remained worthy of the early 80s: a real pleasure!

The goal is to change these components:

I had already studied the signals provided by these two components a little and found nothing to complain about. This was confirmed. Their replacement by two new circuits did not change anything!

As a last resort, I removed the time base establishing resistor needed to separate the clock and data, and replaced it with a potentiometer.

This allowed me to check with the logic analyzer that the signals were correctly recreated, as well as to determine the operating terminals. I placed the value of this potentiometer in the middle of this area. So, from that side, everything seems okay too.

And now the question arises of what can prevent the correct reception of data from the floppy drive. I obviously tested all the signals to and from the floppy drive without detecting anything wrong. Although I noticed a small artifact with the HXC emulator, which should not exist, but I will not dwell on this phenomenon since the behavior observed is identical to that with the real floppy drive.

And there, a new question arises: how does the system recover the data from the floppy drive, to process it? Afterwards?

And yes, because in reality, the boot system does not process data on the fly. It collects them, places them in RAM then executes the program which, if I counted correctly, this time is approximately 8Kb and not the 1Kb contained in the boot ROM.

And this operation is not done by polling. I imagine the processor wouldn't quite be fast enough for that. This entire operation is done by DMA. 

So, assuming now that all the 'mechanics' of managing the floppy drive work and that the correct data is indeed recovered by the system, we must now check that the DMA system places it in RAM.

I had already had the opportunity to discuss the Emulator's DMA system. In fact, there are 8 DMA channels that manage the sending of data to the converter boards for sound generation. However there is a particularity, the first DMA channel is 'usurped' on demand by the floppy disk reading system thanks to the SIORDY signal.

I am now 'imagining' that if this system does not work, the data cannot be placed in RAM, and therefore cannot be executed. If the boot system thinks that things are going well and that it checks the validity of the data in RAM, it will inevitably find that things are not working.

This can be verified by the LEDs on the front panel which remain on or which go off depending on the type of error encountered when reading a floppy disk.

In fact, I have some problems there too. I actually find myself between the following two cases:

And yes, I hear the head moving neither twice per second, nor once every two seconds, but about moving less than two seconds but not twice per second.

But, with the SWAP LED off, I would tend to lean towards case B. 

That would suit me well, because a CRC problem is entirely possible in the event of an absence of data. In any case, I'm going to go with this assumption for now.

The next step is therefore to check if the DMA system is working well and that the data is correctly placed in RAM. I don't know yet how I'm going to carry out these tests. The adventure continues...

EMU1 : it's still progressing...

The last time I posted about the EMU1 motherboard refurbishment, I stopped at the detected problem of the system reset. In fact I was able to see that the new SIO/2 put in place of the original SIO/2 did not start and did not allow me to run my monitor program developed to test the onboard RAM.

While the original SIO/2 port #1 works fine, I realized that the 'new' SIO/2s require a bit more initialization time. So, I studied the RESET system of the board and connected the SIO/2 reset pin directly to the main reset system. This did not allow the SIO/2 to work properly. Obviously, if the system developed by EMU did not provide a slight delay at the processor startup, and this is most certainly the case, the new SIO/2 cannot start. And since it is the SIO/2 port #0 that communicates with the floppy drive, obviously, it can't work.

So I opted for a somewhat 'baroque' solution: I took out the reset pin of the processor in order to generate a manual reset whenever I want. This reset does not reset the other circuits on the board. Therefore, I can start the processor once I am sure that the SIO, the CTC and the PIO are correctly initialized.

The reset button is the left switch. I also added another switch to simulate the 'UPPER' loading switch on the EMU 1 control panel.

And of course, this time I got my monitor program to start correctly. The SIO/2 is therefore correctly initialized and configured. So I will have to study a global reset system a little more sophisticated than the original one implemented by EMU.

Finally, when I say that my monitor can now boot properly on the new SIO/2, it does not mean that the monitor works properly. And yes, since absolutely nothing will be spared on this board, now I sometimes get strange characters on my serial terminal emulator.

Of course, I first suspected a RAM problem. When I launched the DRAM circuit test, I got random errors. I then told myself that this was not credible. I went to look at the PIO. Because this is the circuit that is responsible for bank switching. So obviously if there is a problem on this side, it will inevitably generate problems. I was still a little skeptical because I had to change this circuit once to test another one, nothing more. And until now, I have not had any problems with my monitor. The problems appeared when I modified the processor reset. Another 'bad' lead not to follow?

And indeed, after some tests, I realized that the PIO was simply not powered. A contact problem on the power pin with the effect that the component outputs were navigating in the middle of 'nowhere', generating a totally random RAM bank switch. Well, I changed the circuit support.

Once this socket change was done, my monitor worked properly again. Fortunately I didn't have this problem during my phase of writing the monitor code. With the 'shitty' addressing of the ROM and this bank switch problem in addition, I might not have been able to validate my monitor and, in a fit of extreme anger, I could have thrown this board out the window. It happens!

To recap, the biggest problem with this board initially seemed to be the SIO/2 port #0, which handled communication with the floppy drive, which was no longer working. All my work and all my struggles were 'just' aimed at getting a working port #0 back. What a struggle to get to this point.

It was finally time to test the original code of this board. So I did, and... absolutely nothing happened!
No more unexpected start-ups of the floppy drive motor. Nothing at all happens!

Damn!!! Is this bad news? Well no: 'saved' (for this time) ;-)

I then looked at the machine's user documentation, just to confirm what I had already seen, namely that in fact the machine does nothing at startup, except light up a few LEDs, and waits for a press on either UPPER or LOWER, to start loading the data onto the diskette.

So I followed the EMU 1 schematic and ended up finding (and I guess what I determined is correct) the connections to make on the motherboard of the machine to simulate at least the UPPER switch. The references of the connectors on the front of the machine and the motherboard are different. So, deduction work is required.

So I wired a second switch to the small piece of study PCB, and rebooted the system.

Obviously, it would have been too easy for it to work. Once again, absolutely nothing happens. As I am starting to get used to it now with this machine, I started to check if the system was operational. Using the oscilloscope, I was able to see that the two integrated circuits that manage the multiplexing of the keyboards were correctly addressed. So, a priori, everything is fine on that side.

So I simply continued testing the signal values ​​on the input and output side of the keyboards. And I found something interesting. While the Y9 output of the IC125 circuit is high, 3 inputs on IC121 and IC122 are low. Logically, all the inputs of these two circuits should be high.

I tested all the diodes and found 3 simply cut and a fourth shorted. The result of all this is that overall the system sees a certain number of switches activated. So, I already don't know how the small boot system can react with this type of malfunction.

Well, all I have to do now is change all these diodes and see what happens. But, for once, I feel like I'm moving in the right direction...