Cumulus Bus Saga Continues

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.

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.

Quick Cumulus Update

Here is a small update on what’s going on with Cumulus: I’ve finally received the CumuluBus boards from the PCB manufacturer today. Within the next few days, I am going to assemble and test a few of them, and if all goes well, move on to assembling some full Cumulus boards.

The source code for the Cumulus firmware has been available at the defence-force SVN for some days now:
http://miniserve.defence-force.org/svn/public/oric/hardware/cumulus/.

I have not worked on the sources after I uploaded the sources though, mainly because I have been working on (yet) another, quite different project during the last week or so, while waiting for the boards. I’ll disclose the details about that soon here on the blog.

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.

Cumulus Firmware Progress

Cumulus UI (Main)

Cumulus UI (Menu)

Cumulus UI (Mount Image)

Cumulus (Copied Files in Drive B)

Over the last few days, I’ve improved the Cumulus firmware quite a bit. First of all, as the shots above show, Cumulus now has a proper user interface. The emulation screen shows the state of all drives, including the image mounted, the current track (updated in real-time), and the write protect status. From this screen, one may go into the image selection menu to mount a DSK image in one of the emulated drives or modify the write protect status. Also accessible from here is the main menu which allows one to modify the more general settings/preferences or even reset the Oric.

The square “light” on the top right blinks in green when Cumulus is idle and becomes when red disk operations are being executed. One can even interact with Cumulus while disk operations are in progress. Obviously, disk operations are given priority over user interaction, so the UI may feel sluggish or unresponsive if the drives are being accessed frequently.

As the UI shots already suggest, in addition to all these, I’ve implemented support for multiple drives and it seems to be working well. There is also very preliminary support for the “write sector” command in the firmware at the moment. I’ve done some early tests on this with the Sedoric copy command and I was able to copy some files with success, but I definitely need to do more thorough testing on it to make sure. I am open to suggestions on this.

There are still numerous bits and pieces missing, from both the UI and the WD1793 emulation, but I think this is a good start for verifying the main features on the new board and making them more accessible.

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.