CODEWITHSUNDEEP
assemblyx86x86-16osdevreal-mode
MaoKo
MaoKo

Reputation: 23

Why I read 0H after a character write in vga graphic mode?

In real mode (or virtual 8086), when I switch to the vga graphic mode (00DH, 00EH, 012H) and I use the BIOS function to display a character (int 00AH, int 00EH), nothing can be read from 0xA0000 except a bunch of zero. The character is indeed displayed on the screen but it's not apparent from memory. Everything work fine with text mode (1H, 3H, ...) although.

format binary
use16
org 07C00H

_TELETYPE_GRAPHIC_40x25 = 00DH
_TELETYPE_GRAPHIC_80x25 = 00EH
_TELETYPE_GRAPHIC_80x30 = 012H

cli

mov ax, _TELETYPE_GRAPHIC_80x30
int 010H

mov ax, 00E41H
mov bx, 2H
int 010H

mov bx, 0A000H
mov es, bx
xor di, di
xor ax, ax
mov cx, 04000H
cld
rep scasb
jz _always
hlt
jmp $-1H
_always:
; ...

Upvotes: 1

Views: 290

Answers (2)

MaoKo
MaoKo

Reputation: 23

Thank you. This is because, I did not understand what planar graphic trully mean :). This code work fine, when I select the plane 2:

mov ax, 00DH
int 010H

mov dx, 3CEH
mov al, 4H
out dx, al
mov dx, 3CFH
mov al, 1H
out dx, al

mov ax, 00A41H
mov bx, 2H
mov cx, 2H
int 010H

; I can read now pixel value from 00A0000H

In fact, I want to implement several tty (tty1,...,tty8) and for that I use virtual 8086 and paging. And several tty can be in different mode in the same time. My original idea is when a ring=3 program wan to write to a tty that is not the current one, I change the page table to redirect the video ram to the internal tty regen buffer. For example in bochs when the current tty is in resolution 12H and a user want to write to the tty2 which has the resolution 3H it's use this mapping:

0x0000000000000000-0x000000000009ffff -> 0x000000000000-0x00000009ffff
0x00000000000a0000-0x00000000000b7fff -> 0x000000010000-0x000000027fff ; trick to avoid to clear the vram when chaning mode
0x00000000000b8000-0x00000000000bbfff -> 0x00000021c000-0x00000021ffff ; regen internal buffer
0x00000000000bc000-0x00000000000bffff -> 0x00000002c000-0x00000002ffff
0x00000000000c0000-0x000000000011ffff -> 0x0000000c0000-0x00000011ffff

Upvotes: 1

vitsoft
vitsoft

Reputation: 5775

I tried to read videomemory in graphic mode 13h (320*200px) with TurboDebugger in DOSBox on 64bit Windows and it worked as expected: REPE SCASB stopped with DI=0143h and the value loaded by
MOV AL,[ES:DI-1] was 2.
The first pixel line at ES:0 (140h bytes) is all 0 (black), the second line starts at ES:0140h with two black pixels (0 bytes), followed by the byte with value AL=2 (blue), which is the tip of capital letter A glyph.

However the videomemory cannot be inspected using Alt-F5 to switch between TurboDebugger user-screen and CPU window) due to imperfection of debugger and DOSBox emulation. The situation is even more complicated with planar graphic modes 0Dh, 0Eh, 12h. VGA maps all four memory planes (pages) at the same linear address A0000h and you would have to select the page first by direct output to CRT ports (see the link in @fuz first comment). You may want to load the nonzero byte from videoram and print it with INT 10h instead of hlt, just to assure that it's there.

I remember how I debugged my graphic program some 30 years ago with two DOS computers connected by serial ports, using Borland TD.EXE and TDREMOTE.EXE. I was able to step through instructions which wrote to EGA/VGA CRT registers and to watch the effects without having to switch between debugger window and user screen.

I'm not sure what do you want to achieve but in nonemulated DOS with graphic mode 13h you might succeed.

Upvotes: 4

Related Questions