Retromaster’s Electronics Projects

…related to old computers and other assorted stuff…

Posts Tagged ‘CumuluBus’

Cumulus Bus Saga Continues

Posted by retromaster on August 22, 2011

Here is today’s second post: Another update on Cumulus.

First, the bad news: It looks like with the most recent change to CumuluBus, Cumulus bus errors were greatly reduced, but not completely eliminated. This is the case with the long cable setup.

Now the good news: I have tried the short cable setup (using the two closely-located connectors on the IDE cable), and during extensive testing, I have not encountered any bus-related issues.

What does this mean? It means that on some Orics the long cable setup may not work properly. In these cases, Cumulus will most probably still work fine in the short cable setup, though. It will be a somewhat inconvenient, though, as the cable length is not more than 10cms.

Why does this happen? Here is my guess:

The CPLD used in the Cumulus (XC95XL series) is a relatively modern part (at least compared to the Oric, that is). It has pin signal rise times in the range of a few nanoseconds.

In the current Cumulus design, the CPLD is connected to the data bus over a level-shifter IC (also w/ fast rise times) and directly connected to most of the bus control signals. The connection is by means of the 80-wire IDE cable. When the length of this cable exceeds a certain threshold, the cable starts to exhibit “transmission line” effects. Without the necessary termination on both ends of the cable, these effects cause significant signal integrity issues.

Even with the “SLOW” rise time setting on the output drivers, the XC95XL is fast enough to limit the length of the cable to just about 10cms.

I have to admit that I have overlooked this aspect of the design. I thought that since the frequencies on the Oric bus are so low, there would not be problems over a long cable. However, I failed to see that it is the rise time that’s the real governing parameter here, which was a mistake. This is most likely why things go wrong with the long cable setup.

One way of solving this problem could be by adding “slow” (74hc or 4000-series CMOS) buffers on the Cumulus side. Since these parts have much higher rise times, the permitted cable could be much longer. An additional advantage is that this way, possibly, CumuluBus could be eliminated! However, it would take a significant redesign effort, and it would enlarge the main PCB by quite a bit. To tell the truth, I am not really motivated to go through another design cycle, especially considering that Cumulus seems to work fine with the short cable setup.

Posted in Projects, Retrocomputing | Tagged: , , , , , , , , | 5 Comments »

More Cumulus News

Posted by retromaster on January 17, 2011

Time for some more Cumulus news. There is not a lot, this time, though.

Over the last few days, I’ve worked on the firmware and made numerous small improvements and fixed some minor bugs. I’ve also implemented the log feature suggested by DBug.

I’ve also had the chance to do some tests on the newly-added write feature. I found out that, there was a bug in the code that caused part of the data not being actually written to the SD card. This bug was causing, strangely enough, “Disk Full” errors when copying large files under Sedoric. I’ve fixed this bug and now files are being copied without problems. I’ve also tested saving a game in Space 1999 and that seems to work, too.

Finally, I ordered yesterday some CumuluBus boards from the PCB manufacturer. I should receive them sometime next week, if all goes well. In the meanwhile, I’ll try to locate a cheap local source for the LCD modules. Afterwards, I plan to start assembling some boards :). Also, I am going to put up a project page for Cumulus very soon.

Posted in Projects, Retrocomputing | Tagged: , , , , | 12 Comments »

Cumulus Stability Issues Solved

Posted by retromaster on December 13, 2010

I’ve finally managed to solve the stability problems exhibited by Cumulus. The solution was to implement buffering very similar to what is found in the AmpliBus.

At first, I noticed once more that attaching Cumulus directly to the Oric expansion bus provides very stable operation. I’ve also noticed that, using a cable connection causes major signal integrity problems, including crosstalk visible in the oscilloscope, even with a very short cable. Operation without a cable connection is not feasible, however, due to mechanical stresses placed on the connectors during SD card insertion/removal and button presses.

The first solution I tried was using better cabling. The 80-conductor IDE cables seemed to be very suitable for this purpose, as the ground lines between the signal lines significantly reduce crosstalk, to allow very fast signalling rates. I made a couple of custom adapters to be able to use the 80-pin cables, simple connections, no buffering.

The result was a definite improvement, but bus problems still existed, occurring at much lower frequency, but occurring nevertheless. To me, this indicated that the drive strength of the bus lines on the Oric side was very low, and/or cable loading on the bus lines had a big effect. The next logical step was to implement buffering, similar to the AmpliBus device. I replaced the adaptor on the Oric side with a new design that buffers all Oric output signals (address and control lines) with three 74(A)HCT541 chips. The 541 is the same as the 241/244 used in the original AmpliBus except for a pinout that makes PCB layout easier.

This time, I obtained excellent results, with absolutely stable operation. I’ve also tested operation over the full length of the cable. The IDE cable is great because it gives very good signal quality and it is still commonly available. The only problem with the IDE cables is that despite higher number of pins on the connector, actually, in terms of usable pins, it is one (or two) pins short, because many pins are grounded on the cable itself. To work around this, I opted to move the /RESET and VCC lines to a separate connector. There will not be any problems with simple cable connections for these lines.

At the moment, I am also testing if a regular 34-pin floppy cable will work with buffering. I’ve made yet another adapter for this purpose. So far it hasn’t worked yet but I’d like to figure out why before giving up. Based on the results of these tests, I’ll decide whether the new PCB design will contain a 34-pin connector or a 40-pin (IDE) connector.

It is still unclear to me how the original Microdisc drive even worked under these conditions. Perhaps, it is the pairing of different families of logic with Cumulus and Oric that caused the problems. In any case, a clock pulse (of just 1 Mhz) that does not look like a square wave is a big red flag, in the first place. Nevertheless, I am glad to have solved the stability problems.

Posted in Projects, Retrocomputing | Tagged: , , , , , , , | 15 Comments »