πŸ’Ύ Archived View for cugi.ie β€Ί newsletter β€Ί 1989sep.gmi captured on 2022-04-28 at 17:24:17. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-03-01)

➑️ Next capture (2022-06-03)

🚧 View Differences

-=-=-=-=-=-=-

    β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ    β–ˆ β–ˆ β–ˆ    β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ
   β–ˆ          β–ˆ    β–ˆ β–ˆ β–ˆ   β–ˆ               β–ˆ
  β–ˆ  β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ β–ˆ    β–ˆ β–ˆ β–ˆ  β–ˆ  β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ β–ˆ
 β–ˆ  β–ˆ       β–ˆ β–ˆ    β–ˆ β–ˆ β–ˆ β–ˆ  β–ˆ            β–ˆ β–ˆ
 β–ˆ β–ˆ  β–ˆβ–ˆβ–ˆβ–ˆβ–ˆ β–ˆ β–ˆ    β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ  β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ β–ˆ β–ˆ
 β–ˆ β–ˆ β–ˆ    β–ˆ β–ˆ β–ˆ    β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ         β–ˆ β–ˆ β–ˆ
 β–ˆ β–ˆ β–ˆ    β–ˆ β–ˆ β–ˆ    β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ         β–ˆ β–ˆ β–ˆ
 β–ˆ β–ˆ β–ˆ    β–ˆ β–ˆ  β–ˆ  β–ˆ  β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ   β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ
 β–ˆ β–ˆ  β–ˆβ–ˆβ–ˆ β–ˆ  β–ˆ  β–ˆβ–ˆ  β–ˆ  β–ˆ β–ˆ β–ˆ  β–ˆβ–ˆβ–ˆβ–ˆ β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ
 β–ˆ  β–ˆ      β–ˆ  β–ˆ    β–ˆ  β–ˆ  β–ˆ  β–ˆ      β–ˆ β–ˆ β–ˆ β–ˆ β–ˆ
  β–ˆ  β–ˆβ–ˆβ–ˆβ–ˆ   β–ˆ  β–ˆβ–ˆβ–ˆβ–ˆ  β–ˆ    β–ˆ  β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ β–ˆ β–ˆ β–ˆ β–ˆ
   β–ˆ         β–ˆ      β–ˆ      β–ˆ         β–ˆ β–ˆ β–ˆ β–ˆ
    β–ˆβ–ˆβ–ˆβ–ˆβ–ˆ     β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ        β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ β–ˆ β–ˆ β–ˆ

CUGI Newsletter / September 1989

In this issue..

Procomm on the PC

Build an Amiga Sampler

Mathematical Computer Games

Amiga Messages & Ports

C128 Fast Word Searches

HONORARY CUGI OFFICIALS

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.

Newsletter Contents

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

Editorial

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!

The Pro's and Con's of Procomm

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

SETTING UP

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.

DIALLING A BBS

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.

UPLOADS & DOWNLOADS

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.

CUSTOMISING YOUR SOFTWARE

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.

MACROS

"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!

Useful key combinations in Procomm

 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

Modem Communications in Brief

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.

Modem

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.

Null Modem

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.

Duplex

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.

Host/Remote Computer

This is the computer that you dial up.

Echo

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.

Speed

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.

Baud Rate

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.

Speed Buffering

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.

Word length, parity and stop bits

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

Characters per second

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.

Answer/Originate

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.

V numbers

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

Protocol

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.

MNP

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.

PSTN

The Public Switched Telephone Network, i.e. the normal phone system as

provided by British Telecom and Telecom Eireann.

Leased Lines

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.

ISDN

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.

Golden Words and Dashing Graphics

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.

1989sep01.png

Sample output from TV Text

Microcomputer Interfacing

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.

3rd Law of Microcomputer Interfacing

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.

Exercise #3

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:

4th Law of Microcomputer Interfacing

Patience will be rewarded with an interface that lives longer than you do.

____________________

Club Diary

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]

Rocco's Ramblings

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 devised 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]

Searching for the Right Words

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 Iransactor (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 sur-

prisingly 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 - s

isr 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

Get another comma and last element to check

jsr comaddr

ldx #4

ldy #0

jsr gofar1

; Jump to $0400 in Bank 1

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 WS has been assigned to some word, and VS is an ar-

ray of words which is made of adjectives VS(1)....V$(100) and other words

VS(101)... VS(250), then the command:

SYS location:W$, V$(101), 250, P

will search for WS 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

ldx #1

Read in the variable

;

loop lda vardata, x

sta temp, x

lda facint, x

sta index2,x

dex

bpl loop

rts

; Transfer the pointer to the array

; To somewhere else (??)

; And save the first element no.

: For later use

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 lx #β€Ί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

index

index2

temp

searchi

= $16

= $24

$26

= $28

This holds

the max element no. to be searched

Points to the array word being looked at

; Holds the no. of the current element, no.

; Temporary storage

srch2

lda int+1

emp index2+1

bcc notfound

bne srch2

lda int

cmp index2

bcc notfound

ldy #0

Ida (temp) , y

cmp len

bcc srchnext

Check if current element number

exceeds the max allowed

; If it does, it's a case of NOTFOUND

; Pick up length of current array word

If it's smaller

than our word

; then try the next array word

; Otherwise, get the pointer to

the array word and store

: it in INDEX

iny

lda (temp), y

sta index

iny

lda (temp) , y

sta index+1

[p22]

ldy len

dey

; Get length of search word, and

; adjust to start check with last char

lda (pointr),y ; Compare the array word's char with

cmp (index),y

the SEARCH WORD's char

be srchnext

; No match - try the next one

dey

Go backwards to the first char

bpl srch3

rts

; Matched exactly

- result in INDEX2

; Failed, set up result of

=1

notfound lda #255

sta index2

sta index2+1

rts

srchnext cle

lda temp

adc #3

;

To check next array word, move 3

;

along the array header

; (skipping the length and

sta temp

two-byte pointer)

bcc srch4

inc temp+1

srch4

inc index2

bne search1

inc index2+1

bne searchi

Also, we, must increment the element

number so that if we get a match

; it'll be ready

; 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]

Mathematical Computer Games

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 cre-

ation? Not necessarily. Mathematical formulae can do the job as well. Take

the simple equation

2

2? +c

This equation describes something called the Mandelbrot Set after its dis-

coverer, 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 dif-

ferent 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 gen-

erate images that nobody has ever seen before. Shortly after its discovery,

an American computer graphics company started selling posters with Man-

delbrot 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]

DIY Amiga Sound Sampler

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 de.

cided 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 process

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

1989sep02.png

[p28]

A Year On

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

(280 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]

Amiga Messages and Ports

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 num-

ber 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 β…•0

th 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 con-

tention 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). Intur

ition 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 mes-

sages 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 Find-

Port() 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 displas;

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.

Signals

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.

Posting and Receiving Messages

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 "f

sing around the loop many thousands of fines 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, IgX 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!

A Short Sample Program

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 CU

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] ;

f:

typedef struct OurMessage OURMSG;

typedef struct MsgPort

MSGPORT:

char *portname

=

"test_port";

void main(argc, argv)

int arge;

char *argv(];

{

MSGPORT *ourport;

OURMSG

ourport = (MSGPORT *) FindPort (portname)

if (ourport == NULL) {

/*

Couldn't find port, therefore must be first Fu

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 (!stremp (data-β€Ίtext, "quit"))

done = 1:

}

RePort (ourport);

} else {

/*

Port already exists, so send msg on command line

if (argc ! = 2) {

printf ("Usage: testmsg <msg>,

exit(5):

'quit' to end\n");

}

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

strepy(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]

CUGI Crossword #4

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)