Contents of the PNL011.TXT file
Issue #11 September,1992
The Pascal Newsletter (C) Copyright 1992 by Alex Boisvert
ALL RIGHTS RESERVED
   
    
     
    
    
    
   
   
T H E I N T E R N A T I O N A L P A S C A L N E W S L E T T E R
Table of Contents
(*) Introduction ................................................. 2
by Alex Boisvert - Editor, Writer
(*) Technojock's Object Toolkit -- A Review....................... 3
by Stephan Patterson - Contributing Writer
(*) MCGA Graphics Tutorial - Part 1............................... 5
by James Cook
(*) Conclusion ................................................... 11
by Alex Boisvert - Editor, Writer
(*) Distribution list............................................. 12
The Pascal Newsletter is published by Alex Boisvert as a medium for all
Pascal programmers to share ideas, comments, techniques or experiences
concerning any subject related to the Pascal programming language.
DataMAX BBS is the home of PNL. It can be reached in Sherbrooke,
Quebec, Canada at (819) 563-6327 or FidoNet @ 1:167/405.0 between 23:00
and 8:00 Eastern Standard Time.
Articles and source code submitted by others are the property of the
authors and are used with permission. They may not be treated
separately from this newsletter without the author's permission and thus
maintain all distribution rules of the newsletter as a whole. It may be
freely distributed in un-modified form, but no charge whatsoever may be
incurred on the recipient. All code is provided 'as-is' with no
PNL #11 Page 2 September, 1992
Introduction - Editor's Note
Hello Everybody! (ie. fellow pascal programmers)
I have good news and bad news for all of you. To be a little
pessimistic, I will start with the bad news.
First, the Pascal News Letter has not been published since March 1992
(that means 6 months ago.) Not very good for a bimonthly newsletter...
The question is why?
Why? I have two simple answers. First, I did not receive enough
articles to fill one issue. Secondly, my computer was stolen! This
means that the articles I had personally written were lost. Oh well, I
still have ONE UNIQUE ARTICLE to publish (except my own) because IT IS
ALL THAT I HAVE RECEIVED.
Wait. I am lying. I have two articles... because I have contacted
James Cook to have his permission to publish his series of tutorial on
Now, the good news. Notwithstanding all this, I have decided to publish
this issue of PNL... to "market it" better. That's right. I think that
if I can get one issue out every 1-2 month(s), the newsletter will
become more popular and eventually [read: hopefully], I will get
articles to fill it.
But there's MORE!
I now have a few new ideas behind my head to get PNL out of the water.
Advertising will now be tolerated to a greater extent. Hey! If any
company wants to advertise in PNL, just contact me personally. Software
developers, Pascal compiler writers, shareware unit coder now have their
place in PNL. 'still more. Are there any Pascal user groups just
waiting for FREE advertisement out there? Here's your chance to get
worldwide advertisement, and attract MORE members, possibly make more
money, and help the Pascal community to get the information they need.
[see conclusion for more on this.]
Enough said now. You have PNL #11 in hand and PNL #12 will be out by
Christmas. But don't forget your gift to the Pascal community: Write
your OWN article!
PNL's New Chief Editor.
PNL #11 Page 3 September, 1992
Technojock's Object Toolkit -- A Review
by Stephan Patterson
Professional programmers know that a program's user interface can
require a very large portion of the development time. The Object
Toolkit, by Technojock Software is designed to help you implement the
type of interface users have come to expect from professional software
with a minimum of effort on your part. In a collection of objects,
procedures and functions, the Toolkit provides the programmer with ready
to use routines for building pull-down, pop-up and Lotus-style menus,
displaying messages and prompts, handling data input with validation,
pick lists, radio buttons and check boxes, memo fields with scroll bars
and all, providing keyboard and mouse support, displaying and managing
string arrays or linked lists, browsing files, displaying directories,
manipulating strings, ascertaining hardware and operating system
configurations, managing Julian and Gregorian dates and more.
Considering the overall usability of the Toolkit, a lot of thought and
experience evidently have gone into the design process. The object
hierarchy makes it easy to derive objects with precisely the
functionality you want without too much overhead. Global objects define
colors, special characters and keys used for displaying and controlling
windows, menus and lists and there are methods to easily access and
modify these values, making it easy to change the overall look and feel
of an application on command. There are several means of extending the
Object Toolkit and the manual devotes a whole chapter to the subject.
Each unit includes a configuration file with various defines and
compiler directives, include it in your own program files and with only
one change to this configuration you can modify the optimization options
that affect your program as a whole.
The User's Manual is an outstanding piece of work. While programming
libraries typically provide good reference manual, they usually fall
short of providing documentation that's useful at the early stage of
your learning the library. Technojock's Toolkit does not suffer from
this shortcoming. The manual demonstrates step by step the capabilities
of the Toolkit, and is nevertheless thoroughly indexed both by topic and
by method for easy reference. It includes several screen-shots and
reference tables, and special notes, tricks and traps are in grayed
areas to grab your attention. The manual also features the best
introduction to the concept of object oriented programming I've ever
read. The author even adds a slight touch of humor throughout the manual
to keep you smiling. Clearly, user's manuals don't get much better than
The Toolkit also comes with a multitude of small example programs
demonstrating quite adequately the capabilities of the library.
Programmers will learn a lot by studying and modifying these examples.
The Toolkit does have its weak points, however. The first release of the
toolkit had several minor bugs, nuisances and an embarrassing error in
the manual on the subject of overlays in Turbo Pascal that should have
PNL #11 Page 4 September, 1992
been identified by beta testers and corrected before the general
release. The maximum number of user-defined buttons that can be added to
a form is set to ten and I quickly had to modify the source to raise it
to a higher value. The Toolkit has provisions for international
requirements for date, time, currency and number formats, but that's not
enough. In order to change the default capitalization routine to one
that better suits foreign characters, you will have to make several
minor modifications to the source code. In some (admittedly rare)
instances, strings are hard coded into the source, making translation to
foreign languages more difficult than it could be. Finally, this is a
large and extensive library, and the source code is not commented very
well. If you have to modify it directly you may have a hard time finding
your way around. However, those are minor complaints, which may not
affect a programmer who develops only for internal use or the casual
Of course, Technojock's Object Toolkit is not without competition.
Borland supplies its Turbo Vision application framework free with Turbo
Pascal v6.0, and there's TurboPower with its impressive Object
Professional package. Borland's Turbo Vision is object oriented and
event-driven like Technojock's Object Toolkit, but the latter's
conception makes it much easier to use only the parts you need, and to
modify the default look and feel, and behavior of your applications.
TurboPower's Object Professional is not event- driven and designing an
SAA/CUA style user interface is considerably more difficult than with
the Toolkit. But in all fairness, Object Professional provides
capabilities that the Toolkit won't even attempt, like TSR programming
and printer control, among others. Then again, nothing prevents you from
using Object Professional or another library as a general purpose
programming library to complement the Toolkit when needed.
In conclusion, I have used Technojock's Object Toolkit very extensively
for almost a year now and have come to expect a lot from it. Needless to
say I have not been disappointed.
The Object Toolkit is published by:
PO Box 820927 Houston TX 77282-0927 USA
Phone: (713) 493-6354 -- Fax: (713) 493-5872
Compuserve: 74017,227 -- MCI Mail: TECHNOJOCK
Technojock's Object Toolkit is shareware. The registration price is
$89.95 plus shipping, and includes the complete program disk(s) with
source and example programs, two typeset manuals (User's Manual, Flash
Cards) and a reference card with all composite display attributes, CRT
color constants, and keyboard and mouse codes. Borland Turbo Pascal v5.5
and later, and Stony Brook Pascal+ compilers are supported.
About the author:
Stephan Patterson provides software development services as well as
technology consulting to small and medium-size businesses in Quebec,
Canada. He can be reached on Compuserve at 70313,1071 or by Fido NetMail
PNL #11 Page 5 September, 1992
MCGA Graphics Tutorial - Part 1
by James Cook
[Editor's note: This is the first two parts of several lessons dealing
with MCGA graphics. The original text was posted by James Cook on the
FidoNet international Pascal conference. With Mr. Cook's permission, I
am publishing these lessons separately in PNL. Look for more lessons in
upcoming issues! (James has currently written 7 lessons in all.]
I'm not sure how this online tutorial will be received, but with your
comments and feedback I plan on creating a full-blown animation package.
This graphics library will be available to the public domain and will
contain the following abilities:
Saving/Restoring areas of the screen
Displaying PCX/LBM files to the screen
Spriting (Display picture with transparent areas)
Palette control (Smooth fades to black)
Before we're done, you will have the tools to produce programs with
rich, even photo-realistic (for the resolution) images on your PC. The
necessary hardware is a VGA card and monitor that's it. I'll be using
Turbo Pascal version 6.0. Please holler if that will be a problem. I'm
using it to create inline assembly. My alternatives are inline code
(yuk) or linking in external assembly. For speed (and actually ease)
the latter is better. If I receive three complaints against 6.0, I'll
use external assembly.
What is MCGA?
Multi-Color Graphics Array is the video card that IBM built into it's
Model 25 and 30 PS/2's. It subsequently became a subset of the standard
VGA adapter card. It has the distiction of being the first card
(excluding Targa and other expensive cards) to display 256 colors at
once on the computer screen. To us that meant cool games and neat
pictures. The MCGA addapter is added two new video modes to the PC
Mode $11 640x480x2 colors
Mode $13 320x200x256 colors
Obviously, we will deal with mode $13. If we wanted to deal with two
colors, we'd be programming a CGA. So much for the history
lesson...let's dive in.
I've created a unit, MCGALib, that will contain all of our MCGA
routines. The first two procedures we will concern ourselves with are
PNL #11 Page 6 September, 1992
setting the graphics mode and setting a pixel. The MCGALib is followed
by a test program that uses the two procedures:
Procedure SetGraphMode (Num:Byte);
Procedure SetPixel (X,Y:Integer;Color:Byte);
ScreenWide : Integer;
ScreenAddr : Word;
Procedure SetGraphMode (Num:Byte);
Case Num of
$13 : ScreenWide := 320;
ScreenAddr := $A000;
Function PixelAddr (X,Y:Word) : Word;
PixelAddr := Y * ScreenWide + X;
Procedure SetPixel (X,Y:Integer;Color:Byte);
Ofs : Word;
Ofs := PixelAddr (X,Y);
Mem [ScreenAddr:Ofs] := Color;
Procedure SetPixel (X,Y:Integer;Color:Byte);
PNL #11 Page September, 1992
mov byte ptr ds:[bx],al
This is the test program to make sure it's working...
Start : LongInt;
Regs : Registers;
Function Tick : LongInt;
Regs.ah := 0;
Tick := Regs.cx shl 16 + Regs.dx;
I,J : Integer;
Start := Tick;
For I := 0 to 199 do
For J := 0 to 320 do
Stop := Tick;
Ch : Char;
Repeat Until Keypressed;
While Keypressed do Ch := Readkey;
WriteLn ('Routine took ',(Stop-Start),' ticks or
PNL #11 Page 8 September, 1992
OK, I can see where these listings could get unbearably long in time.
I'll explore a few ways I can get this information to ya'll without
taking up too much space. I would like you to make sure this routine
works, just in case you had questions about your graphics card. You may
notice two SetPixel procedures in the MCGALib, one is commented out.
Remove the comments, comment up the uncommented SetPixel and run the
test program again. Notice the speed degradation. Linking in raw
assembly will even improve upon the speed of the inline assembly.
Please take the time to study each procedure and ASK ANY QUESTIONS that
you may have, even if it doesn't relate to the graphics routines. I'm
certain I do not want to get pulled off track by any discussions about
STYLE, but please post your critique for others to learn from.
I have to apologize a little bit. The first lesson contained code for
setting a pixel by directly altering video memory. This probably was a
strange sight for those of you that do not understand video memory, how
it's layed out and how to address it. I do hope you did get excited by
workable code in the first lesson.
Video memory in the MCGA Mode we are using is far simpler to understand
than even Text mode display memory. Those of you that know all about
text screen addressing, just scoffed. No, seriously, it is easier. I
will try to make this easy to understand, because it really is.
There is a section of memory in your computer that holds the
communications program you run. There is a section of memory that holds
COMMAND.COM. There is also a section of memory that holds the video
buffer. Unlike COMMAND.COM and the comm program, whose starting address
in memory could be different depending on your system, video memory is
always at the same location. In MCGA mode, video memory begins at the
655,360th byte of computer memory. You may say that my computer only
has 655,360 bytes of memory total (640K). Where does that memory
reside? Don't quote me on this, but I beleive the memory resides on
your graphics card.
So, the graphics card is responsible for scanning this piece of memory
many times per second, and displaying on the screen whatever color
values are stored starting at byte 655,360. By the way, in hex (base
that number is $A0000, and we'll refer to it like that from now on.
These color values that I referred to are numbers from 0 to 255. If we
store the number 0 in every byte of screen memory and the computer
thinks that 0 means black, which it usually does, the screen will
PNL #11 Page 9 September, 1992
instantly clear to black. That's how you do a screen clear in MCGA.
The resolution of our screen is 320 pixels horizontal by 200 pixels
vertical. That makes up a total of 64000 pixels per screen. A normal
text screen only has 4000 bytes of screen memory, so you can see why we
sometimes use assembly language. So, a very prehistoric screen clear
procedure could look something like:
Procedure ClearScreen (Color:Byte);
I : Word;
For I := 0 to 64000 do
Mem [$A000:I] := Color;
You'll notice I had to break the number $A0000 into two numbers. This
is called segment-offset addressing, and it is a throwback to the days
when the engineers felt we would never need more than 640K of memory.
Let me briefly explain. The memory address $A0000 and $A000:0000 are
synonymous. To compute a virtual address from a seg:ofs address you
perform the calcualtion: virtual := seg * 16 + ofs. This lets a
programmer access over 1 meg of memory using 2 word size values. Don't
OK. Since we are pretty much all hackers at heart and I don't have a
chalkboard, I'll illustrate video memory:
0 1 2 3 4 5 ---> up to pixel 319
0 + 0 | 1 | 2 | 3 | 4 | 5 | | | | | | |
1 +320|321|322|323|324| | | | | | | |
2 +640|641|642|643| | | | | | | | |
3 + | | | | | | | | | | | |
Assume, (I know, bad word), that this is a extreme closeup of the upper
left corner of a MCGA screen. As a matter of fact the box 0 is the
first pixel (the uppermost leftest most pixel) on the screen. Say, we
want to make it white. In the default palette the color white is 255.
All we have to do is say: Mem [$A000:0000] := 255;
If we want to make the pixel below it white also, we type :
Mem [$A000:0320] := 255;
As you can see, segment:offset addressing actually comes in handy in
addressing pixels on the screen. Since there are 320 pixels across and
200 Pixels up and down, the following formula returns the address of any
pixel on the MCGA screen: (Y * 320) + X
This is assuming the upperleft pixel is (0,0) and the lower right pixel
is (319,199), and we will.
Understanding screen addresses is essential to comprehending any of the
code we will be developing, so if a point is not clear...POST a message.
Don't be bashful about asking questions. Just a quick point...I did not
go to school to learn this. This is something everyone can learn.
PNL #11 Page 10 September, 1992
Graphics is a subject that a lot gets written about, but not the guts of
programming it. Many of you may opt for the easy way out (canned
libraries) but to really understand your computer you have to know
what's going on under the hood. Also, for laughs, try implementing a
good animation program or GUI with the BGI.
PNL #11 Page 11 September, 1992
I have talked about Pascal user's group in the introduction...well, in
the next issue of PNL, expect a short list of user's group currently
distributed by Borland. User's group who want to make sure they get
"officially" listed in PNL should send me an EMAIL message containing
The beginner's toolbox that was promised in issue #10 will be posted in
the next issue as well... Anybody needs input/output routines, a help
system or a menuing system? All right, this should quench your thirst.
I must also point out that no Aussie's articles were received by
September 1st... I have lost contact with my editor-over-the-pond
(Richard Morris) and without him, I have no way of reaching my favorite
contributors from Australia. [Hey guys, are you listening?]
[Now, the usual teaser...]
Again, I beg you all to send in articles. Everybody has his/her own
techniques to program, comments to share with others. You can send in
book reviews or software reviews,
The newsletter depends on your contribution...
Anybody interested in publishing an article can request the Article
Specifications with the magic name ARTSPEC on FidoNet 1:167/405 - It
will also be available soon from Richard Morris, FidoNet 3:640/372.5.
If you would like to receive back issues of PNL directly from me, send a
a diskette and $3.00 for shipping. Don't forget to include your address.
Send your order to:
86 Bryant St.
Canada J1J 3E4
If you are a SysOp that will regularly carry PNL and would like to have
your bulletin board listed as such, here, send me a message either by
postal mail or at one of the electronic addresses given on the title
page, with your bulletin board's name, phone number, and your name.
PNL #11 Page 12 September, 1992
The following is the phone numbers to bulletin boards known to carry
PNL. If you would like your bulletin board's name and number added to
or deleted from this list, please send me a message at one of my many
addresses. I can not guarantee whether a listed board will have any
particular issue, however.
Thieve's World ......................... Phone: (713) 463-8053
Hippocampus ............................ Phone: (203) 484-4621
Turbo City BBS ......................... Phone: (209) 599-7435
The Final Frontier BBS.................. Phone: (518) 761-0869