Last time we examined how the Podule Manager identifies podules and loads any
software that might be on them.  As well as routines for reading, writing and
deciphering podule ROMs, it also provides a degree of hardware abstraction. 
Up till now, we've been assuming things about where the podule bus lives in
the machine's address space.  This was constant up until the release of
Iyonix, which caused some radical changes.  Now everything has moved around,
and we need some way to work uniformly on different hardware.

Podule_ReadInfo
---------------
The SWI Podule_ReadInfo performs much of this work.  It is used to read
everything a podule driver might need to know from the operating system,
rather than assuming things about the hardware.  It is called as follows:

On entry:
R0 = bitmask of required results (see table 1)
R1 = pointer to buffer to store results
R2 = length of buffer
R3 = ROM section (in other words the podule number - 8 being a Risc PC
network slot)

On exit:
R2 = length of results in bytes

The bitmask has a bit set for each value required, and for each set bit a
word is stored in the buffer.  Table 1 shows all the results that can be
returned with their bit numbers.  For example, a mask of %110 would store the
synchronous hardware base at address R1+0 and the address of its CMOS RAM
bytes at R1+4.

Much of this may not make sense at this stage, but we shall meet it when we
cover interrupts and the Risc PC's extensions.  In the meantime we'll cover a
few options:

Synchronous address:  This is what it says on the tin - the base of
synchronous space for this podule.  Other types of IOC space accesses can be
derived from it by changing bits 19 and 20 - see table 2.

CMOS address and CMOS size:  Each podule slot has a number of bytes reserved
for it in CMOS RAM.  These determine the address and length of these bytes -
the address is ready to pass to OS_Byte 161 and 162.  Note that bytes are
associated with the *slot*, rather than the podule itself - which explains
why moving podules between slots loses their configuration.

Extension ROM/network ROM base address:  Extension ROMs are additional ROMs
containing software to supplement the OS that may be loaded into the system,
but are not located on podules.  An example is the A4, which contains its
battery manager on a separate ROM from the OS.  Such ROMs are formatted as
podule ROMs, and are loaded by the podule manager in the normal way, except
that they live in the memory map separate from the podule bus - this call
returns their address.  The Risc PC network card also contains a ROM treated
in a similar way.

Expansion card ID:  This is the simple expansion card ID (EcID), normally 0
if a podule ROM is fitted.

Expansion card product type:  This is the hex type number stored in an
extended EcID.

Combined hardware address:  The synchronous base of the hardware logically
ORed with the CMOS address in one word.  This is of little use as the
components are available separately.

Pointer to description:  The description field from the podule ROM is read
into a buffer and a pointer to it is returned.

Ethernet address:  Reads the 48 bit MAC address of a podule.  It only works
if this address is stored in the podule ROM: if, for example, the address is
derived from the machine's unique ID, then no value is found.


Podule_ReadInfo is not supported under RISC OS 3.1.  To rectify this I have
written the HAL26 module which provides it (with more, as we shall see
later).  This module can be found on the monthly disc, or at
http://www.markettos.org.uk/riscos/podules/


IOC spaces
----------

Now back to some hardware.  We mentioned a while ago that the IOC supports
different speeds of access, namely fast, medium, slow and synchronous.  I've
been carefully skirting around this subject with mentions of the
different speeds, but now is the time to go into it in depth.

Fast, medium and slow modes are fairly self-explanatory.  By choosing which
area of memory to access, you choose the I/O controller's (be it IOC, IOMD,
ARM7500 or Iyonix's FPGA) cycle time.  The time the /PS strobe is low can be
assumed to be a good metric of this, and is 625ns, 500ns and 375ns for slow,
medium and fast modes respectively.  This roughly equates to 1.6MHz, 2MHz and
2.66MHz cycle times although it isn't that simple because the bus isn't tied
directly to the CPU clock and there are additional setup times.  Over the
traditional pre-Risc PC podule bus, one 8 or 16 bit transfer can be made in
each cycle.  Also these timings aren't guaranteed because cycles may be
stretched by the MEMC for some nanoseconds to perform operations like memory
refresh or video DMA.  There is nothing the podule hardware or programmer can
do about this (short of turning such operations off, which would be
detrimental to the user's pleasure by causing the machine to crash), but the
hardware must be able to cope with cycles being longer than specified.  The
majority of chips made since about 1990 have been faster than the podule bus
in IOC mode, so most podules use fast mode.

Synchronous mode is really designed to drive 68xx and 65xx series chips, such
as those used in the original BBC.  As such the timings are tied relative to
the 2MHz clock on the podule bus, CLK2.  This means it can only interface to
newer 68xx/65xx chips capable of running at 2MHz - many of those in the BBC
were rated at 1MHz.  Other than these restrictions it is similar to slow
mode, with the difference that data is latch on the falling edge of CLK2
instead of the rising edge of /PS.  If you wish to use synchronous mode other
than simply interfacing to such chips I recommend you study the timing
diagrams in the podule specification, if not a simple User Port podule
using the 6522 chip is presented in figure 1.

MEMC space
----------

The timing provided by the IOC is all very well, but what if you have a
device where the cycle time needs to vary - for example a disc controller,
where some bytes may come off the disc quicker than others due to different
packing rates of data across the disc surface?  The MEMC allows the podule
itself to control its timing, enabling it to stretch or compress cycles as it
requires, through use of a handshaking protocol.

Whilst this seems like a great idea, it does require more work on the part of
the podule.  It requires that the podule manually latch data it presents to
the podule bus onto the I/O bus data latches using the /BL signal.  It also
means that the podule must itself manage cycle stretching for video DMA or
memory refresh.

MEMC space introduces a number of new signals:
/IORQ	pin 24c		I/O request
/IOGT	pin 23c 	I/O grant (open drain)
/BL	pin 25c		Bus latch (open drain) - high for buffers transparent
/MS	pin  6c 	MEMC space select

The podule specification should be consulted for exact timings, but briefly
what happens is this:

/MS is asserted for the duration of the cycle on the podule to be accessed.  /PS is kept inactive.

When /MS is asserted, /IORQ is asserted also.  This signals to the podule that a transfer is in progress.

If it is a write, /IORQ being asserted signifies that data is ready for
collection on the podule bus.  As soon as the podule notices this, it must
take /BL low for the duration of the cycle to keep the data steady on the I/O
bus.  The podule must make use of this data, and then assert /IOGT to reply
that the data is finished with.

If it is a read, /IORQ asserted means the podule must produce some data. 
Once it is stable on the podule bus, the podule must take /BL low to latch it
onto the I/O bus, then assert /IOGT.

It is possible that the cycle is stretched by DMA.  In this case /IORQ
becomes deasserted (goes high) before /IOGT is asserted.  /IOGT may still be
asserted at any time, but in the case of an interruption data to write must
be latched onto the I/O bus by the podule driving /BL low.  When /IORQ is low
again, the cycle may be terminated by the podule rising /IOGT, after which
the MEMC acknowledges by rising /IORQ.  When /IORQ goes high the podule may
deassert /BL.  Such stretching may last for up to 15 REF8M cycles, or
1875ns.


MEMC accesses can be used to produce cycle times as short as 250ns, and was
a favourite way to build fast podules for pre-Risc PC machines.  Other
cunning tricks using it include holding the machine up until data from a SCSI
controller was ready, saving an expensive wait in software.  With the advent
of the Risc PC with its faster podule bus, many of these tricks are
unnecessary.

IC bus
-------

The IIC or Inter IC bus is provided 'for free' on the podule bus.  This is
a simple two-wire bidirectional bus, originally designed by Philips for low
speed serial controls between chips intended for TVs (such as teletext,
tuning and audio functions).  It is now used by many other specialised chips
and microcontrollers for different applications.

It is implemented by most (but not all) RISC OS machines to
drive the real-time clock chip, but current RISC OS machines do not contain
an IC controller chip and so perform all transmission in software using two
pins on the IOC/IOMD.  As such the IIC module in RISC OS is quite limited in
what it can do, but more flexible third party implementations are available.

More details on the bus are available from Philips Semiconductors.  A common
use for the bus on a podule is to drive a serial EEPROM for
extra configuration options, or to talk to special IC driven chips such as
those on teletext cards.

Power supplies
--------------

Finally a short note on the power supplies available to the podule bus. 
The specification says that each podule can draw up to 1A from the +5V line,
10mA from -5V and 250mA from +12V.  Acorn recommends that podules run from
+5V only, since this is the only supply guaranteed to be available - indeed
the A3000 only provides this.  The A30x0/A4000 minipodule slot additionally
has its current consumption limited to 100mA.  Double width podules on
Archimedes machines may use the combined currents allocated for both podule
slots.

That's it for this time.  Next time we're going to dive into another
important topic: interrupts.
