18 Oct
2006
18 Oct
'06
10:47 p.m.
Don't know if any of you saw this, but a 5.25" floppy disk drive just went
for $192 on E-Bay tonight (Wed., 10/18).
It was a "backpack" external parallel port drive, New Old Stock in Box,
still shrink wrapped.
I am strongly of the opinion that there is a far bigger market than is
generally perceived for a USB floppy disk controller that will support 5.25"
and even 8" drives, if only someone would develop the product.
18 Oct
18 Oct
11:10 p.m.
On 10/18/2006 at 10:47 PM Barry Watzman wrote:
Don't know if any of you saw this, but a 5.25"
floppy disk drive just went
for $192 on E-Bay tonight (Wed., 10/18).
It was a "backpack" external parallel port drive, New Old Stock in Box,
still shrink wrapped.
Note that a 3.5" Backpack will support a 5.25' drive--and I believe that a
BP controller can support up to 2 drives.
Hmmm, I've still got a few 3.5' BP drives in original shrinkwrap...
The backpack controller itself is little more than an NS 80277, a bit of
RAM and what looks like a custom-programmed single-chip MPU. Conversation
with it is via a 4-bit data path. The neat thing is that you can program
that 82077 just like the one on an ISA floppy controller.
The amazing thing about MS was their absolute refusal to discuss
programming of th thing--I had to take apart their driver myself to figure
it out so I could write a Win95 VxD for it.
Cheers,
Chuck
19 Oct
19 Oct
11:11 a.m.
Chuck Guzis wrote:
Hmmm, I've still got a few 3.5' BP drives in
original shrinkwrap...
The backpack controller itself is little more than an NS 80277, a bit of
RAM and what looks like a custom-programmed single-chip MPU. Conversation
with it is via a 4-bit data path. The neat thing is that you can program
that 82077 just like the one on an ISA floppy controller.
The amazing thing about MS was their absolute refusal to discuss
programming of th thing--I had to take apart their driver myself to figure
it out so I could write a Win95 VxD for it.
Gah - the BP drive is my least-favourite device of all time. I spent many
hours struggling to get one working under Linux a few years ago with no luck -
this was including lots of talking to the developers of the Linux BP drivers
and sending trace logs back and forth; they couldn't make any sense of it
either. Makes me wonder if the timing protocol changed at some point or something.
The experience certainly did a lot to put me off external floppy devices,
anyway. :-(
cheers,
Jules
12:56 p.m.
On 19 Oct 2006 at 10:11, Jules Richardson wrote:
Gah - the BP drive is my least-favourite device of all
time. I spent many
hours struggling to get one working under Linux a few years ago with no luck -
this was including lots of talking to the developers of the Linux BP drivers
and sending trace logs back and forth; they couldn't make any sense of it
either. Makes me wonder if the timing protocol changed at some point or something.
I don't think so--we sold the 3.5" versions with our special software
(for handling 360 RPM 3.5" drives) from the metal-cased version right
up to the time they stopped shipping the plastic-cased version.
Timing's a little twitchy, but not too bad in the PeeCee universe of
things--and the Windoze 9x/3.1 VxD's were solid.
Forgot to mention that the BP also has 16x63 bit serial NVRAM in it.
Was just reminded of it looking at some old code.
If you're thinking about a Catweasel-type external box, then I'd put
lots of memory (10 MB or more) and some programmable intelligence in
it (so the "nuts and bolts" isn't subject to OS platform-related
issues). Maybe interface with something dirt-common, like RS-232C.
Of course, this would push the price of a basic unit up pretty high.
Cheers,
Chuck
P.S. This is my first message using a new email client--Pegasus.
Calypso finally has developed an irritating bug that I can't fix
because I don't have access to the source code.
1:42 p.m.
On 10/19/2006 at 1:14 PM Barry Watzman wrote:
I have a 3.5" backpack also. And a backpack tape
drive, which used
a floppy interface. I'd love to convert either/both to a 5.25"
drive if you know how.
The interface electronics for both 3.5 and 5.25 are the same--only
the NVRAM content is different--and that can be easily changed. Most
of the rest is PSU (most 5.25" drives require +12 in addition to +5)
and the physical box to hold it all in. You could even put a
5.25"/3.5" combo drive on the BP controller--it supports 2 drives.
I've never fooled with the BP tape drive, so I don't know what's
inside.
I've also got a Rancho Technologies parallel-to-floppy PCB, but
haven't bothered to figure out the programming protocol.
Cheers,
Chuck
3:16 p.m.
Chuck Guzis wrote:
If you're thinking about a Catweasel-type external
box, then I'd put
lots of memory (10 MB or more)
I don't think you necessarily need anything like that much; I remember Dave
Dunfield and I discussing this a while back and it worked out at something
like a couple of hundred KB I'm sure.
and some programmable intelligence in
it (so the "nuts and bolts" isn't subject to OS platform-related
issues).
Oh, absolutely. I was wondering about making the bulk of device's firmware
downloadable from the attached computer to be honest, just so things can be as
flexible as possible.
Maybe interface with something dirt-common, like
RS-232C.
Of course, this would push the price of a basic unit up pretty high.
I don't know, what's a couple of hundred KB of memory, a CPU (say a Z80 for
sake of argument), a bit of ROM, and a serial interface chip, plus a bit of
glue logic?
Actually, some of the PIC micros have RS232 ability (with the addition of line
drivers) I believe and might kill two birds with one stone. Not sure what the
cost of RAM would be - cheap if DRAM I suppose, but then there's the
complexity of refreshing... SRAM would make life really easy.
P.S. This is my first message using a new email
client--Pegasus.
I feel honoured, or something ;)
cheers
Jules
3:51 p.m.
On 19 Oct 2006 at 14:16, Jules Richardson wrote:
I don't think you necessarily need anything like
that much; I remember Dave
Dunfield and I discussing this a while back and it worked out at something
like a couple of hundred KB I'm sure.
If you're going track-by-track, probably a couple hundred K is more
than enough. But holding a complete 8" DSHD image runs to something
like 6MB if you hang onto the whole histogram.
I think you'd definitely want to have enough storage to hold a
complete image--it'd make copying much simpler, no? Besides, a few
megabytes of RAM is nothing nowadays.
I don't know, what's a couple of hundred KB of
memory, a CPU (say a Z80 for
sake of argument), a bit of ROM, and a serial interface chip, plus a bit of
glue logic?
Probably use something a bit more common, say an ARM? Not that I
have anything against a Z80 (or Z180, or EZ80). Just that extra
horsepower can be very nice, even if you don't need it right away.
Cheers,
Chuck
4:28 p.m.
Chuck Guzis wrote:
Possibly, depending on cost. I'd hope that something could typically be lashed
together (parts cost only) for about 20 bucks, though using a combination of
purchased bits and things from the parts bin [1]. Beyond that and it's sort of
into catweasel territory (albeit with the convenience of an external device).
[1] 8 bit CPUs, SRAM from old PC motherboards, SIO chips, RS232 connectors,
cables, old SIMMs, old DIMMs etc. are all easily available for free. For a
design based around one of the common old 8-bit CPUs (say Z80 or 6502) the
main parts cost is probably the PCB itself.
On 19 Oct 2006 at 14:16, Jules Richardson wrote:
I don't see what it would gain you, though. You've still got the same amount
of data to transfer between host and device - and I bet someone can come up
with a situation where they'd want to just read or write a single track rather
than an entire image, which makes transferring an entire image wasteful
(particularly at RS232 speeds!)
Maybe someone can think of a situation where you *need* more than one track in
memory at once, though. (Note I'm not thinking at all about storage formats
which aren't track-based though)
I don't think you necessarily need anything
like that much; I remember Dave
Dunfield and I discussing this a while back and it worked out at something
like a couple of hundred KB I'm sure.
If you're going track-by-track, probably a couple hundred K is more
than enough. But holding a complete 8" DSHD image runs to something
like 6MB if you hang onto the whole histogram.
I think you'd definitely want to have enough storage to hold a
complete image--it'd make copying much simpler, no? Besides, a few megabytes of RAM is nothing nowadays.
DRAM, no. In that sort of situation providing a SIMM / DIMM socket would seem
the best bet and people can populate it with whatever memory they have to
hand. There is the refresh issue then, though.
I don't
know, what's a couple of hundred KB of memory, a CPU (say a Z80 for
sake of argument), a bit of ROM, and a serial interface chip, plus a bit of
glue logic?
Probably use something a bit more common, say an ARM? Not that I have anything against a Z80 (or Z180, or
EZ80). Just that extra
horsepower can be very nice, even if you don't need it right away.
Actually, a sister project (in a way) would be to oversample the raw data
stream from the drive heads in an attempt to read disks that otherwise
appeared dead, with software then doing the analysis of the waveform. I know
Dave has more than a few thoughts on that subject - and that does need a lot
more RAM and CPU horsepower to do.
For a 'simple' track-based design though I'd think that CPU choice comes
pretty much down to cost only, plus concerns about the average user's ability
to program the system with the necessary code after construction. (For
example, I can burn EPROMs. I could probably figure out how to program a PIC.
I would have absolutely no idea what to do with an FPGA, let alone be able to
contribute anything to the design :)
From the point of view of the host machine, the set of operations needed
isn't complex - something like 'assign parameters', 'read track',
'write
track', 'get error information', 'format track', 'seek', and
possibly
something like 'download firmware'. It shouldn't actually be a complex device
- but it is best left to someone who has experience of building SBC-like
devices :-)
Transfer speed is a huge headache - 200KB or whatever at RS232 speeds is
painful. Repeat for 160 tracks and it becomes rather annoying! (It suggests
that some sort of simple compression scheme is needed)
cheers
Jules
6:18 p.m.
I think
you'd definitely want to have enough storage to hold a
complete image--it'd make copying much simpler, no?
I don't see what it would gain you, though. You've still got the same amount
of data to transfer between host and device - and I bet someone can come up
with a situation where they'd want to just read or write a single track rather
than an entire image, which makes transferring an entire image wasteful
(particularly at RS232 speeds!)
Maybe someone can think of a situation where you *need* more than one track in
memory at once, though. (Note I'm not thinking at all about storage formats
which aren't track-based though) Besides, a few
megabytes of RAM is nothing nowadays.
DRAM, no. In that sort of situation providing a SIMM / DIMM socket would seem
the best bet and people can populate it with whatever memory they have to
hand. There is the refresh issue then, though.
6:24 p.m.
On 19 Oct 2006 at 15:28, Jules Richardson wrote:
I don't see what it would gain you, though.
You've still got the same amount
of data to transfer between host and device - and I bet someone can come up
with a situation where they'd want to just read or write a single track rather
than an entire image, which makes transferring an entire image wasteful
(particularly at RS232 speeds!)
I didn't say that transfers should be whole-image; just that the read
operation should be capable of transferring a whole image at a time.
Here's why.
Suppose the track image of a CW contains HD MFM data--worst-case,
you'll have something like 100K flux transitions to record. That's
100K bytes per track. Assuming you use 115K for your serial transfer
link, that's 10 bits per byte (8N1) or about 11K bytes per second,
so you can transfer the aforementioned track in 9 seconds, roughly.
160 tracks amounts to 24 minutes. That's more time than I want to
have the heads loaded and motor spinning with some aging floppy
that's barely hanging on to its oxide.
Granted, these are back-of-the-envelope calculations, but you get the
general idea.
When I work with floppies here, I usually read them at most one-and-a-
half times. I then spend my head-scratching hours looking at the
image, not the original.
So, if the aforementioned hypothetical box can simply suck up an
entire disk at full drive speed, so much the better for everyone.
Cheers,
Chuck
20 Oct
20 Oct
11:14 a.m.
Chuck Guzis wrote:
On 19 Oct 2006 at 15:28, Jules Richardson wrote:
Sure - I wouldn't want that either, I'd expect the motor to only be run during
each track read, though. Whether starting and stopping the motor n times to
read a disk is a good idea or not I don't know - it's more stress on the drive
for sure, but whether it's sufficiently more to warrant not doing it I don't
know.
What's the worst-case floppy rotation speed - 300rpm? So five revolutions per
second. Fastest transfer rate is 1Mbps (although didn't some PS/2 systems
manage two?) which in theory gives a maximum of 200Kbits for a track. But with
8x oversampling that'll be 200KB of data for a single sampled track read. So
roughly 18 seconds per track, given the port speeds you mentioned above.
That's slooooow. Given the nature of the data though, it'd probably compress
(using something like LZW) reasonably well - but then if driven by an old 8bit
CPU it may be that any compression (or decompression for write transfers) uses
up any time saved at the transfer stage.
I don't see what it would gain you, though.
You've still got the same amount
of data to transfer between host and device - and I bet someone can come up
with a situation where they'd want to just read or write a single track rather
than an entire image, which makes transferring an entire image wasteful
(particularly at RS232 speeds!)
I didn't say that transfers should be whole-image; just that the read
operation should be capable of transferring a whole image at a time.
Here's why.
Suppose the track image of a CW contains HD MFM data--worst-case,
you'll have something like 100K flux transitions to record. That's
100K bytes per track. Assuming you use 115K for your serial transfer
link, that's 10 bits per byte (8N1) or about 11K bytes per second,
so you can transfer the aforementioned track in 9 seconds, roughly.
160 tracks amounts to 24 minutes. That's more time than I want to
have the heads loaded and motor spinning with some aging floppy
that's barely hanging on to its oxide. When I work with floppies here, I usually read them at
most one-and-a-
half times. I then spend my head-scratching hours looking at the
image, not the original.
Yep, same here. I don't normally expect more than a couple of reads out of a
disk - although typically they'll do a *lot* more than that (at least for
5.25" media).
So, if the aforementioned hypothetical box can simply
suck up an
entire disk at full drive speed, so much the better for everyone.
I'm thinking that the "box built from junk PC bits" needs more investigation
(would make it easy to provide Ethernet support!). It depends what people
want, though - do they want a box to do data recovery from various floppy
media (which means a selection of drive types plugged in at once), or do they
want a backpack-like single drive solution (which implies they want something
compact, and the bulk of a scrap PC motherboard + PSU is too big)?
Personally I'd ideally want to throw at least 8", DD + HD 5.25", and DD + HD
3.5" drives in there - which in PC parlance probably means something like a
midi-tower case just to fit drives in, so compactness of the controlling
hardware isn't an issue.
cheers
Jules
21 Oct
21 Oct
6:44 a.m.
Jules Richardson wrote:
Sure - I wouldn't want that either, I'd expect
the motor to only be
run during each track read, though. Whether starting and stopping the
motor n times to read a disk is a good idea or not I don't know - it's
more stress on the drive for sure, but whether it's sufficiently more
to warrant not doing it I don't know.
What's the worst-case floppy rotation speed - 300rpm? So five
revolutions per second. Fastest transfer rate is 1Mbps (although
didn't some PS/2 systems manage two?) which in theory gives a maximum
of 200Kbits for a track. But with 8x oversampling that'll be 200KB of
data for a single sampled track read. So roughly 18 seconds per track,
given the port speeds you mentioned above.
That's slooooow. Given the nature of the data though, it'd probably
compress (using something like LZW) reasonably well - but then if
driven by an old 8bit CPU it may be that any compression (or
decompression for write transfers) uses up any time saved at the
transfer stage.
Sounds to me like the computer driving this needs to be reasonably fast,
and needs to have lots of RAM and perhaps even a generously sized hard
drive for post-read analysis. Perhaps designing a new floppy controller
might be better? One that can get the analog signal from the R/W head
directly?
You might even be able to use a normal floppy controller to drive the
head and motor, but duplicate the R/W head sensor from the floppy drive
to an add-on card with a sensitive and fast 8 or 16 bit A/D converter.
This way, only a quick, single pass over the floppy is needed, and you
don't have to worry about varying the motor speed. If the r/w head is
sensitive enough, and the A/D converter is fast enough, a single pass
should suffice.
Once the data is in RAM and then saved to hard disk, lots and lots of
analysis can be done in software regardless of its format. Better yet,
it should just be compressed and transferred over to another machine for
analysis. The analysis would take a lot longer, but can be done in a
batch. (i.e. if you have lots and lots of floppies to go through, in
terms of human interaction time, you're better off scanning them in as
quickly as possible, and then letting the machine process them overnight.)
You'd probably want to scan half tracks as well as any extra tracks the
physical drive head is capable of reaching, if you suspect that the
disks are protected.
Such a setup would be able to handle anything you throw at it and would
even be able to recover data from damaged floppies. Well, not
physically damaged floppies, but floppies where the sync marks or data
are too weak to resolve in normal cases.
8:16 p.m.
Ray Arachelian <ray at arachelian.com> wrote:
Jules Richardson wrote:
In the 90's I did some business reading various-format hard-sectored
5.25" and 8" floppies.
The drives were perfectly standard drives.
The "controller" was a 286-clone (I think I spent $25 for it in the
early 90's, it was hopelessly slow and out-of-date even then) interfaced
by parallel port to a circuit that would read the transitions off the
floppy along with the sector holes for a few revolutions, and store
the timing information in a SRAM chip. Overall it was the SRAM chip
and a dozen chips of TTL on a breadboard, with a ribbon cable to the
PC-clone.
This kludge could read each floppy and store the raw transitions
to a file on the hard drive in under a minute. Yes, that's a lot
longer than optimal but the transfer software was literally something
I threw together in GWBASIC. It is almost true that it takes longer
to write an E-mail of this length than it takes to throw together the
circuit on a protoboard and write the aquisition software :-).
I toyed with the idea of optimizing the software by doing it in
assembler instead of slow GWBASIC, but even for the several hundred
floppies I had to do, I knew I could just chug through all the floppies
in far less time than it would take to round up an assembler and the
concentration to make it work!
So the "reasonably fast PC" and "generously sized hard drive" is
basically a 286 clone rescued from the trash in the 90's along with
its built-in 10MB IDE drive :-).
Tim.
Sure - I wouldn't want that either, I'd
expect the motor to only be
run during each track read, though. Whether starting and stopping the
motor n times to read a disk is a good idea or not I don't know - it's
more stress on the drive for sure, but whether it's sufficiently more
to warrant not doing it I don't know.
What's the worst-case floppy rotation speed - 300rpm? So five
revolutions per second. Fastest transfer rate is 1Mbps (although
didn't some PS/2 systems manage two?) which in theory gives a maximum
of 200Kbits for a track. But with 8x oversampling that'll be 200KB of
data for a single sampled track read. So roughly 18 seconds per track,
given the port speeds you mentioned above.
That's slooooow. Given the nature of the data though, it'd probably
compress (using something like LZW) reasonably well - but then if
driven by an old 8bit CPU it may be that any compression (or
decompression for write transfers) uses up any time saved at the
transfer stage.
Sounds to me like the computer driving this needs to be reasonably fast,
and needs to have lots of RAM and perhaps even a generously sized hard
drive for post-read analysis. 
4:31 p.m.
I'm thinking that the "box built from junk PC
bits" needs more investigation
(would make it easy to provide Ethernet support!). It depends what people
want, though - do they want a box to do data recovery from various floppy
media (which means a selection of drive types plugged in at once), or do they
want a backpack-like single drive solution (which implies they want something
compact, and the bulk of a scrap PC motherboard + PSU is too big)?
So, NOBODY remembers that these devices WERE commercially available??
In ~1987, there was an aftermarket "external drive for reading PC and CP/M
diskettes" being sold for the Macintosh. EXACTLY what we're talking
about. It was a full height 5.25" case, with a 1/2 height 360K drive.
The remainder of the case held an Ampro Little Board. And nothing else.
There was a floppy used to "start-up" the "drive", along with software
on
the Mac. The software on the Mac was, of course, a simple terminal
program.
OB_ reminesce: there two two formats misspelled in their format list.
Both were ones that had previously been misspelled (and later corrected)
on the XenoCopy format list.
I have an Ampro Little Board, but it is in an Ampro case, not disguised as
an "external drive for reading diskettes", and I promised it to somebody
(if/when I dig it out, and remember who I promised it to)
The Quark Megatel (80186?), (or OQO!), might be a better choice for the
guts of the device, due to software availability.
--
Grumpy Ol' Fred cisin at xenosoft.com
19 Oct
19 Oct
8:14 p.m.
Jules Richardson wrote:
Maybe someone can think of a situation where you
*need* more than one
track in memory at once, though. (Note I'm not thinking at all about
storage formats which aren't track-based though)
Disc-to-disc imaging?
DRAM, no. In that sort of situation providing a SIMM /
DIMM socket would
seem the best bet and people can populate it with whatever memory they
have to hand. There is the refresh issue then, though.
Use a CPLD and one of the many free SDRAM-to-SRAM-interface Verilog/VDL models
- <http://www.cmosexod.com/sdram.html> for example.
Possibly, depending on cost. I'd hope that
something could typically be
lashed together (parts cost only) for about 20 bucks, though using a
combination of purchased bits and things from the parts bin [1]. Beyond
that and it's sort of into catweasel territory (albeit with the
convenience of an external device).
Speaking of the Catweasel, does anyone know what the data it returns actually
means? Is it a 'time from last transition to this one' value, or something else?
(I've read the programming specs, and they're about as clear as mud)
out how to program a PIC. I would have absolutely no
idea what to do
with an FPGA, let alone be able to contribute anything to the design :)
Verilog isn't particularly hard to learn, especially if you know C.
From the point of view of the host machine, the set
of operations
needed isn't complex - something like 'assign parameters', 'read
track',
'write track', 'get error information', 'format track',
'seek', and
possibly something like 'download firmware'. It shouldn't actually be a
complex device - but it is best left to someone who has experience of
building SBC-like devices :-)
That'd be me then.
Transfer speed is a huge headache - 200KB or whatever
at RS232 speeds is
painful. Repeat for 160 tracks and it becomes rather annoying! (It
suggests that some sort of simple compression scheme is needed)
Maybe have 115200-baud RS232 and multi-megabit USB as an option?
Add a jumper to the board to switch between them - one position for RS232, the
other for USB.
--
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.
20 Oct
20 Oct
2:32 a.m.
On 20 Oct 2006 at 1:14, Philip Pemberton wrote:
Speaking of the Catweasel, does anyone know what the
data it returns actually
means? Is it a 'time from last transition to this one' value, or something else?
(I've read the programming specs, and they're about as clear as mud)
Just so--and the high order bit of each byte indicates if the INDEX/ line is active. The
Catweasel is exceedingly simple-minded. One might be able to get rid of the SRAM and
counter that the CW uses for track storage if the host controller supported reliable DMA.
Maybe have 115200-baud RS232 and multi-megabit USB as
an option?
Add a jumper to the board to switch between them - one position for RS232, the
other for USB.
I *like* the idea of ethernet myself. Hardly anything, save for some very vintage gear
that
doesn't understand it. I wonder if you could use one of the standard services, such
as ftp, to
nearly avoid having to write anything for the host system...
Cheers,
Chuck
2:52 p.m.
cclist at sydex.com wrote:
I *like* the idea of ethernet myself. Hardly
anything, save for some very vintage gear that
doesn't understand it. I wonder if you could use one of the standard services, such
as ftp, to
nearly avoid having to write anything for the host system...
Hrrm. TFTP would be a natural for this, at least if you limit the
host to Unix/Linux systems. I have no idea how you'd fare for a TFTP
daemon in WinWorld.
Normally TFTP services are read-only or allow only modification to
existing files, but the daemon can be told to allow file creation. The
client code - appliance end - is necessarily tiny, it's lightweight, and
most current clients and daemons support RFC1783 negotiation for
large-file transfers. The appliance could then boot from the host, too,
but that seems like overkill to me.
I have a couple of thoughts to offer about this basic concept.
1) I like the idea of using something like ARM processors With
everything built into the chip, you'd not only get a much smaller
component count, but it seems to me that most of the layout and basic
code would likely be already out there. All that spells a lower
long-run cost in general, and more universal accessibility.
2) RS232/RS422 serial is getting harder to support, and will continue to
get worse. USB is simply not an option for some of us. Anyone with a
PDP-11 or a C64 can support an ethernet connection, and almost (?)
everything needed for implementation for both host and appliance is
already there. Plus, the standards for ethernet transactions are not as
"widely interpreted" as those for USB or serial.
3) It might be well to stipulate and design this as a tool for advanced
users only, at least to start. I'd happily settle for something simple
and raw with 8 pages of install instructions. As an example of what I
mean and why, if TFTP is used, having that set up by hand makes it more
likely that the user understands the security implications and will
handle that.
4) Same concept concerning host platforms. I vote for $FreeOS as the
initial supporting platform, but if DOS works better, so be it. Get it
out the door and running, and somebody else will write support for the
other platforms.
5) For anyone not a network geek, DHCP is a right pain to manage, as is
broadcast TFTP. Again as a short-term implementation, how about
stipulating a dedicated interface, with the IP preprogrammed and
programmable? If can't leave it dedicated, I could set the host IP to
talk to the appliance and reprogram the appliance IP and TFTP target to
match my subnet. That should actually reduce the amount of setup on the
host side.
6) Git 'er dun. I'd like to point at The Great Universal Archive Format
Project of a couple of years ago. Trying to anticipate and solve every
possible permutation killed that deader than hell. Design in some room
to grow, cover the basic common disk formats, and expect v1.0 to suck.
I don't have any design skills to offer, but I'd throw some dollars
in the pot and such free time as I have for testing. This is a tool
that I'd very much like to have.
Doc
3:56 p.m.
Doc Shipley wrote:
cclist at sydex.com wrote:
Hmmm, I wouldn't think that the device being the client and the 'attached'
computer being the server is a good idea; given that we'd likely want to
support more than one OS, it opens up problems of file naming and the like
(which aren't an issue the other way around, as it's the OS-specific bit of
software running on the attached machine which prompts the user for a filename)
Some sort of server on the device *might* be an option depending on
architecture and what tools are out there; HTTP and FTP protocols aren't
rocket science.
Personally I'd like to treat this as though a single attached computer talks
to a single 'remote floppy' device for the purpose of transferring a single
disk image only at this stage - just to keep things as simple as possible and
hopefully speed up development times. Later on there might be scope for having
the device able to store more than one image at once or other fun things...
I *like* the idea of ethernet myself. Hardly
anything, save for some
very vintage gear that doesn't understand it. I wonder if you could
use one of the standard services, such as ftp, to nearly avoid having
to write anything for the host system...
Hrrm. TFTP would be a natural for this, at least if you limit the
host to Unix/Linux systems. I have no idea how you'd fare for a TFTP
daemon in WinWorld. 2) RS232/RS422 serial is getting harder to support,
and will continue to
get worse. USB is simply not an option for some of us. Anyone with a
PDP-11 or a C64 can support an ethernet connection, and almost (?)
everything needed for implementation for both host and appliance is
already there. Plus, the standards for ethernet transactions are not as
"widely interpreted" as those for USB or serial.
Yep. I am concerned that OS support for sending raw Ethernet packets from any
kind of user-space app just isn't there in most modern OSes, though. I really
think it'd have to be IP-based to make the 'client' software do-able (and to
prevent problems with any intermediate network devices), even if that means
more complexity at the device end.
3) It might be well to stipulate and design this as a
tool for advanced
users only, at least to start. I'd happily settle for something simple
and raw with 8 pages of install instructions. As an example of what I
mean and why, if TFTP is used, having that set up by hand makes it more
likely that the user understands the security implications and will
handle that.
If the device is the 'server', what's to set up? Plug it in, give it an IP
address (method to be determined), fire up the client software and talk to it.
4) Same concept concerning host platforms. I vote for
$FreeOS as the
initial supporting platform, but if DOS works better, so be it.
I'm of the same mind there. I expect nearly everyone who will want this can
easily rustle up a DOS / Unix / OSX / whatever system, but Windows is more
problematic for some of us.
5) For anyone not a network geek, DHCP is a right pain
to manage, as is
broadcast TFTP. Again as a short-term implementation, how about
stipulating a dedicated interface, with the IP preprogrammed and
programmable? If can't leave it dedicated, I could set the host IP to
talk to the appliance and reprogram the appliance IP and TFTP target to
match my subnet. That should actually reduce the amount of setup on the
host side.
That was the reason for my question about DHCP; I've almost exclusively used
static IP addresses for anything I've ever set up (mainly because most of the
time they've been servers), so my knowledge of DHCP is lacking.
I can't think of an easy way of doing that initial device configuration in an
Ethernet world, though; DIP switches and the like requires a lot of them, but
any other configuration seems to require some other form of interface to 'kick
start' the initial config.
6) Git 'er dun.
For sure...
I'd love for someone to Just Do This. Providing it's cheap I don't really mind
how it's implemented either; I'd rather have something than nothing. What I
don't want to do is pay 'too much' for something that doesn't do
what's needed
though, or is completely inflexible.
It's probably worth exploring ideas for a couple of weeks, though, just to
see what comes of it. After that, hopefully someone can just get on with it :)
--
If you've ever wondered how you get triangles from a cow
You need buttermilk and cheese, and an equilateral chainsaw
21 Oct
21 Oct
6:59 a.m.
Jules Richardson wrote:
If the device is the 'server', what's to
set up? Plug it in, give it
an IP address (method to be determined), fire up the client software
and talk to it.
Exactly!
I'm of the same mind there. I expect nearly
everyone who will want
this can easily rustle up a DOS / Unix / OSX / whatever system, but
Windows is more problematic for some of us.
Nah! Samba works beautifully. As does
a USB port and formatting or
mounting a FAT32 drive from under Linux.
That was the reason for my question about DHCP;
I've almost
exclusively used static IP addresses for anything I've ever set up
(mainly because most of the time they've been servers), so my
knowledge of DHCP is lacking.
I can't think of an easy way of doing that initial device
configuration in an Ethernet world, though; DIP switches and the like
requires a lot of them, but any other configuration seems to require
some other form of interface to 'kick start' the initial config.
Simple
enough. Don't try to build a specialized device. Reuse normal
hardware and use something like Linux or FreeBSD. It has all that stuff
built in. Support for Ethernet, USB, FireWire, TCP/IP, DHCP, FTP client
and server, HTTP client and server, NFS client and server, Appletalk
server, Samba, FAT-16, FAT32, etc. And the best part is you don't have
to spend 6 months to a couple of years reinventing the wheel just to get
that side of the project going.
6:44 p.m.
Ray Arachelian wrote:
Simple enough. Don't try to build a specialized
device. Reuse normal
hardware and use something like Linux or FreeBSD. It has all that stuff
built in. Support for Ethernet, USB, FireWire, TCP/IP, DHCP, FTP client
and server, HTTP client and server, NFS client and server, Appletalk
server, Samba, FAT-16, FAT32, etc. And the best part is you don't have
to spend 6 months to a couple of years reinventing the wheel just to get
that side of the project going.
There's definitely a lot of merit to that approach. The downside is that at
the interface to the floppy drive(s) there seems to be two possible routes:
1) Use an off-the-shelf catweasel board
2) Build a new board which is totally open (unlike catweasel)
Option 1 suffers from lack of good driver support, documentation, and the
proprietary nature of the system. Option 2 suffers from a total lack of any
hardware interface software (anyone here have experience of writing linux
kernel drivers?)
I'd *love* an 'open source' catweasel board, I really would. But it's
dependent on someone being able to write the necessary kernel-level driver for
the hardware (in a DOS world it's not so bad, but the linux kernel is total
spaghetti whenever I've looked and there's no apparent 'house style' for
how a
kernel driver should work)
cheers
Jules
4:37 p.m.
6) Git 'er
dun.
For sure...
I'd love for someone to Just Do This. Providing it's cheap I don't really
mind
how it's implemented either; I'd rather have something than nothing. What I
don't want to do is pay 'too much' for something that doesn't do
what's needed
though, or is completely inflexible.
It's probably worth exploring ideas for a couple of weeks, though, just to
see what comes of it. After that, hopefully someone can just get on with it :) 
6:24 p.m.
On Oct 21, 2006, at 4:37 PM, Fred Cisin wrote:
How can anybody see an Ampro Little Board, and NOT
immediately realize
that there, sitting in front of you, IS the great mythical external
drive??
Have you found a stash of Ampro Little Boards? If so, please
share. :)
-Dave
--
Dave McGuire
Cape Coral, FL
6:54 p.m.
On Sat, 21 Oct 2006, Dave McGuire wrote:
Have you found a stash of Ampro Little Boards? If
so, please
share. :)
Sorry, I have to apologize;
I didn't realize that they had become rare.
There were at least a half a dozen different brands of miniature
motherboards in that form factor. Are they all rare now?
--
Grumpy Ol' Fred cisin at xenosoft.com
6:58 p.m.
On Oct 21, 2006, at 6:54 PM, Fred Cisin wrote:
Well I'm not sure if I'd call them "rare", but I certainly
haven't
had much luck finding one. My primary effort (along these lines) has
been to find a Ferguson Big Board, but I've been halfheartedly
looking for a Little Board for quite a while as well.
Have you
found a stash of Ampro Little Boards? If so, please
share. :)
Sorry, I have to apologize;
I didn't realize that they had become rare. There were at least a half a dozen different brands of
miniature
motherboards in that form factor. Are they all rare now?
Well, the PC-ish ones certainly aren't; I've got a few of those in
my closet and they show up on eBay all the time. The CP/M ones,
well, I'm an old CP/M hack (from when it was "modern") and I've never
even seen one in the flesh.
-Dave
--
Dave McGuire
Cape Coral, FL
22 Oct
22 Oct
2:32 p.m.
Fred Cisin wrote:
On Sat, 21 Oct 2006, Dave McGuire wrote:
Will they all read / write FM density, and allow raw bit-level access to the
track data coming from the floppy drive, though? I think that's what we're
hoping for from a data imaging device...
Actually, there's perhaps three different projects that would be useful to tackle:
1) Off-the-shelf imaging box using a stock FDC chip capable of MFM and FM
(with little ability to handle faulty media)
2) Custom imaging box [ which may mean scrap PC + extras ] that does data
sampling at the drive digital interface level and reconstruction ( /
deconstruction) in software.
3) Custom imaging box which hooks to the floppy drive's heads directly and
uses a DAC / ADC; essentially as option 2 but can cope with marginal signal
levels to reconstruct data.
Option 1 I think is reasonably well covered with things like Imagedisk. Option
3 would be rather useful to a lot of us, but is a lot of work, both to design
and set up on a per-drive basis. Option 2 is more middle ground, and seems to
be within the realms of something that can be designed using a fairly low
parts count and (hopefully) built by most hobbyists.
Unless I'm completely misreading the discussion :-)
cheers
Jules
Have you found a stash of Ampro Little Boards?
If so, please
share. :)
Sorry, I have to apologize;
I didn't realize that they had become rare.
There were at least a half a dozen different brands of miniature
motherboards in that form factor. Are they all rare now?
3:20 p.m.
Have you found a stash of Ampro Little Boards? If
so, please
. . .
There were at least a half a dozen different brands of miniature
motherboards in that form factor. Are they all rare now? Will they all read / write FM density,
WITH A FEW EXCEPTIONS.
The x86 ones tend to be reasonable implementations of 37C65,
The Z80 ones tend to be WD 179x
and allow raw bit-level access to the
track data coming from the floppy drive, though?
No
well, the 179x (Z80 ones) have a track read, but additional MINOR
circuitry will be needed to get flux transition level access.
I think that's what we're
hoping for from a data imaging device...
As you state later, there are at least three different projects/goals
being conflated here!
1) One of the most commonly stated is "I want an external 5.25" drive".
2) I want a flux transition editor and recorder
3) I want a universal recovery tool.
Actually, there's perhaps three different projects
that would be useful to tackle:
1) Off-the-shelf imaging box using a stock FDC chip capable of MFM and FM
(with little ability to handle faulty media)
2) Custom imaging box [ which may mean scrap PC + extras ] that does data
sampling at the drive digital interface level and reconstruction ( /
deconstruction) in software.
3) Custom imaging box which hooks to the floppy drive's heads directly and
uses a DAC / ADC; essentially as option 2 but can cope with marginal signal
levels to reconstruct data.
Unless I'm completely misreading the discussion
:-)
Each participant has hold of a different part of the elephant.
20 Oct
20 Oct
6:05 p.m.
On Fri, 20 Oct 2006, Doc Shipley wrote:
1) I like the idea of using something like ARM
processors With
everything built into the chip, you'd not only get a much smaller
component count, but it seems to me that most of the layout and basic
code would likely be already out there. All that spells a lower
long-run cost in general, and more universal accessibility.
I was thinking the same thing. Heck, if you are using an ARM already, lots
of *nix type OS have already been ported to it, which might mean there are
already even more software tools ready for use.
2) RS232/RS422 serial is getting harder to support,
and will continue to
get worse. USB is simply not an option for some of us. Anyone with a
PDP-11 or a C64 can support an ethernet connection, and almost (?)
everything needed for implementation for both host and appliance is
already there. Plus, the standards for ethernet transactions are not as
"widely interpreted" as those for USB or serial.
Personally, if someone is going to build a small device such as this, I'd
really like to see at least 3 interface options; RS232 serial, USB 2.0,
and ethernet. These would pretty much cover 99% of the folks who'd want to
use it. If someone wanted to get fancy, firewire would be another option,
but USB 2.0 would cover most of the folks who'd want firewire anyway.
3) It might be well to stipulate and design this as a
tool for advanced
users only, at least to start. I'd happily settle for something simple
and raw with 8 pages of install instructions. As an example of what I
mean and why, if TFTP is used, having that set up by hand makes it more
likely that the user understands the security implications and will
handle that.
4) Same concept concerning host platforms. I vote for $FreeOS as the
initial supporting platform, but if DOS works better, so be it. Get it
out the door and running, and somebody else will write support for the
other platforms.
5) For anyone not a network geek, DHCP is a right pain to manage, as is
broadcast TFTP. Again as a short-term implementation, how about
stipulating a dedicated interface, with the IP preprogrammed and
programmable? If can't leave it dedicated, I could set the host IP to
talk to the appliance and reprogram the appliance IP and TFTP target to
match my subnet. That should actually reduce the amount of setup on the
host side.
Is anyone else here familiar with the Empeg? StrongARM processor, USB,
serial, ethernet and running Linux. One thing that I think they got right
were the connectivity options. USB works pretty much out of the box, as
does serial. Ethernet support can work with DHCP or can be manually
configured.
6) Git 'er dun. I'd like to point at The
Great Universal Archive Format
Project of a couple of years ago. Trying to anticipate and solve every
possible permutation killed that deader than hell. Design in some room
to grow, cover the basic common disk formats, and expect v1.0 to suck.
I don't have any design skills to offer, but I'd throw some dollars in
the pot and such free time as I have for testing. This is a tool that
I'd very much like to have.
I have a literal pile of 5.25" drive chassis with DB37 connectors on
them...
I'm not sure which type of 5.25" drive was still installed when they were
decommissioned though.
I am setup where I can fab cables and wiring harnesses (with the most
common types of connectors anyway). Anything I don't have in the way of
tooling I can probably find if needed too.
-Toth
10:26 p.m.
Tothwolf wrote:
On Fri, 20 Oct 2006, Doc Shipley wrote:
True. I'm sure one of the guys over on the BBC micro mailing list has
mentioned he's come up with an IP stack for one of the ARM boards; I'll have a
hunt through messages sometime.
1) I like the idea of using something like ARM
processors With
everything built into the chip, you'd not only get a much smaller
component count, but it seems to me that most of the layout and basic
code would likely be already out there. All that spells a lower
long-run cost in general, and more universal accessibility.
I was thinking the same thing. Heck, if you are using an ARM already,
lots of *nix type OS have already been ported to it, which might mean
there are already even more software tools ready for use. Personally, if someone is going to build a small
device such as this,
I'd really like to see at least 3 interface options; RS232 serial, USB
2.0, and ethernet. These would pretty much cover 99% of the folks who'd
want to use it.
Personally I'd prefer SCSI over most other options - for the level of what
we'd need it's easy to implement in hardware and easy to program for at the
device end, plus certainly for Linux I know there are user-land tools
available to send out raw SCSI commands to a device. Any kind of serious data
recovery box I built would have SCSI on it anyway, in order to support
archival from disks and tapes. I'm atypical, though :-)
Is anyone else here familiar with the Empeg?
Yahuh - I've met the designer, actually; he lives not too far from me in the
UK and was the person who gave the museum our BeBox. Nice guy.
cheers
Jules
19 Oct
19 Oct
5:21 p.m.
Probably use something a bit more common, say an ARM?
Not that I
have anything against a Z80 (or Z180, or EZ80). Just that extra
horsepower can be very nice, even if you don't need it right away.
If you are willing to go to an ARM, then I would put on say 16M and
have lots of room for a complete image - an ethernet inferface would
also be easy (built into many ARM devices), and would allow fast
transfer of images.
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
4:44 p.m.
Dave Dunfield wrote:
Ethernet seems ideal - high-speed and flexible. What I'm not sure of is how
such a box would get configured with its IP address, nor once it was
configured how it would be found on the network by a controlling system
application somewhere.
Maybe DHCP solves half that problem; can a device broadcast on the network and
find a DHCP server without being told of its IP address in advance? Even
assuming it can, and the DHCP server assigns it an IP address, I'm not sure
how client controlling machines would then locate it on the network, though.
Doubtless both questions are easily answered by a trained network admin,
though :-)
Last thing we probably need though is something that relies on DHCP, or on any
particular flavour of OS being present on any machine on the network.
[All of this is on-topic enough, but is it of interest to the majority? Or is
it something better taken to a mailing list for those interested that's set up
with the specific aim of bashing out some ideas and hopefully getting
something closer to realisation?]
cheers
Jules
Probably use
something a bit more common, say an ARM? Not that I
have anything against a Z80 (or Z180, or EZ80). Just that extra
horsepower can be very nice, even if you don't need it right away.
If you are willing to go to an ARM, then I would put on say 16M and
have lots of room for a complete image - an ethernet inferface would
also be easy (built into many ARM devices), and would allow fast
transfer of images.
6:15 p.m.
If you are
willing to go to an ARM, then I would put on say 16M and
have lots of room for a complete image - an ethernet inferface would
also be easy (built into many ARM devices), and would allow fast
transfer of images.
Ethernet seems ideal - high-speed and flexible. What I'm not sure of is how
such a box would get configured with its IP address, nor once it was
configured how it would be found on the network by a controlling system
application somewhere. Maybe DHCP solves half that problem; can a device
broadcast on the network and
find a DHCP server without being told of its IP address in advance? Even
assuming it can, and the DHCP server assigns it an IP address, I'm not sure
how client controlling machines would then locate it on the network, though.
Doubtless both questions are easily answered by a trained network admin,
though :-)
Last thing we probably need though is something that relies on DHCP, or on any
particular flavour of OS being present on any machine on the network.
All solvable problems, however in my experience, the IP stack will add as much
complexity to your embedded device (or more) than the disk drive interface.
Why does it have to be RS-232 or IP - does nobody remember plain simple
ethernet anymore? (almost as simple as RS-232 - way faster).
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
5:46 p.m.
Dave Dunfield wrote:
Why does it have to be RS-232 or IP - does nobody
remember plain simple
ethernet anymore? (almost as simple as RS-232 - way faster).
A fair point. Wonder what the complexity is like at the 'client' end for the
most common OSes though? DOS I imagine is easy because you can pretty much do
what you want - but I wonder how hard it is to talk raw Ethernet from
user-space applications for OSes like Linux and Windows?
Agreed that a full IP stack is a pain for an embedded device (I believe Phil
Blundell's done some work with IP stacks and ARM devices, though). For
something built from an off-the-shelf redundant PC though it'd be easy, with
the exceptions of how to do the IP address assignment / discovery.
(For a data recovery type of scenario, I expect several different drive types
will be needed anyway - so the bulk of a PC PSU / motherboard / case is hardly
an issue!)
cheers
Jules
12:07 p.m.
Jules Richardson wrote:
Even assuming it can, and the DHCP server assigns it
an IP
address, I'm not sure how client controlling machines would then locate
it on the network, though. Doubtless both questions are easily answered
by a trained network admin, though :-)
You send a packet to the broadcast address.
Say your client is 10.0.0.1, and the target device is 10.0.0.2, and the subnet
mask is 255.0.0.0. That means your broadcast address is 10.255.255.255.
Sending a packet to the broadcast address means any device on that subnet will
receive the packet. So the target listens on whatever port it's using, the
source machine sends out a broadcast, and the target responds by sending a
unicast packet (e.g. 10.0.0.2 to 10.0.0.1) back to the source to advertise its
presence.
As far as protocols go, UDP is nice and simple, but doesn't offer any form of
guarantee that a sent packet will arrive, so you'd probably need to hack
together some form of send/acknowledge/repeat-if-scrambled/repeat type system.
[All of this is on-topic enough, but is it of interest
to the majority?
Or is it something better taken to a mailing list for those interested
that's set up with the specific aim of bashing out some ideas and
hopefully getting something closer to realisation?]
Jules, if you want a mailing list setting up, email me off-list and I'll set
you one up on my server. Assuming you don't mind it running on Mailman, that is.
--
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.
21 Oct
21 Oct
6:54 a.m.
Philip Pemberton wrote:
You send a packet to the broadcast address.
Say your client is 10.0.0.1, and the target device is 10.0.0.2, and
the subnet mask is 255.0.0.0. That means your broadcast address is
10.255.255.255. Sending a packet to the broadcast address means any
device on that subnet will receive the packet. So the target listens
on whatever port it's using, the source machine sends out a broadcast,
and the target responds by sending a unicast packet (e.g. 10.0.0.2 to
10.0.0.1) back to the source to advertise its presence.
As far as protocols go, UDP is nice and simple, but doesn't offer any
form of guarantee that a sent packet will arrive, so you'd probably
need to hack together some form of
send/acknowledge/repeat-if-scrambled/repeat type system.
Keep it simple and open.
Use protocols and code that already exist.
HTTP, FTP, Samba and NFS servers come to mind. Use Linux or some sort
of BSD. All the code is already built in. And yes, you can use DHCP
with those. Reuse some older PC like a P2. Otherwise, you'll spend
lots of time engineering the hardware AND the software. It'll be
difficult enough just to write the software to get it to do the core
task of imaging the disks in the first place. Don't make it more
complex than it has to be.
Don't be afraid of requiring a generic VGA monitor and a normal USB/AT
keyboard for configuration. It greatly simplifies things to have them,
and everyone has them already or they wouldn't be trying to image
floppies in the first place.
If you go with a custom black box design that lacks them, you'll wind up
re-engineering lots and lots of kludges just to hide the fact that this
is a computer. Treat it like a normal computer and slap some easy to
use UI on top of it. Hell, use Firefox and a web server to drive the
software. There are lots of wonderful tiny Linux distros that are well
suited for this sort of thing.
Keeping it as simple as possible and using what's already out there will
save lots of time, effort, and headaches. If you try to invent your own
protocols, you'll be working on the other stuff for half a year and
still not be able to build something that's as robust and as flexible as
reusing existing OS code.
19 Oct
19 Oct
7:24 p.m.
Dave Dunfield wrote:
Can we add a LEG later on?
OK, OK! I'm getting my hat.
Doc
Probably use
something a bit more common, say an ARM? Not that I
have anything against a Z80 (or Z180, or EZ80). Just that extra
horsepower can be very nice, even if you don't need it right away.
If you are willing to go to an ARM, then I would put on say 16M and
have lots of room for a complete image - an ethernet inferface would
also be easy (built into many ARM devices), and would allow fast
transfer of images. 
3:59 p.m.
On Thu, 19 Oct 2006, Jules Richardson wrote:
Actually, some of the PIC micros have RS232 ability
(with the addition
of line drivers) I believe and might kill two birds with one stone. Not
sure what the cost of RAM would be - cheap if DRAM I suppose, but then
there's the complexity of refreshing... SRAM would make life really
easy.
I don't think that using an RS232 interface would be the Ideal Approach.
The objective of this external drive box is to equip a "modern" computer
with archaic disk drives. Given this, a USB interface would be the better
choice since it would presumably require no additional driver fiddling.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
4:13 p.m.
On Thu, 19 Oct 2006, Chuck Guzis wrote:
If you're thinking about a Catweasel-type external
box, then I'd put
lots of memory (10 MB or more) and some programmable intelligence in
it (so the "nuts and bolts" isn't subject to OS platform-related
issues). Maybe interface with something dirt-common, like RS-232C.
Of course, this would push the price of a basic unit up pretty high.
If you don't mind it being rather bulky, . . .
just start with an old AT. Put in a lot of RAM (up to 16M on 286 or
386SX), a catweasel, a serial port, and some relatively trivial software.
The catweasel is the only part that will cost more than a burger.
4:35 p.m.
Fred Cisin wrote:
On Thu, 19 Oct 2006, Chuck Guzis wrote:
That's actually exactly where I was heading with design of such a box of
tricks for our museum. I don't want the hassle of a hard disk in there, though
- but even if I can't figure out how to graft my own boot ROM into the thing,
booting from a CF card on an IDE channel would probably do the job (I bought a
CF-IDE adapter a couple of months ago with just such a purpose in mind)
The other benefit would be that that same box could likely support other
classes of device other than floppies which used interfaces like SCSI and IDE.
My main headache is with catweasel drivers, though - the use of a CF card
probably rules out Windows (which doesn't lend itself to a headless box
anyway), but catweasel support software for non-Windows OSes looked to be
pretty thin on the ground.
cheers
Jules
If you're thinking about a Catweasel-type
external box, then I'd put
lots of memory (10 MB or more) and some programmable intelligence in
it (so the "nuts and bolts" isn't subject to OS platform-related
issues). Maybe interface with something dirt-common, like RS-232C.
Of course, this would push the price of a basic unit up pretty high.
If you don't mind it being rather bulky, . . .
just start with an old AT. Put in a lot of RAM (up to 16M on 286 or
386SX), a catweasel, a serial port, and some relatively trivial software.
The catweasel is the only part that will cost more than a burger.
12:21 a.m.
On Wed, 18 Oct 2006, Barry Watzman wrote:
Don't know if any of you saw this, but a
5.25" floppy disk drive just went
for $192 on E-Bay tonight (Wed., 10/18).
It was a "backpack" external parallel port drive, New Old Stock in Box,
still shrink wrapped.
I am strongly of the opinion that there is a far bigger market than is
generally perceived for a USB floppy disk controller that will support 5.25"
and even 8" drives, if only someone would develop the product.
I agree. Perhaps one can start with one of the open-source FPGA
implementations of floppy controllers known to support 5.25" and 3.5"
drives. Couple that with (mumble)'s 8" converter gizmo. Add to that a
general-purpose USB controller chip.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
11:20 a.m.
David Griffith wrote:
On Wed, 18 Oct 2006, Barry Watzman wrote:
I know we go around this issue every few months, but it is worth considering
your target market.
If the aim is for this to be more useful to classic computing enthusiasts
(which the inclusion of 8" support suggests) then I would expect as a group
we're more likely to have knowledge of programming / building gadgets based
around classic 8-bit CPUs and some EPROM, or maybe PIC microcontrollers, than
we are of FPGA technology.
Same goes for the use of USB for an interface - witness the recent posts from
people who much prefer to have RS232 serial around on their systems.
Of course maybe the solution is two parallel projects which share the same
design philosophy and a lot of the high-level stuff, even though the low-level
hardware and interface is different?
Either way, I'd say it's probably not worth making a 'classic' floppy
controller. We (as a community) badly need a gadget that can read/write raw
data at the track level across the interface boundary (be it USB, serial, or
something else) - given that need it'd be sensible to make that a design goal
Don't know if any of you saw this, but a
5.25" floppy disk drive just went
for $192 on E-Bay tonight (Wed., 10/18).
It was a "backpack" external parallel port drive, New Old Stock in Box,
still shrink wrapped.
I am strongly of the opinion that there is a far bigger market than is
generally perceived for a USB floppy disk controller that will support 5.25"
and even 8" drives, if only someone would develop the product.
I agree. Perhaps one can start with one of the open-source FPGA
implementations of floppy controllers known to support 5.25" and 3.5"
drives. Couple that with (mumble)'s 8" converter gizmo. Add to that a
general-purpose USB controller chip. from day 1.
cheers
Jules
7:06 p.m.
On Wed, 18 Oct 2006, Barry Watzman wrote:
Don't know if any of you saw this, but a
5.25" floppy disk drive just
went for $192 on E-Bay tonight (Wed., 10/18).
It was a "backpack" external parallel port drive, New Old Stock in Box,
still shrink wrapped.
I missed that one, but I guess its time for me to pull my used backpack
drives out of storage... I actually can get to them right now since I'm
cleaning out and sorting stuff anyway :P
The NOS TRS-80 cables I packratted away for decades are doing well on eBay
since I re-unearthed them again too.
-Toth
20 Oct
20 Oct
1:23 a.m.
If you're thinking about putting two drives on a BP controller or changing the types,
I think
I've got the MicroSolutions "write drive type to NVRAM" utility here
somewhere if anyone
needs it.
Cheers,
Chuck
6489
days inactive
6492
days old
42 comments
13 participants
participants (13)
-
cclist＠sydex.com -
cisin＠xenosoft.com -
classiccmp＠philpem.me.uk -
dave06a＠dunfield.com -
dgriffi＠cs.csubak.edu -
doc＠mdrconsult.com -
gordon＠gjcp.net -
julesrichardsonuk＠yahoo.co.uk -
mcguire＠neurotica.com -
ray＠arachelian.com -
shoppa_classiccmp＠trailing-edge.com -
tothwolf＠concentric.net -
Watzman＠neo.rr.com