EMU, oh no!!! Why???

After investigations of all kinds, still impossible to find an entry point on the non-functioning of this EMU 1, but...

Until now, I have taken the subject in a 'scientific' way. That is to say, by systematically controlling the operation of the processor. Despite the number of hours which is now starting to rise, not only do I not understand what is happening, but the result of what I observed really perplexes me!

Alas, must I say that I have now to move on to another study methodology: place to the artistic side of my brain! 

And, as a result, I am forced to let my mind wander at its own pace, without really commanding it. I have no idea of ​​the direction my ellucubrations will take. On the other hand, I think it will take some time...

So, and I can't really explain the entire thought pattern that I followed to arrive at the current result, but the fact remains that I finally arrived at the first result.

What is it about? I can get 'nothing' to run on the Z80 processor. Isn't it beautiful?

After many negative results, I tried to execute a NOP (No OPeration) loop on the entire ROM area of ​​the system, with looping at address 0x0000.

Well this simple 'trick' didn't work. On the other hand, I was able to note with the logic analyzer the repetition of a value at regular intervals. Not the right value, and not the right tempo!!!

SO? Well I carried out some connection tests on the processor board, and I noticed that it does not correspond at all to the diagram that I was able to obtain for this board. So obviously, I'm not sure that the schematic I have corresponds to version 4 of my motherboard. But, even so, some connections are, how can I put it, baroque!

And at this stage, to ask the developers of this EMU 1 (if any is still alive): but why? To avoid copying the machine too simply? But no... It's of no use, except to stall 'some' time for anyone trying to troubleshoot an EMU 1 :-(

So, perhaps, in the context of the times (1982), it was probably not easy to find a personal computer capable of assembling Z80 code, encoding the result so that it could be properly executed by the Z80. But hey, that’s debatable. On the other hand, this makes it completely impossible to disassemble the PROM. But on the one hand, this doesn't fool anyone with Z80 experience, and then you 'just' have to find an EMU 1 and study the motherboard to find the 'trick'. That's what I did. And frankly, finding only one OUT statement in all the code is just not credible, and that set me off ;-)

In short, once I understood the 'false' problem, I coded the PROM correctly and inserted it into its socket on the EMU 1 processor board. And you know what? With the logic analyzer, I found the code 0xC3 (JUMP) at the regular interval of 1024 bytes. Which proves to me that, for the first time, this board is able to execute an empty loop correctly.

No but, frankly, EMU! :-(

Now I can turn to the four DMA circuits that equip this motherboard. In fact there are five, but only the four 'slaves' cause problems on the data bus when they are on their socket. I will focus on their operation because that is what my brain is now telling me to go and check. So....

During this time...

I'm currently waiting for some printed circuit boards, and since I'm on the Drumulator topic, I decided to try to troubleshoot another machine from EMU: the Emulator 1.

This machine was offered to me by someone who wanted to part with it. It had obviously suffered some damage to the frame, following a fall I imagine, because it is really very heavy.

I turned it on once. It started, it smoked, then nothing since then. In fact it was tantalum capacitors that smoked. Nothing serious a priori.

In the past, I took it all apart and changed the front panel capacitors. I also redid the power supply. Then, I put everything back together, scrupulously, and then nothing. This EMU never wanted to restart. The keyboard has been sitting in a corner of my workshop for years. So, having studied the Z80 processor quite a bit during my work on FPGA, I thought it might be interesting to start troubleshooting it. After all, I have managed to troubleshoot several Drumulatore and SP12!

The interior of this EMU1 is in very good condition. Given the 'historical' nature of this machine, I find it increasingly difficult to look at it half dying in its corner!

So I removed the motherboard from the machine once again.

Will I finally be able to boot this motherboard from its floppy drive? The question remains!

It starts badly, the disk rotation motor gives a very slight knock and then stops. I have already spent some time checking the functioning of the motherboard by testing the behavior of the components. And, while I have already done this work years ago, I can't find anything dysfunctional. I don't have a diagnostic ROM for this machine, so for now, it's just a matter of testing the components. I haven't noticed anything glaring. Now I have to try to discover a functional malfunction. This is not going to be easy and may take a lot of time. But hey, I figure that by working on the subject a little regularly, I should get there! This machine only has standard components so....

MIDI SWITCH.

I have been thinking about developing 'simple' hardware for MIDI network management for years. In fact, I have been thinking about this for decades now!

I remember starting to develop a prototype based on a 68000 processor and two large communication circuits equipped with four serial ports each. That was in 1994, exactly thirty years ago!

I never got anywhere because, I don't know, subconsciously I found that there was something wrong.

In fact, I always started from the same paradigm, namely, a centralized element for the management of all MIDI communications.

And precisely, in the last few days, while I am currently rethinking all the wiring of my hardware in MIDI, a kind of evidence presented itself to me. Not an evidence on what to do, but only an evidence on what not to do. Exactly what I have always done, always starting from the same concept.

As you can imagine, the result I arrived at does not correspond at all to what I was doing until now.

So I present to you just a small piece of the printed circuit of what will be my MIDI network flexibility device :

Simple, right?

Of course, the hardware aspect is not everything. It will also be necessary to develop the right software, because the information management will be a little more complicated than with the standard MIDI network. But nothing too esoteric nevertheless.

I am hopeful that with this solution, I will finally be able to use all my MIDI machines without having to rack my brains every time I want to do something, nor having to unplug and replug inaccessible cables, equipped with this 'crappy' DIN plug!

Drumulator and Efinix FPGA.

The fact is that I have made good progress on the transcription of the Drumulator into an FPGA.

But what craftsmanship job is the management of vectorized interruptions on the Z80! It 'smells' like the thing put in place last, with the resources still available for the circuit, and added on top of the logic of the processor itself! 

Well, that's the effect it has on me. So, it's a bit complicated to create a circuit that responds to this mechanism, especially the CTC circuit, very important in the Drumulator. I still got there.

But another problem arises. I wanted to recover the values ​​of the display digits in registers in order to be able to exploit them as I wanted, but using the small resources of the FPGA development board, I absolutely cannot get an idea of ​​how the multiplexing of the display is set up.

Obviously, everyone knows the principle of multiplexing, and basically, it works in the standard way on the Drumulator, but I retrieve multiple information in the registers. So, and as I have already set up the display of the Dumulator on an FPGA board equipped with 7-segment displays, I decided to create a small display/keyboard card functioning in the same way as the hardware implemented on the Drumulator. And in any case this card will allow me to work more easily with the Efinix FPGA board because it only has 8 user LEDs in total: it's really too few and it's a real criticism that the 'we can do with this board.

Here is what I sent to be done:

Although the Drumulator display only has 4 digits, I implemented 8, which will allow me to also display other debugging information if necessary.

So I'm putting this topic in standby until I receive the printed circuit  board and can mount and test this display/keyboard card.