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