What I see is the drives and memory devices growing and growing, with little
more functionality in the software we use, yet with an order of magnitude
increase in the size of the software every decade. Admittedly there are
many improvements which, lumped together, spell progress. Nevertheless, I'm
not excited about drifting too far out of the apropriate historical period
with my own hardware. I've found that early S-100 (MITS, IMSAI, Processor
Tech) hardware tends to play together better with its own generation rather
than with later stuff. I've also found that middle-period (CCS, S.D. Sales,
Cromemco, etc.) boards don't interoperate with early or late period stuff
nearly as well as it should. The late stuff (Systems Group, IMS, and MANY
others) doesn't seem to like early or middle period stuff.
As a result, I like to keep these periods isolated. Note that I didn't
mention GODBOUT/COMPUPRO in any of the above groups. I've found that their
stuff doesn't even play well with other products from their own catalog. If
you wanted it to play together, you had to buy what they wanted you to use
together. I never learned to like that, so I only use their simplest stuff.
Please see remarkes embedded below.
Dick
----- Original Message -----
From: <allisonp_at_world.std.com>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, April 17, 2000 7:34 AM
Subject: Re: 8-bit IDE
> > >
> > 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 nicads 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 24-bit math rather than 16-bit truncated. They also
> allow larger ALLOC sizes (up to 32k).
>
Is there a word or two missing in this paragraph? I'm not sure what it
says.
>
> > 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 found 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 partition 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,
<snip>
> > 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. Using 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.
>
That seems remarkably un-CP/M-like, but quite practical, provided the OS is
able to mount/dismount a drive as part of a ^C. Otherwise, you have to have
a directory of directories on line so you can automatically dismount one
drive and mount another between reads and writes. Perhaps you could tell
me how it works when you copy between two drives at least one of which is
not currently logged. We should take that off the list, though.
>
> > 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 24-bit
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.
>
I'd certainly like to know more about this, but for now, I'm promarily
focused on finding out what the story on the standard approach to forcing
8-bit mode on the IDE interface is.
>
> 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.
>
Well, I've still got a bit of work ahead of me to find out precisely how
these enhanced BDOS thingies expect to communicate with memory outside the
normal/default 64K memory space. I've got to do all this in a way that
works with an 8080/8085. I'd also like to do it in a way that works with
nearly all physical mapping strategies without a major rewrite. If
"extended" memory addressing is a realistic option, I could go for the
CP/M-3 approach to putting the BIOS in the "extended" region.
>
> > whatever-dos will have to be demonstrated working properly and properly
> > documented as well before I'll be interested.
>
> Well it's old news.
>
One reason I rejected some of the approches to memory management and large
storage management was that there was no reasonable documentation, nor was
there a reasonable hope of any standardization. Maybe the doc's finally
caught up with the realities.
>
> Allison
>
Received on Mon Apr 17 2000 - 12:23:55 BST