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

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

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

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:

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:

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:

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:

1) The system is entirely user transparent - the modems will establish

connection at the highest level they have in common.

2) You are guaranteed error-free data

3) With data compression you can achieve effectively higher data speeds,

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.

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

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:

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

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

[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:

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:

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:

and then the routine:

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

will do the trick nicely but DO put it at the start of your BASIC program!

And now for the routine:

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 creation? Not necessarily. Mathematical formulae can do the job as well. Take the simple equation

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]

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

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

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

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.

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:

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!

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

[p36]

CUGI Crossword #4

by Rocco Matassa

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)