███████████ █ █ █ ████████████████
█ █ █ █ █ █ █
█ ████████ █ █ █ █ █ █████████████ █
█ █ █ █ █ █ █ █ █ █ █
█ █ █████ █ █ █ █ █ █ █ ██████████ █ █
█ █ █ █ █ █ █ █ █ █ █ █ █ █ █
█ █ █ █ █ █ █ █ █ █ █ █ █ █ █
█ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █
█ █ ███ █ █ ██ █ █ █ █ ████ █ █ █ █ █
█ █ █ █ █ █ █ █ █ █ █ █ █
█ ████ █ ████ █ █ ███████ █ █ █ █
█ █ █ █ █ █ █ █
█████ ██████ ██████████ █ █ █
Procomm on the PC
Build an Amiga Sampler
Mathematical Computer Games
Amiga Messages & Ports
C128 Fast Word Searches
Chairman Geoffrey J. Reeves Secretary Rocco Matassa Treasurer Brian Ward General Librarian Tom Kinsella Amiga Librarian Eddy Carroll Communications Liam Murphy Hardware Steve Kemp Software Shane Broadberry Newsletter Editor Eddy Carroll
CUGI Meetings are held every second Friday at 8:00 PM in the computer room at St. Andrew's College, Booterstown. All correspondance should be addressed to:
CUGI.
c/o St. Andrew's College.
Booterstown
Blackrock.
Co. Dublin.
Volume 1 Number 6
September 1989
Editorial Eddy Carroll 2 The Pro's and Con's of Procomm Brian Ward 4 Modem Communications in Brief John Pelan 8 Golden Words & Dashing Graphics Colm O'Rourke 12 Microcomputer Interfacing Part 2 John Pelan 14 Club Diary Secretary 16 Rocco's Ramblings Rocco Matassa 17 Searching for the Right Words Geoffrey J. Reeves 18 Mathematical Computer Games Russell Wallace 23 DIY Amiga Sound Sampler John Pelan 26 A Year On Stephen McGerty 28 Amiga Messages and Ports Shane Broadberry 30 CUGI Crossword #3 Rocco Matassa 36
Welcome to the Autumn edition of the newsletter, which manages to legitimately claim the title "September Issue" by a mere two days. As threatened in the last issue, AmigaTEX has taken over from Professional Page as the software used to produce the newsletter, and I hope the improvement will be noticeable. Though this issue was printed on a laser printer with a slighly lower resolution than we've previously used, I think the flexibility introduced by TEX (pronounced "Tek" by the way) more than compensates.
Of course, this isn't a perfect world, and so Professional Page has been retained to take care of a few things I haven't quite had the time to teach TEX how to do. In particular, TEX doesn't know about the CUGI logo yet, so the title page and contents page have been printed using Professional Page. The version of TEX I'm using doesn't support output of IFF graphics to non-PostScript printers (though the latest version does), so the screenshots, circuit diagram and crossword have been done on PP also.
Since the deadline is drawing close, and the sun is starting to rise outside, I'm not going to waste time coming up with some stunning examples of what TEX is capable of. Maybe next time.
Once again, the newsletter has grown in size. This issue seems to have something of a communications flavour, with a look at Procomm on the PC, a glossary explaining all those mysterious terms like baud and parity, and an in-depth look at the RS-232C interface. There are also plans for building a sound sampler for your Amiga, and a program to help you search string arrays rapidly on the C128, plus the usual mix of general interest articles. There are no articles for the C64 however, for the very simple reason that none were submitted. I know that many members have upgraded to the
Amiga over the past year, but surely there is still some interest in the C64?
Since the June issue, I've been getting to grips with Lattice C V5.0. In particular, I've been playing with CodeProbe, the source level debugger which is part of the package. This program is amazing! (It would be even more amazing if it didn't crash occasionally, but that's another story.) It will let you display the source code for a C program onscreen, and then let you step through it line by line, or run it until a certain line is reached, or a certain condition becomes true. You can also do useful things such as displaying your source code intermingled with the assembly language that was generated for each line. Watch for a review in the next issue.
In the middle of July, I headed off to Nottingham for a long weekend to attend the 1989 ADAB UK Developer's Conference. Since I was travelling by car, I was a bit apprehensive about my ability to navigate the route from Holyhead to Nottingham (I have an undeserved reputation for getting lost) but in the event, I arrived an hour ahead of schedule, on Friday evening.
On Saturday, the conference itself started. There were quite a few "big" names there, including Gail Wellington of Commodore International, Carolyn Scheppner of Commodore Amiga Technical Support (CATS), Jez San of Argonaut Software, Dave Parkinson of Ariadne, Simon Tranmer of Precision Software, Mike Todd (editor of Transactor UK) and so on. All in all, about 80 people attended during the two days. After we each received a "Commodore Pack" (including a Commodore notepad, Com-modore biro, Commodore bag, and lots of Commodore literature), the conferences started. Saturday was aimed mainly at programmers unfamiliar with the Amiga, but with a few things thrown in to keep the more senior Amiga gurus from getting bored. Speakers of note were Dave Parkinson, Simon Tranmer and Jez San.
Sunday was where most of the real meat was to be found. Most of the morning was given over to Gail and Carolyn, who gave a detailed presentation of what to expect in Workbench 1.4, and also what new peripherals Commodore are planning to launch. I'm sure that by now, everyone has read about Workbench 1.4, and knows that it will be well worth upgrading to (a MUCH bigger upgrade than from WB 1.2 to WB 1.3). Some of the new peripherals were interesting as well, such as a hi-resolution graphics board (1024x768 in 256 colours out of 16.7 million) and a 7-port serial card for the A2000. No date was given for the shipping of these however, so it will probably be a while before they appear on the market.
Sunday afternoon concentrated on serious Amiga programming, with Jez San giving an interesting talk on how to "hit the metal" in the Amiga without killing the operating system. He also demonstrated a prerelease version of Argonaut's forthcoming game Hawk (a very fast 3D flight simulator/combat game) and a new assembler, ArgAsm, which has a peak rate of 1,000,000 lines of code per minute (yes, that's really six 0's). I ordered a copy of the latter on the spot, but it hasn't arrived yet. When it does,
CUGI will certainly be getting a demonstration.
Out of space and out of time. The deadline for submissions for the next issue is 1st December. Until next time!
by Brian Ward
A lot of people today are buying modems to supplement their PC's only
to find themselves bogged down with such terms as baud rate, protocol and
parity. When you do eventually get a modem, the first thing you want to
do with it is phone up a Bulletin Board, but unfortunately you don't even
know where to start. So this is as much as possible, an idiot-proof guide to
the comms software in the CUGI PC library known as Procomm
The first thing you you have to find out when you take the modem out of its
box is if you have the correct lead for your computer. The lead should be
an R$232 cable, but there are two types, DTE and DCE. DTE stands for
Data Terminal Equipment and DC is Data Communications Equipment.
If your machine is DTE then with the appropriate lead all you have to do
is plug straight in to your machine. However if your machine is DCE then
you'll have to get a special lead either made up or purchased. The dealer
who sold you your modem should know and have a stock of either cable.
Make sure you specify whether your modem and your computer have male
or female connections.
Okay, we have our modem, we have our cable, so we are ready to go. First
turn on your modem. Then load Procomm. During the loading, a message
will flash up saying "INITIALISING" and you will notice the LED's on
your modem flashing. When Procomm loads, it sends a command string to
your modem which may be up to 46 characters in length. The default is set
for a Hayes or compatible modem, which is ATEO S7=60 S11=55 SO=0
V1 X1. "What the hell is that?" I hear you cry. These are commands that
the modem understands. ATEO means ATtention Echo Off, S7=60 means
wait 60 seconds for carrier etc. Each modem has its own peculiarities, but
generally they are mostly the same.
So the program has loaded and you want to make that first call. The next
thing that you have to do is set the baud rate for your modem. The baud
rate is the rate at which data is transferred between the two machines. Io
set the baud rate, you must enter [ALT] P. It will then give you a screen
which will have at the top the current settings. You may choose the baud
rate which your modem is capable of or leave it as it is. Hit [ESC] and you
will return to the main screen. Now type 'at' or AT [RETURN]. Some modems
ignore lower case characters so depending on which one your own modem
uses, enter accordingly. If everything is going well, you should get an "OK"
response from your modem. If not, reset the modem and try again. If you
get "atat" or "ATAT" your local echo is turned on so try typing [ALT] E to
turn it off.
Don't worry, you won't have to do this every time, because you can
tell the modem to turn off the echo in the initialisation string which we
will come to later. The command to dial is normally ATD followed by the
number you want to dial and [RETURN]. The OL (Online) light should go on
and start to flicker as it dials the number. When the modem at the other
end answers, the CD (Carrier Detect) light should go on. Now you have
logged on and you're away.
The next thing you will need to know is how to upload and download files.
When you have logged on and found the files section, you must first tell the
other computer what type of data transfer you are using. Procomm has
several including Xmodem, Ymodem, Kermit and Ascii. The form you use
is dictated by the BBS - if a BBS only offers Xmodem, then you won't be
able to use Procomm's Ymodem transfer. The transfer method is called the
protocol, so when the other computer asks "Which protocol?", you reply
Xmodem, Ymodem or whatever.
You are now ready to start the transfer. When you have selected the
file you wish to download the other modem will now be waiting for a signal
from your modem to start the transfer. Hit [PgDn] and you will then be
asked by Procomm which protocol you will be using. Hit the number that
you want, and another screen will ask you the name of the file. Be sure
to add in the extension e.g. GAMES.COM or GAMES.ARC. Hit RETURN
and your computer will do the rest. When it has finished, the computer
will start sounding an alarm, so if you want to, during an extremely long
transfer, you can go off and make a cup of tea. The file receive is basically
the same except you hit [PgUp] instead.
After the initial ecstasy has worn off, you can try out some more time saving
ideas. Hit [ALT] [F10] to display Procomm's Help screen. Hit [ALT] P to get
to the Initialisation screen, where you can configure Procomm for your own
modem. Once you have done this, you will never have to do it again. The
Various commands and functions can be found in your modem manual.
Now that you're getting to grips with the software, let's try setting up
the phone directory. Hit the [ALT] D keys and you will be brought to the
directory screen. To enter a phone number, hit R for Revise and off you go.
When you are finished entering your numbers, you will be asked if you want
to save them to disk, so you will then have a permanent directory which you
can add to or delete from at will in the future. Once this has been done,
all you then have to do is call up the directory and hit the number beside
the phone number that you want, and wait for a carrier. If you find that
the number is busy, hit [ALT] [R] and the computer will redial and continue
to do so until you cancel the command.
"What is a macro?" I hear you ask. Well, a macro is a series of keystrokes
which you can allocate to a specific function. Basically it's just like a batch
file where a series of DOS commands are named, and when you hit that
key or series of keys, the commands are carried out. What good is this to
you? Well you could, like I have done, allocate your name to a macro, or
your password or even your credit card number if you use it to purchase
goods over the modem. This is very handy if you have different passwords
on different BBS's. You enter the macro screen by hitting [ALT] M. This
brings you into the screen and as with the directory screen, you type R to
Revise or enter the macro. When you're online, you can send the macro by
hitting [ALT] and the number of the macro that you want to send. It is very
easy to use and extremely useful. Of course, if you give a copy of Procomm
to a friend, make sure you haven't left your password installed in one of the
macros, or you could be in trouble.
If you want to turn your printer on, [ALT] [L] will do so. If you have a
hard disk or a twin disk system and you want to change the drive, [ALT] [B]
will achieve this. If you're logged on to a BBS and the screen scrolls past
without stopping, [ALT] [F6] will redisplay the last 4000 characters received.
If you are online and are just about to download the program that you
have waited for for months, and your foppy disk drive suddenly informs you
that the disk that you are just about to save the data to isn't formatted,
DON'T PANIC! There is a way to get back to DOS and perform all your
DOS functions without dropping the line. This is called the DOS Gateway.
All you have to do is hit [ALT] [F4] and you will be back to where you started
from, but you will technically still be online. One word of warning though.
Don't delay too long in the DOS Gateway, because most BBS's log you off
automatically if you haven't typed anything for about 5 minutes or so.
I hope this has been of some assistance to somebody. Certainly when I
started using a modem and Procomm, I was totally lost and I would have
been glad of some assistance. If you have any other problems that have
not been discussed, drop me a line or send me a message on Infomatique
or Niteline, and I'll try and help you. I have compiled a table of all the
commands discussed here along with a few I didn't mention. The only way
to find out sometimes, is to push the button and hope. So happy modeming!
ALT D | Dialling Directory | ALT B | Change Directory
ALT R | Automatic Redial | ALT C | Clear Screen
ALT M | Keyboard Macros. | ALT E | Toggle Echo/Duplex
ALT P | Modem Parameters | ALT H | Hang Up Phone
ALT W | Translate Table | ALT T | Elapsed Time
ALT A | Editor | ALT L | Printer On/Of
ALT X | Exit to DOS | ALT Z | Set Colours
ALT Q | Host Mode | ALT F3 | Toggle CR-CR/LF
ALT Q | Chat Mode | ALT F7 | Break Key
ALT F4 | DOS Gateway | ALT F | File Directory
ALT F5 | Command File | ALT V | View a File
ALT F6 | Redisplay | ALT G | Screen Dump
ALT I | Program Info | ALT F1 | Log Open/Close Toggle
ALT S | Setup Screen | ALT F2 | Log Hold
ALT K | Kermit server cmds. | ALT PgDn | Receive Files
| ALT PgUp | Send Files
A quick but comprehensive guide
by John Pelan
This guide was designed to be read in order, but you can dip in at auy
point if you understand the previous terms. The ones at the end need nor
necessarily be understood for successful communications.
A device that allows computers to communicate across normal telephone
lines. It converts those ones and zeros into audible tones and back again,
i.e. MOdulates and DEModulates. A dumb modem does nothing else but
this, whereas an intelligent modem will have a range of commands at its
disposal like Dial Number or Hangup. The modems made by Hayes in the
US have become so popular that the set of commands they use (the so
called AT command set because each command begins with 'AT') has been
adopted by many modem manufacturers.
A cable designed to let two near-by computers talk together without the
need for any modems.
It does the job that the modems normally do,
i.e. switches the TX and RX lines.
Literally means 'two-fold'. Full duplex means simultaneous transmission in
both directions while half duplex means that only one end can talk at any
given time. Half duplex is rarely used.
This is the computer that you dial up.
When you type on a terminal keyboard, the characters are sent to the host
and are echoed back, so you can see what you have typed. If the host
doesn't do this, i.e. if it's running in half duplex mode, then you can set
local echo (or half duplex) so that you can see what is typed.
If you are online and you can see everything you type twice, that means
that you have local echo on when the host is echoing everything back as
well. The solution is to turn off local echo.
The transfer speed is given in bps (bits per second) and is in the format
receive speed/transmit speed, e.g. 2400/2400. The term split speed means
that the receive and transmit rates are different and generally applies to
1200/75. The most common bps rates are 300, 1200, 2400, 4800, and 9600.
This is the rate at which the modem modulates the signal and is not to be
confused with the number of bits per second (bps). Many people use the
two terms interchangeably, but they mean different things.
Many modems offer this feature. This means that you can 'talk' to your
modem at one speed while it 'talks' to the other modem at a different
speed, e.g. computer to modem 1200/1200 and modem to modem 1200/75.
This is normally used with split speeds, as in the example, because many
computers can't handle split speeds properly and must have the same speed
in both directions.
Most computers represent characters and symbols with either 7 or 8 bits.
You must determine which length the host uses before calling. With each
group of 7 or 8 bits an additional parity bit may be sent along. This parity
bit will be set to make the total number of 1's either odd or even and is
used for error checking. For example, the 7 bits 0101010 would be followed
by a parity bit set to 1 if even but set to 0 if odd. Finally after the character
gets sent, either one or two stop bits follow.
These parameters are expressed in the form 'word length-parity-stop
bits' and the following are the most common combinations:
8-N-1 meaning 8 bits, no parity and 1 stop bit 7-E-1 meaning 7 bits, even parity and 1 stop bit
To be able to calculate how many characters are sent per second, you need
to know the bps rate together with the word length, parity and stop bits.
Each character is sent as a group of bits:
Start bit (this is always sent) 7 or 8 bits for the character in question Parity bit (if any) 1 or 2 stop bits
So with the 8-N-1 setting at 1200 bps you get 1200/(1 +8+0 + 1) = 120
characters per second.
Different tones are used for the callins and answering moderns to avoid
any confiction of signals. The calling modem uses originate tones and Whe
answering modem uses answer tones.
The V numbers represent particular standards described by the CCITT(a
big French abbreviation). The common ones are as follows:
V24 This is what you and I call the RS-232C interface and deals with the connections between computers and modems. V21 300/300 bps full duplex V23 1200/75 bps full duplex V22 1200/1200 bps full duplex V22bis 2400/2400 bps full duplex V32 9600/9600 bps full duplex
A set of rules governing a method of data communications. There are many
file transfer protocols which allow files to be transfered error free, and often
in groups (batches). The popular ones are Xmodem, Ymodem, Zmodem
and Kermit and these are all freely distributable. Zmodem is currently the
fastest, and has several other nice features to recommend it as well.
Kermit is more than just a FTP. The Kermit program has a server mode
which when set up on the remote computer allows you to send and receive
files by name, type etc. and effectively gives full control of file handling on
the host. The protocol is relatively slow however.
This stands for Microcom Networking Protocol and is a proprietary erof
correction/data-compression protocol. There are different levels of MNP,
the lower ones (up to level 1) only deal with error-correction while the
higher ones deal with compression too. Each level is upwards compatible
with lower levels. It has threc major advantages:
connection at the highest level they have in common.
over double the uncompressed rates in some cases.
It is not a CCITT standard, and V42bis may supplant it in popularity.
The Public Switched Telephone Network, i.e. the normal phone system as
provided by British Telecom and Telecom Eireann.
These are actual cables (either two or four wire) that are permanently
connected between places (for example, head office to branch office). They
are leased from telecommunications companies, are miles long and are very
expensive.
Integrated Services Digital Network. The future replacement for the cur-
rently analogue telephone network. (Current digital exchanges only use
digital switching techniques on analogue signals).
Optical fibres are used in place of wires and will carry many high speed
data channels in both directions simultaneously. A single optical fibre lead-
ing into your home will supply all your communications needs, including
television as well as telephone. Because the system is inherently digital,
modems as they are today will not be required as there will be a direct link
from your computer into your ISDN termination box. The transmission
will be ultra-reliable and could dispense with much of the present day need
for error-correction.
by Colm O 'Rourke
I switched on the computer, the printer winked at me did a double shute
and slowed ready. The disk drive whirred and the screen awoke to dispa,
TV Text. Load in the fonts and the selection appears on the screen. Select
an individual font and the available sizes are shown. Enter text and when
your golden words appear on the screen you can change face colour, shador
colour, outline colour and light direction at will. You can decide on the
depth of shadow and you can even select strobe mode in which each letter
appears four times creating a very colourful pack-of-cards effect.
When this work of art is ready to be stamped on the screen, you have
a further choice. You can overlay it on any background to create some
very useful slides. "Oh joy," you say, "This is fantastic." It is indeed but
like many other wonderful moments there is a dark cloud just waiting to
pounce. It is an easy mistake to make and it happens like this. The golden
words are ready and saved. The superb graphic is also safely on disk. Load
the graphic and pause a moment to enjoy it. After all, you have spent a
long time creating it. When you are ready, overlay the text. Shock, horror!
The letters appear using the graphic colour palette. The result is pathetic.
In desperation, you reverse the procedure. Load the text and overlay the
graphic. Even worse. The graphic is now using the text colour palette. I
have not been able to find a way around this problem, but maybe someone
out there has. My present solution is to carefully select the colours of the
graphic so that the text will shine through. The screen shots shown here
display well in colour but I am not certain how they will print up in the
newsletter.
This is an exciting time for anyone interested in text and graphics work
for video recording. The programs available for the Amiga are improving at
a rapid pace and the gap between advanced amateur and basic professional
equipment is narrowing all the time. I recently photographed an Amiga
graphics screen using a 35 mm SR manual focus camera mounted on a
tripod. The room was as dark as I could make it and the exposure was
one second at 12.8 on to 100 ASA slide film. The screen filled the slide and
the projected result was very good. No genlock is required using TV Text
to videotape, as the overlay and graphics merge to form one picture. If
you have an insert-edit machine in which the control track remains unin-
terrupted no matter how many video drop ins you make, then those little
annoying blips and glitches which I have to contend with while doing crash
edits will not be a problem for you. I would go further and say don't buy
a video recorder unless it has a proper insert edit mode.
I really must get some more memory soon, or perhaps a hard disk, or
maybe a colour printer, or a text reader, or even an Amax Macintosh em-
ulator, or maybe I'll settle for a sandwich. The joys of computing. That
never ending battle for peaceful co-existence with an overgrown silicon chip
which has become the all pervasive force just sitting in the corner waiting
to be entertained with the latest goodies. Well, I'm sorry Amiga, you'll just
have to wait a little longer for your next course. Remember, I have to eat
as well - and as for your little brother Z88 sitting smugly on the sideboard
chewing his extra memory packs, well that's another story.
Part 2 - The dreaded RS-232C interface
bu John Pelan
The last exercise I left you asked "What problems do you expect to en.
counter when attempting to make two computers communicate?"
You should have a sizable list there but I suspect that most of you will have
underestimated the problem.
Never under-estimate the problem at hand, otherwise you'll waste time and
probably money pursuing a project that will never work. Think it out fully.
To illustrate the point: you should be able to divide your list into two
sections, hardware and software. The hardware side deals with getting both
ends electronically compatible while the software side ensures that they both
speak the same language (protocol) harmoniously. By harmoniously, I mean
they don't both talk together nor should they be wasting time waiting for
data that isn't going to arrive. Did you think of that?
Take RS-232C. This standard was laid down over twenty years ago as
a common means of connecting computers (called TE for Data Terminal
Equipment) to some sort of data equipment (called DCE for Data Com-
munications Equipment), such as a printer, modem or even another DIE.
Devices in those days were slow and couldn't really cope with lots of data at
once. In fact, the data had to be passed in 'series' as a sequence of bits, i.e.
I's and O's. Another problem was the fact that they all worked at different
voltage levels and so this had to be catered for.
It was decided that a voltage level between -3V and -15V would represent
1 and a voltage between +3V and +15V would represent O. What happens
between -3V and +3V, I hear you ask. The answer is nothing, as the line
wouldn't be in either state, i.e. 1 or 0. This is a protection against noise
since it would take 6 volts to switch between states.
Line noise rarely
occurs at that level, thankfully. Notice though that these voltage ranges
are outside those normally found in a computer and are potentially lethal
to a computer. Special voltage interface chips are available that will do the
necessary voltage conversion.
What does an RS-232C connection consist of?
First we need a line (electrical conductor) to provide a common reference voltage (voltages are
always measured with respect to something) of zero volts. This is called
the Ground (GND) or Common line. Next we need the data lines of course;
one for data out (TX) and one for data in (RX). At this point, you may
say that's all we need as we can now send and receive data. This is true.
What this is called is a 3-line interface. Obviously!
A small diversion is necessary (recall 'harmony'?). When people com-
municate, they have a common set of rules (etiquette) as to who starts
first, when to stop, when to get the quick sarcastic comment in and how to
pass control of the conversation to another. This is all done by signs and
gestures, usually unconsciously (well at parties anyway). Computers there-
fore must have a similar means of 'conversation control' and this is called
handshaking. It is VERY important and will occur often in our interfacing.
With the RS-232C interface, handshaking is achieved by extra control lines
between the two machines. With these extra lines, the RS-232C interface
is called an X-line interface.
Here's a list of those extra lines and a brief description of what they
mean when they are high, i.e. above +3V. Clearly the opposite applies
when they are low, below -3V
(DSR) Data Set Ready - The DCE (modem) is on and ready (DTR) Data Terminal Ready - The DTE (computer) is on and ready (RTS) Request To Send - The DCE is ready to send data (CTS) Clear To Send - The DTE is ready to receive data (DCD) Data Carrier Detect - Tells the DTE that the DCE is receiving (RI) Ring Indicator - This line comes from a modem
It should be clear to you which lines are input and which are output. For
example, DR must come from the DCE, so it's an output line from the
DCE and is connected to an input line on the computer.
Now that you are feeling supremely confident, I'll shatter your dream.
Different manufacturers have different ideas about how the interface is im-
plemented and what type of connector to use! But DON'T PANIC as this
rarely poses a problem and you'll be glad to hear that any Commodore
equipment that has an RS-232C interface will be a common type, usually
a D-25 male connector.
VIC-20, C64 and C128 users may know that their machine already has
qalf an RS-232C interface - it's the software half. You will require a
hardware interface which can be built for about £5 (sce Tom Kinsella's
article in the March '89 newsletter). Should you wish to build it, you can
talk to Tom, Stephen Kemp or myself for assistance. Amiga and PC owners
have a fully fledged interface already.
Speaking of the software side, you may have noticed that it hasn't been
discussed yet. Well, there isn't a terrible amount to this. Read the section
about word length, parity and stop bits in the Modem Communications
article for more information.
I feel another terribly easy exercise coming on.
How would you better the speed of a serial system?
Well, here we are at the end of another article and we haven't even men-
tioned electronic components yet. Patience comes to he who waits. Until
next time, just remember this:
Patience will be rewarded with an interface that lives longer than you do.
____________________
You might like to have an idea of some of the items coming up in the next few months, so mark a few dates in your diary:
Oct 13 - Table Quiz - Fun and prizes galore! Oct 27 - Lattice C version 5, and much more Nov 10 - The Annual General Meeting (with coffee and bikkies) Nov 24 - Suggestions welcome Dec 8 - Ditto Dec 15 - One week later - The Christmas Table Quiz. Fab prizes, etc.
[p17]
by Rocco Matassa
It's funny how people need to cheat. That urge to hold back a card, or contrive to see what your opponent's hand consists of. The slight bending of the rules, when playing someone who is not familiar with the game. Sports present a challenge to cheats that is not usually found elsewhere, as observant officials keep a watchful eye on the proceedings, and of course perform random drug tests.
I can understand the motivation behind cheating - after all who re-members second place - and the more competitive the event the greater the reward. Gold medals, money, glory and status - who doesn't cheat?
Have you noticed the number of pages in computer magazines devoted to playing tips, pokes and cheats? I for one enjoy them as they not only allow me to complete games, but they reassure me that I am not the only one who finds many arcade games impossible. I rarely use 'hints' while doing an adventure. I guess it's because I feel confident in my abilities to solve any puzzle presented, if for no other reason than that they were d
evised by other people. I do not believe for one moment however, that arcade writers can actually complete their own games.
At what point does cheating become pointless? If for instance you have bought a game/adventure and you then cheat, you will find the time/ money ratio reduced and accordingly the value of the product reduced. When playing against yourself, in Patience for example, it doesn't make much sense to cheat. After all, who are you cheating? When playing with others, you could rapidly find yourself not only unpopular but also unwelcome. Table games like Dungeons & Dragons seem to draw the worst and best from players, people really do lose their cool.
Some software, notably adventures where text input is normal, tries to counter such abuse from poor losers by resetting the computer after the use of bad language or the persistent use of violence against non-violent characters. Such measures, while certainly having the desired effect (i.e. you stop using bad language and violence) are rather heavy-handed. After all, half the fun in many adventures comes from trying to do all the things that you're not supposed to do.
The important thing to remember is that it's only a game, and if the worst comes to the worst, you can just turn it off and walk away.
[p18]
by Geoffrey J. Reeves
One of the many advantages that the C128 has over the older C64 is its extra memory. In particular, it is now possible to write programs which need to store vast amounts of data in memory rather than on some slow peripheral. As I have being writing a multi-user adventure system (for some time now!), I needed to be able to check a very large vocabulary in order to parse sentences. Despite the FAST mode of the C128, there was little point in trying to write a search routine in BASIC. If it had been nothing more than a simple search, I might have considered it but I needed the following facilities:
1. Very fast operation.
2. To be able to specify which part of an array of words to check.
3. To allow abbreviations under some circumstances.
In order to satisfy the first requirement, it would have to be machine code or the array would need to be sorted to allow a binary search to be used. As you know, a binary search is very fast but it does require that the information being searched is in alphabetical order. If re-ordering the words in an array is a problem (more than likely), then you must use a tag array which consumes even more memory and may slow up the binary search thus defeating the plan. On the other hand, using machine code would itself cause a small problem on the C128 - the C128 stores its variable information in Bank 1 while most people write their machine code in Bank 0 or Bank 15.
I had already written other routines for my program which were working from Bank 0 and Bank 15 so I decided on an unusual but obviously sensible solution - write the code to operate from Bank 15 but to call another section in Bank 1. The C128 Kernal provides all the routines necessary to read from, compare with, store to, jump to and call other banks although I must say that many are cumbersome to use. Having read articles from magazines such as Transactor (the 8-bit edition), I have learned how to do this much more efficiently.
The program I would write would therefore be called from BASIC and so would pass on the necessary parameters:
[p19]
1. The word to be checked
2. The array to be searched
3. The number of the first array element to be searched
4. The last element
5. A variable to hold the position of the found word in the array
It would then set up the necessary information in Bank 1 or in an area accessible from Bank 1. Then the real trick - jump into Bank 1 and perform the search there. This would be very fast since no bank-switching would be necessary and I could use the FAST mode. Finally, that routine would need to leave the result somewhere handy - and since it was in Bank 1, why not directly into the area used by the variable mentioned above? Very neat and, as I said, very efficient!
So what do these routines look like, you ask? Actually, they are surprisingly short. Rather than present one large listing, I'd like to break the program down into its main components. I'll start with the routine in Bank 15 used to read in the parameters and call the search routine in Bank 1.
;
;use SYS loc:search string, array$(first), max, find pos
;
search = *
;
jsr decodstr ; Read in and set up pointers to word
sta len ; Store length of word
jsr getcomma ; Pass over the next comma
isr array ; Read in and set up the details of the array
; AND the first element to be checked
jsr comaddr ; Get another comma and last element to check
ldx #4 ;
ldy #0 ; Jump to $0400 in Bank 1
jsr gofar1 ;
;
jsr commavar ; Read in the variable to hold the result
lda index2
sta fac+1 : Move result into floating point accumulator
da index2+1
sta fac
jmp assfac ; And assign to the last mentioned variable
[p20]
For example, if W$ has been assigned to some word, and V$ is an array of words which is made of adjectives V$(1)...V$(100) and other words V$(101)... V$(250), then the command:
SYS location:W$, V$(101), 250, P
will search for W$ but only the array elements 101...250. If the word is found then P will be set to that element number, and if it is not, P will be set to -1.
To save a lot of unnecessary writing, I won't bother to reprint the routines which I gave in the last example in the June issue. So you won't find DECODSTR, GETCOMMA or ASSFAC listed here. Also, GOFAR1 differs only in the first instruction from the GOFAR routine - the former needs a LDA #1 (for Bank 1) instead of LDA #15. That leaves the ARRAY routine:
array = *
;
jsr var ; Read in the variable
ldx #1
;
loop lda vardata, x ; Transfer the pointer to the array
sta temp, x ; To somewhere else (??)
lda facint, x ; And save the first element no.
sta index2,x ; For later use
dex
bpl loop
rts
You'll also want the COMADDR routine - it's very similar to the GETCOMMA routine in the last issue. You'll need to add a new label/variable:
chkcomad = $880f
and then the routine:
comaddr ldx #›chkcomad
ldy #<chkcomad
jmp gofar ; This is GOFAR and not GOFAR1!
[p21]
And that's the calling routine done. Finished? NO! You haven't seen the actual search routine yet. This has to go in Bank 1 - I used $0400 because I knew it was very easy to fool the C128 into thinking that its Bank 1 variable space began at $0500 leaving me 256 bytes to play with.
POKE 47,0: POKE 48,5: CLR
will do the trick nicely but DO put it at the start of your BASIC program!
And now for the routine:
;
; Some variables
;
int = $16 ; This holds the max element no. to be searched
index = $24 ; Points to the array word being looked at
index2 = $26 ; Holds the no. of the current element no.
temp = $28 ; Temporary storage
;
search1 = *
;
lda int+1 ; Check if current element number
cmp index2+1 ; exceeds the max allowed
bcc notfound ; If it does' it's a case of NOTFOUND
bne srch2
lda int
cmp index2
bcc notfound
;
srch2 ldy #0 ; Pick up length of current array word
lda (temp),y
cmp len ; If it's smaller than our word
bcc srchnext ; then try the next array word
;
iny ; Otherwise, get the pointer to
lda (temp),y ; the array word and store
sta index ; it in INDEX
iny
lda (temp), y
sta index+1
ldy len ; Get length of search word' and
dey ; adjust to start check with last char
;
srch3 lda (pointr),y ; Compare the array word's char with
cmp (index),y ; the SEARCH WORD's char
bne srchnext ; No match - try the next one
dey ; Go backwards to the first char
bpl srch3
rts ; Matched exactly - result in INDEX2
;
notfound lda #255 ; Failed, set up result of -1
sta index2
sta index2+1
rts
;
srchnext clc ; To check next array word, move 3
lda temp ; along the array header
adc #3 ; (skipping the length and
sta temp ; two-byte pointer)
bcc srch4
inc temp+1
;
srch4 inc index2 ; Also, we must increment the element
bne search1 ; number that if we get a match,
inc index2+1 ; it'll be ready
bne search1 ;This is a cheeky Branch Always
Well, there you have it. Believe me, when I say it's fast! Despite using a sequential search technique (Boo...hiss.. etc.), I have encouraged the routine to be more efficient by, for example, checking for the length of my word exceeding the one I was about to check. Writing the code in Bank 1 and forgetting to set the right bank or to reset the Bank 1 variable space caused some very interesting effects but such are the rewards of machine code programming.
If you want a demo of this, I'd be happy to show you at any CUGI meeting provided you give me advance warning - I don't usually carry that particular disk around with me! Actually, there are two disks, one with the program and the other containing a 1200 word vocabulary.
Try it - it really is impressive.
[p23]
by Russell Wallace
What are computers good for? Ask an accountant and he'll talk about spreadsheets and graphs. Ask an engineer and he'll tell you they're for number crunching. Most of us know of course that computers are for having fun. Usually that means screens filled with alien landing craft, exploding ICBMs, bouncing balls or passages of text describing exotic fantasy worlds. How else can you have fun with a computer? Load up any of the hundreds of demo disks floating around the place, turn the volume up high and the lights down low. So you don't always need interaction with the computer. Interesting sound and graphics can be enough by themselves.
So how do you get nice sound and graphics? A process of artistic creation? Not necessarily. Mathematical formulae can do the job as well. Take the simple equation
z = z² + c
This equation describes something called the Mandelbrot Set after its discoverer, Benoit Mandelbrot. Think of it as an abstract landscape. There are programs available that can draw contour maps of the landscape using a different colour for each contour level. So why is this so interesting? The point is that the landscape is infinitely detailed. Literally. And every part of it is different from every other part. So you view different areas at different magnifications and every one gives you a different image. Fantastic shapes emerge, reminiscent of star clusters or Chinese dragons. A computer program can't give you infinite magnification of course, but if you think of the entire Mandelbrot set as being the size of Europe, most of the programs around will let you examine areas the size of atoms. So it's easy to generate images that nobody has ever seen before. Shortly after its discovery, an American computer graphics company started selling posters with Mandelbrot Set images. Business was good. Nowadays, you can produce the images with a home computer and public domain software.
For each point on the Mandelbrot Set another equation can be used to generate a contour-mapped landscape called a Julia set. A Julia set is not as interesting as the Mandelbrot set because a magnified piece of it looks the same as the whole set - it is a fractal, like a snowflake or a fern. But there are an infinite number of Julia sets, so there's still plenty of territory to explore.
[p24]
There are plenty of other fractal images that programs can generate, The Newton-Raphson method for solving differential equations can produce images as complex as a Julia set. There are programs that can generate pictures of mountainous landscapes using fractals, each one different from all the others. Or pictures of ferns or snowflakes, the classical examples of natural fractals (if you magnify a frond of a fern, it looks the same as the whole fern, so does a sub-frond of the frond etc).
These are all still images. What about motion produced by abstract formulae? This is the territory of Cellular Automata. Take John Conway's Game of Life. Imagine a grid of squares, in principle extending to infinity in all directions, but in practice limited to a few hundred by a few hundred squares on a computer with finite memory. Each square can be in one of two states - call them ON and OFF. Start with a random pattern of ON and OFF squares and iterate according to these rules: Count each cell's ON neighbours, where a neighbour is a cell that adjoins horizontally, vertically or diagonally, so there are eight neighbours. A cell can have from zero to eight ON neighbour cells. An ON cell remains ON if it has two or three ON neighbours. An OFF cell goes oN if it has three ON neighbours. All other cells go OFF.
Keep following these rules on a fast computer with a high-resolution display and watch. The random initial pattern will condense into clumps with recognisable shapes. The same patterns will appear over and over again; some patterns will remain stable, some will constantly blink back and forth between two or more different forms, some will move steadily across the screen. You can study the forms that appear naturally from random patterns or try to devise your own. There are whole bodies of literature devoted to the Game of Life (so named because the changing patterns look almost like living organisms). It has been proven that there must be huge Life patterns, far too big to fit on any display screens, that can reproduce themselves and even act as digital computers.
Again there are many other sets of rules for Cellular Automata. The Game of Life uses a 2-dimensional grid and only 2 states for each cell. Devising rules is easy. Decide on how many dimensions you want (line, grid, cube, hypercube etc. but the more dimensions you have, the bigger the strain on memory and processor speed). Decide how many states you want for each cell and invent rules for processing the cells. The idea is to invent rules that produce results that look interesting.
[p25]
A final idea: Consider the attract mode on arcade games where the game plays itself as a demo. Or the computer-controlled characters in adventure games which in some of the more sophisticated systems can interact with each other as well as the player, and imagine running one of these in attract mode. Now suppose you have a game complex enough that the game world is continually evolving and changing, with power bases shifting as wars are fought and alliances made. Play it for a while. Then go off and leave the computer running overnight. When you come back the next morning the game world will have changed dramatically. Maybe a lot more complex than when you left it. Or maybe if you're unlucky most of it will have been destroyed in various wars, so you watch it running by itself for another while until it's been restored to a sufficient extent to be worth playing in. Maybe eventually there will be games that are supposed to be left running for a few hours before you play them for the first time to evolve an interesting, individual game world. It's a thought.
Further references
The Fractal Geometry of Nature by Benoit Mandelbrot, on fractals.
The Recursive Universe by William Poundstone, on the Game of Life.
An Amiga utility disk called Gizmoz contains a Game of Life program.
Contact the author, Russell Wallace, 24 Lower Georges St., Dunlaoghaire, Co. Dublin, Ireland (phone 807094) for public domain Amiga programs to draw Mandelbrot Set and Julia set images and run cellular automata. Also for a simple adventure game with a self-play mode.
[p26]
by John Pelan
Build your own Mono/Stereo sound sampler for less than £20!
Against my better judgement (Brian are you reading this?) I have decided to release my design for a sampler into the public domain. The plans are fairly simple but should only be attempted by those that are competent at constructing projects of this kind, i.e. don't let it be your first!
It consists of nothing more than an audio amp (LM386) connected to an A/D converter (ZN449), two of each if stereo is required. Note that the left and right channel circuits are identical except that the control lines for each are connected to SEL (pin 13) and POUT (pin 12) respectively. The A/D converters are set to sample at about 900 KHz but the rate at which the data is actually read is determined by the software. The ZN449 requires a negative voltage for the conversion process and this is supplied by the 7414/diode pump arrangement via the point labeled 'A'. Examine the schematic carefully. Lines that are connected are highlighted by a 'dot' at the point of intersection.
When operational, the software will read the parallel port which produces an automatic pulse on pin 1, the STROBE line. This initiates the conversion process. Then either POUT or SEL will be brought low depending on what channel it wants to read. As the conversion takes place faster than than software can read it, there is no need to use the End Of Conversion signal. We are assured that it has always ended, no matter how fast the software reads. Reading the port will produce another STROBE pulse and the proces repeats.
Before use you will have to adjust the 10K preset so that no input results in a reading of 127/128, i.e. short the input line to ground and while reading the display from any good sampling program, adjust the preset. In use you should adjust the 100K pot (gain control) so that the highest anticipated input will give a reading of 255 (or zero if negative). This will give you the best possible resolution and hence better sound reproduction.
I have built the mono version and it operates to my satisfaction. The addition of a second channel should pose no problems as the Amiga is able to supply the additional power required. However, no responsibilty will be held on my part for ANY consequences of the use of this circuit or derivatives thereof. Use entirely at your own risk.
[p27]
Circuit Diagrams and Part lists
[p28]
by Stephen McGerty
It is about twelve months since I got my Amiga 500, so I thought I would write a little piece on my first year in the world of Commodore. (Yes, I was one of those people who actually got a Spectrum instead of a 64 when the home computer craze began.) My main conclusion is that it's far more active and enthusiastic than any other 'discipleships' orientated around other computers. Okay, IBM's may have a greater serious user base, but they aren't exactly king of the games world. The Amiga, on the other hand, is an excellent games machine, has a huge and varied collection of public domain software, and also has quite a lot to offer the serious user. After all, multi-tasking isn't exactly a common feature of microcomputers.
That brings me to my next point about the Amiga: If its complexity is its strength, then it is also its Achille's heel. I simply couldn't believe some of the things the Amiga was doing when I first got it. The graphics were stunning and the music (yup, it's progressed from just being called sound!) was even better. But when I started to try and program the damn thing, beasts by the names of 'ROM Kernel Manual' and 'C' and a particularly nasty one called 'compiling' reared their ugly mugs. Suddenly, I was wishing that I was back in the simple old days, with BASIC, or simple Machine Code (Z80 of course, remember the Speccy.. .sigh. But it was at this point that CUGI came to my rescue. Numerous people offered support and advice, on what to get and what to avoid. I felt that I wasn't wandering aimlessly through the jungle, but that I could ask for directions every now and then.
As I didn't get the Amiga just to play games on, or gape like a goldfish at the demos, I began the long and arduous process of learning how to program it. A few points which should be noted about getting going:
1. BASIC is not exactly well suited to the Amiga.
2. C is.
3. Learn C.
4. Expand your memory, and get a compiler.
5. Learn how to use C to control the Amiga.
6. Keep practicing.
The computer world is changing fast, and however you look at it, BASIC just will not get good results on the Amiga. So you are going to have to learn a new language called C. This requires the purchase of a general book
[p29]
on C. Try looking in Easons or Fred Hannas. I would highly recommend The Art of C programming but it weighs in at £20. There are numerous other books which are almost as good, and a good bit cheaper. Try C at a Glance which is just over a tenner. Next, once you think you can handle the basics of the language (or once you think you want to handle them), you will have to buy a C Compiler. This is not a pleasant task, as it will do a very unpleasant thing to your bank balance, i.e. lower it a lot. Lattice C looks good and has lots of features in its latest version, but it takes ages to compile anything, so I prefer Aztec C, which is quicker.
The next step is to learn how to use the features of the Amiga. Here the road divides: You can go in at the deep end and buy the Hardware Reference Guide and program the machine at a very low level, possibly from machine code. Alternatively, you can do what I did and buy the Amiga ROM Kernel Reference Manual: (Libs and Devs), and the Intuition Reference Guide. I won't comment on the low level approach, as I haven't tried it myself. Instead, I opted to learn about the operating system. It's no easy path, I can tell you. After a month or so you will have one side of your brain begging the other side not to force it to think about C, structures, computers or that telephone directory sized book, the ROM Kernel manual, when it could be thinking about far more pleasant subjects.
But fear not, the fog, thick and syrupy though it may be, will slowly clear. Once you learn how to open Windows and Screens, make Gadgets and Menus, the sky's the limit (well actually the top of the screen is) and you will have no trouble making almost any type of program you want. And all with the speed of a compiled language. There are limitations, and ways around them, but just cross each bridge as you come to it!
Well that about wraps it up. Feel free to totally ignore my advice, as it is only one person's opinion. Others will be only too happy to give you theirs. Above all: Know what you want and then work at getting it. Choose your own road and cross the river by the bridge.
[p30]
by Shane Broadberry
When Commodore brought us the Amiga, they gave us more than just custom hardware, a mouse and a disk drive - they gave us some incredibly versatile and powerful software which when interfaced correctly can greatly reduce the work-load of any programmer considerably.
At the base level of the Amiga's software hierarchy lies Exec, which takes care of all the memory management, task creation/execution, and message handling to name but a few of its many responsibilities. We are going to have a look at some of the applications and the implementation of message passing on the Amiga, why we would want it, and the benefits it bestows upon us.
Behind every action a user makes on a computer, there are a large number of small and hidden actions performed within. Many of these repeat often, some occur only after a particular event, but all of them have to be taken care of in the current 'environment'. Most of the laborious tasks are taken away from the programmer unless for some reason they tasks are of particular interest to him. For example, most programs do not need a separate keyboard scan routine and thus they allow the standard routines to operate, accepting the information as passed on from the routine. On the CBM 64, these operations are performed under interrupt every ¹/₅₀ᵗʰ of a second, the results placed in a location in memory, and as we process the input, more data is supplied. Similarly on nearly all computers.
When any two or more tasks are operating at the same time, they must co-operate (to a certain extent). Often this co-operation remains minimal, but when routines start sharing blocks of memory or devices, or require shared data of one form or another, co-operation is vital to avoid contention between the tasks. In order to achieve this co-operation, signals and messages are sent between the various processes.
In the Amiga, messages are sent all the time. Anyone with experience of using Intuition for example will have come across the reading of messages sent via Intuition's Direct Communication Message Port (IDCMP). Intuition passes to the program any user selected options from menus, gadgets ete, which originate from the program's window. How does it know which lask to send the data to? Well when the menus or gadgets are initialised, Intuition creates (or uses an existing) mailing address called a MsgPort.
[p31]
This is a private address to which data relating to menu selections will be sent. In effect, it's a MsgPort data structure in memory.
In this data structure, among other things, is a pointer to a list of messages currently waiting to be read. We simply read these messages, process the information sent, and continue it's as simple as processing keyboard input on a C64. Intuition associates our particular message port with a particular window, and then posts messages to our port. It worries about which menus to display, colours and so on, using the data we supplied, freeing the programmer from having to consider such things.
Okay, let's get down to the brass tacks. How do we send messages between our tasks? We have very few limitations with message passing but we must follow the rules. We cannot send a message with more than 64k of data, we must usually reply to any messages received (the sooner the better indicating that we are finished with the data, and that's about it. We decide at the outset what data we want to send between our tasks, whether we want to have a two-way conversation, or a single "write only messaging system. There are also a few other options which are available to us, regarding the way the messages are to be waited for using signals, but more about these later.
The common data that we wish 'sent' between tasks must be defined in a structure. This structure must have as its first member a message structure, so our data structure must look something like this:
struct OurMessage {
struct Message Msg;
‹our data fields>
};
The parent task must now create a named port (using the CreatePort() function or a similar function) to which the data can be sent. Then the newly run or spawned task searches for this port by name, using the FindPort() function. When this function is called it should return a pointer to a message port to which we can post messages (if it fails, we've either searched for the wrong name, or there wäs some problem setting up the port). Once the address of the port is known we can post and receive messages to it.
There are a number of ways in which a task can check to see if a message has arrived at its port. If our task is only going to act on the arrival of a message from a sister task then it is probably best to call the CreatePort()
[p32]
function when creating this tasks port. CreatePort) allocates one of 16 possible spare signals that can be used to signal tasks. Waiting for the atrival of a signal is by far the most efficient method of checking the port for a message and allows a very fast method of determining information about the message, without actually reading it (if this is of use). If on the other band the task has other things to do, such as update a screen display; and only needs to check for messages at comparatively large intervals the overhead for doing so is quite small; in this case allocating a signal for the port would probably be unnecessary.
As mentioned earlier, CreatePort() allocates a signal for the port (the first available signal) using the AllocSignal() function. This function can either allocate the next available signal or attempt to grab a particular signal bit; it is best to take the next available signal. The value returned from AllocSignal() corresponds to a particular bit within a 32 bit longword. 16 of these bits are reserved for internal use, but we can use any of the remaining signals for our own use.
Messages are posted using the PutMsg() function. This function queues the message to the port by passing the task a pointer to the message being sent and signals the task of its arrival. It is important to realise that our message structure is not copied. We simply receive a pointer to the contents of another task's data structure. This is done for efficiency reasons, since copying large chunks of data around unnecessarily can waste a lot of time. If another message has been posted previously and has not been replied to, the new message will be queued.
In order to read the next queued message, a call to the GetMsg() function is used. This will return a pointer to the next message at our port (or NULL if there is no message waiting). In order to check to see if a message has arrived, we might try something like this:
while ((data = (OURMSG *)GetMsg(ourport)) == NULL)
; /* skip - do nothing */
‹process the message>
However, this is bad, because it uses busywaiting. The Amiga is tied up going around the loop many thousands of tines until a message arrives,
[p33]
using processor time that could be better spent running other tasks on the system. The correct way to do this is to ask the system to wait until a message arrives on our behalf. This will put our task to sleep, and avoid hogging the system. The easiest function to call is WaitPort() (providing we have allocated a signal for our port, using Create Port()) which will wait until a message arrives, and then return a pointer to it. Wait Port/) doesn't actually remove the message from the queue, so we must still call GetMsg().
So, what can you use these techniques for? A good example of how they can be put to good use is in TEX, the typesetting package used to layout this newsletter. On the Amiga, TEX comes with a previewer which can display pages before they are sent to the printer. The main TEX program communicates with the previewer using messages as described above. When TEX has finished processing one page, it sends a message to the previewer which can then read in that page immediately and display it, while TEX is working on the next page. This makes for a very interactive and user-friendly environment.
Another good application is in any of those little programs like DMouse, Backdrop, Snipit and so on, which you run in the background to provide some much-needed facility. The first time you run them, they open up a public message port, and put themselves into the background to do whatever it is they do. If they are then run a second time, they spot the message port already exists and realise that there is another copy of themselves somewhere. They can then send messages to this copy (via the message port), telling it to update certain parameters, activate a particular feature, or just quit. This is a very nice feature to make available!
There are many other uses as well - as with most things on the Amiga, the only limit is your imagination!
In order to provide an example program to serve as an introduction into the
powers of inter-process communication, here is a short example C program.
Compile it with your favourite C compiler (use the 32-bit option if you are
using Aztec C).
To try it out, open up two CLI's. Now run the program in one of the CLI's. It will look around for a message port with the name "test-port" not find it, and then open up the port itself. It will then go into a loop, reading messages from the port and printing them, until a 'quit' message is received, whereupon it will cleanup and exit.
[p34]
Alter you have run the program once as above, so into the other CLI and run it again. This time, the program will spot that the message port already exists, and will send what you typed in quotes on the commant lime to the port, where it will be received by the first copy of the program and printed out. Send the message 'quit' to make the first program exit.
/*
* Example program to demonstrate message passing
*/
#include <exec/types.h>
#include <exec/ports.h›
#include <exec/memory.h›
#include <libraries/dos.h›
#ifdef AZTEC
#include <functions.h›
#endif
struct OurMessage {
struct Message Msg;
char text[256];
};
typedef struct OurMessage OURMSG;
typedef struct MsgPort MSGPORT;
char *portname = "test_port";
void main(argc, argv)
int argc;
char *argv[];
{
MSGPORT *ourport;
OURMSG *data;
ourport = (MSGPORT *)FindPort(portname);
if (ourport == NULL) {
/*
* Couldn't find port, therefore must be first run
*/
int, done = 0:
[p35]
ourport = (MSGPORT *)CreatePort(portname, 0);
printf("Waiting for a message.\n") ;
while (!done){
WaitPort (ourport) ;
data = (OURMSG *)GetMsg (ourport);
printf ("Message received: %s\n", data-›text);
if (!strcmp (data-›text, "quit"))
done = 1;
}
RemPort (ourport);
} else {
/*
* Port already exists, so send msg on command line
*/
if (argc != 2) {
printf ("Usage: testmsg <msg>, 'quit' to end\n");
exit(5);
}
data = (OURMSG *) AllocMem (sizeof (OURMSG) , MEMF_PUBLIC) ;
if (data == NULL) {
printf ("Couldn't allocate memory for message\n") ;
exit (5) :
}
/*
* Allocated memory okay, now copy command line
* into message, and send message
*/
strcpy(data-›text, argy(1]);
PutMsg (ourport, data) ;
/*
* Should wait for a reply here, before we free
* the memory. Left as an exercise for the reader
*/
FreeMem (data, sizeof (OURMSG)) ;
}
}
[p36]
by Rocco Matassa
._______________. |#12 3 4 5 6 #| |7# # ## ## # #8| |9 # #A | | # # #B # # # | |C D# #E | | # #F # # | | ##G# # # #H## | |I #J | | ## # #K# # # | | #L#M N#O# | |P # #Q | | # # #R # # # | |S # #T | | # # ## ## # # | |#U #| .---------------.
Welcome to the September CGI crossword. Since nobody submitted a
coffect solution to the June crossword, nobody got the mystery prize. As a
result, it is being held over for this crossword. First correct result handed
to a committee member by 1 December gets the prize.
[p33 - inside back cover]
Across Clues
1. Flow back to what takes place in a theatre. Could
be entertaining on a computer. (9,4)
9. Unties would be going in the opposite direction. (6)
A. Give them this and they could take a lime? (2,4)
B. H this ain't no miss. (3)
C. Food for example can lead to a mistake. (6)
E. Formally to this place, O there. (4,2)
F. Rule far, as S able, the genuine article. (4,3)
I. Could e' rot the nun in A tom. (7)
J. Do a Read, leading to an uneven size. (3,4)
M. Lo! super, wasting away. (7)
P. That old man river? (6)
Q. You'd be in no coma if you were watching this G. Prix. (6)
R. Sh, this is the word. (3)
S. Chop the Free State to find the right time. (6)
T. Farmable? (6)
U. Natural film, an inclination to wander. (4,2,3,4)
Down Clues
2. Nightshade is an example. (6)
3. Sailor's jacket. (6)
4. In the point at which air flow breaks away from the wings,
or a way of killing Amiga germs. (7)
5. About this twin, could it be the season? (6)
6. Yearned. (6)
7. He who controls a character's destiny, mast gone under. (7,6)
8. A unique? (3,3,3,4)
D. Elect in a British river, a loyal fan. (7)
E. A monotonous task, you could hum to this cask. (7)
G. L' this could miss an important date. (3)
H. See 13 down for a cooler. (3)
K. Ought the docter be the cause of no rain? (7)
L. A knock out in computer information has wings. (6)
M. Maybe all the, will see you dead. (6)
N. So small are and tier sounds like it leads to tears. (6)
O. One hears a bet could have you dancing. (6)