home *** CD-ROM | disk | FTP | other *** search
-
- PC-CARDs and the Amiga
-
- For those of you who might want to write drivers for PC-CARDs, here are
- some things I have found out about them.
-
- Most cards are designed to be set up to look like an ISA bus card, which is
- what the peecee needs for software compatibility.
-
- Since PCMCIA is quite different from ISA, the peecee has a controller
- chip (PCIC) which can be programmed to translate from one bus to the other.
- Using the PCIC, the PCMCIA memory can be mapped into the I/O and memory
- space expected by an ISA card. Also the INT line is routed to one the ISA
- interrupts. Once this setup has been done, the card would be accessed as if
- it were a standard ISA bus card.
-
- Since the Amiga does not have a PCIC, we can access the memory and I/O
- space directly. The single IRQ is handled for us by card.resource, we
- merely have to provide a routine to run when the interrupt occurs.
- It may be necessary to access odd I/O register locations at a different
- address range from the even registers. Apparently this allows the card
- to respond to byte accesses. A typical Amiga memory map for PCMCIA looks
- like this:-
-
- $600000 - $9fffff RAM (may be a mirror of attribute memory for I/O cards)
- $a00000 - $a1ffff attribute memory
- $a20000 - $a2ffff I/O space (16bit and even 8bit registers)
- $a30000 - $a3ffff I/O space (odd 8bit registers)
-
- If the PC-Card's registers were at the ISA I/O addresses of $0300 and $0301,
- 8bit access would appear in the Amiga at locations $a200300 ($0300) and
- $a300300 ($0301). For 16bit access, both bytes would appear at $a200300/1.
- Note that the Amiga PCMCIA slot has its data bus wires swapped to account
- for INTEL byte order.
-
- In order to enable I/O access, the card may need to be programmed by first
- writing to the Card Configuration Register in attribute memory. The location
- of this register can be determined by examining the CCR tuple, however the
- value to write is card specific.
-
- Determining this magic number can be a tricky job, because usually the
- manufacturer is not interested in telling anyone what it is. Therefore
- some sleuthing will probably be necessary. I have found some useful clues
- by looking at FreeBSD and Linux source code, which can be downloaded from
- the Internet. However this may not be enough, so hacking into the peecee
- driver supplied with a PC-Card might be the ultimate answer.
-
- Once you have gathered enough infomation on the card's hardware features,
- you will want to write a program to control it. This will involve use of
- card.resource functions, so it is a good idea to read the docs on this
- (available on the Amiga Developer CD). At a minimum, you will need to call
- the functions OwnCard (to set up the interrupt) and CardMiscControl (to
- enable I/O addressing). Other functions regarding Tuple parsing and Card
- Memory Map etc. are not really necessary, as this information can be hard-
- coded into your program.
-
-
- The case of the mysterious missing interrupts
-
- The Cnet card generates a standard level-sensitive interrupt. However Gayle
- (the custom chip that controls the PCMCIA port) responds to interrupts on
- negative and positive edges only. Since the card.resource resets Gayle's
- interrupt latch _after_ the status interrupt routine finishes, there is a
- small but fatal period of time where an interrupt could be missed. The
- result is that the PCMCIA card could hold its INT line down expecting
- service, but Gayle ignores it because the negative transition occurred
- before her interrupt latch got reset.
-
- Commodore's recommended workaround for this is to add another PORTS
- interrupt server, whose sole job is to make sure that card interrupts
- are not enabled until after the status change interrupt has completed
- (and the card.resource has reset the Gayle interrupt latch). This ensures
- that the next downwards transition on the PCMCIA INT line gets detected.
-
- For V39 of card.resource a new method was provided, where by setting a flag
- 'CARDB_POSTSTATUS' your status interrupt would be called twice, the second
- time would occur after Gayle had been reset. Unfortantely V39 did not make
- it into the WB3.0 ROMS, so this is not an option for most A1200s and A600s.
-
- Being a lazy programmer, I could not be bothered writing conditional
- code for different OS versions. I merely traced through the ROM to
- find how the Gayle interrupts were reset, and included this in my
- device code. Of course this is a 'hack' which may break if new PCMCIA
- hardware is developed in future Amigas.
-
-
-
- Accton EN2216
-
- I was recently loaned one of these cards, with the intention of modifying
- my driver to suit it. Imagine my suprise when I plugged the card in and
- it worked with my original driver!
-
- Actually the Accton is not quite the same as the CNet card. Firstly its
- ethernet hardware addresses are in a different range, so I had to modify
- my code a bit to accept it rather than dropping back to the default value.
- I also suspect that my I/O enable byte is wrong for the Accton, however
- this does not matter because the Accton card puts its registers at all
- possible I/O locations! (later versions of the CNet card also do this).
-
- The Accton card makes its hardware address available in attribute memory.
- This is an easier and more reliable place to get the address from, but
- to make use of it I would have to detect the type of card inserted. maybe
- in the next version I will pass tuples to find the card details, and then
- add specific code for each model.
-
-