3 Aug
2005
3 Aug
'05
12:56 p.m.
Yes. - What
happens when the catweasel becomes unavailable?
What happens when (disk controller of choice) become unavailable? :) A grave
omission for something thats supposed to archive
non-PC-standard disks.
If you're supposing the user can wire up a disk controller, why can't
they wire up a simple 34(SA400) to 50(SA800) pin adapter cable? Also,
you can buy an SA400/SA800 adaptor board that someone has made, which
properly controls the TG43 line. Unfortunately, I can't remember the
name of the board or who made it right now. But would have
tied the thing to one particular development
environment (Here's you VisualC++ library - have a nice day). The
best solution is a fully open and documented description of the
hardware and lots of sample code.
There's no reason a bit of C wrapper code has to be tied to any
particular 'development environment'. I'd say that by ignoring (specifically) Apple ][
and C64, you're missing
a large percentage of possible software/users.
another missed point ... anyone who's been following my work knows that I
have implemented a number of systems to cheaply archive, distribute and
restore disk images for various systems. This would have been just another
piece in the puzzle. Such systems already exist (and I use them) to archive
AppleII and C64 images.
Still deciding
if it's worth it - I'll record your "NO" vote.
Not to discourage you, but, I'd echo the sentiment above. I'd suggest
that if you do want to produce something, make something that can read
the disk on a flux-transition level, and store that sort of data.
Something nice and generic. That way, you can do all the processing in
software, and handle any format of disk that comes your way. 
3 Aug
3 Aug
1:50 p.m.
Dave Dunfield wrote:
lots of other arguments snipped.
Ok - I don't need to get dumped on anymore. Consider the idea dropped...
Umm, please no. I've been staying out of this because I don't have
the hardware skills or the knowledge of formats to contribute, but I do
have an opinion, or at least I see some factors that make your idea
desirable.
1) The first point is something Dave already touched on - there is no
One True Solution here. I rad Dave's proposal and I envision a *group*
of products, all based on the same basic framework and each supporting
more-or-less similar formats and media.
It might theoretically be _possible_ to create a device that will
read every floppy format ever devised, but why on earth would that be
_desirable_? Such a logical behemoth is bound to be extremely complex
and expensive, and most of its features and formats will be useless to
most of its users.
For example, I have an XE1514 cable and a 1514 drive. I do not need
those features in an SBC solution. A parallel port and compatible
supporting software will be enough.
2) *Any* hardware solution for archiving/migrating/transcribing media
is going to be, financially, a negative-sum project. I think that's a
given. As interested parties, we need to expect it to be Not Cheap, at
least initially. I'm speaking in terms of time as much as money.
3) Individual Computers is a profit-making venture. The catweasel is a
current product. While I use and like mine, I don't expect it ever to
be an open product. I personally would like to see "the standard" based
on more common hardware.
4) Nothing Dave does is written in stone. Worst case, it would be a
marginally applicable tool for a few common formats, and a prototypical
starting point for further development.
5) (Go ahead and shoot me now.) I see absolutely no reason to base an
SBC archival tool on Z80, 8008, or any other classic platform, unless
that directly facilitates its function. This is a tool, and should be
built from the most efficient and available components.
6) There's not a chance that everybody is going to get everything they
need from the first iteration of this project. Anybody remember The
Search For The Perfect Archival Format?
We have here someone who's interested and experienced, who has a
track record of creating useful and useable Stuff, apparently has the
resources to START work on a much-needed set of tools, and who is
OFFERING TO DO IT. I say we applaud instead of throwing rocks.
Doc
2:13 p.m.
Doc Shipley wrote:
...
We have here someone who's interested and
experienced, who has a track
record of creating useful and useable Stuff, apparently has the
resources to START work on a much-needed set of tools, and who is
OFFERING TO DO IT. I say we applaud instead of throwing rocks.
Doc, and Dave,
I apologize if you consider my comments among the rocks. Dave solicited
feedback; that it wasn't all positive shouldn't make Dave feel dumped on, and
shouldn't be viewed as rocks. I thought the comments on both sides had merit
and none were mean. There is also no need to chose between applauding and
throwing rocks if both are merited. :-)
2:17 p.m.
On Wed, 2005-08-03 at 12:50 -0500, Doc Shipley wrote:
Dave Dunfield wrote:
picking up on that one... presumably the hardware copes with a huge
majority of formats out there if it can handle hard and soft sectored
floppies by buffering raw data at the track level? It's the software
which then dictates how many formats can actually be interpreted, but as
far as the hardware's concerned doesn't it just need to be able to shunt
data around between disk / buffer / host with no interpretation of what
the data actually is (OK so there's a bit of extra logic there to do the
right thing for hard sectored floppies)
In other words, would it actually be a logical behemoth?
lots of other arguments snipped.
Ok - I don't need to get dumped on anymore. Consider the idea dropped...
Umm, please no. I've been staying out of this because I don't have
the hardware skills or the knowledge of formats to contribute, but I do
have an opinion, or at least I see some factors that make your idea
desirable.
1) The first point is something Dave already touched on - there is no
One True Solution here. I rad Dave's proposal and I envision a *group*
of products, all based on the same basic framework and each supporting
more-or-less similar formats and media.
It might theoretically be _possible_ to create a device that will
read every floppy format ever devised, but why on earth would that be
_desirable_? Such a logical behemoth is bound to be extremely complex
and expensive, and most of its features and formats will be useless to
most of its users. 2) *Any* hardware solution for
archiving/migrating/transcribing media
is going to be, financially, a negative-sum project. I think that's a
given. As interested parties, we need to expect it to be Not Cheap, at
least initially. I'm speaking in terms of time as much as money.
Agreed. I couldn't care less about the time aspect (providing it gets
done before all floppies on the planet have rotted :) but I'd rather
something that didn't require expensive ICs or programming tools (for
the hardware controller side)
5) (Go ahead and shoot me now.) I see absolutely no
reason to base an
SBC archival tool on Z80, 8008, or any other classic platform, unless
that directly facilitates its function. This is a tool, and should be
built from the most efficient and available components.
My only reason for saying that was really cost / complexity grounds. Eg.
most of us who can throw a few bits of electronics together and see the
need to archive things will have access to an EPROM programmer. That's
probably less true of PIC programmers or other more modern devices. Old
8 bit CPUs are easily obtainable free in scrap equipment (and easily
understandable and well documented); the latest whizzy all-in-one IC
might well be expensive and a nightmare to program for anyone not
familiar with it.
*but* at the end of the day complexity's important too. An old 8 bitter
won't be fast enough without support hardware to read/write between
floppy and buffer memory, nor will it address the whole buffer in one
go. That may well dictate the use of a more modern 16 bit chip running
at several tens of MHz... but it depends how complex surrounding
hardware would be otherwise.
6) There's not a chance that everybody is going
to get everything they
need from the first iteration of this project. Anybody remember The
Search For The Perfect Archival Format?
Well, once we have the hardware in place it can flourish :-)
cheers
Jules
3:01 p.m.
Ok - I don't need to get dumped on anymore.
Consider the idea
dropped...
Please don't just drop the idea! The catweasel requires a
handy PC (or Amiga or whatnot). There is definitely place
for something self-contained that just gathers the data
and makes it available via RS232 (or ethernet or whatever).
For a start, it means I could carry it out to the garage
and hook it up to the _heavy_ dual RX02 and read those
WT78 floppies! (OK, so some has probably done those,
but you get the idea).
Give it some simple non-volatile storage (like a PCMCIA
card etc.) and it would be quite simple to carry one off
to someone else's place and archive stuff without
having to drag a PC along.
Antonio
7:44 p.m.
On Wed, 3 Aug 2005, Dave Dunfield wrote:
lots of other arguments snipped.
Ok - I don't need to get dumped on anymore. Consider the idea dropped...
Although there is substantial overlap,
EVERYBODY has different goals or desires.
No matter what you build, SOMEBODY will want MORE.
"Why not include Z80/6502/6800/6809/68000 emulation,
keyboard and video, and have it capable of RUNNING
everything that it sees?"
An external WD style disk controller sounds wonderful!
Build YOUR device; and put me down for one!
Once it is available, somebody else can be saddled with
making an external flux transition unit.
With IDE, serial, parallel, ethernet, SA400, AND USB interfaces!
... and software compatible with Catweasel AND COPYII-PC
... and 40 pin DIP plug to plug-in in place of stock FDC chip
... and PLCC? PGA?
... and enough RAM to hold multiple complete disk images
... and CF, SD, SM, etc. card memory
... and capability of operating stand-alone (without PC)
... and "drivers" to use as primary disk controller
... and software to interpret the file systems of every OS,
... and full selection of "deleted data" address marks for TRS-80
... and software to defeat copy protection
... and damaged sector/track recovery
... and compatability to run on any/all classic platforms
... and Windoze NT/2k,XP compatability
... and software to have it look like a "normal" drive to Windoze
... and drive indexed off of spindle, instead of index hole
... and 1M data tranfer rate for 2.8M (IBM, Next)
... and floptical
... and capability of also handling ST506 hard drives
... MFM, RLL, ESDI, IDE, SASI, SCSI, . . .
... ZIP, LS120, Bernoulli, cartridge drive, tape drives, . . .
Yeah, I want that! But in the meantime,
I'd be very happy to see Dave's device.
--
Grumpy Ol' Fred cisin at xenosoft.com
6902
days inactive
6902
days old
5 comments
6 participants
participants (6)
-
a.carlini＠ntlworld.com -
cisin＠xenosoft.com -
dave04a＠dunfield.com -
doc＠mdrconsult.com -
frustum＠pacbell.net -
julesrichardsonuk＠yahoo.co.uk