Retromaster’s Electronics Projects

…related to old computers and other assorted stuff…

CPC6128 Keyboard Daughterboard for UFE

Posted by retromaster on January 17, 2011

This time, a post unrelated to Cumulus (a Cumulus-related update will follow shortly).

At the request of my friend Alcofribas, I’ve been designing and building (in parallel with my work on Cumulus) a CPC6128 keyboard daughterboard for UFE. It allows one to control the UFE floppy emulator using the host keyboard on a CPC6128, just like one does on an Amiga 500 or 1200.

This daughterboard ended up being a bit complicated to setup (at least moreso than the other UFE keyboard daughterboard designs). The existing ribbon connectors on the CPC mainboard are desoldered and female headers are installed in their place. The ribbon connectors are then soldered to the daughterboard. The daughterboard has male headers that match the female headers installed on the CPC mainboard. So, the daughterboard sits upside down on top of the CPC mainboard, and the case cover can be closed without any problems. The rest of the installation is the same as any UFE installation.

The board contains a PIC16F877 along with three 74LS245 chips, four headers/connectors and lots of pull-ups. The 245 octal buffers control the connections between the CPC mainboard and the CPC keyboard, so that UFE can prevent the CPC host from receiving keypresses when its user interface is active. The PIC controls everthing, scans the key matrix and transmits keypresses to the UFE mainboard over I2C.

It seems to work well, but at the moment there is one complication: For the daughterboard to be able to detect the activation keypress, the CPC host must be actively scanning the keyboard. I am told that this may become a problem with some demos and games. So, I’ll need to devise a way to make the daughterboard scan the keyboard at times for the activation keystroke without interfering with the host scan of the keyboard. The most likely solution is that the daughterboard will determine when (or if) it needs to scan the keyboard, by dynamically adapting to the host’s scanning patterns. I am sure that with some more experimentation and practical thinking, a satisfactory solution may be obtained here.


Posted in Projects, Retrocomputing | Tagged: , , , , , , , | Leave a Comment »

Cumulus Firmware Progress

Posted by retromaster on January 11, 2011

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.

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

New Cumulus PCBs Working

Posted by retromaster on January 5, 2011

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.

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

Cumulus New PCBs Ordered

Posted by retromaster on December 21, 2010

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.

Posted in Projects, Retrocomputing | Tagged: , , , , , | 7 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 »

Cumulus and Custom Disk Routines

Posted by retromaster on November 29, 2010

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.

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

Cumulus and Sedoric 3

Posted by retromaster on November 25, 2010

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.

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

Cumulus Booted First Game

Posted by retromaster on November 24, 2010

I checked the Oric Bus lines with the oscilloscope and it seemed that there could be some signal integrity problems (overshoot, excessive oscillation, maybe even crosstalk). So I decided to remove the ribbon cable in between Cumulus and the Oric and connect Cumulus directly to the Oric by means of a makeshift male-male adapter.

The result was a huge improvement. Now I am able to boot Oric DOS disks without problems. Sedoric 1 disks also work (like the above L’Aigle d’Or). Unfortunately, Sedoric 3 still does not boot. It sometimes crashes with garbage on the screen, or other times, I get the Sedoric copyright boot text but also a warning that says “DOS is altered”, and it is stuck there. A commented disassembly of Sedoric 3 would have been very helpful at this stage… Anyway, it looks like I am getting quite close :).

Getting Sedoric 3 to boot is the first priority now. Once I get that to work, I might work on a new PCB design that gets rid of the separate UI daughterboard and puts everything on one compact, integrated board. To be able to do that, I’ll need to figure out if the cable can be left in place (solving the signal integrity issues in some other way), as that has a direct bearing on the mechanical properties of the board.

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

Cumulus Further Progress

Posted by retromaster on November 22, 2010

Cumulus doesn’t work quite reliably yet, but here is a screenshot of it booting into Oric DOS.

I’ve implemented the seek/step/restore commands, together with the read sector and read address commands. This seems to be the bare minimum for the Microdisc ROM to boot the OS. Unfortunately, there is a random error with the Oric Bus that causes miserable crashes (the screen filling up with garbage, etc.). When it does not happen, I can get the Oric to boot the OS. Most of the time, it does not work, though.

Getting to this stage took a fair bit of debugging and some important modifications. My original CPLD implementation contained an almost exact replica of the original Microdisc schematics. I found out that this did not work very well with the CPLD in some cases. For example, the WD179X contain an edge-trigger /WE input that controls writes to internal registers. This, however, is a problem with an XC95 CPLD, because signal transitions in the /WE line (gated clock into register flip-flops) cause random glitches. My guess is that this behaviour is due to the much higher speed of the CPLD compared to the 74-series logic chips used in the original Microdisc design. The solution here is to use a single, system-wide clock (the CPU bus clock) into all flip-flop clock inputs and use the /WE line only as an enable control. Similar issues arose also in the interface between the MCU and the CPLD, and the solution was the same.

Anyway, getting back to the currently unsolved problem I mentioned above… I modified the original Microdisc ROM to create a test ROM that will hopefully help me debug the issue. It uses the original routines in the Microdisc ROM to continuously read sectors from emulated floppy into RAM and it compares them against copies stored in the ROM. This test ROM usually works fine for several sectors, but eventually, and invariably, I see the same bus glitches occurring with this setup as well. Hopefully, I’ll soon solve this issue and I’ll have a first working prototype of Cumulus in my hands.

Posted in Projects, Retrocomputing | Tagged: , , , , , , , | Leave a Comment »

Cumulus Progress

Posted by retromaster on November 11, 2010

Here is the Atmos with the Cumulus board displaying the “insert system disc” message running the original Microdisc ROM.

Getting to this stage took a fair bit of debugging. First, I had to further tweak the MAP signal timing to make sure that all RAM accesses (including the hidden upper 16k) worked fine. Then I needed to solve a couple of problems with the CPLD code (minor changes, but critical for operation, nevertheless).

At this point, the LA shows that the CPU is stuck in an infinite loop, waiting for an IRQ, right after the first command having been issued to the WD1793. This is perfectly normal, as the floppy controller emulation code (on the PIC side) is not in place yet. That is the first item that I will be addressing in the upcoming days.

On a side note, I have also solved the instability and video flicker issues I mentioned in a previous post. It turned out to be due to the original Atmos power adapter not being able to provide enough juice to power both the Atmos and Cumulus, causing the 5V line to oscillate. Switching to an adapter with a higher current rating (1A at 9V DC) solved the problem. So, apparently, Cumulus will not require a separate power supply connection, but a single, more powerful supply will be required to power both from the Atmos DC power jack.

The debugging process here on this project also gave me the idea to design and build a specialized logic analyzer for projects such as this one. It would be very wide (perhaps up to 48 or 64 channels), but not very fast. It would be intended for the expansion connectors on retro computers, perhaps in a pass-through fashion, by means of custom-made adapters. A SDRAM module could be used for deep storage and a small MCU for USB communication with a PC host. A small FPGA would handle the capture operations and provide and coordinate access to SDRAM storage. Presence of an FPGA would also make triggering very flexible.

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