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