Re: Ram Card Design Help
- From: Udo Munk <umunk@xxxxxxxxxxxx>
- Date: Mon, 22 Oct 2007 00:01:00 +0200
On Sun, 21 Oct 2007 20:28:11 +0000, no.spam wrote:
....
There were many schemes. The easiest is to have the lower 32k
swapable.
Why would that be the easiest? 32k banks actually are pretty bad.
You only need one bit to select a bank then. There are plenty of
other schemes. My preference is 4k scatter/gather paging.
Ah, for the circuit design that would be the easiest, true.
4kb page tables would be the best option, agreed.
A good compromise was upper 16k common and lower 48k swappable.
For CP/M 3 it doesn't matter, because when the user bank is in context,
the TPA can reach up into the common memory, so any bank size could be
used. Not so with MP/M, the size of the swappable banks is the size of
the TPA. 16/48 will work OK for MP/M, but if one wants to implement CP/NET
that won't work. The CP/NET processes were not written as banked
extensions and need to be completely in common memory. So the best
compromise would be 20k common and 44k swappable, much better than a 32k
TPA.
Exactly, most any scheme works. I only suggested one possible way.
For CP/M 3 any scheme works and it doesn't matter. I just wanted to point
out that the 32/32 scheme might not be a real good idea, if one wants to
use MP/M on the system.
In the current version of my virtual Z80 system the size of the common
memory can be programmed in steps of 256byte pages, so one can
experiment with this.
I have the granularity is nice but the overhead is high. 4K strikes a
good balance.
What you can program at a very early stage in OS initialization is the
size of the common memory, leaving the rest as swappable banks. That is to
experiment with 16/48 settings and others, because I couldn't get CP/NET
stuffed into that. There is no overhead involved because the segmentation
can be programmed once only and any change afterwards just would make a
mess, so it is verboten ;-)
At later times MMU's with page tables were used, the whole memory is
split into pages with 4k or 8k so that any memory configuration can be
programmed. There was a TTL MMU from TI that would do this, 743xx
something, I don't know anymore, sorry.
74612 was one, it can also be done with a pair of 74ls189s or similar 8
words by 8bits of ram or register.
Ah yes, the 74612 was the one I meant, if I remember right that one was
used in some machines I worked with.
Something I still have to do for my virtual Z80 system.
I've done it and it's fun to play with. The most useful application is
buffers, ramdisk and other bios bulk placed in them to allow a larger
say 62-63K TPA.
I was using that for real work, not to play with, and that machine wasn't
running any DRI product at all. We needed 4mb memory for real huge
programs and lots of data needed right in memory, because of real time
requirements.
Generally speaking there are few applications that took advantage of
extende memory. CP/M+ and MPM used it but user applications didn't.
No CP/M 3 program can use it, because the memory management is
transparent to the application and only the OS knows where GENCPM put
the buffers, hash tables and so on. The ccp can be loaded from one bank
to avoid disk access for a warm boot, or one can create a memory disk to
be used by compilers as faster temp workspace. There is a lot one can do
in the BIOS to speed up disk access significantly, but programs can't
use it.
I didn't say they could not use it I said there were very limited number
of applications that were written for that and utilized it. The larger
volume of programs are for the CP/M2.2 programming model.
I would be interested to see such applications, I've never seen one before
for CP/M 3 which utilizes this.
Also CP/M 2.2 did not prevent or disallow expanded memory.
No, CP/M 2.2 and before wouldn't know about banked memory and if there is
some, it could all be used by applications in some way. Not so easy to do
with CP/M 3 because the OS itself uses banking frequently and in an
application you won't know which banks are free to use, there is no OS
support function to figure this. Of course you could gencpm to use lets
say 3 segments and have the rest used by applications. But if someone
gencpm with different segment configuration, your application is going to
destroy OS data structures.
....
MP/M supports ~400kb, CP/M 3 supports 1mb, so go for it I think.
MPM supports as much as CP/M 3 which is at least 1MB I know of no reason
why larger is not possible.
Sorry but I cannot agree with this. MP/M, as distributed, supports 8
memory segments, one reserved for the OS, 7 for user banks. In the
commonly used setup that are 7 banks with 48kb plus one full 64kb segment
for the OS, alltogether 400kb. That's why the DRI MP/M documentation says
400kb. I have looked already at the sources to expand this, requires some
changes in the kernel and in the MP/M gensys program.
If more memory is available that could be used as ram disk, but certainly
not from applications, because MP/M doesn't know about and would
completely screw up it's memory management. The OS is in control of the
banking and the application is not supposed to switch to other banks.
Basically how you page or bank memory it is up to you as it will be
complatable with at least one of the many schemes out there all of which
were mostly incompatable with each other.
There have been schemes that were almost/totally unusable for MP/M. And
yes, it won't be compatible to anything, but that doesn't matter because
the BIOS has to support the banking. Essential is a usable documentation
for the banking hardware, so that BIOS's can be written.
As to how much, 512k is a start more if you care to. MY
suggestion is at least 512 and a meg is better. Reason, even on V2.2
the excess ram beyobd 64k can at a minimum
be a ramdisk and I've found for that application the more
is better and I have two systems with 1MB and one with 8MB as a baseline
of experience. The speed and spae of ram disk can make even slow 8080s
look impressive compared to a floppy.
Absolutely.
Allison
Udo Munk
--
The real fun is building it and then using it...
.
- References:
- Ram Card Design Help
- From: Grant Stockly
- Re: Ram Card Design Help
- From: no . spam
- Ram Card Design Help
- Prev by Date: Re: Ancient Intel software
- Next by Date: Re: Ancient Intel software
- Previous by thread: Re: Ram Card Design Help
- Next by thread: Re: Ram Card Design Help
- Index(es):
Relevant Pages
|
