17 Apr
2000
17 Apr
'00
1:08 p.m.
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.
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.
Huh? The drives you would be copying from are "mounted" before use.
There is no on the fly mount/dismount.
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.
Praying to the gods that some manufactuere implemted it.
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
well the easy way is make the top 2k (or 4k) COMMON space so both memory
maps and communicate through that. if you really look at the bios You
will find only the stuff accessable through the jumptable has to be in
current page ram relative to the BDOS, the rest can be literally anywhere
even on a different cpu accessed over a serial line!
the other approach often used was map ram to low memeory such that
CPM(entirely) was in high ram and if it needed workspace you would enable
16k starting at 0000 and work there. This was usually combined with boot
rom mapping so that you boot from rom at 0000, copy OS to high ram, then
enable common ram and run there. If you needed space you enable a fixed
size block into low space for scratch use.
Of course if you crazy like I was you can have only 64k of ram and copy
out sections to disk (or ramdisk) as swapping then when your done swap it
back. Better have fast DMA for that or it gets real slow. it was an
effective way in 1980-81 to fit stuff into the 64k space without killing
the TPA or using a memory mapper. in that system the "ramdisk" was only
16k (memory was not cheap then) but it worked.
Of course the 8080/8085 limits you more and the enhanced BDOSes out there
didn't support them. To pack the improved code into the "standard" space
a z80 was a must.
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.
You can but that was more involved.
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.
somewhat and limited. You either live in 64k and take the TPA hit or
implement in a non compatable but in a way that can easily move to a
different platform. There were only few different schemes for open bus
systems. some of the closed bus systems did similar things but they are
already implmented.
Keep in mind by 1983 systems with 128-256k and z80 were common and allowed
all manner of options for bios mapping.
Allison