6 Apr
2007
6 Apr
'07
12:27 p.m.
I just discovered a flaw in my DMA setup sequence which exposes
a timing window during which bus noise can cause false dma
events (DMA enabled but FDC not driving it yet), leading to
ImageDisk not working correctly in some PCs.
I have corrected this (with the help of a couple of very knowlegeable
list members - thanks guys!), and released an updated ImageDisk 1.16
with the fix.
I have also updated the source code archive to include the new
TESTFDC and .TD0 conversion utilities.
Enjoy,
Dave
PS: I found this while fooling with and old 486 because I finally
decided to see if I could get my Central Point DEluxe Options Board
working - the TRANSCOPY that I had for it wouldn't run at all (froze
during the analyze phase), but I downloaded one from the net which
does, but I have been unsuccessful in actually recording and
recreating a plain-jane DOS DD 360k disk - I've gotten it to complete
the motions a couple of times but the result has errors in it.
This is a 486/25 (slowest I could make it) - does anyone know if
the CTP board will work reliably, or do I need to go slower...
Any other common causes of problems...?
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
7 Apr
7 Apr
1:33 a.m.
Dave Dunfield wrote:
PS: I found this while fooling with and old 486
because I finally
decided to see if I could get my Central Point DEluxe Options Board
working - the TRANSCOPY that I had for it wouldn't run at all (froze
during the analyze phase), but I downloaded one from the net which
does, but I have been unsuccessful in actually recording and
recreating a plain-jane DOS DD 360k disk - I've gotten it to complete
the motions a couple of times but the result has errors in it.
The Option Board was, IIRC, completely software-driven and extremely
susceptible to machine speed (and sometimes even interrupt noise, which
is why they made TCS.EXE which doesn't use EMS and might disable some
hardware interrupts as well). The fastest machine I could get it to
work in reliably was an AMD 386-40, with the ISA bus speed at either
clock/5 (8MHz) or locked at a timer clock integral divider (ie.
7.16MHz). If memory serves, I had the best results at 7.16MHz.
Currently I keep mine in my 5160.
Trivia: Central Point received legal pressure from companies late in
the Option Board's life; as such, later revisions of the software, while
more compatible with faster machines, actually copy *less* protection
methods -- and in a few cases, will copy a diskette such that the copy
will work but copies of the copy will not. So my usual operation with
the OB is to use the latest version to make a backup copy; if that
fails, start going backward through revisions until I find one that works.
I have only come across one protection method the OB cannot duplicate
(other than laser holes, of course): Cop's Copylock II. It was used
mostly in Europe.
This is a 486/25 (slowest I could make it) - does
anyone know if
the CTP board will work reliably, or do I need to go slower...
Slower. Look for ICD.COM (and companion ICE.COM) which disable the
internal cache. I believe you can find a copy of them here:
http://www.oldskool.org/guides/oldonnew/resources/icdice.zip
Also, add wait states if possible. Fix bus speed at or close to ISA
standard (see above).
I heard through the grapevine that, sadly, the creator of the Option
Board (everything, hardware to software) passed away in the mid 1990s,
so there is no official resource to ask about the OB. But it was always
one of my favorite peripherals, and just watching it try to match track
length while copying gave me some insight into FDC operation (and
protection methods!)
I used to have programming information on the OB; I don't know where it
is but I can try to dig it up if you think you'd find it useful. Also,
I'm assuming you've seen the treasure trove of info over at
http://retro.icequake.net/dob/ ?
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
11:38 a.m.
On 7 Apr 2007 at 0:33, Jim Leonard wrote:
The Option Board was, IIRC, completely software-driven
and extremely
susceptible to machine speed (and sometimes even interrupt noise, which
is why they made TCS.EXE which doesn't use EMS and might disable some
hardware interrupts as well). The fastest machine I could get it to
work in reliably was an AMD 386-40, with the ISA bus speed at either
clock/5 (8MHz) or locked at a timer clock integral divider (ie.
7.16MHz). If memory serves, I had the best results at 7.16MHz.
It should also be noted (if it hasn't already) that the Deluxe Dption
board and the Option board are not the same animal. But neither will
run in anything much faster than a slow 386. I've still got one in
original shrink wrap as well as one installed in a 5160.
I seem to remember something the DOB having a tie-in with a group of
Hong Kong investors, and for the life of me, can't seem to recall the
story. It may have been that the DOB was killed off when the HK
people came in because the business of copying protected software was
a little too much of a legal gray area for them.
Be advised that the number of formats that a DOB can process is
fairly limited. A Catweasel is far more flexible--and programming
information is freely available, as well as being able to run on the
fastest x86 PCI-equipped boxes. At one time, I began accumulating a
pile of notes on DOB operation, but dropped it when the CW came out.
There was no point in continuing the mental abuse.
Cheers,
Chuck
3:55 p.m.
It should also be noted (if it hasn't already)
that the Deluxe Dption
board and the Option board are not the same animal.
I was aware of that - I've found detailed info on the OB but not the DOB.
But neither will
run in anything much faster than a slow 386. I've still got one in
original shrink wrap as well as one installed in a 5160.
I was afraid of that - Getting a 5160 to network (to get the
images off) is a little painful - I believe I have an 8088 compatible
network client, but all my network cards are 16-bit etc.)
I seem to remember something the DOB having a tie-in
with a group of
Hong Kong investors, and for the life of me, can't seem to recall the
story. It may have been that the DOB was killed off when the HK
people came in because the business of copying protected software was
a little too much of a legal gray area for them.
Rumors are that they bowed to presure from the software makers - I
don't know - I really don't care about copy protection, I just wanted
to see if I could copy some non-IBM format disks.
Be advised that the number of formats that a DOB can
process is
fairly limited. A Catweasel is far more flexible--and programming
information is freely available, as well as being able to run on the
fastest x86 PCI-equipped boxes. At one time, I began accumulating a
pile of notes on DOB operation, but dropped it when the CW came out.
There was no point in continuing the mental abuse.
Yeah, I have to order a cat - The DOB came in with some other material
last year, and I've just gotten around to trying it out. It is
"interesting",
but IMHO fairly useless as an archival tool because it's tied up in
closed formats and proprietary software (at least I've not been able to
find any information on the formats) - That means that the archives can
only last as long as I have access to a working DOB system...
I though the DOB would make a bitwise copy (they call it transition
copy) - with warnings about testing the copy because it can't do CRC
check etc. I assumed it was at a lower level than any actual formatting
and that it could copy "most anything" ....
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:04 p.m.
Dave Dunfield wrote:
I was afraid of that - Getting a 5160 to network (to
get the
images off) is a little painful - I believe I have an 8088 compatible
network client, but all my network cards are 16-bit etc.)
If you have an Intel Etherexpress 8/16 it will work, but you need to set
it up for 8-bit mode whilst in a 16-bit slot first, using the software
that comes with it IIRC. I've heard that most older 3com cards will
work in an 8-bit slot if you put them there, but I haven't tried it.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
6:06 p.m.
On 7 Apr 2007 at 16:04, Jim Leonard wrote:
Dave Dunfield wrote:
I've got a couple of Artisoft AE-2 cards here--they've got a 16-bit
ISA edge connector on them but they'll work just fine on 8 bit ISA
bus. I can't believe they were the only ones that would work that
way.
Cheers,
Chuck
I was afraid of that - Getting a 5160 to network
(to get the
images off) is a little painful - I believe I have an 8088 compatible
network client, but all my network cards are 16-bit etc.)
If you have an Intel Etherexpress 8/16 it will work, but you need to set
it up for 8-bit mode whilst in a 16-bit slot first, using the software
that comes with it IIRC. I've heard that most older 3com cards will
work in an 8-bit slot if you put them there, but I haven't tried it. 
10:09 p.m.
Jim Leonard wrote:
Dave Dunfield wrote:
I have a truly gigantic pile (pile takes up more space than many of my
mainframe CPU's) of 8-bit ethernet NIC's. Are they really that rare?
Peace... Sridhar
I was afraid of that - Getting a 5160 to network
(to get the
images off) is a little painful - I believe I have an 8088 compatible
network client, but all my network cards are 16-bit etc.)
If you have an Intel Etherexpress 8/16 it will work, but you need to set
it up for 8-bit mode whilst in a 16-bit slot first, using the software
that comes with it IIRC. I've heard that most older 3com cards will
work in an 8-bit slot if you put them there, but I haven't tried it.
8 Apr
8 Apr
2:37 p.m.
Sridhar Ayengar wrote:
I have a truly gigantic pile (pile takes up more space
than many of my
mainframe CPU's) of 8-bit ethernet NIC's. Are they really that rare?
Nothing is rare until you need it.
For example, to this day I still don't have a Hercules mono card or
8-bit ISA SCSI card with a boot ROM, and I've got at least 200 pounds of
loose parts. And I've only got one 5153 CGA monitor to my name while
others claim they have them stacked in a corner (!).
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
9 Apr
9 Apr
2:10 p.m.
Sridhar Ayengar wrote:
Indeed...
I have a truly gigantic pile (pile takes up more
space than many of my
mainframe CPU's) of 8-bit ethernet NIC's. Are they really that rare?
Nothing is rare until you need it.
For example, to this day I still don't have a Hercules mono card or
8-bit ISA SCSI card with a boot ROM, and I've got at least 200 pounds of
loose parts. And I've only got one 5153 CGA monitor to my name while
others claim they have them stacked in a corner (!).
I suspect I'm unique in that I have 3 times as many classic PERQs (or if
you like, twice as many HP9100Bs) as Apple //e machines. And I've never
even seen an Apple IIGS
-tony
8 Apr
8 Apr
5:45 p.m.
Sridhar Ayengar wrote:
I have a truly gigantic pile (pile takes up more space
than many of my
mainframe CPU's) of 8-bit ethernet NIC's. Are they really that rare?
They're rare because you have the world's stockpile ;-)
They probably are reasonably uncommon these days, because they've mostly been
chucked out during upgrades (I've found the same problem in trying to locate a
HD 5.25" floppy drive this last week)
cheers
Jules
9 Apr
9 Apr
3:21 p.m.
And thusly were the wise words spake by Sridhar Ayengar
I have a truly gigantic pile (pile takes up more space than many of my
mainframe CPU's) of 8-bit ethernet NIC's. Are they really that rare?
I would hate to be the NIC at the bottom of that pile! %-(
Cheers,
Bryan
7:25 p.m.
--- Bryan Pope <bpope at wordstock.com> wrote:
And thusly were the wise words spake by Sridhar
Ayengar
I would hate to be the NIC at the bottom of that
pile! %-(
Cheers,
Bryan
This reminds me of a firesale I once attended in
Middletown, NY. A local chain in Long Island called
Computer Factory rented out a warehouse and proceeded
to sell off loads and loads of groovy stuff. Tucked in
the back of the place was a huge cardboard box filled
to the brim w/apparently flawed isa cards and whatnot.
To walk by that area was like walking through a ticker
tape parade of copper clad epoxy. At the time I really
couldn't understand what they were getting all excited
over. Scrounging ram chips? I didn't care much though.
I bought my first VGA card for I think $32. I bought a
brand new ram expansion package for the Mac Plus
(still got it) for $10. One lady was looking to tackle
me for it. And I didn't even own a Mac LOL LOL. Most
of the prices were pretty reasonable, but the brand
new MS Fortran package, sealed, 10.0 IIRC, was going
for either $100 or $200, and I said no way.
I was real real sorry I had missed an earlier sale
somewhere in Nassau or Queens. Brand new in the box
Lisas were going for $200. This was in 1990. I'm
curious what those who did purchase them up intend to
so with them.
____________________________________________________________________________________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/
I have a truly gigantic pile (pile takes up more
space than many of my
mainframe CPU's) of 8-bit ethernet NIC's.
Are
they really that rare?
8 Apr
8 Apr
8:12 a.m.
I was afraid
of that - Getting a 5160 to network (to get the
images off) is a little painful - I believe I have an 8088 compatible
network client, but all my network cards are 16-bit etc.)
If you have an Intel Etherexpress 8/16 it will work, but you need to set
it up for 8-bit mode whilst in a 16-bit slot first, using the software
that comes with it IIRC. I've heard that most older 3com cards will
work in an 8-bit slot if you put them there, but I haven't tried it.
2:45 p.m.
Dave Dunfield wrote:
ones, find the docs and/or configuration utility, finf
the 8-bit client
No client needed unless you want to screw with netware or samba... That
is so much of a hassle that I just use the packet driver with NCSA
telnet, which contains an FTP server and I just FTP stuff on/off the
machine that way. It also takes a script, so that's how I back up the
machine (batch file creates an archive, then that archive is FTP'd up to
my server).
Don't expect blazing speeds though. 30KB/s is a reasonable target for
an 808x machine.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
7 Apr
7 Apr
5:42 p.m.
Dave Dunfield wrote:
You can doubtless find one closer to home, but *somewhere* I have an 8-bit
Ethernet card [1] pulled from an XT clone (and I stumbled across the boot
floppy with the network stack on it the other day - no idea if it's still
readable of course!). I can go digging for it if needs be...
[1] memory says it was a 3Com board, but memory also says it was full-length -
and I don't think that computes (looking at google, the majority of 3Com ISA
boards are short and 16-bit)
But neither
will
run in anything much faster than a slow 386. I've still got one in
original shrink wrap as well as one installed in a 5160.
I was afraid of that - Getting a 5160 to network (to get the
images off) is a little painful - I believe I have an 8088 compatible
network client, but all my network cards are 16-bit etc.) Yeah, I have to order a cat
<aol>
me too
</aol>
I'm still concerned about what documentation and resources there are out there
for the cat though - I mean quite a few must have been sold, and owners must
have thrown together quite a bit of code to drive them - but every time I've
dug around on the 'net it's been unclear as to what kind of user community
exists to actively share code and experiences.
(Plus I really don't want to be driving the thing under a heavyweight OS like
Windows - and God knows what the resources and docs are available for the
alternatives)
I don't mind hacking code together if I have to - but I really don't want to
be hacking the same code together that every other single owner has also had
to hack together; that's just a waste... :-)
cheers
J.
10:43 p.m.
Jules Richardson wrote:
...
I'm still concerned about what documentation and
resources there are out
there for the cat though - I mean quite a few must have been sold, and
owners must have thrown together quite a bit of code to drive them - but
every time I've dug around on the 'net it's been unclear as to what kind
of user community exists to actively share code and experiences.
(Plus I really don't want to be driving the thing under a heavyweight OS
like Windows - and God knows what the resources and docs are available
for the alternatives)
Join the following yahoo group: Catweasel-Dev at yahoogroups.com
Jens Shoenfeld, the creator of the catweasel is active there, along with
various people of varying degrees of involvement.
I've written code to read (not write) PTDOS disks, and another to do
hard sectored Wang disks (again read, not write). The code isn't
pretty, but it worked well enough for my purposes. In both cases the
code ran on a win98 box. There is a win32 driver for the catweasel, so
it is possible to write code on a new machine, but I found it easy
enough to poke the hardware directly. Most of the low level code was
stolen from Tim Mann's trs80 disk read/write tool. The driver used to
have a specific list of formats that it decoded, in the driver, but
recently the author changed things to expose the low level read/write
track commands at driver level, and then leave the format decoding to a
user mode program (which is how it should have been all along, for my
purposes).
8 Apr
8 Apr
10:30 a.m.
Jim Battle wrote:
Jules Richardson wrote:
...
Aha - I will try that, thanks.
I'm still concerned about what documentation
and resources there are
out there for the cat though - I mean quite a few must have been sold,
and owners must have thrown together quite a bit of code to drive them
- but every time I've dug around on the 'net it's been unclear as to
what kind of user community exists to actively share code and
experiences.
(Plus I really don't want to be driving the thing under a heavyweight
OS like Windows - and God knows what the resources and docs are
available for the alternatives)
Join the following yahoo group: Catweasel-Dev at yahoogroups.com
Jens Shoenfeld, the creator of the catweasel is active there, along with
various people of varying degrees of involvement. I've written code to read (not write) PTDOS disks,
and another to do
hard sectored Wang disks (again read, not write).
Writing would be nice - but I'm more concerned about preserving media before
it dies than anything; being able to recreate it can take a back seat if it
has to!
recently the author changed things to expose the low
level read/write
track commands at driver level, and then leave the format decoding to a
user mode program (which is how it should have been all along, for my
purposes).
That seems the sensible way to do it to me too; operate at the track level
when talking to the low-level driver, with all the serious decoding / encoding
done within a user-space app.
cheers
Jules
9 Apr
9 Apr
7:14 a.m.
Jim Battle wrote:
Jules Richardson wrote:
...
Granted that I suck at web forums, but the Yahoo! I subscribe to
claims no such group. The "catweasel" group shows that its last post
was in 2000.
Doc
I'm still concerned about what documentation
and resources there are
out there for the cat though - I mean quite a few must have been sold,
and owners must have thrown together quite a bit of code to drive them
- but every time I've dug around on the 'net it's been unclear as to
what kind of user community exists to actively share code and
experiences.
(Plus I really don't want to be driving the thing under a heavyweight
OS like Windows - and God knows what the resources and docs are
available for the alternatives)
Join the following yahoo group: Catweasel-Dev at yahoogroups.com
10:32 a.m.
New subject: catweasel resources, and other thoughts
Doc Shipley wrote:
Jim Battle wrote:
That is weird -- I definitely get emails from the above address, but
like you, if I entry "catweasel-dev" on yahoo groups, nothing comes up.
I wonder how that can be. Is it possible that there are "private
groups" that don't show up?
I'm sure there are other online resources, but here are a few (including
code for many of them):
Tim Mann's TRS80 catweasel tools:
http://www.tim-mann.org/catweasel.html
Linux drivers:
http://www.soundtracker.org/raw/cwfloppy/index.html
Official english MK3 documentation:
http://www.schoenfeld.de/inside/Inside_CWMK3.txt
Official english MK4 documentation:
http://siliconsonic.de/t/CWMK4_english.pdf
More linux stuff:
http://unusedino.de/cw/
My program (with source) for reading PTDOS disks:
http://www.sol20.org/ptdos.html#catweasel
Jay Jaeger took bits of my code and wrote a program to read DG 6030 hard
sectored disks:
http://webpages.charter.net/thecomputercollection/hardsec_cw.tar.gz
On the one hand I've heard the complaint that there is no centralized
"official" code base, but then I've also heard: I don't borrow code and
would write it myself. Both are fine opinions to have, but not at the
same time by an individual person. :-)
Manipulating the card is really pretty simple (using an unprotected OS
like DOS or Win98), so don't be put off by confusion over drivers. You
don't need one. Just poke the registers and collect the data. The only
tricky part is the code that *you* have to write for your particular
disk format to make sense of the data.
Jules had mentioned worries about the transition counter overflowing.
The counters are 8b (7b if you want to capture the state of the index
sensor at each sample). You get to select a sampling rate (14, 28, or
56 MHz). At the lower sampling rate, a transition would have to be
greater than 18 uS before the counter saturated -- pretty darn slow.
But you are right, if media existed with a bit rate under this, you
couldn't capture it exactly.
Jules Richardson wrote:
...
Granted that I suck at web forums, but the Yahoo! I subscribe to
claims no such group. The "catweasel" group shows that its last post
was in 2000. I'm still concerned about what documentation
and resources there are
out there for the cat though - I mean quite a few must have been
sold, and owners must have thrown together quite a bit of code to
drive them - but every time I've dug around on the 'net it's been
unclear as to what kind of user community exists to actively share
code and experiences.
(Plus I really don't want to be driving the thing under a heavyweight
OS like Windows - and God knows what the resources and docs are
available for the alternatives)
Join the following yahoo group: Catweasel-Dev at yahoogroups.com 
7 Apr
7 Apr
11:51 p.m.
On 4/7/07, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
[1] memory says it was a 3Com board, but memory also
says it was full-length -
and I don't think that computes (looking at google, the majority of 3Com ISA
boards are short and 16-bit)
Probably a 3c501.
-ethan
8 Apr
8 Apr
8:23 a.m.
I'm still concerned about what documentation and
resources there are out there
for the cat though - I mean quite a few must have been sold, and owners must
have thrown together quite a bit of code to drive them - but every time I've
dug around on the 'net it's been unclear as to what kind of user community
exists to actively share code and experiences.
Yeah - I've noticed that too. And a lot of what I have found seems incomplete..
Just enough to read this one particular format etc...
(Plus I really don't want to be driving the thing
under a heavyweight OS like
Windows - and God knows what the resources and docs are available for the
alternatives)
Main reason I haven't gotten one yet. PCI card with winblows drivers...
Soon as you have to go into that "complexity for the sake of complexity"
environment, things go a LOT slower - and I just don't have time (or
desire) to deal with it.
I don't mind hacking code together if I have to -
but I really don't want to
be hacking the same code together that every other single owner has also had
to hack together; that's just a waste... :-)
Agreed - I'm surprised someone hasn't put together a good "image/restore
anything" package for it ... Or is such a beast available? I admit I have not
looked all that hard yet...
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
10:26 a.m.
Dave Dunfield wrote:
Yep. Whenever I've dug around on the 'net there seems to be lots of "friend
of
a friend did this" type info, but very little first-hand. It worried me to be
honest, because it gives the impression that people buy the cards and can't
get them to work properly.
I hear ya. I don't recall there being much in the way of online documentation
for the card at all from the people who make the thing; again, it doesn't give
a lot of confidence. My only reason for getting one is that there isn't
currently an alternative.
<cynical>
You'll probably find that a friend of a friend of a friend wrote one once, but
they didn't document it, didn't release it into the public domain, and it
never worked right anyway :-)
</cynical>
That may be unfair, but that's what the level of user community surrounding
the thing feels like.
I'm still
concerned about what documentation and resources there are out there
for the cat though - I mean quite a few must have been sold, and owners must
have thrown together quite a bit of code to drive them - but every time I've
dug around on the 'net it's been unclear as to what kind of user community
exists to actively share code and experiences.
Yeah - I've noticed that too. And a lot of what I have found seems incomplete..
Just enough to read this one particular format etc... (Plus I really
don't want to be driving the thing under a heavyweight OS like
Windows - and God knows what the resources and docs are available for the
alternatives)
Main reason I haven't gotten one yet. PCI card with winblows drivers...
Soon as you have to go into that "complexity for the sake of complexity"
environment, things go a LOT slower - and I just don't have time (or
desire) to deal with it. I don't
mind hacking code together if I have to - but I really don't want to
be hacking the same code together that every other single owner has also had
to hack together; that's just a waste... :-)
Agreed - I'm surprised someone hasn't put together a good "image/restore
anything" package for it ... Or is such a beast available? I admit I have not
looked all that hard yet...
10:33 a.m.
New subject: catweasel (was: ImageDisk update)
Dave Dunfield wrote in response to Jules Richardson (I think):
...
You aren't forced to use the drivers; you can do direct register level
access under windows98, or 95, or dos. The driver is needed only under
xp because of the need to do hardware level access.
(Plus I really
don't want to be driving the thing under a heavyweight OS like
Windows - and God knows what the resources and docs are available for the
alternatives)
Main reason I haven't gotten one yet. PCI card with winblows drivers...
Soon as you have to go into that "complexity for the sake of complexity"
environment, things go a LOT slower - and I just don't have time (or
desire) to deal with it.
3:05 p.m.
On 8 Apr 2007 at 7:23, Dave Dunfield wrote:
Main reason I haven't gotten one yet. PCI card
with winblows drivers...
Soon as you have to go into that "complexity for the sake of complexity"
environment, things go a LOT slower - and I just don't have time (or
desire) to deal with it.
PCI with the Catweasel doesn't imply Windows or any other high-level
OS. Using the PCI BIOS PNP services under real-mode MS-DOS to
identify the I/O ports is quite simple and gives you freedom from
worrying about configuration switches. I have both ISA and PCI
catweasels and find no real difference in the difficulty of
programming them (although there are differences in the way the ports
are defined).
Additionally, you CAN write your own 32 bit real mode code (DJGPP)
using a DPMI server. Given that the track buffer on a CW is about
(IIRC) 128K, this actually makes a lot of sense, when you're sucking
in a track and working with it.
I mean, what else are you going to do with half a gig of memory--
run Windows? ;-)
Cheers,
Chuck
5:24 p.m.
Chuck Guzis wrote:
On 8 Apr 2007 at 7:23, Dave Dunfield wrote:
No - but when I last trawled the web for info on the CW (about a year ago) I
was getting the impression that what little "officially sanctioned"
documentation and example code there was out there was squarely aimed at Windows.
I'm not sure what work users have done with the board under DOS. I know I saw
rumour of a Linux kernel driver - but for what board revision / firmware I
don't know. It's a shame these sorts of things aren't (apparently) fed back
into the main site for the board (<fx: checks> actually, the "main site"
seems
to read more like something pulled up via the Wayback machine rather than a
site for a current product!)
"The Catweasel MK4 will be available starting october 2004." <-- I assume
that
actually happened? Or did it die a death and the (no longer available,
according to the front page of the website) MK3 board is the current product?
Jim's comment about register level access is interesting - question to you
both: how well-documented is this method of controlling the board?
Main reason I haven't gotten one yet. PCI
card with winblows drivers...
Soon as you have to go into that "complexity for the sake of complexity"
environment, things go a LOT slower - and I just don't have time (or
desire) to deal with it.
PCI with the Catweasel doesn't imply Windows or any other high-level
OS. I mean, what else are you going to do with half a gig
of memory--
run Windows? ;-)
Run a thousand or so emulated Sinclair Spectrums, virtually network them
together, then take over the world? :-)
cheers
Jules
7:17 p.m.
On 8 Apr 2007 at 16:24, Jules Richardson wrote:
No - but when I last trawled the web for info on the
CW (about a year ago) I
was getting the impression that what little "officially sanctioned"
documentation and example code there was out there was squarely aimed at Windows.
There is definitely a register-level description and source code for
the MK3 out there that shows how to get the PCI resource values from
the BIOS. There's also a bunch of source code for the MK I.
Myself, I use my own code to drive the cards; I've never needed code
from others.
The interface to the card is brutally simple--unless the MK4 has
added some additional stuff. You step the drive by setting the
direction and pulsing the step line. None of this fancy stuff where
the CW actually remembers the current cylinder number. About the
only thing the CW will do for you is wait and collect data when the
the index pulse goes active--and then will stop when the index pulse
goes active again. There's a 128K SRAM that holds the data until
you're ready to read it back via programmed I/O.
The index feature may not be of particular value for some diskettes--
I've got some formats here that don't use the index for anything--
they just start formatting wherever the disk happens to be in its
rotation.
Generally, I'll collect data under DOS real mode (although Win 9x
works okay) and then digest it with a 32-bit program.
The data from the catweasel is basically a series of counts between
pulses. It's a bit difficult looking at a data stream from the CW
and figuring out what you're looking at. I've got a little Windows
utility that takes any track and plots the data on a time axis,
changing from 1 to 0 with every pulse. The graphical representation
really helps to figure things out, particularly when dealing with
someone's idea of GCR.
Cheers,
Chuck
9 Apr
9 Apr
4:17 a.m.
Chuck Guzis wrote:
On 8 Apr 2007 at 16:24, Jules Richardson wrote:
Hmm, so maybe the trick is to find someone selling an old MK3 board, rather
than the MK4...
No - but when I last trawled the web for info on
the CW (about a year ago) I
was getting the impression that what little "officially sanctioned"
documentation and example code there was out there was squarely aimed at Windows.
There is definitely a register-level description and source code for
the MK3 out there that shows how to get the PCI resource values from
the BIOS. Myself, I use my own code to drive the cards; I've
never needed code
from others.
I must admit I tend to write my own code for things like this - but I like to
be able to see what others have done just to avoid any gotchas which might
otherwise slow progress - hence it's useful to have a repository somewhere.
The data from the catweasel is basically a series of
counts between
pulses.
Hmm, that's interesting. Does it store fixed length counts in the buffer, or
does it use variable-length counts with a couple of bits of "header" to say
how many bits the count takes up?
Either way, it got me wondering if there's some really oddball stuff that the
CW can't read because the count between pulses is just too long. It's too
early here to reason it out :-)
It's a bit difficult looking at a data stream
from the CW
and figuring out what you're looking at. I've got a little Windows
utility that takes any track and plots the data on a time axis,
changing from 1 to 0 with every pulse. The graphical representation
really helps to figure things out, particularly when dealing with
someone's idea of GCR.
I was thinking the same thing with this concept of over-sampling the entire
track into a buffer; it's going to be a heck of a lot easier to decode the
data while looking at a graphical utility.
cheers
Jules
11:15 a.m.
Jules Richardson wrote:
Hmm, that's interesting. Does it store fixed
length counts in the
buffer, or does it use variable-length counts with a couple of bits of
"header" to say how many bits the count takes up?
Here's the document that explains how the CW is programmed:
<http://www.schoenfeld.de/inside/Inside_CWMK3.txt>
AIUI, it goes something like this (with Counter=0 to start):
- Wait for transition
- Store contents of Counter in memory, MemAddr++, Counter=0
- Repeat until all the data has been read
Counter is incremented at the master clock rate -- 14, 28 or 56MHz (well,
actually 56.644MHz). Basically, what the Catweasel tells you is how much time
there was between the last flux transition and the current transition. From
that, you can regenerate the waveform, or do some (relatively) simple data
processing to get the original data back.
Either way, it got me wondering if there's some
really oddball stuff
that the CW can't read because the count between pulses is just too
long. It's too early here to reason it out :-)
The easy answer is to slow the clock down so the counter doesn't overflow :)
I was thinking the same thing with this concept of
over-sampling the
entire track into a buffer; it's going to be a heck of a lot easier to
decode the data while looking at a graphical utility.
I'm sketching out the UI for my drive reader at the moment. It'll probably have:
- A 'logic' display that shows the index pulse and data.
- A histogram display that shows where the timing values lie (may be useful
for giving encoding types a 'signature' and identifying them based on that)
- Standard read/write panel, track navigation, etc.
Maybe I'm getting a bit ahead of myself, seeing as the hardware isn't even
half done yet...
--
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:28 p.m.
On 9 Apr 2007 at 3:17, Jules Richardson wrote:
Hmm, so maybe the trick is to find someone selling an
old MK3 board, rather
than the MK4...
Is the MK4 real? It's not clear from Jens' web site. If it is, I'll
probably buy one.
Hmm, that's interesting. Does it store fixed
length counts in the buffer, or
does it use variable-length counts with a couple of bits of "header" to say
how many bits the count takes up?
Each count takes up 7 bits of an 8-bit byte. The high-order bit
records the presence of an index pulse (essential for decoding hard-
sectored formats). He gets around the fixed-width issue by having
several (3, IIRC) programmable clock speeds. As I said, brutally
simple.
One thing that I've found to be useful is the construction of a
"buffer board"; i.e., some high-current OC drivers and schmitt
receivers that feed from an DC-37 external drive connector to the
MK3. I've found that the bare MK3 driving long cables on "heirloom"
drives don't seem to have the 'oomph" to get the job done.
I was thinking the same thing with this concept of
over-sampling the entire
track into a buffer; it's going to be a heck of a lot easier to decode the
data while looking at a graphical utility.
One thing that's useful is a histogram of a track. FM will show two
peaks; MFM, three. GCR usually shows more than three. Unformatted
tracks show very broad distributions.
GCR can be very challenging. You have an idea of the way it works
and what the "prohibited" bit combinations probably are, but you
still don't have your mappings. I've taken several tracks and, based
on a suspicion that each sector probably contained some sort of
header information that included a cylinder number, have worked from
that.
I've still got a couple of GCR formats that I haven't cracked yet,
though. The process of decoding a new format that isn't FM or MFM is
usually one of staring at the data for a couple of hours and then not
thinking about it for a week or two. Eventually, there will be an
"Aha!" that usually comes sometime around bedtime. :-)
Cheers,
Chuck
6:41 p.m.
On 9 Apr 2007 at 3:17, Jules Richardson wrote:
I don't know if this is at all relevant (and really
don't care besides LOL), but I have an apparently
early CopyII board that has all discrete logic. If I
was presumed upon nicely enough, I could unearth it
and post pictures and whatnot. On second thought...NAH
LOL LOL.
Fred says it won't do GCR, so I guess it's value
relative to later boards is minimal.
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
Hmm, so maybe the trick is to find someone
selling
an old MK3 board, rather
> than the MK4... 
9:34 p.m.
On Mon, 9 Apr 2007, Chris M wrote:
early CopyII board that has all discrete logic. If I
. . .
Fred says it won't do GCR, so I guess it's value
relative to later boards is minimal.
IF you mean me,
the early OB would certainly do GCR, but it could not handle some of the
data rates for Mac disks. That was one of the design goals for the
"Deluxe" OB.
My experience was that both were flaky for high density (500kbps)
I used them in XTs, both OEM and generic, and in almost OEM ATs.
Never had any success with faster machines than that.
Because the software was overly reliant on the index pulse, it couldn't do
the back side of a ][ "flippy", nor hard sectored.
So, one day we made up a copy protection system that it could not handle,
although DISKCOPY would.
--
Grumpy Ol' Fred cisin at xenosoft.com
10:18 p.m.
On 9 Apr 2007 at 18:34, Fred Cisin wrote:
Because the software was overly reliant on the index
pulse, it couldn't do
the back side of a ][ "flippy", nor hard sectored.
So, one day we made up a copy protection system that it could not handle,
although DISKCOPY would.
It could handle "half-tracked" ][ diskettes?
Cheers,
Chuck
11:07 p.m.
> Because the software was overly reliant on the
index pulse, it couldn't do
> the back side of a ][ "flippy", nor hard sectored.
> So, one day we made up a copy protection system that it could not handle,
> although DISKCOPY would.
On Mon, 9 Apr 2007, Chuck Guzis wrote:
It could handle "half-tracked" ][ diskettes?
I doubt it; the supplied software did not know many tricks
But, it also could not handle a perfectly "normal" 360K PC diskette that
happened to not have an index hole.
10 Apr
10 Apr
1:07 a.m.
Fred Cisin wrote:
Because the software was overly reliant on the index
pulse, it couldn't do
the back side of a ][ "flippy", nor hard sectored.
Confused; the software has an option that lets you ignore syncing to the
index hole. Maybe you tested with a very early version of the software.
Also, since stock IBM hardware/OS needs the index hole, I fail to see
how DISKCOPY could copy such a beast.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
1:31 a.m.
New subject: Data General CEO files...
Anyone know of any PC platform based util to import/convert DG CEO files
to make them readable on a PC???
Portions of the CEO files are clear text and some even have partial
formatting, but the majority (about 80%) is what I assume is formatting
codes and unformatted text.
Thanks,
Curt
3:05 p.m.
> Because the software was overly reliant on the
index pulse, it couldn't do
> the back side of a ][ "flippy", nor hard sectored.
On Tue, 10 Apr 2007, Jim Leonard wrote:
Confused; the software has an option that lets you
ignore syncing to the
index hole. Maybe you tested with a very early version of the software.
I'm glad that they added that feature later.
Also, since stock IBM hardware/OS needs the index
hole, I fail to see
how DISKCOPY could copy such a beast.
Only FORMAT needs the index hole. DISKCOPY onto an already formatted disk
does not.
But, some drives, including some Teacs need the index to determine drive
ready. One more reason to stick with the TM100-2.
1:05 a.m.
Chris M wrote:
Yes, I have one too. So there are four revs, but the first two are the
OB, the third with the single "transcopy" IC is the DOB, and the
mid-length board with the switch on the back is the Enhanced OB (the
switch is to facilitate laser-hole disks).
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
On 9 Apr 2007
at 3:17, Jules Richardson wrote:
I don't know if this is at all relevant (and really
don't care besides LOL), but I have an apparently
early CopyII board that has all discrete logic. If I Hmm, so maybe the trick is to find someone
selling
an old MK3 board, rather
> than the MK4... 
9 Apr
9 Apr
8:17 p.m.
On Monday 09 April 2007 10:28, Chuck Guzis wrote:
On 9 Apr 2007 at 3:17, Jules Richardson wrote:
I bought my MK4 a few months ago from SoftwareHut. They have them in their
current online catalog below:
http://www.softhut.com/cgi-bin/test/Web_store/web_store.cgi?page=catalog/ha…
SoftwareHut also carries older Cat Weasels and other controllers:
http://www.softhut.com/cgi-bin/test/Web_store/web_store.cgi?page=catalog/ha…
Regards,
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"
Hmm, so maybe the trick is to find someone
selling an old MK3 board,
rather than the MK4...
Is the MK4 real? It's not clear from Jens' web site. If it is, I'll
probably buy one.
10 Apr
10 Apr
4:44 a.m.
Chuck Guzis wrote:
[catweasel]
The more I think about it, the more I like the idea of recording timings
between pulses, rather than oversampling the entire track - the former seems
the only way of recording exactly what's coming off the disk. I think I'm
still aiming for a sampled approach at first, but I can see a project that
records transition times waiting in the wings.
I need to run some calculations to see what values I get for both the shortest
time between flux transitions (according to bit density of the media) and the
longest time (assuming slowest floppy rotational speed and track with just a
single bit on it).
If the numbers work out, then I wonder if an improved format would be to have
variable-length counts: say three bits of "header", with the first bit
recording presence/absence of index pulse (vital, as you say), then two bits
which state how many bits make up the count value. That gives four possible
lengths of count which could be encoded....
From there I can figure out the maximum buffer memory needed. gut feeling is
that it should all fit within 512KB though, given the CW's 128KB and three
clock speeds.
Use of three different clocks as with the CW bugs me. I think I want the data
that comes out of the device to reflect exactly what's coming out of the drive
interface, no questions asked - and no need to check and tweak any parameters
without resampling.
Hmm,
that's interesting. Does it store fixed length counts in the buffer, or
does it use variable-length counts with a couple of bits of "header" to say
how many bits the count takes up?
Each count takes up 7 bits of an 8-bit byte. The high-order bit
records the presence of an index pulse (essential for decoding hard-
sectored formats). He gets around the fixed-width issue by having
several (3, IIRC) programmable clock speeds. As I said, brutally
simple. GCR can be very challenging. You have an idea of the
way it works
and what the "prohibited" bit combinations probably are, but you
still don't have your mappings. I've taken several tracks and, based
on a suspicion that each sector probably contained some sort of
header information that included a cylinder number, have worked from
that.
Where are you typically finding such formats - other than the well-known
machines that used GCR? Is it more common in some of the factory process
control stuff etc. that you look at, rather than home/business systems?
Eventually, there will be an "Aha!" that
usually comes sometime around
bedtime. :-)
I usually get mine when waking up - and if I don't scribble them down
somewhere immediately then they're gone by the time of the first coffee :-)
cheers
Jules
12:47 p.m.
On 10 Apr 2007 at 3:44, Jules Richardson wrote:
If the numbers work out, then I wonder if an improved
format would be to have
variable-length counts: say three bits of "header", with the first bit
recording presence/absence of index pulse (vital, as you say), then two bits
which state how many bits make up the count value. That gives four possible
lengths of count which could be encoded....
I don't think that would be profitable. Consider MFM recording--you
have pulses that can occur at N, 1.5N and 2N, and for address marks
with missing clocks 2.5N intervals. Given the right clock selection,
there's no real need for a lot of precision. Consider that most
data separator circuits can tolerate about a 20 (+/- 10) percent
variation in speed quite easily. A floppy drive is not a precision
device, in my experience.
Part of data recovery is relying on the categorization of recording
methods. So, for instance if, on an MFM diskette, you find a pulse
that occurs less than about 3N/4, you're safe discarding it.
Similarly, if you find a gap of 4N, you probably should assume a
pulse is missing. And this is really where the "gold" is. You can
be a lot smarter with software than a "dumb" data separator can be
when it comes to figuring out how to recover from an error.
Where are you typically finding such formats - other
than the well-known
machines that used GCR? Is it more common in some of the factory process
control stuff etc. that you look at, rather than home/business systems?
Some older word processors use it and you can find it on some early
personal/business computers as well as some industrial equiopment
(e.g. Future Data development systems).
Cheers,
Chuck
8 Apr
8 Apr
4:55 a.m.
BTW I have a DOB in a box stored somewhere. I'm open to reasonable
offers if someone is willing to get it.
Thanks
Alexandre Souza
2:41 p.m.
Alexandre Souza wrote:
BTW I have a DOB in a box stored somewhere. I'm open to reasonable
offers if someone is willing to get it.
I think now is a good time to mention that I've seen some confusion here
regarding OB models. There were three option boards. The first was a
more complex card and looked like this:
http://retro.icequake.net/dob/img/ob-box-1.jpg
The second was mostly a single IC (the "deluxe" option board) and looked
like this:
http://retro.icequake.net/dob/img/dob1.png
Finally, there was a third "enhanced" board with support for disks with
laser holes in them, looking like this:
http://retro.icequake.net/dob/img/eob.jpg
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
9 Apr
9 Apr
6:20 a.m.
BTW I have
a DOB in a box stored somewhere. I'm open to reasonable
offers if someone is willing to get it.
I think now is a good time to mention that
I've seen some confusion here
regarding OB models. There were three option boards. The first was a
http://retro.icequake.net/dob/img/dob1.png
7 Apr
7 Apr
3:55 p.m.
The Option Board was, IIRC, completely software-driven
and extremely
susceptible to machine speed (and sometimes even interrupt noise, which
is why they made TCS.EXE which doesn't use EMS and might disable some
hardware interrupts as well). The fastest machine I could get it to
work in reliably was an AMD 386-40, with the ISA bus speed at either
clock/5 (8MHz) or locked at a timer clock integral divider (ie.
7.16MHz). If memory serves, I had the best results at 7.16MHz.
Currently I keep mine in my 5160.
I have the bus set to 7.16 Mhz, all the wait states I can get turned on,
cache turned off etc - but I think the 486 is still too fast for it.
Slower. Look for ICD.COM (and companion ICE.COM)
which disable the
internal cache. I believe you can find a copy of them here:
http://www.oldskool.org/guides/oldonnew/resources/icdice.zip
Also, add wait states if possible. Fix bus speed at or close to ISA
standard (see above).
Sad thing is I don't have any 386s or AT any more (Actually I have a
Compaq portable III, but that a bit tough to screw around with - I
might try it in a 5160 - that should be slow enough :-)
I heard through the grapevine that, sadly, the creator
of the Option
Board (everything, hardware to software) passed away in the mid 1990s,
so there is no official resource to ask about the OB. But it was always
one of my favorite peripherals, and just watching it try to match track
length while copying gave me some insight into FDC operation (and
protection methods!)
In my case, the board would take FOREVER to match the track length - another
clue that it's having timing problems - Often several minites/track - I had
to open it up to get it to work at a reasonable speed. As noted previously,
I was just trying to copy a generic 360K dos disk. Just trying to see if the
board workd.
I used to have programming information on the OB; I
don't know where it
is but I can try to dig it up if you think you'd find it useful. Also,
I'm assuming you've seen the treasure trove of info over at
http://retro.icequake.net/dob/ ?
Yes I did thanks - I believe thats where I got the newer software version.
Is there any detailed information available on the DOB (I understand the
OB and the DOB are different)?
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:07 p.m.
Dave Dunfield wrote:
With wait states and cache turned off (INTERNAL cache, not L2, see the
ICD.COM util I mentioned earlier) my 486 is slower than my 5150. So you
probably missed the internal cache step.
Yes, very astute. If it's taking minutes per track to match track
length, then you muck with the computer and/or move the board to a
different machine.
The Option
Board was, IIRC, completely software-driven and extremely
susceptible to machine speed (and sometimes even interrupt noise, which
is why they made TCS.EXE which doesn't use EMS and might disable some
hardware interrupts as well). The fastest machine I could get it to
work in reliably was an AMD 386-40, with the ISA bus speed at either
clock/5 (8MHz) or locked at a timer clock integral divider (ie.
7.16MHz). If memory serves, I had the best results at 7.16MHz.
Currently I keep mine in my 5160.
I have the bus set to 7.16 Mhz, all the wait states I can get turned on,
cache turned off etc - but I think the 486 is still too fast for it. I heard
through the grapevine that, sadly, the creator of the Option
Board (everything, hardware to software) passed away in the mid 1990s,
so there is no official resource to ask about the OB. But it was always
one of my favorite peripherals, and just watching it try to match track
length while copying gave me some insight into FDC operation (and
protection methods!)
In my case, the board would take FOREVER to match the track length - another
clue that it's having timing problems - Often several minites/track - I had
Yes I did thanks - I believe thats where I got the newer software version.
Is there any detailed information available on the DOB (I understand the
OB and the DOB are different)?
They are, but all the info I have I've contributed to the aforementioned
site, and it was only OB info.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
8 Apr
8 Apr
8:15 a.m.
With wait states and cache turned off (INTERNAL cache,
not L2, see the
ICD.COM util I mentioned earlier) my 486 is slower than my 5150. So you
probably missed the internal cache step.
Shouldn't be slower - it's clocked faster and it's a 32 bit bus instead of
8 ...
The BIOS on this machine has an option for disabling both the L2 and internal
caches, but I'm guessing that the one for internal doesn't work - It has
no discernable effect and I would have expected much more than that - I'll
check ou your ICD program.
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
6298
days inactive
6302
days old
45 comments
16 participants
participants (16)
-
alexandre-listas＠e-secure.com.br -
ard＠p850ug1.demon.co.uk -
bpope＠wordstock.com -
cclist＠sydex.com -
chrism3667＠yahoo.com -
cisin＠xenosoft.com -
classiccmp＠philpem.me.uk -
curt＠atarimuseum.com -
dave06a＠dunfield.com -
doc＠mdrconsult.com -
ethan.dicks＠gmail.com -
frustum＠pacbell.net -
julesrichardsonuk＠yahoo.co.uk -
lbickley＠bickleywest.com -
ploopster＠gmail.com -
trixter＠oldskool.org