EMU : STOP!

Since my last post about trying to repair the EMU1, I've done a whole bunch of new tests. I also replaced a few integrated circuits. The result is that I haven't progressed one bit.

I still can't load the loading utility from the floppy disk. Whether it's from the actual floppy drive, or whether it's using the HxC emulator.

I now believe that I have carried out all the tests that I could. The problem in this story is that I absolutely don't know the loading program written in the boot EPROM.

It is not impossible, for example, that the motherboard must be correctly mounted in the machine so that information coming, either from the digital/analog conversion boards, or from the control panel, allows the program to exit a loop in order to actually process the data read from the floppy disk.

From what I have done as tests on the motherboard, I know that all the logic for shaping the signals coming from the floppy drive works. As well as serial reception by the SIO/2. Selection by a few PIO output ports also works. Finally, I know that the RAM does not have defective memory.

So I was finally able to test the signals concerning the triggering of DMA when reading floppy disks. And here too, everything seems correct to me. However, the machine obviously tells me that the data coming from the floppy drive is not reliable. I don't understand the reason.

However, the fact remains that the data bus signals are horrible! I also worked on this aspect, managing to obtain very square signals. However that wasn't enough, I always get into a loop trying to read the data without ever getting out.

So, given the time spent doing all these tests and the results obtained, it is high time to stop wasting it like this.

I reassembled the machine. I'm now opting to throw it into scrap metal because in its current state, it's worth absolutely nothing.

No final decision yet...

Regarding the FPGA of a Drumulator, I'll stop there too.

I twice managed to integrate the Drumulator's processor core into two different brands of FPGA. I have been trying the same thing on TRION type FPGAs from Efinix for months now without achieving anything usable.

In fact, right now I know the heart is starting well. It shows me the message 'bAd.' at startup, but immediately, by displaying anything.

This is all the more strange as the interrupt system works well since the message is displayed correctly. But afterwards, the processor seems to go 'I don't know where'. And this is not very easy to test with a standard logic analyzer due to the difficulties in triggering signal sampling.

In addition, I must add that the development software is a bit 'boring': not flexible and above all really very slow. This thing is a real pain, even with a powerful PC. So as in addition, the development tool tends to annoy me a little, and the pseudo-integrated simulation system is not helping the matter, and given the time I have already spent trying to integrate the heart of the Drumulator into this FPGA, I will stop.

Also, I don't know the intricacies of the system of this machine. In fact, it is extremely difficult to move forward when something goes wrong. Indeed, there is virtually no way to know for sure where the problem is coming from. After a while, this type of situation is simply no longer bearable.

The idea was to build a hardware environment compatible with the Drumulator in order to be able to run the machine system there. It seemed 'easier' to do. Observations made, I now say to myself that it would undoubtedly be less complicated to develop everything using equipment that is more practical to use.

I've been working a lot lately on small RISC-V microcontrollers. The development software, which was not very practical a few years ago, has been superbly improved in recent months. And above all, working in this way allows you to carry out debugging in real time. And that’s super interesting.

And as these small microcontrollers operate internally at 144MHz, this provides quite acceptable processing power for this type of machine. And after all, I did this to recreate a programmable clock whose behavior is identical to that proposed in the Texas Instruments TMS1122 of the time!

So I'm still a little sorry for this situation because these two projects made me consume a lot of time without achieving any result. Not to mention the psychological aspect of it, because it is not easy to persevere when there is no sign of improvement. It's even more difficult to abandon a whole job to start again with another method.

But hey, to move forward, you still have to make choices, at some point...

The positive point of all this was to realize that I have lost a progression methodology that I had when I was very young. I know the reasons of this degradation...

EMU1 : no real progress lately :-(

 In fact, I still cannot read the contents of the EMU1 boot disk.

On the other hand, I accumulate the validations of parts that have become or verified functional.

Basically, and following major problems of a really diverse and varied nature, I now know that:

• The SIO/2 serial converter is functional.
• The PIO is also functional on its new circuit support.
• the RAM is free of defects because I can check its operation with the small test program I created.

At this point, I don't know if it's the floppy drive that's the problem. So I put an HXC floppy emulator back into service.

And, good and bad news: the floppy disk still does not read, but, and this is the interesting fact, I obtain exactly the same result as with the 'real' floppy disk drive of the machine.

I was also able to find an image of a system disk for EMU1 on the Internet. I was able to check the content of this image to see that it is indeed an EMU1 image.

I can at least conclude with good confidence that the floppy drive part, real or virtual, is not to be blamed.

How to progress now?

By chance, and passing through Paris, I obtained two replacement integrated circuits which are used to extract the clock and data from the signal coming from the floppy disk drive.

I like to go from time to time to one of the last 'old-fashioned' component resale shops in Paris. Okay, it's not RadioShack but it looks like it:

I have already had the opportunity to talk about this store on my blog. Since then, the window has been somewhat redesigned

On the other hand, the interior has not changed and has remained worthy of the early 80s: a real pleasure!

The goal is to change these components:

I had already studied the signals provided by these two components a little and found nothing to complain about. This was confirmed. Their replacement by two new circuits did not change anything!

As a last resort, I removed the time base establishing resistor needed to separate the clock and data, and replaced it with a potentiometer.

This allowed me to check with the logic analyzer that the signals were correctly recreated, as well as to determine the operating terminals. I placed the value of this potentiometer in the middle of this area. So, from that side, everything seems okay too.

And now the question arises of what can prevent the correct reception of data from the floppy drive. I obviously tested all the signals to and from the floppy drive without detecting anything wrong. Although I noticed a small artifact with the HXC emulator, which should not exist, but I will not dwell on this phenomenon since the behavior observed is identical to that with the real floppy drive.

And there, a new question arises: how does the system recover the data from the floppy drive, to process it? Afterwards?

And yes, because in reality, the boot system does not process data on the fly. It collects them, places them in RAM then executes the program which, if I counted correctly, this time is approximately 8Kb and not the 1Kb contained in the boot ROM.

And this operation is not done by polling. I imagine the processor wouldn't quite be fast enough for that. This entire operation is done by DMA. 

So, assuming now that all the 'mechanics' of managing the floppy drive work and that the correct data is indeed recovered by the system, we must now check that the DMA system places it in RAM.

I had already had the opportunity to discuss the Emulator's DMA system. In fact, there are 8 DMA channels that manage the sending of data to the converter boards for sound generation. However there is a particularity, the first DMA channel is 'usurped' on demand by the floppy disk reading system thanks to the SIORDY signal.

I am now 'imagining' that if this system does not work, the data cannot be placed in RAM, and therefore cannot be executed. If the boot system thinks that things are going well and that it checks the validity of the data in RAM, it will inevitably find that things are not working.

This can be verified by the LEDs on the front panel which remain on or which go off depending on the type of error encountered when reading a floppy disk.

In fact, I have some problems there too. I actually find myself between the following two cases:

And yes, I hear the head moving neither twice per second, nor once every two seconds, but about moving less than two seconds but not twice per second.

But, with the SWAP LED off, I would tend to lean towards case B. 

That would suit me well, because a CRC problem is entirely possible in the event of an absence of data. In any case, I'm going to go with this assumption for now.

The next step is therefore to check if the DMA system is working well and that the data is correctly placed in RAM. I don't know yet how I'm going to carry out these tests. The adventure continues...

EMU1 : it's still progressing...

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

EMU 1 : SIOs are working!

Well, finally, as expected, I was able to set up communication with port #0 of the SIOs without difficulty. It works with the SIO/2 as well as the SIO/0 (fake SIO/2) placed on the adapter that I made.

I can get rid of the original circuit with full knowledge of the facts.

I think I can now enter a 'normal' phase of debugging this electronic board. Because I imagine that it will not work immediately. That would be too good to be true!

Indeed, in principle, replacing the original SIO with a new circuit should not have caused me so many problems. I'll skip over the doubts about the operation of the new circuits, in the end, I had to add a delay when starting my monitor to allow the SIO to initialize correctly.

I imagine that the EMU 1 boot system will also have this problem. I will have to look at the RESET system to see if it is long enough to allow all the components to initialize correctly.

To be continued...

The Cody Computer : juste for fun.

To get away from the topics I've been working on for several months now, I intend to build a small tube audio amplifier and to 'relax' by making a small 'old-school' microcomputer.

I actually came across a Facebook post, while I'm browsing this social network less and less often due to general interest that is very close to absolute emptiness, on a subject that I find interesting: the construction of a small computer resembling the machines of the 80s, and more precisely the Commodore 64.

Nothing fantastic, you might say. Even the 'advertising' picture of the subject can be quite laughable. You'll probably be right, except that...

For years I have been looking for a small machine to turn into a 'thing', a kind of companion that can be used on a daily basis for various 'basic' type applications.

In fact, almost all attempts at new hardware are very ambitious, since it is often about doing 'better' than what was 'before'. Often it starts strong, and then quickly the interest in the subject wanes. In my point of view, the main problem, beyond the difficulty of realization and its cost, is simply the documentation.

Of course, there are always wikis, forums, etc... where the information is not up to date and 'stuffed' with links pointing to the 'detailed' documentation of this or that subject. In fact, it is extremely 'boring'. Which imposes a very slow and tedious learning curve for any newcomer. I faced this type of problem with the MSX machine that I had the opportunity to assemble a few years ago.

Here, none of that. The machine is simple, even simplistic. It only offers basic and functional functions and above all, the designer took the time to publish a book in PDF format that details absolutely everything you need to know to 'play' effectively with this machine. The book is currently 571 pages long that I forced myself to read to see if there was any 'useless padding' of pages, just to make the counter go up. Well no. Everything is there and very well documented.

Frederick John Milens has done a huge amount of documentation work and it is absolutely brilliant. At least there will be no need to spend hours searching on the Internet, and that is a decisive plus.

And then here, in fact, no totally sterile discussions on the characteristics of the machine, which please or not, no sterile disputes either on the choices of the designer and all these sorts of things. The machine is as it is and that's it! You have to do with it, and that's not so bad. So, notice to the real 'reto(or not)-geeks' able to embellish, improve, create with this little machine... 

So, I already had printed circuits board made for this little computer. The assembly work will be quite simple given that few components are present on the circuit. Almost 'Zx81'.

There is no need for me to specify the characteristics of the Cody Computer here since absolutely all the information can be found on the site dedicated to it:

https://www.codycomputer.org

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

EMU 1 : a big small step

As a follow-up to my last post, after publishing it, I asked myself the question of whether I had actually tested my five new SIO/2s from China on the small Eazy Z80 board.

Sure, I tested them, but only on their serial port #0. Because actually at the beginning of my tests, I had not found a way to switch the console to port #1. Now that I knew how to do it, I tested these five circuits again on the small Easy Z80 board.

And there, it was a strange surprise. When I had carried out my first tests with these circuits directly on the EMU1 board and I could not get the menu of my monitor from the serial port #1, I had first thought that these circuits were fakes. It still surprised me coming from the supplier from whom I sometimes get 'unobtainable' components.

By repeating these tests on the Easy Z80 board, port #0 of each SIO works without problem. On the other hand, it is impossible to obtain anything on their port #1. I had initially done the port switch tests with the original SIO/0 of the Easy Z80 to make sure that my manipulation was correct.

That's when I thought that, statistically speaking, what I was seeing was still a bit too 'big' for there not to be a mix-up somewhere. So I tested these components directly on the Easy Z80 board without going through my SIO/2 to SIO/0 adapter. And what do you think happened? All the #1 ports of the SIO/2 started working.

Conclusion: although stamped SIO/2, the five circuits coming from China are, in fact, SIO/0s. Ah, but you could object that maybe my SIO/2 to SIO/0 adapter is not correct? In fact, yes, it is correct. I was able to test it successfully, not only with the two other SIO/2 received from Germany, but also in fact with the only spare SIO/2 that I had from the beginning. Which validates the situation at the moment, and allows me to see a little more clearly in all this mess of tests carried out on the EMU1 board and from which I could not find a way to progress in my diagnostics on this EMU.

So, the situation is as follows: 

• The original SIO/2, present on the EMU1 motherboard has a port #0 that does not work. Therefore, I cannot test port #1 of this circuit on the Eazy Z80 board since the monitor necessarily starts on port #0. On the other hand, I know that port #1 'must' still work since I can display the monitor I created for the EMU1, as well as select the menu options.
  
  
• The five SIO/2 circuits I received from China are actually SIO/0 and are functional.
  
  
• I have three working SIO/2s that I was able to test on the Eazy Z80 board, namely the spare that I have had since the beginning, and the last two components purchased in Germany.
  
  
• Testing the EMU1 using the first spare SIO/2 I had gave no results. Which made me think that this circuit was defective. Which led me to order five other SIO/2 circuits which also did not work but because port #1 is accessible as a SIO/0 and not SIO/2. Which had the effect of making me think that these five circuits were fakes, until I put into service the small Z80 'Easy Z80' board with my SIO/2 to SIO/0 adapter, allowing me to clarify the whole situation.

However, I still can't get my monitor to display on the EMU1 board with the three working SIO/2s I have.

But from now on, the situation has changed. I KNOW that the SIO/2s are functional, and that, therefore, something is happening on the EMU1 board. So, all I had to do was take out the logic analyzer, plug it into the functional SIO/2 and look at the signals submitted to it. 

I don't really like using the logic analyzer I have, I don't like its user and configuration interface. I still have trouble detecting the relevant patterns, but hey, I had no choice. I must admit that for once, I had no trouble following the entire SIO initialization phase, as well as the emission of the first characters.

I noticed two important things. The first is that apparently bit D5 always remains at '0'. and that therefore, in my initialization sequence, at least two data from the CPU are received 'false' by the SIO.

On the other hand, the transmission sequence seems to go well, even if in fact nothing circulates on the TX pin of the circuit, and stops after receiving 6 characters to transmit.

At first glance, the wrong D5 bit would set the transmission format to 6 bits long instead of 8. This should not prevent the transmission of something that would not be understood by the terminal emulator anyway, while nothing happens on the screen. And I do not see why the transmission would stop after 6 writes in the SIO, knowing that the transmission authorization bit is not affected by the D5 bit and that it seems to me that the FIFO in TX is only two bytes.

Conclusion: I have made great progress because I am no longer in total confusion. I notice abnormal phenomena on the EMU1 board when it is equipped with a SIO/2 more recent than the original one. This gives me real research leads. And first of all, determine the reason why the D5 data bit no longer provides the level necessary for it to be taken into account by the SIO. Once this problem is understood and corrected, I will be able to progress in implementing a functional SIO/2 on this board.

This promises me some more very studious evenings. Once I have resolved, quickly I hope, this problem, I will return to the subject of the Drumulator in FPGA. On this subject I have also advanced. The machine does not start correctly but I think that this comes from the way I generate the CTC interrupts.