6 May
2007
6 May
'07
12:10 a.m.
Hi guys,
I think I might be on something of a roll here - I spent the train ride
to/from work (and a good chunk of my lunch break) playing about with state
machine designs for the write side of the floppy disc writer. What I've come
up with is a nifty little finite state machine that interprets instructions
from the acquisition RAM, then executes them and writes
them to disc. The way
I've done it, there are five instructions:
0nnn nnnn: Write Timer. Writes the 7-bit timer value 'n' to the timer, then
outputs a pulse on the WRDATA line when the counter reaches zero
1111 1111: STOP. Sets the STOP flag and halts the state machine until it is
reset.
1011 xxx0: Close Write Gate. Deactivates WRGATE, preventing the head from
writing to the disc.
1011 xxx1: Open Write Gate. Activates WRGATE, allowing the drive head to
write to the disc.
110n nnnn: Wait for 'n' INDEX pulses before continuing execution of SM
instructions.
1100 0000: Wait for a hard-sector track index (sector zero marker) signal
before continuing execution of SM instructions.
As far as I can tell, this is the minimum instruction set required to allow
both soft and hard sectored discs to be duplicated reliably. There is one
'spare' instruction -- 1110 xxxx -- if anyone can come up with a good use for
it, I'm open to suggestions.
The write hardware currently clocks in at 19 macrocells, read hardware is
another 26, the track-index pulse detector (which allows hard-sectored discs
to be read and written) is 18, and the MFM synchronisation detector (including
the neat little state-machine data separator) is another 29. So that's a total
of 92, which leaves 52 for the acquisition control circuitry and registers.
Assuming I don't run out of any other chip resources first, that is.
The disc interface is going to be a standard 34-pin "PC" floppy connector.
It seemed like the best plan - wiring to 3.5 and 5.25" drives can be done with
a standard cable, and 8" drives can probably be connected with a fairly simple
adapter cable.
I do need one thing confirming though - I've read that on hard-sectored
discs, each sector is marked with an index pulse:
---+ +------------+ +----
| | | |
+--+ +--+
And the start of the track (sector 1) looks like this - note the index pulse
half-way between two other index pulses:
---+ +----+ +----+ +----
| | | | | |
+--+ +--+ +--+
1 2 3
My question is, does sector 1 start at 1, 2 or 3? I'm guessing 3, and that's
what the sync detector's set up for at the moment. Basically, it has a timing
window - if a second index pulse arrives within 0.75T (where T = time between
two normal index pulses) of the last one, it is assumed to be a track index
sequence. The threshold value is adjustable in software, so drive speed isn't
an issue.
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
6 May
6 May
8:30 a.m.
On 6 May 2007 at 8:10, Philip Pemberton wrote:
My question is, does sector 1 start at 1, 2 or 3?
Yes, it starts at 3, providing you acknowledge that "Sector 1" is a
completely artificial notion. (i.e. There are a few hard-sectored
systems that don't look for the index pulse at all.)
Cheers,
Chuck
10:05 a.m.
Chuck Guzis wrote:
On 6 May 2007 at 8:10, Philip Pemberton wrote:
By that I assume you mean that they use the index pulse to mark the sectors,
but ignore the track start marker?
Otherwise how could they be called hard-sectored if they weren't synchronising
the sector boundaries against sector marks on the disc?
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
My question is, does sector 1 start at 1, 2 or 3?
Yes, it starts at 3, providing you acknowledge that "Sector 1" is a
completely artificial notion. (i.e. There are a few hard-sectored
systems that don't look for the index pulse at all.)
10:19 a.m.
On 6 May 2007 at 18:05, Philip Pemberton wrote:
By that I assume you mean that they use the index
pulse to mark the sectors,
but ignore the track start marker?
Right.
The ones I'm thinking of are 8" systems, where the drive has separate
outputs for SECTOR and INDEX. There's no compelling reason to pay
attention to INDEX in many applications--and some systems reflect
this.
That was the other thing that I wanted to mention--that 8" drives
separate sector marks from index marks for you. Most do it with a
couple of one-shots--precision timing isn't terribly important, given
that HS 8" disks had at most 32 sectors. Given that, you may want to
make your determination of index and sector marks optional for those
wishing to make use of the drive capabilities.
If you haven't gotten a volunteer for your CW samples, drop me a
private email and I'll make some up for you.
Cheers,
Chuck
12:12 p.m.
Chuck Guzis wrote:
The ones I'm thinking of are 8" systems,
where the drive has separate
outputs for SECTOR and INDEX. There's no compelling reason to pay
attention to INDEX in many applications--and some systems reflect
this.
OK then, looks like I *do* need to read the SA800 docs then...
That was the other thing that I wanted to
mention--that 8" drives
separate sector marks from index marks for you. Most do it with a
couple of one-shots--precision timing isn't terribly important, given
that HS 8" disks had at most 32 sectors. Given that, you may want to
make your determination of index and sector marks optional for those
wishing to make use of the drive capabilities.
That's a good point - if there's a spare pin on the 34-pin connector (and a
bit of spare space in the CPLD) I'll add the relevant logic to it. Pins 4 and
6 on the FDD connector look like fair game - they're listed as "N/C" on my
pinout, but seeing as it's going to be turned into an input, I doubt that
matters much (after all, you can always turn off the external index marker input).
The only thing I'm slightly worried about is if the INDEX output also includes
the half-sector pulse that marks the 'first sector'. That would change how the
drive controller needs to be programmed - if you wanted to read the last
sector on its own, you'd add 1 to the "termination count" (number of times a
termination condition - i.e. the INDEX line - must exist before the R/W
operation is stopped). If the drive masks out the half-sector pulse, you
wouldn't need to add the 1. Again, all of this is configurable in the CPLD;
the hard part is deciding how to integrate all these options into the software
interface and API!
I think I'll spend this evening sorting out the register interface stuff, tie
all the logic together and see if it passes the behavioural simulations. If it
does, I'll start work on the schematics and PCB.
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
1:58 p.m.
Philip Pemberton wrote:
Hmm, any chance of making the connector more of a CPU bus, with a handful of
address lines? Then you just plug in a little module, one per floppy drive, to
give that drive an ID on the bus.
My thinking is that supporting just two drive types isn't enough in a general
archive box, and even four might not cut it. The only overhead is a data cable
per floppy drive, and a few buffer / address decoding ICs...
The module would have a standard 34 pin connector for drive signals on it, or
I suppose there might be special-case variants for 8" or for some really
oddball setups.
(I was tempted to say you could make the modules plug straight into the back
of the drives, similar to SCSI SCA adapters, and then just have a single bus
cable connecting them all up, but the lack of any standard as to placement of
a floppy drive's data connector makes that problematic)
cheers
Jules
--
"What progress. It's almost as good as taping it... on tapes which self
destruct in seven days."
- Bill Bailey on the BBC's "watch again" service
That was the
other thing that I wanted to mention--that 8" drives
separate sector marks from index marks for you. Most do it with a
couple of one-shots--precision timing isn't terribly important, given
that HS 8" disks had at most 32 sectors. Given that, you may want to
make your determination of index and sector marks optional for those
wishing to make use of the drive capabilities.
That's a good point - if there's a spare pin on the 34-pin connector
(and a bit of spare space in the CPLD) I'll add the relevant logic to
it.
7 May
7 May
2:10 a.m.
Jules Richardson wrote:
Hmm, any chance of making the connector more of a CPU
bus, with a
handful of address lines? Then you just plug in a little module, one per
floppy drive, to give that drive an ID on the bus.
Sounds like a good plan.
Adding stuff like that isn't hard - because the CPLD only handles read, write
and indexing, everything else (drive selection, density select output, motor
on/off signalling, basically everything that doesn't need fantastically
accurate timing) is handled by a microcontroller. Adding more I/Os at TTL
level is just a case of adding more links from the MCU to the output ports.
The big problem is that this is going to add an extra connector to the drive
interface box...
My thinking is that supporting just two drive types
isn't enough in a
general archive box, and even four might not cut it. The only overhead
is a data cable per floppy drive, and a few buffer / address decoding
ICs...
Would eight drives be enough for you, or would you prefer sixteen? :)
Open-collector or TTL outputs?
The module would have a standard 34 pin connector for
drive signals on
it, or I suppose there might be special-case variants for 8" or for some
really oddball setups.
What I don't want to end up doing is designing something that needs a box full
of addon modules to use, or becomes useless if those modules are lost. The
plan is to build something that can handle 80% of the work as-is, then do the
other 20% with the help of AOMs.
(I was tempted to say you could make the modules plug
straight into the
back of the drives, similar to SCSI SCA adapters, and then just have a
single bus cable connecting them all up, but the lack of any standard as
to placement of a floppy drive's data connector makes that problematic)
So use an IDC header or something, have the board push into the drive, then
have a flylead connecting up the power.
Did I mention USB didn't have enough oomph to power the CPLD, MCU *and* a disc
drive as well? You're going to need a 5V + 12V + whatever PSU for the drive,
but the box itself will snaffle power from the laptop/desktop machine you've
got it hooked up to.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
6 May
6 May
8:46 p.m.
From: Philip Pemberton <classiccmp at
philpem.me.uk>
Chuck Guzis wrote:
Hi
Not all 8 inch drives select out the index from the sectors. Only
the ones that say they are for hard sectored ( although, my
Nicolet 1080 uses the type that doesn't separate the two
and is hard sectored ).
I'd have to reread the documents on the SA drives but there
was something like the dash number that made the difference.
The 800/801 was with and without data/clock separator ( may
have these backwards ).
Look it up. The ones that state they were for hard sectored have
the separator.
Dwight
_________________________________________________________________
Download Messenger. Join the i?m Initiative. Help make a difference today.
http://im.live.com/messenger/im/home/?source=TAGHM_APR07
The ones I'm thinking of are 8" systems,
where the drive has separate
outputs for SECTOR and INDEX. There's no compelling reason to pay
attention to INDEX in many applications--and some systems reflect this.
OK then, looks like I *do* need to read the SA800 docs then...
7 May
7 May
3:43 a.m.
dwight elvey wrote:
I'd have to reread the documents on the SA drives
but there
was something like the dash number that made the difference.
The 800/801 was with and without data/clock separator ( may
have these backwards ).
You're absolutely correct (according to the Shugart SA800 OEM manual on
Bitsavers) - the SA800 only provides the Index pulse, the SA801 also provides
the Sector pulse, and splits the sector pulses from the index pulses.
Strange that the SA800 only provides an index pulse once per revolution - I
guess it's intended for soft-sector discs. Given that there's no indexing on
the hub like there is on 3.5" drives, the SA800 would probably output one
index pulse every time an index hole was detected - if you used soft-sector
discs that would be one pulse per rev, or 32+1 pulses if you used 32-sector
hard-sector discs.
All adds to the fun, I guess :)
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
4:29 a.m.
Philip Pemberton wrote:
Strange that the SA800 only provides an index pulse
once per revolution
- I guess it's intended for soft-sector discs.
I believe that's right; the 801 is the hard-sectored version.
The 850 is a double-sided version of the 800, and the 851 is a double-sided
version of the 801.
The 85x docs talk about MFM data though, whereas I don't think that the 80x
docs do. I'm not sure if there's any good technical reason that the 80x drives
can't handle an MFM data stream, though. (I think there might be some on-board
"helper" circuitry for separating FM clock/data bits on at least some of the
80x flavours - but I think this can be jumpered out so that the controller
does the stream encoding/decoding instead).
Given that there's no
indexing on the hub like there is on 3.5" drives, the SA800 would
probably output one index pulse every time an index hole was detected -
if you used soft-sector discs that would be one pulse per rev, or 32+1
pulses if you used 32-sector hard-sector discs.
Aren't hard-sectored 8" floppies available in more than just 32 sectors/track
flavours? It's no big deal if your circuitry is analysing timing relationships
to detect index pulse, but it obviously is if the circuitry's relying on
timing windows as the timing will be different for a 32-sector disk versus one
with n sectors...
(I've only got the SA400 manual here, but the index/sector detection circuitry
uses different timing depending on the media used - I presume because 5.25"
hard sectored media was also available with different numbers of sectors per
track)
cheers
Jules
--
"What progress. It's almost as good as taping it... on tapes which self
destruct in seven days."
- Bill Bailey on the BBC's "watch again" service
7:32 a.m.
Jules Richardson wrote:
The 85x docs talk about MFM data though, whereas I
don't think that the
80x docs do. I'm not sure if there's any good technical reason that the
80x drives can't handle an MFM data stream, though. (I think there might
be some on-board "helper" circuitry for separating FM clock/data bits on
at least some of the 80x flavours - but I think this can be jumpered out
so that the controller does the stream encoding/decoding instead).
IIRC, the SA800 provides:
/RDDATA: Raw data from the head - one pulse if there's a flux transition
/SEPDATA: Separated data - no clock pulses
/SEPCLK: Separated clock - no data pulses
So you'd just connect RD DATA up to the controller and let it do its own
thing. If you have a weird drive that only has SEPDATA and SEPCLK, you AND
them together to get the data and clock pulses together (they're active-low
remember - 1&1=1, everything else=0). Then just feed the AND gate output into
the RDDATA input on the controller.
Aren't hard-sectored 8" floppies available in
more than just 32
sectors/track flavours?
Yes, that's why I said "for 32-sector discs". IIRC you can get 8, 16 and
32-sector discs.
It's no big deal if your circuitry is analysing
timing relationships to detect index pulse, but it obviously is if the
circuitry's relying on timing windows as the timing will be different
for a 32-sector disk versus one with n sectors...
Yes, and the timing window is variable. Usually you'd have it set to
0.75Tindex (where Tindex = the time between two normal index pulses).
I think I've posted the pseudocode before - but basically, the pulse detector
looks for two index pulses that came less than Tthreshold after the previous
pulse. Set the threshold to 0.75Tindex and you can detect the "half way"
pulse, even if it's up to 0.25Tindex late, or if the next sector index pulse
is up to 0.25Tindex early.
This is one of those things that's easier to explain with a couple of pictures
(or a whiteboard)...
(I've only got the SA400 manual here, but the
index/sector detection
circuitry uses different timing depending on the media used - I presume
because 5.25" hard sectored media was also available with different
numbers of sectors per track)
On the SA800 you can change a few jumpers (more specifically, you cut a track
and bridge one of two others) to get 8, 16 or 32 sectors per track. The
manual's on Bitsavers if you're interested...
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
7:34 a.m.
From: Jules Richardson <julesrichardsonuk at
yahoo.co.uk>
Philip Pemberton wrote:
Hi
No, the difference between the 800 and 801's was the clock
separator. It had nothing to do with hard sectored.
As I stated before, there was a - option that told if there
was an index/sector separator. In any case, this circuit can
be bypassed to get the raw index signal.
It would be best to bypass any sector/index separator and
just use the raw signal. Reading and writing would be easier
then.
As for the location of the first sector, that could vary, even
for hard sectored. Most often, each sector had a header with
the sector number. It was quite common to interleave sectors
to speed disk activity. In these cases, the order of the sectors
need not follow any particular order from the index mark.
To my knowledge, the Polymorphic, Heathkit H8/89 and the
NorthStar were of this type. The index mark was only used
during formatting and as a rotational indicator.
This is not always true. My Nicolet splits the 32 hard sectors
into two 16 sector marked chunks. Only the first of these
two vertual sectors has any header and that is a track
indicator value. The rest is just data.
Dwight
Strange that the SA800 only provides an index
pulse once per revolution -
I guess it's intended for soft-sector discs.
I believe that's right; the 801 is the hard-sectored version.
The 850 is a double-sided version of the 800, and the 851 is a double-sided
version of the 801.
The 85x docs talk about MFM data though, whereas I don't think that the 80x
docs do. I'm not sure if there's any good technical reason that the 80x
drives can't handle an MFM data stream, though. (I think there might be
some on-board "helper" circuitry for separating FM clock/data bits on at
least some of the 80x flavours - but I think this can be jumpered out so
that the controller does the stream encoding/decoding instead).
I have 32 sectored 8 inch disk. This was the most common but I believe
there was a 16 and a 10 sectored 8 inch as well.
To my knowledge, the 5-1/4 only came in 10 sectored. This was used
by Polymophic and NorthStar, as well as a few others.
As for using a 800 or 801 as a MFM, one could do it but the filters where
real close to the required frequency edge on the read. There was a - option
for this as well. If one can find the documents, there was several
capacitors
and resistors that one could modify to get the desire frequency responce.
I made this modification my self for a friend back in the 80's but that
is all I remember.
Dwight
Given that there's no
indexing on the hub like there is on 3.5" drives, the SA800 would probably
output one index pulse every time an index hole was detected - if you used
soft-sector discs that would be one pulse per rev, or 32+1 pulses if you
used 32-sector hard-sector discs.
Aren't hard-sectored 8" floppies available in more than just 32
sectors/track flavours? It's no big deal if your circuitry is analysing
timing relationships to detect index pulse, but it obviously is if the
circuitry's relying on timing windows as the timing will be different for a
32-sector disk versus one with n sectors...
(I've only got the SA400 manual here, but the index/sector detection
circuitry uses different timing depending on the media used - I presume
because 5.25" hard sectored media was also available with different numbers
of sectors per track)
cheers
Jules
--
"What progress. It's almost as good as taping it... on tapes which self
destruct in seven days."
- Bill Bailey on the BBC's "watch again" service
_________________________________________________________________
Exercise your brain! Try Flexicon.
http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineap…
9:19 a.m.
On 07/05/2007 15:34, dwight elvey wrote:
I have 32 sectored 8 inch disk. This was the most
common but I believe
there was a 16 and a 10 sectored 8 inch as well.
To my knowledge, the 5-1/4 only came in 10 sectored.
I've seen 16-sectored 5-1/4" but I believe they were quite rare.
--
Pete Peter Turnbull
Network Manager
University of York
9:44 a.m.
Pete Turnbull wrote:
On 07/05/2007 15:34, dwight elvey wrote:
The SA400 manual lists SA105 and SA107 media as being hard-sectored and
compatible with the drive.
It takes some digging through the manual to find any more info, but piecing
together clues it would seem that SA105 is 16 sectors/track and SA107 is 10.
SA104 was the soft-sectored flavour.
cheers
Jules
--
"What progress. It's almost as good as taping it... on tapes which self
destruct in seven days."
- Bill Bailey on the BBC's "watch again" service
I have 32 sectored 8 inch disk. This was the most
common but I believe
there was a 16 and a 10 sectored 8 inch as well.
To my knowledge, the 5-1/4 only came in 10 sectored.
I've seen 16-sectored 5-1/4" but I believe they were quite rare.
7:53 a.m.
On 7 May 2007 at 6:29, Jules Richardson wrote:
Aren't hard-sectored 8" floppies available in
more than just 32 sectors/track
flavours? It's no big deal if your circuitry is analysing timing relationships
to detect index pulse, but it obviously is if the circuitry's relying on
timing windows as the timing will be different for a 32-sector disk versus one
with n sectors...
Yes, 8" disks also appear in 8 and 16 sector versions, although the 8-
sector ones are fairly uncommon. Many 8" drives that can take HS
media do so through a jumper settings on the drive board.
I've pushed MFM data through an SA-800 with no problems. I don't
keep the 800's around, however, as they're only single-sided and
don't seek very fast.
-----------------
About putting multiple drives on a single connector--some older
drives have removable pullups (usually 150 ohms); later ones have
lower-value builtin pullups. In any case, I'd limit the number of
drives on a single connector to 4. Two connectors driven by nice
beefy 50 ma OC drivers would make most people pretty happy, I'd
think.
Cheers,
Chuck
2:11 p.m.
About putting multiple drives on a single
connector--some older
drives have removable pullups (usually 150 ohms); later ones have
lower-value builtin pullups. In any case, I'd limit the number of
Surely you mean higher-value here. Typically 3.5" drives have 1k pull-up
resistors.
-tony
3:16 p.m.
On 7 May 2007 at 22:11, Tony Duell wrote:
Inverse thinking again! Yup, about 1-2K typically.
Cheers,
Chuck "Down is Up"
About putting
multiple drives on a single connector--some older
drives have removable pullups (usually 150 ohms); later ones have
lower-value builtin pullups. In any case, I'd limit the number of
Surely you mean higher-value here. Typically 3.5" drives have 1k pull-up
resistors.
3:48 p.m.
Tony Duell wrote:
Surely you mean higher-value here. Typically 3.5"
drives have 1k pull-up
resistors.
Most of the 3.5" drives I've used don't have any PURs at all. /INDEX (for
example) usually sits at 0V until you add a pull-up, then you start to see it
toggling.
Maybe I've just got a box of rather odd drives...
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
4:58 p.m.
On 7 May 2007 at 23:48, Philip Pemberton wrote:
Tony Duell wrote:
Yes, but Index is an output, meaning the host has the pullup. Have a
gander at one of the input lines, like WGATE.
Cheers,
Chuck
Surely you mean higher-value here. Typically
3.5" drives have 1k pull-up
resistors.
Most of the 3.5" drives I've used don't have any PURs at all. /INDEX (for
example) usually sits at 0V until you add a pull-up, then you start to see it
toggling.
1:30 p.m.
It's done.
$DEITY-knows-how-many hours of effort, and it's *finally* done.
Of course, I'm referring to the CPLD that drives the disc reader. All the
logic has been bolted together, compiled, synthesized and fitted into a Xilinx
XC95288XL-10 CPLD. I haven't run the test suite on it yet, but it passed the
timing analysis with a theoretical (emphasis on THEORETICAL) maximum clock
rate of 71.429MHz. Meaning it's sure as heck going to run fine at the 32MHz I
wanted to run it at, with a >2x safety margin. Which is quite nice, actually.
I still need to fiddle with the pinout and lay out the PCB, but once that's
done I can try and build up a prototype and have a play with it. At some point
I'll need to order a couple of XC95288XL chips from Digikey, the shipping
charges from which are going to utterly obliterate my 'buy a new lens for the
400D' budget...
Here's the stats, for anyone that actually cares:
-----
cpldfit: version J.33 Xilinx Inc.
Fitter Report
Design Name: floppyrw Date: 5- 7-2007, 9:11PM
Device Used: XC95288XL-10-TQ144
Fitting Status: Successful
************************* Mapped Resource Summary **************************
Macrocells Product Terms Function Block Registers Pins
Used/Tot Used/Tot Inps Used/Tot Used/Tot Used/Tot
223/288 ( 77%) 1243/1440 ( 86%) 615/864 ( 71%) 146/288 ( 51%) 50 /117 ( 43%)
-----
The CPLD code is zipped up at <http://www.philpem.me.uk/temp/floppyrw.zip> for
anyone that wants to take a peek. It's nothing really special, and floppyrw.v
is a huge mess, but it should give you some idea how it all works. I've tested
everything except the top-level module. You'll need some version of Xilinx ISE
(I used WebPack 9.1i) to compile it, and some knowledge of Verilog HDL to
modify it.
Have fun,
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
3:30 p.m.
Philip Pemberton wrote:
It's done.
$DEITY-knows-how-many hours of effort, and it's *finally* done.
Heh. Congrats :-)
What OS are you going to end up driving this from? (It is on a PCI card isn't
it, rather than a USB interface?)
Regarding earlier question about bringing some address lines out to the I/O
connector... the logical choices I suppose are a 40 pin header or a 50 pin
header.
40 doesn't seem like enough though assuming you keep odd pins as ground still;
it's only another 3 pins, and won't you need one of those for the write
precomp line for 8" drives?
50 would give you an extra 8 pins to play with[1] though. If one of those is
reserved for a write precomp line, that still leaves seven unused. Say reserve
four for addressing, and the other three for the uses which we haven't thought
of yet? ;-)
[1] Assuming the ability to have two drives on the same cable as per the PC
standard... if you don't do that I suppose it frees up a couple of pins of the
'standard' connector.
5:41 p.m.
Jules Richardson wrote:
What OS are you going to end up driving this from?
I dunno. If I have a lapse in sanity I'll write it in Java (which means it'll
run veeery slooowly on just about anything), otherwise I'll use it as an
excuse to learn wxWidgets (which means it'll run on Windows, Linux, OS X and
BSD, which covers about 95% of the market).
In any case, I want it to run on Linux as a bare minimum.
(It is on a PCI card
isn't it, rather than a USB interface?)
PCI?! PCI?! Why the hell would I do something as monumentally STUPID as that?
After all, the PCI-SIG's licence fees are 'just a bit' steep IMO :)
My plan is to do a USB version that's small enough to shove into a laptop bag
with a wall-wart and a 3.5" drive so that you can handle the "Joe Bloggs has
the discs, will let someone image them, but won't let the Royal Mail handle
them" type situations quite easily, while also being able to hook up adapter
cables to use other drive types (e.g. 8"). ST-506 is coming in Version 2 :)
Regarding earlier question about bringing some address
lines out to the
I/O connector... the logical choices I suppose are a 40 pin header or a
50 pin header.
Maybe. IDC headers are pretty cheap. I don't have many in stock ATM though -
just a couple of 34-way box headers and a few PC floppy cables.
40 doesn't seem like enough though assuming you
keep odd pins as ground
still; it's only another 3 pins, and won't you need one of those for the
write precomp line for 8" drives?
Argh, I'm going to have to read through those Shugart manuals again!
Speaking of precompensation, does anyone know anything about the innards of
the 'write precompensation' (early/late/normal) stuff that's generally a part
of most modern floppy controllers? I'm curious to find out what that actually
does, and if I need to do it on my controller.
50 would give you an extra 8 pins to play with[1]
though. If one of
those is reserved for a write precomp line, that still leaves seven
unused. Say reserve four for addressing, and the other three for the
uses which we haven't thought of yet? ;-)
You're after sixteen addressable drives then. Ooookay...
The plan is to have all four on the I/O (has anyone trademarked the name
'DriveBus'?) connector, then wire just the first two to the PC-FDD connector.
If you want to use a single drive, wire it up with a PC cable, then set the
software to 'single or double drive mode with PC selects'. Other modes might
include '8/16 drives with decoder' or '4 drives with one-hot/one-cold
selection'.
[1] Assuming the ability to have two drives on the
same cable as per the
PC standard... if you don't do that I suppose it frees up a couple of
pins of the 'standard' connector.
I'm keeping that in. I want to be able to hook up a 5.25" FDD and a 3.5" FDD
at the same time. Remember - I'm building this thing as a combination
analyser/imager (hence the name - Data Analysis and Recovery Toolkit) with the
primary goal being to be able to image 'odd' floppy formats that a PC
controller just can't touch.
There are a few other things I'd like it to be able to do:
- Can copy the BBC Elite floppy, copy protection and all (I know someone in
Stockport that has a BBC B and a copy of Elite - cloning his master disc
before his eyes without removing the protection would be fantastically cool,
if only to see the grin on his face)
- Can copy Amiga 'Rob Northen Copylock' protected discs, and read out the
disc serial number (this protection has been 'uncopiable without a Trace
duplicator' for far too long)
- Full decode support for Commodore GCR, Apple GCR, PC MFM, PC FM, and
whatever other formats I can get hold of formatting specs for. If/when I
release the hardware (I might do a small production run if anyone's
interested), I might do a "send me a disc and I'll add image and/or decode
support" type service. Could be fun.
I've got a couple of exams to study for this week, but I've got from Friday
night onwards to play with expensive CAD software, corrosive chemicals, hot
soldering irons and homebrew hardware. Yay me :)
FWIW, by "decode support", I mean "take the raw bitstream and turn it into
bytes, then decode those into sectors". I'm not doing filesystem decoding,
that can wait until later.
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
8:45 p.m.
On 8 May 2007 at 1:41, Philip Pemberton wrote:
Jules Richardson wrote:
I don't think there's anything that can't be handled with a DC-37
connector--and that's with 4 drive selects. You don't need the
separated data from 8" drives, so let's look at what signals you do
need:
DS0
DS1
DS2
DS3
MOTOR ON or HEAD LOAD*
SIDE SELECT
INDEX
TRACK 0
STEP
DIRECTION
READ DATA (RAW)
WRITE DATA
WRITE GATE
WRITE PROTECTED
SECTOR (if you want to use the 8" signal)
TG43
*Saying that both HDLD and MTRON are the same signal simplifies
accommodating 8" drives and doesn't hurt a thing.
16 signal lines + return = 32 pins. Some NEC 3.5" floppies have some
very strange "extra" signals, but they're the only ones I'm aware of.
Similarly, some early 8" drives wanted 3-phase stepping signals, but
I haven't seen a specimen in the last 20 years. Similarly, there are
drives with door locks and auto-ejects that can be ignored.
SImilarly, if you've got INDEX, you can derive READY yourself and you
probably don't care and don't want to deal with DISK CHANGED signals.
There's no point to using the 8" drive on-board FM data separator.
Why complicate things? Two DC-37 connectors will allow you to
control 8 drives and yet keep the cabling simple.
What OS are you going to end up driving this
from?
I dunno. If I have a lapse in sanity I'll write it in Java (which means it'll
run veeery slooowly on just about anything), otherwise I'll use it as an
excuse to learn wxWidgets (which means it'll run on Windows, Linux, OS X and
BSD, which covers about 95% of the market).
In any case, I want it to run on Linux as a bare minimum.
(It is on a PCI card
isn't it, rather than a USB interface?)
PCI?! PCI?! Why the hell would I do something as monumentally STUPID as that?
After all, the PCI-SIG's licence fees are 'just a bit' steep IMO :)
My plan is to do a USB version that's small enough to shove into a laptop bag
with a wall-wart and a 3.5" drive so that you can handle the "Joe Bloggs has
the discs, will let someone image them, but won't let the Royal Mail handle
them" type situations quite easily, while also being able to hook up adapter
cables to use other drive types (e.g. 8"). ST-506 is coming in Version 2 :)
Regarding earlier question about bringing some
address lines out to the
I/O connector... the logical choices I suppose are a 40 pin header or a
50 pin header.
Maybe. IDC headers are pretty cheap. I don't have many in stock ATM though -
just a couple of 34-way box headers and a few PC floppy cables.
> 40 doesn't seem like enough though assuming you keep odd pins as ground
> still; it's only another 3 pins, and won't you need one of those for the
> write precomp line for 8" drives? Speaking of precompensation, does anyone know anything
about the innards of
the 'write precompensation' (early/late/normal) stuff that's generally a part
of most modern floppy controllers? I'm curious to find out what that actually
does, and if I need to do it on my controller.
Generally write precompensation isn't used in FM mode. However, in
MFM, it comes into play on the inner tracks when domain edges get
"fuzzier", mostly as a result of the medium. To keep things as
distinct as possible, a clever kludge is used to either advance or
retard the start of a bit cell depending on current the bit being
written and the last two bits just written and the next bit to be
written:
Here are some common patterns and their precompensation (display this
with a monospaced font):
Bits just written Current bit Next bit Action
----------------- ----------- -------- ------
X1 1 0 Advance (early)
X0 1 1 Retard (late)
00 0 1 Advance
10 0 0 Retard
XX X X Nominal timing
The amount of precompensation on an 8" floppy is usually about 200
nsec. The logic for this becomes more apparent if you sketch out the
bit cells.
The usual way that precomp is determined in a controller is to run
the data stream through a shift register and use come combinatorial
logic to determine what should be done.
Typically, the data stream from most floppies is a bit "noisy"
(you'll see what I mean from some CW histograms). So you should have
the capability of rejecting a pulse that follows too soon after the
previous one. Better data separators can even fill in a missing
pulse if necessary.
Hope this helps!
Cheers,
Chuck
8 May
8 May
2:30 a.m.
Chuck Guzis wrote:
I don't think there's anything that can't
be handled with a DC-37
connector--and that's with 4 drive selects. You don't need the
separated data from 8" drives, so let's look at what signals you do
need:
DS0
DS1
DS2
DS3
MOTOR ON or HEAD LOAD*
SIDE SELECT
INDEX
TRACK 0
STEP
DIRECTION
READ DATA (RAW)
WRITE DATA
WRITE GATE
WRITE PROTECTED
SECTOR (if you want to use the 8" signal)
TG43
*Saying that both HDLD and MTRON are the same signal simplifies
accommodating 8" drives and doesn't hurt a thing.
Some drives have speed control on one of the pins (300/600 RPM, or 300/360
RPM), LED signal, motorised eject, disk change reset etc. - I suspect that it
doesn't hurt to have a few I/O lines set aside on the interface connector for
special cases.
Not to mention some drives getting power over the 'data' cable, but the less
said about those the better :-)
16 signal lines + return = 32 pins. Some NEC
3.5" floppies have some
very strange "extra" signals, but they're the only ones I'm aware of.
Similarly, some early 8" drives wanted 3-phase stepping signals, but
I haven't seen a specimen in the last 20 years. Similarly, there are
drives with door locks and auto-ejects that can be ignored.
I'm not sure that ignoring the less-common cases is a good idea though, simply
because *everything* is becoming less common now. I was amazed at how
difficult it was to find a 5.25" HD drive recently; they've all but vanished
despite being so common in PCs at one time. I expect getting a 5.25" 40T drive
is even harder for a lot of people.
There's no point to using the 8" drive
on-board FM data separator.
Why complicate things? Two DC-37 connectors will allow you to
control 8 drives and yet keep the cabling simple.
Wouldn't you have to have motors running on four drives at once, though? I'm
not sure that it matters in practice though as for an archival box I suppose
you only have one disk in one of the drives at any one time...
Generally write precompensation isn't used in FM
mode.
[snip]
Now that was interesting stuff... thanks.
cheers
Jules
9:18 a.m.
On 8 May 2007 at 4:30, Jules Richardson wrote:
Some drives have speed control on one of the pins
(300/600 RPM, or 300/360
RPM), LED signal, motorised eject, disk change reset etc. - I suspect that it
doesn't hurt to have a few I/O lines set aside on the interface connector for
special cases.
One of the problems in engineering is knowing when to stop. DC37
connectors are not uncommon, exist in IDC versions (easy attachment).
50-pin D-subs are far less common. IDC headers aren't made for
frequent use and are subject to pin breakage and stress on the PCB.
Most of the signals you're talking about above are slow signals--
there's no particular need for those extra 5 pins that I mentioned to
be paired with a return, so you could have 5 additional programmable
pins (1 input, 4 outputs?) if needed. But the basic 32 lines I
specified will work with 95%+ of existing drives.
But please let's not run power over the cable--I've seen too many
toasted drives that resulted from someone getting something wrong.
Wouldn't you have to have motors running on four
drives at once, though? I'm
not sure that it matters in practice though as for an archival box I suppose
you only have one disk in one of the drives at any one time...
Before IBM came along, there were plenty of systems that ran the
5.25" drive motors at the same time. IBM gave up 2 drive selects
with their twist and got to use a feebler PSU on the 5150. Some DTC
hard disk/SCSI controllers gave back 4-drive operation by using an
"untwisted" cable. I don't see that as a problem.
Cheers,
Chuck
9:37 a.m.
Chuck Guzis wrote:
The only issue I have is that this is for an archival box, where it's probably
not a good idea to have ancient media spinning any longer than necessary. However:
1) I seem to find that if a disk is going to shed its coating [1] it does
so within the first couple of disk revolutions,
2) As above, usage of any such archival device probably doesn't involve
typically having more than one disk inserted at a time anyway, so the motors
are only on for the length of time needed to access that disk.
... so maybe I'm worrying about nothing.
[1] Grey-labeled 5.25" Wabash disks seem to be guaranteed to leave me with a
clear disk of plastic and drive heads caked in magnetic coating, regardless of
how they've been stored :-(
On 8 May 2007 at 4:30, Jules Richardson wrote:
I hear ya :-)
Some drives have speed control on one of the pins
(300/600 RPM, or 300/360
RPM), LED signal, motorised eject, disk change reset etc. - I suspect that it
doesn't hurt to have a few I/O lines set aside on the interface connector for
special cases.
One of the problems in engineering is knowing when to stop. DC37
connectors are not uncommon, exist in IDC versions (easy attachment).
50-pin D-subs are far less common. IDC headers aren't made for
frequent use and are subject to pin breakage and stress on the PCB.
That one is a good point. I suppose that's up to Phil as to where he's aiming
this. Personally I'd use it more as an internal board with lots of drives
permanently connected - but I do also like his scenario of being able to just
take it on the road with a laptop and a single drive connected.
I suppose in the latter situation it needs a case anyway though, and the
solution might be to have IDC headers on the board but taken out to the DC37
on the case for plugging into a drive.
Most of the signals you're talking about above are
slow signals--
Good point.
there's no particular need for those extra 5 pins
that I mentioned to
be paired with a return, so you could have 5 additional programmable
pins (1 input, 4 outputs?) if needed.
I know the Manta SCSI-floppy boards that I have are set up like that; I think
they have three programmable outputs and then another pin that can be
configured as either an input or output (I know the manual states that pin 2
was an input on some drives and an output on others)
But please let's not run power over the cable
Heh heh. Definitely agree there!
Wouldn't
you have to have motors running on four drives at once, though? I'm
not sure that it matters in practice though as for an archival box I suppose
you only have one disk in one of the drives at any one time...
Before IBM came along, there were plenty of systems that ran the
5.25" drive motors at the same time. IBM gave up 2 drive selects
with their twist and got to use a feebler PSU on the 5150. Some DTC
hard disk/SCSI controllers gave back 4-drive operation by using an
"untwisted" cable. I don't see that as a problem. 
10 May
10 May
6:19 p.m.
New subject: Oxide shedding (was Re: Floppy disc reader/writer status report)
Hi,
[1] Grey-labeled 5.25" Wabash disks seem to be
guaranteed to
leave me with a clear disk of plastic and drive heads caked in
magnetic coating, regardless of how they've been stored :-(
Superb....I've got a fair few of those in my Atari and Beeb disc boxes. :-(
Is there a list anywhere listing which types of discs have these oxide
shedding problems?
TTFN - Pete.
8 May
8 May
3:29 p.m.
One of the problems in engineering is knowing when to stop. DC37
connectors are not uncommon, exist in IDC versions (easy attachment).
50-pin D-subs are far less common. IDC headers aren't made for
They're not particularly hard to get (I can't think of a company the
sells DC37s but not DD50s, for example), but the IDC version of the DD50
is darn expensive (I speak from bitter experience here).
frequent use and are subject to pin breakage and
stress on the PCB.
There is, of course, the 50 pin microribbon connector. That's fairly easy
to get in solder and IDC versions.
-tony
2:12 a.m.
Philip Pemberton wrote:
:-) You know I'd assumed that there was some sort of "testing/hobbyist"
scenario where you could just do what you wanted without fear of stomping all
over commercial cards...
Scavenging from scrap I/O cards works well.
That's going from hazy memory of discussions on here... I'm rather new to the
8" drive game. I gather there's an interface line which gets toggled on at
least some 8" drives and tells the drive to do write precomp; I think this
line was replaced with another signal when things moved to 5.25" drives
though, so it's not available separately on the standard 34-way header.
:-)
Not really, but if you have 7 extra lines to play with it makes sense to set
aside a few of them for addressing.
Hook up an 8", 5.25" DD, 5.25" HD, 3.5" HD and 3" drive, and you
already need
three lines for addressing - that's before worrying about other oddball stuff.
Better safe than sorry...
[Out of interest, I wonder if this gadget will be able to drive one of those
floppy tape units? I've got no idea how their protocol works...]
Absolutely... hence the need for having lots of drives connected at once via
an addressing scheme. It just feels a bit 'cleaner' to have one drive per
cable and have termination set on all drives, somehow. But never mind, as the
way you're doing it, it should still work in that configuration anyway :)
Jules Richardson wrote:
It shouldn't be too bad to be honest - there's going to be a fair bit of
"wait
for user input" and "wait for device" in there, and Java tends to be
reasonable when processing raw data if there's not lots of thread
synchronisation and object creation in the way.
It might be let down by availability of bit-level operations, but then most
languages are...
What OS are you going to end up driving this
from?
I dunno. If I have a lapse in sanity I'll write it in Java (which means
it'll run veeery slooowly on just about anything) otherwise I'll use it
as an excuse to learn wxWidgets (which means it'll run on Windows,
Linux, OS X and BSD, which covers about 95% of the market).
I was thinking GTK+ :-) But yeah, doesn't matter... a goal of portability's
the main thing to my mind. I'm not sure what device access is like under
Windows (particularly from Java) - from Linux / Mac it's probably just as
simple as opening an I/O stream and reading/writing.
(It is on a
PCI card isn't it, rather than a USB interface?)
PCI?! PCI?! Why the hell would I do something as monumentally STUPID as
that? After all, the PCI-SIG's licence fees are 'just a bit' steep IMO :)
My plan is to do a USB version
USB?! USB?! :-) Urgh... SCSI, please...
But seriously, yes an external device is probably more useful than an internal
card I think. And an external card can always be mounted internally anyway :-)
that's small enough to shove into a
laptop bag with a wall-wart and a 3.5" drive so that you can handle the
"Joe Bloggs has the discs, will let someone image them, but won't let
the Royal Mail handle them"
Very good point.
ST-506 is coming in Version 2 :)
Hmmm. I'm not sure if the current implementation's quick enough though... you
probably need to be sampling at around 50MHz for ST506. But I assume there are
faster chips out there you can use?
Regarding
earlier question about bringing some address lines out to
the I/O connector... the logical choices I suppose are a 40 pin header
or a 50 pin header.
Maybe. IDC headers are pretty cheap. I don't have many in stock ATM
though - just a couple of 34-way box headers and a few PC floppy cables. 40 doesn't
seem like enough though assuming you keep odd pins as
ground still; it's only another 3 pins, and won't you need one of
those for the write precomp line for 8" drives?
Argh, I'm going to have to read through those Shugart manuals again! 50 would give
you an extra 8 pins to play with[1] though. If one of
those is reserved for a write precomp line, that still leaves seven
unused. Say reserve four for addressing, and the other three for the
uses which we haven't thought of yet? ;-)
You're after sixteen addressable drives then. Ooookay... [1] Assuming
the ability to have two drives on the same cable as per
the PC standard... if you don't do that I suppose it frees up a couple
of pins of the 'standard' connector.
I'm keeping that in. I want to be able to hook up a 5.25" FDD and a 3.5"
FDD at the same time. Remember - I'm building this thing as a
combination analyser/imager (hence the name - Data Analysis and Recovery
Toolkit) with the primary goal being to be able to image 'odd' floppy
formats that a PC controller just can't touch. - Full decode support for Commodore GCR, Apple GCR,
PC MFM, PC FM, and
whatever other formats I can get hold of formatting specs for.
I saw some nice documentation about how M2FM worked *somewhere*. I'll shout if
I remember where it was now.
If/when I
release the hardware (I might do a small production run if anyone's
interested)
I'd have one in preference to a Catweasel board...
FWIW, by "decode support", I mean "take
the raw bitstream and turn it
into bytes, then decode those into sectors". I'm not doing filesystem
decoding, that can wait until later.
Definitely a separate project!
cheers
Jules
--
"What progress. It's almost as good as taping it... on tapes which self
destruct in seven days."
- Bill Bailey on the BBC's "watch again" service
3:44 a.m.
Jules Richardson wrote:
Have you ever actually used Java on anything less than a 1GHz box? When my
laptop steps down to 500MHz, Java apps become intolerably slow. Admittedly
it's nice because a lot of the data processing algorithms are already
implemented and ready for use, but for some thing's it's just too slow. Not to
mention the amount of memory it hogs just for doing something simple like a
"hello world" window.
Quick question - does the write protect sensor on floppy drives also lock out
the write circuitry, or does the drive depend on the controller not trying to
do silly things like writing to protected floppies?
I was joking, but ISE reckons the logic's good to 70MHz. That's still nearly a
50% safety margin over 50MHz. That said, I don't have any ST506 type drives,
but making a "semi virtual disc" clone for the ST506 interface would be quite
neat.
Ho yus. There are far too many weird formats out there to handle them all.
Better IMO to just handle bit-level decoding in DART, then write something
else to handle splitting out the data from the sector headers, etc.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
I dunno. If I
have a lapse in sanity I'll write it in Java (which
means it'll run veeery slooowly on just about anything)
It shouldn't be too bad to be honest - there's going to be a fair bit of
"wait for user input" and "wait for device" in there, and Java tends
to
be reasonable when processing raw data if there's not lots of thread
synchronisation and object creation in the way. I was thinking GTK+ :-)
So compile wxWidgets to use the GTK backend - I get my object-oriented API
(I've been spoiled by Swing), you get your cute little GTK widgets. Win-win :)
But yeah, doesn't matter... a goal of
portability's the main thing to my mind. I'm not sure what device access
is like under Windows (particularly from Java) - from Linux / Mac it's
probably just as simple as opening an I/O stream and reading/writing.
On Linux you've got LibUSB, which has been ported to Windows too (but works in
a slightly different way due to the kernel-mode and driver differences - on
Linux it uses usbdevfs, on Windows there's a device driver). I have a sneaking
suspicion LibUSB also works on the BSDs...
Ah, here we go (from libusb.sourceforge.net):
Operating System support: Linux, FreeBSD, NetBSD, OpenBSD, Darwin, MacOS X
And for LibUSB-win32:
Libusb-win32 is a port of the USB library libusb to the Windows operating
systems (Win98SE, WinME, Win2k, WinXP). The library allows user space
applications to access any USB device on Windows in a generic way without
writing any line of kernel driver code.
Like I said - I get a single API, everyone else gets cross-platform
compatibility. Win-win again.
:-) You know I'd assumed that there was some sort
of "testing/hobbyist"
scenario where you could just do what you wanted without fear of
stomping all over commercial cards...
It's the same as USB really - you pick a manufacturer ID that isn't in the
Linux PCI-ID list, then pray it doesn't conflict. Then there's the bus
protocol - for USB I can use a PIC18F4550 which has a built-in USB slave
adapter, for PCI I need to cook up the PHY and a VxD/kernel driver for it.
Lots of extra effort for very little gain.
USB?! USB?! :-) Urgh... SCSI, please...
USB: Plug in, install drivers, play.
SCSI: Plug in, fiddle with terminators, play with cables, replace cables,
replace terminators, replace host adapter card, replace terminators again, try
with terminators on and off, try daisychaining in various combinations, give
up, go home.
I don't like SCSI much, can you tell?
But seriously, yes an external device is probably more
useful than an
internal card I think. And an external card can always be mounted
internally anyway :-)
Oh yes - in this case you just chop the end off a USB A-B cable, screw the
external device down to something, then crimp a connector onto the B end of
the cable and plug it into the USB header on the motherboard. External becomes
internal, nice and easy. It's much harder to do the reverse, especially with
PCI cards.
that's
small enough to shove into a laptop bag with a wall-wart and a
3.5" drive so that you can handle the "Joe Bloggs has the discs, will
let someone image them, but won't let the Royal Mail handle them"
Very good point. ST-506 is
coming in Version 2 :)
Hmmm. I'm not sure if the current implementation's quick enough
though... you probably need to be sampling at around 50MHz for ST506.
But I assume there are faster chips out there you can use? Scavenging from scrap I/O cards works well.
Only if you've got scrap I/O cards to scavenge from.
That's going from hazy memory of discussions on
here... I'm rather new
to the 8" drive game. I gather there's an interface line which gets
toggled on at least some 8" drives and tells the drive to do write
precomp; I think this line was replaced with another signal when things
moved to 5.25" drives though, so it's not available separately on the
standard 34-way header.
You're not as new as I am - I don't even HAVE an 8" drive. I want to get a
5.25" DD (both 40 and 80 track variants) first, though, as mine's a HD and I
can't tell how to jumper it for 300RPM. It's a YE Data YD-380B, just on the
offchance anyone has a jumper list knocking about... Otherwise I might
dismantle the motor board and trace the speed control pin back to its source...
[Out of interest, I wonder if this gadget will be able
to drive one of
those floppy tape units? I've got no idea how their protocol works...]
Might be able to. It'd be mostly a case of writing software, assuming the data
format is fairly standard MFM.
Absolutely... hence the need for having lots of drives
connected at once
via an addressing scheme. It just feels a bit 'cleaner' to have one
drive per cable and have termination set on all drives, somehow. But
never mind, as the way you're doing it, it should still work in that
configuration anyway :)
So you think it'd be better to have TTL out of the I/O port, then have a set
of O/C buffers on the adapter cards, and have a separate O/C buffer set for
the PC FDD port? Hmm, the cost just keeps mounting...
I saw some nice documentation about how M2FM worked
*somewhere*. I'll
shout if I remember where it was now.
It's in the Intel Intellec disc controller manuals (on Bitsavers no less), if
this page is accurate:
<http://retrotechnology.com/herbs_stuff/drive.html>
I'd have one in preference to a Catweasel board...
OK, that's one potential sale then. Any more takers? :P
FWIW, by
"decode support", I mean "take the raw bitstream and turn it
into bytes, then decode those into sectors". I'm not doing filesystem
decoding, that can wait until later.
Definitely a separate project!
4:37 a.m.
Philip Pemberton wrote:
That works. I know nothing about wxWidgets or GTK+, incidentally, other than
being aware that there is a Windows port of the latter :-)
If I have to have some form of cross-platform graphical UI it gets done in
Java (or a web browser via PHP), if it just needs a simple Linux text-mode UI
then it gets done in C, and if it needs to run solely on MS Windows it doesn't
get done at all :-)
:-) Oddly enough I've had exactly the opposite experience to you, and it's
been USB that's plagued with problems, whilst SCSI has Just Worked*.
* Except for whenever I go near a bit of NeXT hardware, where the SCSI bus
automagically seems to break if I so much as look at it funny.
I was joking
Well don't! :) Seriously, it's a project that could do with being done by
someone, and in theory it is just a big, fast floppy drive full 'o bits, so if
the interface can be run fast enough (and contain enough buffer memory) it's
possible it could be done.
More than you can ever possibly need on your doorstep via your local Freecycle
list :-)
I'm really not sure. I don't know if those sorts of drives just looked like a
big floppy disk (and control was done purely via twiddling head select / step
/ direction), or whether they actually interpreted the data stream from the
FDC in order to carry out commands.
It's not even as high as low priority (!) but I was just curious...
Well I figure it's probably two or three 74xx series ICs, so it's not
expensive/complex. Certainly cheaper than having to build/buy more than one
card. I suppose it depends on typical application, but I suspect any serious
archive box is going to have several drives attached.
I think the main thing though is to have some form of addressing I/O brought
out on the board which can be under software control - then there's at least
the scope for doing this kind of thing. (and it sure beats having a separate
parallel port bodge or something to provide that :-)
Yeah, that was probably it actually. We've got quite a bit of Intellec stuff
at Bletchley.
cheers
J.
--
"What progress. It's almost as good as taping it... on tapes which self
destruct in seven days."
- Bill Bailey on the BBC's "watch again" service
Have you ever actually used Java on anything less than
a 1GHz box?
Yes, constantly for over ten years :-)
When
my laptop steps down to 500MHz, Java apps become intolerably slow.
You know, it seems to depend largely on the VM. Sun have lost the plot in the
last few years and just kept on piling features in when they should have given
up and declared "this is Java" about five years ago. The older VMs scream
along very nicely, but I know the modern one I've got on the laptop is an
absolute dog :(
Admittedly it's nice because a lot of the data
processing algorithms are
already implemented and ready for use, but for some thing's it's just
too slow.
Generally it's very good providing you're not trying to create massive Swing
applications with it using scads of eye-candy. Unfortunately that's exactly
what a lot of people try and do first, and then it gets a bad rep for being slow.
Not to mention the amount of memory it hogs just for
doing
something simple like a "hello world" window.
I'd suggest there are far better languages for writing "Hello World" in ;-)
I was thinking
GTK+ :-)
So compile wxWidgets to use the GTK backend - I get my object-oriented
API (I've been spoiled by Swing), you get your cute little GTK widgets.
Win-win :) USB?! USB?!
:-) Urgh... SCSI, please...
USB: Plug in, install drivers, play.
SCSI: Plug in, fiddle with terminators, play with cables, replace
cables, replace terminators, replace host adapter card, replace
terminators again, try with terminators on and off, try daisychaining in
various combinations, give up, go home.
I don't like SCSI much, can you tell? External becomes internal, nice and easy. It's
much harder to do the
reverse, especially with PCI cards.
It's one of the major reasons I don't want a Catweasel, to be honest.
Quick question - does the write protect sensor on
floppy drives also
lock out the write circuitry, or does the drive depend on the controller
not trying to do silly things like writing to protected floppies?
I suspect that's open to interpretation by the drive manufacturer, to be honest.
ST-506 is coming in Version 2 :)
Hmmm. I'm not sure if the current implementation's quick enough
though... you probably need to be sampling at around 50MHz for ST506.
But I assume there are faster chips out there you can use? Scavenging
from scrap I/O cards works well.
Only if you've got scrap I/O cards to scavenge from. and I can't tell how to jumper it for 300RPM.
It's a YE Data YD-380B,
just on the offchance anyone has a jumper list knocking about...
I'll have a look...
[Out of
interest, I wonder if this gadget will be able to drive one of
those floppy tape units? I've got no idea how their protocol works...]
Might be able to. It'd be mostly a case of writing software, assuming
the data format is fairly standard MFM. Absolutely...
hence the need for having lots of drives connected at
once via an addressing scheme. It just feels a bit 'cleaner' to have
one drive per cable and have termination set on all drives, somehow.
But never mind, as the way you're doing it, it should still work in
that configuration anyway :)
So you think it'd be better to have TTL out of the I/O port, then have a
set of O/C buffers on the adapter cards, and have a separate O/C buffer
set for the PC FDD port? Hmm, the cost just keeps mounting... I saw some
nice documentation about how M2FM worked *somewhere*. I'll
shout if I remember where it was now.
It's in the Intel Intellec disc controller manuals (on Bitsavers no
less), if this page is accurate:
<http://retrotechnology.com/herbs_stuff/drive.html>
4:48 a.m.
On 08/05/2007 11:44, Philip Pemberton wrote:
Quick question - does the write protect sensor on
floppy drives also
lock out the write circuitry, or does the drive depend on the controller
not trying to do silly things like writing to protected floppies?
Normally the write protect does indeed disable the write circuitry, at
least on 5.25" drives and all the 8" ones I've come across.
> That's going from hazy memory of discussions
on here... I'm rather new
> to the 8" drive game. I gather there's an interface line which gets
> toggled on at least some 8" drives and tells the drive to do write
> precomp; I think this line was replaced with another signal when
> things moved to 5.25" drives though, so it's not available separately
> on the standard 34-way header.
More to do with write current rather than precomp. It does exist on
early 5.25" drives, on pin 2.
You're not as new as I am - I don't even HAVE
an 8" drive. I want to get
a 5.25" DD (both 40 and 80 track variants) first, though, as mine's a HD
and I can't tell how to jumper it for 300RPM. It's a YE Data YD-380B,
just on the offchance anyone has a jumper list knocking about...
Otherwise I might dismantle the motor board and trace the speed control
pin back to its source...
Pin 2 on 5.25" HD drives is actually supposed to control the write
current (ie it's the density select), but is very often jumpered or even
hardwired to change the speed as well. On some really old 5.25" drives,
pin 2 was actually TG43 (Track Greater than 43), the same signal as
found on 8" drives to control the write current.
--
Pete Peter Turnbull
Network Manager
University of York
12:24 p.m.
Quick question - does the write protect sensor on
floppy drives also
lock out the write circuitry, or does the drive depend on the controller
not trying to do silly things like writing to protected floppies?
The write protect circuit does, indeed, block writing.
However, there can be exceptions in some of the weirder systems. For
example, the Apple ][ relies on the controller, not the drive.
7:11 a.m.
On Tuesday 08 May 2007 06:44, Philip Pemberton wrote:
Jules Richardson wrote:
It seems to me that it'd make more sense to write some sort of UI in
plain ANSI C, with a text-based UI. Worry about the GUI part later
(and then you can feel free to use whatever whiz-bang graphics you want
without annoying people like me, if it's got a good CLI).
Possibly just write a library for doing basically everything you want to
do with the device, and distribute that with some sort of API
reference, which should make writing a clean/portable/changeable UI
that much easier.
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu
The Computer Refuge --- http://computer-refuge.org
I was thinking GTK+ :-)
So compile wxWidgets to use the GTK backend - I get my
object-oriented API (I've been spoiled by Swing), you get your cute
little GTK widgets. Win-win :) 
8 p.m.
On May 8, 2007, at 10:11 AM, Patrick Finnegan wrote:
It seems to me that it'd make more sense to write some sort of UI in
plain ANSI C, with a text-based UI. Worry about the GUI part later
(and then you can feel free to use whatever whiz-bang graphics you
want
without annoying people like me, if it's got a good CLI).
Possibly just write a library for doing basically everything you
want to
do with the device, and distribute that with some sort of API
reference, which should make writing a clean/portable/changeable UI
that much easier.
This is a fantastic way to do things like this...If more software
were developed in this manner, I'd have torn out a lot less hair by now.
-Dave
--
Dave McGuire
Port Charlotte, FL
I was thinking GTK+ :-)
So compile wxWidgets to use the GTK backend - I get my
object-oriented API (I've been spoiled by Swing), you get your cute
little GTK widgets. Win-win :)
8:38 p.m.
On Tuesday 08 May 2007 23:00, Dave McGuire wrote:
On May 8, 2007, at 10:11 AM, Patrick Finnegan wrote:
I think this is why I can't stand to work for a company that develops
software (as I had in the past). Too many cut corners, assuming 100% of
their users are idiots, and trying to develop code by piling more and
more crap onto their old code base.
I'm really, REALLY glad thatI don't work for that place anymore, and I
work soemwhere that sysadmins actually write code, debug OSes, and are
encouraged to make things clean and reusable, and avoid hacks.
Oddly enough, since we have the source code to the commercial HSM at
work, I'm pretty sure that we know how it works (and can debug it)
better than the current vendor can (few, if any, of the original
programmers for the code still work on it, as the software has gone
through quite a few corporate acquisitions).
In fact, I can't rememeber a single bug report that we've submitted in
the past year or so, which we haven't figured out the fix for before
EM^Wthe vendor got back to us with any sort of usable workaround.
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Possibly just write a library for doing basically
everything you
want to
do with the device, and distribute that with some sort of API
reference, which should make writing a clean/portable/changeable UI
that much easier.
This is a fantastic way to do things like this...If more software
were developed in this manner, I'd have torn out a lot less hair by
now.
9 May
9 May
10:36 p.m.
On May 8, 2007, at 11:38 PM, Patrick Finnegan wrote:
Yep. That sort of crap is why I abandoned almost all commercial
software. It's just not worth fighting with companies whose primary
motivation is to make money at any cost, customers be damned.
-Dave
--
Dave McGuire
Port Charlotte, FL
This is a
fantastic way to do things like this...If more software
were developed in this manner, I'd have torn out a lot less hair by
now.
I think this is why I can't stand to work for a company that develops
software (as I had in the past). Too many cut corners, assuming
100% of
their users are idiots, and trying to develop code by piling more and
more crap onto their old code base.
I'm really, REALLY glad thatI don't work for that place anymore, and I
work soemwhere that sysadmins actually write code, debug OSes, and are
encouraged to make things clean and reusable, and avoid hacks.
Oddly enough, since we have the source code to the commercial HSM at
work, I'm pretty sure that we know how it works (and can debug it)
better than the current vendor can (few, if any, of the original
programmers for the code still work on it, as the software has gone
through quite a few corporate acquisitions).
In fact, I can't rememeber a single bug report that we've submitted in
the past year or so, which we haven't figured out the fix for before
EM^Wthe vendor got back to us with any sort of usable workaround. 
10:48 p.m.
Dave McGuire wrote:
http://www.catb.org/~esr/jargon/html/meaning-of-hack.html
Section on "Robin Hood" and "Friar Tuck". Customers getting ignored
can
lead to interesting happenings.
Peace... Sridhar
In fact, I
can't rememeber a single bug report that we've submitted in
the past year or so, which we haven't figured out the fix for before
EM^Wthe vendor got back to us with any sort of usable workaround.
Yep. That sort of crap is why I abandoned almost all commercial
software. It's just not worth fighting with companies whose primary
motivation is to make money at any cost, customers be damned. 
10 May
10 May
2:34 a.m.
New subject: Offtopic? ESR's Jargon File
On Thu, 2007-05-10 at 01:48 -0400, Sridhar Ayengar wrote:
is to make money at any cost, customers be damned.
http://www.catb.org/~esr/jargon/html/meaning-of-hack.html
Is anyone else seeing broken UTF-8 characters on the Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty.
Looks awfy like it's been pasted from an MS Word doc - surely not?
Gordon
5:41 a.m.
New subject: Offtopic? ESR's Jargon File
Gordon JC Pearce wrote:
I'm seeing the messed-up characters too, and I'm also using a Mozilla
browser. In my case, Seamonkey 1.1.1.
Peace... Sridhar
is to make
money at any cost, customers be damned.
http://www.catb.org/~esr/jargon/html/meaning-of-hack.html
Is anyone else seeing broken UTF-8 characters on the Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty.
Looks awfy like it's been pasted from an MS Word doc - surely not? 
6:03 a.m.
New subject: Offtopic? ESR's Jargon File
On 5/10/07, Sridhar Ayengar <ploopster at gmail.com> wrote:
Gordon JC Pearce wrote:
And Firefox 1.5.0.10 (Centos 4.4).
So I doubt we are imagining it; the question is, does it look good
under _any_ browser?
-ethan
Is anyone else seeing broken UTF-8 characters on the Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty.
I'm seeing the messed-up characters too, and I'm also using a Mozilla
browser. In my case, Seamonkey 1.1.1.
10:31 a.m.
New subject: Offtopic? ESR's Jargon File
On 10/05/2007 13:41, Sridhar Ayengar wrote:
I see broken UTF-8 characters too, using Firefox 2.0.0.3 or 1.5.0.11
under Windows XP SP2. I see the same crap with Internet Explorer 7
(7.0.5730.11).
--
Pete Peter Turnbull
Network Manager
University of York
Gordon JC Pearce wrote:
Is anyone else seeing broken UTF-8 characters on the Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty.
Looks awfy like it's been pasted from an MS Word doc - surely not?
I'm seeing the messed-up characters too, and I'm also using a Mozilla
browser. In my case, Seamonkey 1.1.1.
5:46 a.m.
New subject: Offtopic? ESR's Jargon File
Gordon JC Pearce wrote:
Is anyone else seeing broken UTF-8 characters on the
Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty.
Same here, with Firefox 2.0.0.3 on Windows 2000 SP4 and Firefox 2.0 on Fedora
Core 6.
Looks awfy like it's been pasted from an MS Word
doc - surely not?
<meta name="generator" content="DocBook XSL Stylesheets
V1.61.0"/>
So either the Docbook source or Docbook->XHTML converter he's using is FUBAR.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
6:17 a.m.
New subject: Offtopic? ESR's Jargon File
Philip Pemberton wrote:
Gordon JC Pearce wrote:
I sent an email to Eric Raymond. We'll see what happens.
Peace... Sridhar
Is anyone else seeing broken UTF-8 characters on
the Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty.
Same here, with Firefox 2.0.0.3 on Windows 2000 SP4 and Firefox 2.0 on
Fedora Core 6.
Looks awfy like it's been pasted from an MS
Word doc - surely not?
<meta name="generator" content="DocBook XSL Stylesheets
V1.61.0"/>
So either the Docbook source or Docbook->XHTML converter he's using is
FUBAR. 
11:35 a.m.
New subject: Offtopic? ESR's Jargon File
It was thus said that the Great Philip Pemberton once stated:
Gordon JC Pearce wrote:
It's actually the HTTP protocol in this case. If you select UTF-8 encoding (under
Firefox, "View -> Character Encodings -> UTF-8" you'll see the page
correctly. Internally, the page is set to UTF-8 (within the <?xml>
processing tag) but Firefox *has* to accept the character set that Apache
sends (in this case, ISO-8859-1, which is the Apache default by the way) and
interpret it that way. So even though the document itself specifies UTF-8,
becasue the way conflicting character set information is resolved, the HTTP
sever (in this case, Apache) wins (wierd, I know, but that's the way it is).
-spc (So there you go)
Is anyone else seeing broken UTF-8 characters on
the Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty.
Same here, with Firefox 2.0.0.3 on Windows 2000 SP4 and Firefox 2.0 on
Fedora Core 6.
Looks awfy like it's been pasted from an MS
Word doc - surely not?
<meta name="generator" content="DocBook XSL Stylesheets
V1.61.0"/>
So either the Docbook source or Docbook->XHTML converter he's using is
FUBAR.
11:59 p.m.
New subject: Offtopic? ESR's Jargon File
On Thu, 2007-05-10 at 14:35 -0400, Sean Conner wrote:
processing tag) but Firefox *has* to accept the
character set that Apache
sends (in this case, ISO-8859-1, which is the Apache default by the way) and
Yes, after a bit of digging I suspected a bit of Apache
misconfiguration.
Gordon
5:47 a.m.
New subject: Offtopic? ESR's Jargon File
is to make
money at any cost, customers be damned.
http://www.catb.org/~esr/jargon/html/meaning-of-hack.html
Is anyone else seeing broken UTF-8 characters on the Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty. 
6:23 a.m.
New subject: Offtopic? ESR's Jargon File
On May 10, 2007, at 6:47 AM, Cameron Kaiser wrote:
It's broken here too, Camino 1.0.4 on OS X 10.4.9.
It's worth pointing out that it does this in Safari and Internet
Explorer (Mac) as well.
is to make money at any cost, customers be damned.
http://www.catb.org/~esr/jargon/html/meaning-of-hack.html
Is anyone else seeing broken UTF-8 characters on the Jargon File?
I'm
using Firefox 2.0.0.3 on Ubuntu Feisty. 
6:53 a.m.
New subject: Offtopic? ESR's Jargon File
Is anyone else seeing broken UTF-8 characters on the
Jargon File?
I'm using Firefox 2.0.0.3 on Ubuntu Feisty.
Looks awfy like it's been pasted from an MS Word
doc - surely not?
Over here, with lynx, the page is reported as
Charset: iso-8859-1
and I see things like
The Meaning of ?Hack?
Prev? Appendix? A.? Hacker Folklore ? Next
The Meaning of ?Hack?
(in case the list mangles that, here it is with ASCII replacements for
the odd characters:
The Meaning of @Hack@
Prev# Appendix# #.# Hacker Folklore # Next
The Meaning of @Hack@
where @ replaces 8859-1 a-circumflex and # replaces A-circumflex.)
This is not the usual Windows brokenness that calls for demoroniser
(google it for those who don't know it and want to - but be sure to
spell it, as I did, with -s- instead of -z-). It's also not the usual
UTF-8 issue I've seen; when that strikes, I get two (or occasionally
more) non-ASCII characters displayed for each non-ASCII character used
by the source.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
7:17 p.m.
New subject: Offtopic? ESR's Jargon File
On Thursday 10 May 2007 05:34, Gordon JC Pearce wrote:
On Thu, 2007-05-10 at 01:48 -0400, Sridhar Ayengar
wrote:
Is that what those are? I was wondering...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
is to make money at any cost, customers be
damned.
http://www.catb.org/~esr/jargon/html/meaning-of-hack.html
Is anyone else seeing broken UTF-8 characters on the Jargon File? I'm
using Firefox 2.0.0.3 on Ubuntu Feisty.
Looks awfy like it's been pasted from an MS Word doc - surely not?
Gordon 
4:32 a.m.
At 12:48 AM 5/10/2007, Sridhar Ayengar wrote:
http://www.catb.org/~esr/jargon/html/meaning-of-hack.html
Section on "Robin Hood" and "Friar Tuck". Customers getting ignored
can lead to interesting happenings.
It doesn't quite explain how the Moto engineers got those hacks
into the Xerox development system, though...
As for the story's aside about Windows viruses... don't get me started
about spyware.
- John
5:47 a.m.
http://www.catb.org/~esr/jargon/html/meaning-of-hack.html
Section on "Robin Hood" and "Friar Tuck". Customers getting ignored
can
lead to interesting happenings.
It doesn't quite explain how the Moto engineers got those hacks
into the Xerox development system, though... 
8 May
8 May
8:25 a.m.
On 08/05/07, Philip Pemberton <classiccmp at philpem.me.uk> wrote:
You're not as new as I am - I don't even HAVE an 8" drive. I want to get a
5.25" DD (both 40 and 80 track variants) first, though, as mine's a HD and I
can't tell how to jumper it for 300RPM. It's a YE Data YD-380B, just on the
I can donate some ex-BBC micro 40T and 80T drives if you need... (I'm
near Manchester..)
Will your design cope with the weird disc machinations of the Sirius 1
discs? (aka Victor 9000 I believe, in the States) They were variable
speed, and I think variable numbers of sectors per track,. The
techref is on bitsavers anyway; pp85+
I've not actually got one, but I have some discs for one somewhere..
Rob
10:14 a.m.
Rob wrote:
I can donate some ex-BBC micro 40T and 80T drives if
you need... (I'm
near Manchester..)
I'm near Leeds (the one in Yorkshire, not the one in Kent). I've got an 80T
drive already - all I really need is a 40T to complete the set. And that's
just because 40T drives have a larger head - the whole "40T reads 40T discs
better than an 80T unless they've been formatted/written in an 80T" thing.
I've just done Dave Dunfield's 300RPM hack on my YE-Data drive (after some
multimeter probing) and it seems to be working. I still need to fit it into a
PC and see if it can read a BBC floppy, but you can certainly hear the
difference in speed (and see it in the index pulse delay on a scope).
Will your design cope with the weird disc machinations
of the Sirius 1
discs? (aka Victor 9000 I believe, in the States) They were variable
speed, and I think variable numbers of sectors per track,. The
techref is on bitsavers anyway; pp85+
It should do. You'd just need to change the read clock rate as the data rate
slowed down, assuming you were using a standard 300 or 360RPM drive. The same
goes for the oddball Amiga (IIRC) drives that change speed depending on head
location - you just need to slow down the read clock so that the slower tracks
don't overflow the track timing counter. I'm going to try and add some logic
that clips the timing counter at 0x7F if it tries to overflow - that should
make it a little easier to find out if the read rate was too slow. Equally,
lots of low values mean you've probably got the read rate too high.
AIUI, the Catweasel doesn't do this.. :)
I've not actually got one, but I have some discs
for one somewhere..
I'd want to get a couple of 'blank' discs formatted on the machine to play
with before reading out the contents of the discs. That way the algorithms and
timing can be perfected without risking ruining irreplaceable media (the
'binder absorbing moisture and losing grip' issue and so forth).
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
10:59 a.m.
USB?! USB?!
:-) Urgh... SCSI, please...
USB: Plug in, install drivers, play.
SCSI: Plug in, fiddle with terminators, play with cables, replace
cables, replace terminators, replace host adapter card, replace
terminators again, try with terminators on and off, try daisychaining
in various combinations, give up, go home. 
11:47 a.m.
But USB has been
flaky and an
incompatibility nightmare. (The latter being
exactly what hardware
makers want, of course, because it sells *new*
hardware.)
Agreed. I *HATE* USB devices. Aside from being a royal
pain and unreliable, it's definitely not Universal,
and it's not really much of a Bus either. I tried
using external USB 2.0 hard drives on a Macintosh
once, but every time I touched grounded metal (the
case, power strip, keyboard frame) in the vicinity,
all the USB drives unmounted.
And, quite aside from that, SCSI is far more
backwards-compatible.
Yes, and more reliable too. I once used one of those
ESDI->SCSI interface boards to connect an ESDI hard
drive to my Macintosh G4. It worked.
And ever used a really recent PC clone? They have done
away with almost all I/O. No RS232C, no parallel, no
keyboard or mouse ports, it's all USB. I had to set
one up as a server, and wasted a half a day trying to
get a modem working for the fax dial-in. We couldn't
use the nice external modem because it was RS232C. I
tried a USB->RS232 converter but could never get the
firmware to load properly under Linux. The crappy
internal WinModem wouldn't work under Linux. The
machine has no ISA slots, so no nice hardware internal
modem. Can't find a hardware PCI modem. One of the
guys bought some commercial Linux WinModem driver, and
it almost worked, but was really unreliable.
We kept the old fax server. A Pentium 100.
-Ian
1:19 p.m.
Mr Ian Primus wrote:
Also seconded.
--
Pete Peter Turnbull
Network Manager
University of York
But USB has been
Seconded. I have here several USB memory sticks which work on PCs but
not on a Mac, and as if that's not bad enough, several others of the
same make and same model number which work on both. Also a couple of
USB-to-serial-port adaptors which work on some laptops but not others.
When did you last see wide-ranging USB support on a Unix box (Linux
doesn't count)?
flaky and an
incompatibility nightmare. (The latter being
exactly what hardware
makers want, of course, because it sells *new*
hardware.)
Agreed. I *HATE* USB devices. Aside from being a royal
pain and unreliable, it's definitely not Universal,
and it's not really much of a Bus either. And, quite
aside from that, SCSI is far more
backwards-compatible.
Yes, and more reliable too.
2:10 p.m.
Pete Turnbull wrote:
Also seconded.
I don't even need to comment... :-)
In a traditional CPU-driven environment the logical thing to do would perhaps
have been to make the CPU and floppy interface a separate board to the one
containing the interface, with the CPU bus coupling them together. That way
the core stays the same but the interface can change (USB, SCSI, Ethernet
etc.) relatively easily (plug in the right board, drop in the right firmware ROM).
I'm not sure if that maps to whatever IC Phil's using though.
And, quite aside from that, SCSI is far more
backwards-compatible.
Yes, and more reliable too.
3:25 p.m.
Jules Richardson wrote:
In a traditional CPU-driven environment the logical
thing to do would
perhaps have been to make the CPU and floppy interface a separate board
to the one containing the interface, with the CPU bus coupling them
together. That way the core stays the same but the interface can change
(USB, SCSI, Ethernet etc.) relatively easily (plug in the right board,
drop in the right firmware ROM).
The reader IS separate from the microcontroller.
The CPLD handles data read, data write, and write gating. Its interface to the
microcontroller consists of three address lines, an 8-bit bidirectional data
bus, a read line and a write line. It's basically the same as the Z80 bus -
nIOR, nIOW, address and data.
The PIC handles the interface between the USB bus and the CPLD (register
programming, waiting for operations to complete, etc), the status LEDs, and
the floppy drive control lines (MOTEN, DS0, DS1, TG42, etc). That
microcontroller and its support circuitry can be torn out and replaced with
close to anything that can be made to speak 8080-style bus protocols (which
usually involves a small amount of glue and not much else).
So if you don't like USB, you're quite welcome to use SCSI, RS232, CAN,
LINBUS, SB-Bus, Firewire, or some form of wet string serial or parallel
interface - swap out the microcontroller, write some software to drive it and
have fun.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
7:52 p.m.
Talking'bout SCSI, see that
http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2001/sjk26/De…
I'll take a nice look how this interfacing was done, there are much to
learn here! :oD
10 May
10 May
3:02 a.m.
Alexandre Souza wrote:
Talking'bout SCSI, see that
http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2001/sjk26/De…
I'll take a nice look how this interfacing was done, there are much
to learn here! :oD
Interfacing *to* a SCSI device should be fairly straightforward. It's a bit
more complex to make something look like a SCSI device though due to the
command set that needs to be supported. I'm not sure what the minimum that
needs to be done is (beyond just read / write / inquiry / test-unit-ready /
request-sense). Fun project, though.
9:11 a.m.
On 10/05/07, Alexandre Souza <alexandre-listas at e-secure.com.br> wrote:
Talking'bout SCSI, see that
http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2001/sjk26/De…
[microcontroller connecting serial digital camera to scsi zip drive]
LOL.. I had one of those Barbie cameras; very low resolution, RS232
only, and a terrible (for an adult!) windows application to drive
it... ?69.99 ($140) it cost me, about 1998 or so, when new. ...
picked up several from a local bargain store about three years ago at
?4.99 ($10) each and managed to sell on eBay for just a little more..
The last one I failed to get rid of a few months ago on freecycle;
ended up giving it to the kids next door.
Hasn't digital camera technology come down in price ...
8 May
8 May
2:12 p.m.
On Tuesday 08 May 2007 16:19, Pete Turnbull wrote:
I'm starting to wonder if the reason I've NEVER had ANY problem with USB
devices is because I've only used them on Linux machines (short of the
USB keyboard/mouse that Sun and Apple ship with their machines).
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Agreed. I
*HATE* USB devices. Aside from being a royal
pain and unreliable, it's definitely not Universal,
and it's not really much of a Bus either.
Seconded. I have here several USB memory sticks which work on PCs
but not on a Mac, and as if that's not bad enough, several others of
the same make and same model number which work on both. Also a
couple of USB-to-serial-port adaptors which work on some laptops but
not others.
When did you last see wide-ranging USB support on a Unix box (Linux
doesn't count)?
3:48 p.m.
Agreed. I
*HATE* USB devices. Aside from being a royal
pain and unreliable, it's definitely not Universal,
and it's not really much of a Bus either.
Seconded. I have here several USB memory sticks which work on PCs but
not on a Mac, and as if that's not bad enough, several others of the
same make and same model number which work on both. Also a couple of
USB-to-serial-port adaptors which work on some laptops but not others.
6 p.m.
On 8 May 2007 at 23:48, Tony Duell wrote:
My other main boan is that the interface is nowhere
near symmetical
between the 2 devices. People used to moan about having to have RS232
null-modem cables, but at least for asynchronous operation they were just
cables with the right wiring. Linking 2 USB 'slave' devices (say an HP50G
calculator to a USB printer or a USB memory stick) is a lot more work, in
fact it's probably impreactical.
Maybe for some devices, but there's a standard:
http://www.usb.org/developers/onthego/
Cheers,
Chuck
9 May
9 May
8:16 p.m.
Hi,
Well, if folks don't really care for USB, how
about 802.3u?
Best idea yet.
I use the Ethernet port on my Rio Karma all the time in preference to the
lousy USB2 interface also present on the device (I don't even know if the
USB port on the ting works!).
Now, if I could just get a working replacement 1.8" hard drive for
it....bl**dy Hitachi Deathstars (they're the only thing I hate more than
USB, LOL). :-(
TTFN - Pete.
8 May
8 May
2:07 p.m.
Mr Ian Primus wrote:
Agreed. I *HATE* USB devices. Aside from being a
royal
pain and unreliable, it's definitely not Universal,
and it's not really much of a Bus either. I tried
using external USB 2.0 hard drives on a Macintosh
once, but every time I touched grounded metal (the
case, power strip, keyboard frame) in the vicinity,
all the USB drives unmounted.
Which suggests your 'grounded metal' may not be grounded so well.
Most of the problems I've had were with USB devices plugged into the front USB
ports - because of the length (and poor quality) of the cable inside the
machine, they'd work at 12Mbit for a flashdrive, but as soon as you go up to
480Mbit (especially with something like a scanner), the data just gets mangled.
Minolta scanners are really fussy about this sort of signal degradation, but
most other devices are more tolerant...
99% of the problems I've had with USB could be traced back to bad grounding,
bad cable or a combination of the two.
And ever used a really recent PC clone? They have
done
away with almost all I/O. No RS232C, no parallel, no
keyboard or mouse ports, it's all USB.
So now you know why I'm fiercely protective of my laptop (a Toshiba Satellite
Pro 4600) - it's a 1GHz Mobile Pentium III with Cardbus, RS232, parallel, WiFi
and USB - only USB1.1, but it's better than the modern 2GHz ubermachines that
only have USB and VGA (and even that's a push with most of them - some only
have DVI-out).
The main reason I'm using USB is speed - the fastest RS232 will work (with
standard parts) is 115200bps. That gives a maximum theoretical transfer rate
of 11.25KBytes/sec. 128KB of RAM over 11.25KB is around 11.4 seconds per
track. Multiply that by 80 tracks, and you get 910.2 seconds - 15 minutes and
10 seconds. That's not counting the second or so for each track to actually
read...
Would you wait more than 15 minutes for a disc to image?
If you assume that USB can transfer 1MByte per second (in USB2 High Speed
mode, i.e. 12Mbit/sec), then you can transfer 128Kbytes in 125 milliseconds.
Ten seconds data transfer time on top of the 80 seconds for data transfer -
roughly a minute and a half best case. You're probably looking at a maximum of
two minutes worst case - an eighth of the time it'd take to do the same thing
over RS232.
If there were easily-available (and cheap) SCSI slave controllers, and I had a
SCSI host adapter, I might consider using SCSI. Fact is though, it's much
easier just to throw in a USB PIC and program it to control the CPLD. But even
so, SCSI is total overkill anyway - it's designed for connecting fast
computers to really fast hard drives, and it does really well at that. For
scanners and other I/O peripherals I wouldn't even consider it.
We kept the old fax server. A Pentium 100.
Sometimes the old kit works far better than the new stuff. My current server
is a Linksys NSLU2, coupled to a pair of Seagate 400GB USB drives (in RAID1
mode) and a Netgear DG834GT router. The aforementioned NSLU2 runs Debian
Linux, and hasn't had a reboot in more than two weeks. The reboot before that
was because I did something monumentally stupid when I replaced the old router
with the DG834GT. Admittedly it's less than a year old, but it gets the job
done quite nicely, and uses less power than the K6 box it replaced.
Now I just need to hack together a DC UPS for it to get rid of the wall-warts
and allow it to survive a brownout/blackout until the mains sorts itself out.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
3:01 p.m.
I've lately grown partial to USB interfaces--but not rolled on my
own, but rather using those little USB modules that plug into a 32-
pin DIP socket and give you 8 bits of I/O with send and receive
FIFOs. They're treated as generic communications devices, so there
are no drivers to write on the host side. The big thing to be
careful of is the transfer mode. Single-byte transfer on *any*
generation of USB is very very slow. OTOH, burst/block transfers can
be nice and speedy. Unlike SCSI, USB really *is* plug-and-play.
Cables are easy to come by and you can leech power from the host if
your device doesn't draw too much. All in all, not a bad solution.
SCSI, while simple on the host end (almost any platform has some sort
of "pass through capability", is more of a problem on the device end.
I'm not aware of any generic "plug it into a DIP socket" SCSI module,
which means that you've got that layer to work out and debug.
FWIW,
Chuck
10 May
10 May
2:40 a.m.
Ensor wrote:
You plug it in, then you play with it for hours trying to get the darn thing
to work.
It seems to be the software side that nearly always causes me problems. Even
under Linux it seems a total mess and any logfile output isn't particularly
helpful in diagnosing problems (and of course under MS Windows you're lucky if
you even *get* any logfile output when something goes wrong)
My experience so far with USB cameras, mice, webcams, RS232 adapters and CF
adapters has been decidedly not good...
....USB really *is* plug-and-play.
LMAO! Maybe in some weird, parallel universe....
3:10 a.m.
On Thu, 2007-05-10 at 04:40 -0500, Jules Richardson wrote:
Ensor wrote:
You plug it in, then you play with it for hours trying to get the darn thing
to work.
It seems to be the software side that nearly always causes me problems. Even
under Linux it seems a total mess and any logfile output isn't particularly
helpful in diagnosing problems (and of course under MS Windows you're lucky if
you even *get* any logfile output when something goes wrong)
My experience so far with USB cameras, mice, webcams, RS232 adapters and CF
adapters has been decidedly not good...
Sounds like you're just having bad luck. The only USB devices I've
entirely failed to get working in Linux have been an el-cheapo DVB-T
adaptor and a MOTU Midi Timepiece-type thing (can't remember the exact
model).
Everything else has worked perfectly, instantly. MIDI interfaces, audio
interfaces, GPS receivers, cameras, disk drives, MP3 players, serial
ports, parallel ports, and probably some other stuff I can't quite
remember just now.
The only thing I have had a degree of difficulty with was one GPS module
that had a slightly odd serial-to-USB interface inside. It took a
couple of minutes to hack up a suitable kernel module for that.
Gordon
....USB really *is* plug-and-play.
LMAO! Maybe in some weird, parallel universe.... 
8:46 a.m.
On Thu, 2007-05-10 at 04:40 -0500, Jules Richardson wrote:
Ensor wrote:
You plug it in, then you play with it for hours trying to get the darn thing
to work.
It seems to be the software side that nearly always causes me problems. Even
under Linux it seems a total mess and any logfile output isn't particularly
helpful in diagnosing problems (and of course under MS Windows you're lucky if
you even *get* any logfile output when something goes wrong)
My experience so far with USB cameras, mice, webcams, RS232 adapters and CF
adapters has been decidedly not good...
I have to admit I'm puzzled by this entire exchange. I was trying
to remember a problem I've had, so I could add to the list in the spirit
of commiseration, but I honestly cannot say that I have ever had a
problem with USB connections, compact flash adapters, SCSI connections,
or IDE connections, for that matter. I simply use components that are
age-similar, and have never had a problem. I don't like the idea of
writing a driver for, say, a USB memory stick, but, when I've plugged
them in, they have always worked. SOMEBODY wrote them, and that's what
counts -- in my opinion.
I will admit that I've never (so far) attempted to put a USB port on
a CP/M machine, for instance. That would be, as I see it, an awkward
usage. What I *HAVE* had problems doing is connecting monitors to video
cards. I used to have a Thompson all-purpose (forget the model number)
multi-synch monitor. Back then, life was simple. If it had 15 pins,
hook up a VGA monitor. If it had 9 pins, hook up the Thompson, at least
until I figure out what kind of video it is... and it's handy to be able
to boot and run the machine to do that, if it is a video card with which
I am not familiar. I have also had problems hooking up the old ST
interface hard drives -- some folks, apparently deliberately, mislabeled
the pin 1 stripe on drive cables, ensuring the drives were hooked up
backwards, if connected by "normal" techs, as opposed to those versed in
that manufacturer's quirks. That has a demoralizing effect on the
drive.
I've got a compact flash card reader, a PCMCIA USB card for laptops
without USB built-in, a 3.5 inch diskette drive, several Zip drives, and
"el cheapo" memory sticks. I've never had the first problem with any of
them. If my current computer didn't already have a 3.5 inch drive, I
certainly would not get one, since I have the USB drive. All I need now
is a 5.25 inch USB diskette drive and an 8 inch USB diskette drive and
Bob's your uncle. I am seriously considering getting a large external
USB HD, because I have had such outstanding luck with other USB devices.
Their operation might as well be magic for all I know about them,
that's true, but, at a certain point, the functionality wins me over. I
can always tinker with old equipment, but, for me, the fact that all my
USB appliances work on all my machines with USB ports has always been a
given. Since I have just blundered into using USB, and the only
"technical" information I normally use is to insert the plug in the
orientation which puts the least strain on the fingers, it makes me
wonder if some folks here -- the ones with the bitter experiences --
might be over-engineering it. Just wondering.
Peace,
Warren E. Wolfe
wizard at voyager.net
....USB really *is* plug-and-play.
LMAO! Maybe in some weird, parallel universe....
9:22 a.m.
On 10 May 2007 at 11:46, Warren Wolfe wrote:
Their operation might as well be magic for all I
know about them,
that's true, but, at a certain point, the functionality wins me over. I
can always tinker with old equipment, but, for me, the fact that all my
USB appliances work on all my machines with USB ports has always been a
given. Since I have just blundered into using USB, and the only
"technical" information I normally use is to insert the plug in the
orientation which puts the least strain on the fingers, it makes me
wonder if some folks here -- the ones with the bitter experiences --
might be over-engineering it. Just wondering.
Many of the problems associated with USB can be attributed solely to
faulty driver software. After bumbling around with USB support as an
add-on for Win95 (horrible), the geniuses at Redmond really did have
a good idea--layer the driver implementation into the baseline
drivers and device-specific "minidrivers" that would work with either
NT or Win98. Unfortunately, this was carried out with the usual
competence (or lack of it) that we associate with Windows software.
If memory serves, USB came rather late to Linux, most of the effort
being spearheaded by an on-again, off-again effort out of Spain(?).
In any case, it was a retrofit into the existing system device driver
structure.
Simple USB devices, such as floppy drives and CF card readers have
worked just fine for me. On the other hand, I have a box of USB
peripherals which don't operate in any fashion and whose
manufacturers have long been out of business (or who disavow ever
having built the damned things).
One of the big issues that I have with wholesale USB peripheral
implementation is the need for additional boxes (hubs) in my already
cluttered work area. Cables, cables everywhere with lots of little
dodads to get buried under the flotsam of paper and books.
That being said, I've got an HP scanner with both USB and SCSI
interfaces--and I use it in SCSI mode.
Cheers,
Chuck
2:48 p.m.
"Chuck Guzis" wrote:
If memory serves, USB came rather late to Linux, most of the effort
being spearheaded by an on-again, off-again effort out of Spain(?).
In any case, it was a retrofit into the existing system device driver
structure.
I don't like to quibble, but I don't think that's a fair
characterization of USB in linux. There are a small group of very
devoted people behind it, and the work they have done is quite
reasonable. The support in the 2.6 kernels has worked well for me, but
I don't use a lot of different devices. The support is *very* active
and on-going. Monitor the linux-usb mailing list and you'll see a *lot*
of traffic.
The usb code in linux is (my opinion) well structured these days. And
there is support for usb client devices as well as multiple different
hosts and layered hosts. The URB model seems to be holding up well.
But other's may have a different opinion.
Linux (and other operating systems) have struggled with how to best
support the "plug and play" model. Some methods work better than
others. Certainly all have evolved over time. They are all at
best a "work in progress" (again, my opinion).
-brad
Brad Parker
Heeltoe Consulting
+1-781-483-3101
http://www.heeltoe.com
9:47 a.m.
On 5/10/07, Warren Wolfe <wizard at voyager.net> wrote:
I have to admit I'm puzzled by this entire
exchange. I was trying
to remember a problem I've had, so I could add to the list in the spirit
of commiseration, but I honestly cannot say that I have ever had a
problem with USB connections... I simply use components that are
age-similar, and have never had a problem.
Therein is the answer to a lot of USB *and* SCSI complaints - trying
to use an ACB-4000 and MFM drives on a "modern" machine (no way to
query drive geometry), or, for one USB case I can speak to, attempting
to attach a Toshiba "In-Touch" (PMD-C004) display to *anything* newer
than Windows 95 (no, really... that's what its drivers are for)
doesn't go well.
As most of us have experienced, it doesn't take much to break
"age-similar". Yes, I would expect that if I go out *today* and buy
any USB disk or printer and plug it into any PC bought *today* running
an OS I can buy or download *today*, it should "just work". The
problem creeps in, say, when I want to run a 4-year-old USB 1.0 disk
enclosure on a week-old machine that only has USB 2.0 ports. USB
claims to be "universal", but even that's been a moving target from
1.0 to 1.1 to 2.0. Most things do manage to achieve interoperability,
but it only takes one or two devices to throw a wrench in the works.
One thing I _really_ don't like about USB is that you are at the mercy
of the writers of the drivers. RS-232-attached or
parallel-port-attached or even SCSI-attached devices can be poked and
proded with a variety of tools (hardware and software) and can be made
to work in situations where they _don't_ work out of the box. I don't
think the same level of flexibility exists with USB. Since I would
like to be able to talk to this PMD-C004, I'd like to be proven wrong.
I am, by necessity, using more and more USB devices every day. I
still insist on being able to hook "legacy devices" to "legacy
ports".
I expect to freeze in time somewhat when there is just no way to fit
a real serial port or real parallel port to a "modern" machine. USB
works fine for the masses who just want to hook scanners and printers
and memory card readers to their machines; I do things that "the
public" don't find interesting, so my standards are higher.
-ethan
10:39 a.m.
On 10/05/2007 17:47, Ethan Dicks wrote:
As most of us have experienced, it doesn't take
much to break
"age-similar". Yes, I would expect that if I go out *today* and buy
any USB disk or printer and plug it into any PC bought *today* running
an OS I can buy or download *today*, it should "just work".
Hmm... but the whole world's not a PC (nor even a Vax :-)) A few weeks
ago I bought a few USB serial port adapters, and they work fine on a
variety of PCs running various versions of Windows. Not, though, on a
Mac, which doesn't even see them.
--
Pete Peter Turnbull
Network Manager
University of York
11:13 a.m.
On 5/10/07, Pete Turnbull <pete at dunnington.plus.com> wrote:
On 10/05/2007 17:47, Ethan Dicks wrote:
In terms of aggregate market-share and hardware vendors' planning, it
might as well be. :-(
As most of us have experienced, it doesn't
take much to break
"age-similar". Yes, I would expect that if I go out *today* and buy
any USB disk or printer and plug it into any PC bought *today* running
an OS I can buy or download *today*, it should "just work".
Hmm... but the whole world's not a PC (nor even a Vax :-))
I learned C on an 11/750 running 4.1BSD... "all the world's a VAX"
really means something to me. It was, um, a secondary education when
I went from C programming on UNIX on a VAX to embedded C on a 68000
with our own home-rolled clib. Fortunately, I had plenty of M68K
assembler experience to make heads-or-tails of what was going on.
A few weeks
ago I bought a few USB serial port adapters, and they work fine on a
variety of PCs running various versions of Windows. Not, though, on a
Mac, which doesn't even see them.
Yeah... I have yet to take the plunge and buy any USB serial adapters
for just that reason - for me, they have to work with Windows
(laptops), Linux, _and_ Mac OS X, or I don't care if they are $2 or
$10 each... they aren't going to cut it.
I'm faced with getting a new company-paid laptop later this year. I'm
now trying to decide between "whatever hardware is being provided by
internal IT" and replacing Vista with RedHat Linux, or taking the
plunge and going with some form of Macbook. My job is 100% Linux, so
I'd _rather_ be running it on my desk, but given the stuff that's
available new as a "standard laptop", since they aren't hardware
compatible with what was available even 2 years ago (no
PCMCIA/Cardbus, no serial, no parallel, no PATA, no PS/2...), I might
as well get a Mac (I've already asked if I can get my old laptop back
- no answer yet).
I haven't done any software dev on a Mac, but at least with Linux, I
know I can write device drivers from scratch (having done it for VMS
and Ultrix, I don't find the process too scary, just fiddly).
-ethan
3:14 p.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
On 10/05/2007 19:13, Ethan Dicks wrote:
I learned C on an 11/750 running 4.1BSD... "all
the world's a VAX"
really means something to me. It was, um, a secondary education when
I went from C programming on UNIX on a VAX to embedded C on a 68000
with our own home-rolled clib. Fortunately, I had plenty of M68K
assembler experience to make heads-or-tails of what was going on.
:-)
Yeah... I have yet to take the plunge and buy any USB
serial adapters
for just that reason - for me, they have to work with Windows
(laptops), Linux, _and_ Mac OS X, or I don't care if they are $2 or
$10 each... they aren't going to cut it.
If I find one that does, i'll let you know.
I'm faced with getting a new company-paid laptop
later this year. I'm
now trying to decide between "whatever hardware is being provided by
internal IT" and replacing Vista with RedHat Linux, or taking the
plunge and going with some form of Macbook. My job is 100% Linux, so
I'd _rather_ be running it on my desk, but given the stuff that's
available new as a "standard laptop", since they aren't hardware
compatible with what was available even 2 years ago (no
PCMCIA/Cardbus, no serial, no parallel, no PATA, no PS/2...), I might
as well get a Mac (I've already asked if I can get my old laptop back
- no answer yet).
This is getting way off-topic now, but FWIW a couple of our systems
guys, including one who's *really* into Linux, have Macbooks. In fact
that's how I know about some of the USB stuff not working. Just to temp
you in the other direction, one recently got a new dual-core Toshiba
laptop, which performs very well, and which I mention because it has a
real RS232 port on the back. OTOH, my USB-to-serial works fine on my
Vaio, and even sends breaks correctly (which I need for some of our
switches).
--
Pete Peter Turnbull
Network Manager
University of York
11 May
11 May
12:13 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
Yeah... I have
yet to take the plunge and buy any USB serial adapters
for just that reason - for me, they have to work with Windows
(laptops), Linux, _and_ Mac OS X, or I don't care if they are $2 or
$10 each... they aren't going to cut it.
If I find one that does, i'll let you know.
2:20 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
On 11/05/2007 08:13, r.stricklin wrote:
Jesus, you guys, Keyspan has had not one, but NINE (at least!) models
that have been supported under Windows, OS X, and linux, for YEARS.
How hard is it to use Google?
Using Google *and* the search engines on two suppliers sites we use
found adapters, including the one I referred to, that *claim* to work
but don't (or don't work straight off). Don't assume that just because
something says it's supported that it actually works properly in all
cases. A perfect example being the memory sticks I also mentioned earlier.
--
Pete Peter Turnbull
Network Manager
University of York
Yeah... I
have yet to take the plunge and buy any USB serial adapters
for just that reason - for me, they have to work with Windows
(laptops), Linux, _and_ Mac OS X, or I don't care if they are $2 or
$10 each... they aren't going to cut it.
If I find one that does, i'll let you know.
2:47 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
On 11/05/2007 10:20, Pete Turnbull wrote:
I should have said that the specific one I was testing earlier this week
came with Mac OS X drivers, but they don't work. It also had drivers
for earlier Mac OS but we had nothing to try those on. It wasn't a
Keyspan one, though; they tend to cost a lot more here (cheapest I can
find is about US$40 equivalent an upwards as opposed to just over a
third of that for the one I tried) but I'm off to order one now.
--
Pete Peter Turnbull
Network Manager
University of York
On 11/05/2007 08:13, r.stricklin wrote:
How hard is it
to use Google?
Using Google *and* the search engines on two suppliers sites we use
found adapters, including the one I referred to, that *claim* to work
but don't (or don't work straight off).
3:22 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
On Fri, 2007-05-11 at 10:47 +0100, Pete Turnbull wrote:
On 11/05/2007 10:20, Pete Turnbull wrote:
I should have said that the specific one I was testing earlier this week
came with Mac OS X drivers, but they don't work. It also had drivers
for earlier Mac OS but we had nothing to try those on. It wasn't a
Keyspan one, though; they tend to cost a lot more here (cheapest I can
find is about US$40 equivalent an upwards as opposed to just over a
third of that for the one I tried) but I'm off to order one now.
What drivers? It's a USB-to-Serial adaptor - it should be a
class-compliant device. I have never come across one that actually
needed additional drivers to work in MacOS X or Linux. I haven't tried
one in Windows, but past experience suggests that it needs drivers for
*everything*.
Gordon
On 11/05/2007 08:13, r.stricklin wrote:
How hard
is it to use Google?
Using Google *and* the search engines on two suppliers sites we use
found adapters, including the one I referred to, that *claim* to work
but don't (or don't work straight off). 
8:22 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
On 11/05/07, Gordon JC Pearce <gordon at gjcp.net> wrote:
What drivers? It's a USB-to-Serial adaptor - it
should be a
class-compliant device. I have never come across one that actually
needed additional drivers to work in MacOS X or Linux. I haven't tried
one in Windows, but past experience suggests that it needs drivers for
*everything*.
From my experience, the "driver" for
class-compliant devices tends to
be just a file saying "Manufacturer ID XXXX
product ID YYYY is a
device using driver C:\WINDOWS\system32\genericclassdevice.dll" It
then ties the IDs and the location on the USB tree (!) to that driver.
Dumb.
(!) Yes, the location on the tree. We set up a lab here at McGill
with 2 USB devices standard for each workstation: TI DSP eval board,
and a USB oscilloscope. We then imaged the main station (with the
CodeComposer software which takes about 3hrs to install: WTF? lazy
programming I guess...) with the drivers (custom, from the mfg. CD's)
for the two USB devices... Once the images were copied onto the
student workstations and they got powered up, both USB devices
demanded drivers to be installed because the devices were plugged into
different USB ports than they were on the main station! Argh! (More
frustrating than it sounds because we didn't know that this was the
problem, of course. We had to go around 12 workstations and
sequentially install the driver 1, reboot, install driver 2, reboot...
ugh.)
That is beyond dumb. That is broken by design.
Joe.
10:50 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
On 11/05/2007 16:22, Joachim Thiemann wrote:
Once the images were copied onto the
student workstations and they got powered up, both USB devices
demanded drivers to be installed because the devices were plugged into
different USB ports than they were on the main station! Argh! (More
frustrating than it sounds because we didn't know that this was the
problem, of course. We had to go around 12 workstations and
sequentially install the driver 1, reboot, install driver 2, reboot...
ugh.)
That is beyond dumb. That is broken by design.
Yep, this sounds not unlike the problem of using a USB to serial adapter
which only gets plugged in when needed. I always use the same serial
adapter, but sometimes it shows up as COM3, sometimes as COM6, sometimes
as COM15, etc, even when it's plugged into the same USB port (this is
under Win XP). It wouldn't matter, except that hyperterminal needs to
know which COM port, and it's stored in the settings file, so I end up
guessing which settings file to pick.
--
Pete Peter Turnbull
Network Manager
University of York
8:37 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
On 11/05/2007 11:22, Gordon JC Pearce wrote:
What drivers? It's a USB-to-Serial adaptor - it
should be a
class-compliant device.
Many aren't -- including, according to one webpage I saw, some of the
Keyspan ones bear mentioned.
--
Pete Peter Turnbull
Network Manager
University of York
9:41 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
What drivers?
It's a USB-to-Serial adaptor - it should be a
class-compliant device.
Many aren't -- including, according to one webpage I saw, some of the
Keyspan ones bear mentioned.
11:34 a.m.
New subject: USB, serial, Macs and Linux (was Floppy disc reader/writer status report)
It was thus said that the Great Gordon JC Pearce once stated:
What drivers? It's a USB-to-Serial adaptor - it should be a
class-compliant device. I have never come across one that actually
needed additional drivers to work in MacOS X or Linux. I haven't tried
one in Windows, but past experience suggests that it needs drivers for
*everything*.
I recently got a USB-to-Serial adaptor (I deal with the routers and
switches at work). Under Windows I had to install a driver. On my Linux
computer (a recent Linux install) it just worked. On my Linux laptop (with
an older Linux install) it didn't.
-spc (Go figure)
10 May
10 May
11:28 a.m.
Rumor has it that Pete Turnbull may have mentioned these words:
On 10/05/2007 17:47, Ethan Dicks wrote:
Yes, but is that actually USB's fault, or the device, or the Mac?
If Apple didn't fully follow the standard for USB stuff, then it'd be the
Mac's fault.
If the device manufacturer didn't follow a USB specification in making the
device, but "it works on a PC so close enough" -- that's not USB's fault
either - it's whomever made the device.
I have a USB->Serial device that works fine in Linux, AFAIK on a Mac (but
never tested - there are company drivers, tho) and under Win2K & XP...
except running DriveWire for my CoCo. In that one, single application, XP
will occasionally bluescreen right in the middle of my CoCo booting
NitrOS-9. Ungh. I'm *guessing* it's a driver issue.
I'm entertaining suggestions on a new USB->Serial dongle, as that's half of
what I bought the darned thing for... :-/
Just because USB isn't universal, may not actually be USB's fault... ;-)
However, I don't think it's a buss either, so it's still mis-named.
:-)
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger -- SysAdmin, Iceberg Computers
zmerch at 30below.com
Hi! I am a .signature virus. Copy me into your .signature to join in!
As most of us have experienced, it doesn't
take much to break
"age-similar". Yes, I would expect that if I go out *today* and buy
any USB disk or printer and plug it into any PC bought *today* running
an OS I can buy or download *today*, it should "just work".
Hmm... but the whole world's not a PC (nor even a Vax :-)) A few weeks
ago I bought a few USB serial port adapters, and they work fine on a
variety of PCs running various versions of Windows. Not, though, on a
Mac, which doesn't even see them.
5:54 p.m.
Hi,
You plug it in, then you play with it for hours trying
to get
the darn thing to work.
ROTFLMAO!
It seems to be the software side that nearly always
causes me
problems....
Yes, to be fair, it's been the software side that I've mostly had the
problems with - the one real exception being my wonderful "BT Voyager 105"
USB ADSL "modem". It's got a wonderful bug in it which means that as your
data transfer speed approaches the max speed of your line it starts to draw
more and more power....until your USB ports shut down!
But then I have *VERY* few USB devices as I tend to avoid buying them as
much as possible.
....diagnosing problems (and of course under MS Windows
you're lucky
if you even *get* any logfile output when something goes wrong)
Too true, this is one a a vast catalogue of reasons why "XP x64 Edition"
will be the last Windows I run.
Sounds like USB support in Linux at least doesn't force you to have to
abandon your old devices due to lack of drivers when you upgrade; I only
have 7 USB only devices, *5* of which are unusable....
My experience so far with USB cameras, mice, webcams,
RS232 adapters
and CF adapters has been decidedly not good...
Quite, I have a USB webcam (somewhere). It's limited to a max of 15fps @
320*240 due to USB speed restrictions - OTOH my FireWire one can do 30fps @
640*480 (or possibly even 800*600).
CF adapters seem to be pretty hit and miss, when they work they work well,
when they don't....augh!
TTFN - Pete.
8 May
8 May
9:02 p.m.
If there were easily-available (and cheap) SCSI slave
controllers, and I
had a SCSI host adapter, I might consider using SCSI. Fact is though, it's
much easier just to throw in a USB PIC and program it to control the CPLD.
But even so, SCSI is total overkill anyway - it's designed for connecting
fast computers to really fast hard drives, and it does really well at
that. For scanners and other I/O peripherals I wouldn't even consider it.
I don't think SCSI is worth considering. You can have easily RS232 AND
USB 1.1 (don't remember if a 2.0 chip is already avaiable) using a FT232 or
like USB converter chip. For the ones who doesn't like USB, there is always
the fallback for RS232.
9 May
9 May
6:39 a.m.
Philip Pemberton wrote:
So now you know why I'm fiercely protective of my
laptop (a Toshiba
Satellite Pro 4600) - it's a 1GHz Mobile Pentium III with Cardbus,
RS232, parallel, WiFi and USB - only USB1.1, but it's better than the
modern 2GHz ubermachines that only have USB and VGA (and even that's a
push with most of them - some only have DVI-out).
My favorite laptop is the Thinkpad A31p. 1600x1200 15" screen, room for
a DVD-writer and a DVD-ROM at the same time, or two extra batteries,
cheap docking stations available, etc.
Peace... Sridhar
6:39 a.m.
Philip Pemberton wrote:
So now you know why I'm fiercely protective of my
laptop (a Toshiba
Satellite Pro 4600) - it's a 1GHz Mobile Pentium III with Cardbus,
RS232, parallel, WiFi and USB - only USB1.1, but it's better than the
modern 2GHz ubermachines that only have USB and VGA (and even that's a
push with most of them - some only have DVI-out).
My favorite laptop is the Thinkpad A31p. 1600x1200 15" screen, room for
a DVD-writer and a DVD-ROM at the same time, or two extra batteries,
cheap docking stations available, a full complement of ports, etc.
Peace... Sridhar
8:02 p.m.
Hi,
....Most of the problems I've had were with USB
devices
plugged into the front USB ports - because of the length
(and poor quality) of the cable inside the machine, they'd
work at 12Mbit for a flashdrive, but as soon as you go up to
480Mbit (especially with something like a scanner), the data
just gets mangled.
The biggest problem I've found with front mounted ports is that the USB
standard is so brain dead that if you plug in a USB2.0 device into such a
port, and the cable quality is bad, the damn thing refuses to fall back to
USB1 data rates when it fails to communicate at USB2 rates. So you end up
with a non-working, "unidentified" device. :-(
99% of the problems I've had with USB could be
traced back to bad
grounding, bad cable or a combination of the two.
100% of the problems I've had with USB stem from the bad design of the
interface....
Can't you tell I just *LOVE* USB? ;-)
The main reason I'm using USB is speed....
If that's your main reason for using USB then you really should consider
using FireWire instead.
I recall reading up on FireWire vs USB a few years ago before I standardised
on FireWire. Despite being marginally slower in terms of bit rate, FireWire
offers something like 20% more throughput than USB2.
TTFN - Pete.
8:32 p.m.
Ensor wrote:
I recall reading up on FireWire vs USB a few years ago
before I
standardised on FireWire. Despite being marginally slower in terms of
bit rate, FireWire offers something like 20% more throughput than USB2.
Plus, there's always Firewire 800. I have a FW800 hard disk array.
It's fast. Very fast.
Peace... Sridhar
10 May
10 May
2:08 p.m.
On 5/8/07, Philip Pemberton <classiccmp at philpem.me.uk> wrote:
If you assume that USB can transfer 1MByte per second (in USB2 High Speed
mode, i.e. 12Mbit/sec), then you can transfer 128Kbytes in 125 milliseconds.
Ten seconds data transfer time on top of the 80 seconds for data transfer -
roughly a minute and a half best case. You're probably looking at a maximum of
two minutes worst case - an eighth of the time it'd take to do the same thing
over RS232.
That's 1MB/sec in Full-Speed mode. High-Speed mode would be more like
20-30MB/sec, if the device can supply data that fast.
2:46 p.m.
Glen Slick wrote:
That's 1MB/sec in Full-Speed mode. High-Speed
mode would be more like
20-30MB/sec, if the device can supply data that fast.
True. I keep getting High Speed and Full Speed mixed up...
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
8 May
8 May
3:39 p.m.
Agreed. I *HATE* USB devices. Aside from being a
royal
pain and unreliable, it's definitely not Universal,
and it's not really much of a Bus either. I tried
using external USB 2.0 hard drives on a Macintosh
once, but every time I touched grounded metal (the
case, power strip, keyboard frame) in the vicinity,
all the USB drives unmounted.
Never had problems with them. Also, never had problems with XP **since I
changed my motherboard**, and it's been two years since.
And ever used a really recent PC clone? They have
done
away with almost all I/O. No RS232C, no parallel, no
keyboard or mouse ports, it's all USB. I had to set
one up as a server, and wasted a half a day trying to
get a modem working for the fax dial-in. We couldn't
use the nice external modem because it was RS232C. I
tried a USB->RS232 converter but could never get the
firmware to load properly under Linux. The crappy
internal WinModem wouldn't work under Linux. The
machine has no ISA slots, so no nice hardware internal
modem. Can't find a hardware PCI modem. One of the
guys bought some commercial Linux WinModem driver, and
it almost worked, but was really unreliable.
I have no troubles here using **in winXP** any kind of
serial/parallel/keyboard/mouse/coverters thru USB. But I have a **real
nice** two RS232/422 and 1 LPT board. Works flawlessly. Never had a trouble.
I work with hardware development. Sometimes I need 3 RS232 ports. so what is
the matter?
1:16 p.m.
On Tue, 2007-05-08 at 13:59 -0400, der Mouse wrote:
I too have almost exactly the opposite experience. SCSI seems
ridiculously robust - I've discovered that SCSI buses, working for
months, were triple-terminated, and I even saw one mostly work once
that was quadruple-terminated. But USB has been flaky and an
incompatibility nightmare. (The latter being exactly what hardware
makers want, of course, because it sells *new* hardware.)
I've never really had problems with USB, but maybe that's because I pick
stuff I know will work.
USB?! USB?! :-) Urgh... SCSI, please...
USB:
Plug in, install drivers, play.
SCSI: Plug in, fiddle with terminators, play with cables, replace
cables, replace terminators, replace host adapter card, replace
terminators again, try with terminators on and off, try daisychaining
in various combinations, give up, go home. And, quite aside from that, SCSI is far more
backwards-compatible. USB
is quite recent. SCSI goes back to the '80s - and, what's more, it's
*compatible* all the way back to the '80s: I can take a disk that was
sold new with a Sun-2 and put it on my Athlon and have it Just Work,
and, conversely, I can take a brand new off-the-shelf SCSI disk and put
it on my Sun-2 and have it Just Work (well, except that I don't think I
*have* a Sun-2). (Sure, it'll stop down performance, but it'll work.)
You've obviously not had to deal with 80s and 90s audio equipment with
SCSI disks...
Gordon
1:40 p.m.
der Mouse <mouse at rodents.montreal.qc.ca> wrote: >> USB?! USB?! :-) Urgh...
SCSI, please...
USB: Plug in, install drivers, play.
SCSI: Plug in, fiddle with terminators, play with cables, replace
cables, replace terminators, replace host adapter card, replace
terminators again, try with terminators on and off, try daisychaining
in various combinations, give up, go home.
I personally prefer USB on modern stuff... saves me fiddling around with crappy laptops
and Microsoft rubbish... just plug in and use. I have 3 items that use USB... my mouse, my
webcam and a USB 2.0 flash disk (2GB).
I like the hands on of the old stuff though... I can learn and actually feel proud when
things work the way *I* want them to :)
I can also tell when things go wrong... not so with modern stuff where you need to bring
up the troubleshooting docs on the laptop.
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
9 May
9 May
7:23 p.m.
Hi,
More like: a) first find a machine that actually HAS USB ports, b) try to
find drivers, c) give up because i) drivers don't exist, ii) if they do
they're so buggy as to be unusable....
USB = a mind bogglingly *CRAP* solution looking for a problem - aka
"*USELESS* SERIAL BODGE".
USB?! USB?!
:-) Urgh... SCSI, please...
USB: Plug in, install drivers, play. SCSI: Plug in, fiddle with terminators, play with
cables, replace
cables, replace terminators, replace host adapter card, replace
terminators again, try with terminators on and off, try daisychaining
in various combinations, give up, go home.
I had similar problems initially because I simply didn't understand SCSI/had
some badly behaved early hard drives.
Since I learnt how SCSI works I've had not one single problem; it all works
automagically.
You're not as new as I am - I don't even HAVE
an 8" drive....
Anyway, to the point of this email. If you can arrange for collection from
Birmingham I have a pair of 8" drives you can have (they're far too
heavy/bulky to post).
TTFN - Pete.
6437
days inactive
6442
days old
104 comments
29 participants
participants (29)
-
alexandre-listas＠e-secure.com.br -
aliensrcooluk＠yahoo.co.uk -
ard＠p850ug1.demon.co.uk -
bear＠typewritten.org -
brad＠heeltoe.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
classiccmp＠memory-alpha.org.uk -
classiccmp＠philpem.me.uk -
dkelvey＠hotmail.com -
ethan.dicks＠gmail.com -
feedle＠feedle.net -
glen.slick＠gmail.com -
gordon＠gjcp.net -
ian_primus＠yahoo.com -
jfoust＠threedee.com -
joachim.thiemann＠gmail.com -
julesrichardsonuk＠yahoo.co.uk -
mcguire＠neurotica.com -
mouse＠Rodents.Montreal.QC.CA -
pat＠computer-refuge.org -
pete＠dunnington.plus.com -
ploopster＠gmail.com -
robert＠irrelevant.com -
rtellason＠verizon.net -
spc＠conman.org -
spectre＠floodgap.com -
wizard＠voyager.net -
zmerch-cctalk＠30below.com