m/grafX2
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

convert DOS txt files from CP437 to UTF-8

Browse Source 
restore doc_eng.txt (UTF8)

Move to original_docs subdirectory, so they won't be included by
packaging
This commit is contained in:
Thomas Bernard
2018-07-12 14:40:48 +02:00
parent 1cdb9a707e
commit a9b72c2ae9
6 changed files with 4941 additions and 2958 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1983
doc/original_docs/doc_eng.txt Normal file
View File

File diff suppressed because it is too large Load Diff

2113
doc/original_docs/doc_fra.txt Normal file
View File

File diff suppressed because it is too large Load Diff

732
doc/original_docs/tech_eng.txt Normal file
View File

@@ -0,0 +1,732 @@
┌────────────────────────────────────────────────────────────────────────────┐
│░▒▓█ Technical documentation for GrafX 2.00 - Version 1.08 (10/05/1997) █▓▒░│
└────────────────────────────────────────────────────────────────────────────┘
This file deals with:
- the PKM picture format
- the values to send to the CRTC to access all the amazing video modes
available in GrafX 2.00
┌────────────────────────────────────────────────────────────────────────────┐
│ ░▒▓█ The PKM picture format - by Karl Maritaud █▓▒░ │
└────────────────────────────────────────────────────────────────────────────┘
First of all, I'd like to say that I made this file format some years ago
when I didn't knew how to load any good format (eg. GIF) and wanted to have
my own format.
PKM format was designed to be very simple, easy to encode and decode. Its
header is very simple (short) and evolutive.
The only real default I can find in this format is that you can only save
256-color pictures.
I know that you will think:
"Oh no just another fucking format! I'll never use it! Its compression
is too poor and I prefer GIF!".
And I'll answer:
"Yeah! You're right. But if you dunno how to load GIF and want a simple
format with a quite good compression rate (on simple pictures at least),
it could be useful."
So, here comes the format documentation...
The HEADER:
═══════════
The header is the following 780-byte-structure. (Don't worry about the size.
That's just because the palette is considered as a part of the header).
┌─────┬───────────┬──────┬──────┬──────────────────────────────────────────┐
│ Pos │ Field │ Type │ Size │ Description │
╞═════╪═══════════╪══════╪══════╪══════════════════════════════════════════╡
│ 0 │ Signature │ char │ 3 │ Constant string "PKM" (with NO size │
│ │ │ │ │ delimitation '\0' or so...) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 3 │ Version │ byte │ 1 │ For the moment, it can take only the │
│ │ │ │ │ value 0. │
│ │ │ │ │ Other packing methods may change this │
│ │ │ │ │ field but there is only one for now... │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 4 │ Pack_byte │ byte │ 1 │ Value of the recognition byte for color │
│ │ │ │ │ repetitions that are coded on 1 byte. │
│ │ │ │ │ (See the picture packing section for a │
│ │ │ │ │ better explanation) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 5 │ Pack_word │ byte │ 1 │ Value of the recognition byte for color │
│ │ │ │ │ repetitions that are coded on 2 bytes. │
│ │ │ │ │ (See the picture packing section...) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 6 │ Width │ word │ 2 │ Picture width (in pixels) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 8 │ Height │ word │ 2 │ Picture height (in pixels) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 10 │ Palette │ byte │ 768 │ RGB palette (RGB RGB ... 256 times) with │
│ │ │ │ │ values from 0 to 63. I know the standard │
│ │ │ │ │ in picture files is 0 to 255 but I find │
│ │ │ │ │ it stupid! It is really easier to send │
│ │ │ │ │ the whole palette in port 3C9h with a │
│ │ │ │ │ REP OUTSB without palette convertion. │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 778 │ PH_size │ word │ 2 │ Post-header size. This is the number of │
│ │ │ │ │ bytes between the header and the picture │
│ │ │ │ │ data. This value can be equal to 0. │
└─────┴───────────┴──────┴──────┴──────────────────────────────────────────┘
Data of type "word" are stored with Intel conventions: lower byte first.
The POST-HEADER:
════════════════
The post-header has a variable size. It was designed to support new features
for this file format without changing the whole format.
It consists in field identifiers followed by their size and their value.
A field identifier is coded with 1 byte and a field size also.
These field identifiers are: (this list may be updated...)
────────────────────────────
0 : Comment on the picture
1 : Original screen dimensions
2 : Back color (transparent color)
If you encounter a field that you don't know just jump over it. But if a
field tells you to jump to a position that is over the beginning of the
picture data, there is an error in the file.
The fields:
───────────
* Comment:
With this field, artists will be able to comment their pictures.
Note that GrafX 2 has a comment size limit of 32 chars. But you can
comment a picture with up to 255 chars if you make your own viewer
since GrafX 2 will just ignore extra characters.
Example: [0],[16],[Picture by X-Man]
This sequence means:
- the field is a comment
- the comment takes 16 characters (there is no end-of-string character
since you know its size)
- the comment is "Picture by X-Man"
* Original screen dimensions:
Since GrafX 2 supplies a huge range of resolutions, it seemed convenient
to add a field that indicates what were the original screen dimensions.
Example: [1],[4],[320],[256]
This sequence means:
- the field is a screen dimensions descriptor
- the dimensions are 2 words (so this value must be always equal to 4)
- the original screen width was 320 pixels
- the original screen height was 256 pixels
Note that words stored in fields are written Intel-like. The 90% BETA
version did not respect this norm. I'm really sorry about this. This is
not very serious but pictures saved with version 90% and loaded with a
latest version (91% and more) won't set the right resolution.
* Back color:
Saving the back color (transparent color) is especially useful when you
want to save a brush.
The size of this field is 1 byte (index of the color between 0 and 255).
Example: [2],[1],[255]
This sequence means:
- the field is a screen dimensions descriptor
- the value takes 1 byte
- the transparent color is 255
The PICTURE PACKING METHOD:
═══════════════════════════
The PKM compression method is some sort of Run-Length-Compression which is
very efficient on pictures with long horizontal color repetitions.
Actually, the compression is efficient if there are often more than 3 times
the same color consecutively.
I think that it would be better to give you the algorithm instead of swim-
ming in incomprehensible explanations.
BEGIN
/*
functions:
Read_byte(File) reads and returns 1 byte from File
Draw_pixel(X,Y,Color) draws a pixel of a certain Color at pos. (X,Y)
File_length(File) returns the total length in bytes of File
variables:
type of Image_size is dword
type of Data_size is dword
type of Packed_data_counter is dword
type of Pixels_counter is dword
type of Color is byte
type of Byte_read is byte
type of Word_read is word
type of Counter is word
type of File is <binary file>
*/
/* At this point you've already read the header and post-header. */
Image_size <- Header.Width * Header.Height
Data_size <- File_length(File) - (780+Header.PH_size)
Packed_data_counter <- 0
Pixels_counter <- 0
/* Depacking loop: */
WHILE ((Pixels_counter<Image_size) AND (Packed_data_counter<Data_size)) DO
{
Byte_read <- Read_byte(File)
/* If it is not a packet recognizer, it's a raw pixel */
IF ((Byte_read<>Header.Pack_byte) AND (Byte_read<>Header.Pack_word))
THEN
{
Draw_pixel(Pixels_counter MOD Header.Width,
Pixels_counter DIV Header.Width,
Byte_read)
Pixels_counter <- Pixels_counter + 1
Packed_data_counter <- Packed_data_counter + 1
}
ELSE /* Is the number of pixels to repeat coded... */
{ /* ... with 1 byte */
IF (Byte_read = Header.Pack_byte) THEN
{
Color <- Read_byte(File)
Byte_read <- Read_byte(File)
FOR Counter FROM 0 TO (Byte_read-1) STEP +1
Draw_pixel((Pixels_counter+Counter) MOD Header.Width,
(Pixels_counter+Counter) DIV Header.Width,
Color)
Pixels_counter <- Pixels_counter + Byte_read
Packed_data_counter <- Packed_data_counter + 3
}
ELSE /* ... with 2 bytes */
{
Color <- Read_byte(File)
Word_read <- (word value) (Read_byte(File) SHL 8)+Read_byte(File)
FOR Counter FROM 0 TO (Word_read-1) STEP +1
Draw_pixel((Pixels_counter+Counter) MOD Header.Width,
(Pixels_counter+Counter) DIV Header.Width,
Color)
Pixels_counter <- Pixels_counter + Word_read
Packed_data_counter <- Packed_data_counter + 4
}
}
}
END
For example, the following sequence:
(we suppose that Pack_byte=01 and Pack_word=02)
04 03 01 05 06 03 02 00 01 2C
will be decoded as:
04 03 05 05 05 05 05 05 03 00 00 00 ... (repeat 0 300 times (012Ch=300))
Repetitions that fit in a word must be written with their higher byte first.
I know that it goes against Intel standard but since I read bytes from the
file thru a buffer (really faster), I don't care about the order (Sorry :)).
But words in the header and post-header must be written and read Intel-like!
Packing advices:
────────────────
* As you can see, there could be a problem when you'd want to pack a raw
pixel with a color equal to Pack_byte or Pack_word. These pixels should
always be coded as a packet even if there is only one pixel.
Example: (we suppose that Pack_byte=9)
9 will be encoded 9,9,1 (The 1st 9 in the encoded...
9,9 will be encoded 9,9,2 ... sequence is Pack_byte)
etc...
* It seems obvious to find values for Pack_byte and Pack_word that are
(almost) never used. So a small routine that finds the 2 less used colors
in the image should be called before starting to pack the picture. This can
be done almost instantaneously in Assembler.
* When you want to pack a 2-color-sequence, just write these 2 colors one
after the other (Color,Color) because it only takes 2 bytes instead of 3 if
you had to write a packet (Pack_byte,Color,2).
* If you pack a very simple picture which has a sequence of more than 65535
same consecutive bytes, you must break the sequence and continue with a new
packet.
Example: you have to pack 65635 same consecutive bytes (eg. color 0)
(we suppose that Pack_byte=01 and Pack_word=02)
You'll write: 02 00 FF FF 01 00 64 (FFFFh=65535, 64h=100)
┌────────────────────────────────────────────────────────────────────────────┐
│ ░▒▓█ Setting GrafX 2.00 video modes █▓▒░ │
└────────────────────────────────────────────────────────────────────────────┘
All set-mode procs are in 386 ASM. Anyway, if you can't understand any
line of ASM, I really can't see the use you'll have of these procedures.
They are designed to be used in FLAT memory model. Anyway, it wouldn't
take too much time for you to adapt them to the model you use since only
memory indexations can be affected by this (so use DS:SI instead of ESI,
ES:DI instead of EDI, and beware to the address 0A0000h that will become
0A000h:0000h).
MCGA: (Standard VGA mode)
═════
Is there anybody in this world who still don't now how to set the MCGA
320x200 256 colors mode ??!?
Well... I hope you are a novice if you read the 2 following lines :)
mov ax,0013h
int 10h
X-Modes: (Extended VGA modes)
════════
Well... I think the original Mode X was 320x240 but now, many people call
"X-Modes" (or Modes X, or Tweaked modes) all the VGA modes that use more
that 64Kb of video memory with the "Unchained" structure.
Setting a pixel in any X-Mode can be done by one same function (but I
won't explain to you how to do that. You just have to tell the function what
the plane width (screen_width/4) is).
If you can't understand anything about what I say (unchained, planes...),
just read any good documentation about Mode X.
We'd like to thank the authors of XLIB2 for saving our time by having made
this useful function. We slightly optimized it for our needs but the most
important parts are here.
mov ax,13h ; Yeah! The MCGA mode again! All X-Modes must start from
int 10h ; the standard VGA mode, but many things change after.
mov dx,3C6h ; During the initialization, we'll turn the palette into
xor al,al ; black in order to avoid the user to see all our
out dx,al ; manipulations.
mov dx,3C4h ; We will inform the TIMING SEQUENCER register to switch
mov ax,0604h ; in unchained mode (mode-X), without odd/even management
out dx,ax ; and with an access to the 256Kb of the video card.
mov ax,0100h ; Now we will engage the synchronous reset of the TS
out dx,ax ; register because we're about to play with registers.
mov al,01h ; Like with the palette, we ask the video card not to
out dx,al ; peek the memory to display it anymore. Thus, it's
inc dx ; one more way to avoid interferences in the display,
in al,dx ; which happens until the mode is completely initialized
mov ah,al ; and stable. In addition, we can expect that asking a
mov al,01h ; memory reading interruption will turn the system
push ax ; faster, and thus speed up the initialization of the
mov al,ah ; graphic mode (hope makes you live :))
or al,20h ;
out dx,al ;
mov esi,X_ptr ; Pointer on the list of constants to send to the CRTC.
cld
lodsb ; This loads in AL a value that will tell what to do
; with the MISCELLANEOUS register, and increases ESI.
; The value is equal to ZERO => Nothing to do
; or ELSE => Send AL to MISCELLANEOUS
or al,al ; Shall we modify the basic video mode?
jz NoThankYou ; No?─┐ Actually the answer is always "Yes".
mov dx,3C2h ; │ Except for a few modes such as
out dx,al ; │ 320x200 in Mode X
NoThankYou: ; <───┘ (but our 320x200 is MCGA...)
mov dx,3C4h ; Manipulations with MISCELLANEOUS register are over, we
mov ax,0300h ; can now disengage the synchronous register of the TS.
out dx,ax
; Now, what about teasing the CRTC?
mov dx,3D4h ; In the 18th register of the CRTC, we will disengage the
mov al,11h ; protection bit. Without this, the values we would have
out dx,al ; sent to the CRTC registers would have been ignored.
inc dx
in al,dx
and al,7Fh
out dx,al
dec dx ; DX points back to the CRTC register entry
lodsb ; This loads in AL the number of CRTC registers to modify
xor ecx,ecx ; You must clear ECX before...
mov cl,al ; ... starting to repeat AL (CL) times OUTSW
rep outsw ; Let's send all the CRTC parameters!
; Just in case the 20th CRTC register would have been forgotten in the
; initialisation table, we can compute it by ourselves (Yeah, we are good
; guys).
mov ax,Screen_width ; You must tell the routine what the Screen width is
shr ax,3
mov ah,al
mov al,13h
out dx,ax
mov dx,3C4h ; Now you have the good resolution but there can be
mov ax,0F02h ; shitty pixels on the screen coming from the uncleared
out dx,ax ; memory areas.
mov edi,0A0000h ; So we'll clean memory starting from 0A0000h with the
xor eax,eax ; value 0 (which is the standard black) and on a range
mov ecx,4000h ; of 4000h dwords (256Kb).
rep stosd ; Let's wipe all this out.
mov dx,3C4h ; We can ask the VGA to read again the memory to display
pop ax ; it on the screen...
out dx,ax ;
mov dx,3C6h ; ... and turn on the palette so the picture appears to
mov al,0FFh ; the user.
out dx,al ;
The table of constants you must send is one of these:
(These are tables for C but they can be easily used in other languages)
word X320Y224[] =
{ 0x0BA3, 0x6F06, 0xBA07, 0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x0014,
0xC715, 0x0416, 0xE317 };
word X320Y240[] =
{ 0x0AE3, 0x0D06, 0x3E07, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715,
0x0616, 0xE317 };
word X320Y256[] =
{ 0x0CE3, 0x2306, 0xB207, 0x0008, 0x6109, 0x0A10, 0xAC11, 0xFF12, 0x2013,
0x0014, 0x0715, 0x1A16, 0xE317 };
word X320Y270[] =
{ 0x0BE7, 0x3006, 0xF007, 0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x0014,
0x1F15, 0x2F16, 0xE317 };
word X320Y282[] =
{ 0x0CE3, 0x6206, 0xF007, 0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x2F13,
0x0014, 0x3C15, 0x5C16, 0xE317 };
word X320Y300[] =
{ 0x0DE3, 0x4606, 0x1F07, 0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2013,
0x0014, 0x2F15, 0x4416, 0xE317 };
word X320Y360[] =
{ 0x09E3, 0x4009, 0x8810, 0x8511, 0x6712, 0x2013, 0x0014, 0x6D15, 0xBA16,
0xE317 };
word X320Y400[] =
{ 0x03E3, 0x4009, 0x0014, 0xE317 };
word X320Y448[] =
{ 0x0BA3, 0x6F06, 0xBA07, 0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x0014,
0xC715, 0x0416, 0xE317 };
word X320Y480[] =
{ 0x0AE3, 0x0D06, 0x3E07, 0x4009, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715,
0x0616 , 0xE317};
word X320Y512[] =
{ 0x0CE3, 0x2306, 0xB207, 0x0008, 0x6009, 0x0A10, 0xAC11, 0xFF12, 0x2013,
0x0014, 0x0715, 0x1A16, 0xE317 };
word X320Y540[] =
{ 0x0BE7, 0x3006, 0xF007, 0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x0014,
0x1F15, 0x2F16, 0xE317 };
word X320Y564[] =
{ 0x0CE7, 0x6206, 0xF007, 0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x2013,
0x0014, 0x3C15, 0x5C16, 0xE317 };
word X320Y600[] =
{ 0x0BE7, 0xBE06, 0xF007, 0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x0014,
0x5815, 0x7016, 0xE317 };
word X360Y200[] =
{ 0x09E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2D13, 0x0014,
0xE317 };
word X360Y224[] =
{ 0x12A7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6F06, 0xBA07,
0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x2D13, 0x0014, 0xC715, 0x0416,
0xE317 };
word X360Y240[] =
{ 0x11E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x0D06, 0x3E07,
0x4109, 0xEA10, 0xAC11, 0xDF12, 0x2D13, 0x0014, 0xE715, 0x0616, 0xE317 };
word X360Y256[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2B06, 0xB207,
0x0008, 0x6109, 0x0E10, 0xAC11, 0xFF12, 0x2D13, 0x0014, 0x0715, 0x1A16,
0xE317 };
word X360Y270[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x3006, 0xF007,
0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x2D13, 0x0014, 0x1F15, 0x2F16,
0xE317 };
word X360Y282[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6206, 0xF007,
0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x2D13, 0x0014, 0x3C15, 0x5C16,
0xE317 };
word X360Y300[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4606, 0x1F07,
0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2D13, 0x0014, 0x2F15, 0x4416,
0xE317 };
word X360Y360[] =
{ 0x0FE7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4009, 0x8810,
0x8511, 0x6712, 0x2D13, 0x0014, 0x6D15, 0xBA16, 0xE317 };
word X360Y400[] =
{ 0x0AE7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4009, 0x2D13,
0x0014, 0xE317 };
word X360Y448[] =
{ 0x12A7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6F06, 0xBA07,
0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x2D13, 0x0014, 0xC715, 0x0416,
0xE317 };
word X360Y480[] =
{ 0x11E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x0D06, 0x3E07,
0x4009, 0xEA10, 0xAC11, 0xDF12, 0x2D13, 0x0014, 0xE715, 0x0616, 0xE317 };
word X360Y512[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2B06, 0xB207,
0x0008, 0x6009, 0x0E10, 0xAC11, 0xff12, 0x2D13, 0x0014, 0x0715, 0x1A16,
0xE317 };
word X360Y540[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x3006, 0xF007,
0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x2D13, 0x0014, 0x1F15, 0x2F16,
0xE317 };
word X360Y564[] =
{ 0x12EB, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6206, 0xF007,
0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x2D13, 0x0014, 0x3C15, 0x5C16,
0xE317 };
word X360Y600[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0xBE06, 0xF007,
0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x2D13, 0x0014, 0x5815, 0x7016,
0xE317 };
word X400Y200[] =
{ 0x09E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3213, 0x0014,
0xE317 };
word X400Y224[] =
{ 0x12A7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6F06, 0xBA07,
0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x3213, 0x0014, 0xC715, 0x0416,
0xE317 };
word X400Y240[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x0D06, 0x3E07,
0x0008, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x3213, 0x0014, 0xE715, 0x0616,
0xE317 };
word X400Y256[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x2B06, 0xB207,
0x0008, 0x6109, 0x1310, 0xAC11, 0xFF12, 0x3213, 0x0014, 0x0715, 0x1A16,
0xE317 };
word X400Y270[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3006, 0xF007,
0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x3213, 0x0014, 0x1F15, 0x2F16,
0xE317 };
word X400Y282[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6206, 0xF007,
0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x3213, 0x0014, 0x3C15, 0x5C16,
0xE317 };
word X400Y300[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4606, 0x1F07,
0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x3213, 0x0014, 0x2F15, 0x4416,
0xE317 };
word X400Y360[] =
{ 0x0FE7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4009, 0x8810,
0x8511, 0x6712, 0x3213, 0x0014, 0x6D15, 0xBA16, 0xE317 };
word X400Y400[] =
{ 0x0AE7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4009, 0x3213,
0x0014, 0xE317 };
word X400Y448[] =
{ 0x12A7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6F06, 0xBA07,
0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x3213, 0x0014, 0xC715, 0x0416,
0xE317 };
word X400Y480[] =
{ 0x11E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x0D06, 0x3E07,
0x4009, 0xEA10, 0xAC11, 0xDF12, 0x3213, 0x0014, 0xE715, 0x0616, 0xE317 };
word X400Y512[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x2B06, 0xB207,
0x0008, 0x6009, 0x1310, 0xAC11, 0xFF12, 0x3213, 0x0014, 0x0715, 0x1A16,
0xE317 };
word X400Y540[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3006, 0xF007,
0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x3213, 0x0014, 0x1F15, 0x2F16,
0xE317 };
word X400Y564[] =
{ 0x12EB, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6206, 0xF007,
0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x3213, 0x0014, 0x3C15, 0x5C16,
0xE317 };
word X400Y600[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0xBE06, 0xF007,
0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x3213, 0x0014, 0x5815, 0x7016,
0xE317 };
The structure: (example)
┌────This is the number of values to send to the CRTC registers. This
│ is actually the number of words in the tables minus 1 (because the
│ 1st word of the table is not sent to the CRTC but contains a value
│ to send to the MISCELLANEOUS register and the number of values to
│ send to the CRTC registers ;) ).
│
│ ┌──This is the value to send to the MISCEALLANEOUS register (or ZERO
│ │ if no value must be sent to it).
│ │
│ │ ┌───This is a value to send to a register of the CRTC.
│ │ │
│ │ │ ┌─This is the index of the CRTC register that will receive
│ │ │ │ the value.
├┐├┐ ├┐├┐
{ 0x0AE3, 0x0D06, 0x3E07, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715,
0x0616, 0xE317 };
You can notice that CRTC registers 0 to 5 (and 13h) define the screen
width while registers 6 to 17h (except 13h) define the screen height.
We have more modes in our pocket than the "few" :) ones we included in
GrafX 2.00, but they aren't really useful or stable. But we may decice to
include them anyway in a next version.
If some of your favourite modes are missing, just send us the list of
constants we must shoot at the CRTC just following the structure we use
above.
IMPORTANT! The constant values listed above are not supported by every
monitor or video card.
We have tested GrafX2 with several different configurations and
we constated that some modes don't work at all with some video
cards while some others can be overscanned, out of center, dark,
too bright, or shrunk.
But they all work fine with our poor little Tseng Labs ET4000...
If you already have a good knowledge about CRTC and have different values
than ours for certain modes, please let us know. We'll use them if they work
better with a majority of computers.
VESA: (A "pseudo-standard" for Super-VGA modes)
═════
We use VESA for modes that require a width of 640, 800 or 1024 pixels.
But there is a way to combine X-Modes height with VESA so it's possible to
have modes as weird as in X-Mode.
mov ax,4F02h
mov bx,Video_mode
int 10h
256-color-VESA video modes are:
100h : 640x400
101h : 640x480
103h : 800x600
105h : 1024x768
107h : 1280x1024 (not available in GrafX2 because only supported with
video cards with 2 or more Megabytes of video memory)
As with X-Modes, you can modify CRTC registers to access "Xtd-VESA" modes!
(Note that some video cards don't support the modification of the VGA CRTC
registers in VESA modes.)
To enter these extended VESA modes, set a standard VESA mode with the right
width, and then call Modify_CRTC_registers with the proper Height table.
Example (640x512) :
VESA_Set_mode(101h) /* Set a video mode with the same width */
Modify_CRTC_registers(Y512) /* Modify height */
* Height tables:
word Y224[] =
{ 0x09A3, 0x6F06, 0xBA07, 0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0xC715,
0x0416 };
word Y240[] =
{ 0x09E3, 0x0D06, 0x3E07, 0x0008, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0xE715,
0x0616 };
word Y256[] =
{ 0x0900, 0x2B06, 0xB207, 0x0008, 0x6109, 0x0A10, 0xAC11, 0xFF12, 0x0715,
0x1A16 };
word Y270[] =
{ 0x09E7, 0x3006, 0xF007, 0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x1F15,
0x2F16 };
word Y282[] =
{ 0x0AE3, 0x6206, 0xF007, 0x0008, 0x6109, 0x310F, 0x3710, 0x8911, 0x3312,
0x3C15, 0x5C16 };
word Y300[] =
{ 0x09E3, 0x4606, 0x1F07, 0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2F15,
0x4416 };
word Y350[] =
{ 0x09A3, 0xBF06, 0x1F07, 0x0008, 0x4009, 0x8310, 0x8511, 0x5D12, 0x6315,
0xBA16 };
word Y360[] =
{ 0x07E3, 0x0008, 0x4009, 0x8810, 0x8511, 0x6712, 0x6D15, 0xBA16 };
word Y400[] =
{ 0x01E3, 0x4009 };
word Y448[] =
{ 0x09A3, 0x6F06, 0xBA07, 0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0xC715,
0x0416 };
word Y480[] =
{ 0x09E3, 0x0D06, 0x3E07, 0x0008, 0x4009, 0xEA10, 0xAC11, 0xDF12, 0xE715,
0x0616 };
word Y512[] =
{ 0x0900, 0x2B06, 0xB207, 0x0008, 0x6009, 0x0A10, 0xAC11, 0xFF12, 0x0715,
0x1A16 };
word Y540[] =
{ 0x09E7, 0x3006, 0xF007, 0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x1F15,
0x2F16 };
word Y564[] =
{ 0x09E7, 0x6206, 0xF007, 0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x3C15,
0x5C16 };
word Y600[] =
{ 0x09E7, 0xBE06, 0xF007, 0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x5815,
0x7016 };
Modifying CRTC registers: (inspired by X-Modes init... See above for more
───────────────────────── details or comments)
mov esi,XVESA_Ptr
cld
lodsb
or al,al ; Shall we modify the basic video mode?
jz NoThankYou ; No?─┐ The answer can be "No" because initialisations
mov dx,3C2h ; │ of certain VESA modes directly set the right
out dx,al ; │ value for the Miscellaneous register.
NoThankYou: ; <───┘
mov dx,3D4h
mov al,11h
out dx,al
inc dx
in al,dx
and al,7Fh
out dx,al
dec dx
lodsb
xor ecx,ecx
mov cl,al
rep outsw
If you are cunning enough, you'll be able to combine constants used in
X-Modes to get more "Xtd-VESA" modes such as 640x200, 800x480, etc...
(but I don't think this will work with 1024x??? because this mode is
generally interlaced... But who knows?...)
The most difficult is to find the right value for the MISCELLANEOUS
register.

769
doc/original_docs/tech_fra.txt Normal file
View File

@@ -0,0 +1,769 @@
┌────────────────────────────────────────────────────────────────────────────┐
│░▒▓█ Doc. technique pour GrafX 2.00 - Version 1.08 (5 octobre 1997) █▓▒░│
└────────────────────────────────────────────────────────────────────────────┘
Ce fichier traite:
- du format d'image PKM
- des valeurs à envoyer au CRTC pour avoir accès à tous les modes vidéos
incroyables disponibles dans GrafX 2.00
┌────────────────────────────────────────────────────────────────────────────┐
│ ░▒▓█ Le format d'image PKM - par Karl Maritaud █▓▒░ │
└────────────────────────────────────────────────────────────────────────────┘
Tout d'abord, je tiens a dire que j'ai créé ce format il y a déjà quelques
années, à l'époque où je ne savais pas comment charger les meilleurs formats
(GIF par exemple) et que je voulais également avoir mon propre format.
Le format PKM a été conçu pour être très simple, facile à encoder et à
décoder. De plus, son header est très simple (court) et evolutif.
Le seul vrai défaut que je puisse y trouver est que l'on ne peut sauver
des images qu'en 256 couleurs.
Je sais que vous allez vous dire:
"Oh non! Encore un nouveau format à la con! J'm'en servirai jamais! En
plus le taux de compression est naze! Je prefère le GIF!".
Et je répondrai:
"Ouais! T'as raison. Mais si tu ne sais pas comment charger du GIF et
que tu veux un format simple avec une compression correcte (du moins sur
les images simples), il peut être utile."
Donc, voici la documentation de ce format...
Le HEADER:
══════════
Le header est la structure de 780 octets suivante. (Ne vous inquiétez pas à
propos de la taille. C'est tout simplement parce que la palette fait partie
du header).
┌─────┬───────────┬──────┬──────┬──────────────────────────────────────────┐
│ Pos │ Champ │ Type │Taille│ Description │
╞═════╪═══════════╪══════╪══════╪══════════════════════════════════════════╡
│ 0 │ Signature │ char │ 3 │ Chaîne constante "PKM" (SANS délimitation│
│ │ │ │ │ de taille '\0' ou autres...) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 3 │ Version │ byte │ 1 │ Pour le moment, ce champ ne peut prendre │
│ │ │ │ │ que la valeur 0. │
│ │ │ │ │ D'autres méthodes de compression pourront│
│ │ │ │ │ la modifier mais pour l'instant il n'y en│
│ │ │ │ │ a qu'une seule. │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 4 │ Pack_byte │ byte │ 1 │ Valeur de l'octet de reconnaissance pour │
│ │ │ │ │ les répétitions de couleurs codées sur 1 │
│ │ │ │ │ Octet. (Voir la section sur la méthode de│
│ │ │ │ │ compression pour plus d'informations) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 5 │ Pack_word │ byte │ 1 │ Valeur de l'octet de reconnaissance pour │
│ │ │ │ │ les répétitions de couleurs codées sur 2 │
│ │ │ │ │ Octets. (Voir la section sur la méthode │
│ │ │ │ │ de compression pour plus d'informations) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 6 │ Largeur │ word │ 2 │ Largeur de l'image (en pixels) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 8 │ Hauteur │ word │ 2 │ Hauteur de l'image (en pixels) │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 10 │ Palette │ byte │ 768 │ Palette RGB (RGB RGB ... 256 fois) avec │
│ │ │ │ │ des valeurs de 0 à 63. Je sais que le │
│ │ │ │ │ standard dans les fichiers d'images est │
│ │ │ │ │ de 0 à 255 mais je trouve ça crétin! │
│ │ │ │ │ C'est tellement plus simple d'envoyer la │
│ │ │ │ │ palette toute entière dans le port 3C9h │
│ │ │ │ │ avec un REP OUTSB sans avoir à convertir │
│ │ │ │ │ la palette. │
├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤
│ 778 │ Taille_PH │ word │ 2 │ Taille du Post-header. C'est le nombre │
│ │ │ │ │ d'octets entre le header et les données │
│ │ │ │ │ de l'image. Cette valeur peut valoir 0. │
└─────┴───────────┴──────┴──────┴──────────────────────────────────────────┘
Les données du type "word" sont stockées selon les conventions d'Intel:
c'est-à-dire l'octet de poids le plus faible en premier.
Le POST-HEADER:
═══════════════
Le post-header a une taille variable. Il a été conçu pour supporter les
nouvelles fonctions de ce format sans avoir a changer complètement le format.
Il est constitué d'identificateurs de champ suivis par leur taille et leur
contenu.
Un identificateur de champ est codé sur 1 octet ainsi que sa taille.
Ces identificateurs de champ sont: (cette liste peut être rallongée...)
──────────────────────────────────
0 : Commentaire sur l'image
1 : Dimensions de l'écran d'origine
2 : Couleur de fond (couleur de transparence)
Si vous rencontrez un champ inconnu par votre routine de chargment, sautez
simplement au delà. Mais, par contre, si un champ vous dit de sauter à une
position qui tombe après le début théorique des données de l'image, alors
c'est qu'il y a une erreur dans le fichier.
Les champs:
───────────
* Commentaire:
Grâce à ce champ, les artistes vont pouvoir commenter leurs dessins.
Notez que GrafX 2 a une taille limite de commentaire de 32 caractères.
Mais vous pourrez avoir des commentaires allant jusqu'à 255 caractères
si vous créez votre propre viewer puisque GrafX 2 ignorera simplement
les caractères en trop.
Exemple: [0],[15],[Dessin de X-Man]
Cette séquence signifie:
- le champ est un commentaire
- le commentaire a une taille de 15 caractères (il n'y a pas de
caractère de fin de chaîne puisque vous connaissez sa taille)
- le commentaire est "Dessin de X-Man"
* Dimensions de l'écran d'origine:
Puisque GrafX 2 propose un énorme choix de résolutions, il a semblé
pratique d'ajouter un champ indicant quelles étaient les dimensions de
l'écran d'origine.
Exemple: [1],[4],[320],[256]
Cette séquence signifie:
- Le champ décrit les dimensions de l'écran d'origine
- Les dimensions sont 2 words (donc cette valeur doit être égale à 4)
- La largeur de l'écran d'origine était de 320 pixels
- La hauteur de l'écran d'origine était de 256 pixels
Notez que les words stockés dans les champs sont écrits à la manière
Intel. La BETA-version 90% ne respectait pas cette norme (désolé).
Ce n'est pas bien grâve mais les images sauvées avec la version 90% et
rechargées avec une version postérieure (91% et plus) ne passeront pas
dans la bonne résolution.
* Couleur de fond:
Enregistrer la couleur de fond (couleur de transparence) se révèle
particulièrement utile lorsque vous voulez sauvegarder une brosse.
La taille de ce champ est 1 octet (indice de la couleur entre 0 et 255).
Exemple: [2],[1],[255]
Cette séquence signifie:
- le champ décrit la couleur de fond
- la valeur prend 1 octet
- La couleur de transparence est 255
La METHODE DE COMPACTAGE DE L'IMAGE:
════════════════════════════════════
La méthode de compression PKM est une sorte de "Run-Length-Compression" qui
est très efficace sur les images comportant de longues répétitions d'une même
couleur horizontalement.
En fait la compression commence à être efficace s'il y a souvent plus de 3
fois la même couleur consécutivement.
Je pense qu'il est préférable de vous donner directement l'algorithme plutôt
que de nager dans des explications incomprehensibles.
DEBUT
/*
fonctions:
Lire_octet(Fichier) Lit et retourne 1 octet à partir de
Fichier
Dessiner_pixel(X,Y,Couleur) Dessine un pixel d'une certaine Couleur
à la position (X,Y)
Taille_fichier(Fichier) Retourne la taille totale d'un Fichier
en octets
variables:
le type de Taille_image est dword
le type de Taille_donnees est dword
le type de Compteur_donnees est dword
le type de Compteur_pixels est dword
le type de Couleur est byte
le type de Octet_lu est byte
le type de Word_lu est word
le type de Compteur est word
le type de Fichier est <fichier binaire>
*/
/* A cet endroit, le header et le post-header ont déjà été lus. */
Taille_image <- Header.Largeur * Header.Hauteur
Taille_donnees <- Taille_fichier(Fichier) - (780+Header.Taille_PH)
Compteur_donnees <- 0
Compteur_pixels <- 0
/* Boucle de décompression: */
TANT QUE ((Compteur_pixels<Taille_image)
ET (Compteur_donnees<Taille_donnees)) FAIRE
{
Octet_lu <- Lire_octet(Fichier)
/* Si pas un octet de reconnaissance de paquet, c'est un pixel brut */
SI ((Octet_lu<>Header.Pack_byte) ET (Octet_lu<>Header.Pack_word))
ALORS
{
Dessiner_pixel(Compteur_pixels MOD Header.Largeur,
Compteur_pixels DIV Header.Largeur,
Octet_lu)
Compteur_pixels <- Compteur_pixels + 1
Compteur_donnees <- Compteur_donnees + 1
}
SINON /* Est-ce que le nombre de pixels à répéter est codé... */
{ /* ... sur 1 octet ? */
SI (Octet_lu = Header.Pack_byte) ALORS
{
Couleur <- Lire_octet(Fichier)
Octet_lu <- Lire_octet(Fichier)
POUR Compteur ALLANT DE 0 A (Octet_lu-1) PAR PAS DE +1
Dessiner_pixel((Compteur_pixels+Compteur) MOD Header.Largeur,
(Compteur_pixels+Compteur) DIV Header.Largeur,
Couleur)
Compteur_pixels <- Compteur_pixels + Octet_lu
Compteur_donnees <- Compteur_donnees + 3
}
SINON /* ... sur 2 octets ? */
{
Couleur <- Lire_octet(Fichier)
Word_lu <- (word) (Lire_octet(Fichier) SHL 8)+Lire_octet(Fichier)
POUR Compteur ALLANT DE 0 A (Word_lu-1) PAR PAS DE +1
Dessiner_pixel((Compteur_pixels+Compteur) MOD Header.Largeur,
(Compteur_pixels+Compteur) DIV Header.Largeur,
Couleur)
Compteur_pixels <- Compteur_pixels + Word_lu
Compteur_donnees <- Compteur_donnees + 4
}
}
}
FIN
Par exemple, la séquence suivante:
(on suppose que Pack_byte=01 et Pack_word=02)
04 03 01 05 06 03 02 00 01 2C
sera décodée comme:
04 03 05 05 05 05 05 05 03 00 00 00 ... (repéter 0 300 fois (012Ch=300))
Les répétitions qui tiennent sur un word doivent être écrites avec leur
octet de poids le plus fort en premier. Je sais que ça va à l'encontre du
standard Intel mais puisque je lis les octets du fichier au travers d'un
buffer (franchement plus rapide), Je me fous complètement de l'ordre
(Désolé :)). Mais les words du header et du post-header doivent être écrits
et lus à la manière Intel!
Conseils de compactage:
───────────────────────
* Comme vous pouvez le constater, il pourrait y avoir un problème lorsque
vous devriez compacter un pixel brut de couleur égale à Pack_byte ou à
Pack_word. Ces pixels doivent toujours être codés comme des paquets même
s'il n'y a qu'un seul pixel.
Exemple: (supposons que Pack_byte=9)
9 sera encodé 9,9,1 (Le 1er 9 dans la séquence...
9,9 sera encodé 9,9,2 ... encodée est Pack_byte)
etc...
* Il semble évident de trouver des valeurs pour Pack_byte et Pack_word qui
ne sont jamais (ou presque) utilisées. Donc, une petite routine qui trouve
les 2 couleurs les moins utilisées dans l'image devrait être appelée avant
de commencer la compression. Ceci peut être réalisé presque instantanément
en Assembleur.
* Quand vous voulez écrire une séquence de 2 couleurs identiques, écrivez
simplement ces 2 couleurs l'une après l'autre (Couleur,Couleur) puisque ça
ne prend que 2 octets au lieu de 3 si vous aviez écrit un paquet (Pack_byte,
Couleur,2).
* Si vous compressez une image extrêmement simple qui comporte une séquence
de plus de 65535 fois la même couleur consécutivement, vous devez "casser"
la séquence et continuer avec un nouveau paquet.
Exemple: vous devez compacter les 65635 mêmes octets consécutifs (de
couleur 0 par exemple)
(On suppose que Pack_byte=01 et Pack_word=02)
Vous devrez alors écrire: 02 00 FF FF 01 00 64 (FFFFh=65535, 64h=100)
┌────────────────────────────────────────────────────────────────────────────┐
│ ░▒▓█ Passer dans les modes vidéos de GrafX 2.00 █▓▒░ │
└────────────────────────────────────────────────────────────────────────────┘
Toutes les procédures d'initialisation de mode sont écrites en ASM 386. De
toutes façons, si vous ne comprenez pas une ligne d'ASM, je ne vois vraiment
pas à quoi pourront vous servir ces procédures.
Elles ont été conçues pour être utilisées dans le modèle de mémoire FLAT.
Mais cela ne devrait pas vous prendre trop de temps de les adapter au modèle
que vous souhaitez utiliser puisqu'il n'y a que les manipulations de mémoire
que cela affectera (utilisez donc DS:SI au lieu de ESI, ES:DI à la place de
EDI et faîtes attention à l'adresse 0A0000h qui se transforme en l'adresse
0A000h:0000h).
MCGA: (Mode VGA standard)
═════
Y-a-t'il quelqu'un sur cette planète qui ne sache toujours pas comment
on passe en mode MCGA 320x200 en 256 couleurs ??!?
Bon... Je suppose que vous êtes un novice si vous lisez les 2 lignes
suivantes :)
mov ax,0013h
int 10h
Modes X: (Modes VGA étendus)
════════
Bon... Il me semble que le Mode X original était en 320x240, mais
maintenant tout le monde appelle "Modes X" (ou X-Modes, ou Tweaked modes)
tous les modes VGA qui utilise plus de 64Ko de mémoire vidéo et la structure
"Unchained".
Afficher un pixel dans n'importe quel Mode X peut être effectué par la
même et unique fonction (mais je ne vous expliquerai pas comment faire, il
vous suffit d'indiquer à la fonction la taille des plans (Largeur/4)).
Si vous ne comprenez rien à ce que je dis, (Unchained, plans...) il vous
suffit de lire n'importe quelle bonne documentation sur le Mode X.
Nous tenons à remercier les auteurs de XLIB2 pour nous avoir économisé du
temps en ayant écrit cette fonction. Nous l'avons légèrement optimisée en
fonction de nos besoins, mais l'essentiel en a été conservé.
mov ax,13h ; Oui! Encore le mode MCGA! Tous les Modes X doivent
int 10h ; commencer à partir du mode VGA standard, mais bien des
; choses changent par la suite.
mov dx,3C6h ; Pour la durée de l'initialisation, on va éteindre la
xor al,al ; palette de façon à ce que l'utilisateur ne subisse pas
out dx,al ; nos triturations.
mov dx,3C4h ; Nous allons demander au registre TIMING SEQUENCER de
mov ax,0604h ; passer dans le mode "Unchained" (mode X), sans gérer de
out dx,ax ; parité, et un accès aux 256Ko de la carte vidéo.
mov ax,0100h ; On va ensuite enclencher le reset synchrone du registre
out dx,ax ; TS car on s'apprête à jouer avec les registres.
mov al,01h ; De la même façon que pour la palette, on demande à la
out dx,al ; carte vidéo de ne plus scruter la mémoire pour
inc dx ; afficher son contenu. Ainsi, c'est une façon de plus
in al,dx ; d'éviter l'affichage parasite qui arrive le temps que
mov ah,al ; le mode soit totalement initialisé et stabilisé.
mov al,01h ; De plus, on peut espérer qu'en demandant un arrêt de
push ax ; la lecture de la mémoire, le système s'en voit un peu
mov al,ah ; accéléré, et ainsi accélérer l'initialisation du mode
or al,20h ; graphique (l'espoir fait vivre :))
out dx,al ;
mov esi,X_ptr ; Pointeur sur la liste des constantes à envoyer au CRTC.
cld
lodsb ; Ceci charge dans AL une valeur qui nous dira quoi faire
; avec le registre MISCELLANEOUS, et incrémente ESI.
; La valeur est égale à ZERO => Rien à faire
; sinon => Envoyer AL au reg. MISC.
or al,al ; Devons nous modifier le mode vidéo de base ?
jz NonMerci ; Non?─┐ En fait, la réponse est toujours "Oui".
mov dx,3C2h ; │ Sauf pour quelques modes tels que le
out dx,al ; │ 320x200 en Mode X
NonMerci: ; <────┘ (mais notre mode 320x200 est en MCGA...)
mov dx,3C4h ; On en a terminé avec les manipulations du registre
mov ax,0300h ; MISCELLANEOUS, on peut maintenant désenclencher le
out dx,ax ; reset synchrone du registre TIMING SEQUENCER.
; Et maintenant, si on jouait avec le CRTC?
mov dx,3D4h ; Dans le 18ème registre du CRTC, on va désenclencher le
mov al,11h ; bit de protection. Sans cela, les valeurs que nous
out dx,al ; aurions envoyées aux registres du CRTC auraient été
inc dx ; ignorées.
in al,dx
and al,7Fh
out dx,al
dec dx ; DX pointe à nouveau sur "l'entrée" du registre CRTC.
lodsb ; Ceci met dans AL le nombre de registres CRTC à changer
xor ecx,ecx ; On doit nettoyer ECX avant de commencer à répéter...
mov cl,al ; ...CL (AL) fois OUTSW
rep outsw ; On peut envoyer la sauce aux registres du CRTC!
; Juste au cas où le 20ème registre CRTC aurait été oublié dans la table
; d'initialisation, on peut le calculer nous-mêmes (Ouaip, on est des
; braves gars).
mov ax,Screen_width ; Vous devez indiquer à la routine quelle est la
shr ax,3 ; largeur de l'écran
mov ah,al
mov al,13h
out dx,ax
mov dx,3C4h ; Maintenant vous avez la bonne résolution mais il peut
mov ax,0F02h ; y avoir des pixels pourris à l'écran à cause de zones
out dx,ax ; non nettoyées de la mémoire vidéo.
mov edi,0A0000h ; Donc on va nettoyer la mémoire à partir de 0A0000h
xor eax,eax ; avec la valeur 0 (qui est le noir standard) et sur une
mov ecx,4000h ; longueur de 4000h dwords (256Ko).
rep stosd ; Allez, liquidez-moi tout ça!
mov dx,3C4h ; On peut redemander à la carte VGA de relire la mémoire
pop ax ; pour afficher l'écran...
out dx,ax ;
mov dx,3C6h ; ... et rétablir la palette pour que l'image soit
mov al,0FFh ; visible à l'utilisateur.
out dx,al ;
La table de constantes que vous devez employer est l'une des suivantes:
(Ces tables sont au format C, mais elles peuvent facilement êtres employées
dans d'autres langages)
word X320Y224[] =
{ 0x0BA3, 0x6F06, 0xBA07, 0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x0014,
0xC715, 0x0416, 0xE317 };
word X320Y240[] =
{ 0x0AE3, 0x0D06, 0x3E07, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715,
0x0616, 0xE317 };
word X320Y256[] =
{ 0x0CE3, 0x2306, 0xB207, 0x0008, 0x6109, 0x0A10, 0xAC11, 0xFF12, 0x2013,
0x0014, 0x0715, 0x1A16, 0xE317 };
word X320Y270[] =
{ 0x0BE7, 0x3006, 0xF007, 0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x0014,
0x1F15, 0x2F16, 0xE317 };
word X320Y282[] =
{ 0x0CE3, 0x6206, 0xF007, 0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x2F13,
0x0014, 0x3C15, 0x5C16, 0xE317 };
word X320Y300[] =
{ 0x0DE3, 0x4606, 0x1F07, 0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2013,
0x0014, 0x2F15, 0x4416, 0xE317 };
word X320Y360[] =
{ 0x09E3, 0x4009, 0x8810, 0x8511, 0x6712, 0x2013, 0x0014, 0x6D15, 0xBA16,
0xE317 };
word X320Y400[] =
{ 0x03E3, 0x4009, 0x0014, 0xE317 };
word X320Y448[] =
{ 0x0BA3, 0x6F06, 0xBA07, 0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x0014,
0xC715, 0x0416, 0xE317 };
word X320Y480[] =
{ 0x0AE3, 0x0D06, 0x3E07, 0x4009, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715,
0x0616 , 0xE317};
word X320Y512[] =
{ 0x0CE3, 0x2306, 0xB207, 0x0008, 0x6009, 0x0A10, 0xAC11, 0xFF12, 0x2013,
0x0014, 0x0715, 0x1A16, 0xE317 };
word X320Y540[] =
{ 0x0BE7, 0x3006, 0xF007, 0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x0014,
0x1F15, 0x2F16, 0xE317 };
word X320Y564[] =
{ 0x0CE7, 0x6206, 0xF007, 0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x2013,
0x0014, 0x3C15, 0x5C16, 0xE317 };
word X320Y600[] =
{ 0x0BE7, 0xBE06, 0xF007, 0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x0014,
0x5815, 0x7016, 0xE317 };
word X360Y200[] =
{ 0x09E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2D13, 0x0014,
0xE317 };
word X360Y224[] =
{ 0x12A7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6F06, 0xBA07,
0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x2D13, 0x0014, 0xC715, 0x0416,
0xE317 };
word X360Y240[] =
{ 0x11E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x0D06, 0x3E07,
0x4109, 0xEA10, 0xAC11, 0xDF12, 0x2D13, 0x0014, 0xE715, 0x0616, 0xE317 };
word X360Y256[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2B06, 0xB207,
0x0008, 0x6109, 0x0E10, 0xAC11, 0xFF12, 0x2D13, 0x0014, 0x0715, 0x1A16,
0xE317 };
word X360Y270[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x3006, 0xF007,
0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x2D13, 0x0014, 0x1F15, 0x2F16,
0xE317 };
word X360Y282[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6206, 0xF007,
0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x2D13, 0x0014, 0x3C15, 0x5C16,
0xE317 };
word X360Y300[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4606, 0x1F07,
0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2D13, 0x0014, 0x2F15, 0x4416,
0xE317 };
word X360Y360[] =
{ 0x0FE7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4009, 0x8810,
0x8511, 0x6712, 0x2D13, 0x0014, 0x6D15, 0xBA16, 0xE317 };
word X360Y400[] =
{ 0x0AE7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4009, 0x2D13,
0x0014, 0xE317 };
word X360Y448[] =
{ 0x12A7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6F06, 0xBA07,
0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x2D13, 0x0014, 0xC715, 0x0416,
0xE317 };
word X360Y480[] =
{ 0x11E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x0D06, 0x3E07,
0x4009, 0xEA10, 0xAC11, 0xDF12, 0x2D13, 0x0014, 0xE715, 0x0616, 0xE317 };
word X360Y512[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2B06, 0xB207,
0x0008, 0x6009, 0x0E10, 0xAC11, 0xff12, 0x2D13, 0x0014, 0x0715, 0x1A16,
0xE317 };
word X360Y540[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x3006, 0xF007,
0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x2D13, 0x0014, 0x1F15, 0x2F16,
0xE317 };
word X360Y564[] =
{ 0x12EB, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6206, 0xF007,
0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x2D13, 0x0014, 0x3C15, 0x5C16,
0xE317 };
word X360Y600[] =
{ 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0xBE06, 0xF007,
0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x2D13, 0x0014, 0x5815, 0x7016,
0xE317 };
word X400Y200[] =
{ 0x09E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3213, 0x0014,
0xE317 };
word X400Y224[] =
{ 0x12A7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6F06, 0xBA07,
0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x3213, 0x0014, 0xC715, 0x0416,
0xE317 };
word X400Y240[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x0D06, 0x3E07,
0x0008, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x3213, 0x0014, 0xE715, 0x0616,
0xE317 };
word X400Y256[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x2B06, 0xB207,
0x0008, 0x6109, 0x1310, 0xAC11, 0xFF12, 0x3213, 0x0014, 0x0715, 0x1A16,
0xE317 };
word X400Y270[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3006, 0xF007,
0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x3213, 0x0014, 0x1F15, 0x2F16,
0xE317 };
word X400Y282[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6206, 0xF007,
0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x3213, 0x0014, 0x3C15, 0x5C16,
0xE317 };
word X400Y300[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4606, 0x1F07,
0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x3213, 0x0014, 0x2F15, 0x4416,
0xE317 };
word X400Y360[] =
{ 0x0FE7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4009, 0x8810,
0x8511, 0x6712, 0x3213, 0x0014, 0x6D15, 0xBA16, 0xE317 };
word X400Y400[] =
{ 0x0AE7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4009, 0x3213,
0x0014, 0xE317 };
word X400Y448[] =
{ 0x12A7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6F06, 0xBA07,
0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x3213, 0x0014, 0xC715, 0x0416,
0xE317 };
word X400Y480[] =
{ 0x11E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x0D06, 0x3E07,
0x4009, 0xEA10, 0xAC11, 0xDF12, 0x3213, 0x0014, 0xE715, 0x0616, 0xE317 };
word X400Y512[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x2B06, 0xB207,
0x0008, 0x6009, 0x1310, 0xAC11, 0xFF12, 0x3213, 0x0014, 0x0715, 0x1A16,
0xE317 };
word X400Y540[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3006, 0xF007,
0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x3213, 0x0014, 0x1F15, 0x2F16,
0xE317 };
word X400Y564[] =
{ 0x12EB, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6206, 0xF007,
0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x3213, 0x0014, 0x3C15, 0x5C16,
0xE317 };
word X400Y600[] =
{ 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0xBE06, 0xF007,
0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x3213, 0x0014, 0x5815, 0x7016,
0xE317 };
La structure: (exemple)
┌────Ceci est le nombre de valeurs à envoyer aux registres CRTC. C'est
│ en fait le nombre de words dans la table moins 1 (à cause du 1er
│ word de la table qui n'est pas envoyé au CRTC mais qui contient
│ une valeur à envoyer au registre MISCELLANEOUS et le nombre de
│ valeurs à envoyer aux registres CRTC ;) ).
│
│ ┌──Ceci est la valeur à envoyer au registre MISCELLANEOUS (ou 0 si
│ │ aucune valeur ne doit y être envoyée).
│ │
│ │ ┌───Ceci est une valeur à envoyer dans un registre du CRTC.
│ │ │
│ │ │ ┌─Ceci est le numéro du registre du CRTC qui recevra la
│ │ │ │ valeur citée précédemment.
├┐├┐ ├┐├┐
{ 0x0AE3, 0x0D06, 0x3E07, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715,
0x0616, 0xE317 };
Vous pouvez remarquer que les registres 0 à 5 (et le 13h) du CRTC
définissent la largeur de l'écran, alors que les registres 6 à 17h (à
l'exception du 13h) definissent la hauteur de l'écran.
Nous avons plus de modes en poche que les quelques-uns :) que nous avons
inclus dans GrafX 2.00, mais ils ne sont ni vraiment utiles ni vraiment
stables. Nous pourrons toutefois décider de les inclure dans une prochaine
version.
S'il manque certains de vos modes préféres, envoyez nous simplement la
liste des constantes que l'on doit balancer au CRTC à la manière de la
structure utilisée ci-dessus.
IMPORTANT! Les valeurs des constantes citées plus haut ne sont pas
supportées par tous les moniteurs ou les cartes vidéos.
Nous avons testé GrafX2 avec différentes configurations et avons
constatés que certains modes ne marchent pas du tout avec
certaines cartes vidéos, alors que d'autres débordent de l'écran,
sont décentrés, assombris, trop clairs, ou tassés.
Toutefois, ils marchent tous correctement avec notre pauvre
petite Tseng Labs ET4000...
Si vous avez déjà une bonne connaissance à propos du CRTC, et avez des
valeurs différentes des notres pour certains modes, merci de nous en
informer. Nous nous en servirons s'ils marchent mieux sur une majorité
d'ordinateurs.
VESA: (Un "pseudo-standard" pour les modes Super-VGA)
═════
Nous nous servons du VESA pour des modes qui nécessitent une largeur de
640, 800 ou 1024 pixels. Mais il existe un moyen de combiner la hauteur des
Modes X avec les modes VESA, il est ainsi possible d'avoir des modes aussi
timbrés qu'en Mode X.
mov ax,4F02h
mov bx,Video_mode
int 10h
Les modes VESA 256 couleur VESA sont:
100h : 640x400
101h : 640x480
103h : 800x600
105h : 1024x768
107h : 1280x1024 (non disponible dans GrafX2 parce qu'uniquement supporté
par des cartes vidéo avec 2 Megaoctets ou plus de mémoire
vidéo)
Comme avec les Modes X, vous pouvez modifier les registres CRTC pour accéder
aux modes "VESA-X"! (Notez que certaines cartes vidéo ne supportent pas les
modifications des registres du CRTC VGA dans les modes VESA.)
Pour passer dans ces modes étendus, passez dans un mode VESA standard ayant
la bonne largeur, puis appelez Modif_registres_CRTC avec la bonne table de
hauteur.
Exemple (640x512) :
VESA_Set_mode(101h) // On passe dans un mode qui a la même largeur
Modif_registres_CRTC(Y512) // On modifie la hauteur
* Tables des hauteurs:
word Y224[] =
{ 0x09A3, 0x6F06, 0xBA07, 0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0xC715,
0x0416 };
word Y240[] =
{ 0x09E3, 0x0D06, 0x3E07, 0x0008, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0xE715,
0x0616 };
word Y256[] =
{ 0x0900, 0x2B06, 0xB207, 0x0008, 0x6109, 0x0A10, 0xAC11, 0xFF12, 0x0715,
0x1A16 };
word Y270[] =
{ 0x09E7, 0x3006, 0xF007, 0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x1F15,
0x2F16 };
word Y282[] =
{ 0x0AE3, 0x6206, 0xF007, 0x0008, 0x6109, 0x310F, 0x3710, 0x8911, 0x3312,
0x3C15, 0x5C16 };
word Y300[] =
{ 0x09E3, 0x4606, 0x1F07, 0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2F15,
0x4416 };
word Y350[] =
{ 0x09A3, 0xBF06, 0x1F07, 0x0008, 0x4009, 0x8310, 0x8511, 0x5D12, 0x6315,
0xBA16 };
word Y360[] =
{ 0x07E3, 0x0008, 0x4009, 0x8810, 0x8511, 0x6712, 0x6D15, 0xBA16 };
word Y400[] =
{ 0x01E3, 0x4009 };
word Y448[] =
{ 0x09A3, 0x6F06, 0xBA07, 0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0xC715,
0x0416 };
word Y480[] =
{ 0x09E3, 0x0D06, 0x3E07, 0x0008, 0x4009, 0xEA10, 0xAC11, 0xDF12, 0xE715,
0x0616 };
word Y512[] =
{ 0x0900, 0x2B06, 0xB207, 0x0008, 0x6009, 0x0A10, 0xAC11, 0xFF12, 0x0715,
0x1A16 };
word Y540[] =
{ 0x09E7, 0x3006, 0xF007, 0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x1F15,
0x2F16 };
word Y564[] =
{ 0x09E7, 0x6206, 0xF007, 0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x3C15,
0x5C16 };
word Y600[] =
{ 0x09E7, 0xBE06, 0xF007, 0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x5815,
0x7016 };
Modifier les registres CRTC: (inspiré de l'init. des Modes X... voir plus
──────────────────────────── haut pour de plus amples détails)
mov esi,XVESA_Ptr
cld
lodsb
or al,al ; Devons nous modifier le mode vidéo de base ?
jz NonMerci ; Non?─┐ La réponse peut être "Non" car les initialisations
mov dx,3C2h ; │ de certains modes VESA mettent directement la
out dx,al ; │ bonne valeur pour le registre MISCELLANEOUS.
NonMerci: ; <────┘
mov dx,3D4h
mov al,11h
out dx,al
inc dx
in al,dx
and al,7Fh
out dx,al
dec dx
lodsb
xor ecx,ecx
mov cl,al
rep outsw
Si vous êtes suffisament astucieux, vous pourrez combiner les constantes
utilisées dans les Modes X pour obtenir plus de modes "VESA-X" tels que le
640x200, 800x480, etc... (mais je ne pense pas que ça marche convenablement
avec les largeurs de 1024 pixels puisque ce mode est généralement
entrelacé... Mais qui sait?...)
Je pense que le plus difficile est de trouver la bonne valeur du registre
MISCELLANEOUS.