http://www.theregister.co.uk/content/2/13785.html
These guys are a bunch of clowns. They used to be selling these for
$29.95 until the eBay phenomenon hit. Then they jacked up the price to
$99.95. I guess they must be selling these at that price because they
haven't backed it down.
Is an unassembled ZX-81 kit worth $99.95 to me? Hell no.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
From: Eric Smith <eric(a)brouhaha.com>
>He's not proposing to figure out the parameters by looking at tables in
>the BDOS. As you correctly point out, that stuff is in the BIOS.
True the BIOS is the repository of the disk information but it's not all
as I've repeatedly said in the "tables". It can be deeply embedded
in the code.
>Richard's point is that on a bootable disk, some set of sectors contain
>the BDOS code, which has known contents (for any specific DRI CP/M
release).
>The point is that some of the disk parameters can be worked out by
matching
>what sectors on the media contain what pieces of the BDOS code.
Sorry but the BDOS is usually in reserved tracks where things like skew
(aka intereave) is not always there or even the same density.
The BDOS other than being a known block of code contains none
of the disk specific code or layout. Putting that in the bios is what
made cpm portable to different platforms.
>It may not tell you everything about the disk format, and it obviously
>only works on bootable diskettes, but I think it is a good start.
It's only a start. to me as an bystander to this it's a interesting
exercize but one fraught with exceptions and limiations for it to
work reliabily.
Allison
-----Original Message-----
>> he uses as example. It is a defective assumption.
>>
>I'm not convinced that the structure of the BIOS matters at all if one
uses
>the BDOS to fetch or point to whatever he's after. I do believe it's
fair
His utilities break on three of my systems as I do some things like
bank part of the bios and in one case part of the BIOS is resident
and executed by a seperate cpu.
>> >In those cases, among which one finds the CCS example, wherein a
simple,
>> >"dumb" BIOS is loaded into a 20-K CP/M requiring a 32K memory in
which
>> >to run, and subseqeuently used to run a "smarter" and more fully
>developed
>>
>> Not really.
>>
>What do you mean, Allison? I can assure you that it works fine as a
larger
I didn't mean you cant load a smarter bios. Only that in the case of the
CCS
if you want a nice system loading a smarter bios is a good thing to do.
>> Yes it is. I have floppies that use 1k (most SD though some are DD!),
>> many that use 2k and even some nut case using 4k(not me honest!).
>>
>Yes but that's easily recognizable if you check the directory entries
and
>disk parameters. Remember, I propose extracting this information from
the
>physical medium, not from some speculation.
Suit yourself. There are a few programs outthere that "image" the
disk and they didn't have it easy either.
>The stepper-driven Rodime 204E (1982) was about as fast as that Quantum
and
>had 640 cylinders instead of the Q540's 512. I used one for years and
am
I presume the rodime was larger than 31mb as well so more cylinders are
not
amazing. Was it an 8headed disk?
>be posted sometime soon, I hope) was 3 ms. It would do the job for
sure, in
>3 ms. I checked many of them. The Tandon equivalent and the Shugart
>equivalent both did the same. Others came later.
There is no dispute about that and I still have the spec sheat and all
for mine.
But to go from track 71 to track 0 still takes 213Ms, you can go faster
if
you ramp the step rate to 2.2mS and look for track 000.
>So, what did you do when you wanted to use 17 512-byte sectors (commonly
>used) and a 5-head drive, like the ones form Miniscribe that plagued us
now
>and again? Or, for that matter, the 6-head ST225, which was somewhat
later.
>How about 1K sectors? You could get 9 of them per track. People were
after
>capacity, even though they hadn't yet figured out how to waste it.
did that too sector(s) is a 16bit value though most bios will truncate it
on
assumption that it will be 256 or less. The only effect doing to the
miniscribe
( have two) was I had to divide out using non binary integer math rather
than
shifts, no biggie. it was much faster drive too.
>I'm not sure it helped much, but since the early ('506-class) HDD's
stepped
>at 3 ms regardless, and since the controllers didn't take advantage of
>momentum, I put the logical zero track of every partition in the
physical
>middle of the corresponding region of the drive. That made the
worst-case
>directory-seek half as long. Once drives capable of buffering step
commands
>became available that stunt wasn't necessary. Avoiding the use of
physical
>track zero was an important trick, however, since almost every drive
homed
>to that track on power-on, and if anything went wrong, it took a "rest"
>there. I had a lot less trouble with drives once I learned not to use
>physical track zero for anything that mattered at all.
Yep you can do that. You can take multi platter drive and designate
each platter or head as a drive. In some cases thats faster.
For a 5mb st506 partitions were sorta pointless as I was going for
something
bigger than the 1mb floppies I already had. A 2.5mb partition was not
considered or desired.
For the larger 31mb drives I went to 8mb partitions and let them fall on
cylinder
boundaries and left it at that. By then caching was in use and directory
caching
as well so where things were was not much of an issue.
>> Memorex 102 I gave away working, CTRL-C was a real wait and
>> a kick to watch the head creap back.
>>
>If it truly "crept" back, it was probably because it was being stepped
too
>fast and got lost, finally having to do a recal, which it did slowly.
No 512 tracks or so and a really slow step rate it crept. the controller
was doing step out, are we at 000, repeat. Morrow disk jocky and
controller with their code... very slow.
Allison
I hope I don't get flamed too much. I just posted most of my remaining S100
cards on eBay. Seller name is Innfosale.
Sorry for this but I need to maximize my income. Boards from Northstar,
Compupro, Vector Graphic, Alpha Micro and some oddities. Also some Quantum 8"
disk drives.
Paxton
Please reply to original sender.
Reply-To: badger(a)netwalk.com
---------- Forwarded message ----------
Date: Thu, 05 Oct 2000 14:46:41 -0400
From: Butch Clodfelter <badger(a)netwalk.com>
To: donate(a)vintage.org
Subject: Re:Find Home
I am looking for a new home for my old IBM PC XT. It was manufactured in
the early 80's with the 8088 processor. IT has two HD's (10MB & 20MB) and
two 360 Floppy Drives. I have the original manuals for it. The monitor has
a 12' VGA color. DOS 3.1 was the operating system, with WP4.2, MP80. My
copies of the licenses were damaged and so only have copies, not originals!
If I find a museum where they will be used I also have a Kaypro 4 with 2.2
CPM OS I will sell for $100.00. The Kaypro 4 has all the original manuals
and Disks. Original cost = $3645.00 in 1984.
If you know of who I can contact, or of a home for the IBM please let me know!
Thanks
Butch
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
VCF 4.0 is September 30-October 1
San Jose Convention Center, San Jose, California
See http://www.vintage.org for details!
From: Fred Cisin (XenoSoft) <cisin(a)xenosoft.com>
>I am NOT saying that it is impossible - it is definitely possible. But
I
>am saying that the task of automating it would be significant. I have
I have said the same thing repeatedly. it's a worthy project but, I've
explained there are many formats that are similar that the only way
to tell them apart is to know or trial and error. I even gave one set
that is common in my room here.
Myself, prove me wrong. I have no investment in that and would
love to use it if it's a practical and useful tool.
Also myself I'm investing time in a project that I consider more
valuable. Adding a true heirarchal directories without breaking
most reasonable apps.
Allison
From: Richard Erlacher <richard(a)idcomm.com>
>Allison suggests that the disk parameters are obscure and hard to
locate,
>but CORTESI's book on CP/M, among others, provides a bit of software
that
In short simple sentences. If you have not done this you will be
surprized.
Cortesi write with the assumption that all bioses have the structure and
form
he uses as example. It is a defective assumption.
>In those cases, among which one finds the CCS example, wherein a simple,
>"dumb" BIOS is loaded into a 20-K CP/M requiring a 32K memory in which
to
>run, and subseqeuently used to run a "smarter" and more fully developed
Not really.
>version of the BIOS together with the OS loaded into whatever memory it
>finds available thereby making a 64K(actually 61K) CP/M quite
attainable,
This is not news, nor significant.
>one would have to examine the autocommand that's loaded in the "dumb"
system
>in order to find the image that's going to contain the "real McCoy" with
the
>full-featured BIOS from which the parameters relating to the directory
and
>data areas of the diskette can be extracted.
Presuming there was an autocommand.
>This strategy is particularly important in those rare cases where one
has
>actually done what the CCS folks recommend and format the first two
tracks
>of an 8" diskette single-density and the remainder at double density.
>Likewise, the remainder of the diskette can be two-sided. The reason
THEIR
CCS while a decent box is far from being the be all, say all of the bios
world.
>What puzzles me is that, if this information is so readily available,
why
>hasn't the entire process been automated already? I know there are lots
of
Becasue it's is not so readially available. You assume it is and proceed
that
way but once you get off that CCS box the world changes greatly. Look at
the 5.25 formats, look close at the similar but not the same formats.
For
example I have 5 different 5.25 781kb formats that are not even similar.
One uses 1024byte sectors, another has sector 1 on side one and side two
ends with sector 18 (512byte!). There is one that numbers the cylinders
sero thourgh 79 on one side and 80 throgh 159 on the second. The fifth
is like the first save for the skew is appied at format and not in the
bios.
Funny thing the DPH and DPB is exactly the same for all of them
>should be done. There is always a bit of a guess as to whether 4K or 8K
>allocation blocks should be used when hooking up a hard disk. That's
not an
>issue with floppies, however.
Yes it is. I have floppies that use 1k (most SD though some are DD!),
many
that use 2k and even some nut case using 4k(not me honest!).
>> I have a fully documented CCS and it clasifies as the early basic CP/M
>> bios of low to average functionality. It's robust but closer to a
minimal
>> example.
>>
>True enough, but it's compatible with a front-panel and the software's
>written for an 8080 so you can use their FDC with an 8080 or 8085 as
well as
>a Z80. Moreover, it's rock-solid. The fact that it uses a nearly
>vanilla-flavored CP/M doesn't detract either. I've run into absolutely
no
>CP/M programs that won't run on it, while there are numerous utilities
that
>won't work properly on the more modern MPM-targeted boards I got from
>Systems Group.
Sorta. It doesn't support type ahead, circular iterrupt driven buffers
for
fast serial devices and relies on CPU PIO. It's low end. The only thing
it does do is double density and SSSD 8" interchange (sometimes).
>What you refer to as skew is what I call the interleave, while a sector
skew
No I'm using the DRI term out of their books. I know its interleave.
>is a difference in sector numbering from idex, used by some systems
(mostly
>early DEC actually, but some truly random-access systems as well) to
Actually DEC has a two level one for VT180, interleaved 512byte physical
sectors
and interleave inside the sectors. It's one of three formats that were
used for that
though that was least common.
>If it's not the stuff from DRI, it's not relevant, since it's not CP/M.
Your really looking to ignore progress, and even DRI supplied mods?
>I'll admit that's a weakness, but for now, I'm happy to deal with CP/M
only.
>AFAIK, DRI didn't issue any patches to v2.2. There were several
enhanced
If you insist.
>That's true, BUT, when you have a two-stage boot, you can examine the
second
>layer boot system, and, in fact, have to in order to avoid getting
tangled
>up in discrepancies between the boot tracks and the directory and data
area.
Ok but what systems usually use a two stage boot? Few and nearly none.
>> storage. You will have to figure out from that a lot of things that
are
>variable and can still end up as the same answer.
>>
>In fact, I don't believe they have to be "figured out" at all. After
all
>the diskette is in the drive. You just have to look at it.
See my example of the 781k disks. Two of them would defy simple
inspection.
>It does get much more messy when you try to squeeze speed out of the
system
>in ways the ultra-slow CPU doesn't let you appreciate, but when I said
>optimal, I meant for the technology of the time, which meant, at least
to
>me, getting the most hard disk space to fit into the parameters the
system
>would allow, without overly restricting either effective space
utilization
>or directory space. That seems to have been the key tradeoff of the
time
>... allocation block size versus number of directory entries. One other
Not really a big deal was made of it as few had real world expereince and
were trying to scare up a few more bytes of the drive they paid so dearly
for and then never filled more than 50%. The other half was hard disks
were new things to have to deal directly with so there was an aura of
mystery to setting values. The only thing that ever and still concerns
me
is the ALLOC vector as for a 8mb logical drive with 4k granularity there
will
be 256 bytes of ram for just for that, add 512 for a host buffer, 128 for
the
directory buffer local variables and you eaten 896 bytes for the first
drive
and about 256+ per drive and that is non recoverable space. That is the
only real problem. Add that to a featureless base driver and it's an
easy
2-3k of space for the bios more if it's a real bios.
>factor was swtiching heads rather than moving the head stack. The heads
>take at least 3 ms to move from track to track, plus 8 ms on the
average, to
>rotate half a rev, while switching heads took about 40-50 microseconds
on
More than that as the ST506 didn't do (nor did the controllers of the
time)
fast seeks. You had to wait for the ST225 for that. Stated average
access
time is 178mS for st506, St225 was a more resonable 73 and the Quantum
D540 took that to a mere 57. The D540 could look faster though with it's
8 heads as you didn't shuffle far and the voicecoil actuator was fairly
fast.
>the early Seagate ST506's. The trick, to me, was always finding a way
to
>computer head, cylinder and sector from the CP/M sector number you were
>given by the BDOS without having to swallow up half a KByte in lookup
>tables.
Floggin. One the drive was filled to about 30% and had been in use for a
while you were moving around a lot and there was little trickery that
helped
at the drive level.
I didn't kill space in lookup tables. It was simple to me. The 4 heads
and the 16 512 byte sectors per track were handled as SPT of 256 in
the DPB so the BDOS would hand back a logical sector on a track
with head number in there too. I treated the four sides as one logical
track. A few right and left shifts would give me a head (upper two bits)
physical sector (middle 4bits) and logical sector index into the physical
sector (lower two bits). The CYLINDER was passed as track by the BDOS.
Obviously it was quite compact.
If you build like DRI, Cortesi or Laird said you hit the wall every
16k as where ever you are your going back to the directory where
ever it happened to be and that took a long time.
The first drive I had(still have turns 20 next summer) was a 506. It was
slow, the controllers were slow and the only up side is some would
buffer a full sector for you saving CPU timing. I stopped using it
when I got my second hard disk a D540, in real life it was much
faster and introduced me to the problem of partitions. I moved up
as the drive was available and offered speed, even with 6mhz z80s
the ST506 was ponderously slow. It was only exceeded by an 8"
Memorex 102 I gave away working, CTRL-C was a real wait and
a kick to watch the head creap back.
Allison
>Hope to have the event here in the Twicities after the snow leaves ext
>spring (2001). Still looking for more volunteers to help with the work.
>Also talking with some companies about being cash sponsors for the event
>along with prizes to give away. That's about all I want to give out
>right now until I have things locked down, but more to come.
>John Keys
Another words you are planning it for June? I remember when I moved to
Duluth MN, I figured I was safe with Memorial weekend. Wrong it snowed
while we were unloading the truck.
Dan
Opportunity knocks! I broke my left (prosthetic) foot last weekend and the replacement didn't make it here today as scheduled, so I'm going to be on my gluteus maximus for much of the weekend. If I've offered to scan a document for you, please remind me, and promptly, because I'm going to be busy catching up on chores, etc, after my broken foot is replaced.
I'm looking for a widely accessible site on which to store these documents, but I think the 1 MB/page TIFF's are a mite big for that. Perhaps someone would like to recommend a site? Let's NOT fight about the format, though, all right?
Dick
