Create Memory Mapper
The memory mapper, or pager, allows the cpu to change which physical addresses its virtual addresses map to. This is kind of opposite of 391, since the virtual address space is smaller than the physical one. Targeting 4k page size (aka 0x1000).
Activity
changed milestone to %Initial Kernel
added Functionality Hardware labels
assigned to @bslathi19
created branch
12-create-memory-mapperto address this issuementioned in merge request !21 (merged)
You need to decide if the mapper will just map sdram addresses or if it will map the entire address space. Mapping the entire address space makes more sense, however you will have to be careful not to map away the mapper or you will never be able change the mappings again!
In e.g. x86, the mappings are based on a control register which is always available. May you could implement something like that?
What if there were 2 address decoders, one before the mapper and one after.
But what would go on the fixed decoder, other than the mapper itself?
- Could figure it out later, but have the things in place now
- Things like fault codes (in the mapper...)
Should I have a control register interface? If I did, where would it go? Maybe in fist 4k?
- We have zeropage and processor stack which may or may not be paged
- we have software stack which probably will be paged.
- These take up 2560 out of 4096 bytes. The rest of it can be marked as control registers? then there are 1536 possible locations then.
This seems plausible, I guess go with that for now.
How will these be separated then?
- If the address is within the control register section (0x0a00 - 0x0fff), then we output control_reg_cs
- If this signal is high, then this overrides any other cs, even if the first page is mapped somewhere else.
added #20 (closed) as child task
added #21 as child task
marked this issue as related to #13 (closed)
Should IO not always be mapped though? cause thats pretty much it.
Video memory (when it exists) is going to be large though and will want to be mapped.
Right now the address map has the peripherals, the ROM, and the ram. The peripherals take up approximately 4k (eventually), and so does the ROM. I think that the IO should have the ability to be paged out, and it will be up to the user to not do that.
One downside of this is that the 4k for the peripherals and the 4k for rom will be wasted in sdram. that is 8K out of 32M, or 0.02%. It is what it is.
Long story short: final decision: The address decoding will be done with the physical address, except for the control register interface which will always have the same virtual address.
closed with merge request !21 (merged)
