EMU 1 : a big small step confirmed!

Following on from my last post on the EMULATOR 1, I spent some time trying to get communication on port #1 of one of the new SIOs I recently purchased. As a reminder, I created a small monitor to test at least the RAM on the EMU motherboard. This monitor works very well on port #1 of the original SIO/2, knowing that this original SIO/2 has a port #0 that no longer works, which I was able to verify by installing this SIO/2 on a small Easy z80 processor board using a SIO/2 to SIO/1 adapter of my own design.

The object is therefore to replace this now defective original SIO/2, with a new fully functional SIO. The first step is therefore to make my monitor work on one of these new SIOs. I have already tried to do this step without success a few weeks ago. Not being sure of the only spare SIO/2 I had at the time, I engaged in what turned out to be a long and tedious procedure of 'certifying' the proper functioning of these new circuits. See previous posts.

That being said, I find myself in the following situation:

• - I know that my monitor program works on port #1 of the original SIO/2, although it has a faulty port #0.
  
  
• - I have three working SIO/2s, successfully tested on the Easy z80 board.
  
  
• - I have five SIO/0s stamped SIO/2 from China successfully tested on the Easy z80 board.
  
  
• - The first tests of the monitor on a working SIO/2 do not work :-(
  
  
• - I had some problems with signals arriving at the SIO/2, which I easily fixed by replacing the IC socket. I was able to follow the progress of the SIO initialization with the logic analyzer.
  
  
• - When the SIO is initialized, I systematically end up with bit D6 of the status register #0 (Tx UNDERRUN) set.

The conclusion I draw from all this is that now, there must be a problem in my code, particularly in the part dedicated to the initialization of port #1. Difficult to understand since it works very well with the original SIO. But, no doubt yet, all the tests previously carried out on the new components have clearly explained the real situation. Doubt is no longer permitted.

So I spent some time trying to find examples of SIO initialization. I found some, I tested them, nothing worked. I even pushed the 'vice' to the point of asking the question to ChatGPT. He did give me some codes, or pseudo initialization codes, but nothing that shows a big error on my part.

Skeptical and a little discouraged.

That's when I remembered a 'prophetic' sentence from a teacher I had in 1992 when I was taking a higher technician's certificate, telling me: "You're a guy from the 80s, that's for sure".

Which he was totally right about. I had a total lack of professional career, mediocre jobs, mediocre pay etc etc... But that's another story.

Yes, but at the time, I spent my time experimenting with the small microcomputers of the time (hence my lack of high degrees, you can't do everything at the same time!). I then remembered problems I had encountered with component initialization. Quite simply the initialization delay of certain circuits. Either after a RESET, or even after the register initialization phase.

SO: I simply inserted a small timer loop at the start of the monitor, just before launching the initialization of the various circuits used, namely the PIO, the CTC and the SIO. I also inserted an identical timer just after the initialization phase of the SIO. You never know, and it does not interfere with the launch of the program.

Well, ChatGPT never indicated to me that there could be problems of this type. The ChatGPT universe is an ideal universe where everything always happens as in theory.

Obviously, as soon as this modification was made, the monitor program started on this new SIO. The original SIO also worked as before.

Screenshot obtained during a 'test session' of the RAM with a new and functional SIO:

And to 'push the plug' a little further, I also performed this test this time with one of the fake SIO/2s, namely a SIO/0, but placed on my SIO/2 to SIO/0 adapter because... it can also do the reverse.

The monitor started working again without any problems.

Fake SIO/2 but real SIO/0 on the EMU1 board

So you might ask: all this time and effort for that?

That's not wrong. But hey, when you have one big doubt, it's already potentially not easy to move forward. When you have two, a Saturn V doesn't take off. Beyond that, it's not even worth getting up in the morning, unless...

And besides, all this doesn't help me with my floppy disk reading problem. Actually, it does. Since I'm moving forward with full knowledge of my abilities now. 

The next step is now to make my monitor work on port #0 of one of the functional SIOs. This shouldn't be difficult because port #0 doesn't receive its clock from the CTC but directly from system frequency dividers. And basically, I configured the CTC to generate the same communication frequency to the SIO. In principle, only the SIO port addresses need to be changed. 

Wiring the serial to USB adapter will be a bit more complicated because the additional integrated circuits must remain in place, which was not the case for port #1.

Once this is done, I will then be certain that communication with the floppy drive will be functional. However, I have already changed the original SIO/2 with the first spare SIO/2 that I had and that I now know is functional, without having succeeded in booting the EMU1 on its system. 

But that was before discovering that I had a defective memory component, precisely in a most inconvenient place, that is to say almost at the beginning of the RAM available for system variables. Assuming that this is also where the system developed by EMU places its data...

I'm not at the end of my troubles, but at least, after several weeks, I'm making some progress on the subject...

EMU 1 : a big small step

As a follow-up to my last post, after publishing it, I asked myself the question of whether I had actually tested my five new SIO/2s from China on the small Eazy Z80 board.

Sure, I tested them, but only on their serial port #0. Because actually at the beginning of my tests, I had not found a way to switch the console to port #1. Now that I knew how to do it, I tested these five circuits again on the small Easy Z80 board.

And there, it was a strange surprise. When I had carried out my first tests with these circuits directly on the EMU1 board and I could not get the menu of my monitor from the serial port #1, I had first thought that these circuits were fakes. It still surprised me coming from the supplier from whom I sometimes get 'unobtainable' components.

By repeating these tests on the Easy Z80 board, port #0 of each SIO works without problem. On the other hand, it is impossible to obtain anything on their port #1. I had initially done the port switch tests with the original SIO/0 of the Easy Z80 to make sure that my manipulation was correct.

That's when I thought that, statistically speaking, what I was seeing was still a bit too 'big' for there not to be a mix-up somewhere. So I tested these components directly on the Easy Z80 board without going through my SIO/2 to SIO/0 adapter. And what do you think happened? All the #1 ports of the SIO/2 started working.

Conclusion: although stamped SIO/2, the five circuits coming from China are, in fact, SIO/0s. Ah, but you could object that maybe my SIO/2 to SIO/0 adapter is not correct? In fact, yes, it is correct. I was able to test it successfully, not only with the two other SIO/2 received from Germany, but also in fact with the only spare SIO/2 that I had from the beginning. Which validates the situation at the moment, and allows me to see a little more clearly in all this mess of tests carried out on the EMU1 board and from which I could not find a way to progress in my diagnostics on this EMU.

So, the situation is as follows: 

• The original SIO/2, present on the EMU1 motherboard has a port #0 that does not work. Therefore, I cannot test port #1 of this circuit on the Eazy Z80 board since the monitor necessarily starts on port #0. On the other hand, I know that port #1 'must' still work since I can display the monitor I created for the EMU1, as well as select the menu options.
  
  
• The five SIO/2 circuits I received from China are actually SIO/0 and are functional.
  
  
• I have three working SIO/2s that I was able to test on the Eazy Z80 board, namely the spare that I have had since the beginning, and the last two components purchased in Germany.
  
  
• Testing the EMU1 using the first spare SIO/2 I had gave no results. Which made me think that this circuit was defective. Which led me to order five other SIO/2 circuits which also did not work but because port #1 is accessible as a SIO/0 and not SIO/2. Which had the effect of making me think that these five circuits were fakes, until I put into service the small Z80 'Easy Z80' board with my SIO/2 to SIO/0 adapter, allowing me to clarify the whole situation.

However, I still can't get my monitor to display on the EMU1 board with the three working SIO/2s I have.

But from now on, the situation has changed. I KNOW that the SIO/2s are functional, and that, therefore, something is happening on the EMU1 board. So, all I had to do was take out the logic analyzer, plug it into the functional SIO/2 and look at the signals submitted to it. 

I don't really like using the logic analyzer I have, I don't like its user and configuration interface. I still have trouble detecting the relevant patterns, but hey, I had no choice. I must admit that for once, I had no trouble following the entire SIO initialization phase, as well as the emission of the first characters.

I noticed two important things. The first is that apparently bit D5 always remains at '0'. and that therefore, in my initialization sequence, at least two data from the CPU are received 'false' by the SIO.

On the other hand, the transmission sequence seems to go well, even if in fact nothing circulates on the TX pin of the circuit, and stops after receiving 6 characters to transmit.

At first glance, the wrong D5 bit would set the transmission format to 6 bits long instead of 8. This should not prevent the transmission of something that would not be understood by the terminal emulator anyway, while nothing happens on the screen. And I do not see why the transmission would stop after 6 writes in the SIO, knowing that the transmission authorization bit is not affected by the D5 bit and that it seems to me that the FIFO in TX is only two bytes.

Conclusion: I have made great progress because I am no longer in total confusion. I notice abnormal phenomena on the EMU1 board when it is equipped with a SIO/2 more recent than the original one. This gives me real research leads. And first of all, determine the reason why the D5 data bit no longer provides the level necessary for it to be taken into account by the SIO. Once this problem is understood and corrected, I will be able to progress in implementing a functional SIO/2 on this board.

This promises me some more very studious evenings. Once I have resolved, quickly I hope, this problem, I will return to the subject of the Drumulator in FPGA. On this subject I have also advanced. The machine does not start correctly but I think that this comes from the way I generate the CTC interrupts.

EMU 1 : a small step

At the moment, I'm still stuck on what I think is the main problem, which is a supposed malfunction of the SIO/2 which manages data writing and reading from the floppy disk drive.

The SIO has two serial ports numbered #0 and #1.

So I created a small monitor for the EMU1 mother board from port #1 of the SIO, allowing me to run the RAM test, because the EMU1 has an original serial output available for external communication with a computer.

I had a lot of difficulties making this monitor. But, after a while, it ended up working on port #1 of the board's original SIO/2. 

Then, I tried to make this monitor work with an SIO/2 which I assumed was fully functional. I never managed to get anything. Hence the doubt about the functioning of this other SIO/2.

In fact, I ordered five more SIO/2s, directly from a supplier in China. Supplier from whom I sometimes order unobtainable components, and with whom I have never had a problem.

So I tested my monitor with these five new SIO/2s. I never managed to get anything. And the EMU board didn't show any more signs of working when I booted it with the stock OS. Hence, once again, the doubt about these five new circuits.

Result: I went in two directions simultaneously. The first to consist of purchasing two SIO/2 again, from Germany this time, then creating a small adapter board allowing a SIO/2 to operate in place of a SIO/0. The difference between these two components is minimal and consists of just two or three port #1 pins to rearrange. There is no differences in software.

The adaptation circuit that I sent to be made:

I actually intend to use a small computer board under CP/M 80 which has a SIO/0 in order to test the operation of the two ports of all the SIO/2s in my possession. This is the Easy Z80 board created by Sergey Kiselev and available on his github repository: https://github.com/skiselev/easy_z80

I built this board in 2021. Since then, the RomWBW ROM has gone from version 3.0.1 to version 3.4.0, with the possibility of swapping the monitor's communication port using the simple command "i 1 115200" for example. I told myself that I had a perfect system for testing my SIO/2s.

First of all, I updated the ROM of this little system, and tested the controls with the original SIO/0 circuit. And indeed, at startup, I have communication with port #0 of the SIO, then after launching the command, communication goes to port #1. This part being validated, I therefore inserted the SIO/2 to SIO/0 adapter on this Z80 board and started my communication tests again.

My Easy-Z80 with an SIO/2 on my adapter.

Eazy-Z80 currently on port #0 asking for going to port #1

Easy-Z80, communication established on port #1

And there: amazement!

All SIO/2s in my possession, other than the original one on the EMU1 board, work. Which embarrassed me. This means that there is a problem, either in the initialization of the SIO which I do in my monitor program, but then, why it works very well with port #1 of the original SIO/2? Or there has an electronic problem on the EMU1 board, which I cannot determine. And again, why does this work with the original SIO/2?

On the other hand, and this is very good news, I was able to notice that on the Easy Z80 board, the original SIO/2 whose port #1 works very well on the EMU1 board, does not work correctly, in any case on its port #0. The transmission goes without problem, I get the board's monitor pattern every time I perform a RESET of the board. On the other hand, I only receive characters very rarely, and when it goes well, it is only a few characters maximum and only on the condition that the board has just been put back under power. In fact I got exactly the same result when I coded my monitor program not to work with port #1, but with port #0. 

So, there, I can now conclude that the original SIO/2 of the EMU1 is not working correctly and, in its current state, is in any case incapable of receiving information from the floppy disk :The TX function of port #0 therefore seems to work normally, however the RX function only works a few seconds after powering up. That's already a good point.

The second thing now is to try to understand why none of the functional SIO/2s are able to provide me with access to the monitor that I programmed for the EMU1 board. Signals problem or problem in my code?

I feel that the origin of the problem may not be easy to determine...

Small remark about the Easy Z80 board. I am completely surprised that RomWBW is still maintained and even improved four years after creating this little system. It's actually quite cool to see this board working in a terminal on my PC. Guaranteed vintage feeling...

EMU 1 : the saga continues

For some time now, and following all the tests that I have been able to carry out on the EMU 1 motherboard, I have come to the conclusion that I 'must' have a problem with the circuit Zilog SIO/2 serial interface, in other words an 8442 type circuit.

Obviously, I haven't been doing nothing for the entire time since my last post on the subject. I ordered five circuits directly in China from a supplier in whom I have relatively good confidence.

After a few days of waiting, I received my five circuits.

I was quite excited upon receiving these circuits and couldn't resist trying them 'right away' on the EMU 1 motherboard.

Hallo what?!!! Impossible to have the test menu on screen which nevertheless works very well with the original SIO/2 component.

Looking carefully at the logo engraved on the new circuits, I really wonder if they are not fakes!

I don't have the means to resolve the doubt at the moment. I would need a machine using a SIO/2 circuit to check their operation. Exactly, I have one. This is a montage created by Sergey Kiselev, who is called Easy_z80 and which is located at this address: https://github.com/skiselev/easy_z80

Unfortunately, this system uses not an SIO/2, but an SIO/0. The difference? Communications port #2 is not wired the same way. Nothing very complicated in fact, the TX and RX clock is on the same pin on the SIO/0 while on the SIO/2 the clock arrives on two different pins, which allows for a different communication speed in transmission and reception. In addition, the receive pin arrives on pin 29 of the SIO/2 while it is pin 28 on the SIO/0.

The result of this is that I cannot test a SIO/2 on the Easy_Z80 board either!

Impossible to dispel doubt about the functioning of the circuits, and therefore the motherboard of the EMU 1. What a 'mess'!

So I opted for two actions. On the one hand I ordered a set of two other SIO/2s on eBay, but this time in Germany and supposedly coming from an NOS! I also developed a small adapter to allow the use of either an SIO/0 type circuit on the EMU 1 card, or an SIO/2 on the Easy_Z80 system card.

With this adapter, I will at least be able to test the operation of my SIO/2 on the Easy_Z80 card, knowing that Easy_Z80 works very well with the SIO/0 with which it is equipped.

As you can see on the Easy_Z80 card, the SIO is indeed an 8440, a SIO/0 therefore:

I will be able to test the SIO/2 with my adapter, knowing that the two serial ports are used as simple asynchronous communication ports. The /SYNCA and /SYNCB signals are not used, which therefore allows the use of an SIO/2 instead of an SIO/0.

Likewise, these signals are not used on the EMU 1 motherboard. An SIO/0 can therefore be used instead of an SIO/2, with the adapter I made.

The continuation after the next experiments...

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

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 ;-)

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