IIC...
...via the parallel port

Logo

IMPORTANT: This requires your computer to have a fully wired parallel port.
If you are using an A3xx/A4xx/A3000/A540/R1x0 machine, you will not be able to do this. Read this to find out why, along with some suggestions.
The machines believed to be compatible with this are: A5000/A4/A30x0/A4000/RiscPC/Bush IBX/Mico.
It is not (currently) known if the Omega is compatible.
It is expected that the Iyonix will be incompatible due to the lack of a parallel port, and also (possibly?) because of a lack of the IOC/IOMD 2MHz timer used to time the 5µS delays.

 

 

Well, since I had a 'parallel' IIC lead available (for the Teletext for DOS project), I thought that maybe it would be a useful thing for people who can handle a soldering iron (or know someone who can) without resorting to fiddling around inside their computer and hooking things to the podule bus.

Hence, the PtrIIC module.

It provides a SWI "PtrIIC_Control" which functions in exactly the same way as IIC_Control, and you've also got a patch program that will load a module (the Teletext module, by default) and patch it to use PtrIIC instead of IIC.

Other SWIs are provided for lower-level access to the IIC bus - only use these if you know what you're doing.

 

Refer to the details of Teletext for DOS if you want to see what the parallel lead involves... it's a parallel lead, a compatible lead for your teletext receiver, and two signal diodes...

 

I can't show you a screenshot of PtrIIC in operation as it looks exactly like Teletext operating normally!
This module was written over the past two days, and was implemented entirely in assembler so it does all that stuff and still only consumes (an enormous) 1476 bytes!
I'm pleased with this module, if I say so myself. :-)

While we're at it, I'll add that for the most part I listened to stuff I've taped from MTV and Viva - "Ice Queen" (Within Temptation), "Killerbee" (Itchycoo), several songs from Linkin' Park, "J'en ai marre" (Alizée), and the amazing "White Flag" (Dido). Well, if-and-when I get myself a job here, I know what'll be on my CD list.

 


Software status:

  Software name        : PtrIIC
  Latest version       : 0.04

  Archive size         : 24584 bytes
  Classification       : Freeware
  Registration cost    : None

  RISC OS 2 compatible : Unknown
  RISC OS 3 compatible : Yes
  WIMP 3.98 compatible : Yes
  RISC OS 4 compatible : Untested, should work okay
  32bit RISC OS        : Yes

  Written in           : Assembler
  Libraries            : n/a

                         YOU'LL NEED TO BUILD YOUR OWN PARALLEL LEAD
                         IN ORDER TO USE THIS SOFTWARE... INSTRUCTIONS
                         INCLUDED WITHIN THE ARCHIVE.

 


PtrIIC download
ptriic004.zip (24K) Version 0.04
2003/11/26
The PtrIIC module, v0.04.

 


Here follows a copy of the implementation notes that may be of interest to programmers. This information is also included in the !Help file within the archive...

SWIs

The SWI chunk used by PtrIIC is &56DC0. It has been OFFICIALLY allocated to
me (on 2003/10/15).


   PtrIIC_Control                                              &56DC0

     Entry:
       R0 = Device address (bit 0 set to read, clear to write)
       R1 = Pointer to block
       R2 = Size of block (bytes)

     Exit:
       All registers preserved.
       Processor flags MAY be corrupted.

     This reads from or writes to the specified IIC device connected to the
     appropriate parallel hardware. This is primarily intended for the
     connection of a teletext receiver, however any IIC compatible device
     should work.
     THIS IS A COMPATIBLE REPLACEMENT FOR "IIC_Control" IF YOU WISH TO USE
     THIS PARALLEL SYSTEM INSTEAD.

     The most likely error is "No acknowledge from IIC device" (&20300).



The following SWI calls allow a more direct access to the IIC bus. In all
cases, registers not mentioned are preserved, and processor flags may be
corrupted.
For further information, please refer to the Philips IIC specification and
also to the datasheet for the IIC device in question.
Important: DO NOT USE THESE CALLS UNLESS YOU KNOW WHAT YOU'RE DOING.

   PtrIIC_Start                                                &56DC1
     Entry:
       -
     Exit:
       -
     Notes:
       You MUST call this before first PtrIIC_ReadByte or PtrIIC_WriteByte.


   PtrIIC_ReadByte                                             &56DC2
     Entry:
       R0 = '1' if this byte should be acknowledged, or '0' if not.
     Exit:
       R0 = Byte read.
     Notes:
       No error is returned if this fails, as always you need to write the
       device ID first, and if that fails to Ack the transfer should be
       aborted. Expect R0 to be 255 if read failed.


   PtrIIC_WriteByte                                            &56DC3
     Entry:
       R0 = The byte to send.
     Exit:
       R0 = '1' if acknowledged, else '0'.
     Notes:
       This does not raise an error or set V on NAK, refer to value of R0.


   PtrIIC_Stop                                                 &56DC4
     Entry:
       -
     Exit:
       -
     Notes:
       You MUST call this to finish the transfer.



Implementation notes

This IIC implementation does not support arbitration, clock stretching (by
slave devices), nor the 400kb/s 'fast' mode.
You cannot 'slave', nor can you be promiscuous.
It is expected that we are acting as the only 'master'.


IMPORTANT: Timer1 is utilised for the correct delays between bits, so you
=========  should NOT use this software with other software that expects to
           exclusively 'own' Timer1.
           The two programs that I'm aware of is:
             * Acorn's TimeCode module
             * Niall Douglas' Wimp2 pre-emption module

           The Timer1 is used with interrupts disabled, so will co-exist with
           other software that uses Timer1 only as-is-needed.
           Because of the lack of 'claimable' timers, software using Timer1
           should NOT assume it is the only possible owner.
           PtrIIC sets Timer1 to a 'known' state prior to use, so it does not
           need anything preserved. This state is &FFFF, and upon exit it'll
           be &FFEF (ie, 10 ticks or 5 microseconds).



Errors

The error block used by PtrIIC is &81B500. It has been OFFICIALLY allocated
to me (on 2003/10/15).


 &81B500  Incorrect parallel driver (XParallel_HardwareAddress failed)

          This is self-explanatory. If the SWI works, so will this module.
          (can't see why it'd fail (asides RISC OS 2), but you never know...)


 &81B501  Invalid PtrIIC SWI

          Only &16FC0 - &16FC4 are valid SWIs.


 &81B502  IIC buffer is in "page zero"

          The IIC buffer must reside in application workspace, the module
          area, a dynamic area, or any place that isn't &0000-&7FFF.


 &81B503  You must send/receive at least one byte

          On entry to SWI PtrIIC_Control, R2 must be greater than zero.


 &81B504  IIC bus error: SCL stuck low

          The clock line is stuck active LOW. This is usually a hardware
          error, but may be because a printer is connected.


 &81B505  IIC bus error: SDA stuck low (is a printer connected?)

          The data line is stuck active LOW. This is usually because a
          printer is connected, but may be a hardware error.


 &81B506  IIC bus error: SCL and SDA are stuck low (is a printer connected?)

          The clock and data lines are stuck active LOW. This is usually
          because a printer is connected, but may be a hardware error.


 &20300  No acknowledge from IIC device

          Check the leads are properly wired, connected, and the IIC device
          is switched on.
          NOTE: This is the same error number as is generated by the IIC
                module, and it is used to ensure compatibility with software
                expecting the IIC module error.
                You MAY receive one of the above errors instead, in case of
                hardware anomolies (like a line stuck low).



32 bit

This module should be fully 32-bit compatible.

It has been hand-coded in assembler.

 

Hacks (v0.04)

By altering the parameters to the Parallel_Op calls, you can change which pins are used for the interface. If you don't like my design, feel free to implement your own.

It is possible to run the I2C faster. Some devices will cope, some won't. Experimentation will tell...
In the module, at offset +&1FC, is the instruction STMFD R13!, {R0-R2,R14}. If you replace this with MOV PC,R14 then you will disable the timer system - if your I2C device still works, you can...

It's up to you. :-)

 


Return to Teletext software index


Copyright © 2004 Richard Murray