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!