Before my (somewhat lengthy!) break in writing these articles we were looking at the standard podule bus, which applies to any 32-bit Acorn machine.  This time we're going to look at the extensions Acorn provided for the Risc PC and later machines.  For the sake of space I'm not going to go over them in depth, but give an outline so you know where to look in the relevant sections of the podule specification to find out more.

EASI DEBI

EASI stands for the Extended Address Space Interface.  It provides for faster podules and a larger memory map.  DEBI (the DMA Extended Bus Interface) adds DMA to the podule bus.  EASI is available on all Risc PC, A7000(+) and Iyonix machines, whilst DEBI is only found on the Risc PC.  Both make the podule bus a bit more like the PC's ISA bus.

EASI

If you've been following my series so far, you might have noticed that I had to employ a few tricks to work round the limitation of only having 4Kwords of address space on a standard podule.  EASI greatly expands this, to provide 4 million words of address space.  So we now don't have to mess with paging registers if we wish to fit a ROM onto our podule.  In addition EASI provides a 32 bit wide bus to the podule - so we can read whole words of data at once.  This is particularly useful for modern interface chips which have a 32 bit interface.

To do this, we need more address and data lines on the podule bus.  These are provided by using a 96 way connector (DIN41612 with rows a, b and c loaded), where the previously unused middle row of pins provides the extra signals.  These new signals can be seen in bold on figure 1.

Address lines LA[16] to LA[23] provide our extra address space.  To do this we must use a new type of bus access - EASI.  IOMD provides another area of memory through which we can access EASI podules, and gives us another bus strobe to indicate we're accessing this area.  /EASI is similar to the /PS strobe, except that it tells our podule we now have 4M addresses to play with.  It's also faster than IOC fast mode as indicated by /PS, and its speed may be controlled not by the address we access, but by a register in the IOMD.  So to change the speed of our accesses we must use a SWI, Podule_SetSpeed.

Let's look at an example.  In article 2 we interfaced a 2Kbyte SRAM chip to the podule bus using /PS to decode IOC space.  Now we can do the same for a somewhat bigger memory.  Let's assume we want to fit a 16Mbyte SRAM into EASI space.  In fact such devices don't exist yet - usually you use several chips - but we'll assume that they simply follow the same interface as the 2Kbyte SRAM we used before.  Here the bus strobe is started by /EASI which selects the chip.  /IOWR or /IORD are used to time the data into or out of the RAM, whilst we just have a few more address and data lines than before.

The timing here is roughly the same as the IOC space cycle, except the cycle is shorter.  The Expansion Card specification gives all the specific timing information, and it's recommended that you study this if interfacing a device into EASI space.

A feature of EASI space is its ability to stretch bus cycles.  If you have a peripheral that sometimes need to wait a little longer for the data it is asked to provide, the peripheral can stretch the bus cycle for up to 2 microseconds by asserting the Ready signal (otherwise known as IOCHRDY on the PC's ISA bus).  In this way the computer will just wait until the Ready signal has been deasserted before the data is transferred off the podule.  Similarly an attempt to write to a slow device can be stalled until the device has completed using this method.

Another new signal provided by EASI mode is /BW.  When low this indicates a byte wide transfer is taking place, whilst when high a word wide transfer is occuring.  In this way we can, for example, route byte writes to a 32 bit wide memory on our podule.  Using /BW and LA[0] and LA[1] (which tell us which byte in the word is being written to), we can arrange that only one byte is latched into the memory.

EASI speeds

I mentioned that EASI space provides different speeds of access.  If we accessed them as IOC space does, with one address area for each speed, it would mean an awful lot of address space!  Instead IOMD controls the timing which can be set using a register - RISC OS provides the Podule_SetSpeed SWI to control this.

IOMD provides four speeds:  A (slowest) to D (fastest).  In fact only speeds A and C can be used in EASI space on IOMD hardware, but the interface allows for extra speeds.  In particular, Iyonix supplies another four speeds, E to H, which are twice as fast as A to D.  As a guide, the /EASI strobe width for speed A is 427ns, and 175ns for speed C.

The speed can be set using Podule_SetSpeed (&4028E) as follows:

On entry:
R0 = New speed required:
  0 = no change, 1=A, 2=B etc to 8=H
R3 = ROM section (ie podule slot number)

On exit
R0 = Previous speed setting
R3 preserved

This only works on RISC OS 3.5 or later machines, since only they have the hardware to do this.  HAL26 provides it for RISC OS 3.1, but does nothing.

DEBI

The DMA signals that DEBI adds to the podule bus are the same as those supplied by the ISA bus.  As such there is plenty of documentation available both on the Internet and on paper about the workings of the ISA bus, so I won't go into too much detail on how they work.  However I will give a quick overview.  DMA is described in Appendix B of the podule specification, and is basically a means to transfer data to and from memory without the CPU being involved.  On traditional operating systems this means that the CPU can get on with something else while the DMA transfer happens.  Under RISC OS opportunities for this are limited since it's not easy for a device driver to pass control to other programs without returning valid data first.  However DMA has the advantage that it's sometimes quicker over the slow podule bus.

The main DMA signals are DRQ, /DACK and TC.  First the DMA controller in the IOMD needs to be programmed to tell it whether to read or write and where in memory we want to use.  This is done using the DMA_QueueTransfer SWI (&46142) - but first we need to register the DMA channel we want to use using DMA_RegisterChannel (&46140) - see the PRMs for more details on these.  We also need to provide some routines to control DMA whilst a transfer is in progress.

Once the DMA controller know what's going to happen, our device driver can now talk to the hardware on our podule to cause a DMA transfer.  So for an IDE drive we might issue a READ DMA command.  When this is done, the IDE interface will place some data on its bus and assert DRQ (DMA request) to signify some data being available.  When the data is latched into memory the IOMD will assert /DACK to acknowledge the correct data transfer.  DRQ is then deasserted, and thus /DACK is deasserted in response.  Another DRQ assertion signifies another word to be transmitted.  For a write the same process happens, except the drive 'pulls' data by asserting DRQ.  The IOMD provides data on the podule bus which may be latched in on the edge of /DACK supplied by IOMD.

This can be seen in figure 4, and is a standard 4-phase handshake protocol.  It is also possible for a podule to keep DRQ asserted if it has more than one DMA cycle to perform.

The other signal of interest is TC, or Terminal Count.  When high, this informs the podule that the last DMA cycle is taking place.  This might be useful if a podule has hardware that can terminate a DMA transfer early if only half the data is required.  It isn't often used.

Let's look at a simple example.  The Cirrus Logic CS8900 ethernet controller is designed to fit the ISA bus, so provides three sets of DMA pins, DMARQ0 to DMARQ2 and /DMACK0 to /DMACK2.  This is because ISA shares its DMA channels (and interrupts) across all possible slots, so it's necessary to select in software or by jumpers which DMA a card is to use.  We'll just use DMARQ0 and /DMACK0 and ignore the others.

So to provide DMA, all we need do is connect DMARQ0 to podule bus DRQ and /DMACK0 to podule bus /DACK.  That's it.  When reading from the chip, the CS8900 will turn on its data bus buffers and output data when requested to by DRQ.  It will also latch in data when we do a write.

Life may be a little more complicated though.  If we have a data bus buffer between the podule bus and our chip, we need to enable it at the right time.  PR/W tells us in which direction the transfer is happening, and /DACK signifies a DMA transfer is in progress.   So this part of our circuit might be as in figure 5.


So far we've covered most of the important things to know about the standard Archimedes and Risc PC podule bus.  Next time we'll round off with a look at the other podule-like interfaces to have appeared on Acorn machines over the years.
