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