In development : the Drumulator in a FPGA

As the writing of the Drumulator VHDL code continues, I encountered an issue that kept me busy for a few days. Impossible to send the correct information to the sound sequencer!

The symptom was as follows. A series of bytes must be sent to the sequencer. On the series, only the first byte is correct. The following are a copy of the first.

This results in this type of chronogram:

As you can see, I get the same code four times. In this case, I should get 0x8D then 0xD7 then 0xF8 and finally 0xF9.

After spending many hours trying to figure out what was going on, I still checked the operation on my Drumulator.

In this case, I get 0x8D and 0xD7 for half of the signals captured. On the other half (not displayed here), I get the 0xF8 then the 0xF9. So it works as expected on the 'real' Drumulator. What????

Being virtually certain that it was not the decoding logic I implemented in the FPGA that was causing the problem, I attempted to look directly at the system version 3.0 code to determine what might be causing this error.

To do so, I installed a disassembler then I examined the generated listing:

In this listing, I found a series of OUTI instructions allowing the output of a series of bytes on an output port, with auto-increment. After studying the supposed operation of this instruction, it became fairly obvious that if I got all the same byte, there was a chance that an increment would not work.

So I went back to the git of the processor core repository and here is what I discovered:

This is how I discovered that this file had undergone a modification concerning the treatment of the OUTI op-codes (among others). 

Indeed, by comparing the parts of code which deal with the problem, we see that there has been a modification with the addition of IncDec_16 (3) <= IR (3); Plus a few other minor changes:

The code on the right is the most recent code.

It's a fact, the Z80 VHDL code I am using is a bit old. But a few days ago, I had checked that I hadn't 'missed' anything important. Yes, but....

The version I use is the 0242 and there is no mention on the intermediate version 0240mj1 :

There was therefore insertion of an intermediate version n° 0240 after the publication of version n° 0242 : big mistake!!!

And since a few days ago, I had not yet understood the possible problem of the OUTI instruction, I did not pay attention to this new version.

" Okay, Houston, we've had a problem here"

It's time to test the latest version of this T80 instruction decoder!

And the winner is :

With this version of the Z80 processor including the corrected OUTI instruction, I get the correct timing diagrams. This time the sequence 0x8D, 0xD7, 0xF8, 0xF9 is good : yessssss