Drumulator and Efinix FPGA.

A month after my last publication on the subject, a little progress...

And yes, I spent a lot of time on the EMU1 motherboard which, if it still doesn't work, gave me a lot of its secrets which will hopefully allow me to make it work again!

I am therefore resuming the implementation of the Drumulator in an FPGA. This time I test the small simulation board of the machine control panel.

In fact, I have a few issues that I didn't expect with this FPGA. Certainly, its cost is affordable compared to other offers on the market. But I discovered a pretty significant limitation of the implementation of these Efinix FPGAs.

In principle, it is of course possible to do the same thing as any other FPGA with the Efinix Trion range, except that...

It's not that simple. The internal resources are not as flexible as what you can find on other components, which means you have to rethink your way of doing things somewhat..

Basically, asynchronism is not the strong point of these circuits. Well, you will tell me that when we do FPGA, it is not to do asynchronous. Yes... or no. Actually it depends...

Well with the Trion range, the question does not arise : it's 'nyet, tovarishch' !

Once it is well integrated, you just have to review the design. And to validate my 'new' approach, I simply coded a basic Z80 system, accompanied by a very small program allowing me to test the display of the front panel of the Drumulator :

Which allows me to validate not only my way of doing things synchronously now, but also the functioning of the display system.

I can now get back to studying the CTC equipping the Drumulator and conductor of the entire machine.

The next goal is to obtain the same display directly from the Drumulator environment, that is to say with not only the CTC programmed in VHDL, but also the entire generation and reading of the interrupt vector, as well as than his acquittal. I admit that this whole vectorized IRQ system of the Z80 is still a 'happy mess' ;-)

I have (unfortunately) been working again for a few months in national education. Which leaves me less time to do electronics. I still hope to be able to make significant progress on the subject in the coming weeks...

EMU 1 : Finally a first hope?

Same title as the previous post? Indeed, the chain of discoveries continues...

In fact, after discovering a faulty memory component and replacing it, I found that the EMU1 boot process still would not initialize.

What to do then? To get to this point, I set up a serial communication with a PC using port B of the SIO component. It is port A of this component that manages access to the floppy drive. So I considered that this SIO was fully functional since I had no problems with this serial connection.

Not really knowing what to do anymore, I then decided to test port A of this SIO by programming it exactly the same way as port B. The Emu1 schematic means that in fact, it is the same clock speed that drives the writing to the floppy drive. Happy coincidence. So, I have absolutely nothing to change in my code, except just the access addresses to port A.

And then there: surprise!

I had a lot of trouble getting characters to display on the screen. As for getting strings to display: impossible. So I ran a whole series of tests to try to figure out what might be going on.

The conclusions are as follows: When powering up, more than 90% of the time I do not have the characters displayed. And above all, reading the status register seems to pose real problems.

Even though the character was emitted, the empty transmit register bit is never set. So my test program crashes on this, and I can't emit a complete character string.

So: I think the original SIO on the EMU1 board has a malfunctioning port A. Which fits perfectly with the current state of the board that won't boot at all. I have another SIO that I've never gotten anything to output. I assumed it was fine. I've done a lot of testing with it, which has led me to a bunch of wrong assumptions.

What now? I can't really move forward on this. I absolutely need to find some working 8442 type SIO circuits to check if the current state of my assumptions is correct or not!

The hunt for 8442 is on...

Come on, I ordered 5 SIO2 8442 circuits. I just have to wait for them to resume testing...

EMU 1 : Finally a first hope?

Since my last post, I have finalized the EMU1 motherboard DRAM test program.

The problem that arose when testing a 64KB bank and then the other 64KB bank was the management of the variables of my small application. Indeed, by switching banks, we completely lose the contents of variables, which can only crash the program.

How to do it then? One possible answer might be: no global variables to avoid fixed references, use the stack, and switch banks only from the main loop, never in a subroutine.

This way, you can use as many variables as you want, and the stack pointer is necessarily at its origin when you are at the highest point in the program: easy!

And that's how I was able to complete my program, and then test it with two DRAM circuits removed from the board.

I set up a small menu to launch the test, then to choose which bank to test. And on the terminal output, we can clearly see the two missing circuits, which therefore generate two errors.

If we look at how the memory circuits are placed on the motherboard, we have this:

Which corresponds to the following logical organization:

I could have clearly indicated the address where the errors are found but converting from numbers to hex strings takes a lot of resources, in the little program space available, less than 1KB, it is impossible to implement. So, I simply indicate in which 16K segment the defective memory component is located.

If I take the example above, where the indication was RAS2/RAS6, knowing that I had previously selected bank no. 1, I know exactly where the faulty circuit is located.

And that in addition the crash occurs with the processing of 0xAA, I only have to target the four circuits corresponding to the '1' of 0xAA, that is: 0b10101010, or bits 1, 3, 5, 7.

Obviously, if there are more bits in error, this will involve testing all 8 circuits that make up the 16KB segment. But hey, it's already much more practical than just knowing that there is a problem on one of the banks...

So what, you ask? Apparently, I am now able to determine that there is no RAM problem, in fact. Because when I put the two circuits back in place, obviously, I no longer had any errors. Yes, except that...

That's when I decided to configure my program to test absolutely all memory addresses. To do this, I placed the memory stack at the minimum possible RAM space according to the number of bytes needed for my program. In fact, by successive tests, I placed the stack one byte above the value where the program crashes, at 0x040C. As a reminder, the first 0x0400 addresses are those of the ROM. The RAM therefore starts at 0x0400, and I placed the stack 12 bytes higher. Then, I configured the RAM scan to start just above the stack, at 0x040D.

And what do you think happened?

I have several bits in error on the RAS4 segment, since if you run the entire test, you see that I had first performed the test on bank 0 which had not generated any errors, then I selected bank n°1 to relaunch the test which generated these errors.

In fact, and as I was in the process of writing my program, I was able to test the RAM by starting the scan at different addresses. What I determined is that at 0x040E, I have the problem with 0x55 and that at 0x040F I have the problem with 0xAA. I am not able to know if it is the same component that is causing the problem. I am obliged to test the 8 circuits.

On the other hand, I don't know where the EMU program is stored, in bank 0 or 1. I also don't know how the two banks are used by EMU. At 27KHz, and given for 2 seconds of sampling, it seems obvious that only 64Ko are used for sound reproduction, and not 128K. In any case, if the EMU1 program is stored from the base of RAM in bank 1, then there is a guaranteed crash.

At least for the first time, I have a small lead to follow for the resolution of the machine startup problem. In addition, I am pretty sure that the CTC, the SIO and the PIO fulfill their function since to be able to communicate by serial link, I was forced to program these three circuits. And their operation corresponds to what was expected. I should also add that I also tested all the RAM circuits using a small DRAM tester of this type :

As for the EPROM programmer used in component test mode that did not detect a faulty 74ls00, would I be a victim of the same tool reliability problem? Hmm...

So....

EMU 1 : Finally a 'real' first program!

Of course, this may raise a smile, but it wasn't easy to get there!

This allowed me to verify that the serial interface was working in both directions, as well as that there were no errors on the first 64KB bank of RAM.

I still have to check the second bank. I don't know how to do it at the moment, since it will be necessary to do bank switching, otherwise my program will crash miserably.

EMU 1 : Second attempt to write a program for the EMU1 motherboard

I think I finally found the problem of adapting the EPROM emulator. It must be said that it is not particularly easy to adapt an emulator that can only emulate at least a 2764 EPROM on a system designed for a 2708 EPROM!

This is not a problem with my EPROM adapter addressing, but with how the EPROM emulator works internally. For a 2764, it is absolutely necessary to send it 8KB of data otherwise, part of the code is simply not available at the output of the EPROM Emulator.

The usual little loop of sending strings through the serial port. This time the message is big enough to crash the system, but it seems to work.

It took several steps to be able to start working correctly with this EMU1 motherboard!

Well, tomorrow I'm programming the character reception in order to try to lay the foundations of a micro debugging system. I hope that what I've modified about the EPROM emulator will confirm the validity of my approach of today...

Manfred Veber, the guy who...

Have you seen the announcement on Facebook recently about the recreation of the specific buttons for drum machine like Drumulator, SP12, DMX, LinnDrum and others?

Hmm, and the one who did this is not unknown to me: Manfred Veber.

In fact I already had a contact with Manfred a few years ago by providing him with two copies of ELD5530, the replacement circuits I had created to replace the original CEM5530. Since then he opened his repair shop in Paris.

While passing through the capital of the kingdom of france, I took the opportunity to go and see him, in order to buy a few copies of these famous switches.

"I love smelling napalm in the morning." as he said. 

How to explain this? This smell of old electronics, very warm, which recalls the wonderful moments of my discovery of electronics at the end of the 70s, beginning of the 80s. Ah, what happiness : To each his own!

What beautiful machines!

My first real encounter with a DX1 or a Prophet 5. And there, there were some beautiful specimens of Prophet 5. A magnificent T8, Oberheims, Moogs and other beauties!

And meet her, also for real, with a passionate guy. An interview that was supposed to last an hour, like, finally lasted more than two and a half hours. We discussed technology, repairs and strange objects.

Have you ever seen these CEM5512 ?

Thanks to Manfred for this moment of sharing around these superb machines. And thanks for the twenty or so switches that I was able to buy.

The EMU 1 is taking up a lot of my time. It's bothering me a bit because I have the Drumulator subject to move forward: complicated :-(

EMU 1 : Second attempt to write a program for the EMU1 motherboard

After successfully getting the famous 'Hello World' of embedded computing to work, namely making an LED flash, I decided to tackle something bigger. 

The goal is to create a diagnostic program that can test the system operation. I don't really know how I'm going to do this yet because the EMU1's ROM space is only 1 KB.

But, what I know is that I want to use a method of communication with the diagnostic system, other than displaying error codes on the LEDs of the control panel. So the idea is to use the serial port of the machine to communicate with a computer, PC or MAC or Linux, through a terminal emulator.

And for the occasion, I decided to implement the use of the memory stack, thus allowing me to create functions with input parameters, even if sometimes the compiler used, SDCC, directly transmits the parameter via the processor registers.

The previous program to flash a LED was so simple that I directly programmed a 2732. But now, as I want to develop a much more complex application, I decided to use an EPROM emulator.

I have been using this emulator and it works very well for years. In order to be able to use it on the original 2708 socket of the EMU 1 motherboard, I had to mount a small adapter, since the emulator is only able to emulate EPROM components from the 2764.

In order to check the possibility of such operation, I loaded this EPROM emulator with the binary of the LED blinking.

This worked without any problems, ensuring that my binary file converter, as well as the operation of the board with the EPROM emulator, was validated.

Yes... but no, actually. It took me a while to get all the circuits programmed correctly to be able to send my first characters through the serial port.

At first I was using a RS232/USB serial adapter. Nothing happened. By doing some tests on the output buffer, I realized that the output was not following the input. Another malfunctioning circuit: a MC1488.

Later, I had quite a few difficulties to output characters through the SIO port B. The operation of the SIO requires, not only to configure it and also to configure the CTC, but also to configure the PIO. Always this usurpation of the DMA1 for the management of the floppy drive. If the PIO port B is not correctly programmed, the SIO will not output any characters.

I did of course eventually get there. So I have 9600 baud character transmission from the EMU 1 motherboard to my PC.

Yes... but not so well, actually. Because something strange is happening. My test program, which simply consists of emitting a string in a loop, crashes under certain conditions. What conditions?

And this is where it gets hellish, because nothing makes sense. Basically, I obviously suspected that my conversion routine had a coding problem, I suspected that there was a RAM memory problem that was causing problems where I had initialized the processor stack pointer etc etc... I couldn't get any conclusive results.

And then, at one point, I realized that the problem disappeared when I decreased the size of the string. This string is placed just after the main() routine and just before the functions by the SDCC compiler. The emission of a string is done using a function placed at the end of the program. The result is that when I decrease the size of the string, the overall size of the program decreases and the last instruction of the send function appears to fall back into what I assume is the safe domain of ROM memory space.

After some unsuccessful tests, I concluded something 'crazy': that the emulator must have a problem and, for a reason that I don't understand, not provide the right codes on a part of the ROM space.

I have two Momik emulators. I tried the second one, with the same result. Which made my perplexity even worse. The doubt becoming unbearable, I plugged the EPROM emulator into the EPROM programmer, in order to read its content. And there, the jackpot, a whole part of the code does not correspond to what I send to the EPROM Emulator.

Until now, I was doing my tests with the EPROM emulator connected to the memory adapter that I made. In order to be sure, I remove it from the emulator that I program this time to behave like a 27010 in order to position all the pins at a determined level, and I read this time the emulator by specifying to the EPROM programmer to also read a 27010. And there you have it: the reading is correct.

To confirm my result, I put the EPROM adapter back on the emulator and reread it. As expected, part of the code read is 'rotten'. So be it! I checked the modification I made on the EPROM adapter, everything seems correct to me, except that to go from a 2708 to a 2764, the minimum component that the EPROM emulator is capable of emulating, I have to use the /OE signal instead of the /CS signal, the /CS signal being directly connected to ground.

In fact, /CE, A10, A11 and A12 of the 2764 are connected to GND. /PGM, +12 and -5V having been directly connected on the motherboard when moving from the 2705 to the 2716.

With the adapter corresponding to these changes, the data is placed in the right place, but it no longer corresponds to anything from the second data block. This is not an addressing problem, otherwise the data blocks would not be placed in the right places.

So, after a long time of research, I finally understood that my program problem most likely comes from the EPROM adapter that I mounted. However, I do not understand the phenomenon at all. I still have some research to do at this level if I want to be able to fully use the EPROM emulator to develop my diagnostic program.

It's really not easy to 'play' with EMU's productions. These guys were really 'crazy' in electronics ;-)

Drumulator and Efinix FPGA.

I'm busy trying to get the EMU1 working again, but I finally received the test control panel. I will finally be able to start testing the implementation of the CTC component inside the FPGA :

Obviously, the final panel won't look quite like this. It will also depend on the type of switchs that I can find for triggering the sounds.

Maybe a newly recreated switchs like these :

EMU 1 : First attempt to write a program for the EMU1 motherboard

As I indicated in my previous post, I now need to know if the DRAM on the EMU1 motherboard is fully functional or not.

As a reminder, when I had this EMU1, a few years ago, I was able to load a sound disk without the slightest problem. Then the machine smoked. Nothing serious, a few tantalum capacitors shorted. I replaced these capacitors and reassembled the machine without ever being able to restart it. Since then, it has never managed to read a diskette. So I had tested all the DRAM components with a small tester which had not indicated any faulty components.

Due to the multiplexing mechanism of the DRAM address bus, using 'criminal' timings performed with resistors/capacitors, I am therefore trying to get an idea of how this system currently works.

To do this, I will write a very simple program whose goal will be to represent on a series of LEDs connected to an output port of the EMU1 motherboard, the evolution of a simple 8-bit counter.

This program, of rare complexity, simply increments an Index whose value will be sent to the IO address space 0xC0 (__sfr __at 0xC0), in a loop slowed down by a timer consisting of two nested empty loops. There is no prior initialization of the Z80 registers. I do not use IRQs or the memory stack.

This simple program requires 5 bytes of RAM memory. If it works, it will already indicate that the DRAM components are being accessed 'relatively' correctly. If this program works, I will modify it to test the entire 128KB of RAM.

I compile this program using SDCC and the command:

sdcc -mz80 --no-std-crt0 --vc --code-loc 0x0000 --data-loc 0x400 TestRam.c

No special comments. The code starts at address 0x0000 and continues and uses only a few bytes of program area. The data in RAM will be positioned from address 0x0400, just at the beginning of the RAM space, just behind the first KB of code.

And now??? Well, we need to encode the content of the ROM code obtained after compilation and conversion into a binary file to make it compatible with the wiring system made by EMU (thanks EMU)!

Even for a few bytes of ROM, I preferred to write a small program under Windows to automate the task. Because it is necessary to encode not only the data but also the addresses. So as I plan to expand this small test program, I might as well make this encoding process as automatic as possible, even if it means 'taking' a little time to write the Windows application.

I hate using Microsoft's Visual C++. A gas factory, a big piece of crap (for me, because there are thousands of programmers who love Visual C++), GB of data to load and never knowing where we're going! So I tried it with QT. Its mode of operation is much more logical/simpler/efficient for me. Starting with no knowledge of QT, I 'only' needed a short day (I program embedded and am very bad with OS applications) of discovery to be able to write a minimal application that suits me.

So I know that the original EMU executable is 60 bytes. It's 'big' for such a small program, but I coded it in 'C' and not directly in assembler.

And for comparison, here is what the contents of the original binary file look like :

And now the binary encoded in the EMU 'way':

Well, if I understood correctly how the EMU1 motherboard works, if I also understood correctly the ROM coding system and if the DRAM multiplexing system is correct, it is not impossible that I can see something on the LED connector. Maybe not the progress of the counter if my temporisation is not sufficient, but still something...

Now I just have to program a 2732, put it on the motherboard, connect an LED and see if anything happens.

The result of my investigations in a future post...

EMU 1 : blocked for now

In my previous post, I stuck to the fact that the EMU1 motherboard was now able to start the floppy drive as well as return the read head to track zero. However, I still had no real boot from the motherboard.

From what I was able to read from the EMU doc, in principle the bios reads the first track, which obviously contains a more sophisticated bootloader than the one contained in the EPROM, therefore records this first track somewhere in RAM, then executes this piece of code whose objective is to read the entire contents of the floppy disk.

However, even with a floppy disk supposed to contain the necessary files, the contents are not read. Which therefore indicates that the first track is not read correctly, or that its loading and execution from RAM is not going well.

Since I think the SIO and PIO system now works for floppy disk drive and reading, I decided to take a closer look at the signals from the dynamic RAM. And as a result, I was able to see that the pin 3 of the RAMs had a level that never varied.

All these signals are driven by the signal noted MMWR. This signal comes from the logic for managing the types of memories accessed.

And indeed whatever the levels present on inputs 4 & 5 of the NAND gate, output 6 does not move. So I removed this IC145 circuit from the EMU board and positioned it on the EPROM programmer, which also acts as a logic integrated circuit tester, and the test result is that everything is good.

Hmm, skeptical! I therefore replaced this circuit with a new 74HCT00 that I own and as was predictable, I found activity on pin 6. The MMWR signal therefore became valid again.

From my first tests years ago on this motherboard, I started by testing as many integrated circuits as possible this way, so I put this 74LS00 back in place since it was supposed to be in good condition. As a result, now, I no longer have any certainty about the other components tested in this way, which still represents almost 90% of the components.

And now? Well, I'm supposed to have a motherboard with a working floppy drive system, as well as a working DRAM. And yet, the OS still does not load from the floppy disk, knowing that I respected the minimum configurations of the mother board for it to work.

However, this EMU motherboard contains an absolutely horrible and totally prohibited solution when it comes to logic circuits: the creation of delays using resistors and capacitors. Here is the 'crime' scene:

The principle is easily understood. First, part of the address bits are sent to the RAx pins of the DRAMs. Then, some time later, the other address bits are presented to the RAx pins of the DRAMs. Then, some time later, again, the validation of this second part of the address is validated by the CAS signal. The selection of the address bits is done with the 100Ohm resistor and the 220pF capacitor, the activation of the CAS signal is done with the 200Ohm resistor and the 680pF capacitor.

I was actually able to check with the oscilloscope that the timing was respected. But, due to the uncertainty of the real level of taking into account the levels by the different circuits, and especially the possible drift in capacitor capacity over time, I am, in the current state of things, totally incapable of tell if the current timing of the signals fits within the specifications of the DRAM packages. If this is not the case, obviously the bytes read from the floppy disk cannot be stored/read correctly in memory.

And so here I am again blocked by too many uncertainties. Obviously, if I had been able to get my hands on the dynamic memory test EPROM, it would have allowed me to quickly get an idea. On the contrary, if I want to move forward efficiently, I need to create a small program whose purpose will be to write a byte to the extent of the memory, and to check its presence when reading. This should allow me to first check if anything is wrong.

And to do it well, I would even have to configure the serial interface of the SIO dedicated to the connection with a computer to allow the display of a few messages including, if possible, the location of the DRAM circuit affected by a writing/reading problem. Creating this type of program does not pose any difficulty, however, it is still necessary to code the generated binary in both bit order and address order, to match the 'esoteric' wiring of the EPROM on the processor.

At the same time, this type of exercise could allow me to also program some operating tests for the PIO, the SIO, the CTC and possibly the DMA controllers...

EMU1 : some progress...

In the previous post on this subject, I had stopped at the fact that I had discovered that the wiring of the EPROM to the processor did not respect the conventions. I therefore confirm this fact, and am even able to say that all EMU1 motherboards have this characteristic which can be defined as a relatively simple coding of the EPROM whose purpose is, I think, to make the disassembly of the program difficult.

To come to this conclusion, I read the original EPROM from my EMU1 motherboard. To do this, I placed the EPROM on a circuit socket from which I cut off the +12V and -5V power supply pins. Because the MiniPro is not able to provide these power supplies on these pins. So I was able to connect these two EPROM pins directly to an external laboratory power supply.

MiniPro

Socket adaptor

In fact, in order to be able to test the operation of this motherboard, I had originally removed the +12V and -5V power supply from this EPROM. The goal was to be able to eventually test the operation of the board with another version of the boot program. This also allowed me to check the behavior with the logic analyzer and draw my conclusions as to how this EPROM is connected to the processor.

Note that to read the EPROM on the MiniPro, I selected a 2716 type EPROM, the smallest available on the software, knowing that I would therefore have twice the same KB read since the original EPROM is a 2708 and the additional address bit of a 2716 is not connected to the 2708.

So, now that I am sure that the motherboard of this EMU1 works, since it is able to execute my 'NOP' loop, I need to continue on the right basis, that is to say, program a 2732 that I have with the original EPROM program and insert this 2732 in place of the original 2708.

On the other hand, EMU strongly advises to always use the original EPROM to perform tests. So...

I don't know why this exists, but I strongly suspect it has to do with some hardware feature. Since the boot program just reads the first track of the floppy anyway and then runs this firmware to load the entire floppy, I suspect it has to do with just some basic motherboard functions. I don't know more than that at this point. Potentially setting a timer?

In fact, I compared the contents of the EPROM of my EMU1 board with other contents of different versions found on the Internet, I noted different codes at the addresses:

0x208

0x228

0x237

At least, the code in 0x237 is different on all the contents. The 4-voices version also has a difference in 0x208, and the Wildcard version, has the 3 differences.

Be careful, these codes at these addresses do not mean anything. They correspond to a specific code at a specific location, but after reorganization of the code according to the wiring of the EPROM to the processor.

The versions tested were the following:

600X.PROM(c)82_820816_#008D.BIN (The one on my board)

820816-00B8.bin

820816-0081.bin

820816-0165.bin

820816-0181.bin

E14Voice2708.BIN

Emu_wildcard.bin

At this point, and after inserting an EPROM containing the original boot program of my EMU board, nothing happens at the floppy drive. On the EMU1 board, the voice DMA controllers are not inserted. Only the principal DMA controller is inserted on its socket. In this configuration, I know that the boot program starts and runs. Despite the fact that this situation is not optimal for the minimal operation of the motherboard, something should still happen at the floppy drive, namely at least the rotation of the disk. However, nothing happens.

And this is when I change the first component that I think is defective on my board, namely the SIO. In fact, it is this SIO that generates the floppy drive selection signal, which has the effect of starting the floppy disk rotation motor. 

After this intervention, indeed, the rotation motor starts correctly. This is a good start, but nothing else happens. However, before anything else, in any procedure for reading a floppy disk, the controller must ensure that the reading head has returned to its initial position. Three signals are then important, the movement direction signal, the control signal for the stepper motor for positioning the reading head, and the track 0 position return signal. And these signals are managed not by the board's SIO, but by the PIO.

So I also replace this PIO.

After replacing these two components, indeed, by powering the motherboard back on, randomly, the floppy drive not only starts, but its head moves slightly to test the positioning of track 0. So I am also on the right track!

Of course, at this point I can't avoid to ask myself a few questions. How come the two interface components with the floppy drive are defective? On my workbench, the system is in the same configuration as in the EMU1 box. Is there a power supply problem in the EMU1? Because on my workbench, everything is powered by a laboratory power supply. Before reassembling this EMU1, I had obviously checked the proper functioning of the power supply that I had recapped. Strange all that!!!

Well, now I have a system that seems to boot properly from time to time. That is, it boots the floppy drive and sets the read head to track 0. But nothing more. The randomness doesn't surprise me either. The current configuration of the DMA components is not good at all. Besides, I'm now dealing with these DMAs.

It may not be very obvious at first glance, but the DMA system takes care of all data transfers with the floppy disk drive, in addition to managing the sound by sending the samples to the digital/analog conversion boards.

And, a quick reading of the schematic indicates that it is the first channel of the first DMA controller for reading samples that is used. Quite simply by assigning its signals, not to the conversion board, but to the floppy drive when accessing this drive. In order to make the board undisturbed by the absence of the conversion boards, I therefore position certain signals to ground, as indicated on the schematic provided by EMU. In fact, I only keep the first DMA controller and I remove any random character of a DMA trigger by the conversion boards.

In fact, I only leave the DMA controller #1 (I'm not talking about the head one which must be in place anyway). This is materialized by grounding some signals on the EMU1 motherboard.

Well, it's not meant to stay like this in the long term ;-)

And now I can power up this great EMU1 board again. Good 'surprise', the boot sequence now runs correctly and in the same way after each RESET of the board. The disk rotation motor starts, the reading head is positioned at track zero, even when I previously moved it by hand.

But for now, the situation seems frozen in this state. According to the EMU documentation, track 0 should be read then saved in RAM then executed to completely load the floppy disk. I performed my tests with a floppy disk containing the system but nothing works. I now need to check with the oscilloscope that the data from the floppy disk arrives correctly at the SIO of the EMU1 motherboard.

So I also have to deal with the interrupt management chain because it may 'block' at that level. I imagine that the SIO generates some of them, in any case it is wired for that and even has the maximum priority. A priori the interrupt chain stops at the PIO, the DMA controllers do not manage interrupts in this system.

This is the next step. It's laborious, but it's progressing!

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