> > 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.
What is saying is Novados and Suprbdos are improved version of cpm v2.2
bdos with 24bit math rather than truncated 16bit math. In addition to
that large (jumbo) allocation block sizes of 232k are allowed.
> >
> > 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
It can. the mount utilitiy messes with the DPB and DPH then does a warmboot.
CPM (the bdos that is) really doesn't care what the bios does so long as
the interface is by the book.
This is a very CP/M way to do things. I didn't invent it.
> 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
Received on Mon Apr 17 2000 - 13:08:05 BST
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:32:41 BST