OT: Visual memory program

what memory, what BMP ?

-Lasse

None!

Did that once, made a graphics renderer of historic interest; added a top level variable for starting address and sent that to the texturing subroutine instead of the normal image buffer addresses. Certain things down in the BIOS/DOS area (~700h) are always blinking and incrementing; program data looks patchy to random; and reading video RAM sometimes gives weird feedback effects (since each frame depends on the previous and so on, and the format is different).

But that's 8086 architecture, too. If you meant today, uh... have fun with that.

There is debugging and memory viewing / hacking / dumping software (literally, MHS), which allows you to operate on the memory space of a particular process. Maybe anything in userspace. But certainly not system memory, not without a kernel hack.

Tim

Den torsdag den 24. juli 2014 00.33.25 UTC+2 skrev Tim Williams:

on linux just open /dev/mem and mmap, you'll have to be root ofcourse

-Lasse

-Lasse

Is there an equivalent for Windows, a way for a user program to address physical memory?

Den torsdag den 24. juli 2014 01.41.44 UTC+2 skrev John Larkin:

afaik not with out a kernel driver

-Lasse

Memory in your computer, silly. BMP is a particular image format, being used here as a reference...

Would you please clarify on that? ;)

Wow! Am !extremely! interested in that program of yours. Is it available?

-- snipped due to aioe limits --

Have same Q.

Well, I didn't understand what memory you were talking about, or the operating context.

What's a BMP? Why is it backwards?

A Bitmap is an image format with a header specifying its length, offset, format and so on, followed by a palette array (if relevant), followed by an image array. The image is simply a linear X x Y buffer (give or take some rounding at the right edge on

Oh, that BMP. 'BMP' stands for dozens of different things.

How would one map the contents of computer memory into a bmp file? Would the result have visual meaning?

You'd think it might be better to dump memory into a pure binary file.

Stick a suitable BMP header on the front and decide how you want to interpret it. I'd suggest indexed byte representation with peano-koch false colour curve, spectrum or greyscale colour mapping as a start.

It doesn't make any sense at all to map it to RGB.

You can even map an in memory BMP/DIB onto any output device. The main problem being that unless your display has at least one pixel per byte you will get rather meaningless averages - 6M displays are available. This is a bit of a limitation with PCs now having >8GB ram!

Depends what he is trying to do. I am guessing watching some array of sensors incoming raw data in realtime as a bunch of pixels. I have done something similar myself in the past but as a log/lin histogram display.

Regards, Martin

In a virtual-memory system, like Windowses since 3.1 and Linux, there is little to be gained from visualizing real memory (the chips), as the program pages and data are being paged in and out of real memory.

For memory-mapped I/O, there may be some sense, and the older directly accessed video adapters did just that.

I'd like to be able to directly address big chunks of the PCIe address space. In Linux, that's easy with dev_mem.

That was meant to e a joke; "none" _is_ rather specific and gives no wiggle room. The OS is not relevant; looking at memory contents in a visual manner gives patterns according to what is there / running. The BMP spec is backwards, in that it starts with the end of the picture and scans up.

Check; "bottom to top" i see as backwards.

I would assume so. JFGI. Only way I've seen it is providing state monitoring in emulators (which I guess don't usually have debugging internals). Example: locking the correct memory addresses to specific values achieves the same result as a Game Genie did, way back in the day.

Tim