PCMCIA/Gayle compatibility problems

[ncafferkey]

Recently, and also in the past, I've come across apparent compatibility problems with certain PC Cards in my A1200 that I've tried to write drivers for. These problems include:

- Data (buffer access) registers that won't move on to the next word after being read or written.
- Register sets that can't be accessed where I expect them to be in I/O space (in spite of lots of tweaking of PCMCIA config registers).
- Cards that lock up the Amiga when inserted.

Does anyone know why these effects may occur or potential work-arounds?

I can't 100% rule out that I'm just not programming the cards properly, but it's hard to be sure without an alternate card.resource-compatible PCMCIA interface to test against (maybe I could try a PowerBook running MorphOS).

[Bruce Abbott]

Originally Posted by ncafferkey

I've come across apparent compatibility problems with certain PC Cards in my A1200 that I've tried to write drivers for.

What does your A1200 have in it? Does it have the PCMCIA hardware reset fix? Are you running CardReset during startup?

Which cards are you having trouble with, and what problems(s) is each one having?

I can't 100% rule out that I'm just not programming the cards properly,

Show us your code.

it's hard to be sure without an alternate card.resource-compatible PCMCIA interface to test against (maybe I could try a PowerBook running MorphOS)

What you really need is source code showing how to set up the card. Linux driver sources may be useful.

Does anyone know why these effects may occur or potential work-arounds?

Register sets not appearing where they should might be because the card hasn't been properly initialized.

Other problms like address increment not working or cards locking up could be due to signal timing differences between the Amiga and PC controllers, voltage levels, or latent bugs. Back in the day I didn't investigate any of this (getting my CNET card going was enough for me), but now might be a time to address it.

[Toni Wilen]

There is some hardware problem with Amiga PCMCIA slots (AFAIK it wasn't based on final PCMCIA spec)

I did some m68k AROS PCMCIA stuff many years ago and noticed some CF cards in PCMCIA adapter simply refuse to configure. (Does not enable ATA registers in requested address space). My guess is that any write is ignored for some reason.

Lockup probably is caused by interrupt line being stuck in active state.

EDIT: I didn't find any workarounds.

[ncafferkey]

Thanks for the info guys.

My current troubles are with Xircom Ethernet cards, for which I'm writing a driver. I know my code is basically OK as two 100Mbps cards work apart from the data registers not "moving on" (which fortunately I can work around because there's another register to explicitly seek within the buffer). However, my 10Mbps card doesn't show its Ethernet registers.

BTW another problem some (non-Xircom) cards have that I didn't mention in my first post is that they don't even show their attribute memory.

I don't have the hardware fix on my A1200 060. I do run CardReset, but all these problems have been seen after a hot insertion in any case.

In theory, could some of these hardware quirks be fixed by analysing the signals on the PCMCIA pins and maybe applying fixes similar to the hardware reset fix? I know it's doubtful anyone would do it, but I'm curious :-)

BTW, is there any possibility of accessing PCMCIA I/O space with the copper/blitter? I was wondering if my driver could use that to read/write Ethernet frames instead of having the CPU locked up waiting for extremely slow Ethernet registers.

[coldacid]

Copper/Blitter is only for chip RAM, if I'm not mistaken, both source and destination. You won't be able to use it for PCMCIA I/O.

[patrik]

The data registers “moving on”, that is a card-internal counter increasing if you read or write the data port register of the card?

Could it be that the card must be in a certain state for this “moving on” to work?

[ncafferkey]

Originally Posted by patrik

The data registers “moving on”, that is a card-internal counter increasing if you read or write the data port register of the card?

Could it be that the card must be in a certain state for this “moving on” to work?

Quite possibly, but I've checked over and over again that I'm doing the same as the Linux and BSD drivers. So I'm wondering if there's some quirk with the A1200 that these registers can be read and written without "knowing" that it's happened.

[ncafferkey]

Originally Posted by coldacid

Copper/Blitter is only for chip RAM, if I'm not mistaken, both source and destination. You won't be able to use it for PCMCIA I/O.

I'm pretty sure I've read about them addressing other custom chips, and that the floppy driver uses them for track transfer.

[patrik]

Originally Posted by ncafferkey

Quite possibly, but I've checked over and over again that I'm doing the same as the Linux and BSD drivers. So I'm wondering if there's some quirk with the A1200 that these registers can be read and written without "knowing" that it's happened.

Could there be some PCMCIA system level code in BSD/Linux that initializes the card in a more generic sense (outside the specific driver), which perhaps card.resource does not?

[alexh]

Neil if any of this stuff is of any use to you I could mail it to you?

https://twitter.com/a1exh/status/1265927704467169280

Three PCMCIA FPGA devkits with documentation (make your own PCMCIA hardware). Lots of books. We used them when created the OXU950 chip (16-bit PCMCIA->USB host)

As well as what is in the picture is a PCMCIA debug card (it's a card you plug in-between the PCMCIA card and the Amiga which exposes all the PCMCIA pins for use with a logic analyser)

I don't have a PCMCIA Amiga here at the moment (I have an A600 in storage) or I would offer to help debug. (The current prices of A600/A1200 are too much just to pick one up.)

Originally Posted by ncafferkey

So I'm wondering if there's some quirk with the A1200 that these registers can be read and written without "knowing" that it's happened.

I've had situations here at work (not Amiga) where using the wrong access type (byte instead of word or dword) results in multiple reads/writes of the same address.

[hooverphonique]

Originally Posted by ncafferkey

I'm pretty sure I've read about them addressing other custom chips, and that the floppy driver uses them for track transfer.

That's true, but pcmcia stuff is not part of the "custom" chipset that makes an Amiga an Amiga.

[Bruce Abbott]

Originally Posted by ncafferkey

Thanks for the info guys.

My current troubles are with Xircom Ethernet cards, for which I'm writing a driver. I know my code is basically OK as two 100Mbps cards work apart from the data registers not "moving on" (which fortunately I can work around because there's another register to explicitly seek within the buffer). However, my 10Mbps card doesn't show its Ethernet registers.

Which Xircom cards do you have? I have a "CreditCard Ethernet-Modem 33.6" part number CEM33.

[Cyprian]

Originally Posted by ncafferkey

I'm pretty sure I've read about them addressing other custom chips, and that the floppy driver uses them for track transfer.

Copper can only write to the custom register.
Blitter has an access only to the chip-ram and yes it decodes floppy data (CRC) but they have be placed by the floppy DMA in the chip-ram first.

[ncafferkey]

Originally Posted by alexh

Neil if any of this stuff is of any use to you I could mail it to you?

https://twitter.com/a1exh/status/1265927704467169280

Three PCMCIA FPGA devkits with documentation (make your own PCMCIA hardware). Lots of books. We used them when created the OXU950 chip (16-bit PCMCIA->USB host)

As well as what is in the picture is a PCMCIA debug card (it's a card you plug in-between the PCMCIA card and the Amiga which exposes all the PCMCIA pins for use with a logic analyser)

Thanks Alex, but I fear the hardware would go to waste as I don't have much electronics knowledge. An exception may be the CardBus book, which I could potentially see myself using in relation to AROS or MorphOS (I actually have the matching PCMCIA book already). But if you want to keep the kit together that's fine.

I don't have a PCMCIA Amiga here at the moment (I have an A600 in storage) or I would offer to help debug. (The current prices of A600/A1200 are too much just to pick one up.)

And to think I once gave away an A600 because it had a wobbly keyboard

I've had situations here at work (not Amiga) where using the wrong access type (byte instead of word or dword) results in multiple reads/writes of the same address.

Yes, I was thinking about that too. I try to do what I can to avoid such problems by trying the separate memory range for odd I/O addresses when I run into problems.

[ncafferkey]

Originally Posted by Bruce Abbott

Which Xircom cards do you have? I have a "CreditCard Ethernet-Modem 33.6" part number CEM33.

PS-CE2-10, CE3B-100BTX, CE3-10/100

The CEM33 should be compatible with my driver in theory. It think it's similar to the PS-CE2-10, which doesn't show its registers for me. If you'd like to try a beta version let me know.

[Bruce Abbott]

Originally Posted by ncafferkey

PS-CE2-10, CE3B-100BTX, CE3-10/100

The CEM33 should be compatible with my driver in theory. It think it's similar to the PS-CE2-10, which doesn't show its registers for me.

The CEM33 and CE2 are both supported in the Linux driver, so I think they could be compatible.

If you'd like to try a beta version let me know.

Yes, I am interested.

[ncafferkey]

Originally Posted by Bruce Abbott

The CEM33 and CE2 are both supported in the Linux driver, so I think they could be compatible.

Yes, I am interested.

Sorry for the delay in responding. I've been tidying up my driver to make a suitable beta version. However, I'm now thinking that it might not be very useful: it's unlikely to work for you as I haven't been able to test it on that generation of hardware due to the problems with register visibility already discussed. What might be better is if you could poke the appropriate config value into the card and check if the registers are visible. Otherwise I could send a version of the driver that just does that much and then exits, so that register visibility can be checked without causing a crash (hopefully).


I'm also trying to source another CE2 generation card on eBay. I got one last week but it was DOA.

[Bruce Abbott]

Originally Posted by ncafferkey

I could send a version of the driver that just does that much and then exits, so that register visibility can be checked without causing a crash (hopefully).

I can work with that.