Index
> OS Construction > vga memory? |
| Author |
|
|
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
edfed wrote:
 |
|||
|
09 Nov 2010, 22:53 |
|
|
adroit 10 Nov 2010, 01:34
lol
Quote: 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: push 0A000h pop es or by setting an index register to 0A000h such as, bx, bp, di, si mov di,0A000h mov es,dii xor di,di you can now access any pixel on the screen by: [es:di] 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 di,319 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: where, 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 example: 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
Quote: (k * y) + x + y = offset position Calculations that you used are very weird. Try This.. Code: ;------------- ; 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 instead of Code: rol ax, 8 Code:
mov ah, al
or Code: 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
Code: 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
b1528932 wrote: 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). b1528932 wrote: 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 ...
http://technet.microsoft.com/en-us/library/bb490916.aspx Quote:
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
rugxulo,
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 > |
Forum Rules:
|