Peripheral (SCSI, ADB) Hardware Docs?

[equant]

I was wondering if anyone knew if there were any PDFs (or webpages) that cover the hardware side of the ADB or SCSI specs? I've found the OS/Software info in Inside Macintosh, but I'm looking for the specs/data/etc for the hardware. I figure Apple must have published something for peripheral designers to use right?

Thanks

 

[Charlieman]

"Inside Macintosh" was a clue. Try searching for "Inside Macintosh Hardware", or is that the doc you found:

http://developer.apple.com/documentation/mac/Devices/Devices-2.html

There's an older book that you may need too -- Porter?

Look at the Linux and BSD pages that discuss Mac hardware. They discuss third party additions that don't make it into the official specs.

 

[equant]

or is that the doc you found:

It is, but I obviously dismissed it too quickly. I'm finding some good hardware info, although I'd still like to know if there's another source.

I've browsed some of the BSD stuff, but it's not so much about the hardware as it is interacting with it, which is better than nothing, but still not quite what I want.

 

[Mac128]

or is that the doc you found:

It is, but I obviously dismissed it too quickly. I'm finding some good hardware info, although I'd still like to know if there's another source.

The book you may be thinking of is Guide to the Macintosh Family Hardware or the first ed. Macintosh Family Hardware Reference. There were PDFs around the web for the 128K through Plus. But if you are looking for ADB & SCSI you most likely need the later chapters. The books can be picked up fairly inexpensively from used book sites and is a good investment for a vintage Mac enthusiast.

 

[equant]

The book you may be thinking of is Guide to the Macintosh Family Hardware or the first ed. Macintosh Family Hardware Reference.

Perfect, thanks. Several of the used booksellers don't mention the revision/edition number, but they have the publication date. I'm guessing that 1988 would include the SE and II?

 

[porter]

"Inside Macintosh" was a clue....
There's an older book that you may need too -- Porter?

The original white covered "Inside Macintosh" volumes are pretty good with at describing the hardware and how to use SCSI with Macs. SCSI is not for the faint of heart and you do need the real SCSI documentation regarding command formats.

Of course, to keep things Macintosh, when using the Mac hardware, use the provided drivers, don't dive into programming the SCC chip yourself or whatever. By that I mean if you get into the hardware yourself you won't work when running on a IIfx, under A/UX or Basilisk.

 

[equant]

Of course, to keep things Macintosh, when using the Mac hardware, use the provided drivers, don't dive into programming the SCC chip yourself or whatever.

I'm not sure I fully understand. What do you mean by "use the provided drivers"? Does this mean, "use the SCSI Manager" or something else? Also, I assumed that I would be making a custom SCC chip, is this ridiculous?

I realize people often bite off more than they can chew when they get into these things. I was just hoping to get enough information to play with the SCSI a bit. Turn on an LED for example, then see where I want to go with it. I have no intention of trying to create a SCSI <-> SD bridge yet.

Thanks for everyone's input.

 

[Trash80toHP_Mini]

. . . so why would you want to use their info on an open standard? :?:

Apple used an unsupported connector (DB-25) for a 50 pin standard interface. Google SCSI a/o "Small Computer Systems Interface" and you'll have a whole lot more luck finding the right info than looking in the Apple hardware docs.

Trust me on this, I own most of their docs from the Mac II/Quadra era.

jt: a founding member of the 68kMLA's cantankerous old coot contingent. :b&w:

 

[porter]

. . . so why would you want to use their info on an open standard? :?:

because there are two parts to this

(a) the actual SCSI commands that go on the SCSI bus, which the open standards define

( B) how you initiate SCSI commands and get SCSI data to and from the bus on a macintosh are defined in the Apple docs.

So if you are building a device to be operate by SCSI, just use the standards.

If you are writing the mac driver, you need both.

 

[joshc]

. . . so why would you want to use their info on an open standard? :?:

AFAIK, Apple's implementation isn't the same as the open standard.

 

[equant]

Ok, thanks for the input regarding vs Apple vs SCSI Standard. I'll keep it in mind, but I don't think this thread needs to go in that direction. I'm still curious about this...

Of course, to keep things Macintosh, when using the Mac hardware, use the provided drivers, don't dive into programming the SCC chip yourself or whatever.

I'm not sure I fully understand. What do you mean by "use the provided drivers"? Does this mean, "use the SCSI Manager" or something else? Also, I assumed that I would be making a custom SCC chip, is this ridiculous?

... My brief look at SCSI makes me think that I should be able to implement it with a microcontroller. Am I way off base? Here are the two 'learning' projects I had in mind...

* Control a bank of LEDs.

* Make a read-only memory device.

Using C and an AVR, is this unrealistic?

 

[wally]

http://micha.freeshell.org/ramdisk/index.php

http://micha.freeshell.org/pcmcia_drive/index.php

http://www.eetasia.com/ARTICLES/2000JUN/2000JUN02_CT_AN8.PDF

 

[Charlieman]

Of course, to keep things Macintosh, when using the Mac hardware, use the provided drivers, don't dive into programming the SCC chip yourself or whatever. By that I mean if you get into the hardware yourself you won't work when running on a IIfx, under A/UX or Basilisk.

To follow on from Porter: if you build a device that looks to the OS like a supported Macintosh device, you don't need to write your own driver. Indirectly, those driver specifications are part of Inside Macintosh.

Take the proliferation of ethernet adapters on the market in the 1990s. Manufacturers who chose to use the Sonic chipset could rely on their devices working straight out of the box. No drivers were required unless the manufacturer diverged from the spec (eg by adding extra cache), but even those cards would still work at sub-optimal speed.

If you build a device that is not directly supported by Mac OS, you have two choices:

1. Create your own software driver for Mac OS. And separate drivers for A/UX and Basilisk, or anything that emulates Mac OS.

2. Write a shim (a "translator") that sits between the Mac OS driver and your device. With luck, it'll work with an emulator.

 

[porter]

To follow on from Porter: if you build a device that looks to the OS like a supported Macintosh device, you don't need to write your own driver. Indirectly, those driver specifications are part of Inside Macintosh.

And to follow on from Charlieman, say for example you are writing a new fandangled PPP implementation. Don't write to the SCC yourself, use the CommsToolbox way of locating serial drivers to provide the actual stream, but you do your fancy PPP thing. Eg you build properly layered device drivers.

If you are thinking of writing a device driver, first think what kind of device is it, eg block, video, stream or whatever then choose the appropriate way of delivering your implementation. If you choose correctly then any other application will be able to use your device as if it was part of the operating system.

 

[equant]

http://micha.freeshell.org/ramdisk/index.phphttp://micha.freeshell.org/pcmcia_drive/index.php

http://www.eetasia.com/ARTICLES/2000JUN/2000JUN02_CT_AN8.PDF

Great links!

 

[equant]

To follow on from Porter [...]

And to follow on from Charlieman [...]

Ack!

Thanks C & P for the expounding. I appreciate it.

Looking at the links Wally posted makes me think it's a big task to do something simple with SCSI, but I still want to take a whack at it.

 

[porter]

Looking at the links Wally posted makes me think it's a big task to do something simple with SCSI, but I still want to take a whack at it.

My computer communications career started with RS232 hardware and software. It's still not a bad place to start, you have two serial ports, and you can plug plenty of different things onto it, including just another computer running a terminal emulator to help you debugging.

 

[equant]

Looking at the links Wally posted makes me think it's a big task to do something simple with SCSI, but I still want to take a whack at it.

My computer communications career started with RS232 hardware and software. It's still not a bad place to start, you have two serial ports, and you can plug plenty of different things onto it, including just another computer running a terminal emulator to help you debugging.

Mine too, and It's good advice, but I've had my fill of RS232. I'm looking for something more involved; not for any good reason. I'd just like to take on a hardware and/or driver project. It's pretty intimidating to take the first step though.

 

[porter]

I'd just like to take on a hardware and/or driver project.

The one thing the world is crying out for is USB drivers. If you want something with mileage, go for that. You can also fill your boots with SCSIness because the USB block storage is a SCSI protocol over the top of USB. Hey, it combines serial with SCSI!