8-bit IDE

From: allisonp_at_world.std.com <(allisonp_at_world.std.com)>
Date: Mon Apr 17 08:34:21 2000

> >
> The really good thing about the latchless and bufferless interface to the
> 8-bit channel is also readily adaptable to a RAMDISK via the same channel.
> That's what makes me hope for the availability of the 8-bit mode as
> described in the ATA standard. Using LBA, it's possible to write a 24-bit
> sector address to a RAMDISK. An old 8-bit SIMM would do the job nicely.

Been there done that. Current ramdisk is 8 1mx9 30 pin simms. I use
cas before ras refresh and a loadable autoincrement register for
transfers. Works just fine and using CMOS runs on 4 225mah nicards for
many days.

> know how to exploit their features. In any case, in a system where I've got

They are CPM, the difference is the internal logic for FCB to
sector/cylinder is 24bit math rather than 16bit truncated. They also
allow larger ALLOC sizes (up to 32k).

> Since it appears to be the consensus that all the doc's + all the software
> and such for CP/M 2.2 and earlier, take up less than 50 MB, a big drive in
> excess of 120 MB would make no sense at all. The Walnut creek CD has only

True save for it's a flat directory. I've foudn that multiple partitions
each for C, pascal, basic, CPM and other things allow lots of space while
not filling the directory of any one. Doing that tends to eat space but
in the long run it's a easier work enviornment and easier to backup.

> effort and with the certainty that you'll be out there all by yourself, to
> use a bigger drive, what's the point? I mentioned I had a 44MB drive back
> in the '80's and even though I had several copies of everything, it was
> never even close to half full. So, while I don't doubt that someone could

Currently used 45mb SCSI is 65% full and it does not contain everything
I'd like on it. Keep in mind I tend to keep sources and executables
in the same space as well as docs. To make handling easier I expand all
files (no compression). The WC cdrom if expanded with grow greatly.

> figure out a way to use a bigger drive rationally, I don't feel motivated to
> go out of my way. If the pico-drives I already have will work in 8-bit
> mode, then the code I already have will work to operate them. If not, I'll

Keep in mind I don't mount every partition in the house. I have a mount
utility that will "attach" a partation to a drive name so that I don't
have to have 12 drives. The savings in ALLOC space in considerable.

> The two 2-1/2" IDE drives I've got for this hard-card thing are both 250 MB,
> nominally. If you have a good and inobtrusive way to accomodate that
> without reducing the size of the TPA to such extent that I can't run a
> normal 64K CP/M and such that I can still use the MT+ v5.5 or so Pascal
> compiler for serious work, I'd be interested. I've also got a couple of
> 2-1/2" (IBM)drives with a 2mm-pin pitch connector with enough pins to be a
> SCSI device. I don't know what their pinout is likely to be. I'll have to
> look in the standards, since IBM doesn't have them on their site. These are
> 120 MB in size.

Well going to the enhanced BDOS will make logical drives bigger. Uing a
utility to mount only the partitions you need will save AOLLOC space.

Been doing that for 18+ years (mount utility) and nominally run a 56-60k
tpa.

> The standard v2.2 CP/M doesn't like logical drives (partitions) bigger than
> 64K 128-byte sectors. That's 8192 KB. What I'm after is something that
> will paste easily into a pretty standard CP/M 2.2. All the other

Check the enhanced BDOS, they (all of them) are on the WC cdrom and
SIMTEL. Not the real fix for larger logical drives and larger addressable
disks is correcting the truncation that occurs in the bdos. This is a
limitation of how the math was done and though there was a 24bit workspace
all numbers were truncated to 16bit in the 8080 version likely due to the
forseeable limits of the time. So you still have the 65535 allocation
block limit (65535*16384=1gb) for the logical drive and a 262144 sector
limit (32mb) for logical files and the FCB is unaffected. Note that some
programs will internally bounds check and quite before you hit those
limits. This still doesn't fix the fact that ALLOC space is 1bit per
allocation block and that gets big real fast.

The other fix is to bank the bios and use a common area in high memory.
then space is less a concern. A mix of both is the hot setup.

> whatever-dos will have to be denonstrated working properly and properly
> documented as well before I'll be interested.

Well it's old news.

Allison
Received on Mon Apr 17 2000 - 08:34:21 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:41 BST