PC Cards

What is the format for kCISMagicTuple (0xA0)? Is kCISTupleVersion2 (0x40) used for anything beyond information or is it required as well?

Here's the definition of the Magic specific tuple.

The Magic number and version should be set from the constants found below.

For a pager card the card type should be kTypeIOCard.

The clusterOffset should be the offset from the start of common memory space of the start of the metacluster. That should be the start of the RAM card image plus the offset found within the RAM card image's Magic Cap tuple.

The unique ID needs to be just that. Currently, there's no way to ensure uniqueness, but for now just use the unique ID found in the RAM card file's Magic Cap tuple.

The modification date and time and the crc should be set to zero.

kCISTupleVersion2 is present only for the edification of other systems. Too bad no other system pays any attention to it.

The QuadChar('w','x','y','z') macro is equivelent to 'wxyz'.

typedef struct MagicCapTuple {
   ulong	magicNumber;
   ulong	version;
   ulong	cardType;
   ulong	clusterOffset;
   ulong	uniqueID;
   ulong 	modificationDate;
   ulong 	modificationTime;
   ulong	crc;
} MagicCapTuple;

#define kMagicCapTupleVersion     0x00010001
#define kMagicCapTupleMagicNumber QuadChar('G','M','M','C')

#define kTypeNoCardInSlot         QuadChar('N','U','L','L')
#define kTypeForeignRAMCard       QuadChar('F','O','R','N')
#define kTypeDamagedRAMCard       QuadChar('D','A','M','G')
#define kTypeUnformattedRAMCard   QuadChar('B','L','N','K')
#define kTypeExtendedRAMCard      QuadChar('X','R','A','M')
#define kTypeFormattedRAMCard     QuadChar('R','A','M','C')
#define kTypeROMCard              QuadChar('J','R','O','M')
#define kTypeROMWithStorage       QuadChar('R','O','M','+')
#define kTypeSelfHostedFlashCard  QuadChar('F','S','R','V')
#define kTypeFlashCard            QuadChar('F','L','S','H')
#define kTypeIOCard               QuadChar('I','O','C','D')

Whenever I download a package to my communicator using Telebug, the name of the PC card gets changed to "Untitled". How do I change the card's name?

ObjectMaker does not provide a way to name a card; it is hard-coded to name the PC card "Untitled".

As a work around, you can do this:

Build your package for a ROM Card and download it to the device.

Once you've tested it and have verified that it works properly, do this:

     # "touch" the modification date to force a rebuild
SetFile -m . Objects.Def
     # make sure ObjectMaker leaves room for the card name
     # THIS STEP IS VERY IMPORTANT
Set CardTypeOptions '-cardsize=262144' ; Export CardTypeOptions
     # use BuildPackage instead of Command B
BuildPackage

At this point, the RC file contains the downloadable ROM card image. But this has the name of the PC Card set to "Untitled". (Here comes the ugly part).

Using your trusty file editor (FEdit, MacTools, etc...) look at the end of the RC file. You should see something like this:

6AB0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
6AC0: 0000 0009 0000 001C 0855 6E74 6974 6C65 .........Untitle
6AD0: 6400 0000 0000 0048 FFFF 0080 0000 0000 d......HŘŘ.Ą....
6AE0: 0000 0030 0000 0008 8000 69D8 0000 0000 ...0....Ą.iŻ....
6AF0: 8000 0044 8000 0060 8000 0074 8000 0088 Ą..DĄ..`Ą..tĄ..Ă
6B00: 8000 009C 8000 29C0 8000 51CC 8000 298C Ą..ţĄ.)ËĄ.QíĄ.)Ô
6B10: 8000 6A20 0000 0008 8000 6A04 8003 2AC0 Ą.j.....Ą.j.Ą.*Ë
6B20: 0000 0000 0000 0000                     ........

You can change the name of the PC Card object here, but it MUST BE EXACTLY NINE characters long (ugh). Just edit the bytes (leaving the 0x08 at the beginning; that's the Pascal length byte) to be the name of your card. Use space characters to pad it out to nine characters if it's shorter.

Choose "Resend RAMCard" from the "Utils" menu. It'll download that changed image.

Can standard type II PCMCIA cards be used in a Magic Cap communicator, or are custom PC cards required?

There are two ways to support PC cards on Magic Cap communicators. The first method requires a custom "Magic Cap saavy" PC card. Part of the PC card looks like a RAM or ROM card to Magic Cap, and this area would contain a Magic Cap package that knows how to interact with the rest of the PC card. This solution is entirely self contained, and allows a PC card to bootstrap itself. The disadvantage of this method is that the cards are non-standard.

However, you can also have the package separate from the PC card. The package would install a CardServer subclass into iCardServers. When a PC card is inserted, Magic Cap calls CanHandleCard() on each CardServer subclass in this list. If your subclass determines that it can talk with the inserted PC card, you return an instance of your CardServer subclass. Magic Cap will then make all CardServer calls on this instance. This solution is good because you can use off the shelf PC cards with Magic Cap communicators. The disadvantage to this method is that the user must manually install a Magic Cap package on their communicator before they can use the PC card.