Difference between revisions of "Output"
(adding alternative pixel set approach, "LES" trick into PSP section, logical tricks)
m (→Outputting in mode 13h (320x200))
|Line 104:||Line 104:|
Revision as of 13:59, 12 August 2016
Outputting to the screen
First, be aware of the MSDOS memory layout
Outputting in Textmode (80x25)
Right after the start of your program you are in mode 3, that is 80x25 in 16 colors.
See the Video Modes List
So, to show something on the screen, you would need to set a segment register to 0xB800, then write values into this segment.
The following three snippets showcase how to draw a red smiley in three different ways. The target coordinate (40,12) is about the middle of the screen. We need a multiplier 2 since one char needs two bytes in memory (char and color is a byte each). The high byte 0x04 means red (4) on black (0) while the 0x01 is the first ASCII char - a smiley.
push 0xb800 pop ds mov bx,(80*12+40)*2 mov ax, 0x0401 mov [bx],ax ret
push 0xb800 pop es mov di,(80*12+40)*2 mov ax, 0x0401 stosw ret
push ss push 0xb800 pop ss mov sp,(80*12+40)*2 mov ax, 0x0401 push ax pop ss int 0x20
You might notice that the push <word> + pop seg_reg combination is always the same and occupies four bytes alltogether. If correct alignment is not important to you and you really just want any pointer to the screen, there is another way to get a valid one:
les bx,[si] nop stosb
That's also four bytes, but it already has the stosb opcode (for putting something onto the screen) integrated and even one slot free for another one-byte-instruction. It works because SI initially points to the start of our code, and stosb has the hexadecimal representation of 0xAA. After the first command, the segment register ES contains the value 0xAB90. If you repeatedly write something to the screen with stosb you will eventually reach the 0xB800 segment and chars will appear on the screen. With a careful selection of the free one-byte-opcode you can also reintroduce some alignment. This works also with the stosw opcode (0xAB).
Outputting in mode 13h (320x200)
The videomemory for mode 13h is located at segment 0xA000, so you need to assign this value to a segment register. Also, after the start of your program you are normally still in textmode, so you need to switch to the videomode. The following snippet does both:
mov al,0x13 int 0x10 ; AH = 0 means : set video mode to AL = 0x13 (320 x 200 pixels in 256 colors) push 0xA000 ; put value on the stack pop es ; pop the stack into segment register ES
You're free to use any of the segment register / opcode combinations to write to the screen
- ES / stosb
- DS / mov
- SS / push
Let's add some code that actually draws something on the screen, the following program occupies 23 bytes and draws a fullscreen XOR texture
mov al,0x13 int 0x10 push 0xa000 pop es X: cwd ; "clear" DX (if AH < 0x7F) mov ax,di ; get screen position into AX mov bx,320 ; get screen width into BX div bx ; divide, to get row and column xor ax,dx ; the famous XOR pattern and al,32+8 ; a more interesting variation of it stosb ; finally, draw to the screen jmp short X ; rinse and repeat
Note that there is a different way of preparing the segment register, instead of :
push 0xa000 pop es
you can also do :
mov ah,0xA0 mov es,ax
both variations occupy 4 bytes, but the latter is executable on processor architectures where push <word> is not available.
Now let's optimize on the snippet. First, we can adapt the "LES" trick from the textmode section. We just exchange
push 0xa000 pop es
to save two bytes. This works because BX is 0x0000 at start and thus, accesses the region before our code, which is called Program Segment Prefix. The two bytes that are put into the segment register ES are bytes 2 and 3 = "Segment of the first byte beyond the memory allocated to the program" which is usually 0x9FFF. That is just off by one to our desired 0xA000. Unfortunately that means a 16 pixel offset, so if screen alignment means something to you, you can't use this optimization. Also, said two bytes are not always 0x9FFF, for example if resident programs are above the "memory allocated to the program" (FreeDos) their content is overwritten if we take their base as our video memory base.
Second, we can use an alternative way of putting pixels to the screen, subfunction AH = 0x0C of int 0x10. Also, instead of constructing row and column from the screen pointer, we can use some interesting properties of the screenwidth regarding logical operations. This results in the following 16 byte program:
cwd ; "clear" DX for perfect alignment mov al,0x13 X: int 0x10 ; set video mode AND draw pixel inc cx ; increment column mov ax,cx ; get column in AH xor al,ah ; the famous XOR pattern mov ah,0x0C ; set subfunction "set pixel" for int 0x10 and al,32+8 ; a more interesting variation of it jmp short X ; rinse and repeat
The first optimization is the double usage of the same "int 0x10" as setting the videomode and drawing the pixel. The subfunction AH = 0x0C expects row and column in DX and CX. Since the screenwidth is 320, which is 5 * 64, we can ignore the row and just works with the column, if we use logical operations and just use bit 0-6 of the result. The subfunction AH = 0x0C allows for unbounded column values in CX (up to 65535) and correctly "wraps" it internally without an error.
The major drawback of the "subfunction AH = 0x0C" approach is performance loss. While DosBox and many emulators perform just fine, real hardware will draw much much slower based on the Video BIOS.