colours in mode 13h

[rain_storm]

This is really slow you can notice the screen being updated, How can I speed this up? I have seen tutorials talking about writing directly to the screen buffer but I have never seen a tutorial that allowed the colour to be changed. Also I have gotten this down to 57 bytes is this too big for the effect that Im going for? This is a little test run in preparation for a plasma effect but I thought that if I couldnt get this runnin fast than plasma would be far too slow...

Code: [Select]

org 100h
mov al,13h
int 10h
xor cx,cx
main:
   mov al,cl
   add al,dl
   add al,bl
   shr al,01h
   mov ah,0Ch
   int 10h
   inc cx
   cmp cx,320
   jb  main
   xor cx,cx
   inc dx
   cmp dx,200
   jb  main
   xor cx,cx
   xor dx,dx
   inc bx
   cmp bx,0FFH
   jbe exit
   xor bx,bx
exit:
   mov ah, 01h
   int 16h
   jz  main
   mov ah, 4Ch
   int 21h


[Jim]

Using int 10h to draw pixels is very, very slow.
Try making a pointer to
a000:0000
this is where the screen memory is located
ie.

Code: [Select]

mov ax,0a000h
mov ds,ax
Then to draw a pixel

Code: [Select]

mov si,pixel offset (0-63999)
mov al,colour
mov [si],al

That should get you somewhere!

Jim

[rain_storm]

Thanks Jim thats was miles faster, I'm gonna avoid int 10h from now on

[rain_storm]

heres a much faster version its up to 85 bytes but its much faster so its worth it -

Code: [Select]

org 100h
mov al,13h
int 10h
mov ax,0a000h
mov ds,ax
xor cx,cx
main:
   mov [si],al
   inc si
   inc al
   inc cx
   cmp cx, 320
   jb  main

   mov si, dx
   mov cx, dx
   shl cx, 06h
   shl si, 08h
   add si, cx
   xor cx, cx
   inc bx
   mov al, bl
   inc dx
   cmp dx, 200
   jbe main

   xor dx, dx
   sub bx,200
   mov ah,01h
   int 16h
   jz  main

mov ah, 4Ch
int 21h



[Jim]

You'll get it much smaller when you realise that all the pixels are next to each other in memory.
So there's no need to do x+320*y every pixel, you just need to add 1 to si.

Jim

[rain_storm]

You are right I got it down to 52 bytes thats smaller than the first version I posted man this has really been worthwhile I cant believe the increase in speed. Now I really have to get some sleep. Thanks alot Jim 

Code: [Select]

org 100h
mov al,13h
int 10h
mov ax, 0a000h
mov ds, ax

main:
   xor si, si
   xor dl, dl
   mov al, bl
   inc bl

plot:
   xor cx, cx
   mov al, dl
   add al, bl

draw:
   mov [si],al
   inc si
   inc al
   inc cx
   cmp cx, 140h
   jb  draw

   inc dl
   cmp dl, 0C8h
   jb  plot

   mov ah,01h
   int 16h
   jz  main
mov ah, 4Ch
int 21h



[Jim]

This will go smaller again when you spot that now you're not using x and y in your calculation, you only need one loop.  It's not necessary to count up cx and dl separately, just count cx from 0 to 64000 (320*200).

Have fun!

Jim

[rain_storm]

How do you do that? Whats you're secret, Jim? Are you an Illuminati or a Freemason or something +karma for the insights, Iv picked up more assembler today than a month of reading Art of Assembly

[Jim]

http://dbfinteractive.com/index.php?topic=407.msg5603#msg5603

Actually, it's quicker to count cx down from 64000 to 0.

Jim

[rain_storm]

thats because an addition in hardware is a pyrabid of 'xor gates' and 'and gates' that tapers upwards whilst subtraction is mearly a xor (thats why xor ax,ax clears the value in ax). since a 16 bit number requires 16 xors+ands to add them thats 15 more steps than it takes to subtract. I've got a logic simulator, a good one, I work in electrics too and I've built full adders and multipliers out of 7400's logic chips I'm really more a hardware guy that has a thing for graphics than an all out programmer. Heres a thing I put together to subtract and add two values you need an emulator to check the results in the variables 'value' and 'carry' but this is a true software emulation of how basic math is done in hardware it was written for emu8086 so it might not work as is in fasm but everything is done with boolean logic so the math will be universal

Code: [Select]

mins_oper:
     mov ah, a_reg
     mov value, ah
     mov bh, b_reg
     xor ah, bh
     mov value, ah

plus_oper:
     mov ah, a_reg
     mov value, ah
     mov bh, b_reg
     mov ch, a_reg
     mov dh, b_reg
     mov carry, dh
     xor ah, bh
     mov value, ah
     and ch, dh
     mov carry, ch
     shl ch, 0001h
     mov carry, ch

plus_loop:
     mov ah, value
     mov bh, carry
     mov ch, value
     mov dh, carry
     mov value, ah
     xor ah, bh
     mov value, ah
     and ch, dh
     mov carry, ch
     shl ch, 0001h
     mov carry, ch
     cmp ch, 0000_0000b
     jne plus_loop

     ret

a_reg db 0111_1111b
b_reg db 0001_0001b
value db 0000_0000b
carry db 0000_0000b
end


[Jim]

  I was thinking it's because there's an instruction jcxz which doesn't need a cmp cx,64000 to check for the end.  It's easier to check for cx=0 than cx=value.
Isn't a-b implemented as a+(-b) in hardware?  Last time I worked at that level was with 8bit PALs and PALASM about 17 years ago now!

Jim

[rain_storm]

you mean twos compliment? the way I was shown was with logic chips and xor works to return the difference between two values. its not capable of handling negative values but at least at a hobbyist level its very adaptable ie obstacle avoidence for gettin a robot to turn away from the closest wall this is a cheap way to calculate without a microcontroller since a xor chip only costs about 50p micros range from 8 pounds to 80 pounds
Got it down to 39 bytes Iv never coded anything this small before

Code: [Select]

org 100h
mov al,13h
int 10h
mov ax, 0A000h
mov ds, ax

draw:
   mov [si], dl
   inc si
   sub dl, 02h
   cmp si, 0FFFFh
   jb  draw

   inc bl
   mov dl, bl
   mov ah, 01h
   int 16h
   jz  draw

   mov ax, 0003h
   int 10h
   mov ah, 4Ch
   int 21h


[Jim]

I think si=0 at the start of a com file, so you're getting away with not setting that.  Also, there are 64000 pixels on the screen, not 65536, but it won't matter if you go over the end, since there is really a 64Kb segment there anyway.

Nice work on shrinking it!  I'm pretty sure the keytest can be made smaller.

Were you looking for code to change the palette too?

Jim

[rain_storm]

Ive been playing around with the pallet offset (3C8h) and sending values to the vga card to replace the default values but I am finding it very hard to generate a pallet that the monitor can display. Any body got any pointers just so you can see what I am attempting it looks something like this ...

mov dx,3c8h ; pallet offset
xor al,al       ; set al to zero
out dx,al      ; send the offset to the vga card
inc dx          ; increase dx now we start sending RGB values ranging from 0 - 63 (up to 256 colours)

but its very difficult to create a pallet that actually works most wotnt display and the ones that do are as difficult to work with as mode 13h default pallet which is a joke imho

[Jim]

Try working with values from 32-63 to start with.  Or try some colour ramps, black->red, black->green, black->blue etc.

What do you mean "most won't display"?  Anything with values 0-63 in there should display.

Jim

[rain_storm]

This tutorial states that it is possible to create pallets that will not display and its correct I have made ones that only display black for all colours  but also have created ones with mixed results not happy with anything so far
values of 32 and up I will see what I can do with that (I was starting with 0 and up)
whats a ramp? a transition from black to colour?

[Jim]

A ramp is just a gradient between two colours.  Since you know that red (63,0,0) is a good colour and blue (0,0,63) is a good colour, then any colours in between them in a gradient are also good colours.

I couldn't find anything on that page about invalid palettes (because I skimmed it too quickly) - can you point it out?

Jim

[rain_storm]

I dont really know how to link to parts of a webpage but its about half way down. there are two sections headed with quotes with really big text

first quote is -
"Apparently, it IS
possible to cause damage
to monitors if incorrect
values are used!" 

and the second one is right below that -
"A little knowledge
can be dangerous,
so be careful!"

[Jim]

OK, at that point he's not talking about the palette, he's talking about the display controller in general.
In theory, it's possible to set the frequency of the display to something ludicrous, and have a monitor blow due to that.  In new monitors that will never happen - they all spot out of range signals and ignore them.  Last time I heard of this happening was in a Commodore PET from the 1980s.

So, putting in duff palette values isn't going to make a non-displayable screen.  Are you actually trying to follow that Mode-X tutorial or are you still in 13h?

Jim

[rain_storm]

Ah I see. I figured out why things went going right with the black screen I forgot to increas the colour value and it was always set to zero stupid mistake I am still in mode 13h I want to get the pallet working before I even think about different resolutions and paging I got one to work it was exactly how you explained it before keep values below 63 and it worked perfectly but it doesnt look I used all 256 collours thats because the screen is 320 pixels long so I had to use an increment of 4 for colours or it wouldnt look right

Code: [Select]

org 100h

mov al, 13h       ; enter graphics mode
int 10h
mov ax, 0A000h    ; get screen buffer offset
mov ds, ax        ; and put it in ds

mov dx,03C8h      ; get colour pallet offset
xor al,al         ; clear al
out dx,al         ; send zero to vga card
inc dx            ; now dx points to pallet

reds:
   mov al, bl     ; get brightness
   out dx, al     ; red
   xor al, al     ; only red
   out dx, al     ; green
   out dx, al     ; blue

   mov al, bl     ; get brightness
   out dx, al     ; red
   xor al, al     ; only red
   out dx, al     ; green
   out dx, al     ; blue

   mov al, bl     ; get brightness
   out dx, al     ; red
   xor al, al     ; only red
   out dx, al     ; green
   out dx, al     ; blue

   mov al, bl     ; get brightness
   out dx, al     ; red
   xor al, al     ; only red
   out dx, al     ; green
   out dx, al     ; blue

   inc bl         ; make it a bit brighter
   cmp bl, 64     ; check for max brightness
   jb  reds       ; loop if not max brightness

draw:
   mov [si], dl   ; put colour on screen
   add dx, 04h    ; next colour
   inc si         ; next pixel
   cmp si, 0FFFFh ; compare against screen buffer limit
   jb  draw       ; loop
   add dx, 01h    ; scroll one colour for next frame

   mov ah, 01h    ; check for key press
   int 16h
   jz  draw       ; loop

   mov ax, 0003h  ; enter text mode
   int 10h
   mov ah, 4Ch    ; exit to o/s
   int 21h