test-drb November 1999

test-drb@ccmp.vtda.org

211 participants
749 discussions

Obsolete media -- wanted a non-three phase RP06

by CLASSICCMP＠trailing-edge.com

>> 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

24 years, 11 months

Need DOS 3.3 to restore a PC based instrument

by edick＠idcomm.com

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

24 years, 11 months

CP/M-80 drivers for WD33C93 ???

by edick＠idcomm.com

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 >

24 years, 11 months

Obsolete media (was: Whats the screwiest thing you collect?)

by aek＠spies.com

"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.

24 years, 11 months

CP/M-80 drivers for WD33C93 ???

by allisonp＠world.std.com

<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

24 years, 11 months

Dayna File

by jcountry＠seidata.com

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

24 years, 11 months

[OT] They're restarting Chernobyl?

by cem14＠cornell.edu

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.

24 years, 11 months

Whats the screwiest thing you collect?

by foxnhare＠jps.net

> 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

24 years, 11 months

[OT] They're restarting Chernobyl?

by classiccmp＠mrynet.com

> 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 -----

24 years, 11 months

CP/M-80 drivers for WD33C93 ???

by edick＠idcomm.com

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 >

24 years, 11 months

← Newer
1
...
8
9
10
11
12
13
14
...
75
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb November 1999