>> It would be great if there was a massbus interface for a more recent
>> tape drive, and the same for a disk... it would be neat to be able to
>> have a DAT tape acting like a TU77 or something supported by the machine,
>> and a couple of SCSI or even IDE disks acting as RM03 or RP06 disks...
>>
>> (anyone know of any? Anyone up for the challenge of designing one?)
>Well, considering the DEC Massbuss patent and that they damn near sued
>anyone who used it to death... I don't think it will get much interest.
>I don't know any company out there that would consider it.
Luckily, a company called SETASI did consider, and has been selling
Massbus-compatible interfaces to "modern" drives for the past
two decades.
DEC, as a matter of fact, has been selling several SETASI-produced
units for the past several years. The SETASI Shelby has been listed
as the DEC RM06 and RP12 in the DEC Systems and Options catalog for some
time now.
See http://www.setasi.com/DECPP.html for details.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
In case you can't get the right dos version right away, perhaps you could
try loading SETVER. That should work with your later DOS version.
Dick
-----Original Message-----
From: Stan Perkins <stan(a)netcom.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, November 28, 1999 10:49 AM
Subject: Need DOS 3.3 to restore a PC based instrument
>Hello all,
>
>I have just acquired a PC-based instrument. It's a Model DTA 8850
>Digital Timing Analyzer, made in 1989 by a company called International
>Test Instruments, Inc. in Irvine, CA. Unfortunately, they seem to be out
>of business.
>
>The machine is based on a PC architecture, with the specialized signal
>conditioning circuitry on a backplane. It has some sort of non-volatile
>electronic disk as the C drive. I was able to determine that the
>operating system is DOS 3.3, but there is something munged about it,
>because it won't run the application software for the instrument. I can
>boot the instrument from a floppy, but the only version of DOS I have is
>6.22, and the instrument gives "Incorrect DOS Version" error messages
>when I run the application software (but it does run).
>
>I would like to get a copy of DOS 3.3 to restore this machine to its
>original state. Also, does anyone know anything about International Test
>Instruments, or (fingers crossed) have a manual or other information
>about this machine?
>
>Thanks in advance,
>Stan
Actually, the ACB4070 is a SCSI<=>RLL bridge. It operates in a way which
translates what is on the disk to cyl/hd/sector. However, it talks to the
host in SCSI. In any case, I've seen implementations (back when they were
all over the place) which worked very well, and I've seen others which
worked very poorly. Insofar as the bridge controllers were the same, I have
to assume that it was because of the BIOS code. I should have informed
myself about that back then, but it didn't seem important enough.
Take a look at additional comments below, plz.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, November 28, 1999 10:45 AM
Subject: Re: CP/M-80 drivers for WD33C93 ???
><Yes, that part of the task is quite clear. However, if you have an ACB407
><with, say, a 60 MB drive attached to its other side with some very specifi
>
>Ok thats a EDSI controller. The key question is do you talk to the bridge
>board in blocks or CHS? Most SCSI disks (like my RZ22s are blocks) and
>the drive logic does things to make that into CHS for it's internal use.
Many ESDI drives work on a logical block basis just like the SCSI's. They
have in many cases, in fact, dedicated processors on the drive logic to
handle the individual tasks. I've got some old Miniscribe 9380's on which I
can put either an ESDI or a SCSI logic board. If you compare the two
boards, they seem to have most of the same logic. Only the host interface
is different. There's a dedicated MPU to run the head carriage, one to
manage the raw data flow into the drive-resident buffer memory, one to
handle correction/detection of errors, (in the case of the SCSI only) and
one to shuffle the data between the host and drive. The thing that makes
SCSI outperform ESDI in most cases is that the SCSI leaves the host adapter
alone except when it's transferring corrected data. The ESDI relies on the
controller to handle all the correction, etc. In an environment, e.g. DEC's
MSCP, where there are enough smarts to utilize command queueing and
overlapped seeks, etc, SCSI outperforms the fastest ESDI by quite a little
bit. I participated in a MicroVax implementation using two ESDI drives from
Maxtor for a JPL-run Army/Air Force project. When Maxtor released their
SCSI drive equivalent to the very famous 4380E, which they called the 3380,
we took out the Emulex ESDI controller and replaced it with someone's SCSI
adapter, half the size of the ESDI one, perhaps it was from Emulex as well,
and put in two of the 3380's where the 4380's had been, and got WAY better
() performance. The adapter cost less than half what the ESDI one cost, the
3380 drives were $1k lower in price, at $3375, while the 4380's cost, (get
this!) $4380. It wasn't a tough choice. The JPL guys didn't like the
report I had written about the performance gain which went along with the
price cut. I was fired (briefly) from the project, and the switch to SCSI
was made a few months later.
><number of cylinders, heads, and sectors, there's yet another task to
handle
><It would really be slick to figure out some combination of partitioning,
><simple arithmetic, and some form of sleight of hand, to map the sector
><number and track number you get from the BDOS into the physical drive
layou
><directly, then derive a parameter for the benefit of the SCSI side of the
><controller to munch while fetching the appropriate block. The DR-supplied
>
>For current SCSI and IDE I just map SPT at something binary and that set
>tracks to a number I can easily work with. Since TRACK and SECTOR are both
>16bit values (or can be) this makes it pretty easy.
>
>Watch out for track (one head) and cylinder (n many heads).
It seems that if the BDOS is willing to call out both the track and the
sector numbers in a range from 0..FFFFH, that means you only need to specify
one sector per track if all you want is a logical block (physical sector)
number. You then right-shift to scale for the physical sector size and then
let the deblocking code wade through undoing that. FFFFH sectors is the 8MB
max allowable capacity, is it not? The bridge controller translates from
logical block numbers to cyl/hd/sec in some way they don't choose to tell us
mere mortals.
OTOH, using the BDOS to do more of the work, sorta, you can map tracks into
logical blocks, and use the sector number to point into the logical block at
the appropriate 128-byte portion. What I'd like to know is what works best.
It's particularly important that this be small, since it's for CP/M 2.2.
>
>For something like the old Xybec bridge you working with raw CHS so
>something like 16 physical (64 logical) sectors per track (what it
>formatted to on a ST225) and 4 heads can be sent to the bdos as 256spt
>(4h*16sectors*4logicalsectors per physcial block). That means there
>will be 615 tracks. Very straightforward. This gets a bit messy if
>there are say 17spt (512byte sectors) but then if there are 4 heads that
>makes 68 physical sectors times 4 (128 byte logical sectors) or 272 sectors
>per track... awkward but manageable (note the sector value is 9bits so the
>bios will have to capture the full 16 bits passed in DE from the BDOS).
>
>Myself unless I'm working with floppies I give the bios table (disk
>prarmeter block) numbers like 256spt and say 2047 blocks (8mb logical disk
>with 4k allocation size). That means the concatination of TRACK and SECTOR
>passed to the bios will be a pure binary number of the logical sector
>(0-65535) the BDOS wants. I can then in the BIOS translate that to what
>ever mapping I need. Generally for SCSI disks I add some number of blocks
>to that to get the track offest for partitioning or system tracks.
What do you find this does to your directory allocation scheme? I've never
quite figured out how to optimize the block size so you don't either run out
of directory entries or disk space far too soon.
><code (DEBLOCK.ASM) will handle the selection of the right 128-byte block
><easily enough.
>
>You can do better than DEBLOCK. If you have space caching larger that
>physical blocks give a real performance boost.
>
><Barry Watzman was kind enough to root through his BDOS listings to assure
m
><that while the sample BIOS's in every case use only a byte for the sector
><number and track number, those are developed to 16-bits and passed as such
><in and from the BDOS and to the BIOS. This means one has to make no
><concessions to CP/M about contiguous block numbering. It gets ugly,
though
>
>Barry's examples are practice VS what the BDOS actually does. The BDOS
>passes 16 bit values for both track and sector. If the SPT happens to be
>set to less that 257 then you can be assured the BIOS will recieve a 16 bit
>sector with the upper byte of 00. Why not take advantage of the BDOS doing
>this work? For all the BDOS cares SPT can be 1 or 65535! all it does is
>crank out a different "track" value for those cases.
>
>Hint in the past I've use 4 spt! that means the sector number is an index
>into a physical block for a 512byte sector (for deblocking). Track has the
>relative block (0-16384) for me to crack into physical head, sector, track.
>Or in the case of most SCSI disks the actual block I want from the drive.
Yes, this is what I meant, above.
>The one thing that is hard limit is there will be 65536 sectors MAXIMUM to
a
>logical disk under cpm 2.2. If you have P2DOS, ZRdos, Novados, CPM3 those
>all increase by a minimum of 4 to 32mb and can be as large as 1gb for
>logical disks (if you can live with a allocation size of 32k and have the
>alloc table space).
>
><if you want to fit those nice, neat numbers into a scheme supporting 7
><heads, 1117 cylinders, and 26 sectors of 512 bytes into it.
>
>It will not fit as that is a 1Gb disk! Reality is the BDOS (V2.2) can
>only deal with a 8mb partition of that (some 128 partitions would be
>needed and CPM is never going to do all of them <limit of 16>). Also
>while some of the CPM clones will address a disk this large the granularity
>is really bad as they want to use 32k allocation blocks. It can be done
>but you going to have to create a "different" bios that will allow ony of
>the 16 logical drive to be assigned to any physical drive (or a partition
on
>one).
Actually, it's a 99.25 MB disk. It's a miniscribe 3085 used with RLL.
Since I have one of these lying about, and since the 4070 is an RLL bridge,
I thought I'd use those numbers.
>I've done this enough times to know what the book says, what people have
>done (not all good either!) and what the BDOS really does (read the code!).
>What the BDOS sends back is reflective of the Disk Parameter Block and
those
>numbers do not have to have any relationship to the physical device other
>than some consistancy on total device size. Keep in mind the BDOS has no
>concept of heads (you have to deal with that in the bios) and could care
>less about the geometry of the disk as that is something the bios writer
has
>to decide.
>
>There are few hard rules for the CPM bios and a great deal of flexibility
>if you care to take advantage.
>
>Allison
>
"IMHO, it makes little sense to retain media for washing-machine-sized disk
drives if you don't retain the drives and maintain them in order to retain
the value of the media. Hindsight is always 20/20, but wouldn't it make
sense to archive data/software on an archival medium, likely, we hope, to
remain useable over time, rather than to store it on what's intended for
on-line storage, and is likely to become obsolete within a couple of years
of when it was developed?
"
It makes perfect sense, and as soon as I can get a mechanism running to
read the packs, the data will be archived. If it was simple to get this
done, I would have finished the project years ago.
Archiving data in a form that is "useable over time" is another matter
entirely, and I'm sure it must have been the subject of many messages
here in the past.
<Yes, that part of the task is quite clear. However, if you have an ACB407
<with, say, a 60 MB drive attached to its other side with some very specifi
Ok thats a EDSI controller. The key question is do you talk to the bridge
board in blocks or CHS? Most SCSI disks (like my RZ22s are blocks) and
the drive logic dows things to make that into CHS for it's internal use.
<number of cylinders, heads, and sectors, there's yet another task to handle
<It would really be slick to figure out some combination of partitioning,
<simple arithmetic, and some form of sleight of hand, to map the sector
<number and track number you get from the BDOS into the physical drive layou
<directly, then derive a parameter for the benefit of the SCSI side of the
<controller to munch while fetching the appropriate block. The DR-supplied
For current SCSI and IDE I just map SPT at something binary and that set
tracks to a number I can easily work with. Since TRACK and SECTOR are both
16bit values (or can be) this makes it pretty easy.
Watch out for track (one head) and cylinder (n many heads).
For something like the old Xybec bridge you working with raw CHS so
something like 16 physical (64 logical) sectors per track (what it
formatted to on a ST225) and 4 heads can be sent to the bdos as 256spt
(4h*16sectors*4logicalsectors per physcial block). That means there
will be 615 tracks. Very straightforward. This gets a bit messy if
there are say 17spt (512byte sectors) but then if there are 4 heads that
makes 68 physical sectors times 4 (128 byte logical sectors) or 272 sectors
per track... awkward but manageable (note the sector value is 9bits so the
bios will ahve to capture the full 16 bits passed in DE from the BDOS).
Myself unless I'm working with floppies I give the bios table (disk
prarmeter block) numbers like 256spt and say 2047 blocks (8mb logical disk
with 4k allocation size). That means the concatination of TRACK and SECTOR
passed to the bios will be a pure binary number of the logical sector
(0-65535) the BDOS wants. I can then in the BIOS translate that to what
ever mapping I need. Generally for SCSI disks I add some number of blocks
to that to get the track offest for partitioning or system tracks.
<code (DEBLOCK.ASM) will handle the selection of the right 128-byte block
<easily enough.
You can do better than DEBLOCK. If you have space caching larger that
physical blocks give a real performance boost.
<Barry Watzman was kind enough to root through his BDOS listings to assure m
<that while the sample BIOS's in every case use only a byte for the sector
<number and track number, those are developed to 16-bits and passed as such
<in and from the BDOS and to the BIOS. This means one has to make no
<concessions to CP/M about contiguous block numbering. It gets ugly, though
Barry's examples are practice VS what the BDOS actually does. The BDOS
passes 16 bit values for both track and sector. If the SPT happens to be
set to less that 257 then you can be assured the BIOS will recieve a 16 bit
sector with the upper byte of 00. Why not take advantage of the BDOS doing
this work? For all the BDOS cares SPT can be 1 or 65535! all it does is
crank out a different "track" value for those cases.
Hint in the past I've use 4 spt! that means the sector number is an index
into a physical block for a 512byte sector (for deblocking). Track has the
relative block (0-16384) for me to crack into physical head, sector, track.
Or in the case of most SCSI disks the actual block I want from the drive.
The one thing that is hard limit is there will be 65536 sectors MAXIMUM to a
logical disk under cpm 2.2. If you have P2DOS, ZRdos, Novados, CPM3 those
all increase by a minimum of 4 to 32mb and can be as large as 1gb for
logical disks (if you can live with a allocation size of 32k and have the
alloc table space).
<if you want to fit those nice, neat numbers into a scheme supporting 7
<heads, 1117 cylinders, and 26 sectors of 512 bytes into it.
It will not fit as that is a 1Gb disk! Reality is the BDOS (V2.2) can
only deal with a 8mb partition of that (some 128 partitions would be
needed and CPM is never going to do all of them <limit of 16>). Also
while some of the CPM clones will address a disk this large the granularity
is really bad as they want to use 32k allocation blocks. It can be done
but you going to have to create a "different" bios that will allow ony of
the 16 logical drive to be assigned to any physical drive (or a partition on
one).
I've done this enough times to know what the book says, what people have
done (not all good either!) and what the BDOS really does (read the code!).
What the BDOS sends back is reflective of the Disk Parameter Block and those
numbers do not have to have any relationship to the physical device other
than some consistancy on total device size. Keep in mind the BDOS has no
concept of heads (you have to deal with that in the bios) and could care
less about the geometry of the disk as that is something the bios writer has
to decide.
There are few hard rules for the CPM bios and a great deal of flexibility
if you care to take advantage.
Allison
Did you ever find one/data or manual/ or better yet the software to make them work?
I've got two of them here (one 3.5/5.25 the other dsdd 5.25/dshd 5.25) but only one power supply and no software. They show on the scsi bus to scsi probe, but
won't mount a disk to the desktop...I suppose I need software for that?
I find a site on the dayna ftp that has versions of the driver...but they are password protected, so they are of no use to me, and their tech support hasn't
answered.
All ideas/help appreciated!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Home | Collection
>
>
>
> Software | Mailing Lists
>
>
>
> ------------------------------------------------------------------------
> [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
>
> Re: Dayna File II
>
> ------------------------------------------------------------------------
>
> * To: "Discussion re-collecting of classic computers" <classiccmp(a)u.washington.edu>
> * Subject: Re: Dayna File II
> * From: jruschme(a)hiway1.exit109.com
> * Date: Thu, 25 Mar 99 17:20:57 +0000
> * Reply-To: classiccmp(a)u.washington.edu
> * Sender: CLASSICCMP-owner(a)u.washington.edu
>
> ------------------------------------------------------------------------
>
> <pre>
> I found a couple of these surplus. They're external 5 1/4" floppy drives
> and appear to have a SCSI connector. Does anyone know what system they're
> for? Are they SCSI? What voltage and polarity is the external power
> supply? Any details appreciated.
> </pre>
>
> They are SCSI and with the appropriate software would allow one to read
> PC-format disks on a Mac. Not sure about the adapter, but I *think* one
> can still find the software at:
>
> ftp://ftp.dayna.com/Pub/Macintosh/DaynaFile/
>
> A couple of notes: 1) They've been discontinued for quite a while, so I
> don't know how well it will work with newer OS releases. 2) Apparently,
> they equipped them with different types of drives as I've seen ones with
> 360K, 1.2MB, and even 1.44MB floppy drives.
>
> I have to confess that I wouldn't mind finding a cheap one to play
> with. Unfortunately, the ones I've seen always seem to be out of my
> range.
>
> <<<john>>>
>
> ------------------------------------------------------------------------
>
> * Prev by Date: Re: Floppy drive Jumper question
> * Next by Date: Re: Open Houses (was Re: Museums)
> * Prev by thread: Re: Dayna File II
> * Next by thread: Dayna File II
> * Index(es):
> o Date
> o Thread
>
>
>
>
> Created by: Kevan Heydon on Thursday, 25-Mar-1999 09:36:00 PST
I know, bad form to reply to my own post, but I kept on reading the
report and found more specific stuff:
At 12:46 AM 11/28/99 -0500, I wrote:
>>From the numbers quoted, a little over 10000 cases of thyroid cancer
>(which has a 10% mortality rate), mostly in children, can be blamed on
>Chernobyl.
The exact figure until 1996 was actually 800 people in the three most
exposed countries.
Projections of excess cancers resulting in death over the lifetime of all
those exposed have been revised downwards continuously. They are currently
at about 7000, but the lack of incidence of leukemia (compared to what they
expected) is making people to further downgrade the expected death toll.
Of course, many people venture figures; Greenpeace estimates that the
death toll will eventually be 30000, but most cancer epidemiologists
disagree, according to the report.
> Subject: Whats the screwiest thing you collect?
> Date: Thu, 25 Nov 1999 23:48:11 -0800
> From: Mike Ford <mikeford(a)socal.rr.com>
> To: classiccmp(a)u.washington.edu
>
> I am just wondering what some of us collect that we consider the screwiest
> ourselves. For example, for reasons I can't fathom I have started
> collecting Apple logo AC power cords, and have a couple dozen of various
> styles now.
I never think of my collections screwey, but other (mundane souls) may have
problems with that.
Here are my top must-grabs:
* Commodore stuff (Micros, Monitors, Literature, am kinda looking for a C=
filing cabinet now.)
* Wierd Movies (Plan 9 from Outer Space, Dr. Caligari, stuff by Troma and
other videos of 'unique' quality.) mainstream is getting too gross and violent.
* Computer related books and movies (like reading good computer history and
tales in fiction; though nowadays it is hard to find 'good' stuff in all the
crud being made.)
* BASIC program/programming books, mainly 8-Bit BASIC stuff (I was surprised
to find a single player chess game in BASIC in one).
--
01000011 01001111 01001101 01001101 01001111 01000100 01001111 01010010 01000101
Larry Anderson - Sysop of Silicon Realms BBS (209) 754-1363 300-2400 baud
Commodore 8-bit page at: http://www.jps.net/foxnhare/commodore.html
01000011 01001111 01001101 01010000 01010101 01010100 01000101 01010010 01010011
> At 11:48 AM 11/27/99 -0800, Daniel A. Seagraves wrote:
> >Slashdot has a link to an MSNBC story about the Russians restarting reactor
> >#3 at the Chernobyl plant in the Ukraine. They need the power but can't
> >afford a new reactor.
>
> The reactor that had the fire was (and is) irretrievable. The new reactor
> was one that was in process to go on line before the disaster and has never
> been run.
>
> There are several interesting reports about Chernobyl but perhaps the one
> most sobering is that during its time of operation, _including_ the
> meltdown, it has generated more power and killed fewer people and done less
> harm to the environment than the coal fired plants in Michigan. The damage
> those plants have done include dumping so much sulphur and other chemicals
> into the air that they have killed vast tracts of forest and made some
> lakes and streams completely devoid of life. If you add the number of
> people killed in coal mining accidents and getting black lung disease the
> numbers are even worse.
>
> Consider it flame bait if you like, but if you run the numbers this country
> would be a lot better off (fewer people killed generating the power, fewer
> natural resources destroyed) with a nuclear power infrastructure than it
> would be with a fossil fuel powered one.
The issue is not one of nuclear power vs fossil fuel (or otherwise). It is
one of mismanagement, disregard, spitefulness (towards the IMF and others,
in paraphrase, "If you don't pay us to shut it down, we won't."), and the
continued use of poor technology and less-than-marginal safeguards.
The recommendations and subsequent agreement in decision to shut the plant
down was for safety reasons. It was not simply because its sister plant
failed that it was shut down--the fundamental design for operation and
containment are flawed.
It is sad you compare this Soviet-era technology to that of the U.S. or
even other modern installations. The number of casualties in Ukraine
alone are in the thousands for the first months after the accident there.
Well over 150,000 people have now died as a result. This from a single
incident. The numbers are staggering. There are still tens of thousands
of people suffering and dying from thyroid cancer. There are towns for
a hundred miles surrounding the plant that have been evacuated and are
now off-limits. The radiation is still there. The radiation is still
killing people. The radiation will not go away soon. Let's not confuse
a world-wide coal-fueled industry (dare you imply the U.S. of being alone
here) to the Chernobyl installation which has proven design flaws.
Whether the sister reactor had been brought online or not (which I won't
bother going into, since your information is wrong there as well), the fact
remains: they are of the same design and the same generation. The reason
the reactor is being brought online is political. It is not one of dire
necessity. It is purely political, and economic as well. Here again
the callousness towards humanity comes into play. The Soviet Legacy
prevails.
People, if you need to, search the web. Get educated, or at least
informed. The world has forgotten the true nature and impact of the
Chernobyl accident. These innocent dead and dying people don't deserve
to be forgotten and this should not be repeated by arrogance.
I believe the simple act of taking just a few minutes to type into
a web search engine, "chernobyl dead," will elighten people much more
than what they think they know about the issue. The Western press is
infamous for its minimal reporting, and then only when the subject is
current, topical, and fantastic enough to gain readership. You simply
must find out from more than one source and without the Media Fantasy
bias.
Respectfully,
Scott G. Taylor
--
Scott G. Akmentins-Taylor InterNet: staylor(a)mrynet.com
MRY Systems staylor(a)mrynet.lv
(Skots Gregorijs Akmentins-Teilors -- just call me "Skots")
----- Labak miris neka sarkans -----
Yes, that part of the task is quite clear. However, if you have an ACB4070
with, say, a 60 MB drive attached to its other side with some very specific
number of cylinders, heads, and sectors, there's yet another task to handle.
It would really be slick to figure out some combination of partitioning,
simple arithmetic, and some form of sleight of hand, to map the sector
number and track number you get from the BDOS into the physical drive layout
directly, then derive a parameter for the benefit of the SCSI side of the
controller to munch while fetching the appropriate block. The DR-supplied
code (DEBLOCK.ASM) will handle the selection of the right 128-byte block
easily enough.
Barry Watzman was kind enough to root through his BDOS listings to assure me
that while the sample BIOS's in every case use only a byte for the sector
number and track number, those are developed to 16-bits and passed as such
in and from the BDOS and to the BIOS. This means one has to make no
concessions to CP/M about contiguous block numbering. It gets ugly, though,
if you want to fit those nice, neat numbers into a scheme supporting 7
heads, 1117 cylinders, and 26 sectors of 512 bytes into it.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Saturday, November 27, 1999 9:40 PM
Subject: Re: CP/M-80 drivers for WD33C93 ???
>
><It would be interesting to see SOMETHING for the 33C93, but what puzzles m
><more than anything else is the question of how to cook up a quick and dirt
><translation from the CP/M drive/track/sector specification to a logical
><block structure as is used on SCSI/SASI devices. CP/M 2.2 is so much nice
>
>This is real easy, first remember you going to be limited to 8mb unless you
>used something like P2DOS or ZRdos.
>
>With that said and done...
>
>This means there will be 65536 sectors to a logical disk (CP/M-80 V2).
>
> SPT set that to some handy number like 64, that means tracks will be
> expressed as 64 sector chunks.
>
> That means there has to be 1024 tracks. This will be the bios passed
> numbers for track and sector.
>
> Of course thats logical sectors (128bytes) this will have to be grouped
> 2 or 4 per physical sector (256 or 512bytes). Deblocking will be done
> locally on the host and all reads and writes will be at the disk physical
> level.
>
> Offset (reserved tracks) is sized as logical tracks (what ever sector
> amount has been set up)
>
> of course there is more work but those are the clues.
>
>By using binary sizes for sectors, them math to concatenate tracks and
>sectors into "blocks" is a matter of a few right or left shifts.
>
><if you have a maximal TPA which won't happen if one's using table lookups
><and stuff in place of computations to determine which block contains what
><the OS is in sector ss of track tt on drive x. You see, if this is
><implemented on a bridge controller which talks SCSI to the system, but
whos
><drives are ST-506 interfaced, there are good ways and bad ways to allocate
><blocks. It's simple enough to do one layer, but if you have to deal with
><two, how you do one will have substantial impact on how the other works
out
>
>This is hard to follow but the bios does not have to be large and the real
>space grabber is the ALLOC vector. If the system has banking even a 4k or
>16k bank in low memory can easily swallow the various host buffers and
>Allocation storage which can be large.
>
>Allison
>
