> From: Jules Richardson <jules.richardson99 at gmail.com>
> Hmm, I thought I read once that you could throw pretty much anything you
> wanted at a ST506 drive so long as it was within the various tolerances -
> is that not true of ST412-type drives?
While that may be true in theory, I'm going to guesstimate that 99
and 44/100 percent of the applications of the ST506/412 out there
used either MFM, MMFM (maybe) or 2,7 RLL for recording. While anyone
could throw together a bunch of TTL chips to record any old way on a
floppy (and did), implementing a hard disk controller with random
logic wasn't a simple matter and almost all manufacturers, by the
time of the ST506 used commodity solutions.
That's not to say that there aren't any bizarre recording schemes out
there for ST506s; just that I've never run into one.
For example, I've got a few mutually incompatible 2,7 RLL PC-AT style
controllers, but they differ more in logical details (address marks,
header layout, ECC codes) than they do in modulation methods or clock
rate. While it may have been possible to, say, employ FM recording
on a ST412, I've never seen it done in practice. There *were* some
RLL variants that attempted to push things past 2,7 (Perstor?) on a
412 interface, but they were never very reliable or popular.
Did any application of a 506 even use zoned recording (i.e. using a
faster data clock on the outer cylinders)?
Cheers,
Chuck
I have never gotten it to work. I have tried a couple times
over some reasonable long (month?) time and it always says no
matches found. Is it just me?
http://www.classiccmp.org/pipermail/cctalk/
No matches were found for '(digital or digitally)'
Dear Bruce,
I have a Cushman 6-A service monitor. The 5 MHZ crystal oven assembly has
died. Do you have a source for the 10 MHZ crystal and how did you provide
both the TTL and sine 5 MHZ for the Cushman instrument.
I am retired and I would like to keep the 6-A working without spending a lot
f dollars.
Thanks for your help!!
Ron Raspet N3JLF
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.13/1208 - Release Date: 1/3/2008
3:52 PM
ggs said:
> Folks, there was *no* OS/2 for anything other than the x86 and the PPC.
Awww, injecting REALITY into typical classiccmp nonsense.
Also, there was NO NT for the 68K, as it REQUIRES little-endian support in
the CPU.
> Date: Wed, 02 Jan 2008 14:28:23 -0600
> From: Jules Richardson <jules.richardson99 at gmail.com>
> Andrew Lynch wrote:
> > Hi,
> > Just out of curiosity, is there a technique or device which can do raw
> > reads of tracks on ST506/ST412 style hard disk drives similar to how a
> > Catweasel can with a floppy disk drive?
>
> To the best of my knowledge, no - and I've been keeping an ear to the
> ground for such things for a while (plus it's a discussion which crops up
> here every once in a while, but I don't believe anyone's produced any
> working hardware yet).
>
> The speeds involved (particularly if over-sampling the data) are
> reasonably high - enough that it'd be tricky[1] to throw something
> together out of OTS TTL parts. That puts such a project more within the
> realm of people who know all about interfacing to high speed
> microcontrollers, and the pool of available carbon units with the time,
> skills and inclination to make such a device is pretty darn small.
I'll assume that we're talking about (surviving--and that's a real
gotcha) ST506/ST412 interface drives here. Why would a Catweasel-
type interface (i.e. pulse time sampling) be even desirable? All the
drives used to store digital data that I'm aware of were recorded as
MFM, M2FM or some flavor of RLL (2,7 probably being the most common).
Controllers differ in small details such as address marks which
renders them mutually incompatible, but the data stream has far less
variation in encoding than the floppy world.
Just give me a programmable data separator and a way to capture that
output--I'll figure out what the bits mean.
The rated speeds of old ST412-type drives were pretty modest; about
5MHz for MFM and 7.5MHz for RLL, IIRC.
Cheers,
Chuck
Hi Guys,
I've just posted an updated PC100 to my site - excepting for bug fixes
(please send reports), this should be the last version for a while, as
it has reached the point where it does everything I need (and more).
Updates in this version:
- Implemented slow-scroll as a substitute for smooth-scroll
- Improved key mapping function so you can more easily see the
existing mappings.
- Added a BREAK key (finally) - and programmable break timing.
(Removed the BREAK function from the menu)
- Programmable ^G and Margin BELL fequency and bell length.
- Programmable VT-100 DA response value (mainly so that you.
can decide if the terminal indicates AVO present or not).
PC100 is a PC based VT-100 emulator which:
Runs under DOS, so you can use any old PC as a VT-100
Is more complete than any other DOS VT-100 emulator I've seen,
supports everything from the DEC VT-100 documentation (including
VT-52 functions) except for:
- Double Wide/High characters.
- Smooth scroll is implemented as "slow scroll".
Supports all VT-100 attributes correctly (VGA).
Supports full VT-100 graphics character set (VGA).
Keyboard is fully mappable, including Shift, Control, NoScroll,
Break, and all other VT-100 key functions. You can use ANY key
on the PC keyboard for any VT-100 key. Default layout replicates
the DEC keypad to the extent allowed by the physical differences.
Additional (non-VT-100 features):
Powerful script language lets you automate sessions.
File transfers - ASCII is built in, and can link to external
programs for other protocols. I include a XMODEM/YMODEM module.
30 programmable function keys with status line labels and up to 64
character transmit strings (I use them for commonly issued commands
during debug sessions).
Enjoy,
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
For some modifications on a classic computer I need 1, preferably 3 74s124 ( TTL VCO's)
Cannot seem to locate them locally (Zurich, switzerland ) and would rather not pay the 30 UKP each quoted for them by some UK based shop...
Anyone with a well stocked spare parts store ?
(I tought I had one, but no '124 among the several 1000 IC's I stocked )
Jos Dreesen
On Jan 2, 2008, at 6:31 PM, Zane wrote:
> I believe the first version or two of Windows NT shipped with x86,
> Alpha,
> PPC, and MIPS hardware support (at least I think those were the 4
> listed
> architectures). Somewhere I should have a box that says it supports
> all 4.
NT4.0 definitely does - I put it on an AlphaServer once for the novelty
(booted it up, said "why bother?" and installed something more
DIGITesque and appropriate).
Somebody wrote (sorry--I lost the original digest:)
> Many will disagree with me, but I feel that a floppy based OS that can't
> handle non-contiguous files is the worst product ever marked as being an
> OS.
They're more common than you'd think, particularly in OS for
industrial machinery, such as CAD equipment and embroidery machines.
Typically, the diskette is written only once for a particular job
(usually as a paper tape substitute) and read over and over again. In
those cases, it makes perfect sense.
Non-contiguous floppy files can be a real drag on the older floppy-
based systems that used drives with very slow positioners (now, why
does "Micropolis" immediately come to mind?). A scheme that involves
contiguous allocation with a fixed number of shots at extending (in
case you mis-estimated the size) works well on slow floppy systems.
For many single-user applications, it's possible to employ an
"allocate the remainder of the disk and truncate on close" scheme.
It's also a piece of soup/duck cake to recover files from a floppy
using contiguous allocation where the directory and allocation
information has been destroyed. (Even better to incorporate recovery
information throughout the diskette instead of one track that gets
hit over and over again, but that's another story). (Have you ever
had to recover a "work" floppy full of Lotus 1-2-3 spreadsheet data
without a directory or FAT?)
More related to the topic is that DEC VMS FILES11 had an incredibly
complicated floppy file system. Maybe BTOS was worse...
Cheers,
Chuck
