Copy Link
Add to Bookmark
Report
Ictari Issue 24
ICTARI USER GROUP ISSUE 24 July 1995
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* m a g a z i n e *
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I C T A R I U S E R G R O U P
63 Woolsbridge Road, Ringwood, Hants, BH24 2LX Tel. 01425-474415
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
INDEX FOR ISSUE 24
==================
ASSEMBLY Floating Point routines (needs fixing, see below).
Picture conversion package (PICPAC) update.
C Bouncing Ball demo program.
Tim Oren GEM Tutorial. Part 13. A new form manager.
GFA Naval Battle Game program.
STOS Variable to string converter code.
MISC Chain program.
Using the Atari clipboard.
Current membership list.
Index for issues 1-23.
In next months issue of ICTARI (this may change) :-
ASSEMBLY
C Tim Oren GEM Tutorial. Part 14. User interfaces.
GFA Weller Tools utilities.
STOS Print examples using M Cubitts STOS extension.
STOS loader program, etc for Missing Link Extn.
MISC Mrten Lindstrm, GEM Guide. Part 1.
How GDOS works.
----------------------------------------------------------------------
EDITORIAL
=========
TEAM GAME
---------
Congratulations to Ralph Lovesy on the good reviews that his Team
football game is getting in the glossy magazines, perhaps he will now
write a decent cricket game for the ST, the existing ones are pretty
pathetic. It would also be interesting to know the problems of getting
a program on the market, perhaps Ralph would write an article for
ICTARI about the processes involved, i.e. programming, artwork,
advertising, packaging, etc, etc.
PUBLICITY
---------
This month we have been in contact with Atari World magazine who have
promised to publish an article about ICTARI, probably in issue 5
(August 95). Hopefully this will bring in a few more members.
Thanks also to a couple of members who have sent in MicroMart advert
pages. We send one advert to MicroMart each month when the magazine
disks are sent out. If you buy the MicroMart magazine, please save the
advert pages for us and send them in when you have a few.
PICPAC UPDATE
-------------
In ICTARI issue 16 we published a set of picture packing/unpacking
routines by Mrten Lindstrm. Mrten has now sent in an update for
these routines which now includes code for GIF and TIFF formats as
well as GFA routines and advice on using them with other languages.
All the articles and source code can be found in the ASSEMBLY folder.
We would also like to hear from anyone who uses these routines in
another language such as C, Pascal, etc. Also in the same folder is an
article and code for converting GEM colour palettes when loading
picture files.
NAVAL GAME
----------
In the GFA folder is a PD Naval Game program which has an interesting
speech synthesis option. Since I don't know much about GFA Basic it
would be useful if a GFA expert could provide some example code in
another language (C or Assembler perhaps) on using the speech program.
The speech generator itself appears to be a separate .TOS program and
so could presumably be used from any language and even as a stand-
alone program.
FOR ASSEMBLER PROGRAMMERS
-------------------------
In the ASSEMBLY folder is some source code of a package of floating
point arithmetic routines which were taken from the November 1985
issue of Personal Computer World magazine. Unfortunately I have not
been able to get them to work and I hope that someone will be able to
do this for us as they could be quite useful. The code has been copied
exactly as it appeared in the magazine with all the comments that were
published and it has been checked over for mistakes several times.
Also, as far as I know, there were no subsequent articles published in
later magazines to correct any errors.
The author does not give enough detailed information on how the
floating point numbers are represented in binary format and also does
not provide any routines to convert from normal ASCII format to or
from the floating point format which would also be necessary in a
practical program. If anyone can get these routines working and
perhaps write some ASCII-FP conversion routines, we would be very
grateful.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: ICTARI
From: Steve Gale
Does anyone know of any 'legal' way to stop 'overshoot' when scrolling
through a document, i.e. stopping the scrolling sequence immediately
when the up or down arrow key is released. Presumably this is caused
by the keyboard buffer storing keypresses even after the key has been
released.
----------------------------------------------------------------------
To: *.*
From: Terry King
Does anyone know much about the Falcon hardware ? In particular I
would like to know how to use the sound, I believe that the STE DMA
sound commands are not supported on the Falcon which means STE games
run in silence, is this true ?
I tried out a game I am writing on a Falcon and although the
game played, the display seemed to give quadruple vision with
messed up colours. I was using an STE to write it and it was
using hardware scrolling and writing to the video address registers.
Should I put the Falcon in some specific mode for it to work ? (Please
no "use backward" answers as I want the game to work directly,
without the need for any patch programs).
Also, what's the best way to check whether the machine the program
is running on is a Falcon ? Would it be something like the cookie
jar variable _MCH containing the value 30 ?
*/ The Falcon has the same DMA sound chip as the STE (as well as the
DSP) and the hardware addresses are the same. I suspect that the
Falcon has to have additional initialisation before it can be used
(which is probably what 'Backward' does. Perhaps our Falcon
programmers can give us more info. In ICTARI issue 15 Paul Brookes
published some code using the DSP in C which may also be of interest.
In ICTARI issue 5 Simon Rigby published an assembler routine called
WHATTOS2 which detects which TOS is being used, what type of computer
the program is running on as well as a number of other parameters.
Perhaps you could modify this routine to do what you want, if it
doesn't do the job, let us know. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Dick Teuber
Can anyone help me on how to use machine code in Lattice C. I want to
include a small block of machine code within the source code of a C
program and not link in with an Object file. I also need to pass
parameters from C to the CPU registers and stack. The Lattice C
manuals seem to be very unhelpful on how to do any of this.
----------------------------------------------------------------------
To: Ictari
From: Mrten Lindstrm
PRINTER DRIVERS
===============
Like Simon Rigby I think that any printer driver system has to be
viewed in relation to GDOS, since GDOS (allowing standard GEM VDI
operations to work on the printer as well as on the screen) already
constitutes a 'universal printer driver' system for TOS computers,
conveniently usable by the application programmer.
I think standards should be stuck to unless there are very good
reasons against it, but GDOS does have a number of drawbacks which
might motivate an alternative system. On the other hand I can see some
solutions too.
The drawbacks to GDOS first :-
------------------------------
1) No GDOS version is freeware, as far as I know, which means
that some licensing agreement with Atari is needed to
distribute programs with GDOS included. Many or most ST users
probably already have some GDOS version lying around
somewhere, got with a magazine cover disk or with a program
bundled with the computer. But you would of course like to
guarantee some basic printing capabilities to any user, and if
your own program is shareware or even freeware you wouldn't
want to pay Atari much or anything for distributing the stone-
age old GDOS 1. On the other hand Atari may be reasonable with
this (The $500 mentioned by D N Wheeler in his text from 1988
must be history long since). Does anyone have any experience
or knowledge?
2) I have found no documentation on writing GDOS drivers in TOS
books of mine (though gained some insight from disassembly),
and writing a GDOS driver from scratch is probably no small
task in any case.
3) The VDI/GDOS offers rather limited support for character
oriented "alphanumeric" output. Graphic output is of course
much more flexible, but simple character output is a lot
faster and potentially could give as good-looking results for
plain text. On the other hand there DOES exist a VDI command
V_ALPHA_TEXT, unknown to me until I read the Compendium, which
allows character output to a printer including the setting of
all common printer styles and densities, though most of these
features are apparently unsupported by current drivers. There
are no definitions for font changes or support of justified
text, however.
And some solutions :-
---------------------
1) In worst case, it may not be an insurmountable task to write
our own GDOS replacement. The basic GDOS release 1.1 is not a
very big program (and not particularly effectively programmed
either). I have disassembled it and think I understand almost
completely everything done by this program.
2) Regarding the programming of the GDOS driver itself I think I
have deduced, from the disassembly of GDOS, what rules should
apply (see below) though, official documentation would be most
helpful.
While the complete programming from scratch of a GDOS driver
isn't a days work I think that it might be possible to split
it up in stages. I haven't disassembled (at least not
completely) a GDOS driver yet, but I would imagine its various
VDI graphic routines draw their output on an internal bitmap
(this may be done in 'strips' to save memory), which is then
sent to the printer, translated into the appropriate printer
codes.
It thus may be possible to write the core code for sending a
bitmap (and character output) to printers in one step, and add
the complete GDOS 'driver shell' later. Furthermore this
shell, once written, may conceivably be used with any printer
driver.
3) A solution to the limited support for alphanumeric character
output, is of course to introduce our own extensions to
V_ALPHA_TEXT (extra escape codes) or possibly even add new
calls. This would not be ideal but better than not supporting
GDOS at all.
If needed, a driver could perhaps also make some information
on e.g. accessible fonts, character width tables etc.
available to the program outside of the VDI system (via a
cookie in the jar).
The UPD system of Peter Hibbs in relation to this :-
----------------------------------------------------
1) Until we have a freeware GDOS (replacement) this is obviously
a strong point in favour of UPD as a separate system.
2) Likewise the simple configuration commands envisaged in your
UPD specification, would be a vast improvement to the gruesome
task of writing a complete GDOS driver for each new printer.
If, on the other hand, this flexibility was built into a
'Universal _GDOS_ Printer Driver' it might possibly be even
better.
3) Had UPD been aiming at making universal the advanced non-
graphic capabilities of e.g. Protext printer drivers (font
changes and justified text), this would have been another
argument for UPD as a separate alternative to GDOS. As it is,
many or most of the UPD style commands seem to have their
counterpart in escape codes defined with the VDI/GDOS command
V_ALPHA_TEXT. Which instead speaks in favour of adapting UPD
to support GDOS.
The ability with UPD to select a lower-than-maximum resolution
for graphics output is a nice (speed-gaining) feature that may
be difficult to make general use of within the VDI/GDOS
context where each workstation is supposed to have fixed
resolution and dimensions. On the other hand it would with
some commands - for instance with V_BIT_IMAGE to print an IMG
file (scaled) - be possible to let a GDOS driver internally
decide on a lower resolution.
÷÷÷÷÷÷÷÷÷÷÷ PROPOSITION: GDOS UPD ÷÷÷÷÷÷÷÷÷÷÷
- To everybody: How about expanding the UPD into the joint Ictari
project of creating a 'universal _GDOS_ printer driver' ? I would be
prepared to help with writing a freeware GDOS replacement (if needed)
or with the GDOS driver itself. Regarding the driver I think it may be
possible to split this up in one part responsible for outputting to
the printer (essentially the UPD of Peter Hibbs), and other routines
converting the VDI commands into drawing on a bitmap, though there
must of course be some main routines too, keeping it all together. If
anyone has any documentation on GDOS driver programming this would be
most welcome. I will continue to disassemble an existing GDOS printer
driver to see what I can find out.
- To Peter Hibbs: Would you be willing to adapt UPD to support GDOS?
I do think this would increase its potential usability even further,
though I appreciate the amount of work you have already invested into
UPD (and, regarded on their own or in relation to BIOS, I found your
function definitions and calling interface very well thought out
indeed).
Adaptation to GDOS would partly mean making UPD mimic VDI/GDOS calling
procedures more closely (to simplify things for application
programmers changing between 'non-GEM UPD' and GDOS). But the ultimate
aim would be to prepare it to execute VDI commands as part of a GDOS
driver.
÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
If you are at all interested, this would lead to the following remarks
on the specific UPD functions described in Ictari 23 :-
UPD_INIT
This is the trickiest one and you may possibly let it remain as it is
for the time being. If and when UPD is to become part of a GDOS
driver, however, it must already be initialized when anyone first
sends VDI output to the printer or else be able to initialize at the
first call of V_OPNWK.
I would then envisage UPD as a separate program, UPD.PRG, to rest side
by side with GDOS on the disk, reading and converting into tables the
ascii text driver file during bootup, exactly like GDOS is reading
ASSIGN.SYS (from the current drive and path = the root of the boot
disk). Like GDOS the UPD program would afterwards copy the extracted
data down over the now redundant ascii text, shrink its memory
accordingly and terminate with PTERMRES to make itself memory
resident. Before this it would however install a cookie, with the
address to a routine or parameter block within itself, in the jar.
The GDOS 'driver shell' - UPD.SYS - would, at the first V_OPNWK call
it gets, seek contact with the - UPD.PRG - core via the cookie jar.
UPD_TEXT
Let this command deal with a whole string (like V_ALPHA_TEXT) and
internally take care of the error checking after each character.
Furthermore, instead of your attribute word with each character, use
the escapes defined with V_ALPHA_TEXT for styles changes as far as
possible. Though for attributes not defined with V_ALPHA_TEXT I guess
you will have to define your own. I would suggest that you try to
support ALL of the DEFINED codes (in the Atari Compendium) AS defined,
which I'm afraid would, as neat as they are, require you to skip
explicit definitions of 5, 6, 17 and 20 CPI (the results of 2-mode
combinations). Remember that both widened and condensed printing are
also possible to combine with proportional printing (on my NEC P2200
anyway).
NOTE: Multiple copies on lasers is set with a separate VDI command
V_PGCOUNT.
Also, the reset printer and clear printer buffer attributes would
perhaps be better replaced by internal handling in the V_OPNWK
routine.
GRAPHICS
Analogically to the character output, I would suggest the graphics
output routine print the whole bitmap in one go, and internally take
care of error checking after each line. Thus merging UPD_SGM, UPD_SGD
and UPD_EGM into a single bitmap output command. This would simplify
things for the application programmer and is how it must be done
within a GDOS driver anyway.
To make the UPD command completely mimic the VDI raster copy functions
would perhaps not be worth the trouble (and not necessary once working
within the GDOS driver), but I think it should be prepared to take a
width specification IN PIXELS, not necessarily divisible by 16 or even
8 (any unused end bits to be cleared or whatever by the UPD function).
Each new line should on the other hand be required to begin on a word
boundary.
UPD_DELAY
I would suggest this command be replaced with a definition in the
ASCII text file for the driver. I also think that VSYNC calls for the
measurement of time would be better replaced with polling of the
_HZ_200 count (example routine given below) or alternatively polling
of the GEMDOS time with TGETTIME. These methods would make delay times
independent of the monitor hardware.
Dimensions of the workstation (paper sheet), as well as pixel
dimensions (in microns), and any colour capacity, should also be
possible to define within the driver text file, in some form or
another. (Since they need to be written by the driver into the output
arrays during calls of V_OPNWK.)
One final suggestion, and not related to GDOS in any way:
Allowing characters to be redefined into any byte sequences before
output to the printer, would be worth a lot to many non-English
speaking people, I think. All Swedish letters should in principle come
out right if the printer is set to IBM mode, but there are (old)
printers lacking this mode (Is the British pound sign really printed
correctly by all printers without re-definition?). And other letters
(the O slash of Danish/Norwegian and the German double s) definitely
need to be redefined before being sent to the printer.
Programming a GDOS driver
-------------------------
Regarding the workings of a GDOS driver I think the following rules
apply (deduced purely from disassembly - official documentation would
be most helpful) :-
A GDOS driver is, as Simon Rigby said, basically a program file,
complete with program file header and a relocation table. (I actually
discovered a bug, when disassembling GDOS release 1.1, that I think
will make a driver crash if there is NOT any relocation data - i.e. if
the driver is written to be completely PC-relative.)
The driver should not shrink its memory, since GDOS will have
allocated space only for its TEXT, DATA and BSS segments, and should
not terminate with a GEMDOS call (PTERM) but simply with an RTS
instruction (it is called as a subroutine from GDOS).
The driver will be called for each and every VDI call directed to the
device with which it is associated. And the sole input is a pointer in
register D1 to the VDI parameter block (as with any low level VDI
call).
The driver is apparently supposed to return a value in D0: seemingly
just a flag determining whether or not the Y-axis should be reversed
by GDOS in the case that NDC coordinates are being used. (The driver I
studied seemed to always return a 1 - preventing GDOS interfering with
the Y axis direction in any case.)
All other registers are saved on the stack by the driver I have looked
into. The stack itself is a system stack, so should probably not be
too heavily used.
Apart from this, I think that the GDOS driver is free to implement
each VDI call in whatever fashion it likes as long as the
specifications for the call are met with. Input and output are handled
via the standard VDI arrays: contrl, intin, intout, ptsin and ptsout.
The driver is apparently free to pick any number for the V_HANDLE to
return when opening a workstation (except that 0 indicates error as
usual). GDOS will store this handle and use it in future calls to the
driver, translating between this 'internal' handle and the handle used
in communication with calling programs.
GDOS will take care of any font loading, as well as sorting fonts
according to ID and point size (lowest font ID's - and within fonts of
same ID, smallest sizes - first). Or at least GDOS release 1.1 will
have done this sorting, though older GDOS versions perhaps never did.
But GDOS after this also passes the VST_LOAD_FONTS call to the driver,
like with any other VDI call, only this time with some extra values
supplied in the CONTRL array:-
contrl[7-8] : Pointer to a buffer for character manipulations.
contrl[9] : Length of this buffer
contrl[10-11]: Pointer to the (header of the) first font
The driver should save these for future use. It is apparently solely
the responsibility of the driver to manage text output from these data
given. No further help will be offered by the GDOS program.
(Note: The above applies to the basic GDOS 1.1. I suppose that later
GDOS versions - FontGDOS, FSM and SpeedoGDOS - will do more, possibly
even take fully care of any Bezier curves and outline fonts and
somehow send them to the driver as bitmaps (perhaps via calls of
raster copy operations or via fill pattern operations). Can someone
tell?)
* ASSEMBLER ROUTINE TO WAIT A GIVEN NUMBER OF HUNDREDTHS OF SECONDS:-
* -------------------------
* Number of hundredths of seconds given on stack as a LONGWORD.
* E.g. pea 100.W ;to wait 1 second
* bsr delay
* addq.l #4,SP
delay movem.l D0-D3/A0-A2,-(SP)
move.l 32(SP),D3
add.l D3,D3 ;Convert hundredths of s into 200Hz ticks
bsr.s gethz200
add.l D0,D3
.delay bsr.s gethz200
cmp.l D3,D0
bls.s .delay
movem.l (SP)+,D0-D3/A0-A2
rts
gethz200 bsr.s .supexec ;Push next address on stack and jump
move.l $4BA.W,D0
rts
.supexec move.w #38,-(SP)
trap #14
addq.l #6,SP
rts
*/ In response to Mrtens letter above and Simon Rigby last month I
have to disagree with their suggestion that a new Printer Driver
program should try and emulate or tie into the existing GDOS system. I
have several reasons for this view -
Firstly, while I accept that a 'serious' program should use the GEM
system for maximum compatibility with all ST versions, I know that
there are some programmers who prefer not to use GEM for various
reasons (games programs, for example) and also some languages do not
allow the use of GEM (STOS being one example). The proposed UPD system
would allow ANY programmer to use a printer whether under GEM or not.
Secondly, any GDOS equivalent program would have to cater for vector
fonts (as I cannot see a bit mapped font version having any
credibility among Atari programmers) and this would be a huge task.
Look how long SPEEDO-GDOS has taken to arrive along with all the other
aborted versions on the way. And, in any case, what would be the point
in copying a program that has already been written, not to mention the
legal aspects of copyright.
Thirdly, GDOS is essentially a graphics system and would not cater for
sending text data and text attributes to the printer. While this may
be a relatively trivial problem for a program to overcome, the UPD
system still has the advantage of rationalising the printer output so
that the programmer does not have to worry about all the different
control code sequences for the various attribute functions. Admittedly
the available attribute codes have to be limited to those that are
available on most printers but this is still better than having none
at all.
Fourthly, using the GDOS system, a (machine code) printer driver would
have to be written for each printer to print graphics images. This
would make it very difficult, if not impossible, for the end user to
write a printer driver for his/her printer if there was not one
already available. With the UPD system, writing a printer driver is
relatively easy with the help of the printer manual and a suitable
test program. Of course, the graphics printing code must already be
built into the UPD program itself but as Simon pointed out last month,
there are only a small number of different graphics printing methods
used in most printers. I have identified a number of methods, most use
the Epson system (ESC, K, No_of_bytes, data) while the Canon system is
slightly different (ESC, [, g, No_of_bytes, mode, data). HP Laser and
DeskJet are basically the same and 9 pin, 16 pin, 24 pin and 48 pin
modes are virtually the same except for the number of bytes per
vertical slice. If any other methods of printing graphics data are
discovered, then these can be added later, the code has been written
in such a way as to facilitate additional graphics drivers easily.
Colour printing will have to wait until someone tells me how it works
but hopefully that can be incorporated later.
Regarding some of the specific points raised in the letter above :-
I agree that the UPD program is best stored as a separate program on
disk and loaded in by the application although I don't think it should
be defined as a .PRG program since it cannot be run as a stand alone
program which the .PRG extension implies. Using the title UPD_V100.BIN
indicates that it is a binary file (version 1.00 in this case) and
implies that it has to be loaded into an application at run time.
Creating an entry in the 'cookie jar' is an option I had not
considered. As I understand this system, it is for situations where
one program can determine whether another program (or some hardware
device) has been installed and could be used by accessory programs or
other applications programs in a multi-tasking environment. The only
reason I can see for the UPD to install a cookie jar entry would be to
allow several programs to use the same program. In other words, an
application loads in the UPD program and then stores its start address
in the 'cookie jar' so that a second application (or accessory) could
use the same program without having to load the program code again.
This would save some memory (although the code is only about 4K long
anyway) but I think it could cause other problems. The programmer
would have to assume the same printer was being used by both programs
(probable but not absolutely definite) since the printer driver will
also be loaded by the original program. Another major problem would be
that, since printing can take some time, the variable stores set up by
the first program could be corrupted by the second if both programs
try to print at the same time. We would need some form of memory
allocation and print spooling to allow stacking of printer calls. I
will have to think about this one but I suspect it would not be worth
the extra complications !
Sending text characters as a complete string instead of individually
would be possible, I suppose, but I think it would be less flexible
since the program would need another control code to define the end of
the string and the UPD would need more buffer space to store the
string before sending it on to the printer. The proposed system is
easy enough to use and the programmer can always implement such a
system if he wants to. It would be possible to use just the attributes
defined by the v_alpha_text function but since we don't want to use
GEM anyway we may as well use the extra codes. The attribute codes
that I have defined ($0200, $0400, etc) were designed to make the code
simple and run as quickly as possible.
I had considered sending a complete bit map to the printer using one
command but decided against it because the command itself would be
rather involved as it would have to incorporate image width, image
length, graphics mode, image address and possibly colour information.
Also sending one raster line at a time allows the programmer to
provide a method of aborting the printout with a keypress at any time.
The current system is very easy to implement with a simple loop and
image address pointer. I suppose the width specification could be
defined in pixels rather than bytes if there is any advantage in this.
Regarding the delay period, I did consider using the 200Hz counter but
this would mean going into Supervisor mode within the UPD program
which causes complications on return. However, using the 'Tgettime'
GEMDOS function to generate the delay is a good idea which I have now
implemented although the delay does not really need to be very
accurate. I am not sure about including the delay period value in the
Printer Driver file itself since the reason for the delay could vary
even in the same printer depending on the size of the printer buffer,
whether single sheets or fanfold is being used, etc. In fact, I am not
even sure if a delay is needed anyway, my own experience with printers
has not shown any problems. I only included the option just in case
someone somewhere needed it, perhaps some other members could let me
know if it is really required.
I don't think the paper size should be included in the Printer Driver
text file since that could vary for each print-out but the colour
options will certainly need to be defined, I will sort that out when I
have more information on colour printing.
Allowing a character to be redefined into a series of byte codes is a
lot more complicated than it first seems, however, changing one
character into another one is relatively simple and that is what I
propose to implement first. However, even this opens up a whole new
can of worms. The character set from $20 to $7F seems to be (in
English anyway) fairly standard, assuming, that is, that code $23 is
defined as the # character (and not the English pound sign). The
problem is that some printers can be configured to print a different
character for some codes (i.e. $, #, , etc) and the applications
program or the UPD program cannot know what is being printed for each
character code. For the codes from $80 to $FF it is even more
difficult. Again, depending on how the printer is configured, these
codes can print as IBM graphics characters, italics, or sometimes
nothing at all. My HP Laser printer prints a completely different
character set from my 24 pin Panasonic, most of the characters are
there but in different positions. It would probably be useful to have
the IBM ProPrinter character set as standard since these have the line
drawing characters available but some printers cannot emulate this
mode. Perhaps we need a complete character set defined which all
printers can print and which could then be defined in the Printer
Driver text file. The problem is that, apart from the English pound
sign at code $9C (usually), all the other characters are non-English.
Perhaps our European members could advise us on the characters or
symbols required.
I think it would be very useful to know more about how GDOS drivers
work as we may be able to use some of the ideas. I would also like
more information on colour printing, if anyone can provide this info,
please let me know.
I would also like to hear more comments on the UPD from other members,
especially any that are writing programs that use print-outs. PDH /*
------------------------------ End of file ---------------------------
