Message board for the users of flat assembler.
> OS Construction > vga memory?
b1528932 09 Nov 2010, 13:46
i do have few questions regarding display.
- when i write to a0000, i get the text mode. what code page is used to display code points?
- how do i access single pixel, (or multiple pixels if thats possible)?
|09 Nov 2010, 13:46||
edfed 09 Nov 2010, 16:41
in vga programming, you first need to set the mode.
the VGA memory is just memory, it contains only bits, not the way to represent them on the screen.
it means that you didn't set the correct mode.
text modes will see bytes as character + attributes
graphics modes will see bytes as pixels, and depending on graphic mode used, one byte can encode from 8 to 1 pixel.
the black and white uses one bit for a pixel, the 13h ode uses 8 bytes to encode the index of a color in the palette.
yeah, i know, it looks like eating an elephant, but as stated here, eat it piece by piece.
|09 Nov 2010, 16:41||
Tyler 09 Nov 2010, 22:53
The saying is "eat it byte by byte".
|09 Nov 2010, 22:53||
adroit 10 Nov 2010, 01:34
eat it byte by byte
I assume this is what you mean:
b1528932, to access a pixel first, you need to set the segment selector for graphics mode 13h (0A000h) into an extra segment such as es, fs or gs. But it's usually es
set es = 0A000h
remember, es cannot be accessed directly, so you can do either of the following:
by setting an index register to 0A000h such as, bx, bp, di, si
you can now access any pixel on the screen by:
es is 0A000h and di points to any pixel on the screen
basically, for every 320 values in the segment represent 1 line.
so if you want to access pixel 319 and put a colour there, you would write:
mov [es:di],0Fh ; puts white dot on screen
Lately, I thought about a formula to get the exact position on screen by using X and Y coordinates
the formula is:
k = 319
0 <= y <= 319
0 <= x <= 199
1. (k * y) x + y = offset position or
2. y(k + 1) + x = offset position
keep in mind for formula 2, that y is distributed over k and 1
k = 319
x = 21
y = 3
(k * y) + x + y = offset position
(319 * 3) + 21 + 3 = 981
982 is the black block in the grid.
If you have the time try counting it, you'll see it works.
I suppose thats what you mean by accessing a pixel
Last edited by adroit on 12 Nov 2010, 00:06; edited 1 time in total
|10 Nov 2010, 01:34||
DJ Mauretto 10 Nov 2010, 09:05
(k * y) + x + y = offset position
Calculations that you used are very weird.
;------------- ; Data ;------------- Y DW ? X DW ? Color DB ? ;------------- ; (320*y)+ x ;------------- @VGA_Mode_13H: PUSH 0A000H POP ES MOV DL,[Color] MOV CX,[X] MOV AX,[Y] ROL AX,8 MOV BX,AX ADD AX,CX SHR BX,2 ADD BX,AX MOV [ES:BX],DL ; Write Pixel RET
you can use
rol ax, 8
mov ah, al
shl ax, 8
Nil Volentibus Arduum
|10 Nov 2010, 09:05||
edfed 10 Nov 2010, 14:49
with 32 bit instruction set (the one that i think 99,9% of running x86 PC supports), you can do it in a lot less instructions
pixel13h: ;eax=X ;ebx=Y ;ecx=color ; can be used in that case as a 32bpp value (with alpha), ;and some seeker will find (or create) the closest entry in palette. ;but there it will just be used as 8 bit value ;edi will be the index in video memory lea edi,[ebx*4+ebx] shl edi,6 lea,edi,[edi+eax] push es word 0a000h pop es mov [es:edi],cl pop es ret
|10 Nov 2010, 14:49||
revolution 10 Nov 2010, 14:59
I think you are all focussed on the wrong thing to optimise.
In all probability, the CPU can compute the pixel addresses (with most of the methods posted here, even the slow ones) faster than the graphics memory can be updated. So the bottleneck is not your instruction selection, but the external hardware memory bus. Optimise for memory bus transfers, not coordinate computations. Use the cache first then transfer to video memory by use of a back buffer. etc.
Also: Get it working, then get it fast.
|10 Nov 2010, 14:59||
baldr 11 Nov 2010, 07:17
In text mode, characters' shapes are defined by contents of selected character maps (sequencer, index 3; memory map 2). Most VBIOSes load codepage 437 character generator there; I've seen samples with codepage 850; several (at least) videocontrollers support reflashing their VBIOS (so you can't count on it).
when i write to a0000, i get the text mode. what code page is used to display code points?
BTW, for standard text modes graphics controller (3CEh/3CFh) is programmed so buffer is mapped to 0B8000h…0BFFFFh (or 0B0000h…0B7FFFh for monochrome mode 7).
That depends on how videocontroller is programmed (chained/unchained memory mode, interlacing for 200-line modes and others). Read manual.
how do i access single pixel, (or multiple pixels if thats possible)?
|11 Nov 2010, 07:17||
edfed 11 Nov 2010, 19:41
the better i think is to just give you a link to some mode 13h demo.
click here to download mode13h life
|11 Nov 2010, 19:41||
rugxulo 12 Nov 2010, 16:34
Okay, this may not directly be what he was asking, but since it's already been mentioned ...
Codepage? Which one: hardware, system, or display?
For instance, I'm pretty sure you can't change text-mode fonts without EGA or VGA or above. But FreeDOS' DISPLAY.EXE (once prepared and selected) shows 8-bit text in (for example) CGA gfx mode 4 (if you use the BIOS, not sure about other methods).
|12 Nov 2010, 16:34||
baldr 13 Nov 2010, 11:17
Original MDA/CGA didn't support chargen loading; HGC and later did (even variant of CGA in ES-1840). I mean hardware support in text modes.
In graphics modes 4…6 int10 BIOS video output services support custom 8×8 character bitmaps for upper half of code page through int1F vector that points to 1 KiB of those 8-byte bitmaps for 80h…0FFh codes. EGA and later add support for lower half through int43 vector (8×14 and 8×16 chargens for full range are pointed by this vector too in corresponding graphics modes).
In one BIOS listing I saw code that tried to match those custom shapes to implement int10/08 service (read char/attr at cursor). Primitive OCR?!
|13 Nov 2010, 11:17||
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.