EMU 1 : a big small step confirmed!

Following on from my last post on the EMULATOR 1, I spent some time trying to get communication on port #1 of one of the new SIOs I recently purchased. As a reminder, I created a small monitor to test at least the RAM on the EMU motherboard. This monitor works very well on port #1 of the original SIO/2, knowing that this original SIO/2 has a port #0 that no longer works, which I was able to verify by installing this SIO/2 on a small Easy z80 processor board using a SIO/2 to SIO/1 adapter of my own design.

The object is therefore to replace this now defective original SIO/2, with a new fully functional SIO. The first step is therefore to make my monitor work on one of these new SIOs. I have already tried to do this step without success a few weeks ago. Not being sure of the only spare SIO/2 I had at the time, I engaged in what turned out to be a long and tedious procedure of 'certifying' the proper functioning of these new circuits. See previous posts.

That being said, I find myself in the following situation:

• - I know that my monitor program works on port #1 of the original SIO/2, although it has a faulty port #0.
  
  
• - I have three working SIO/2s, successfully tested on the Easy z80 board.
  
  
• - I have five SIO/0s stamped SIO/2 from China successfully tested on the Easy z80 board.
  
  
• - The first tests of the monitor on a working SIO/2 do not work :-(
  
  
• - I had some problems with signals arriving at the SIO/2, which I easily fixed by replacing the IC socket. I was able to follow the progress of the SIO initialization with the logic analyzer.
  
  
• - When the SIO is initialized, I systematically end up with bit D6 of the status register #0 (Tx UNDERRUN) set.

The conclusion I draw from all this is that now, there must be a problem in my code, particularly in the part dedicated to the initialization of port #1. Difficult to understand since it works very well with the original SIO. But, no doubt yet, all the tests previously carried out on the new components have clearly explained the real situation. Doubt is no longer permitted.

So I spent some time trying to find examples of SIO initialization. I found some, I tested them, nothing worked. I even pushed the 'vice' to the point of asking the question to ChatGPT. He did give me some codes, or pseudo initialization codes, but nothing that shows a big error on my part.

Skeptical and a little discouraged.

That's when I remembered a 'prophetic' sentence from a teacher I had in 1992 when I was taking a higher technician's certificate, telling me: "You're a guy from the 80s, that's for sure".

Which he was totally right about. I had a total lack of professional career, mediocre jobs, mediocre pay etc etc... But that's another story.

Yes, but at the time, I spent my time experimenting with the small microcomputers of the time (hence my lack of high degrees, you can't do everything at the same time!). I then remembered problems I had encountered with component initialization. Quite simply the initialization delay of certain circuits. Either after a RESET, or even after the register initialization phase.

SO: I simply inserted a small timer loop at the start of the monitor, just before launching the initialization of the various circuits used, namely the PIO, the CTC and the SIO. I also inserted an identical timer just after the initialization phase of the SIO. You never know, and it does not interfere with the launch of the program.

Well, ChatGPT never indicated to me that there could be problems of this type. The ChatGPT universe is an ideal universe where everything always happens as in theory.

Obviously, as soon as this modification was made, the monitor program started on this new SIO. The original SIO also worked as before.

Screenshot obtained during a 'test session' of the RAM with a new and functional SIO:

And to 'push the plug' a little further, I also performed this test this time with one of the fake SIO/2s, namely a SIO/0, but placed on my SIO/2 to SIO/0 adapter because... it can also do the reverse.

The monitor started working again without any problems.

Fake SIO/2 but real SIO/0 on the EMU1 board

So you might ask: all this time and effort for that?

That's not wrong. But hey, when you have one big doubt, it's already potentially not easy to move forward. When you have two, a Saturn V doesn't take off. Beyond that, it's not even worth getting up in the morning, unless...

And besides, all this doesn't help me with my floppy disk reading problem. Actually, it does. Since I'm moving forward with full knowledge of my abilities now. 

The next step is now to make my monitor work on port #0 of one of the functional SIOs. This shouldn't be difficult because port #0 doesn't receive its clock from the CTC but directly from system frequency dividers. And basically, I configured the CTC to generate the same communication frequency to the SIO. In principle, only the SIO port addresses need to be changed. 

Wiring the serial to USB adapter will be a bit more complicated because the additional integrated circuits must remain in place, which was not the case for port #1.

Once this is done, I will then be certain that communication with the floppy drive will be functional. However, I have already changed the original SIO/2 with the first spare SIO/2 that I had and that I now know is functional, without having succeeded in booting the EMU1 on its system. 

But that was before discovering that I had a defective memory component, precisely in a most inconvenient place, that is to say almost at the beginning of the RAM available for system variables. Assuming that this is also where the system developed by EMU places its data...

I'm not at the end of my troubles, but at least, after several weeks, I'm making some progress on the subject...