| |
VK2ZRG > TECH 24.08.05 16:55l 138 Lines 5465 Bytes #999 (0) @ WW
BID : 1354_VK2ZRG
Read: GUEST OE7FMI
Subj: Colours with the VGA card
Path: DB0FHN<DB0RGB<DB0AAB<F6KFT<LX0PAC<ON0LGE<SR1BSZ<SP7MGD<7M3TJZ<DK0WUE<
I0TVL<VK2BNR<VK2TGB<VK2IO<VK2WI
Sent: 050824/0733Z @:VK2WI.#SYD.NSW.AUS.OC #:10054 [SYDNEY] FBB7 $:1354_VK2ZRG
From: VK2ZRG@VK2WI.#SYD.NSW.AUS.OC
To : TECH@WW
VK2ZRG/TPK 1.83d Msg #:1354 Date:24-08-05 Time:7:54Z
Hello programmers,
I've been looking at ways to write text direct to the video
memory in graphics mode since I last put out a bulletin on packet. The reason
for this is to get greater speed in putting text on the screen.
Some of my recent programmes run in graphics mode and have the help/info
pages included in the executable file. These pages can be read by pressing F1.
The normal way of putting text on the screen with Pascal is rather slow on
some computers...and not necessarily older PCs. Speed seems to depend mainly
on the speed of the video card rather than CPU speed. It takes nearly 0.25
seconds to write a page of text on a 486 DX66 PC with a moderately good video
card. The 486 is actually faster than a Pentium PC with a not too good video
card. Another drawback of normal way is that the 8x8 bit mapped text is hard
to read.
I've worked out a way to write directly to the video memory, but so far it
only uses the colour in palette 15. I know that the attribute address
registers have to be accessed through memory port 03C0 hex in a very complex
way. Just what the routine is, I haven't been able to work out or find out.
While looking into this colour problem I've found that it is possible to
have many thousands of colours in both text and graphics modes with a VGA
video card. There are theoretically 262144 possible colours (262144 = 64^3)
by setting the input numbers to each of the digital to analogue converters
that control the red, blue and green colour guns in the CRT. Just how many
colours the human eye can distinguish between, is another matter.
I've written two small demo programmes that you can have a play with.
COLOURS.EXE runs in DOS text mode. It probably won't work too well with
windoze xp. COLOURSG.EXE runs in graphics mode and should work OK in DOS
or any of the windoze OS, including xp. There is some assembler code in the
help/info page. (Press F1) There are 16 colour palettes in VGA. These are
are what you select when you choose one of 16 colours. The colour that each
palette contains can be selected from 64 preset colours. Any of these 64
colours can be changed by setting the numbers going to the DACs that control
the red,blue and green colour guns in the CRT.
If anyone is interested to know how the text direct to memory works in
graphics mode, then let me know via packet radio and I'll put out another
bulletin.
If anyone can tell me how to select the colour palettes through port
03C0 or some other way, I will be very grateful indeed.
In my reading up on the subject I came across some assembler code that
is supposed to write text direct to memory with a chosen colour. I did get
it to write text to the screen, BUT no colour. Well that's not quite true;
there were vertical bars of colour running through the letters. Usually
green or pink or blue. The code is intended to be used in a C programme.
Maybe it's supposed to be made into an external linked object file...I'm
not sure.
This is the code. It is written to use microsoft C compiler ver 5 conventions
using the large model C compiler. The CharBuf dimensions were not stated in
the book. I guessed that it was 0..15 of byte (or char in C)
;Load a graphics character direct to display memory
;Input assumptions : In graphics mode and write mode 2 in effect
;Output assumptions : Write mode reset to 0
;Input parameters
;charbuf[] array containing bit pattern
;address address to load character
;offset offset in bytes per scan line. Usually 80
;bpc bytes per character. Usually 16
;colour foreground character colour
;calling protocol
;GraphChar(Charbuf,address,offset,bpc,colour);
GraphChar proc far
PUSH BP
MOV BP,SP
PUSH DS
PUSH ES
PUSH SI
PUSH DI ;End of save prefix
MOV AX,3CEh ;point to address port
MOV DX,AX
_XX MOV DI,[BP+10] ;display memory segment in DI
MOV BX,[BP+12] ;offset in BX (80 bytes per scan line)
MOV CX,[BP+14] ;bytes per char in CX (16)
MOV AH,[BP+16] ;colour
RunLoop :
MOV AL,DS:[SI]
INC SI
OUT DX,AL
MOV ES:[DI],AH
ADD DI,BX
LOOP RunLoop
POP DI ;Start of restore
POP SI
POP ES
POP DS
MOV SP,BP
POP BP
RET
GraphChar endp
To get it to run in Pascal I had to make these changes to the BP offsets
(The Pascal procedure was set to FAR, not NEAR.)
LDS SI,[BP+32]
MOV AX,0A000h
MOV ES,AX
MOV DI,[BP+30]
MOV BX,[BP+28]
MOV CX,[BP+26]
MOV AH,[BP+24]
The number going to AH that was said to set the colour actually acted as
as mask for which pixels could be turned on by the input bytes in CharBuf[]
when I got it working??? in Pascal. Worst of all, it runs at half to a third
of the speed of my method of writing bytes directly to the graphics video
memory.
Maybe some other changes are necessary to get the colour input to work in
Pascal. Does anyone have a suggestion along that line? As it's so much slower
than my method, I don't feel inclined to persist with it too much. Although
it would be nice to make it work...could learn a bit more about assembler I
suppose.
73s from Ralph VK2ZRG@VK2WI.#SYD.NSW.AUS.OC
/ack
Taglines Version 1.00, by Colin Coker G4FCN
C Program run, C Program Crash...ReWrite in Pascal!
Read previous mail | Read next mail
| |
