fredriks@cat40.CS.WISC.EDU (Lars Fredriksen) (02/14/89)
Does anyone know the format for the Borland BGI terminal driver files? I am trying to incorporate the features of my own graphics display into the Borland packet, and it seems almost impossible. I know that Borland main- tains that the format is proprietary, but I would still like to use it for my private programs. So again, has anyone deciphered the BGI format? --Lars Fredriksen
dmurdoch@watdcsu.waterloo.edu (D.J. Murdoch - Statistics) (02/14/89)
In article <2260@puff.cs.wisc.edu> fredriks@cat40.CS.WISC.EDU (Lars Fredriksen) writes: > >Does anyone know the format for the Borland BGI terminal driver files? I >am trying to incorporate the features of my own graphics display into the >Borland packet, and it seems almost impossible. I know that Borland main- >tains that the format is proprietary, but I would still like to use it for >my private programs. So again, has anyone deciphered the BGI format? > --Lars Fredriksen I haven't, but others have: Here's something I picked up on Compuserve. It's missing a lot of details, but gives a good start. In particular, it doesn't tell the format of arguments being passed to the driver, or how the driver lets GRAPH know things like MaxX, MaxColor, etc. ------- ATTDOC.TXT -------- This document is released due to inquiries about the structure of the BGI driver ATTDEB that I recently uploaded. It should be noted that this is relative to TP5, and that the information presented here is from my "investigation" of GRAPH.TPU. There COULD be inaccurate information presented but ATTDEB.BGI does work! If I read my mail correctly, there was a concern with TP's requirement that all code is in segment CODE. That is only a problem for OBJ files combined at compile time (with {$L ...}). A BGI is loaded at run time as a BIN type file (ie: just load the file, no fixups), so there is no CODE restriction. GRAPH.TPU assumes everything starts at the right offset from the beginning of the file. So to create a BGI file this is the procedure: 1. Create your ASM source with two segments. The first segment is the 160 byte header that precedes your actual code. Make sure that this segment is 160 bytes long so that the next segment will start in the right place. The second segment is the actual BGI driver code. For ease of linking no matter what LINK options are used, give the first segment an alphabetically lower name. [ Note: This didn't work for me using A86 and LINK. I had to add class name 'BGI' to both segments to get them right. -djm] 2. Then do the following assembly steps (assuming a source name ATTDEB.ASM): a. ; Create an OBJ file >>> TASM ATTDEB ; This creates ATTDEB.OBJ b. ; Create an EXE file >>> LINK ATTDEB,ATTDEB; ; This creates ATTDEB.EXE c. ; Finally make your BGI file >>> EXE2BIN ATTDEB ATTDEB.BGI You now have a functional (if YOUR code is correct) BGI driver. What now follows is the begining of my source for ATTDEB.BGI. My philosophy is Learn by Example works best. ;-----------------------------------------------; ; ATTDEB.BGI ; ; Borland Graphic Interface For TP 5.0 ; ; AT&T Display Enhancement Board ; ; Copyright (c) 1988 Ritchey Software Assoc. ; ;-----------------------------------------------; ; ACODE segment 'BGI' ; ; Note: All values that don't have comments explaining them ; were identical in all BOR supplied BGIs, so they were ; just plugged in here. (I don't know what they are!) ; astart DB 'pk' ; BGI magic word (Phillipe K.) DB 8,8 DB 'BGI Device Driver (AT&T) V2.00 - 25 October 1988 ' db 0Dh,0Ah DB 'Copyright (c) 1988 Ritchey Software Assoc.',0Dh,0Ah db 0,1Ah dw 00A0h,11 dw endofcode ; This is a label that precedes CODE ENDS dw 2 db 1,1 org 80h dw 00A0h,11 dw endofcode ; see above dw 2 db 1,1 ; The following is supposed to be returned by GetDriverName, but ; because of GRAPH keeps two tables of driver numbers it won't. db 6,'ATTDEB' alen = $-astart ; Pad this segment out to db (160 - alen) dup(0) ; 160 bytes ACODE ends CODE SEGMENT 'BGI' ; ; Now for the real BGI driver code. A separate segment is required ; because although this code starts at offset 0A0h in the file ; ATTDEB.BGI, GRAPH will adjust its address up by 10 paras and then ; do a CALL FAR xxxx:[0000]. So all memrefs have to be 0 relative to ; the label BGIENTRY below. IMPORTANT: All code from here to JMP_TABLE ; needs to be exactly as it is. GRAPH expects the label NOP_01 to be ; at the offset that it is in this code (GRAPH is going to shove code ; blindly at that location). ; ASSUME CS:CODE,DS:CODE BGIENTRY PROC FAR ; "FAR" So that the RET is a RETF PUSH DS ; Save DATA's value PUSH CS POP DS ; Make the ASSUMption correct CLD PUSH BP ; Save TP Stack Frame Ptr ; ; GRAPH puts the Function number to be performed in SI. It is really ; a table index because all SI values are even. ; CALL [SI+JMP_TABLE] ; See JMP_TABLE Below POP BP ; Restore TP Stack Frame Ptr POP DS ; Restore DATA RET ; Back to GRAPH BGIENTRY ENDP ; db 'CB' ; You've got me! but it's here in dw 0 ; all BGI files (I know 0CBh is RETF) ; NOP_01 PROC NEAR ; This becomes a Call to an entry point RET ; in GRAPH's "generic" BGI driver code dw 0 ; to handle functions that individual dw 0 ; drivers don't need to (ie: non-machine NOP_01 ENDP ; specific functions). NOP_02 PROC NEAR ; a common return for all non- RET ; implemented functions NOP_02 ENDP ; Now for the Jump Table; The SVC_xx labels correspond to the ; value in SI when the driver is called(ie: SVC_00 is the entry point ; when SI = 0. IF the labels are NOP_01 or NOP_02 the value of SI is ; to the right in braces. NOP_02 means this function is a NOP and ; GRAPH should never call it (at least relative to TP5). The label ; NOP_01 is a JMP to a CALL back to GRAPH to perform the function. ; (Aren't you glad you don't have to write a Circle Drawing Algorithm!) ; ; It should also be noted that calls to the BGI code are both pre- ; processed and post-processed by GRAPH. Some calls never make it to ; your code. One example is the DisplayText functions. The only time ; that calls make it here is for the bit-map text displays. GRAPH ; handles all of the stroked CHR fonts. ; jmp_table dw svc_00 ; Initialize dw svc_02 ; Set Mode dw svc_04 ; Clear Graphics Screen dw nop_02 ; { 06 } dw SVC_08 ; set current pointer (CP) dw SVC_0A ; draw line from CP to new CP dw SVC_0C ; Draw Line dw nop_01 ; {0E} Draw/Fill Poly dw NOP_01 ; {10} Bar3D dw SVC_12 ; Bar dw NOP_01 ; {14} Draw Circle dw NOP_01 ; {16} Draw Pie Slice dw NOP_01 ; {18} Draw Ellipse dw SVC_1A ; Set Palette dw SVC_1C ; Set All Palette dw SVC_1E ; Set Color dw SVC_20 ; Set Fill Style/Pattern dw SVC_22 ; Set Line Style/Pattern dw SVC_24 ; Set UserCharSize dw SVC_26 ; Display Text dw SVC_28 ; Text Width/Height dw NOP_01 ; { 2A } ; I never figured this one out ! ; GRAPH handles it anyway. dw SVC_2C ; FloodFill dw SVC_2E ; GetPixel dw SVC_30 ; SetPixel dw SVC_32 ; Set CallTable dw SVC_34 ; GetImage dw SVC_36 ; PutImage dw SVC_38 ; Set View Min/Max dw svc_3A ; SetParameters dw NOP_02 ; 3C dw NOP_02 ; 3E dw NOP_02 ; 40 dw NOP_02 ; 42 dw NOP_02 ; 44 dw NOP_02 ; 46 dw NOP_02 ; 48 dw NOP_02 ; 4A dw NOP_02 ; 4C dw NOP_02 ; 4E dw NOP_02 ; 50 dw NOP_02 ; 52 dw NOP_02 ; 54 dw NOP_02 ; 56 dw NOP_02 ; 58 dw NOP_02 ; 5A ; . . . . Code to support the above functions goes here . . . endofcode label byte ; This is the label ref'd in ACODE segment CODE ENDS END And so ends this short tutorial on the BGI file structure. I hope it is of use to you. Any Comments or questions would be appreciated. Pat Ritchey, CIS [72537,2420] Ritchey Software Assoc. PO BOX 88 Canal Winchester, OH 43110 ------- end of ATTDOC.TXT ---------
bobc@killer.DALLAS.TX.US (Bob Calbridge) (02/14/89)
In article <2260@puff.cs.wisc.edu>, fredriks@cat40.CS.WISC.EDU (Lars Fredriksen) writes:
+
+ Does anyone know the format for the Borland BGI terminal driver files? I
+ am trying to incorporate the features of my own graphics display into the
+ Borland packet, and it seems almost impossible. I know that Borland main-
+ tains that the format is proprietary, but I would still like to use it for
+ my private programs. So again, has anyone deciphered the BGI format?
+ --Lars Fredriksen
I would like to know in addition if the .BGI files are allowed to be
distributed if you write a program using them for the benefit of others.
That is, if I write a program for someone using .BGI files, can I give them
a copy of .BGI files in order to make the program run?
Bobmesmo@Portia.Stanford.EDU (Chris Johnson) (02/15/89)
In article <7156@killer.DALLAS.TX.US> bobc@killer.DALLAS.TX.US (Bob Calbridge) writes: > >I would like to know in addition if the .BGI files are allowed to be >distributed if you write a program using them for the benefit of others. >That is, if I write a program for someone using .BGI files, can I give them >a copy of .BGI files in order to make the program run? Quoting from the Turbo-C 2.0 (update) manual license statement: "Included in the Turbo C diskettes are several support files that contain encoded hardware and font information used by the standard graphics library (GRAPHICS.LIB). These files, which can be listed by typing DIR *.CHR and DIR *.BGI, are proprietary to Borland International. You may use these files with the programs you create with Turbo C for your own personal use. In addition, to the extent the programs you write and compile using the Turbo C language compiler make use of these suppot files, you may distribute these support files in combination with such programs, provided you do not use, give away, or sell the support files separately, and all copies of such programs bear a copyright notice." In a previous discussion, it came out that the copyright may be yours, or Borland's copyright statement accompanying Turbo C. RTFM! Just kidding. -- ============================================================================== Chris M Johnson === mesmo@portia.stanford.edu === "Grad school sucks rocks" ==============================================================================
bobc@killer.DALLAS.TX.US (Bob Calbridge) (02/17/89)
In article <342@Portia.Stanford.EDU>, mesmo@Portia.Stanford.EDU (Chris Johnson) writes: - In article <7156@killer.DALLAS.TX.US> bobc@killer.DALLAS.TX.US (Bob Calbridge) - writes: - > - >I would like to know in addition if the .BGI files are allowed to be - >distributed if you write a program using them for the benefit of others. - >That is, if I write a program for someone using .BGI files, can I give them - >a copy of .BGI files in order to make the program run? [some stuff deleted on Borland's policy] - In a previous discussion, it came out that the copyright may be yours, or - Borland's copyright statement accompanying Turbo C. - - RTFM! Just kidding. ^^^^ | |_____ I know what you mean but the program was left on my office machine when I took over the job and there was no FM to R. However, I have placed an order for version 2.0 and should have all the F material to R. :-) Me too! Bob