Re: RamFAST partition table different from Mac? Can't access drives under Linux.

["Jay Krell" <jay.krell@cornell.edu>]

Scott, I don't know about the RamFast, but Apple uses just the one
partitioning format across the Apple II and Mac. It's simple, and documented
at
http://developer.apple.com/techpubs/mac/Devices/Devices-121.html
Just look at the raw drive and decide for yourself if it follows the format.
(I wonder how easy it is to step through the Linux support in the debugger
to see what it thinks of the data..)

There's this
TYPE Block0 = PACKED RECORD
   sbSig:         Integer;    {device signature}
   sbBlkSize:     Integer;    {block size of the device}
   sbBlkCount:    LongInt;    {number of blocks on the device}
   sbDevType:     Integer;    {reserved}   sbDevId:       Integer;
{reserved}
   sbData:        LongInt;    {reserved}
   sbDrvrCount:   Integer;    {number of driver descriptor entries}
   ddBlock:       LongInt;    {first driver's starting block}
   ddSize:        Integer;    {size of the driver, in 512-byte blocks}
   ddType:        Integer;    {operating system type (MacOS = 1)}
   ddPad:         ARRAY [0..242] OF Integer; {additional drivers, if any}
END;

Then an array of (one 512 byte record per block, starting at block 1):
TYPE Partition = RECORD
   pmSig:         Integer;       {partition signature}
   pmSigPad:      Integer;       {reserved}
   pmMapBlkCnt:   LongInt;       {number of blocks in partition map}
   pmPyPartStart: LongInt;       {first physical block of partition}
   pmPartBlkCnt:  LongInt;       {number of blocks in partition}
   pmPartName:    PACKED ARRAY [0..31] OF Char; {partition name}
   pmParType:     PACKED ARRAY [0..31] OF Char; {partition type}
   pmLgDataStart: LongInt;       {first logical block of data area}
   pmDataCnt:     LongInt;       {number of blocks in data area}
   pmPartStatus:  LongInt;       {partition status information}
   pmLgBootStart: LongInt;       {first logical block of boot code}
   pmBootSize:    LongInt;       {size of boot code, in bytes}
   pmBootAddr:    LongInt;       {boot code load address}
   pmBootAddr2:   LongInt;       {reserved}
   pmBootEntry:   LongInt;       {boot code entry point}
   pmBootEntry2:  LongInt;       {reserved}
   pmBootCksum:   LongInt;       {boot code checksum}
   pmProcessor:   PACKED ARRAY [0..15] OF Char; {processor type}
   pmPad:         ARRAY [0..187] OF Integer;    {reserved}
END;

// block zero and the partition map starting at block one.
const unsigned kAppleBlock0Signature = 0x4552; // 'ER' ?
const unsigned kApplePartionMapSignature = 0x504D; // 'PM'

 - Jay


Scott Alfter wrote in message ...
>Recent 2.1.x versions of the Linux kernel have had an option by which they
>are
>supposed to be able to make sense of the partition table format used by the
>Macintosh.  They also have some degree of support for HFS.  I got to
>thinking that hanging my IIGS's hard drives off of the end of my Linux
box's
>SCSI chain, combined with these new capabilities, might allow a faster way
>to get files over to my GS than going through the serial port.
>
>I made sure that the GS's SCSI IDs (two 40-meg hard drives (one Conner
>and one Quantum) and an Archive Viper 60S tape drive) didn't conflict with
>the Linux box's SCSI IDs (for an internal Zip drive, an HP ScanJet 4p, and
>the Adaptec AVA-1502 that runs the show on that machine)...had to open the
>HD case for the first time in a few years to do that.  I unplugged the SCSI
>cable from the GS and moved it to the scanner (turned off its internal
>termination, of course).  When the Linux box booted up, it saw all five
>devices just fine...the GS's hard drives appeared as /dev/sda and /dev/sdb,
>the tape drive was /dev/st0, the scanner was /dev/sg0, and the Zip was
>/dev/sdc.  When I checked the partition table on the hard drives with
fdisk,
>though, nothing showed up.  /dev/sda should have shown two partitions (both
>ProDOS, so they might've appeared as "unknown") and /dev/sdb should have
>shown two partitions (one ProDOS, one HFS).  Hex dumps of the two drives
>showed normal-looking data within the space of each partition.
>
>First, I was under the impression that the Apple II uses the same type of
>partition table as the Mac.  I think I've heard of people taking hard
>drives, Zip disks, and such that were used with a Mac and being able to
just
>plug them into a IIGS and read the data off of them by way of the HFS FST.
>Is this true?
>
>The $64k question: assuming that the Apple II and Mac use the same
partition
>table format, does the RamFAST store its partition data in a different
>format
>than Apple's products?  I don't remember having to back up and restore
>everything back when I upgraded from an Apple DMA SCSI card to a RamFAST,
so
>that would seem to indicate some degree of commonality.
>
>Might there be a slight difference between types that would cause Linux to
>ignore the partition information on my GS's hard drives?  The code that's
>supposed to deal with Mac partitions is in drivers/block/genhd.c; the
kernel
>option to include the capability is CONFIG_MAC_PARTITION, which is what
>you'd want to find in genhd.c.  I don't have much of an idea what
>partition-table data would look like on either system.  Might the fix be as
>simple as a few more lines of code added to the Linux kernel to pick up on
>some slightly different identifying information, or is more needed than
>that?  Is what I'm asking even feasible?  SCSI beats serial any
>day...besides, possibly adding ProDOS filesystem support to Linux might be
>kinda neat. :-)
>
>--
>|   _/_
>|  / v \
>| (IIGS(  Scott Alfter (remove "KILLSPAMMERSNOW" to reply)
>|  \_^_/  http://people.delphi.com/salfter
>
>
>