DEV Community: William

Guide to VBE graphics in x86

William — Sun, 27 Jul 2025 19:25:29 +0000

Preface 📘

This should act as your complete guide to implementing and understanding VBE graphics in x86 assembly, if you are unfamiliar with BIOS programming I recommend my article about making pong (https://dev.to/willy1948/making-pong-in-x86-assembly-11li). So, what is VBE graphics? VBE (VESA bios extension) graphics is a standard that aims to improve upon VGA graphics which was created by IBM. What are the benefits of using VBE graphics? Well, the biggest benefit is the improvement in screen resolution. VGA at best gives you 320x200 whereas using VBE one can have up to 1280x1024. It's not just the resolution, but in certain video you can have up to 255^3 colours, compare that to just 255 for VGA. If you are looking to make a OS or just a bootloader game you should definitely consider using VBE graphics.

  ／＞　 フ
  | 　_　_| 
／` ミ＿xノ 
/　　　　 |
/　 ヽ　　 ﾉ
│　　|　|　|
／￣|　　 |　|
(￣ヽ＿_ヽ_)__)

Setting the video mode 🎛️

We need to tell BIOS that we want to use VBE graphics. luckily there exists an interrupt that we can call with specific arguments to do this. Using int 0x10 with ax set to 0x4f02 and bx used to specify the video mode, (https://en.wikipedia.org/wiki/INT_10H).

mov ax, 0x4f02 ; code to set video mode
mov bx, 0x4118 ; specifies video + flags
int 0x10
cmp ax, 0x4f ;Check if video mode is supported by hardware
je  .successLabel

To understand what the cmp line does we can look at the VBE specification document (https://pdos.csail.mit.edu/6.828/2011/readings/hardware/vbe3.pdf).

We want to check if the video mode in bx is supported and therefore we check to see if ax is 0x4f. I mentioned earlier that bx stores the mode, this is partly true but it also stores flags which specify certain behaviours.

It is a bit confusing but D means bit number. Breaking down 0x4118 into binary we get 0b|0|1|00|0|00|1|00011000| (I used | character to separate the different sections). Moving from left to right the sections are defined as follows:

0=clear display, 1=preserve display. This means weather or not what is in video memory will be cleared to black. Majority of the time it makes sense to clear the display when switching modes. Hence why the first bit is 0.
0=Use banked frame buffer, 1=linear frame buffer. The reason this exists is because with 16 bits one can only address so much memory, even with segment offsets. Video memory could need up to 1280x1024x3 = 3,932,160 bytes, which is greater than 64kb. To get around this issue video card manufactures split up memory in banks. Only one bank exists in memory at one time and one can switch to a particular bank through a BIOS call. Linear frame buffer is where the frame buffer is just stored as normal in memory. Because I am going to use 32 bit registers (this can be done in real mode), I am going to use a linear buffer. If you are developing for 16-bit retro hardware then you would need to set this bit to 0.
Must be 0
0=Uses BIOS default refresh rate, 1=Use user specified CRTC (Cathode ray tube controller). You may think, well, I'm not using a CRT monitor. But you still specify values through the CRTC to control your up to date monitor. Using BIOS defaults will be fine. If you do want to specify the refresh rate, I believe you specify a pointer in ES:DI to a CRTC information struct.
Should be 0
0=mode specifies VGA mode, 1=mode specifies super VGA mode. This should be set to 1 because we want access to higher resolutions that are available only in super VGA (super VGA is VBE).
Specifies the video mode: Entry one has mode number of 0 and so on, this is a little unclear from the table. 7 bit mode number means that the 8th bit(zero indexed) is set to 0.

Great, using this information you should be able to run your program and it should show a bigger window than before. There are still some problems we need to fix. Firstly we don't know important information like where video memory is, and secondly we do not have enough address lines to write into all of video memory. Lets take a look at how to solve these issues.

Finding video memory 💾

We can call a function that will give us all the information we need about the current mode. It takes a pointer to a struct and fills in all the information.

mov ax, 0x4F01       ; VBE function 01h which returns mode info
; mode number (remember to include the 8th bit)
; cx is mode 5 with 8th bit set because we are using super VGA
mov cx, 0x105        
mov di, video_info   ; pointer to structure
int 0x10

Next we need to define the structure

That's a bit of a pain to write out by hand so here is a text version with labels for the important attributes.

video_info:
    dw 0h     ; ModeAttributes found on page 40 of VBE spec pdf
    db 0h             ; WinAAttributes
    db 0h             ; WinBAttributes
    dw 0h             ; WinGranularity
    dw 0h             ; WinSize
    dw 0h             ; WinASegment
    dw 0h             ; WinBSegment
    dd 0h             ; WinFuncPtr
video_bytesPerScanLine: dw 0h ; BytesPerScanLine
    dw 0h             ; XResolution
    dw 0h             ; YResolution
    db 0h             ; XCharSize
    db 0h             ; YCharSize
    db 0h            ; NumberOfPlanes
    db 0h              ; BitsPerPixel
    db 0h             ; NumberOfBanks
    db 0h             ; MemoryModel
    db 0h             ; BankSize
    db 0h             ; NumberOfImagePages
    db 0h             ; Reserved1
    db 0h             ; RedMaskSize
    db 0h             ; RedFieldPosition
    db 0h             ; GreenMaskSize
    db 0h             ; GreenFieldPosition
    db 0h             ; BlueMaskSize
    db 0h             ; BlueFieldPosition
    db 0h             ; RsvdMaskSize
    db 0h             ; RsvdFieldPosition
    db 0h             ; DirectColorModeInfo
video_address: dd 0h      ; PhysBasePtr
    dd 0h             ; OffScreenMemOffset
    dw 0h             ; OffScreenMemSize
    times 206 db 0h

The video address label stores the pointer to the first pixel.

Accessing more memory🚀

When the computer boots in real mode only 20 address lines are usable. This means we can only address 2^20=1MB of memory. This is not good enough, say if we want to use video mode 0x11B which is 1280x1024 with 3 colour channels, we would need about 4MB of memory just to access all of video memory. To fix this we can do something called enabling the A20 line. This doesn't just give us one more address line, which still wouldn't be enough, but it gives us access to all available address lines, circa 32 probably. This means we can now address up to 4GB of RAM.

Great, so how do I enable the A20 line? Most BIOS's provide a fast and simple way of doing this by setting some port signals. In fact some BIOS's come with the A20 lines enabled on boot, but this is not always the case so we better make sure.

in al, 0x92
or al, 2
out 0x92, al    
;A20 lines now enabled

Drawing pixels 🎨

Jolly good, now we can start drawing pixels to the screen.

mov edi, dword[video_address]
add edi, 5; determins the x cord of the pixel / bytes per pixel
mov al, 0x4
mov byte[edi], al

Depending on the resolution of the video mode you choose, you may find it difficult to see the pixel because it is so small. Here's some code that should set all the pixels on screen.

mov ecx, dword[video_address]
;set this to the number of pixels for your chosen video mode
mov edx, 1280*1024*3;resolution X * resolution Y * bytes per pix
add edx, ecx    
;edx is now the end value for the loop
;ecx being the start
.loopHead:
        ;set the colour the counter for more interesting display
        mov al, cl
    mov byte[ecx], al
        inc ecx ; move onto next pixel
    cmp ecx, edx
    jle .loopHead
jmp $ ; infinate loop, $ means address of current instruction

Now you have all the tools you need to create something awesome.

Going further 🧭

I decided to draw the hello world of images, Lena. It took me a little while to get it working but in the end I managed it.

The pixelated effect is due to my code not a limitation of VBE.

This just leaves one question. What are you going to do with this knowledge? Let me know in the comments below. Perhaps coding a game, or maybe adding nicer graphics for your kernel.

Wrapping up 🎁

I have produced a GitHub repo to pair with this tutorial so if you want to look at sections in more detail head to (https://github.com/asdf-a11/VBE_Tutorial). If you have any questions make sure to leave them in the comments below. If you have enjoyed this article then make sure to check out my other articles, I think they'll be of interest to you. Have a great day!

Learn any Language Faster with One Click

William — Sat, 26 Jul 2025 15:37:04 +0000

Have you ever wished that you could learn a new language just by browsing the web? Well I know I have. About a year ago I decided that I wanted to learn Russian. Learning a new language is a slow process, so being able to spend time constantly working towards this goal is critical. However once the novelty of embarking on a new hobby wore off I found it harder and harder to engage and enjoy what I was reading, children stories just aren't that entertaining. This lead to me thinking, I wish I could engage with Russian the same way I do English every day. And this is where I decided to create Lingo Journey, a Chrome extension designed to help people learn a new language. If Language learning is all about immersion, then what better way to achieve this than surfing the web entirely in your new language. I wanted the ability to read news articles and watch YouTube videos all in my target language.
Here are some images showing Lingo Journey in action.

For those who are familiar with LingQ it works somewhat similarly. Words are highlighted different colours depending on their learning status. You have the ability to click on words creating a popup window displaying translations, the learning status and other information.

This window remembers where you placed it so you can position it wherever you want and every time you click on a word it will popup and show translations. It can highlight words in the subtitles as you watch the video. Being able to use YouTube to learn a new language opens up so many opportunities.

If that sounds good to you then I strongly recommend taking a look at installing Lingo Journey here (https://chromewebstore.google.com/detail/lingo-journey/hkkghimlnkomhmnndmnnidbpilokcaeo). If you are curious you can find the source code on GitHub here (https://github.com/asdf-a11/LingoJourney).

Paid translations. Lingo Journey provides free translations which should be good for beginners but as you progress you may find words that don't have translations, I suggest getting the complete translation list from my patron (https://patreon.com/LingoJourney and then in the shop tab). It costs barely more than one month of LingQ but you keep it forever, sounds like a good deal to me.

What's next. I think my main focus is to support more languages, German, French and Spanish just to name a few. So far I have been solo testing this project and developing for my own needs, but I am excited to see what other make of it and implement any feedback.

Lastly if you have any thoughts or questions you wish to share I would love to hear about them in the comments.

Making Pong in x86 Assembly

William — Thu, 24 Jul 2025 18:37:55 +0000

Introduction 📘

So many developers won't have even touched assembly language let alone decide to write a whole program in it. This is understandable, reasons to write assembly are few and far between. However the knowledge you gain from doing as such can help build a deeper understanding of how computers function helping you write better more efficient code even in other programming languages.

So to start off lets take a look at what "x86 Assembly" actually means. Assembly code is device specific meaning code that runs one one machine might not work on another. This is because CPUs can have different architecture and therefore expect different instructions. Each architecture will have a certain set of instructions that the CPU is designed to use. Here we are using the x86 architecture which is what majority of laptops and desktops use. ARM and RISCV are the other two major ones. Whilst your code might not run on a different architecture the knowledge you gain from learning one variant of assembly will easily transfer to any other variant.

Boot loaders 🧰

A common use of assembly is writing bootloader games. These were popular 40 or so years ago where memory was expensive and so compacting a game into the 512 byte boot segment was a popular and challenging thing to do. It was the first segment that is loaded into memory when the computer boots, and is the first to starts running.

I decided to set myself this challenge of writing pong in assembly from the bootloader. I gave myself one allowance: the ability to utilize additional memory segments beyond the strict 512-byte boot sector. This is critical if I want to implement a font which requires lots of space to store. Here are some of the most interesting parts of this project.

One thing that you might not have expected is the fact that when booting computers are in 16 bit mode, even if it is a 64 bit processor. This may seem strange, and it is, but the reason for it is to keep backwards compatibility with older software whilst computers were still making the transition from 16 bit to 32 bit. This isn't the only weird thing about booting. For some reason the boot sector is loaded in the hex address 0x7c00. One would naturally expect it to be address 0, but no. The reason for this is that BIOS (code that boots the bootloader and does other stuff) can use values in the lower address space and overwriting that would be bad. So before any code is written it is important to have the two lines

[bits 16];tells the assembler this code is for 16 bit mode
[org 0x7c00];tells the assembler where the code is located in RAM

16 bit instructions are different to 32 bit instructions and therefore we need to tell the assembler to generate the 16 bit machine code not 32 bit. [org 0x7c00] is important so that the assembler can correctly calculate the address of our labels and data. This is because in assembly instead of using if, while, for you use labels. These are just flags that don't actually exist but the assembler knows there byte position in the machine code and you can tell the CPU to jump to them e.g

someLabel:
jmp someLable

creating an infinite loop. This links back to [org 0x7c00] if we don't tell the assembler the starting address of our labels it will miscalculate their positions. This means that jmp someLabel will send execution to completely the wrong place in memory, which is no bueno.

Right, now the assembler knows what its doing, lets take a look at the next vital part of our program.

[bits 16]
[org 0x7c00]
jmp main; Jump over variables to not execute as instructions
BOOT_DISK: db 0; Stores boot device ID
main:
  ;Stack grows downwards from the bootloader
  mov bp, 0x7c00
  mov sp, bp
  ;Save the boot device for loading the later segments
  mov byte[BOOT_DISK], dl

One of the first things we need to do is set up the stack. If you have programmed in C or C++ you may be familiar with what the stack is, but if not. The stack is data structure in computer science where you can only add or remove an item from the top but you can read from any where on the stack. This is how the majority of data is stored in a computer program, there is something else called the heap. This can be used for say, lists that can change dynamically in size during run time, but we don't need to worry about that for this project. However there is a problem to solve. After a function has been called and during which variables have been added to the stack, when that function returns how do we know how to restore the stack i.e remove all the data that was previously pushed whilst the function was running? To solve this we break the stack into sections called stack frames. A stack frame is created every time a function is called, and when it is created it pushes the address of the previous stack frame onto the stack. This means when climbing up the stack it can set bp = sp then read of the stack the new value for sp, returning the stack to it's state before the function call.

All we need to implement a stack is a value to store the address of the start of the stack and a value to store the address of the previse stack frame. Luckily for us, x86 architecture comes with two registers designed just for that. The names of the two registers are sp and bp, standing for stack pointer and base pointer. Stack pointer points to the previse stack frame and the base pointer to the bottom of the stack. You may think that to set up the stack you should do something like

mov bp, 0
mov sp, 0

setting their address to begging of memory seems sensible right? Wrong! The slightly unintuitive thing about stacks are that they grow downwards, each subsequent item added is at a lower memory address. That is why the following code works.

mov bp, 0x7c00; setting to the top of the stack
mov sp, bp; no previse stack frame so just set it to bp

Whilst the memory segments containing our program are loaded into higher addresses, the stack will use lower address. Understanding memory and therefore stacks is a really important part of righting good efficient programs in any language.

The BIOS will only load the boot sector, so it is our job to do the rest. We need to load the next, how ever many pages (512 bytes) of memory. This is the reason for the line.

mov byte[BOOT_DISK], dl

Upon boot the 8 bit id of the storage device that was used to boot from, is moved into the lower half of the 16 bit dx register, hence dl (data lower). We need to make a copy of this value so we know which device to read the remaining sectors off of. One of the great things about being in 16 bit mode is that we have access to BIOS routines, this is not the case in 32 bit / 64 bit mode because the processor uses different methods for managing memory which makes the code incompatible (16 bit mode uses segmentation, 64 bit mode uses paging and 32 bit mode uses a combination of paging and segmentation). To call these routines all you have to do is call the int instruction, short for interrupt, with some code which relates to some routine. So to read in the next segments from memory all we have to do is.

readDisk:
mov ah, 0x02; Specifies BIOS function: "Read sectors from disk"
mov bx, PROGRAM_SPACE ; ES:BX = destination address in memory to load the data
mov al, [BOOT_DISK_READ_SIZE] ; AL = number of sectors to read (each sector is 512 bytes)
mov dl, [BOOT_DISK] ; DL = BIOS drive number (e.g., 0x00 for floppy, 0x80 for HDD)
mov ch, 0x00 ; CH = cylinder number (part of the CHS address), here it's 0
mov dh, 0x00 ; DH = head number, starting at head 0
mov cl, 0x02 ;CL = sector number (sectors start at 1; this means sector 2)

int 0x13 ; BIOS disk hindering function — executes the read based on register setup
jc .errorCode ;carry flag is set if error occurs
ret ; returns from function back to callee
.errorCode:
    mov bx, diskReadErrMsg; bx is pointer to string
    call print; takes bx as argument
    jmp $; $ means current address therefore infinite loop

There is one small part of this code that you might not be able to understand just yet, and that is ES:BX. This simply means BX offset by ES. More precisely it translates to BX + ES * 16. Because this program is small we don't need to write into the higher address spaces so ES and all other segment registers are set to zero at the start by the bootloader.

This raps up all the functionality that we need from the bootloader. All we need to do now is call the readDisk function then jump to the loaded segments.

call readDisk
jmp 0x7e00; = 0x7c00 + 512

You may be wondering why the code jumps to the new segments and doesn't just run from the boot sector into the new segments. That would save space right? Well this is partially true but there is a special two bytes called the boot signature, 0xaa55. Located at the end of the boot sector which is mandatory. As our code grows we don't want it to overwrite these two bytes. So it is just simpler to jump over them and execute in the new segments.

Graphics 🎨

I think the most interesting part of this project is the graphics. I mean, what is a game without graphics, right? Luckily for use we can get graphics working within a few lines of code just by using in-built interrupts.

mov ax, 0x13 ; VGA mode 0x13
int 0x10 ; Sets the graphics mode based on ax

VGA mode 13 gives us a colour pallet size of 255 and a resolution of 320 x 200. A list of what int 0x10 can do can be found here (https://en.wikipedia.org/wiki/INT_10H). This is great, but now we need to be able to draw to the screen. There are two ways to do this, using interrupts and writing directly to memory. Using interrupts is simple, but at the cost of performance. The second option of writing directly to memory at a certain address where the graphics card will read from is much faster. This special place is at address 0xA0000 (not the same for all video modes), you may think, hang on this is bigger than 16 bit register can address, do we need to use segment registers? You would be right that is a valid way, but the strange thing is, in 16 bit mode we are still free to use 32 bit registers (not the case for 64 bit registers). To write to the first pixel on the screen (top left) all we need to do is.

mov eax, 0xA0000; eax is 32 bit version of ax
mov byte[eax], 200

200 represents the 200th colour in the VGA 13h colour pallet. This is very simple and very fast. Building upon this to draw text is easy. All we need to do is have a way to draw pictures, this can be done with two loops like so.

drawImg_f: ; eax = ptr edi = xpos esi = ypos
    pushad; pushes all resgisters to the stack
    push eax; stored because mul uses eax
        mov eax, SX; SX=screen size x = 320
        mul esi; = SX * ypos
        add edi, eax; xpos + SX * ypos
        add edi, BM; xpos + SX * ypos + buf offset
    pop eax; restore to value
    ;esi ecx x,y respectivly
    xor ecx, ecx; quicker than mov ecx, 0
        ; I chose to store the sizex and sizey before the start
        ; of the image therefore need to jump over both 4 bytes
    mov ebx, 8
    .loopY:
        mov edx, dword[eax+4]; get size y
        cmp ecx, edx
        jge .endLoopY

        xor esi, esi
        .loopX:
            mov edx, dword[eax]; get size x
            cmp esi, edx
            jge .endLoopX

            push eax        
                mov al, byte[eax+ebx]
                mov byte[edi], al
            pop eax

            inc esi 
            inc edi
            inc ebx
            jmp .loopX
        .endLoopX:

        add edi, SX
        sub edi, dword[eax]
        inc ecx
        jmp .loopY
    .endLoopY:  
    popad; pops all registers from the stack
    ret

Now all we need to do is add the images to our code. We want to have a way of getting the location of each numerical character so we can render it. To do this we can use labels and have the NASM pre-processor set them for use

%assign i 0 ; what number the font reprisents
%rep 10 ; set all 0-9 characters
Font%[i]: ; defines the label we can use later
        ;Gets the bin file from folder Font
    %defstr myString Font\\%[i].bin
        ;Short for include binary
    incbin myString
        ; incriments the number counter
    %assign i i+1
%endrep

Now Font0 is represents the address of the 0 character image and so on. This is all well and good, but image editors don't just output the plain image data. There is almost always some sort of compression going on. To get the plain data we can use a python script to help us.

import sys
from PIL import Image
import numpy
import numpy as np
#Takes in images names as arguments when program is launched
for i in range(1,len(sys.argv)):
    pic = Image.open(sys.argv[i])#Understands png format
    pix = numpy.array(pic.getdata(),numpy.ubyte)
    name = sys.argv[i]
    #Remove the .png from the end of the file name
    name = name[:-4]
    f = open(name+".bin","wb")
    #Writes image dimension each 4 bytes
    f.write(bytes(np.array([pic.size[0],pic.size[1]],np.uint)))
    #Writes the image data .flatten() means make it one 
    #dimentional list
    f.write(bytes(pix.flatten()))
    f.close()

All together it yields:
(https://github.com/asdf-a11/Pong_Boot_Sector/blob/main/README_Images/Animation.gif). I don't believe one can upload a gif, so here it is hosted in the repo.

This has been a quick overview into getting started with x86 assembly. I hope you found it engaging, any questions leave them in the comment section. If you would like to learn more, here is the link to my GitHub repo (https://github.com/asdf-a11/Pong_Boot_Sector/).

Common Bugs 🐛

Lastly for those who would like to get started with assembly bootloader shenanigans, I would like to help you avoid some of the pitfalls I fell in whilst I was learning. The first being, include special data at the start of you bootloader.

    jmp main ; dont want to execute this table by accident
    TIMES 3-($-$$) DB 0x90 
    OEMname: db    "mkfs.fat"
    bytesPerSector:    dw    512
    sectPerCluster:    db    1
    reservedSectors:   dw    1
    numFAT:            db    2
    numRootDirEntries: dw    224
    numSectors:        dw    2880
    mediaType:         db    0xf0
    numFATsectors:     dw    9
    sectorsPerTrack:   dw    18
    numHeads:          dw    2
    numHiddenSectors:  dd    0
    numSectorsHuge:    dd    0
    driveNum:          db    0
    reserved:          db    0
    signature:         db    0x29
    volumeID:          dd    0x2d7e5a1a
    volumeLabel:       db    "NO NAME    "
    fileSysType:       db    "FAT12   "

You may notice that your code runs in a emulator but not on real hardware. If you don't have this at the very start of your bootloader, that might be the problem. I don't know exactly what it does but make sure to include it. Another thing to be aware of is making sure the processor is in a known state. When booting registers and settings could be anything, make sure to set their values. For example at the start of my bootloader I do

;Dont need to use segment registers so sell them to 0
mov ax, 0x00
mov es, ax
mov ss, ax
mov ds, ax
;set the direction flag, it is used for certain string related
;instructions
cld

If you are using the FPU (floating point processing unit) then make sure you add fninit, this sets the FPU to a default state.