EMU 1 : Finally a first hope?

Same title as the previous post? Indeed, the chain of discoveries continues...

In fact, after discovering a faulty memory component and replacing it, I found that the EMU1 boot process still would not initialize.

What to do then? To get to this point, I set up a serial communication with a PC using port B of the SIO component. It is port A of this component that manages access to the floppy drive. So I considered that this SIO was fully functional since I had no problems with this serial connection.

Not really knowing what to do anymore, I then decided to test port A of this SIO by programming it exactly the same way as port B. The Emu1 schematic means that in fact, it is the same clock speed that drives the writing to the floppy drive. Happy coincidence. So, I have absolutely nothing to change in my code, except just the access addresses to port A.

And then there: surprise!

I had a lot of trouble getting characters to display on the screen. As for getting strings to display: impossible. So I ran a whole series of tests to try to figure out what might be going on.

The conclusions are as follows: When powering up, more than 90% of the time I do not have the characters displayed. And above all, reading the status register seems to pose real problems.

Even though the character was emitted, the empty transmit register bit is never set. So my test program crashes on this, and I can't emit a complete character string.

So: I think the original SIO on the EMU1 board has a malfunctioning port A. Which fits perfectly with the current state of the board that won't boot at all. I have another SIO that I've never gotten anything to output. I assumed it was fine. I've done a lot of testing with it, which has led me to a bunch of wrong assumptions.

What now? I can't really move forward on this. I absolutely need to find some working 8442 type SIO circuits to check if the current state of my assumptions is correct or not!

The hunt for 8442 is on...

Come on, I ordered 5 SIO2 8442 circuits. I just have to wait for them to resume testing...

EMU 1 : Finally a first hope?

Since my last post, I have finalized the EMU1 motherboard DRAM test program.

The problem that arose when testing a 64KB bank and then the other 64KB bank was the management of the variables of my small application. Indeed, by switching banks, we completely lose the contents of variables, which can only crash the program.

How to do it then? One possible answer might be: no global variables to avoid fixed references, use the stack, and switch banks only from the main loop, never in a subroutine.

This way, you can use as many variables as you want, and the stack pointer is necessarily at its origin when you are at the highest point in the program: easy!

And that's how I was able to complete my program, and then test it with two DRAM circuits removed from the board.

I set up a small menu to launch the test, then to choose which bank to test. And on the terminal output, we can clearly see the two missing circuits, which therefore generate two errors.

If we look at how the memory circuits are placed on the motherboard, we have this:

Which corresponds to the following logical organization:

I could have clearly indicated the address where the errors are found but converting from numbers to hex strings takes a lot of resources, in the little program space available, less than 1KB, it is impossible to implement. So, I simply indicate in which 16K segment the defective memory component is located.

If I take the example above, where the indication was RAS2/RAS6, knowing that I had previously selected bank no. 1, I know exactly where the faulty circuit is located.

And that in addition the crash occurs with the processing of 0xAA, I only have to target the four circuits corresponding to the '1' of 0xAA, that is: 0b10101010, or bits 1, 3, 5, 7.

Obviously, if there are more bits in error, this will involve testing all 8 circuits that make up the 16KB segment. But hey, it's already much more practical than just knowing that there is a problem on one of the banks...

So what, you ask? Apparently, I am now able to determine that there is no RAM problem, in fact. Because when I put the two circuits back in place, obviously, I no longer had any errors. Yes, except that...

That's when I decided to configure my program to test absolutely all memory addresses. To do this, I placed the memory stack at the minimum possible RAM space according to the number of bytes needed for my program. In fact, by successive tests, I placed the stack one byte above the value where the program crashes, at 0x040C. As a reminder, the first 0x0400 addresses are those of the ROM. The RAM therefore starts at 0x0400, and I placed the stack 12 bytes higher. Then, I configured the RAM scan to start just above the stack, at 0x040D.

And what do you think happened?

I have several bits in error on the RAS4 segment, since if you run the entire test, you see that I had first performed the test on bank 0 which had not generated any errors, then I selected bank n°1 to relaunch the test which generated these errors.

In fact, and as I was in the process of writing my program, I was able to test the RAM by starting the scan at different addresses. What I determined is that at 0x040E, I have the problem with 0x55 and that at 0x040F I have the problem with 0xAA. I am not able to know if it is the same component that is causing the problem. I am obliged to test the 8 circuits.

On the other hand, I don't know where the EMU program is stored, in bank 0 or 1. I also don't know how the two banks are used by EMU. At 27KHz, and given for 2 seconds of sampling, it seems obvious that only 64Ko are used for sound reproduction, and not 128K. In any case, if the EMU1 program is stored from the base of RAM in bank 1, then there is a guaranteed crash.

At least for the first time, I have a small lead to follow for the resolution of the machine startup problem. In addition, I am pretty sure that the CTC, the SIO and the PIO fulfill their function since to be able to communicate by serial link, I was forced to program these three circuits. And their operation corresponds to what was expected. I should also add that I also tested all the RAM circuits using a small DRAM tester of this type :

As for the EPROM programmer used in component test mode that did not detect a faulty 74ls00, would I be a victim of the same tool reliability problem? Hmm...

So....

EMU 1 : Second attempt to write a program for the EMU1 motherboard

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

EMU 1 : First attempt to write a program for the EMU1 motherboard

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.

This program, of rare complexity, simply increments an Index whose value will be sent to the IO address space 0xC0 (__sfr __at 0xC0), in a loop slowed down by a timer consisting of two nested empty loops. There is no prior initialization of the Z80 registers. I do not use IRQs or the memory stack.

This simple program requires 5 bytes of RAM memory. If it works, it will already indicate that the DRAM components are being accessed 'relatively' correctly. If this program works, I will modify it to test the entire 128KB of RAM.

I compile this program using SDCC and the command:

sdcc -mz80 --no-std-crt0 --vc --code-loc 0x0000 --data-loc 0x400 TestRam.c

No special comments. The code starts at address 0x0000 and continues and uses only a few bytes of program area. The data in RAM will be positioned from address 0x0400, just at the beginning of the RAM space, just behind the first KB of code.

And now??? Well, we need to encode the content of the ROM code obtained after compilation and conversion into a binary file to make it compatible with the wiring system made by EMU (thanks EMU)!

Even for a few bytes of ROM, I preferred to write a small program under Windows to automate the task. Because it is necessary to encode not only the data but also the addresses. So as I plan to expand this small test program, I might as well make this encoding process as automatic as possible, even if it means 'taking' a little time to write the Windows application.

I hate using Microsoft's Visual C++. A gas factory, a big piece of crap (for me, because there are thousands of programmers who love Visual C++), GB of data to load and never knowing where we're going! So I tried it with QT. Its mode of operation is much more logical/simpler/efficient for me. Starting with no knowledge of QT, I 'only' needed a short day (I program embedded and am very bad with OS applications) of discovery to be able to write a minimal application that suits me.

So I know that the original EMU executable is 60 bytes. It's 'big' for such a small program, but I coded it in 'C' and not directly in assembler.

And for comparison, here is what the contents of the original binary file look like :

And now the binary encoded in the EMU 'way':

Well, if I understood correctly how the EMU1 motherboard works, if I also understood correctly the ROM coding system and if the DRAM multiplexing system is correct, it is not impossible that I can see something on the LED connector. Maybe not the progress of the counter if my temporisation is not sufficient, but still something...

Now I just have to program a 2732, put it on the motherboard, connect an LED and see if anything happens.

The result of my investigations in a future post...

During this time...

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.

In the past, I took it all apart and changed the front panel capacitors. I also redid the power supply. Then, I put everything back together, scrupulously, and then nothing. This EMU never wanted to restart. The keyboard has been sitting in a corner of my workshop for years. So, having studied the Z80 processor quite a bit during my work on FPGA, I thought it might be interesting to start troubleshooting it. After all, I have managed to troubleshoot several Drumulatore and SP12!

The interior of this EMU1 is in very good condition. Given the 'historical' nature of this machine, I find it increasingly difficult to look at it half dying in its corner!

So I removed the motherboard from the machine once again.

Will I finally be able to boot this motherboard from its floppy drive? The question remains!

It starts badly, the disk rotation motor gives a very slight knock and then stops. I have already spent some time checking the functioning of the motherboard by testing the behavior of the components. And, while I have already done this work years ago, I can't find anything dysfunctional. I don't have a diagnostic ROM for this machine, so for now, it's just a matter of testing the components. I haven't noticed anything glaring. Now I have to try to discover a functional malfunction. This is not going to be easy and may take a lot of time. But hey, I figure that by working on the subject a little regularly, I should get there! This machine only has standard components so....