One thing that used to be common for video graphic controllers is Video RAM or VRAM.
VRAM has two sets of data output pins, and thus two ports that can be used simultaneously. The first port, the DRAM port, is accessed by the host computer in a manner very similar to traditional DRAM. The second port, the video port, is typically read-only and is dedicated to providing a high throughput, serialized data channel for the graphics chipset.
Internally, VRAM reads an entire DRAM row and shifts it out sequentially to the video circuitry. This leave the DRAM available for use by the MPU. VRAM has largely been replaced by the use of SDRAM, "even though it is only single-ported and more overhead is required".
A technique I have used in the past is to use interleaved access to memory. It's a bit complex to explain (the devil is in the details), but I will outline the basics:
Basically the MPU accesses video memory in between pixel accesses by the video-controller. If this timing gets too tight, there are a couple things you can do that will greatly relieve the timing (usually only 1 of these is necessary):
- You can use 2 RAM chips (or banks) and interleave those using each chip for every-other pixel. In your case, this would effectively slow your pixel clock to 80ns per chip allowing MPU and video-controller access to have windows of 40ns each. This could be extended to more banks interleaving more pixels if necessary. This technique is called Interleaved Memory.
- You can increase the data-bus size of the video memory. The video-controller would read multiple pixels in a single access and use them sequentially. The MPU would either have a larger data-bus, each access would be directed to the appropriate byte (or word) and byte-selects would be used on the video memory, or a read-modify-write would have to be performed to write to the larger data size. In your case, it would probably be simplest to increase the video memory data bus to 16 or 32 bits (2 or 4 pixels), and probably then use an MPU with the same bus size.
If you interleave video accesses, you may want to consider the use of an FPGA or CPLD for your video memory controller.
Another method is to have 2 separate video memories and use bank-select. The MPU writes to one bank while the other is being used by the video-controller for display. When the MPU is finished writing, the bank accesses are swapped (usually during a sync pulse).
Since Read_Ptr is uint8 ...
Except that it's not. It's uint8*.
ptr_t, which is (should be) the type for pointers on an architecture, is however long the architecture deems it to be and is completely independent from the size of the value the compiler is looking at in that specific location.
Best Answer
virtual memory...the typical implementation is an mmu (memory management unit) between the processor and the physical memory. This can provide many features. 1) you can compile all your programs (lets assume this is windows or linux for example) for the same address space, the programs can assume their memory is from 0 to N bytes and they can have the same entry point address. The operating system manages memory and the mmu. Before switching tasks so the application, the operating system knows what physical memory belongs to that application and can program the mmu (or play games with tables to switch in a set of mmu entries) to map a virtual address space from 0 to n that is really one or more chunks of physical memory. So the processor in user/application mode sitting behind the mmu thinks it is really accessing address 0x1234 because that is the address the program generated and that is the address on the processors bus. BUT, the mmus job is to take that address, step through one or more set of tables to ideally find the physical address that is mapped to that virtual address. Which might be 0x11001234 for example. Some other program when it gets a time slice its address 0x1234 might be mapped to the physical address 0x34001234 for example.
The next benefit is that when it looks up the physical address in a table that table can (depends on the implementation) various flags, for example cached or not cached. If you were allowed to actually talk to a status register in a peripheral or were talking to something shared between you and the operating system or some other task that could change a location, you dont want that cached. If you were polling say for a uart tx buffer empty, and the memory access to that register were cached and you just sat in a loop waiting for it to change, you are going to be there a long time as each subsequent read just gets the cached value not the real value. (unless there is something else, operating system, etc, that tickles the cache and evicts your value). the uart example is for embedded bare metal cases, real world windows, mac, etc programs generally dont talk directly to peripherals but to kernel drivers via shared memory and that shared memory might/can go through the same cache for both kernel software and app software so sometimes that can be cached. Long story short, the mmu table can contain information like cached or not cached.
yes I am getting to the rest of your question...
Another feature is protection. Parts of the virtual address are used to index into the tables, if the table shows no entry for that decoded address or it shows that the application that is accessing this ram is not the application that owns that chunk of memory an exception is thrown to the processor to handle. Yes the table can and often does contain information related to a task or process id which is assigned to your program by the operating system and is used to tag your virtual addresses. Now the operating system can initially do one of two things, one is simply kill your program for trying to wander outside your space. The second is to swap, say you have 1GB of ram and 7 programs all wanting 0.5 gig of ram 3.5gig total. What you do is keep what you dont have space for in physical ram somewhere else for example on a swap partition or file on the hard drive. When the current program who thinks it has 0.5gig accesses an address which does not have a physical mapping the operating system takes a chunk of ram that ideally has not been accessed in a while, saves that to disk, and then retrieves from disk the ram for the space the program was asking for, puts that somewhere, updates the mmu table and allows the transaction to complete, other that being a really really long access the program doesnt know that all this occured. This is why you hit a performance cliff on your computer when you run out of ram, all of the sudden all/most of the programs have to swap out and with several programs running "at the same time" there is near constant moving of data to/from the disk.
Lastly the mmu feature and virtual memory/virtual address space is that what appears in the virtual address space to be linear memory from address 0 to N does not have to be linear in physical memory. Mmus often work on one or various sized chunks, say for a simple case 4096 bytes per mmu entry. So even 12kbytes which would be four mmu entries could come from four totally different places, but look to the application to be a linear 12kbytes. virtual 0x0000 to 0x0FFF might come from physical 0x10000000, virtual 0x1000 to 0x1FFF might come from 0x76001000, virtual 0x2000 to 0x2FFF might come from 0x23002000 and so on. This makes memory management much easier on one respect (more things to juggle yes so harder in that respect) but if an application requests a big chunk of ram, there doesnt have to be a linear chunk of free ram of that size, there could be hundreds or thousands of small chunks scattered all about that could be made to look linear in the virtual address space, this makes allocating and freeing memory much simpler than having to try to find linear chunks like you would if you didnt have an mmu. Some mmus and some operating system implementations have various sized chunks maybe 4k 16k 1mb etc and the os can juggle various sized physical chunks to map to the virtual address space.
The operating system manages the allocation and freeing of physical memory chunks as well as mmu tables and swapping to disk.
So sometimes when folks say virtual memory they are talking about not real memory or basically the stuff that is being swapped to disk giving the illusion of having more ram than you really have, or virtual ram. Other folks mean something else when they use that term.
Virtual address space, is the fake address on the virtual side of the mmu or the processor side of the mmu, physical address space is the other side of the mmu, yes it is absolutely possible and happens in practice that you have multiple layers of virtual and physical, the one most obvious is the mmu case virtual is always on the processor side of a boundary and physical the other side, but for example your physical address on an x86 machine for say your video card memory is really virtual. the pci(e) address space in the case of x86 has the illusion of being flat and fixed. But the window you look through to see the video ram is quite small just like a window in your house, if you look out the window and see a tree, then take a few steps to the left or right you might instead see a swingset or car or something different out side the window. This is another virtual/real address boundary. the driver tells the video card what physical chunk to map into the small window of pcie address space and then the layers of software can talk to that chunk, similar to disk swapping, when you need to access something that is not within that window you have to change what the window points to. it is like having a single entry mmu table one chunk. and that process to pcie address space boundary is the mmu most likely but the pcie to video ram address space boundaries is another virtual/physical. and if you really dig in deeper you find many of these boundaries.
I know long winded but perhaps that helps...
If you are asking with respect to microcontrollers or embedded systems that dont use an operating system, then someone has to manage this, first off few microcontrollers have an mmu although the cortex-m4 is one that does have some notion of one. if you did have a processor with an mmu that you were running bare metal (say a raspberry pi) which means no operating system basically, then the application has to manage the mmu, for reasons mentioned above you may want to have the cache enabled for ram to improve performance of your application but you need the mmu or some other hardware assist to make sure when you talk directly to a peripheral, in particular reading/polling, you dont cache that space. A very easy way to manage this is to make the virtual address equal the physical address 0x1234 = 0x1234, its bare metal you dont need to pretend to be at a convenient address. Some microcontrollers for example have straps to allow for different flashes to be used, so one strap setting may map in a bootloader flash, another setting may map in an application flash, but the processor still boots in a hardcoded way from a hardcoded address, so this is another form of virtual addressing. further still you may have a microcontroller that once you are running you can tickle a register and move where ram and flash are mapped, say your processor has a vector table at 0x0000 and you need flash there to boot initially but the chip designers have given you a feature to re-map that address to ram, so you can change the vector table or do whatever other lazy programmer thing you want to do rather than live in a fixed address space. that is another form of virtual address space.