noonan,

Unfortunately, I can only be of limited help here. By your post, I assume that you are using the bSQUARE BSP instead of Logic's. Therefore, the following information is my best guess.

1) MMU Changes:
Yes, you will need to adjust the MMU to make the SRAM and some portion of SDRAM look contiguous to the processor. This should be possible with some tweaking of the OEMAddressTable data-structure. That structure should be found somewhere down in the OAL code and is typically implemented in assembly language. The address to this table is passed to the KernelStart function which is the first thing called after StartUp. If you do this, you will also need to change the entire memory map of your Windows CE image. Thus, you will have to adjust the values in config.bib or bSQUARE's equivelant file.

2) Code Changes to the SOCLCD Driver:
That is not our driver, so I can't really advise you what you'll need to do here. You can contact our support team if needed and they can help you out. I'm sure tha bSQUARE has a support option as well.

3) Other Threads:
Logic makes extensive use of the system registry to resolve most device driver variables at run-time instead of compile-time. This allows us to provide our customers with a very flexible solution. The threads you read are most likely referring to how we (Logic) implement our LCD drivers. We export most of the device's register settings into the driver's individual registry file. That way, customers can edit a simple text file and make their custom glass work with our kits, instead of forcing them to change the driver's code.

Hope this helps,
--mikee

Mike,

Thanks for the info.

Regarding the use of the registry for LCD register settings, is the Overflow register one of these registers?

Regards,
Chris

I don't see it in our exported registers.

Do you need it for something?

--mikee

It is the necessary piece of information that tells the LCD Controller where to pick up the rest of the framebuffer in SDRAM after it runs out of internal SRAM. Without it, there would be no need to remap everything for the processor and the WinCE port does not support using the internal SRAM as part of the framebuffer.

Chris

Okay,

I see where you are going with this and, unfortunately, I'm going to have to stop you. Well, maybe not stop you completely, but at least inform you of a few things that you might not know about.

If you want to do this, you are going to have to write a completely new display driver from scratch. I know that seems harsh, but I'll try and explain why.

Most Windows CE display drivers are built around what is known as the Graphics Primitive Engine (GPE) library of software. Microsoft provides a GPE base class which driver writers can inherit from to build their own, custom driver. Doing so saves a ton of time and effort. Basing a display driver on the GPE also makes sense when the targeted hardware does not include any acceleration technology. For example, there is no need to write a display driver from scratch if all you are going to be doing is calling into the emulated blit, line, etc. libraries to do the actual drawing.

Unfortunately, GPE-based display drivers have some limitations. The biggest one in this case is that they must have a single, flat, contiguous frame buffer.

So, if you want to split up the frame buffer, you not only need to write your own display driver (as oppossed to using Logic's), but you will not be able to inherit from the GPE classes as well.

For more information, I suggest you look in the Platform Builder Help file under:

Developing a Device Driver
-> Windows CE Drivers
--> Display Drivers

After you check that out, if you still want to proceed, please contact us again. Logic could definately help you out with this effort.

However, my $0.02 is that you look for another way to increase overall system performance.

Best regards,
--mikee

Mike,

Enlightening!

Based on your description, I'm guessing the GPE works with virtual addresses and requires a contiguous framebuffer in the virtual memory space. Correct?

If so, the MMU could map that virtual framebuffer space to two physical address regions (one in internal SRAM and the other in SDRAM) and the LCD Controller can handle this. Sounds like the trick would be in correctly setting up the MMU.

Chris