Re: SCSI Card

[dempson@actrix.gen.nz (David Empson)]

Scott Alfter <salfter@salfter.dyndns.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In article <1ferves.o2k56i1ilmsdcN%dempson@actrix.gen.nz>,
> David Empson <dempson@actrix.gen.nz> wrote:
> >The original Apple SCSI card doesn't know about removable hard drives,
> >so if you swap cartridges in a Zip or SyQuest and don't reboot, it will
> >continue to use the partition map from the original cartridge,
> >potentially destroying the contents of the new cartridge.  It didn't
> >support CD-ROM drives until the revision C firmware.
> 
> I think the non-DMA Apple SCSI card I obtained recently is more than likely
> a rev. C card, but is there a way to tell for sure?  The FAQ says to check
> for particular Apple part numbers on the firmware EPROM, but mine has a
> plain white label on top (maybe it was upgraded from something older, or
> maybe the original label fell off and the plain label was stuck on to
> protect the EPROM's contents...one of the PALs is missing its label, so the
> latter is possible).

There is a call you can issue to the SmartPort firmware which returns
the firmware revision number (amongst other details), but it tricky to
set up, because the entry point needs to be calculated from a pointer
stored in the ROM.

The following should do the trick for an Apple SCSI card.  (The RamFast
doesn't support SmartPort, so this won't work.)

It doesn't matter whether you have an operating system lodaed, but there
could be some weird behaviour with the Apple High-Speed SCSI card if you
use this call without having booted ProDOS first, so the easiest
solution is to boot into ProDOS and launch BASIC.SYSTEM.

You must have a drive connected to the card and switched on.

I'm assuming your SCSI card is in slot 7.  If not, replace all
references to "C7" in the following instructions with "Cn", where 'n' is
the slot number.

I'm also going to show the prompt character, but don't type it.

]CALL -151
*C7FF

(Don't forget to change the C7 to the appropriate value if your SCSI
card isn't in slot 7.)

The computer will print the contents of location C7FF, something like
this on a II+ or IIe:

C7FF-0A

On a IIgs, it will look something like this:

00/C7FF:0A-.

The two digits after the hyphen (0A in this example) are the low order
byte of the entry point of the ProDOS block driver in the card's
firmware.  I'll call this number 'xx' in the rest of the instructions.

We need to add 3 to this number to determine the entry point of the
SmartPort firmware.  If you can add 3 in base 16 without help, go right
ahead.  If you need assistance, the monitor has an addition command
which can do it for you:

*xx+3

The computer will print the sum.  I'll call this 'yy' in the rest of the
instructions.

Now we need to set up some code to call the SmartPort firmware and issue
a status request, asking for the device information block from unit 1.
The first line is the code, and the second line is the parameter block.
Replace 'yy' with the result of the above sum, and replace the C7 if
necessary.

*300:20 yy C7 00 10 03 85 00 60
*310:03 01 20 03 03

Now we can run the code.

*300G

If you want to check whether there was an error, display the contents of
location zero:

*0
0000-zz

(zz is the error code, which will be 00 if there was no error.)

If there was no error, the device information block (DIB) will be set up
in locations 0320 through 0338.  It is structured as follows:

0320      device status byte
0321-0323  block count of the device (lo/mid/hi)
0324      ID string length
0325-0334 ID string
0335      device type byte
0336      device subtype byte
0337-0338 version word (lo/hi)

To display the whole DIB, use the following command:

*0320.0338

It will print out three lines of hex numbers, eight per line, plus one
more byte (all preceded by addresses, and with ASCII as well if you are
doing this on a IIgs).

Here is an example from the SmartPort firmware of Bernie to the Rescue:

00/0320:E8 00 00 00 09 56 49 52-h....VIR
00/0328:54 55 41 4C 20 44 49 53-TUAL DIS
00/0330:4B 20 20 20 20 01 D0 00-K    .P.
00/0338:30-0

You can see the ID string length (9) and ID string ("VIRTUAL DISK",
padded with spaces).  Bernie has a minor bug - its ID string is actually
12 characters, so if this was displayed by an application, it would
appear as "VIRTUAL D" instead of "VIRTUAL DISK".

The bytes at 0337 and 0338 are the version number, in this case 00 30,
or $3000 if you read it in reverse order.

For an Apple High-Speed SCSI card, this value should be $3000 (00 30).

For an original Apple SCSI card, it will be $0200 (00 02) for the
revision C firmware.  I don't know what version is reported for rev A
and rev B, but it will be a smaller number (such as $0100) - I know it
is not the same as rev C, because this is the official method for
software to detect the rev C firmware.

> Since some (all?) of the ROM gets mapped into the computer's address space,
> can the different versions be detected in software?

All of the code in the ROM has to be addressable by the CPU in some
manner, or it wouldn't be possible to execute it.  256 bytes are easy to
access, but the rest of it is tricky - bank switched in the $C800-$CFFE
area, which is also shared with other slots.

> Were there some signature bytes that can be checked?

There might be some portion of the ROM which can be used to identify rev
C, but I'd need to have a look at all three revisions to be certain.
The above method is more work, but it is guaranteed to produce the
correct answer.

-- 
David Empson
dempson@actrix.gen.nz