The last time I posted about the EMU1 motherboard refurbishment, I stopped at the detected problem of the system reset. In fact I was able to see that the new SIO/2 put in place of the original SIO/2 did not start and did not allow me to run my monitor program developed to test the onboard RAM.
While the original SIO/2 port #1 works fine, I realized that the 'new' SIO/2s require a bit more initialization time. So, I studied the RESET system of the board and connected the SIO/2 reset pin directly to the main reset system. This did not allow the SIO/2 to work properly. Obviously, if the system developed by EMU did not provide a slight delay at the processor startup, and this is most certainly the case, the new SIO/2 cannot start. And since it is the SIO/2 port #0 that communicates with the floppy drive, obviously, it can't work.
So I opted for a somewhat 'baroque' solution: I took out the reset pin of the processor in order to generate a manual reset whenever I want. This reset does not reset the other circuits on the board. Therefore, I can start the processor once I am sure that the SIO, the CTC and the PIO are correctly initialized.
The reset button is the left switch. I also added another switch to simulate the 'UPPER' loading switch on the EMU 1 control panel.
And of course, this time I got my monitor program to start correctly. The SIO/2 is therefore correctly initialized and configured. So I will have to study a global reset system a little more sophisticated than the original one implemented by EMU.
Finally, when I say that my monitor can now boot properly on the new SIO/2, it does not mean that the monitor works properly. And yes, since absolutely nothing will be spared on this board, now I sometimes get strange characters on my serial terminal emulator.
Of course, I first suspected a RAM problem. When I launched the DRAM circuit test, I got random errors. I then told myself that this was not credible. I went to look at the PIO. Because this is the circuit that is responsible for bank switching. So obviously if there is a problem on this side, it will inevitably generate problems. I was still a little skeptical because I had to change this circuit once to test another one, nothing more. And until now, I have not had any problems with my monitor. The problems appeared when I modified the processor reset. Another 'bad' lead not to follow?
And indeed, after some tests, I realized that the PIO was simply not powered. A contact problem on the power pin with the effect that the component outputs were navigating in the middle of 'nowhere', generating a totally random RAM bank switch. Well, I changed the circuit support.
Once this socket change was done, my monitor worked properly again. Fortunately I didn't have this problem during my phase of writing the monitor code. With the 'shitty' addressing of the ROM and this bank switch problem in addition, I might not have been able to validate my monitor and, in a fit of extreme anger, I could have thrown this board out the window. It happens!
To recap, the biggest problem with this board initially seemed to be the SIO/2 port #0, which handled communication with the floppy drive, which was no longer working. All my work and all my struggles were 'just' aimed at getting a working port #0 back. What a struggle to get to this point.
It was finally time to test the original code of this board. So I did, and... absolutely nothing happened!
No more unexpected start-ups of the floppy drive motor. Nothing at all happens!
Damn!!! Is this bad news? Well no: 'saved' (for this time) ;-)
I then looked at the machine's user documentation, just to confirm what I had already seen, namely that in fact the machine does nothing at startup, except light up a few LEDs, and waits for a press on either UPPER or LOWER, to start loading the data onto the diskette.
So I followed the EMU 1 schematic and ended up finding (and I guess what I determined is correct) the connections to make on the motherboard of the machine to simulate at least the UPPER switch. The references of the connectors on the front of the machine and the motherboard are different. So, deduction work is required.
So I wired a second switch to the small piece of study PCB, and rebooted the system.
Obviously, it would have been too easy for it to work. Once again, absolutely nothing happens. As I am starting to get used to it now with this machine, I started to check if the system was operational. Using the oscilloscope, I was able to see that the two integrated circuits that manage the multiplexing of the keyboards were correctly addressed. So, a priori, everything is fine on that side.
So I simply continued testing the signal values on the input and output side of the keyboards. And I found something interesting. While the Y9 output of the IC125 circuit is high, 3 inputs on IC121 and IC122 are low. Logically, all the inputs of these two circuits should be high.
I tested all the diodes and found 3 simply cut and a fourth shorted. The result of all this is that overall the system sees a certain number of switches activated. So, I already don't know how the small boot system can react with this type of malfunction.
Well, all I have to do now is change all these diodes and see what happens. But, for once, I feel like I'm moving in the right direction...
Aucun commentaire:
Enregistrer un commentaire