SYNTHELECTRO : synthesizers, electronic, retro-computing, etc...
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 :
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.
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.
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...
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 |
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....
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.
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!
