30 Jun
2005
30 Jun
'05
9:30 a.m.
Has anyone here successfully interfaced a SASI device to a PC at the
hardware level?
I've got a few classic systems which use SASI (or not-quite-SCSI)
controllers to talk to SASI-ST506 bridge boards and from there to ST506
type drives.
As has been documented many times in the past here, an ST506 drive has a
pretty tight relationship with its controller, and so hooking up the
drive to a different controller (say MFM controller in a PC) causes all
sorts of problems when it comes to backup.
Hence driving the SASI side of things (and preserving the drive/bridge
board relationship) would seem like a sensible move when it came to
backing up data. In theory data could then be restored to a replacement
drive if/when the original dies via the same method.
Presumably inventing a simple SASI board to hang off a PC parallel port
(say) is a lot easier than mucking around with the equivalent for floppy
drives - or is the data rate still likely too low to cause timeout
problems within the bridge board's firmware?
I've got several Acorn, Torch and RML machines which use bridge boards
and in most cases the tools needed to back up and restore data have long
since vanished off the face of the earth (my RML fileserver's a
particularly important one as it seems to be the only one left in the
world)
cheers
Jules
30 Jun
30 Jun
9:43 a.m.
On Thursday 30 June 2005 09:30, Jules Richardson wrote:
Has anyone here successfully interfaced a SASI device
to a PC at the
hardware level?
I have a couple of older Alpha Micro systems that use SASI drives. I've found
that early SCSI controllers (typically ISA) will work fine with SASI drives
as long as you don't mix SASI with SCSI drives on the same controller.
A number of early SCSI drives (typically <= 120MB) work with both SASI and
SCSI controllers. Early Maxtor drives seem particularly good at this. I've
found that I can replace busted SASI drives with these "early" SCSI drives
quite successfully in Alpha Micro's.
Cheers,
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"
9:58 a.m.
From: "Lyle Bickley" <lbickley at bickleywest.com>
I have a couple of older Alpha Micro systems that use
SASI drives. I've
found
that early SCSI controllers (typically ISA) will work
fine with SASI
drives
as long as you don't mix SASI with SCSI drives on
the same controller.
Would that include adapters like Adaptec 1542?
Nico
12:14 p.m.
On Thursday 30 June 2005 09:58, Nico de Jong wrote:
From: "Lyle Bickley" <lbickley at
bickleywest.com>
I don't think I tried an Adaptec 1542, but I suspect it's way too
"smart" to
work with SASI drives.
It's been a while since I used the controller, but IIRC it was an old ISA
controller card like a WD7000 or Seagate ST-01/ST-02. Any early SCSI-1
controller should do - that was before SCSI became "smart" - and the
messaging between the controller and the device (HDD) was minimal. A SASI
device on such a controller will respond "well enough" to "look like"
SCSI-1.
As I said before - DO NOT mix a SASI device with a SCSI device on the same
controller - or strange things can happen (don't ask).
Cheers,
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"
I have a couple of older Alpha Micro systems that
use SASI drives. I've
found
that early SCSI controllers (typically ISA) will
work fine with SASI
drives
as long as you don't mix SASI with SCSI
drives on the same controller.
Would that include adapters like Adaptec 1542?
12:45 p.m.
On Thu, 2005-06-30 at 12:14 -0700, Lyle Bickley wrote:
It's been a while since I used the controller, but
IIRC it was an old ISA
controller card like a WD7000 or Seagate ST-01/ST-02. Any early SCSI-1
controller should do - that was before SCSI became "smart" - and the
messaging between the controller and the device (HDD) was minimal. A SASI
device on such a controller will respond "well enough" to "look like"
SCSI-1.
As I said before - DO NOT mix a SASI device with a SCSI device on the same
controller - or strange things can happen (don't ask).
Yep - far as I remember, SASI's single target only, so I expect if you
have a SASI target on the same bus as a SCSI target all sorts of things
would happen! :-)
Most classic SASI controllers seem to be little more than a handful of
buffer and latch ICs though (only about 6 chips total) - hence I was
wondering if someone had chucked together something to hang off a PC
parallel port (and just drive it all in software). Not especially
complex - my worry would be that the SASI target would timeout on
certain ops if the PC parallel port isn't quick enough though.
cheers
Jules
12:56 p.m.
On 6/30/05, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
Most classic SASI controllers seem to be little more
than a handful of
buffer and latch ICs though (only about 6 chips total)
There's a simple SASI implementation buried in the Commodore
D9060/D9090 disk drives - I've done a lot of digging around those
guys, but have yet to break down and completely reverse-engineer the
source, so I am sketching on deep details, but essentially, the D90x0
has a "DOS board" with one 650x CPU talking IEEE-488, the other
talking SASI to a Tandon(?) SASI<->ST506 board, then a Tandon TM603S
or TM602S drive mech.
We've done some playing around, and it's possible to, say, stick an
ST225 in there and get it to format as if it were a TM602S (4 heads,
153 cyls of 32 sectors of 256 bytes). I am now getting hazy on if
this works (I didn't do it myself), but it might be trivial to patch
the firmware to address cylinders up to 255. My biggest concern with
those drives is, of couse, the unobtanium nature of 5MB and 7.5MB
ST506 drive mechs. I've always wanted to enhance the firmware to a)
address disks as large as possible (16MB?) and b) to use a more
available medium than ST506 drives. So if anyone learns more about
how SASI interoperates with ancient SCSI drives, I'd love to hear
about it.
-ethan
8:28 p.m.
From: "Jules Richardson" <julesrichardsonuk at yahoo.co.uk>
Most classic SASI controllers seem to be little more
than a handful of
buffer and latch ICs though (only about 6 chips total) - hence I was
wondering if someone had chucked together something to hang off a PC
parallel port (and just drive it all in software). Not especially
complex - my worry would be that the SASI target would timeout on
certain ops if the PC parallel port isn't quick enough though.
I have in fact 2 converters to be placed between a PC printerport and a SCSI
device. IIRC, it supports only one device. I used them _years_ ago for a
killed project, where I had to read from an Archive Viper drive, IIRC.
However, I dont know if the converter is stupid enough to be used with SASI
Nico
1:03 p.m.
On Thu, 30 Jun 2005, Lyle Bickley wrote:
As I said before - DO NOT mix a SASI device with a
SCSI device on the same
controller - or strange things can happen (don't ask).
I have a SASI controller for an Apple II Sider hard drive, and have
found clues on the web that say older SCSI drives like the Seagate ST-225N
should work with it. Does that sound reasonable? What other make/model
SCSI drives would be likely to work?
Mike Loewen mloewen at cpumagic.scol.pa.us
The Dixie Lion Jazz Band http://ripsaw.cac.psu.edu/dixie.html
The B9 Robot Builders Club B9-0014 http://ripsaw.cac.psu.edu/~mloewen/B9/
Old Technology http://ripsaw.cac.psu.edu/~mloewen/Oldtech/
1:16 p.m.
On 6/30/05, Mike Loewen <mloewen at cpumagic.scol.pa.us> wrote:
I have a SASI controller for an Apple II Sider
hard drive, and have
found clues on the web that say older SCSI drives like the Seagate ST-225N
should work with it. Does that sound reasonable? What other make/model
SCSI drives would be likely to work?
Hmm... interesting... an ST225N might be something to try with the
D90x0, but one important question... does your Sider use 512-byte
blocks or 256-byte blocks? I've reformatted odd-sized blocks (528?)
to 512, but never to 256 bytes... was there a way of doing that back
in the old days? (I was playing with DEC hardware and kinda missed out
on hanging early hard drives on 8-bit micros)
-ethan
1:30 p.m.
On Thu, 30 Jun 2005, Ethan Dicks wrote:
On 6/30/05, Mike Loewen <mloewen at
cpumagic.scol.pa.us> wrote:
Good question: I don't have the Sider drive itself, just the
controller. Back in the 8-bit days I couldn't afford a hard drive, so I
never had the chance to play with one on an 8-bit machine.
Mike Loewen mloewen at cpumagic.scol.pa.us
The Dixie Lion Jazz Band http://ripsaw.cac.psu.edu/dixie.html
The B9 Robot Builders Club B9-0014 http://ripsaw.cac.psu.edu/~mloewen/B9/
Old Technology http://ripsaw.cac.psu.edu/~mloewen/Oldtech/
I have a SASI controller for an Apple II
Sider hard drive, and have
found clues on the web that say older SCSI drives like the Seagate ST-225N
should work with it. Does that sound reasonable? What other make/model
SCSI drives would be likely to work?
Hmm... interesting... an ST225N might be something to try with the
D90x0, but one important question... does your Sider use 512-byte
blocks or 256-byte blocks? I've reformatted odd-sized blocks (528?)
to 512, but never to 256 bytes... was there a way of doing that back
in the old days? (I was playing with DEC hardware and kinda missed out
on hanging early hard drives on 8-bit micros)
3:04 p.m.
On Thu, 2005-06-30 at 16:30 -0400, Mike Loewen wrote:
On Thu, 30 Jun 2005, Ethan Dicks wrote:
At least in the Acorn world, lack of drives that'll support 256 bytes /
sector seems to be the main problem, as Acorn's SCSI controllers expect
to be talking to a bridge board which is only using 256 bytes / sector.
I have a hazy memory that it's possible with SCSI to do a read/write
operation and *not* use the full disk block size though - on a read you
just say "give me 256 bytes of block n" and on a write you supply only
256 bytes (and presumably the target pads out with zeros or something).
In other words it *might* be possible to use a device formatted with 512
byte blocks and just waste the upper half of every block (no big deal
given the choice of drives available now).
Still might need code changes though, and of course formatting /
filesystem generation tools might still have problems (and may need to
be done on a more modern machine even)
cheers
Jules
On 6/30/05, Mike Loewen <mloewen at
cpumagic.scol.pa.us> wrote:
Good question: I don't have the Sider drive itself, just the
controller. Back in the 8-bit days I couldn't afford a hard drive, so I
never had the chance to play with one on an 8-bit machine. I have a SASI controller for an Apple II
Sider hard drive, and have
found clues on the web that say older SCSI drives like the Seagate ST-225N
should work with it. Does that sound reasonable? What other make/model
SCSI drives would be likely to work?
Hmm... interesting... an ST225N might be something to try with the
D90x0, but one important question... does your Sider use 512-byte
blocks or 256-byte blocks? I've reformatted odd-sized blocks (528?)
to 512, but never to 256 bytes... was there a way of doing that back
in the old days? (I was playing with DEC hardware and kinda missed out
on hanging early hard drives on 8-bit micros)
7:06 p.m.
On Thursday 30 June 2005 13:03, Mike Loewen wrote:
On Thu, 30 Jun 2005, Lyle Bickley wrote:
I can't speak for the Apple II SASI - but I do know Alpha Micro's SASI
controller will work well with many older SCSI drives (but not ALL). [IIRC,
I had to jumper parity "off" in the drive.]
I suspect that many of the early SCSI drives made during the transition from
SASI to SCSI-1 will work O.K. with various SASI controllers. Give it a try -
it certainly won't hurt anything (drive or controller) - the SASI/SCSI
hardware interfaces are reasonably compatible - it's the protocol that either
works for a given combo. or not.
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"
As I said before - DO NOT mix a SASI device with
a SCSI device on the
same controller - or strange things can happen (don't ask).
I have a SASI controller for an Apple II Sider hard drive, and have
found clues on the web that say older SCSI drives like the Seagate ST-225N
should work with it. Does that sound reasonable? What other make/model
SCSI drives would be likely to work? 
12:39 p.m.
Has anyone here successfully interfaced a SASI device to a PC at the
hardware level?
I've got a few classic systems which use SASI (or not-quite-SCSI)
controllers to talk to SASI-ST506 bridge boards and from there to ST506
type drives.
I was under the impression that SASI was sufficiently close to SCSI that
a SCSI interface could talk to a SASI device given the right software. It
would probably make things simpler if the SASI device and the controller
were the only things on the bus.
As has been documented many times in the past here, an ST506 drive has a
pretty tight relationship with its controller, and so hooking up the
drive to a different controller (say MFM controller in a PC) causes all
sorts of problems when it comes to backup.
Hence driving the SASI side of things (and preserving the drive/bridge
board relationship) would seem like a sensible move when it came to
backing up data. In theory data could then be restored to a replacement
drive if/when the original dies via the same method.
Agreed.
Presumably inventing a simple SASI board to hang off a PC parallel port
(say) is a lot easier than mucking around with the equivalent for floppy
drives - or is the data rate still likely too low to cause timeout
problems within the bridge board's firmware?
I am pretty sure you can drive it as slowly as you like. All the bridge
boards I've seen have intenral buffer memory, certainly enough for one
block.
I've got several Acorn, Torch and RML machines which use bridge boards
FWIW the Torch XXX uses a SCSI interface chip on the mainboard, and I
thought the drive bus was SCSI on that machine.
-tony
1:35 p.m.
On 6/30/05, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
I was under the impression that SASI was sufficiently
close to SCSI that
a SCSI interface could talk to a SASI device given the right software. It
would probably make things simpler if the SASI device and the controller
were the only things on the bus.
Your postings probably crossed in the aether, but I think that's what
Allison was saying - the interfaces are close, electrically (ISTR
parity was new with SCSI), but there can be some incompatibilies at
the command-set level. - i.e. - changing the firmware for the
controller (or host) can allow one to use the other type of device
from what was originally intended.
To tie this in to what I was saying earlier, I've wanted to recode the
firmware for the D90x0 drives for a number of years, but have never
torn it apart far enough to consider reconstructing it for SCSI, plus
there's the 512-byte/256-byte issue (the D90x0 instructs the SASI
bridge card to format the tracks as 32 256-byte sectors rather than
the more ordinary and more modern 17 512-byte sectors). That, to my
level of understanding about embedded SCSI drives, is a show-stopper.
-ethan
2:53 p.m.
On Thu, 2005-06-30 at 20:39 +0100, Tony Duell wrote:
Far as I recall, it misses out some of the things found in SCSI, such as
multiple targets and extent reservation. I can't remember if it supports
parity or not either, which might mess with some SCSI controllers that
expect it.
At to the software level - again from memory - it's close, but there are
a few holes (ISTR there's no notion of an INQUIRY command, so any host
that tries to gain knowledge of what's connected to it that way is going
to get upset - this rules out the use of all Adaptec controllers that I
know of which have an on-board BIOS, for instance)
Yep - I think there may be a few cases where drive/controller assert a
line and the 'other' thing is supposed to respond within a certain time
period though; it's cases like that with the basic handshaking where I'm
not sure if a PC parallel port would cope or not. For actual shifting
data around I believe you're absolutely correct and it doesn't matter if
it takes a second or a week between bytes...
Yep, the XXX is SCSI (NCR interface chip of some sort IIRC) - their
machines which use the BBC as the I/O processor tend to be SASI though
(such as the C520 'giant brown turd' machine and the 725). As well as
the machines, I've got a few ex-workshop drives and so it'd be nice to
save any useful data that may be on them!
Actually, if I'm remembering right (without venturing into the loft and
pulling lids!), the XXX typically shipped with a bridge board in it and
used ST506 type drives, it just used a SCSI bridge rather than SASI (I
think it was an OMTI)
I have a feeling it might have been a customer option, but at the time
it was possible to buy a XXX through official channels with a much
larger capacity disk via the ST506 route than it was one with SCSI disk.
I'd have to go back through old notes and emails to be sure!
cheers
Jules
Has anyone here successfully interfaced a SASI device to a PC at the
hardware level?
I've got a few classic systems which use SASI (or not-quite-SCSI)
controllers to talk to SASI-ST506 bridge boards and from there to ST506
type drives.
I was under the impression that SASI was sufficiently close to SCSI that
a SCSI interface could talk to a SASI device given the right software. It
would probably make things simpler if the SASI device and the controller
were the only things on the bus. Presumably
inventing a simple SASI board to hang off a PC parallel port
(say) is a lot easier than mucking around with the equivalent for floppy
drives - or is the data rate still likely too low to cause timeout
problems within the bridge board's firmware?
I am pretty sure you can drive it as slowly as you like. All the bridge
boards I've seen have intenral buffer memory, certainly enough for one
block. I've got
several Acorn, Torch and RML machines which use bridge boards
FWIW the Torch XXX uses a SCSI interface chip on the mainboard, and I
thought the drive bus was SCSI on that machine. 
3:13 p.m.
The biggest problem with SASI vs SCSI is that from almost the gitgo
SCSI required select plus atn (attention) to be applied and that messages
be handled.
The only message in SASI is the status at the end of the data phase, and
it comes in whether atn is there or not.
The main thing you should look for in SASI is that it can control whether
ATN is applied on select, usually you will need to control this in the SASI
initiator software you use for the driver.
The other feature that most controllers will have that will wipe you out
(potentially) is that they will read and handle message phases automatically,
and do something you dont want them to.
Disconnects are not allowed in SASI, and a lot of controllers would disconnect
and piss off the SASI target engines.
I still see a lot of gate implemented SASI adapters in bins for a $1 or two,
but
you would have to reverse engineer them. Also almost all SASI devices were
supported in the dark ages pre open source, when everything was a trade
secret and proprietary, with manuals super hard to get.
Most companies mystified me by treating their engineering manuals as defense
grade secrets. What possible justification does one have for not publishing
how to interface to your product? Then or now. The stupidity of marketing
"technical" departments astound me with this crap.
</rant off>
Hope this helps.
Jim
Tony Duell wrote:
Has anyone here successfully interfaced a SASI device to a PC at the
hardware level?
I've got a few classic systems which use SASI (or not-quite-SCSI)
controllers to talk to SASI-ST506 bridge boards and from there to ST506
type drives.
I was under the impression that SASI was sufficiently close to SCSI that
a SCSI interface could talk to a SASI device given the right software. It
would probably make things simpler if the SASI device and the controller
were the only things on the bus. 
2:34 p.m.
Western Digital made a SASI to parallel port controller board. I used one
on a CP/M system. If you could find one it would be really easy to connect
one to a PC.
At 12:30 PM 6/30/2005, Jules Richardson wrote:
Has anyone here successfully interfaced a SASI device
to a PC at the
hardware level?
I've got a few classic systems which use SASI (or not-quite-SCSI)
controllers to talk to SASI-ST506 bridge boards and from there to ST506
type drives.
As has been documented many times in the past here, an ST506 drive has a
pretty tight relationship with its controller, and so hooking up the
drive to a different controller (say MFM controller in a PC) causes all
sorts of problems when it comes to backup.
Hence driving the SASI side of things (and preserving the drive/bridge
board relationship) would seem like a sensible move when it came to
backing up data. In theory data could then be restored to a replacement
drive if/when the original dies via the same method.
Presumably inventing a simple SASI board to hang off a PC parallel port
(say) is a lot easier than mucking around with the equivalent for floppy
drives - or is the data rate still likely too low to cause timeout
problems within the bridge board's firmware?
I've got several Acorn, Torch and RML machines which use bridge boards
and in most cases the tools needed to back up and restore data have long
since vanished off the face of the earth (my RML fileserver's a
particularly important one as it seems to be the only one left in the
world)
cheers
Jules
Michael Thompson
E-Mail: M_Thompson at IDS.net
3:06 p.m.
On Thu, 2005-06-30 at 17:34 -0400, Michael Thompson wrote:
Western Digital made a SASI to parallel port
controller board. I used one
on a CP/M system. If you could find one it would be really easy to connect
one to a PC.
That's exactly the sort of thing needed - although a schematic of
something so that others could use the same device would be nice! I
wonder if it was a simple buffer/latch interface or whether it was a
complex beast with on-board memory buffers and some kind of intelligent
control? Hopefully the former...
cheers
Jules
6:10 p.m.
On Thu, 30 Jun 2005 16:30:23 +0000
Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
Has anyone here successfully interfaced a SASI device to a PC at the
hardware level?
I've got a few classic systems which use SASI (or not-quite-SCSI)
controllers to talk to SASI-ST506 bridge boards and from there to
ST506 type drives.
As has been documented many times in the past here, an ST506 drive has
a pretty tight relationship with its controller, and so hooking up the
drive to a different controller (say MFM controller in a PC) causes
all sorts of problems when it comes to backup.
Hence driving the SASI side of things (and preserving the drive/bridge
board relationship) would seem like a sensible move when it came to
backing up data. In theory data could then be restored to a
replacement drive if/when the original dies via the same method.
Presumably inventing a simple SASI board to hang off a PC parallel
port(say) is a lot easier than mucking around with the equivalent for
floppy drives - or is the data rate still likely too low to cause
timeout problems within the bridge board's firmware?
Years ago, and I mean YEARS ago, I had a SASI card for the ISA bus on a
PC that a friend had given me. I never had a use for it and just 'had'
it for a time. This was in the mid 80's.
8:51 p.m.
Maybe you can grab a plain SCSI card and write a small program to talk
to SASI disks. I know there are some ISA scsi cards for tapes that are
'dumb' so that you can talk to the SCSI chip directly. I have a
program that talks SCSI-1 with NCR 53C90/53C94/53C96 chips. You can
easily avoid morden SCSI commands. I will be happy to share the
program if somebody can help me for the copyright issue (I modified a
program that I downloaded from the web. The license of that program is
unknown)
vax, 9000
10:14 p.m.
New subject: Amiga 2000 Floppy Drive problem
I was messing around with my Amiga 2000HD today (installing a 2.04 Kickstart
Rom to replace the 1.3 Kickstart among other things) and now my internal
floppy is dead. The drive worked fine after I changed the rom and the HD and
installed workbench 2.04, it was when I reassembled the system and rebooted
I noticed the floppy was no longer working. I took the drive out and didn't
notice any smell or burnt traces (as if I had the power connected backwards
and it fried), any way to troubleshoot one of these things (Chinon FB-354)?
Anybody happen to have one of these drives laying around they don't need?
10:30 p.m.
New subject: Amiga 2000 Floppy Drive problem
On 7/1/05, Teo Zenios <teoz at neo.rr.com> wrote:
I was messing around with my Amiga 2000HD today
(installing a 2.04 Kickstart
Rom to replace the 1.3 Kickstart among other things) and now my internal
floppy is dead. The drive worked fine after I changed the rom and the HD and
installed workbench 2.04, it was when I reassembled the system and rebooted
I noticed the floppy was no longer working. I took the drive out and didn't
notice any smell or burnt traces (as if I had the power connected backwards
and it fried), any way to troubleshoot one of these things (Chinon FB-354)?
Hmm... given that there isn't _one_ FDC chip - perhaps you could check
your 8520s? Those control the floppy digital signals (presuming your
problem is that the drive doesn't light up, as opposed to a spinning
floppy that won't read - that can be analog electronics or Paula).
You could remove the drive, check carefully for shorts so you don't
fry another machine, and try it on another machine (as DF1, to be most
helpful).
I'd also make sure you didn't dislodge the DF1 jumper on the
motherboard - the A2000 is quirky in how it supports drive selects and
internal/external drive numbers. This shouldn't affect DF0, but it
_will_ affect DF1.
I guess I should have asked first - you do have the schematics, don't
you? They are at the back of the Tech Ref manual if nowhere else (for
pre-v6 mobos - not sure where to find late-model schematics).
I guess the point is - determine if it's the Amiga or the floppy drive
first. As for troubleshooting the drive itself, I don't know that a)
there's enough information to successfully poke around in the innards,
or b) you'd be able to find parts to fix if it you could.
10:45 p.m.
New subject: Amiga 2000 Floppy Drive problem
----- Original Message -----
From: "Ethan Dicks" <ethan.dicks at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Friday, July 01, 2005 1:30 AM
Subject: Re: Amiga 2000 Floppy Drive problem
On 7/1/05, Teo Zenios <teoz at neo.rr.com>
wrote:
> I was messing around with my Amiga 2000HD today (installing a 2.04
Kickstart
> Rom to replace the 1.3 Kickstart among other
things) and now my internal
> floppy is dead. The drive worked fine after I changed the rom and the HD
and
> installed workbench 2.04, it was when I
reassembled the system and
rebooted
> I noticed the floppy was no longer working. I
took the drive out and
didn't
> notice any smell or burnt traces (as if I had the
power connected
backwards
> and it fried), any way to troubleshoot one of
these things (Chinon
FB-354)?
Hmm... given that there isn't _one_ FDC chip - perhaps you could check
your 8520s? Those control the floppy digital signals (presuming your
problem is that the drive doesn't light up, as opposed to a spinning
floppy that won't read - that can be analog electronics or Paula).
You could remove the drive, check carefully for shorts so you don't
fry another machine, and try it on another machine (as DF1, to be most
helpful).
I'd also make sure you didn't dislodge the DF1 jumper on the
motherboard - the A2000 is quirky in how it supports drive selects and
internal/external drive numbers. This shouldn't affect DF0, but it
_will_ affect DF1.
I guess I should have asked first - you do have the schematics, don't
you? They are at the back of the Tech Ref manual if nowhere else (for
pre-v6 mobos - not sure where to find late-model schematics).
I guess the point is - determine if it's the Amiga or the floppy drive
first. As for troubleshooting the drive itself, I don't know that a)
there's enough information to successfully poke around in the innards,
or b) you'd be able to find parts to fix if it you could.
The floppy does not spin up or light up, workbench shows a DF0:??? on the
screen. I have an external 1011 drive that belongs with my A500 and I can
boot from that drive fine.
I will check the 8520's in the morning.
1 Jul
1 Jul
2:14 p.m.
New subject: Amiga 2000 Floppy Drive problem
----- Original Message -----
From: "Ethan Dicks" <ethan.dicks at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Friday, July 01, 2005 1:30 AM
Subject: Re: Amiga 2000 Floppy Drive problem
On 7/1/05, Teo Zenios <teoz at neo.rr.com>
wrote:
> I was messing around with my Amiga 2000HD today (installing a 2.04
Kickstart
> Rom to replace the 1.3 Kickstart among other
things) and now my internal
> floppy is dead. The drive worked fine after I changed the rom and the HD
and
> installed workbench 2.04, it was when I
reassembled the system and
rebooted
> I noticed the floppy was no longer working. I
took the drive out and
didn't
> notice any smell or burnt traces (as if I had the
power connected
backwards
> and it fried), any way to troubleshoot one of
these things (Chinon
FB-354)?
Hmm... given that there isn't _one_ FDC chip - perhaps you could check
your 8520s? Those control the floppy digital signals (presuming your
problem is that the drive doesn't light up, as opposed to a spinning
floppy that won't read - that can be analog electronics or Paula).
You could remove the drive, check carefully for shorts so you don't
fry another machine, and try it on another machine (as DF1, to be most
helpful).
I'd also make sure you didn't dislodge the DF1 jumper on the
motherboard - the A2000 is quirky in how it supports drive selects and
internal/external drive numbers. This shouldn't affect DF0, but it
_will_ affect DF1.
I guess I should have asked first - you do have the schematics, don't
you? They are at the back of the Tech Ref manual if nowhere else (for
pre-v6 mobos - not sure where to find late-model schematics).
I guess the point is - determine if it's the Amiga or the floppy drive
first. As for troubleshooting the drive itself, I don't know that a)
there's enough information to successfully poke around in the innards,
or b) you'd be able to find parts to fix if it you could.
Jumper 301 is still in the open position (for a single drive).
The two 8520's looked ok (nothing shorting pins together or stuff like that,
no signs of overheating). I swapped the 2 chips around and still have the
same result (external Df2: works while the internal DF0: is dead).
I checked the floppy cable and didn't see anything out of the ordinary
(except a pin in what looks like position 2 of the cable but I think that is
a key, since the motherboard does not look like it has a broken pin on it).
At this point I think it either the floppy cable has a bad line, or the
drive is just dead. Since the amiga cable does not look like a standard
floppy cable I think I will try setting the drive for Df1: and shorting
Jumper 301 to see if its recognized at all.
I did some research and quite a few older DD 3.5" PC drives can be jumpered
to Amiga mode (ofcourse I don't have any on the list).
2 Jul
2 Jul
2:56 a.m.
New subject: Amiga 2000 Floppy Drive problem
On 7/1/05, Teo Zenios <teoz at neo.rr.com> wrote:
Jumper 301 is still in the open position (for a single
drive).
Perfect.
The two 8520's looked ok (nothing shorting pins
together or stuff like that,
no signs of overheating). I swapped the 2 chips around and still have the
same result (external Df2: works while the internal DF0: is dead).
OK... swapping the 8520s and watching the symptoms was a pretty
standard method back in the day - it's easy and it works, so that
_probably_ shows your 8520s are OK.
I checked the floppy cable and didn't see anything
out of the ordinary
(except a pin in what looks like position 2 of the cable but I think that is
a key, since the motherboard does not look like it has a broken pin on it).
That _is_ a key (and needs to be in any Amiga hardware FAQ - I can't
remember how many times we had to tell people that in our Amiga club -
every novice who added an internal floppy use to call us up and ask
how to "replace a broken pin"... they thought that the
pin had become stuck, and they must have pulled it out when they
messed with the cable.
At this point I think it either the floppy cable has a
bad line, or the
drive is just dead. Since the amiga cable does not look like a standard
floppy cable I think I will try setting the drive for Df1: and shorting
Jumper 301 to see if its recognized at all.
I did some research and quite a few older DD 3.5"
PC drives can be jumpered
to Amiga mode (ofcourse I don't have any on the list).
And they support the /DISK-EXCHANGE signal (p 34?) That was what
always hosed frugal early-adopters of the Amiga - they'd try to use a
cheap floppy, and the OS wouldn't be able to step the drive in and out
one track to get the drive to assert the /DISK-EXCHAGE (or whichever
one it was) so that the drive could 'tell' the OS that the diskette
that used to be there isn't there any more.
You _can_ hook up a floppy drive that won't assert that signal, but
that places a burden on the user's head to have to type an AmigaDOS
command to flush the previous diskette's particulars and to cache the
new diskette.
-ethan
11:16 a.m.
New subject: Amiga 2000 Floppy Drive problem
----- Original Message -----
From: "Ethan Dicks" <ethan.dicks at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Saturday, July 02, 2005 5:56 AM
Subject: Re: Amiga 2000 Floppy Drive problem
that is
This link shows how to modify a specific PC floppy to work perfectly on an
Amiga (pin 34 goes to pin 2)
http://www.caps-project.org/articles.php?id=a_v9drivemod
Anyway while checking for Amiga compatible PC drives in my piles of stuff I
came across a HD to floppy power connector (was stuck on a floppy drive) I
decided to try it out on the Amiga. The drive works! I then checked the
voltage at the old amiga power connection and it does show 5V and 12V (using
a multimeter). So either there is a loose connection inside the power cable
or its pinched somewhere so that under load the voltage drops enough so that
the drive wont work. Anyway I kept the power adapter in place (along with a
Y cable so I can power my 2GB HD) and everything works just fine for now
(even with the case back on) so I am happy.
I must say that with a 2.x kickstart and Workbench 2.1 this GVP 030/40
boots up one hell of allot faster then it did in its Kickstart 1.3 days. Too
bad all my other machines can't go from power on to desktop in under 15
seconds (from a HD boot about 10 seconds for my A1200).
Thanks for the help Ethan.
On 7/1/05, Teo Zenios <teoz at neo.rr.com>
wrote:
that,
Jumper 301 is still in the open position (for a
single drive).
Perfect.
> The two 8520's looked ok (nothing shorting pins together or stuff like
> no signs of overheating). I swapped the 2 chips
around and still have
the
same result
(external Df2: works while the internal DF0: is dead).
OK... swapping the 8520s and watching the symptoms was a pretty
standard method back in the day - it's easy and it works, so that
_probably_ shows your 8520s are OK.
> I checked the floppy cable and didn't see anything out of the ordinary
> (except a pin in what looks like position 2 of the cable but I think > a key, since the motherboard does not look like
it has a broken pin on
it).
That _is_ a key (and needs to be in any Amiga hardware FAQ - I can't
remember how many times we had to tell people that in our Amiga club -
every novice who added an internal floppy use to call us up and ask
how to "replace a broken pin"... they thought that the
pin had become stuck, and they must have pulled it out when they
messed with the cable.
jumpered
At this point I think it either the floppy cable
has a bad line, or the
drive is just dead. Since the amiga cable does not look like a standard
floppy cable I think I will try setting the drive for Df1: and shorting
Jumper 301 to see if its recognized at all.
> I did some research and quite a few older DD 3.5" PC drives can be
to Amiga mode
(ofcourse I don't have any on the list).
And they support the /DISK-EXCHANGE signal (p 34?) That was what
always hosed frugal early-adopters of the Amiga - they'd try to use a
cheap floppy, and the OS wouldn't be able to step the drive in and out
one track to get the drive to assert the /DISK-EXCHAGE (or whichever
one it was) so that the drive could 'tell' the OS that the diskette
that used to be there isn't there any more.
You _can_ hook up a floppy drive that won't assert that signal, but
that places a burden on the user's head to have to type an AmigaDOS
command to flush the previous diskette's particulars and to cache the
new diskette.
-ethan
1 Jul
1 Jul
2:24 a.m.
New subject: Amiga 2000 Floppy Drive problem
I noticed the floppy was no longer working. I took the
drive out and
didn't
notice any smell or burnt traces (as if I had the power connected
backwards
and it fried), any way to troubleshoot one of these things (Chinon
FB-354)?
Last time I had that problem with my A1000 I'd managed to put the floppy
cable on offset by 1 pair of pins so it couldn't be seen. Easy mistake to
make :)
--
adrian/witchy
Binary Dinosaurs creator/curator
www.binarydinosaurs.co.uk - the UKs biggest home computer collection?
3:52 a.m.
New subject: Amiga 2000 Floppy Drive problem
On Fri, 2005-07-01 at 01:14 -0400, Teo Zenios wrote:
I noticed the floppy was no longer working. I took the
drive out and didn't
notice any smell or burnt traces (as if I had the power connected backwards
and it fried), any way to troubleshoot one of these things (Chinon FB-354)?
3.5" drive presumably...
Check solder joints for the power connector - the power connectors on
most 3.5" drives are really badly designed with only the solder joints
securing them; it's easy for them to break. Been there a few times...
cheers
Jules
2:01 p.m.
New subject: Amiga 2000 Floppy Drive problem
----- Original Message -----
From: "Jules Richardson" <julesrichardsonuk at yahoo.co.uk>
To: <cctalk at classiccmp.org>
Sent: Friday, July 01, 2005 6:52 AM
Subject: Re: Amiga 2000 Floppy Drive problem
On Fri, 2005-07-01 at 01:14 -0400, Teo Zenios wrote:
> I noticed the floppy was no longer working. I took the drive out and
didn't
> notice any smell or burnt traces (as if I had the
power connected
backwards
> and it fried), any way to troubleshoot one of
these things (Chinon
FB-354)?
3.5" drive presumably...
Check solder joints for the power connector - the power connectors on
most 3.5" drives are really badly designed with only the solder joints
securing them; it's easy for them to break. Been there a few times...
cheers
Jules
I will try that next
7113
days inactive
7115
days old
28 comments
12 participants
participants (12)
-
ard＠p850ug1.demon.co.uk -
chenmel＠earthlink.net -
ethan.dicks＠gmail.com -
julesrichardsonuk＠yahoo.co.uk -
jwstephens＠msm.umr.edu -
lbickley＠bickleywest.com -
m_thompson＠ids.net -
mloewen＠cpumagic.scol.pa.us -
nico＠FARUMDATA.DK -
teoz＠neo.rr.com -
vax9000＠gmail.com -
witchy＠binarydinosaurs.co.uk