Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!bionet!ames!amdcad!sun!imagen!atari!portal!uunet!mcvax!unido!nixpbe!mboen From: mboen@nixpbe.UUCP (Martin Boening) Newsgroups: comp.sys.atari.st Subject: Re: Attaching a CHINON drive to the ST (long (147 lines or so)) Summary: Specs taken from diverse sources Keywords: ST, Chinon, diskdrive Message-ID: <196@nixpbe.UUCP> Date: 10 Feb 89 08:01:46 GMT References: <1003@laura.UUCP> <329@ultb.UUCP> Reply-To: unido!nixpbe!mboening.pad (Martin Boening) Organization: Nixdorf Computer AG, Paderborn, W.-Germany Lines: 153 Subject: Re: Chinon drives (long... 147 lines) This is another edition of the novel: Disk drives and the Atari ST (two worlds collide :-)) This is how the floppy disk connector for the Atari St is shown in the book 'Scheibenkleister - Massenspeicher am ST' (by Claus Brod and Anton Stepper, published by Maxon*) Atari Connector: Shugart Bus: Read Data -01------------------30- RDT, Read Data Side Select -02------------------32- SSL, Side Select Ground -03------------------(odd pins 3..31, GROUND)------+ Index -04------------------08- IDX, Index Pulse | Drive Select A -05------------------10- DS0, Drive Select 0 | Drive Select B -06------------------12- DS1, Drive Select 1 | Ground -07------------------------------------------------+ Motor On -08------------------16- MON, Motor on Step Direction -09------------------18- DIR, Direction Step -10------------------20- STP, Step impulse Write Data -11------------------22- WDT, Write Data Write Gate -12------------------24- WGT, Write Gate Track 00 -13------------------26- TR0, Track 0 Write Protect -14------------------28- WPT, Write Protect ----------- / 10 |_| 11 \ / * * \ / 8 9 \ / * 12 13 * \ ( * 14 * ) ( 6 * 7 ) ( * * ) \ 4 5 / \ * * / \ 2 3 / \ * * / \ 1 / \ * / ----- This is the connector for the Atari ST There's also the Profibuch I mentioned in my last posting. It shows a schematic that demonstrates the connection of a second drive as well. I'm not going to show that one here (I think interested parties might buy the book). They call Pin 1 of the Shugart bus 'Disk change reset' and show it grounded. Then there's pin 2, referred to as 'head load' above and also in the Shugart bus description of the Profibuch, which in the said schematic (on page 785, BTW) is called 'Disk change' (if I remember my BASF maintenance guide correctly, its bidirectional, at least for some drives), also permanently 'grounded', i.e. unused. So much for the drive HW. I hope the chinon drive conforms to the Shugart bus specification. Now, below there's something concerning the detection of disk changes. I was wrong in assuming it to be purely a software problem. Actually its both: listening to 'write protect' and checking serial numbers. That's why it works worst with write protected disks. A disk change is detected when you pull out a diskette because the write protect signal becomes true as soon as the light beam for the write protection is no longer inhibited by a diskette in the drive. With a write protected disk it is activated with the diskette in the drive so there is a little problem in detecting the change of write protected disks. This can be changed on some drives (see below). Some citations (sorry for badly done interpreting, all books mentioned are in German): Scheibenkleister, page 297, remarks to media change in connection with hooking up non-Atari drives to a ST: >... >Lastly, a few general, well-intended tips and tricks that might help >you when you want to hook up other drives. > > There are drives that use pin 2 of the Shugart bus (Head Load) to report > a disk change. The ST detects disk changes in a different manner: it > regularly checks the state of the write protect pin; to detect disk > changes properly connect pin 2 of the Shugart bus to pin 28 (Write > protect) using a diode (for instance a 1N4148). (The diode should permit > current to pass in the direction of pin 2). This way the disk change > signal is modulated onto the write protect signal. This change is > for example necessary for the newer TEAC FD35-F drives > ... Scheibenkleister, page 101, description of diskoriented bios calls: > ... > Bios call no. 9, called MEDIACH, expects the drive number as input and > returns the GUESS of the bios, whether the disk in the named drive was > changed. A return value of 0 means that the BIOS is damned sure the same > disk is still in the drive; 1 indicates the BIOS is unsure (i.e. with the > next disk access the serial number in the bootsector will be checked). > "2" says "You thought I didn't get it but I did: the disk was changed!". Scheibenkleister, page 507, BIOS routines > ... > In its internal VBL-Floppyroutine (i.e. the routine that is called > every 50th/60th/70th of a second, depending on your monitor) the TOS > registers, whether a diskette was changed. The result is kept in an > internal variable which can be read by MEDIACH. After a write access to > the boot sector or after formatting TOS always assumes a disk change. > If the MEDIACH status is 1, TOS will read the boot sector at the next > disk access to check whether the disk was changed or not (comparison > of the serial numbers in the boot sector) and, if so, where the data- > and control sectors are on the new disk. Therfore it is very impor- > tant to give different serial numbers to all disks. Atari ST Profibuch, page 65, description of the bios function 'Mediach (Bios 9): >... >Detects disk changes. This works (naturally not at all times) especially >only when you don't work with write protected disks. In addition, when >formatting disks you should make sure, that every diskette has a different >serial number. >... > [calls in assembler and C deleted] >... > meret(d0): 0: disk was certainly not changed > 1: maybe the disk was changed <-------------!!!!! > 2: disk was certainly changed > (finally three-value-logic!) >... > Atari ST Profibuch, page 197, description of system variables > >... > long $00047e 1150 hdv_mediach > > vector of the routine for detecting the media change status of a logical > drive. > >... This should answer most questions, if there are still more, feel free to ask Martin Email: USA: ...uunet!linus!nixbur!mboening.pad !USA: ...mcvax!unido!nixpbe!mboening.pad