Retromaster’s Electronics Projects

…related to old computers and other assorted stuff…

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.

15 Responses to “Cumulus Stability Issues Solved”

  1. This is really wonderful news – can you tell us Oric groupies what your plans are as far as making this project available to a broader public? I’m ready to start buying parts, if we’re at that stage soon! Maybe a group-buy to get the PCB’s made, or something?

  2. retromaster said

    Well… I’ve been working on a new PCB design as you know from my posts. That’s mostly complete, except for a few details such as what type of connector to use. Once that design is more or less finalized, I’d like to adapt the firmware and the CPLD code to the new PCB design (which should hopefully be trivial). I think it’s best to release everything after that stage, since the current PCB design and the software will be obsoleted at that time, anyway.

    There is still definitely quite a bit of work to be done in the firmware area, like implementing sector/track writes and a proper UI. But I do not anticipate any problems with these, and they can wait until after the new PCB design is finalized.

    For testing the new PCB design, at the moment I am undecided whether to build a new prototype myself or to get a batch made. If I do get a batch made, I may make some of them available once I am done with the initial testing. We will see…

  3. Dbug said

    Congratulations for managing to fix the bus stability issues🙂

    One question, I know that on some Oric, there are problems/conflicts between the power coming from the disc adapter and the power from the Oric PSU.

    Do you think that you could come with a design where the PSU of the Cumulus board could also power the Oric itself, so one does not have to bring along a gazillion of powerbricks? (The default Oric scart is not powered, so the average Microdisc user has a 9v PSU for the Oric, one for the microdisc and one for the scart!)

  4. retromaster said

    I am not surprised to hear about the power conflicts. For some reason (brain damage?), to generate 5V, somebody decided to put a 7905 in the Oric instead of the usual 7805. So, instead of lowering the 9V input to 5V, the ground is “brought upwards”, 9V line stays the same, ground line becomes 4V (with respect to power adapter ground). If there are two separate power adapters (one for Oric and the other for a peripheral), and they have different output voltages, the Oric and the peripheral will have different ground voltages!

    Anyway, what I had in mind is to power Cumulus from the Oric (5V output on the expansion port), but replace the original Oric power adapter with one with a higher current rating (the original one is not enough to power both). That way one still has a single power adapter. There is no need to include a 5V voltage regulator on Cumulus when there is one already in the Oric.

  5. Dbug said

    Are you sure the regulator is going to accept a higher current rating PSU? I know that at least I can burn my fingers on the heat dissipation thingy (radiator?) attached to the regulator after just 20 minutes of usage.

  6. retromaster said

    Actually, I’ve been doing all my tests that way for a while now. I haven’t really left the Oric on for very long periods though.

    The regulator will work with a higher max current power adapter without problems. It only draws as much current as it needs from the power adapter. The real issue is whether the regulator is able to supply both Cumulus and Oric main unit at the same time. It seems to be, but I’ll test it for a longer period to be sure. It won’t work with the original adaptor since the original power adaptor provides barely enough current to run the Oric main unit.

  7. Ian said

    Congratulations on sorting the stability issues! I must have been lucky with my original Microdisc/Atmos pairing as it worked first time and reliably.

    I also once had a prototyping board hanging off a fairly long (~20cm) piece of ribbon cable (in order to interface a C64 SID chip to my Atmos) which worked well, but only after learning about MOS gates and static electricity [the hard way]. If I remember correctly this was flat & twisted to reduce crosstalk. I could open the old Atmos up to see what exact make/model chips are on the bus output buffer if it would help.

    I have also found some info on old Oric PSUs here: http://www.48katmos.freeuk.com/psu.htm . How much current does the Cumulus draw from the +5V line (max, typ)?

    Regards,

    Ian

  8. retromaster said

    Actually, on a stock Atmos, according to the schematics, there are no output buffers on the expansion port. Also part of the problem with Cumulus is that we are pairing different generations of logic here: the XC95XL series CPLD used in Cumulus is probably about 10 years younger than the logic chips in the Oric. This can cause a number of problems, but it all turned out to be solvable.

    In any case, there are many issues in the Oric design itself… Enough to make me write an “engineering review” one day😛. For example, the clock signal looks more like a sine wave than a square wave. The issue of the 7905 I just mentioned… etc. etc.

    Anyway, now I am almost decided on using ATA100 IDE cables for the connection (instead of regular floppy cables I’ve also been testing). The cables are of much better quality and the signal quality will be definitely better (this is important for the data lines that are still unbuffered). The only downside is that an extra cable (of 2 wires) is needed since there are not enough wires to carry all signals and power.

    I haven’t yet measured how much current Cumulus draws but I do not think that it is more than 150mA. A large portion of that is actually spent by the LCD backlight, btw. I’ll measure soon and report here.

  9. Chema said

    Congratulations for this wonderful work!! I always dreamed with a system such as Cumulus. And it already looks pretty finished!

  10. retromaster said

    Thanks a lot, Chema. There is still work to do, but hopefully no major obstacles to overcome.

    By the way, I did measure the current consumption last night. It seems my initial estimate was too low. Cumulus draws around 210mA when idle (no SD card activity). When SD card activity begins, the current consumption may go up to 250mA (depending on the SD card).

    I’ve also left the Oric running with Cumulus for almost an hour and there seemed to be no problems with the on-board 7905 regulator. So I think it’s feasible to power Cumulus from the Oric Expansion Bus. In any case, the 5V power input will be on a separate connector (that is on the CumuluBus bus buffer PCB) so that if problems arise, a separate 7905 can be installed to power just Cumulus.

  11. Dbug said

    I was wondering if you think your system would be able to deal with non standard DSK files, like 256 tracks of 256 sectors🙂

    Of course this would not work on a real microdisc, but for development purpose that would be practical to have everything you need (tools, system stuff, program, debugger, …) on one single DSK file.

  12. retromaster said

    I think it could… From the Cumulus point of view, the only possible issue I can think of is that I only allocated 7 bits for the track register in the CPLD. I’d need to increase that to 8 bits, but this would not be a problem, I guess. In the worst case it would be 128 tracks🙂.

    On the other hand, I am not sure if the standard Microdisc ROM (or even Sedoric?) would be able to support so many tracks. I may be wrong, but I vaguely remember seeing somewhere that the disk access routines took the MSB of the track number as the side. This would also lower the limit to 128 tracks.

    In any case, I am pretty certain that Cumulus will be able to support multiple drives. So perhaps this could be a practical solution, too.

  13. Dbug said

    Well, I was asking that because some people on the defence-force forum have been discussing the possibility of having hard drives on the Oric, or at least “large size storage devices”.

    In any case that would have required a new DOS to handle that, if only for having the support for directories (can’t imagine all the files on the root🙂 )

    So by doing this trick you get the possibility to have approximately 32 megabytes volumes (using 256 bytes per sector – or 64 megabyte with 512 bytes pe sector). If the multiple drives are supported as well, the sky’s the limit🙂

    (Of course this makes sense only if the write operations are supported, else it’s kind of pointless as a “virtual hard drive” if you can’t write🙂 )

  14. retromaster said

    What you’re describing is definitely possible (when a new DOS enters the picture, of course).

    With mega-tracks that contain lots of sectors, and a lot of tracks on one disk, quite large image sizes are possible.

    Some (most likely minor) changes would be necessary for the Cumulus firmware, but it is indeed possible. One thing that comes to my mind is that at the moment Cumulus firmware creates a track-cluster lookup table from FAT to speed up accesses. Perhaps, this would need to be dropped, if tracks became too large, as RAM is quite limited on PIC micros. Each time Cumulus needs to read a new cluster, it would need to check FAT first… This would result in a loss of speed, but ultimately it is not a show-stopper.

    And I do not see any problem implementing writes with the current design, I just haven’t had time to work on it yet. I may leave it until after I order and receive the new PCBs.

  15. Symoon said

    Wow, great news again Retromaster, congratulations !
    About a large size storage device, if Cumulus disk image can be selected directly by the Oric, then the “hard drive” (SD card) can be composed by “directories” (disk images) and that’s it… Only downside is that each directory would remain limited by the maximum size of a disk-image (101 tracks of 19 sectors for Sedoric), and that there would be only 1 level of directories.

    Ayway, if there’s a production batch some day, I’m in for 5 Cumulus !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: