Copy Link
Add to Bookmark
Report
Ictari Issue 16
ICTARI USER GROUP ISSUE 16 November 1994
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* 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. 0425-474415
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
INDEX FOR ISSUE 16
==================
ASSEMBLY IMG mono picture decoding routine.
Degas PI1-3/PC1-3 picture decoding routine.
Tiny TNY/TN1-3 picture decoding routine.
PC Paintbrush PCX picture decoding routine.
STAD PAC picture decoding routine.
Tiny low rez decoding routine.
IMG/IFF/DEGAS/NEO packing/unpacking routines.
C TNY picture decoding routine.
LZW TIFF compression definitions and algorithms.
Neochrome picture show program.
GEM Tutorial by J White. Part 6.
IMG picture loader code.
GFA CrackArt picture compression/decompression code.
Spectrum (SPU) picture format information and code.
Tiny picture decompression code.
STOS Using 80 column text in low rez.
VDU dump program.
MISC Algorithm Corner. Star Wars scroll & Huffman coding.
Video Master picture file format information.
Falcon screen resolution detection.
The IMG, IFF ILBM formats plus EDT sprite file info.
Atari Questions and Answers file No 5.
PCX picture format information.
TIFF/LZW technical memorandum.
Current membership list.
Index to Issues 1-15.
In next months issue of ICTARI (this may change) :-
ASSEMBLY GEM Window redraw routine.
Sprite packer/unpacker routine.
Rectangle intersection detection code.
C Useful MagiC C functions.
GEM Tutorial.
GFA Mandelbrot generator.
ShadeBob, 4 bit real time shading.
GFA menu locating techniques.
STOS Factorial generator program.
Puzzle solving program.
STOS on the Falcon.
PASCAL Program to calculate shift bonuses, etc.
MISC
For future issues :-
Polyline drawing routines in machine code.
Bezier curve drawing routines.
Picture compression routine for IMG pictures.
HP DeskJet/LaserJet compression routines (Mode 2 TIFF).
Picture switching techniques.
Printer driver code for printing mono/colour images.
Using Calamus fonts.
Sorting algorithms.
Using the BitBlit routines.
Code for using the File Selector.
Using multiple rasters in machine code.
Overscan techniques.
STOS sprites.
----------------------------------------------------------------------
EDITORIAL
=========
MEMBERSHIP
----------
We have had four new members join this month including one from
Denmark, welcome to them.
IMAGE COMPRESSION/DECOMPRESSION
-------------------------------
As you can see, this month most of the code and articles are concerned
with picture formats, image decompression and compression. In the
assembly folder I have provided a few of my own unpacking routines for
various picture formats that I have been using for some time. We have
also received a comprehensive file of similar routines from Marten
Lindstrom which, I have to say, are considerably better, but I have
left mine in anyway just in case anyone finds them useful.
OMEGA BBS
---------
We have had an offer to advertise ICTARI on the OMEGA BBS system in
Ewell, Surrey which we have taken up. This may provide a few more
members although I think the BBS is mainly geared towards the PC
community. Perhaps anyone with a Modem could check it out on 081-393-
6226, 8.00pm to 2.00am (8-N-I to 14400bps).
DISK COPYING
------------
Does anyone have a program that can make FAST multiple copies of a
disk. When I have to duplicate the ICTARI disks it takes me about 3
hours using Acopy and it would be nice to be able to do it a bit
quicker. I have tried FastCopy Pro but this takes four times longer
when it has to format the disk as well. I have got a demo copy of
Kobold (which won't format) but I don't think this is any better for
multiple copies. If anyone can suggest a suitable program (or would
like to write one) please let me know.
ARTICLES
--------
We are now very short of articles for next years issues of ICTARI. If
you have any code or general programming articles please send them in
as soon as possible, especially if you have not contributed before.
If everybody just sits back and waits for someone else to send in
material for disks we will shortly run out altogether. If you have any
ideas on what subjects you would like to see covered in future issues
please let us know and we might be able to help.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: *.*
From: Peter Hibbs
Since this issue is all about picture compression techniques I would
like to ask if anyone has any thoughts about text compression. I am
writing a program in machine code which requires access to a large
number of words in the form of a dictionary. Obviously the simplest
way would be to store all the words as an ASCII file with a non ASCII
separator between each one and there is a PD file available which does
just this. The problem with this approach is the size of the file/s
which could run to 1-2 Mb. I really need to compress the file in such
a way that I can still access individual words as well as add or
delete words from the file.
The sort of options I would require are to copy a word into a small
buffer and then call a routine which would tell me if the word exists
in the dictionary file. Upper or lower case letters don't matter and
the order of the words in the file is not important, the number of
letters in each word could vary from 2 to whatever.
I don't know how the dictionary files that come with word processors
are made up but I would guess that they are compressed in some way
using common letter groups found in English, i.e. 'ing', 'ation',
'ent', etc which could be encoded as single bytes and common endings
like 's','ed','es', etc could be stored as set/reset bits in a single
'endings' byte.
If anyone knows how dictionary files are stored or has any ideas on
the subject please let me know.
----------------------------------------------------------------------
To: *.*
From: Dick Teuber
Does anyone have (or has anyone written) a program which can intercept
the output from a program to a printer and write it to a disk file
instead. The file on disk can then be moved to another computer (i.e.
a PC) and sent direct to the printer and so be printed out like the
original file. The program should be able to work with any program
that outputs data to the parallel port.
----------------------------------------------------------------------
To: ICTARI
From: Iain Mcleod
I think I should have explained my request more clearly about
bitmapping a sprite onto a polygon!!!!
What I was wanting to know is, well I'll give an example.. You have a
wall disappearing into the distance and how do you give it a *wall*
texture, i.e map a drawing of a wall on to the (distorted) rectangle.
But of a higher priority... I want to play tracker songs in my game -
I can only get one channel using the XBIOS bufptr, etc.. calls. Does
anyone know how or (even better) have a copy of the tracker code they
can give me.
Keep up the *great* work on ICTARI. I will try to add more answers and
less questions but then without questions, you wouldn't have answers
(?!).
I'm also a member of the FALCON FACT FILE so I'll mention ICTARI to
them.
I also recommend any FALCON user to register :
FFF,
11 POUND MEADOW,
THE GREEN,
WHITCHURCH,
HANTS,
RG28 7LG
Membership is free also except for postage.
----------------------------------------------------------------------
To: Mark Baker
From: Jim Ford
Thanks for the info that Gnu C++ is up to 2.5.8. Does anyone know
where it is available for the Atari ?
----------------------------------------------------------------------
To: Peter Hibbs
From: John Logan
"Computer Arithmetic - Logic and Design" by Otto Spaniol. John Wiley &
Sons 1981.
I had forgotten how expensive this book was and now that I am reminded
of the price, I doubt whether it is of interest to anyone other than
mathematicians or computer engineers. It offers "quick and economical
algorithms for performing arithmetic operations in digital computers"
and "a comparative discussion of differing concepts which can be used
when designing computers". The book considers representation of
numbers, the logic of adders, methods of multiplication and division
and the calculation of special functions. The algorithms are described
by microprograms. These are the hardwired programs used to control the
CPUs of computers. The first 2 lines of a restoring division
microprogram follow (DD, DE and DR are registers, n is the number of
bits in a word, SHL is shift left, Z is the zero flag, V overflow
flag):
0: (DD,DE) := dividend;DR := divisor;Z := n;V := DD n-1 XOR DR n-1;
1: if DR n-1 = DR n-2 then [SHL(DD,DE);DE 0 := 0;SHL(DR);DR 0 :=
0;goto 1];
2: etc etc
Such emphasis as there is, is on the implementation of the algorithms
in hardware although there is probably no reason why they should not
be implemented in software. I was interested in the methods of
speeding up division but I have to confess that I could not understand
them. Not recommended for most programmers.
"Microprocessors and Microcomputers" by Eric Huggins. The Macmillan
Press Ltd 1979.
This a much friendlier book. It describes the evolution of the
microprocessor and then considers in some detail how a CPU works, the
binary and other number systems, programming elements, hardware and
finally software. The latter was the most useful to me as both fixed
and floating point algorithms were covered and methods of division
were fully explained. (It is not uncommon for an author to explain in
detail the process of multiplication and then "leave it to the reader"
to work out how to divide. I always take that to mean that he/she did
not know how do it.) Special functions (square roots, logs, antilogs
and trig) are all covered. Not only are the basic principles set out
but flow charts are given.
Do not be put off by the beginning of the book where there are
descriptions and pictures of elffins and demure damsels! The former
are "ELectronic Fetchers and Filers of INformation" and the latter
"Direct the Elffin to the correct Memory location, Updating REgisters,
Doing Arithmetic and Monitoring the Status record; all
ELectronically." They are used to illustrate how the basic CPU works.
I am sorry to hear that the book is no longer available. Perhaps a
second hand bookshop might be able to supply a copy.
*/ Thanks for the info John, perhaps if anyone comes across the
Huggins book in a bookshop anywhere they could let us know. ICTARI /*
----------------------------------------------------------------------
To: Ictari and all assembler programmers
From: Mrten Lindstrm
I send you (together with this message) an assembler sub-routine
library, for un/packing IMG and IFF ILBM pictures. It has been fairly
extensively tested, except that PUTFM and GETFM (non-GEM image
copying) have only been briefly tested with a blitter (I don't have
one of my own so I had to ask my brother to do the test for me) and
that SETTRU (for non-GEM palette setting on a general Atari machine)
may not work on a Falcon. I hope you have found room for it all on
this disk. */ See ASSEMBLY/PIC_PACS folder. ICTARI /*
Has anyone complained about the disk format (10 sectors/track)? I
personally find nothing wrong with it (it is what I use with all my
personal disks), but if anyone should have problems copying it, I
think it would be possible to include a small (1-2 K) simple
format/copy program on each disk. Maybe you should also consider
packing more of your material into self-extracting files?
*/ We have had someone 'complain' about non-standard disk formats,
primarily disks that were formatted to more than 80 tracks. Also we
have had problems formatting some disks with more than 80 tracks which
is why we do not use this option any more. Formatting tracks with 10
sectors is usually OK but we normally use 9 sectors unless we really
need to squeeze more on a disk. As I am sure everyone knows, if you
copy a full disk that is formatted with 10 sectors/track onto a disk
which is formatted with 9 sectors/track using the normal desk top
copying options, the TOS copies what it can to the target disk but
leaves off anything it cannot copy WITHOUT informing the user. If you
don't happen to notice the missing files you end up with some files
missing on your copied disk. We could provide a small copying type
program but we suspect that most members just take copies of the files
that they are interested in and, in any case, there are plenty of
copying programs in the Public Domain. We try NOT to pack files if we
can avoid it because it is easier for members to copy/read files when
they are not packed. If anyone has any views on this subject please
let us know. ICTARI /*
As soon as I joined Ictari I, of course, immediately ordered all back
issues, so I have read all the main texts at least. Regarding the
discussion on the format for assembler sub-routines I'd like to say:
1) I wholeheartedly support the view that routines intended to be used
by others should normally save all registers that aren't used for
return values.
2) I also would like to suggest that low ordered registers - and
especially D0 - are used as preferred registers for return values.
3) Finally, my own practice is to always make sure that the processor
condition flags on return from a sub-routine are set according to a
return value in D0 (when applicable - e.g. when a negative value
signals error). I know it may be a bit late, but how about it? The
advantage is that it saves you a TST instruction in the main routine -
which is where I think brevity and clarity should be maximised.
To: PoshPaws - man with many names - or anyone else with a Falcon
Could you please answer two Falcon questions (that came up when I was
writing the non-GEM complemental sub-routines in the PICPAC.S library
- for IMG/IFF pictures un/packing - hopefully on this disk):
1) With the exception of high colour resolutions, could you confirm
that all other Falcon screens (especially the 256 colour ones) are
organized word-interleaved? I know that the Atari compendium says that
each and every Atari resolution (except high colour) is word
interleaved, but the reason I doubt this is an article in German ST
Magazine indicating that TT low rez is BYTE interleaved.
2) Does VSETRGB copy colours to hardware immediately or does it wait
for a VBL (like SETPALETTE)? (My routine SETTRU, intended to set a
palette on a general Atari computer, as written is counting on the
former.)
To: everybody
I hope you gave my country a thought this month. When you read this
the Swedish people will hopefully have decided to join the EU, in
which case I intend to order some things from 'Europe' (=UK mostly)
this new year, first of which will be Devpack 3. I have, for fear of
harassments by the Swedish customs, for a long time now lived with
Devpack 2 (cover disk release) + Easy Rider, a German assembler which
is very good, with more and better optimization options and more
powerful macro string handling than Devpack 2, but not as friendly.
Long live the European Union!!!
*/ Just heard on the news that Sweden have voted to join the EU, just.
Hope they know what they are doing. ICTARI /*
----------------------------------------------------------------------
To: ICTARI
From: Tony Harris
I have a couple of programming questions (in 68000).
1) Any examples of using the STE's BLITTER and H/W chips for sprite
and screen manipulation.
2) I need to know how to redraw windows after a DA's been called or
any disturbance of the windows ?
*/ We have published a comprehensive document on the Blitter chip in
Issue 11 and various issues have covered sprite use (although not, I
think, using the blitter). See next month for window redraw code and
INDEX.TXT file in the MISC folder for back issue list. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Richard Evans
Some views on
2B's MagiC 2.0 multitasking OS, running on an STFM with NVDI 2.51
-----------------------------------------------------------------
I'm sure that any feedback on newish software such as MagiC must be
useful, so I will give you my impressions so far. Generally it is
excellent, the whole system is much faster, and with NVDI as well
screen updates are no longer a problem- programs such as Kandinsky
become useable. Whilst the mag reviews didn't think much of MagXdesk,
I have to say that for the majority of users it should be fine, as it
is small and there are many useful features hidden in the keyboard
shortcuts for editing, calling cli's, passing parameters etc. The
system copes well with minor compatibility problems and is able to
tidy corrupted screens, pass control away from locked programs and
delete them from memory. Extended system routines mean that some GEM
programs have extra features similar (but less comprehensive) to
Let'em'fly, windows have a backdrop button and do not have to be
topped to scroll, size, close, etc (some older programs, and the LC
5.52 editor don't respond however). TOS programs run in windows, can
use GDOS fonts and have clipboard support etc. Software written with
multitasking in mind run perfectly (obvious I s'pose), though MagiC
does not yet support some more advanced MTOS features such as drag-
and-drop. Badly written software such as Protext and Prodata can be
run in single mode, though the reliability of the system may be
compromised. In use, the system is responsive even when multi-tasking
and is absolutely brilliant for those endless hours of de-compacting
files etc. If the system is slowing down too much, there are utilities
to control the amount of processor given to background tasks, which
should greatly reduce any potential problem (I've only needed to use
them once). The manual supplied is better than average, covering
MagXdesk and listing new system calls in some detail- it does however
presume that readers have knowledge of GEM/2 and AES 4.x, and an
appropriate reference manual would be required for inexperienced
programmers (me!) trying to write programs for these enhanced
environments; there also appears to be a few errors in the programmers
section, just to keep you on your toes! Installation is refreshingly
simple, and some utilities such as a CLI and routine library are
supplied; unfortunately the utilities and accompanying text files are
in German, and the library is for Pure C- I hope 2B might consider
translating these and supplying a Lattice library (unlikely !).
Cons:
There had to be some! A lot of my older GEM software, especially PD is
not reliable enough to use safely; though most of it is junk anyway,
it could be worth checking your favourite software before you buy.
KnifeST goes very strange if you try to swap to another program and
Wercs (as supplied with LC 5.52) crashes all the time- I have never
liked this program much, and it apparently crashes on the Falcon
anyway: come on HiSoft, it's about time WERCS was rewritten. Protext
V4.37 and Prodata will only run in single mode and the Protext config
program locks if the mouse is used. My favourite CLI by far, Gulam
(beta test version) has problems running because the key bindings
remap the keyboard and some (not all) other programs then produce junk
when you use the keyboard; pressing shift-help when in use can
sometimes limit the problem. Cubase Lite, and a borrowed Cubase V3
crash on loading- this is a major problem for me, so for the meantime
it has to be back to my old TOS for these; apparently Steinberg are
checking this out. KCS Omega V1 is out as well, Tiger is better than
KCS, but the screen still gets messed up, menus swap by themselves and
so it's again back to the old TOS (mind you, Omega isn't too stable
under that either!). Lastly, and most drastic of all in my case, X-
Debug has become unusable; whilst it appears to run OK, it locks up
when running my GEM programs, I don't know where the problem lies, but
I have set the assumptions flag to 1, and it makes no difference; I
admit this may be because I haven't fully got to grips with all the
options available in X-Debug, but as my programs run OK normally on
MagiC, within MonST and within X-Debug with my old ROM TOS, I don't
think this is the case. I sincerely hope that Andy Pennel will revise
this, as I can't live without it.
Here is a list of all the software I have been able to try out, with
the results as follows:
Software that runs OK under Magic & NVDI (may need memory limiting):
Address V1.8 (unregistered)
AIM V3.00
Calligrapher (STR version):won't switch when printing
though
Devpac V2
Edith V1.0 (demo)
Egale V1.52
Everest 3.3E (unregistered)
Ghostscript V?
ST-Guide V(27.5.94)
Imagecopy Colour
Kandinsky (unregistered)
Kobold (STR demo)
Lizard V1.0
Opus V2.2
ORCS V1.0(unregistered)
Lattice C V5.52: won't switch when compiling from editor
Selectric V1.1
Superbase Personal V1.028
TEX V2.9 & probably V3.1
Programs that run with some problems: (* means not recommended):
Arabesque (STF version) ; single only
Calamus V1.09n
Easydraw V2
Gulam Beta test; problems with keyboard entry
KCS Omega V1 *
KnifeST V1.1 ; don't switch tasks
Megapaint V2 * ; single only, screen gets very messy
Music DTP V2.2c
Prodata V1.18 ; single only
Protext V4.37 ; single only, avoid config program
if possible
Tempus V2 * ; As usual, this one is a real pain !
Programs that fail miserably:
Cubase Lite V1.0
Cubase V3 ; presumable all other V's as well
DIPS V?
Omen (demo version); What did you expect?
TEXdraw V?
Wercs V?
X-Debug V1.01 ; unless I'm missing the point here?
A lot of old PD doesn't work.
Autoswitch Overscan software V3.00 is not compatible with MagiC, I was
told it was when I bought mine, so ask for some proof before forking
out good money!
Summary:
In general, the sooner MagiC becomes officially recognised as the new
Atari operating system the better, as unlike MTOS, it offers a stable
total replacement to TOS, and it works !! There are also hints in the
MagiC manual that suggest Mint/MTOS features will be added in later
releases. Despite problems, compatibility is generally excellent, and
lets face it, none of the competition is going to be better in this
department; many recent German shareware programs actively support
MagiC, and the quality of this stuff is generally amazing. From what I
read, Geneva seems less reliable than Magic, is not a complete
replacement (it won't run on pre TOS 1.4 machines) and does not
support pre-emptive multitasking, - I'll leave you to make your mind
up on that one!
These are obviously only my views and I will not be held responsible
for any errors in this text or problems arising from any
interpretations or assumptions made from it. I hope this has been of
some use, and please bear in mind that some compatibility problems may
be caused by NVDI and not MagiC (I couldn't be bothered to check every
program!). If anyone has similar problems, or has answers to some of
mine, please write to me. If anyone has software that needs testing
under MagiC or/and NVDI (4 meg STFM+HD+MM), I will be happy to check
it, but you must enclose a S.S.A.E. or I will not reply, you have been
warned!
By some freak happening (why do I get so many of these?!) NVDI did not
get installed correctly on my system, and it took me 3 weeks to
notice. The differences are not great, but the system is now even
faster, and slightly more compatible:- If run singly, the screen
problems with KCS and Tiger are less problematic, however the MPE
crashes badly if you try to run Tiger from within KCS. I was having
screen redraw problems with Megapaint, but these are fine now.
Arabesque (STF version) also runs fine in single mode. X-Debug seems
slightly happier, but is still unstable under many weird and wonderful
situations (i.e. who knows when it will crash next!).
I have found that the config program for Prodata behaves exactly as
the one in Protext i.e. moving the mouse within this program will
crash the system:- don't do it!
Apparently the latest version of Autoswitch Overscan does work with
MagiC, it is probably version 3.0 zi (I have 3.0 zg), and if anyone
needs to get the upgrade, Compo are the new distributors, not System
Solutions. As I haven't got it yet, I can't comment on this one.
I have also included a print out from the GEM_TEST program supplied
with NVDI to give an idea of the speed increases. Remember that this
is compared to a TOS1.0 STFM, users of later TOS's will not get quite
so good results, and that since GEM_TEST was written by 2B, its
probably optimised to give particularly impressive results with MagiC
& NVDI !!! Even so, not bad eh? I haven't got a program to test the
speed of non-GEM system routines, but believe me, they are all
considerably faster. You can also throw away Pinhead, Poolfix, Foldxxx
and all those other utilities that were an essential part of TOS based
setups.
I am sure that there are problems with this system, but the only one I
have noticed is that the menu bars occasionally don't switch when the
window of another application is selected; this is easily corrected
however by selecting the application required from the program
manager.
*
* NVDI GEM-Test V2.00 (c) 1991-1993 by Sven & Wilfried Behne
*
* Resolution : 640 X, 400 Y
* Planes : 1
* color pens : 2
* Palette : 2 grades
* Operating system: Mag!X 2.01
* Reference : TOS 1.00/ST-High
* NVDI version : V2.51 installed
* GDOS version : NVDI
* Blitter : doesn't exist
* CPU : M68000
* FPU : doesn't exist
* Machine : ATARI ST
*
Text output : 952 %
Lines : 325 %
Rectangles : 498 %
Polygons : 220 %
Circles/Ellipses : 371 %
Raster operations : 315 %
Attribute functions: 489 %
Inquire functions : 365 %
ESCAPES : 297 %
BIOS output : 225 %
GEMDOS output : 647 %
AES object draw : 1121 %
v_gtext (8 chars, height 4, effect 0): 309781 P/s
v_gtext (40 chars, height 4, effect 0): 366441 P/s
v_gtext (8 chars, height 6, effect 0): 642509 P/s
v_gtext (40 chars, height 6, effect 0): 1103299 P/s
v_gtext (8 chars, height 13, effect 0): 794375 P/s
v_gtext (40 chars, height 13, effect 0): 1255478 P/s
v_gtext (8 chars, height 13, effect 1): 789590 P/s
v_gtext (40 chars, height 13, effect 1): 1248304 P/s
v_gtext (20 chars, height 13, effect 29): 131072 P/s
v_justified (8 chars, height 13, effect 8): 775573 P/s
v_justified (40 chars, height 13, effect 8): 1243567 P/s
v_gtext (20 chars, height 26, effect 0): 1217010 P/s
v_pline (horizontal): 3192019 P/s
v_pline (vertical): 321027 P/s
v_pline (arbitrary): 131850 P/s
vr_recfl (48 * 20 points, fillcolor 0, fillstyle 0, fillindex 0):
3130000 P/s
vr_recfl (48 * 20 points, fillcolor 1, fillstyle 2, fillindex 3):
1674000 P/s
vr_recfl (100 * 100 points, fillcolor 0, fillstyle 0, fillindex 0):
7792000 P/s
vr_recfl (100 * 100 points, fillcolor 1, fillstyle 2, fillindex 3):
3708000 P/s
vr_recfl (638 * 400 points, fillcolor 0, fillstyle 0, fillindex 0):
21096000 P/s
vr_recfl (638 * 400 points, fillcolor 1, fillstyle 2, fillindex 3):
12594000 P/s
vrt_cpyfm (100 * 100 points, horizontal moved): 1624000 P/s
vrt_cpyfm (640 * 200 points, horizontal moved): 2510000 P/s
vrt_cpyfm (640 * 200 points, horizontal moved): 2512000 P/s
vrt_cpyfm (320 * 200 points, vertical moved): 7327000 P/s
vrt_cpyfm (640 * 200 points, vertical moved): 8894000 P/s
vrt_cpyfm (640 * 200 points, vertical moved): 8914000 P/s
vro_cpyfm (100 * 100 points, horizontal moved): 1624000 P/s
vro_cpyfm (640 * 200 points, horizontal moved): 2511000 P/s
vro_cpyfm (640 * 200 points, horizontal moved): 2512000 P/s
vro_cpyfm (320 * 200 points, vertical moved): 7340000 P/s
vro_cpyfm (640 * 200 points, vertical moved): 8904000 P/s
vro_cpyfm (640 * 200 points, vertical moved): 8923000 P/s
1000 calls of vst_height : 68 ms
1000 calls of vst_point : 69 ms
1000 calls of vst_color : 61 ms
1000 calls of vst_effects : 59 ms
1000 calls of vst_alignment : 67 ms
1000 calls of vsl_color : 62 ms
1000 calls of vsl_type : 60 ms
1000 calls of vsl_udsty : 55 ms
1000 calls of vsf_interior : 73 ms
1000 calls of vsf_style : 78 ms
1000 calls of vsf_color : 61 ms
1000 calls of vswr_mode : 61 ms
1000 calls of vql_attributes : 68 ms
1000 calls of vqf_attributes : 64 ms
1000 calls of vqt_attributes : 85 ms
1000 calls of vqt_extent : 226 ms
1000 calls of von vqt_width : 85 ms
1000 calls of vqt_name : 146 ms
1000 calls of vqt_fontinfo : 104 ms
1000 calls of vqin_mode : 63 ms
1000 calls of vq_color : 91 ms
v_curtext (without scrolling) : 2308000 P/s
v_curtext (scrolling) : 462000 P/s
Bconout (without scrolling) : 1106000 P/s
Bconout (scrolling) : 379000 P/s
Cconws (without scrolling) : 2496000 P/s
Cconws (scrolling) : 469000 P/s
--------------------------- End of file ------------------------------
