how to convert long pointer into char pointer ..type casting is not working .or tell me how to change video memory.. i cannot initialise char pointer variable to 0xb8000000

Output:


I don't know why you can not initialize the pointer to the address that you seek. However, depending on your operating system and/or hardware, you may not be able to dereference the pointer due to protected addressing.


Output:



:davis:

thanks davis.....
there is one more problem... initialising vdu memory is not possible in cpp ide.......

...and WHY do you think that that is? Consider what would happen to the video display if 100 user applications decided that they all wanted to write something to the display memory at the same time. That is one reason why modern operating systems protect addresses and do not allow user-space processes to directly access memory. Many operating systems employ a virtualization of the physical memory such that one's process can not directly address physical memory. In order to write to "vdu" memory, you must perform a system call that maps that memory (or a portion of it) into your process space IF such is provided for by your system.

Most drivers on modern systems have a need to be the only body of code that is interacting directly with the device. For this reason, the design of the system usually requires the driver(s) to be "installed" in the system. The driver model for the particular system will dictate some system-level interactions required for the driver and the operating system kernel to coexist harmoniously and thusly, be "installable."

So when you say: "initialising vdu memory is not possible in cpp ide"
...you simply have no clue, because I've written numerous drivers, including "vdu," using a "cpp ide." If you're interested in accessing protected address spaces, you will want to familiarize yourself with your operating system driver requirements and any related support libraries for it. For most modern operating systems, drivers are often "loadable" by a dynamic means. In the case of "vdu" drivers, they are usually "installed" but not "loaded" until the next reboot at which time you're given the opportunity to hose the system with your handiwork. For this reason, modern operating systems generally have some sort of fail-safe mode that allows you to go in and restore a previous driver or re/install a different driver to reattempt starting the system.

You may find it interesting to read a book on operating system fundamentals, as they are unavoidable when discussing C and/or C++ programming at the system level. Additionally, while there are a number of similarities between driver models of various platforms, each system tends to have some very specific requirements for the drivers in the system. Even in the same system, different drivers are often handled very differently depending on what kind of device they service. You'd do well by studying the driver model and any applicable driver development kit for your target platform.

One more thing on this topic, your test environment should be a suitable machine that you do not mind hosing, perhaps even extensively. In several hundred drivers that I've written, I don't think that I've ever written a single one that didn't crash, hang or at least dramatically affect the system during development. While it is not as probably, it is certainly possible in some cases to literally toast the system or some of its components during driver development. Which brings up debugging drivers. If you do not have an adequate debugging environment, you may never get a driver to work properly.


:davis: