The Best of Mecomp Multimedia 1/Mecomp-CD.iso/amiga/tools/misc/cnetdevice/devnotes

Text File | 1997-03-04 | 5KB | 107 lines

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.