Re: Ram Card Design Help
- From: no.spam@xxxxxxxxxxxxxxxxxxxxxxx
- Date: Sun, 28 Oct 2007 04:46:35 GMT
On Sat, 27 Oct 2007 01:25:04 +0200, Udo Munk <umunk@xxxxxxxxxxxx>
wrote:
On Fri, 26 Oct 2007 22:54:40 +0000, no.spam wrote:
On Fri, 26 Oct 2007 15:05:17 +0200, Udo Munk <umunk@xxxxxxxxxxxx>...
wrote:
I'm ignoring unix... :)
I'm totally ignorant about Windows :-)
I'm not but sometimes I wish I were. It's mind pollution. ;)
For the cp/m case, MPM took a sane approach. I did take another. The
assumption however was an up front no program will exceed 60k and for
most CP/M programs out there that is valid. The system then could swap
a programs space, and create a sized space in ram for an application.
The programs if they crash would do so in their space and it they touch
the system page (F000h) an interupt was forced ( in hardware)
Yep, that is something else to keep in mind, it should be possible to
write-protect the common memory, or generate an interrupt on write to the
area, so that the OS can be protected.
The Z280 can exceed the 16bit space as it has both the MMU and the I&D
space split.
Right, that one is more useful for more advanced stuff.
With 4K scatter/gather efficientcy is higher. Also applications can
ask for thram they need and the manager can set that space aside and
put the program there for it's time slice. The management cost is
modest and hardware easy being basically a pair of 74189 or similar
plus glue. This is closest to the mapper used in Z280 and also the
PDP11.
If you write in assembler and think a lot about segmenting your
programs, that can be done, yes. On systems like Unix you just want to
write real huge programs and don't be bothered with the memory
management, kernel does it all for you. If you want to do page faults
just with software, you need to inspect every JMP and every MOV, if it
would address memory outside the current active page. Writing a C
compiler that does this is quite a challenge, and it's a lot of
overhead.
Again unix... It's nice if the system can.
Yeah, well, other OS's can do too if the hardware is given. I know
how this stuff is done in the Unix kernel, so I used it as example.
I cheated. I said never exceed 60k and the OS will grant it and track
it. If for some reason you ask for 60k and there is not enough ram left
the system finds a program (least recently used) and pushes it to disk
and uses the recovered space. The idea is Z80 programs are generally
small but multiple tasks require many spaces often less than 16 or 32K.
It's a small system model not an attempt ot make a Z80 into a VAX.
Yes, the swapping can be done with a Z80 too, that won't be a problem.
I'd almost forgotten. During that time I was doing most everything in
Z80 asm and I'd written a macros for jump long and call long to get
around the out of 64k pool problem. The macros were really a
subroutine to get another allocation or ram, set the program counter
inside the code and then catually do a jump to some lower address.
The call did that and saved the return address and page. Essentially
making all of the page fault logic inside the program. Basically I
arrived at it by making a possible fault, not possible except by a
bug. There was never an intent to try and protect the OS save for
limiting space used. Later I added hardware to detect an attempted
write to OS protected space and if it happened force an interrupt
and reporting an illegal write and halting that ap. It was an
interesting exercise both software and some extensive hardware.
In the end since no ap ever used extended memory I started playing
with banked BIOS where the return on effort was higher (63k+ tpa).
No when I build a system I don't bother with more than 96K of ram
and usually as three 32k low pages Rom, ram0 and ram1, and the
upper page as ram allways. It's simple and allows for banked
bios and maybe a few small background functions. It's a lot simpler
and cheaper.
Allison
Clearly a 32 or better 64 bit cpu solves the address space issues and
they also support page faults and the like. I was trying to apply big
ideas in a scaled way.
Right so, trying this too, so I hope the discussion helped a bit.
Allison
Udo Munk
.
- References:
- Ram Card Design Help
- From: Grant Stockly
- Re: Ram Card Design Help
- From: Grant Stockly
- Re: Ram Card Design Help
- From: Herb Johnson
- Re: Ram Card Design Help
- From: no . spam
- Re: Ram Card Design Help
- From: Udo Munk
- Re: Ram Card Design Help
- From: no . spam
- Re: Ram Card Design Help
- From: Udo Munk
- Ram Card Design Help
- Prev by Date: Re: Ram Card Design Help
- Next by Date: Re: Forth and CP/M
- Previous by thread: Re: Ram Card Design Help
- Next by thread: Re: Ram Card Design Help
- Index(es):
Relevant Pages
|