Member Avatar for BabiesGame

Hi i am intrested in learning assembly for the reasons of getting to desgine all the workings of my program, decide precisely all the binary code of it. I am stupped to find a book or some place that i can learn how to do graphics with assembly. I need to know a book that teachs how to do graphics in assembly and evverything, its hard to find i looked for months for a book still can't find out. If you could suggest one that in detail tells you how to do graphics, like make a little blue pixel appear on the screen or whatever.

Also on a side note what part of the memory is the realtime screen data stored, so the screen data displayed on the pc right now that you are seeing?

Thank you

Edited by BabiesGame because: n/a
  • 4 Contributors
  • 3 Replies
  • 1K Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by N1GHTS

Dani AI

Generated

OP wanted a practical way to “make a little blue pixel appear” and to know where screen data lives. The fastest, safest learning path is to pick a constrained environment where you actually control the video mode — an emulator or a small bare-metal kernel. Emulators such as Bochs or QEMU let you boot tiny real‑mode programs or kernels and experiment with video modes and framebuffers without risking real hardware. (bochs.sourceforge.io)

A minimal, hands‑on workflow (builds on ’ options): learn a simple assembler toolchain (NASM/FASM), run an emulator, set a simple graphics mode, then write into the linear framebuffer. Conceptually the pixel math is always: offset = x + y * width; write the appropriate color bytes at that offset (indexed modes use a palette index; chunky modes use packed RGB or 16/24/32‑bit formats). Example pseudocode:

; offs = x + y*width
mov eax, y
imul eax, width
add eax, x
; write 8-bit indexed color at framebuffer[offs]
mov [framebuffer + eax], bl

OSDev has clear tutorials on setting modes and drawing into a linear framebuffer. (wiki.osdev.org)

Caveats: modern Windows/Linux hide raw video memory behind drivers — direct writes normally require kernel code or the kernel framebuffer/DRM interfaces. On Linux the framebuffer device and the DRM/KMS APIs are the supported paths; for portable user‑mode work it’s far easier to call a library (SDL/OpenGL) from small assembly stubs or from C. See the kernel framebuffer and KMS docs and SDL references for those next steps. (kernel.org)

Recommended Answers

All 3 Replies

Member Avatar for gizerakos

VGA text memory is the part of the memory where your screen's data is stored.Manipulating its content is going to produce visual effects but the complexity of the procedure in case you have in mind modern graphics is huge,so you may need to look at a higher level.
A good place to start is the The Art of Assembly Language Programming by Randall Hyde.

Member Avatar for Ancient Dragon

>>Also on a side note what part of the memory is the realtime screen data stored

Depends on what operating system you are talking about. MS-DOS Version 6.X and older was stored at address 0x8000:0000, and graphics memory at 0xA000:0000 (or something like that, I'm recalling from over 20 years ago). Screen memory for modern operating systems such as MS-Windows and *nix is not at any fixed location, your program has to call os-specific functions to address screen and graphics. And modern graphics so complex that no one in his/her right mind would try to do it in pure assembly.

Edited by Ancient Dragon because: n/a
Member Avatar for N1GHTS

Here are a few approaches to your described problem:

1. Write a program in assembly that uses Operating System API facilities or Graphic libraries to draw to the screen (As Ancient Dragon described)

2. Write a program in assembly that writes directly to the monitor by writing directly to video resources via control of the video chipset interrupts. You may also accomplish this by hijacking the operating system's control of the video chipset driver and work directly with the driver.

3. Write an embedded or system program (no existing operating system) that controls the entire system resources including the video device.

4. Bypass the video chipset and write firmware code in assembly to control a video display. This would give you complete control of the video device's inner workings.

About 99% of assembly programmers would use option 1. Unless you have a good reason for reinventing the wheel, pick any of my other options. Like all high level languages, Assembly can work with any operating system and work with high level libraries such as OpenGL and DirectX. This is highly recommended for advanced and portable graphics application programming.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.