f



does CP/M understand "disk head?"

Speaking primarily about CP/M 2.2 (but 1.x and 3.x should be included) ... =
does the OS understand "disk head?" From what I can tell (by looking at var=
ious BIOS implementations and the CP/M 2.2 source), CP/M only "speaks" in t=
racks, sectors, records, and blocks. There are no provisions within the sys=
tem for "disk head." Am I correct, or am I missing something?
Thanks!

P.S. What about CP/Net and MP/M?
0
Liam
11/15/2016 2:11:17 PM
comp.os.cpm 3422 articles. 0 followers. Post Follow

10 Replies
326 Views

Similar Articles

[PageSpeed] 42

On Tue, 15 Nov 2016, Liam Fry wrote:

> Speaking primarily about CP/M 2.2 (but 1.x and 3.x should be included) 
> ... does the OS understand "disk head?" From what I can tell (by looking 
> at various BIOS implementations and the CP/M 2.2 source), CP/M only 
> "speaks" in tracks, sectors, records, and blocks. There are no 
> provisions within the system for "disk head." Am I correct, or am I 
> missing something?

As I understand, the BIOS computes physical head/track from a logical 
track number.

-uso.
0
Steve
11/15/2016 2:52:03 PM
The OS's don't know about a disk head. A double sided 80 track
disk has 160 tracks, 0-79 head 0, 80-159 head 1, or alternating,
BIOS has to handle the heads properly.
0
Udo
11/15/2016 2:59:29 PM
CP/M was written for floppy disks when disk drives were 8" dingle sided sin=
gle density.  It was later modified to allow disk parameters to be altered =
for different disks but disk head was never added.

People implement disk heads by either altering track number or sector numbe=
r.

CP/M normally has a boot portion of the disk, this should be taken into acc=
ount when defining disk parameters (normally done by skipping tracks).

CP/M is limited to 8mb filesystem (logical disk) most other versions have a=
 32mb filesystem limit.

If you have a 64mb drive that is LBA you would normally figure out how many=
 sectors you need for boot portion and offset first logical disk by that mu=
ch or more.  This can be done by using track offset or by hiding the boot p=
ortion by offsetting w/o informing BDOS.

For hard drives with hd/trk/sec it is usually either keep sector count and =
have heads logically in track number or just convert to LBA and using secto=
r offsets - ignoring drive geometry. Using any method the programmer prefer=
s.

If you have "huge" drives then efficiency can be thrown out the window and =
use LBA with 256 sector implementations and just use track offsets for ever=
ything.


Randy
0
randy482
11/15/2016 4:44:32 PM
On Tuesday, November 15, 2016 at 5:44:33 PM UTC+1, rand...@hotmail.com wrote:

> CP/M is limited to 8mb filesystem (logical disk) most other
> versions have a 32mb filesystem limit.

CP/M 2 is limited to 8MB filesystems, CP/M 3 and MP/M 2 512MB.
0
Udo
11/15/2016 5:11:05 PM
Il giorno marted=C3=AC 15 novembre 2016 15:11:20 UTC+1, LiamF ha scritto:
> Speaking primarily about CP/M 2.2 (but 1.x and 3.x should be included) ..=
.. does the OS understand "disk head?" From what I can tell (by looking at v=
arious BIOS implementations and the CP/M 2.2 source), CP/M only "speaks" in=
 tracks, sectors, records, and blocks. There are no provisions within the s=
ystem for "disk head." Am I correct, or am I missing something?
> Thanks!
>=20
> P.S. What about CP/Net and MP/M?

CP/M only knows about track/sector. Any other disk detail is managed by the=
 BIOS (i.e. is implementation dependent).
0
pbetti
11/15/2016 6:36:44 PM
On Tuesday, 15 November 2016 15:52:04 UTC+1, Steve Nickolas  wrote:
 
> As I understand, the BIOS computes physical head/track from a logical 
> track number.
I don't think so.  The conversion of logical record number to track and sector is made in the BDOS and not the BIOS.
0
billcollis
11/16/2016 8:15:37 AM
On Wednesday, November 16, 2016 at 2:15:38 AM UTC-6, billc...@iscmns.org wrote:
> On Tuesday, 15 November 2016 15:52:04 UTC+1, Steve Nickolas  wrote:
>  
> > As I understand, the BIOS computes physical head/track from a logical 
> > track number.
> I don't think so.  The conversion of logical record number to track and sector is made in the BDOS and not the BIOS.

No

Randy
0
randy482
11/16/2016 9:00:24 AM
On Wednesday, November 16, 2016 at 2:15:38 AM UTC-6, billc...@iscmns.org wrote:
> On Tuesday, 15 November 2016 15:52:04 UTC+1, Steve Nickolas  wrote:
>  
> > As I understand, the BIOS computes physical head/track from a logical 
> > track number.
> I don't think so.  The conversion of logical record number to track and sector is made in the BDOS and not the BIOS.

The BDOS knows track and sector based on the drive parameter table.  The table is usually faked to one degree or another, for example dual sided drives and especially large drives.

The easiest thing to fake is number of sectors per track, often it is translated to sectors per cylinder other times just faked with 256 (one byte) for easy LBA translation.


Randy
0
randy482
11/16/2016 9:06:06 AM
> Speaking primarily about CP/M 2.2 (but 1.x and 3.x should be included) ... does the OS understand "disk head?" From what I can tell (by looking at various BIOS implementations and the CP/M 2.2 source), CP/M only "speaks" in tracks, sectors, records, and blocks. There are no provisions within the system for "disk head." Am I correct, or am I missing something?
> Thanks!
> 
> P.S. What about CP/Net and MP/M?

The CP/M BIOS has had to deal in one way or another with the concept
of "head" since the invention of the double-sided floppy disk.  The
BDOS can just deal with logical tracks (I did *NOT* say "logical
records", and I intend "logical tracks" to refer to those on a disk,
not on a file on the disk like the "logical sector" in the CP/M
documentation for BDOS calls), typically using a formula like:

  logical_track = (#_of_heads) * (cylinder_# - #_of_first_cylinder)
  	+ (head_# - #_of_first_head)


Now, the big problem comes when the logical track number overflows
a 16-bit unsigned integer.

You can come up with a completely fake geometry that the driver (or
the disk drive itself) maps to the real one, designed to maximize
the amount of addressable disk space.  Thus you might end up with
a PC disk with 65535 sectors/track, and 255 or 65535 heads, even
though the actual number of sectors/track is different for every
physical track.  (The PC with MS-DOS has a long history of storage
capacity growing faster than the standard interfaces for accessing
disk drives) The extreme case of this is LBA, where the blocks are
simply numbered from 0 to N-1, where N is the number of (visible)
blocks on the disk.  There may be some spare sectors in case some
go bad, but these aren't visible at the ordinary read/write interface,
and the block remapping is automatic.

A Google data center might eventually grow to the point where a
logical disk is divided into galaxies, which are divided into star
systems, which are divided into orbits, which are divided into
(space) barges, which are divided into decks, which are divided
into hosts, which are divided into drives, which are divided into
trains, which are divided into cylinders, which are divided into
tracks, which are divided into sectors.  Now, CP/M will have problems
with this massive virtual disk because the logical sector number
won't fit in 64 bits.  And they'll use this huge storage to track
every ad you've ever seen in your life.

0
gordonb
11/17/2016 3:09:48 AM
Udo Munk wrote:
> On Tuesday, November 15, 2016 at 5:44:33 PM UTC+1, rand...@hotmail.com wrote:
>
> > CP/M is limited to 8mb filesystem (logical disk) most other
> > versions have a 32mb filesystem limit.
>
> CP/M 2 is limited to 8MB filesystems, CP/M 3 and MP/M 2 512MB.

Googled and found the following.  Good to know 8MB is not set in stone.
For the emulator I use it is, since it needs to be DRI compatible.

3/10/09 8:35 PM

"Almost all of the P2DOS
derived/inspired BDOS improvements and CP/M2 replacements all
have far larger limits of at least 512MB.

Allison"



0
Ed
11/19/2016 8:58:47 AM
Reply: