From: Richard Erlacher <richard_at_idcomm.com>
>Allison, what I have tried to put as clearly as I know how, is that the
>objective is to read THIS diskette. I'm not trying to replicate the
BIOS or
>its functions, beyond the simple task of getting the data from THIS
>diskette. While it's true, one might want to write diskettes of a
format
>compatible with a foreign system, that's not what I want to do.
>
>Let me explain:
Dont bother. I understand. I will even repeat it if you dont think so.
WHAT I'M SAYING is "THAT DISK" if you do successfully do this
will likely be the only one (or only ones like it) to work. THere are
formats that resist and defy your assumptions.
>diskettes, of which most are written on controllers I no longer have,
nor
>want. Many of the diskettes I retained were copies of materials
downloaded
>from various RCPM sites in the early '80's, from the BDS CUG, and other
>organizations whose work product was worthy of note, and a bunch of
other
been there done that and then some. I only retain masters, clearly
marked
copies and others.
Much of the non commercial stuff is on the WC CP/M CDrom and there
is my personal archive. AS I read disks I also convert them to a
standard
set of formats and over the years that has kept the accumulation of
massive
piles to a dull roar.
>controller-of-origin. While some are clearly marked as to their
content,
>the format remains a mystery. My Systems Group machine won't read them.
Likely because they are ISIS, DD CP/M written on Intel (using M^2FM).
Some of the soft sector controllers used USART in sync mode and have
really odd formats that the 177x can munge.
>Does that make my objective clear enough?
It was all the time. You haven't heard the why nots.
>I'm not trying to automate out of existence the "black-art" of creating
a
>floppy disk BIOS for CP/M, since there are already enough of them out
there,
>all different because nobody seems to have gone beyond just "getting it
to
>work, sorta ..."
If you dont understand the odd things of BIOS design you can't possibly
understand how some of the truly strange formats result.
>OTOH, I WOULD like to see an automatic procedure for generating the
>parameters for a hard disk of a given configuration, striking a
resonable
>balance between efficient use of capacity and directory space. I've
only
I've done it a lot and it's not innate that I apply a lot of experience
to
doing what must be a black art to some. it's not. most of what you
do will be highly biased by the controller, drive and CPU.
>others, but have concluded that it's possible to do that automatically
given
>the geometry of the drive. The only issue is integrating the deblocking
>code seamlesly so it can handle both floppy and fixed disks sharing the
same
>memory buffer. That introduces plent of opportunity for errors.
Ah now we are getting to something far more practical. deblocking can
easily be automated but your dealing with a BIOS and the automation
has to be incorperated at build time. IE: the BIOS has to be built to
permit adding MODULES that do functions with standardized interfaces
so adding a floppy or hard disk is easier. Of course somethings can be
handled easier if you have memory to burn. For example if you have
4k of ram you can copy as many sectors as will fit regardless of their
physical size and the code will figure out how to accomodate the
geometry by calculation. In the end you will be reproducing a PC bios
without plug and play and limited to SCSI and IDE drives (not so bad)
as they are the only ones that can be queried directly for geometry
or better yet addressed as blocks. Older non IDE controllers are
harder as their register or parameter passing schemes are a PITA.
Examples of controllers that are awkard and different from each
other in some or many ways.
Teltek S100, basically two addresses with a packet messaging
interface. requires a drive specific setup based on geometry and
other low level drive specific functions. It will also deblock for
you
if you pass logical sector info.
Compupro Disk 3A S100, DMA interface to ram, local z80 for
processing and has involved setup. requires a Buffer space
in ram of sector size minimum, system has to deblock.
WD1002-HDO (host interface) like the others requires drive
specific setup and does not deblock. Interface differs.
local sector buffer only
WD1002-wxa ISA-8 Not like WD1002-HDO but does have
setup requiremnts and also deblocking is not done.
has local sector buffer only.
SCSI --> host board is like the WD1002hdo save you now
have to deal with the SCSI layer.
SCSI --> SCSI drive (over 40-50mb) block addressed at
512byte sector level, supplies geometry on query, larger
drive have cache.
IDE (larger than 40-50mb class) caching or at least sector buffers,
respond to geometry query on most. Interface on later designs
have variable geometry and block mode addressing to simplify
matters. Likely the easiest and most consistant to interface.
Thats a can of worms and worrying the right deblock, alloc or
directory size are the most trivial of problems to work out.
Now if you want ot make interfacing them easy and faster build
the bios so that it KNOWS NOTHING about the disk save for
a generic idea of a 8mb hard disk.
dpblk1: DEFW 256 ; SPT pass a ALLOC size chunk
DEFB 5 ; BSH Values for 4k alloc
DEFB 31 ; BLM blkmask
DEFB 3 ; EXM extent msk
DEFW 2047 ; DSM disk size in blocks (4k) -1
(8mb)
DEFB 512 ; DRM allocated directory entries
(512 8k files =4mb)
DEFB 11110000b ; directory alloc
DEFB 00000000b ; byte 2
DEFW 00 ; check size (fixed disk)
DEFW 0 ; track offset (do
partitoning elsewhere)
chk1: DEFS 0
alv1: DEFS 256 ; 2048 bits are needed to
store alloc map for 8mb.
dirbuf1: DEFS 128
this will pass as Setsector a binary value of 0-256 and in set track a
binary value
that is also in the range of 0-255. If these two are concatenated the
result wil
be a 16bit value that is the relative sector for a 8mb disk. If it is
right shifted twice
the result will be a block address (512byte) and a index to the correct
128 byte
sector within the block. For a drive that can accept block (physical
sector)
addresses this will be all you need other than commands around it. To
partition
that likely large drive do some 24 or 32 bit math and add 65536(8mb
partition)
to it to find the start of the next partition. If the disk is only CHS
addressing take
that resulting 14bit block address and divide by # phys-sectors to get
the sector
wanted. Then divide the residue for the cylinder and head. For
partitioning just
add to the track number the required tracks to clear the 8mb space prior.
For deblocking anything works and the floppy deblocker is used. There is
no
reason to deblock the hard disk seperatly from the floppy save for one
thing,
by keeping it seperate you will not slow the apparent floppy access due
to
thrashing. This is a consideration of available space (ram) and if
banked
ram is avalable it's a good place for it.
DEBLOCKING IS caching at the physical sector level. so if you deblock
groups of sectors of a total size that equals the ALLOC size you will
get performance. the BDOS does directory access minimally at the alloc
level, a single read captures an alloc address so your committed access
is alloc/128 sectors. If the sectors happen to be sequential on the
media
so much the better(there is a hint there about interleave). All you
need
is space. If your doing that make SPT equal to ALLOC (32 for 4k) and
just read the block starting at the address passed as track and use
sector as the index as the index into the deblock buffer. Works
better for floppies if you buffer and deblock whole tracks.
Allison
Received on Sat Oct 07 2000 - 20:16:28 BST
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:33:15 BST