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