Cumulus Bus Issues Solved?

Here’s a quick update: Apparently, swapping the AHCT variants of the buffer ICs on the CumuluBus with HC ones did the trick! Coupled with some of the changes I did to the CPLD code, Cumulus seems to be working stable with all three of the Atmos’es I have, with no video issues whatsoever. Over the weekend, if I find the time, I’ll be doing some more tests so that we’ll know for sure… and I might also work on the PIC firmware a bit as well, as there might be still some rough edges there.

I may have to do some repair work in the next days as well, since it looks like the Oric 1 I mentioned in the previous post does not work (with or without Cumulus). Fortunately, the ULA is most likely fine since there is video output (vertical B/W bars). Probably the DRAMs have died… Luckily I have stock :).

Back in Action with Cumulus!

After a few months of absence due to some personal issues, I am glad to announce that for now, everything seems to be back on track :). Now a status update on Cumulus.

Some of the close followers of the Cumulus project may already be aware that, during testing some months ago, some Oric machines failed to boot properly with Cumulus. Lately, I’ve had the chance to work on this issue. It turns out that, due to the notoriously poor clock signal of the Orics (almost sawtooth instead of square!), the bus timings were off with the machines that failed. I have managed to get the failing machines to boot, but there are still timing issues, especially with the MAP signal, as one can observe video corruption from time to time.

I am still working on a solution to this problem… One possible solution is to increase the 32Mhz clock on the Cumulus to 64Mhz. This would enable more accurate sampling of the incoming clock signal and therefor improve MAP signal timing. I do not have any 64Mhz clock oscillators handy though, so I’ll have to order them. I am also not ruling out the possibility that there may be some other signal integrity issue at play here. More tests will probably point this out.

Upgrading the MF70 CNC

MF70 CNC Mk.2 Polyamide X-Axis Endplates

Here is a new post after a litte hiatus.

First of all, let me get the Cumulus news out of the way: Last week, I’ve mailed the very first Cumulus board-set to ibisum for testing. He has five Atmos machines and the necessary hardware for debugging if things do not go as expected, so he is the right guy for testing at this stage. If everything goes smoothly, then I may think about organising a small production run for people who have expressed interest in purchasing Cumulus boards.

And now back to the main topic of this post. For various reasons, I decided to upgrade my MF70 CNC implementation. The aim is to fix some mechanical problems found in my original design, as well as upgrade the motors and the electronics to achieve higher speeds and precision. I even plan to try a split-nut anti-backlash design at some point.

The image above shows the very first parts I’ve manufactured that are intended to replace the current endplates in the X axis. As is evident from the photo, I’ve opted for using plastics this time, instead of aluminium. Although aluminium looks far more impressive, the plastic material I use here (specifically polyamide/nylon) is much easier and quicker to machine (deeper cuts, no coolant required, etc.) with a nice enough finish and they seem to be strong enough for the application (the original parts that come with the MF70 were plastic, too). In any case, if I find that the manufactured parts do not perform to my expectations I can always try out Delrin instead :).

These parts are very similar to the current aluminium parts but there are some differences. The mounting holes have been made into slots for allowing better alignment of the leadscrew with the leadnut. The bearing housing contains an additional 14mm inner groove to allow me to test thrust ball bearings (much higher axial load capacity) instead of the standard ball bearings that I’ve been using so far (I can still use the ball bearings if for some reason I am not happy with the thrust bearings). The motors will be mounted using an additional plate bolted to the motors. That plate and the larger plate in the photo above will be bolted together with a couple of M10 steel screws using the holes on the sides.

Cumulus Page Up!

First of all, the Cumulus project now has a home page  :).

I’ve made a couple of important updates to the Cumulus firmware. First, I made sure that support for both Epson and Phillips LCD controllers is in place and working well (Nokia 6610 LCDs come mainly in these two flavors, as is well known now). There are a few relevant differences between the controllers, mostly in initialization of the controller and handling of screen orientation.

I also implemented bootloader support (i.e. SD card firmware update). It proved to be a little trickier than I first thought, mostly due to compiler issues and a misleading example from Microchip. The main issue was that the compiler does not actually load the table pointer for the erase operation unless you actually issue a dummy read operation first. Now it all seems to be working fine. Right now, the bootloader is larger than it needs to be (there is an embedded font I used for printing debugging messages on the LCD) and verification is missing but these are easy to fix and finalize (before a binary firmware release is made).

I’ve also populated one of the CumuluBus boards that I received and I am glad to say that it works fine.

More Cumulus News

Cumulus About Screen

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.

New Cumulus PCBs Working

Cumulus rev B1 PCB Bottom Side

Cumulus rev B1 PCB Top Side

I finally managed to assemble one of the new Cumulus boards, and I am glad to report that it works fine :). As a matter of fact, I received the bare boards a few days ago but I did not have the 32Mhz oscillators handy so the boards had to wait a bit until I got the part.

Aside from some changes in the CPLD and PIC pin assignments, no changes to the firmware were necessary. In my first tests there did not seem to be stability problems. The only (rather strange) problem I encountered is that the LCD fails to initialize at times (showing nothing), but the PIC definitely keeps on running, because even in this state the floppy emulation works fine. Hopefully, this issue should be fixable.

Here is what’s next (in no particular order):

1. Fix the remaining (firmware) issues and implement some of the missing basic functionality (e.g. writes, user interface).
2. Prepare the enclosure and fit the board in it.
3. Order some CumuluBus PCBs.
4. Prepare the web page for Cumulus and release the current sources, gerbers, etc. under GPL.

Cumulus New PCBs Ordered

Cumulus Rev B PCB Design

A small update this time. I’ve finished the new Cumulus PCB design (revision B) and just yesterday ordered a few units from a manufacturer in China. Usually I manufacture my own prototypes before ordering from a manufacturer, but this time I did not do that, mainly to save some time. Hopefully there are no (major) problems/mistakes with the design :).

Here is a quick summary of what’s new: Integrated LCD and buttons, 40-pin connector (for use with CumuluBus), better routing on critical lines (to further avoid crosstalk), elimination of 74221-based circuitry and crystal oscillator for driving the PIC and the CPLD.

Cumulus Stability Issues Solved

CumuluBus Buffer + 80-wire IDE Cable

Cumulus + 80-wire IDE Cable + Adapter

Cumulus running Barbitoric 1

Cumulus running Barbitoric 2

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.

Cumulus and Custom Disk Routines

Cumulus Running 1337

Cumulus Running Barbitoric

Cumulus Running Quintessential

Cumulus Running Space 1999

At the suggestion of Dbug, I tried out some Oric games and demos that use their own disk access routines instead of the standard OS ones. The behaviour I have seen with these disk images has been consistent with the Oricutron emulator, so I can say that Cumulus is capable of running fine with custom disk routines.

I’ve also made an improvement to the Cumulus design, by getting rid of the 74221 and the associated components. Instead of replicating the circuitry inside the Microdisc, I used an oversampling approach as suggested by Torlus here. I used an 32Mhz clock to sample the incoming ϕ2 clock, apply a digital filter (to prevent glitches that cause instability) and digitally synthesize the associated signals (i.e. MAP, Bus Output Enable, etc.). This approach has been quite promising,  and it looks like the 74221-based circuitry can be eliminated successfully.

One thing I’ve noticed is that, using Cumulus directly attached to the Oric expansion port places a lot of mechanical stress on the connectors. Of course, this is not because of the weight of the Cumulus PCB, but due to the forces applied during SD card insertion and removal. Realising that this will be much more of a problem with the next PCB, which will integrate the LCD and the buttons, I’ve decided to connect Cumulus to the Oric expansion port through a very short length (a few cms) of ribbon cable. This will also allow me to put the board in an enclosure and the PCB can be wider than the expansion port.

So much for good news, though. Unfortunately, Cumulus still seems to exhibit occasional data corruption issues. For example, in demos, this can be in the form of some screens displaying garbage, the music going bad, or even crashes. A number of possible causes come to my mind, including Oric bus signal integrity issues, problems with ϕ2 clock related signals, board issues, CPLD-PIC interoperation or even PIC firmware problems or SD card access issues. I hope that I’ll be able to solve the data corruption issue with some heavy debugging during this week. I’ve come a long way with Cumulus, but I do realize that is basically useless if it does not work reliably.

Cumulus and Sedoric 3

Cumulus in Operation (1)

Cumulus in Operation (2)

Cumulus in Operation (3)

Cumulus in Operation (4)

Cumulus Rev A Closeup

In my post yesterday, I had said that Sedoric 3 disks were not working with Cumulus. Actually, that turned out not to be true, due to a stupid mistake on my part (mostly due to my being not very familiar with the Oric software environment).

The disk images I was trying to get to boot were actually “slave” disks, so they were not bootable at all. Since I had never tried those disks on an emulator (and never had a real Microdisc unit), the “DOS is altered” message misled me into thinking that Cumulus was at fault.

So, booting first with a Sedoric 3 Master disk gave the results in the shots above. To be able to switch disk images, I implemented a rudimentary method that goes through all images in the root directory of the SD card on press of a button.

Now that the basic functionality is working, it’s time to think about where to go next:

0. There is still a bug (probably with the Oric bus) that causes occasional boot failures or crashes. This is much less in frequency than before, but it still needs to be fixed of course.
1. There are quite a few commands missing from the WD179X implementation on the PIC. Also the whole behaviour of the floppy emulator could be made more “floppy-like”, with more accurate timings, for example. Multiple drive support is possible.
2. A proper UI that makes use of the LCD and buttons is part of the specs.
3. A new PCB design that consolidates all existing design elements into a compact, single board, and fixes existing problems (couple of missing traces, etc.) is necessary.