[cover]

     ███████████    █ █ █    ████████████████
    █          █    █ █ █   █               █
   █  ████████ █    █ █ █  █  █████████████ █
  █  █       █ █    █ █ █ █  █            █ █
 █  █  █████ █ █    █ █ █ █ █  ██████████ █ █
 █  █ █    █ █ █    █ █ █ █ █ █         █ █ █
 █  █ █    █ █ █    █ █ █ █ █ █         █ █ █
 █  █ █    █ █  █  █  █ █ █ █ █   █ █ █ █ █ █
 █  █  ███ █  █  ██  █  █ █ █  ████ █ █ █ █ █
  █  █      █  █    █  █  █  █      █ █ █ █ █
   █  ████   █  ████  █    █  ███████ █ █ █ █
    █         █      █      █         █ █ █ █
     █████     ██████        ██████████ █ █ █

CUGI Newsletter March 1990

In this issue …

Installing 1 Meg Agnus

Amiga Peripherals

Introduction to DOS Continued

Amiga Printer Settings

Commodore Poetry

HONORARY CUGI OFFICIALS

Chairman             Geoffrey J. Reeves
Treasurer            Brian Ward
Membership Secretary Shane Broadberry
Chief Librarian      Tom Kinsella
Amiga Librarian      Rocco Matassa
PC Librarian         Brian Ward
C64 Librarian        Steve Kemp
C128 Librarian       Geoffrey J. Reeves
Communications       Liam Murphy
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 correspondence should be addressed to:

CUGI

c/o St. Andrew's College,

Booterstown,

Blackrock,

Co. Dublin.

All articles in this newsletter are copyrighted by the author unless otherwise stated. If you wish to reprint an article, write to its author c/o CUGI at the above address.

Newsletter Contents

Volume 2 Number 2

March 1990

Editorial                            Geoffrey J. Reeves  2
DOS & That                           Brian Ward          3
The Key to Success                   Stephen McGerty     8
Hires Agnus 8372A                    Declan McArdle     13
Ode to Ed                            Colm O'Rourke      18
Music Video                          Liam Murphy        20
Amiga Assembly Language Programming  Shane Broadberry   23
A Window on the C128                 William Leeson     28
Printer Settings                     Leon Hurst         30
Demonstrating Structures             William Leeson     32
Perplexing Peripheral Purchases      Geoffrey J. Reeves 34

Editorial

"Geoff, how would you like to be editor for an issue?" he asked. What ever made me say yes? I really must have been mad! Actually, it's not that bad but I surely appreciate the work that Eddy's put into the previous newsletters (or magazines as someone sussested!). So why the change?

Firstly, it's only temporary (come back Ed - all is forgiven) and seconly, Eddy is studying/working on projects. It doesn't seem all that long ago since he started at college and now he's finishing up ... good luck with the exams and I hope you enjoy having to pay tax like the rest of us now that you'll have to do real work ;-)

Amiga TEX continues to do its job well despite the company who supplied it - we should have had an updated version last Christmas. Miraculously, it arrived today (Friday 13th). Unfortunately, this doesn't give me enough time to try out the new features - it can now include graphics! It should therefore be possible to include pictures and diagrams within the text. I did notice one restriction (so far), namely that it cannot cope with pictures in landscape mode (sideways to non-TEXnicians).

Back to this issue then. It's not as big as the last but that can be put down to the time of year I hope! Having just acquired an A590 and new Amiga (i.e. Kikstart 1.3 etc.) in the last week or so was excellent timing, all things considered. Trying to work on this newsletter from floppies and/or only 1 Meg of RAM would have been interesting, to say the least. It's funny, you know, that one year ago anyone having an Amiga with 1 Meg and two drives would have been considered as having an ideal system. These days, many of our members seem to have a hard drive and are looking towards 2 Meg of RAM. That A590 really is excellent.

There seems to be the usual wide range of topics covered but sadly, little for the C64 - come on, surely someone out there still uses the machine? We certainly have a first in this issue - a poem! It just goes to show that you can write for the newsletter in any form you like. It's very good and may even start a trend; what chance some budding author writing a short story for us? Apart from that, Liam's article explains much about CD, both video and audio, a technology already part of our evervday life. Declan explains how to get that magic 1 Meg of Chip RAM for all you graphics/audio freaks.

But I won't spoil it all for you - start reading and enjoy! By the way, the next newsletter should be ready in about two months so get writing.

Well, there you have it - have a happy Easter! Cheers.

G.J.R.

DOS & That Again

by Brian Ward

This issue I am going to start giving you the DOS commands themselves with a little explanation of what they do and how you should enter the commands themselves.

ASSIGN

If you have a twin disk drive, and you are constantly having to switch the drives from A: to B: you can tell the machine that whenever a request for a particular drive is received, to divert it to the alternative drive. The format for this command is ASSIGN A=B.. To undo the command you just enter ASSIGN.

BACKUP

This is possibly one of the most important commands for owners of hard drives especially. If you do not backup your data regularly (I hope you're reading this Steve), there is every chance that some day you could have a fatal accident such as a head crash, which will leave you high and dry with no excuses. At the recent meeting it was recommended to backup every day, but in business it is not feasible or practical to do so. However once a fortnight will leave you with only 2 weeks to restore instead of having to start from scratch. You do NOT have to back up everything on your hard disk if you don't want to. You can specify data that has been changed since the last backup be saved.

The command to backup every single file on the hard drive to floppy is BACKUP C:\ A: /S. If you replace the /S with a /M, only the files that have been modified since the last backup will be saved. The BACKUP command can tell which files have been changed sice the last time, because each time it does a backup up DOS fags the files and thus saves time. Another form of the /M command is the /D where you can specify a certain date and only files that have changed since that date will be backed up. One important thing to note however. If, like me, you don't have a battery powered clock which automatically updates time and date, you must enter the date at least every time you switch on, otherwise the /d command is useless. You may also only wish to backup files in a subdirectory then the command is BACKUP\ subdirectory A: /S or /D etc.

BATCH

This is the most useful utility that MS-DOS has. It can make life a lot easier for start-up sequences, going to subdirectories at a stroke, or even running programs from the root directory. À batch file is a fle containing one or more commands that DOS executes one at a time. You can create a Batch file by using the line editor (EDLIN), or by the COPY comman. We will talk about EDLIN later in this article, but for now we will use the COPY command. To create a batch file to run the program Symphony, which is kept in the subdirectory Symphony, you do the following.

copy con: s.bat This tells DOS the name of the batch file
echo off        This turns the screen off but is optional
cd\symphony     Changes the current directory to Symphony
access          This is the command to start the program
ALT F6          This tells DOS you are finished

When you have finished a message of "1 File Copied" will appear which tells you that everything is all right. All you have to do then to run your program is type "s" from the root directory and DOS does the rest. N.B. Always make sure you put the .bat at the end of the name of the program when you are originally setting up the file, otherwise DOS doesn't know the file is a batch file. Once you've tried it a few times, you'll wonder how you ever lived without it. If you list all the .BAT files on your hard disk, or the files on your DOS start up disk you will notice a file called AUTOEXEC.BAT.

Do NOT mess about with this file unless you

(a) know what you are doing and

(b) already have a copy of the file somewhere else.

The AUTOEXEC.BAT file is a special batch file that the command processor searches for when you start up. It took me several attempts and a few heart attacks to alter this file to suit my startup sequence, but now I have it exactly as I want it. To edit your startup sequence, you can use EDLIN, which we will come to when we reach the letter "E"

BREAK

Sometimes you will notice that when you hit CTRL-BREAK of CTRL-C that it does nothing, which is quite infuriating. This is because it bas been disabled using the BREAK command. The syntax to turn it on again is BREAK on.

CHDIR or CD

This is one of the first commands that you should learn in MS-DOS, because if you have a machine that has been set up before you use it, chances are that the person who set it up has put everting into subdirectories.

What is a subdirectory? Well if you think of a hard disk as an album, the subdirectory will be the various songs on the album. They are still on the album, but are in a little area of their own. The same principle applies to subdirectories. They are where entire programs are usually held on their own. For instance, on my own PC I have a subdirectory for Symphony, a subdirectory for my communications programs etc. However, if you don't have a batch file to bring you into the program directly, you will have to change the current directory in to the subdirectory and this is done with the CHDIR or CD command. The syntax is CD \symphony etc. It is also possible to have subdirectories within subdirectories, and so the syntax will be CD \Symphony\games if you want to hide your games programs from your boss (or teachers).

CHKDSK

As you may already have guessed, this checks the directory and the FAT (file allocation table) and reports the current status and if any errors are found. It also gives you the free memory left on your disk.

CLS

This is the Clear Screen command.

COMP

This compares the contents of one set of files with another. You would normally use it after the COPY command to check that the files on the two disks match. There is also a shorter way to compare two disks with the DISKCOMP command.

COPY

This command copies one or more files to another disk or even to the same disk, but you must either rename them or put them in subdirectories. You can also use this command to print a document file to the printer. The format would be COPY README.DOC PRN:. If you add the parameter /V it will cause DOS to Verify that the data has been properly transfered.

CTTY

This command changes the standard input/output device, to an auxiliary console, or restores the keyboard and screen and the standard input/output device. The command was designed so that a terminal or a teleprinter could be used in place of a keyboard and a monitor, for input aud output. Personally, I've never used it so I don't really know what the advantages are. Comments welcome.

DATE

Some people are lucky. They have battery powered clocks in their PCs. Some people really need this facility, and some people don't. I fit into the latter category. I hate having to put in the date, so much that I have totally removed this from my AUTOEXEC file, so I'm not bothered each time I reset the computer with an "Enter Date" message. However, if you feel that life isn't worth living without the date/time stamp on all your files, feel free to do as you wish. The DATE command is for when you have forgotten or, like me, deliberately left out the date stamp for your files.

DEL

This is as you might suspect the DELete command. This is also a very recent sore point with me. I will explain. If you want to delte a file, you just enter DEL filename.ext. You can also add in a wildcard e.g DEL *.DOC. This will delete all the files with the extension .DOC. You can also say DEL *.* which will delete everything in the current directory. Now back to my story. I was moving files from one of my subdirectories on my hard disk to a floppy disk. Before I started I did a directory of A: from within the subdirectory. It of course gave me a listing of all the files in drive A. I decided that I didn't need what was on the floppy so I did a DEL *.*. The computer asks you then "Are you sure ?", and I thought to myself "Very clever that. Gives you a chance to make sure you know what you are doing". I naturally knew what I was doing and entered Yes. Now has anyone spotted my mistake yet? I suppose everyone has, except I hadn't. I had forgotten to change the current directory from the subdirectory to the floppy drive A: and of course I deleted all the files in my subdirectory instead of the floppy drive. The moral of the tale is, "He who get too cocky when deleting files, will delete files he not supposed to."

DIR

As I mentioned above, the DIR command gives you a directory. If you just enter DIR, you will get a listing which scrolls off the screen if you have more than 24 files in the current directory. However if you put a /P, the computer will pause when the screen is full, and when you hit the spacebar, it will give another screenful and pause again and so on until the listing is finished. If you want to list the files across the screen DIR/W will give you this. If you would like a combination of the two, DIR/P/W will do that for you. If you would like a printout of your directory DIR>PRN: will do just that. DIR>filename will place the current directory into a file.

DISKCOMP

This compares two disks as I've already explained in the COMP command. Useful after you've just copied two disks to check they are the same.

DISKCOPY

This is probably the second command you will learn and as it says, it copies two disks. The format is usually DISKCOPY A: A: if you have only one drive, DISKCOPY A: B: if you have two etc. If you wish you can copy only the first side by adding /1, but for the life of me I cannot see why you would wish to do so. If you have omitted to format the destination disk, DOS will format as it writes.

Well that's all I have time for this week. If there's anything that I've left out it's either because I've forgotten it, or that I know nothing about it. So until next time.

The Key to Success

by Stephen McGerty

Once you have the knack of openity the odd window or screen. you are over one of the first hurdles of programming the Amiga. You can use some simple graphics routines to do silly tasks like bouncing a point around the seren, but very soon you will be asking yourself how do you get your program to communicate with the outside world. One simple way of getting input from

the user is the C function scanf(). but this is of little use when you have a custom screen and window opened. If you just want a simple input (such as cursor up or cursor down) the keyboard sensing ability of the IDCMP can be useful. The what? I hear you cry. No, the IDCMP isn't a type of missile found on F-15s, it's the Amiga's way of giving a program a specific piece of information. The IDCMP can be thought of as a slave of your program. You just tell it what events you want your program to hear about, and it will monitor those events until something happens to one of them. An event can be one of many things: a keypress, a click on the Close Window box, or

one of numerous other things. For full details of all the events which you can ask the IDCMP to monitor for you, see the Amigo Intuition Reference

Manual.

Once your program has primed the IDCMP to a certain set of events, al your program has to do is check (once in a while) if the IDCMP has any news for it. If it doesn't, then just keep doing something else, and check again later. If it does, then you must extract all the information you need about that event and reply to the IDCMP that you are finished with that message. It is very important to reply, because otherwise the IDCMP Wil be unable to sigual any other events to you. If two or more events happen. the IDCMP will stack up messages about them, and send them to you program in the order that they happened.

If your program reaches a stage where it can't do anything without some usPonse from the user, then you can put four program to sleep, wail the

alytanswers it, This suspends your program (waiek is 't doins aurilief soutay, and froes the processor for other tasks." But Once the event whip Mill Marge ram is waiting for (sas, the press ad 3 kerf occurs, the IDOl Will wake soul program and send it as message a tit a fuse happened

That's the theory anyway, and in practice it isn't much more difficult.

1. You tell the IDCMP what eveuts to monitor by specifying them in the IDCMP flags section of the New Window structure.

2. If you just want to check the IDCMIP occasionally while your program is running something else, do a GetMsg() call every so often. This is quite similar to INKEYS or GETS in BASIC.

3. If your program would rather sleep while waiting for input from the IDCMP, then use Wait() with appropriate parameters.

Here is a (fairly) simple example program which uses the IDCMP to tell the program when keys are pressed, or when the CloseWindow icon is clicked. Just press Q to increase the blue intensity of the screen, and A to decrease it. It also displays the current intensity.

Try altering it so that you can vary the red and the green intensities as

well!

/**冰*米冰***水**水*水水**水*水水次水水水水**水次许本水*水水冰次次水次本冰冰
Colour Pal,
by Stephen McGerty 2/2/90
Use Q and A keys to change screen colour
Compiled with Aztec C
(32 bit its, with precompiled include files)

struct IntuitionBase *IntuitionBase;
struct GfxBase *GfxBase;
struct NewWindow MyNewWindow
{
140, 15, 200, 40, 0, 1,
/* Window info */
CLOSEWINDOW | VANILLAKEY,
/* IDCMP flags */
WINDOWCLOSE| ACTIVATE WINDOWDRAG, /* Window flags */
NULL, NULL,
"COLOUR PALETTE",
/* Window title */
0, 0, 0, 0, 0, 0,
WBENCHSCREEN
/* Put Window on WorkBench screen */
}:


struct Window *MyWindow;
struct RastPort *MyRP;
/* Intuition vars */
main ()
{
struct IntuiMessage *MyMesg; /* Message vars */
ULONG MClass;
SHORT MCode;
int quitprog = FALSE;
/* Used to end program */
int BlueIntensity
=6:
char numstring[2];
/* current colour */
/* A string, to hold a no. */
/*********** Open Libraries and our window **********/
IntuitionBase = (struct IntuitionBase

OpenLibrary("intuition.library",0);
if (IntuitionBase == NULL)
ShutDown (0) ;
GfxBase = (struct GfxBase *)
OpenLibrary("graphics.library",0);
if (GfxBase == NULL)
ShutDown (1) ;
Mywindow = (struct Window *)OpenWindow(&MyNewWindon) i
if (MyWindow == NULL)
ShutDown (2) ;
MyRP = MyWindow-›RPort;




/*********** Othe工 Setups **********************/
SetDrMd (MyRP , JAM2) ;
Move (MyRP, 10, 20) ;
Text (MyRP,
"Press O or A !", 14):
Move (MyRP, 10, 30) ;
Text (MyRP, "Current intensity:", 18) ;
/*********** Main Loop ************水*水****米*****/
while (TRUE)
{
/* Print current intensity number */
Move (MyRP, 160, 30);
if (BlueIntensity > 9)
numstring[0]
=
31':
else
numstring[0] = '01:
numstring{1] = (BlueIntensity % 10) + 48;
Text (MyRP, numstring, 2);
/* Change Screen colour

SetRGB4(ViewPort address, Pen number, Red, Green, Bl

SetRGB4 (ViewPortAddress (MyWindow), 0, 0, 0, BlueIntensity)
/****** Check IDCMP for CLOSEWINDOW & KEYS ********/
Wait (1<<MyWindow-›UserPort-›mp_SigBit);
/* Sleep */
while ((MyMesg = (struct IntuiMessage *)
GetMsg (MyWindow-›UserPort)) != 0)
{
MClass = MyMesg-›Class; /* What type of event
(key or closewindow)
Mode = MyMesg-›Code;
ReplyMsg (MyMesg) ;
/* which key was pressed ?

/* Finished with msg; reply */




if (MClass == CLOSEWINDOW) {
quitprog = TRUE;
break;
/* This will later cause
/* the program to end

}
/*
In the switch we could have more cases doing
more things. The letters are case sensitive.
(Lower case in this example)

switch(MCode) {
case
"g':
BlueIntensity = (BlueIntensity + 1) % 16;
break;
case
la":
BlueIntensity = (BlueIntensity
- 1) & 15:
break;
default:
/* If it ain't q or a, do nothing

}
}
if (quitprog == TRUE)
ShutDown (3) ;
}
}
ShutDown(n)
int D;
{
if (n>2)
CloseWindow(MyWindow);
if (n>1)
CloseLibrary(GfxBase);
if (n>0)
CloseLibrary (IntuitionBase) ;
exit (TRUE) ;
}

Hires Agnus 8372A

by Declan McArdle

First there was OS/2, half an operating system. Now there's ECS/2, half an Euhanced Chip Set. Yes, part 1 of the Eubanced Chip Set is here now

with us. It's called the Fatter Agnus, Obese Agnus, Super Agnus, some people even call it the American Tourist! Commodore calls it the Fires Agnus 8372A.

The Enhanced Chip Set was designed to be introduced with version 1.4 of the operating system and the A3000. This article deals with the first half of the ECS viz. Agnus. As most of you know the Agnus chip is the very heart of Amiga graphics containing the copper and the blitter. The area of memory which it can access is called 'CHIP' memory. In the Amiga's memory map 2 Megabytes are reserved from $000000 to $1FFFFF for CHIP memory. When the Amiga 1000 came out in 1985 it had an oblong Agnus chip (8361) and it could only access the lower 512K of memory. In 1987 when the A2000 1 and A500 came out they had a different Agnus chip (8371) and it was square. This was the Fat Agnus. This chip could still only access the lower 512K of memory but it had extra pins which would come into use later.

Last year Commodore started shipping Amigas with the Obese Agnus in them. To find out whether your Amiga has got an Obese Agnus, compile

and run the listing at the end of this article. As a rough guideline: if your Amiga was made in West Germany within the last year or it was made in

Hong Kong within the last year and has a serial number of approximately 75,000 or greater then it probably has the Obese Agnus in it (though I could be wrong). There are three differences between the Fat Agnus and the Obese Agnus:

1. Obese Agnus can address 1MB of memory, i.e. you can now have two interlace, overscan 16 colour screens open in DPaintIII, play sound samples twice as long, etc.

2. Can now do a 32k x 32K blit. This was previously limited to 1K x 1K. A blit is a single operation of the blitter. A blit is performed by

initialising the blitter registers with the appropriate values and then starting the blitter by writing to the BLISIZE register.

________________

'The original Amiga 2000 had an oblong Agnus, like the A1000. ECS will only work in the newer model, the B2000. The easiest way to know whether you have an A2000 or a B2000 is to look at the back of it. If it has two phono sockets its an A2000, if it has three phono sockets then its a B2000.

3. Switchable in software between NTSC and PAL display modes. This could be uice if you waut to play Americau games with a full screen, They will also play 20

Installation

What follows is a detailed description of how to install the Obese Agnus in ANY Amiga 500 and also vague instructions of how to install it in a B2000.

I know you lot aren't lawsuit mad but just in case:

I HEREBY CLAIM NO LIABILITY FOR ANY INFORMATON IN THIS ARTICLE LEADING TO YOU FRYING YOUR AMIGA.

There, that should do it.

Amiga 500 Revision 6a Motherboard

The easiest of the lot. You guys already have the Obese Agnus so there's no need to go out and buy one. What you have to do is

1. Reverse the contacts of the three pads at JP2

2. Cut the trace between the middle and lower pad at JPTA

3. Cut the trace at JP4

JP2 is located 'North-West' of the ROM just beside the 68000. It consists of three pads, of which the lower and middle pads are connected to each other. You must cut that trace and solder the top and middle pads to each other.

JPA is located near the top end of the RAM expansion slot. Just cut the trace between the middle and bottom pads.

JPA is located at the left hand side of the Agnus socket. Cut the trace between the two pads.

Amiga 500 Revision 5 Motherboard

Okay, go out to your local dealer and buy the Obese Agnus. Now with Breat care, remove the old Fat 1gnus. I found that two precision scre

drivers, each in opposite corners, works quite well (eventually). Match ", the notch on the Obese Agnus with the notch on the Agous socket. If You

Woot to boot up in PAL mode then make sure that pin f1 of the chip is no. touching the socket (just bend it up so that it doesn't enter the socket)

Push it in. Now go and find JP2 (on a Revision 5 board it's between the 68000 and the ROM). Do the same as for the Revision 6a board. Find JPTA; it may not be marked but if there's a collection of three pads near the RAM expansion connecter then that's it. On the offchance that there isn't a JP7A or even an uumarked collection of pads you can cut the trace from Gary PIN 32 which is the same as cutting JPTA. However, make sure you cut it as far down the trace as you can make out (i.e. near the RAM expansion connector).

Amiga 500 Revision 3 Motherboard

Wow! Where'd you get THIS relic? First 50,000 or so A500s. Okay, this is complicated so pay attention.

Get your chip and put install it as described in the Revision 5 instructions. For the JP2 bit you have to change the connection between Agnus A19 and CPU A23 to Agnus A19 and CPU A19. To do this, your best bet is to cut the connection between Agnus A19 and CPU A23 on the bottom side of the board and then solder a connection from CPU A19 to where the other two used to meet.

Fat Agnus A19 = PIN 59

CPU A19 = PIN 47

CPU A23 = PIN 52

Next cut the trace coming from Gary pin 32. Do this as far down the board as you can make out, again preferably as near to the memory expansion connector as you can make out. This is because there is a resistor which runs under the Gary socket and this has to be kept at Vcc.

Its pretty important that this resistor is at Vccbecause if it isn't you can't reset without doing a SetPatch r. (Note: the 'r' must be in lower

case)

Amiga B2000

The 2000s equivalent of the 500s jumpers are:

JP2

JPTA

JP4

• J101

+ J500

- J102

So, if you follow the directions above everything should work out for you as well.

That's it! If you turn on your Amiga now and do an Avail it should tell you you have 1 Meg of Chip RAM.

Note for Revision 6a A500 owners: For maximum efficiency I would recommend that you use 100ns chips for your extra 512k Chip RAM ie. use one of the new type RAM expansious as opposed to the old 16 chip ones, as the Revision Ga board comes with 100us chips.

Technical

As mentioned before JP2 controls which line on the CPU Agnus A19 goes to. On the Fat Agnus whatever address line (CPU A19 or CPU A23) was

connected here merely fed through to the RASO or RAS1 selection logic from the Agnus acting as a pseudo bauk-select. When JP2 passes CPU A23 the 512K expansion is addressed in the RINGER memory area at SC00000, when JP2 passes CPU A19 the extra 512K is addressed from $080000 to

SOFFFFF. Gary is the one who actually decodes the RAM to the relevent addresses. When JP7A is in its default position Gary decodes the RAM

into two different address ranges (see what I mean about 'pseudo' bank select) viz. $000000-$07FFFF and $C00000-SCTFFFF. Cutting JPTA will make Gary decode the RAM to one address range viz. S000000-SOFFFFF.

Program to test for Agnus

include ‹stdio.h>

include <exec/types.h>

include chardware/custom.h›

struct Custom

void main()

{

WORD agnus_id;

agnus_id = (chips-›vposr & 0x7F00) ;

switch (agnus_id)

{

case Ox0000:

printf ("Normal Fat Agnus Chip (PAL) \n" ); break;

case Ox1000:

printf ("Normal Fat Agnus Chip (NTSC) \n'); break;

case 0x2000:

printf ("Obese Agnus Chip (PAL) \n' ); break;

case 0x3000:

printf ("Obese Agnus Chip (NTSC) \n" ); break;

default:

printf ("Unrecognized Agnus Chip (ID# 0x%04X) \n"

agnus_id);

break;

Permission is hereby granted to reproduce this article verbatim in other publications as long as my name is left at the top of the article and you

send me a copy of the publication. Contact the Editor for my address.

Ode to Ed

by Colm O 'Rourke

Our noble Ed has mastered TEX

And produced a super mag.

Prof Page lies dusty on the shelf,

Dot matrix's such a drag.

It's laser time in AD 90

The crystal beam cuts through

To print great powers and cubic roots

And algebraic functions too.

TEX erased the fabric ribbon,

The finest 24 pin heads are gone.

King laser's set to reign forever.

Even subscripts join the throng.

Ed does not use those slugs of lead,

No green eyeshade will you see.

He's not the small town printer type

And never takes a break for tea.

He works to deadlines all the time

Whether in Basic, C or ArgAsm.

He even smiles with great delight

At all our CUGI sarcasm.

How he survives we do not know,

We admire his great love of subject.

He has helped us all keep ahead of the ball.

Hang on, here's another project.

Big bytes and nibbles

JSRs and all.

Getcomma, Comaddr

Gofar and Fall.

Sys Loc and Search String

Array Max, Assfactor

Ed has these for breakfast

And never falls backwards.

1990 has started, another decade

Of higher speed movement of bytes.

Transputers are with us with great accolade

No limit to processing delights.

I continue to marvel at the silicon chip

And everything it can deliver

Pics can tumble and spin and bend and flip

While causing the bank balance to shiver.

Where is the megabyte race going to end?

Expansion seems to self generate.

If we follow the current memory trend

2, 3, 4, 5, 6, 7, 8, .

Imagine eight megs and begging for more

Collecting by night and by day.

I hope we'll remember those fond days of yore

When the ultimate was 64K.

With eight megs on hand

You're the best in the land

At business and graphics and leisure

Then Commodore smiling, produces it's grand

Sixteen meg keyboard of pleasure.

You rant and you rave

Old Vics turn in their graves

But it's no use crying foul play

So you jump into bed, pull the clothes o'er your head

And remain there until next payday.

Music Video

by Liam Murphy

Watch out for a few really interesting demos within the next few months, one of which might come as a major surprise (remember we demonstrated the Amiga at least six months before it became generally available in the British Isles(sic)?). Computing is not my ouly interest. I am also interested in Hi-Fi. Music Videos. Films (movies). Television and Cooking ... to name

but a few.

Geoff has been hounding me for the last few months to write something for the CUGI magazine (or is it still a newsletter?) and much to my annoyance he has complained that I have not demonstrated any hardware or software for more than a year. I had thought that my demonstration of the teletext decoder for the Amiga would have cured him.

Anyway, as I hate being hassled, I suggested that a demonstration of Korean cooking might be a good idea; much to my surprise, the committee

decided against this, claiming that it is a well known fact that Commodore users do not have enough time to eat, let alone cook. I was told to think again.

To be honest, most CUGI members now know more than I do about the Amiga. It was therefore decided that, as a number of technologies are

now converging at an amazing rate, it might be a good idea to devote some space to one of my other interests ... CDV.

I am taking this opportunity to introduce the Pioneer CDL1450 CDV player and if everything goes according to plan we will demonstrate this

amazing piece of modern technology at a CUGI meeting in May or June. There is some doubt because there is a possibility that Pioneer may withdraw the CDL1450 or remove a very important, unadvertised, feature before it becomes generally available. If we do arrange a demonstration, would anyone be willing to bring along a high quality amplifier plus a pair of

speakers?

I purchased my present CD player about six years ago and it has proved to be great value for money; however, with the introduction of MTV and

a number of music programmes on various television channels, I have developed an interest in Music Videos. Last July, I purchased a high quality stereo VCR and while it may perform very well, it did not achieve the standard that I was seeking (also, I am not all that keen on tape). What was needed was a machine that would replay laser disks as well as compact disks

and the recently introduced DVs but my investigations revealed that there were many complications aud there was only machine that came anywhere near meeting my requirements.

The major problem was that different players had to be produced for different markets. NTSC players were required for American and Japanese

markets while PAL players were required for European markets. Certain types of disks such as Laser Digital Disks (LDD) which were introduced

in the USA in 1984 could not be manufactured in the PAL format for a number of technical reasons.

There is a huge selection of material available in North America (NISC format) but PAL disks are almost impossible to obtain and (this may come

as a surprise) they are of inferior quality ...this is because PAL disks are more difficult to manufacture and as it is a much newer product there are more quality control problems.

Several years ago Pioneer began to market NTSC combie players that could play Laser Vision, LDD and conventional CDs. About two years ago they introduced a PAL combie player and I nearly purchased one; when I discovered that there was hardly any PAL disks available, I decided against

it. This was a fortunate decision because Pioneer announced the 1450 towards the end of 1989. A limited number were made available to reviewers

and they discovered an unadvertised feature: the 1450 was capable of playing NTSC disks using up-to-date colour televisions (less than about three years old).

This caused problems for Pioneer as the film companies were not too pleased. They are afraid that people in Europe may import films that have been released in the States on NTSC disks but have not yet been distributed in Europe. They claim that copies could be made using the 1450 but, strangely enough, it is not possible to make a copy of a NTSC disk using a PAL video recorder. Nowhere does Pioneer mention that the 1450 can replay NTSC disks and as they are being subjected to a lot of pressure there is always a possibility that this important feature could be

removed at some future date.

To give some idea as to how complicated the situation really is, I have listed below the different types of disc that may be replayed on the Pioneer

CLD1450:

NAME

CONTENTS

SIZE

DISh

COLOUR VIDEO

DIGITAL

ANALOGUE

SOUND

SOUND

LD(CLV) 30cm

Gold

LD(CAV) 30cm

Gold

LD(CLV) 30cm Silver

LD(CAV)

30cm

Silver

LD(CLV) 20cm

Gold

LD(CAV)

20cm

Gold

CDV

12cm

Gold

yes

res

yes

yes

yes

ves

yes

ves

jes

ves

ves

MAX

TIME

120 min.

72 min.

120 min.

72 min.

40 min.

32 min.

26 min.

yes

yes

yes

Video part: 6 mins

Audio part: 20 mins

CD

CD Single

12cm

Silver

8cm

Silver

jes

yes

71 min.

20 min.

I was going to write much more but as I ran out of time I decided that

the best idea might be to distribute some notes at the demonstration (if it

ever happens ...keep your fingers crossed). [Ed: I look forward to part 2 of this article.]

Amiga Assembly Language Programming

by Shane Broadberry

Programming the Amiga in C seems to be a widespread phenomenon, and with very good cause, but there are times when C just won't provide the speed associated with well written assembly language. For anyone with experience in another assembly language, the 68000 will not seem all that different. There are just a few simple rules that have to be followed, and the 68000 is at your command. The 68000 is a very complicated processor compared to the likes of the 6502. The 6502 had a very small instruction

set, with more in common with RISC than CISC architectures. As a result a great deal of extra work fell on the programmer, limiting to some ex-

tent the ease with which programs could be written. The 68000 has many similarities with high-level languages, as you will shortly see, with some expensive (in terms of time taken to execute) but powerful instructions. On the C64, learning to program in assembly was made all the more simple by the simple OS - on the Amiga learning to program the processor does not

grant immediate access to the upper echelons of Amiga programming, since the rules for making OS calls must be learned - but what better way to do that than by practice?

Firstly an important point to consider when writing in assembly language on the Amiga (or indeed any other machine) is the advantages and

disadvantages of doing so. Unless speed and/or program size are of high importance, write the program in a high-level language. As a result, development time will be cut by an order of magnitude, and the program will be much more easily modified and expanded. It is always much better to try and improve the algorithm (and often much more effective) than to directly translate a more simple (and often less efficient) algorithm into machine code. This is where 'code profilers' and other such utilities prove invaluable.

Assembly language programmers must do everything in their power to ensure that they obey the rules imposed by the operating system. Pro-

gramming in assembly does not include the right to read/write to absolute addresses within the Amiga; this was, and still is, fine on the C64, but as is so commonly pointed out, will definitely not work well with the Amiga. One final point - writing assembly language does not mean that all order and logic must escape program design and implementation, it can be almost as structured, modular, and upwardly compatible as any Amiga C program.

Ok enough warniugs. Firstly a brief look at the g000 overall, and then De some of its addressing modes. The 05000 has S 32-bit data and addres

Teeters. The data registers are numbered do-d7, and the address registers 56-a. The data registers are simply extensions of the familiar I and * registers of the 6502 but the address registers however may aeed some brie explanation. Indirect addressing on the 6502 involved the use of a zero page location and an index register, for example:

lda

($fb), y

This instruction would load the value at the location pointed to by the "Sfb- Sc pair + contents of the Y-Register" into the accumalator. This was the limit of indirect addressing on the 6502 (yes I am aware of the Ida ($fb,x). addressing mode, but it is used rarely, and is practically useless). The

methods of indirect addressing on the 68000 provide much greater flexibility, but the format for doing so is slightly different. For example:

move.b

(a0) , d0

This instruction will move the byte value at the address pointed to by ao into data register do. Note the order this is done - the first argument

is the source operand, the second the destination (unlike Intel's family of processors!). The following instruction

move.b

do, (a0)

is the reverse of the previous instruction. It moves the lower 8 bits of data register do, into the address pointed to by al. I've given away a small

clue here regarding the movement of bytes, words and longwords (32 bits) in instructions. Dependent on whether you wish to effect bytes, words of longwords, we append a .b, .w or a .1 respectively (b refers to the lower 8 bits, w to the lower 16, and I to the whole longword - all other bits in the longword will be unaffected by a .b or a .w operation). A word of caution here however. The 68000 is unable to:

(a) Execute an instruction on an odd word boundary, or

(b) Retrieve a word/longword from an odd boundary.

This is basically a fact of life, a decision made by Motorola to simplify the chip architecture. In practice it won't cause too many problems (although I guarantee every 68000 programmer has generated many "address errors"

in their time).

Some common addressing modes

Two common addressing modes with suitably grandiose titles are "address register indirect with postincrement" and "address register indirect with predecrement". For example:

move.w

do, - (a7)

This instruction decrements the address pointed to by a7 by a word (a7 in the normal course of events is the user stack pointer), and then moves the lower 16 bits of do (note the .w extension) into the address pointed to by a7. Note the order in which the decrement occurred (before the word was moved). The inverse of this is of course to take the contents of the address register, and then increment the address pointed to by a7, i.e.

move.w

(a7)+, do

There are no post decrement or preincrement addressing modes. We'll leave some of the more straightforward addressing modes, and have

a quick look now, at two important forms of addressing. These two addressing modes are used frequently in Amiga programming when accessing system pointers and structures. These modes are of course indirect addressing with displacement, and indirect addressing with inder and displacement.

Let's have a look at how we might use these addressing modes. The idea of an index is common enough to assembly programmers; even the most sparse instruction sets have some way of indexing from an address. The format this takes however, is slightly different. The command

move.x

do, offset (a0,d1.w)

; where x is b,w or l

will move the contents of do into the address contained in a0 + d1. + offset (offset is a signed displacement, explained later). Note by spec.

ifying a . W extension for d1, we can only index to a signed range of one word - .L allows us to index up to a longword.

The other addressing mode mentioned was register indirect with dis placement. With this form of addressing, if we are given a pointer to some

system structure (maybe it's the current preferences settiugs), we can access elements of the structure very easily. Once the address of a particular structure or library is kuowu. we cau then call or access elements (of the structure) in a system friendly way. Let's suppose that a6 holds the base address of a library we have just opeued. Now as we know, each function exists at some place in memory, and, if we happen to know its address then we could call it directly using something like

jsr

Function_Address

This of course is the COMPLETELY WRONG thug to do, because it might not work under another version of the OS, or worse still, even on the machine it was written on. How then do we go about calling a routine that might be somewhere else the next time we reset our machine? Well the answer has been with us all along. Instead of providing absolute addresses, Commodore provide us with offsets. Let's suppose for a moment we have just opened the graphics library (don't worry about how this is done for now) - once we have opened this library, the base address at which the library resides is returned

and we place it into address register a6 (this is done by convention). Now we know the address of the function or procedure we want to call in the

graphics library, because we have an offset (a number to add or subtract to this base address) which we will use when calling the routine. So instead of having everything hardwired into our program we can handle the movement of routines, structures, etc. with an absolute minimum of effort, and our programs should run on just about any configuration of Amiga.

Assuming that a6 holds GfxBase (the base address of the graphics library when opened).

jsr

_LVODraw(a6)

will call the routine in the graphics library called Draw. Now in case you re wondering, LVODraw is a constant defined in one of the header or include

files that the assembler, when instructed, loads at the start of our program (the LVO stands for Library Vector Offset). This constant is added to the contents of a6 to calculate the absolute address of the routine before it is called. We use a similar method for accessing elements of system structures,

One point that has been overlooked which I will briely mention now, is how the library itself is opened. As you might suspect there is one librar whose base address we can find without first having to "open" it. This

library holds the very function we need to open other libraries, Open Library which is in the Exec Library. Fortunately this library's base address is

always held in the same location, location 4. The following instruction will place the contents of AbsEzecBase ($00000004) into register a6

movea.l

AbsExecBase,a6

(The "a' in 'movea' signifies the destination register is an address register.)

All Exec library calls can now be made relative to a6, with little or no cost.

So we now broadly know how to interface with the Amiga environment through assembly language. The best way to learn from here is by writ-

ing and reading programs written in assembly language. There are a few conventions however which are useful to remember when interfacing with library routines; in this way we have a chance of adopting these methods in our own code to minimise any overheads. Registers do, d1, a0 and a1 are always treated as scratch registers - ALL other registers are preserved. The library routine is also free to assume that the base address of the library is in a6. If the routine returns some value, then it will be passed back through

register d0.

There are plenty of examples of Amiga assembly language source in the CUGI library. This is an excellent place to look for useful examples of code and programming style.

A Window on the C128

by William Leeson

Setting up a custom text window from assembly is a simple matter of loading the window parameters to the correct window registers and giving the cursof a new window area. This can be demonstrated using the following BASIC program.

10 POKE 229, 6

20 POKE 228, 14

30 POKE 230, 12

40 POKE 231, 32

50 PRINT CHR$(147)

:REM Row 6 to Window top

:REM Row 14 to window Bottom

: REM

Column 12 to window left

: REM

Column 32 to window right

: REM

Clear Screen

The default window can be restored by typing or printing HoME HOME. The first HOME will move the cursor to the top left of the current window

and the second will bring it to the top left of the screen. Beware of pressing [CLR followed by HOME - the (cuR clears the current window and, naturally, places the cursor in the home position. The HOME will then cause the curent window to be cancelled. You could easily do this by accident

when programming - one section ends by clearing the window and another immediately prints HOME followed by some text. It is even easier for this

to happen if you use the 'official' window command because it always performs a HoME] when it is executed. If you then do another, bang goes your window! (Editor's comment: I solved this problem by printing a colour code after setting up each window. If a HOME was pressed now, nothing unusual happened.]

The attached assembly program shows how to set up a window trom machine code. It has the same as the following BASIC command:

WINiDOM topcolumn, toprox, bottomcol, bottomtok [, clear]

clear is an optional parameter (that's what brackets (] are supposod-ie Cell to - you don't actually tope them in) for automatically dearis"

in stoma text window. You use 1 to cieal'"the Screen or 0 to leave it as it* If you omit tie parameter completes it 15 25 touR you upped in thel 0.

Assembly listing of window program:

top

bottom

elrscrn = $93

= $e5

= $4

= $e6

left

right

= $e7

outchar = $ffd2

lda #4

sta top

lda #14

sta bottom

lda #12

sta left

lda #32

sta right

lda #clrscrn

jsr outchar

; Row 4

; To window top

; Row 14

; To window bottom

; Column 14

; To window left

; Column 32

; To window right

: Clear screen

For Sale

1571 Disk Drive and Final Cartridge 3 - I will sell 1571 with Final Cartridge for £150 OR swap for Amiga External Drive or Half meg Internal memory. Neos Mouse & Cheese, Books on programming the C128 in BASIC and Assembly Language, Simon's BASIC cartridge, Introduction to Basic Part 1 & 2 for C64, Input Programming magazine series, C64 Games Book and The C64 Programmer's Reference Guide (£10 each).

I also have about 100 disks @ 50p each and 15 games on disk and tape £1 each.

Contact William Leeson - phone: 822321.

Printer Settings

by Leon Hurst

Since Commodore released their rauge of Amigas, no real attention has been given (not in any intelligent or informative way) to the Preferences

printer settings section. In this article I will attempt to explain the settings and give the values needed for the best graphics dump possible.

Whew you access the Preferences pick the box marked CHANGE PRINTER. On the page that appears pick the printer driver which is relevant to your particular printer and whether it is SERIAL or PARALLEL. The others below it make no difference to graphic dumps except QUALITY

where DRAFT must be picked as LETTER causes an overlap resulting in parallel lines running down the picture.

Next pick GRAPHIC 1 on that same page:

Threshold

This generally determines the overall darkness of the dump as it increases the amount of dots per inch for each of the colours/shades used. This should be set at around 3.

Aspect

Horizontal means it comes out of the printer as you would read text, Vertical means it comes out on it side. Pick Vertical to make full use of the page.

Shade

Black and White if you want B & W output. Gray Scale 1 if you want a B & W photographic effect. Gray Scale 2 (if you have it) only prints in four shades of gray. And colour if you have a colour printer and want a colour output.

Image

Positive is as a normal picture. Negative is like one of those photographic negatives. Pick Positive. Now pick OK. You are now back a page. Pick GRAPHIC 2.

Anti-aliasing This smooths those jagged lines. Pick OFF for reasons to be given. (This is also known as smoothing or smooth).

Left Offset

Centres picture in middle of page or key in the distance in inches from the left of the page were you wish the dump to begin. Up to you!

Density

It doesn't affect my dumps but it is the "blackness of the black". I have it at 5. However it make text more black as

you go up to 7. In the case of lasers it will higher the DPI setting and so a dump will be sharper but darker, in text and graphics.

Dithering

This is most important. Order causes the shades to be coarse and harsh to the eye (not recommended). Halftone gives best results on "printers" of high densities (e.g. lasers). F-S is what I recommend. It gives a smooth and crisp dump but loses slightly in contrast between shades. This is the reason that "Anti-aliasing" doesn't work. It is automatically switched off when F-S is selected.

Scaling

Just select Integer and be happy it causes no problems as it has caused me. It resizes the dump if you pick Fraction.

Limits

Pick Ignore if you are using Deluxe Photolab as you adjust the size of the dump by using the program itself. If using PhotonPaint or Deluxe Paint III select bounds and key in the size of the paper you are using to the left of the list. This means it will use the full page to dump.

Colour Correct R/G/B

This is to match up the colours on the screen and

the colour which the printer produces. But 308 shades per R/G/B are lost by colour correction.

I recommend the Ham Pics art disk, which is in the CUGI Library, as the best acid test to the quality of dumps possible. I used the above settings on

my Star NL-10 (older brother of the LC-10), with the Epson printer driver and the results were quite impressive. A new ribbon is always recommended

to bring up the darkness.

The settings which are given above work best with pictures of contrasting colours. Small amendments might need to be made to suit the specific printer you have. Any non-standard resolutions, such as the Dynamic Hires pictures seen in the NewTek Demo will cause sizing problems if you use Deluxe Photolab. The only way to solve this is to print a picture of 2 pages

long and 2 pages high.

WARNING! Some art programs (e.g. Photon Paint) have customized Printer Preferences and if you delete them and replace them with another preferences, they will not work and certainly won't print.

Demonstrating Structures

by William Leeson

Here is a small C article for those people who would like to learn about structures. For those of you who do not know, a structure is a set of related pieces of data grouped into a single object. For example:

struct employee_data {

char name [30] ;

int salary;

int account_number ;

} william;

This declares a structure called employee_data with a list of 3 elements: a name, a salary and an account number. I have also declared an instance of this structure although this can be omitted. Whether or not you declare the variable, you must include the semi-colon. In order to refer to an element of this structure, you must give its name followed by a dot as follows:

william.account_number = 891234;

william.salary = 500;

strcpy(william.name, "William Leeson"):

This assigns values to the elements of the structure. A structure declaration can initialise all or some of the elements of the structure. This takes a similar format to the initialisation of static arrays.

struct employee_data {

char name [30] ;

int salary;

int account _number;

} programmer = ( "Fred Flintstone", 2500, 1234);

This initialises a structure called programner. Structure values may be read or written to files. The following example writes the contents of a

structure to a file called names.

include ‹stdio.h>

struct employee_data {

char name [30] :

int salary;

it account_number;

} programmer = { "Fred Flintstone", 2500, 1234};

void main()

{

FILE *fp;

{p = fopen ("names", "wb");

fwrite(&programmer, sizeof (struct employee_data), 1, fp);

fclose(fp);

return (0) ;

}

When the Names file has been created, another program (similar to this one) can read back a structure. Note that we must open the file for writing in binary mode since we are outputting binary information; hence we use "wb" as the file mode in fopen. This article has barely touched on the use of structures but hopefully it has given you an incentive to find out more about them.

Perplexing Peripheral Purchases

by Geoffrey J. Reeves

Note: No apology is made for omitting any company at home or abroad. This is just one person's advice and knowledge on the subject.

Anyone relying on just one such source is missing the point of this article.

One of the most irritating things about expanding one's Amiga is the pricing of those bits and pieces you wish to buy. Reading the (British)

magazines doesn't help either. How is it that a 312k RAM expansion can vary from under £50 (sterling) to over £100? I don't have the answer to

that one but what I can do is to make you aware of facts like this and. maybe, point you in the right direction.

Purchasers of the basic Amiga 500 will quickly become aware of the need to expand their machine, particularly if they intend using it for more than playing games. That is not to say that playing games is in any way a misuse of an Amiga - the Amiga is one of the best games machines around today. But it is capable of much, much more. Besides which, many of the games require more than 512K and one drive. Running programs such as Deluxe Paint III and TEX require a minimum of 1 Meg and two drives. I won't even try to argue which upgrade (more RAM or an extra drive) you should get first. It is very simple - get both!

Where do you start? I'll start with extra memory. There are a few ways to go on this one. Firstly, the 512K slot under the Amiga. Prices vary but

Memory Expansions (£49 without clock) and Diamond Computers (£47.50 inc. clock) lead the field. Get it with the clock; having your files date-stamped cau be very useful. Plus, it is nice to have your computer able to tell you the correct time. Remember, if you buy overseas, ask (tell) them to remove the VAT. You may have heard of a board which gives you 1.8 Meg - this does work by all reports. There is another which includes a PC

and 1.5Meg (£320 estimated) but it not yet available. Oh yes, they do fit into that slot under your Amiga. They obviously must use the new RAMs which require 4 for each 512K.

Secondly, you can get a separate board which either fits inside the main Amiga unit (you have to open up everything, etc.) or is connected to the

expansion port on the left side. Again, prices vary and there can be some hidden catches. Check advertisements by M.A..I. / George Thompson and

Bytes & Pieces. Bear in mind that the latter seem to always reduce their prices within a fortnight of buying one of their products! The catch is all to

do with auto-configuring. Some memory boards simply require connection

and the Amiga recognises the memory automatically, Others require that a

command be executed (or added to your STARTUP-SEQUENCE).

I have, for example, a 1.5 Meg board that requires an AddMem 800000 g7ffff command and I have had some problems when using an A590 with

its added memory and that board. There should be no problem because the memory does not apparently clash. I checked this using the MergeMen command, which while it didn't actually merge any of my memory, it did tell

me what memory I had. My own A590 has no extra memory so the problem has temporarily been 'solved'. There are other boards, in particular, a 2 Meg internal board which can be piggy-backed onto another giving you an

extra 4 Meg internally (and, I suspect, a very warm Amiga). I have heard of 8 Meg boards but their cost is way outside my funds.

Thirdly, there is the afore-mentioned expansion capability of the A590. This is certainly the cheapest way to expand your Amiga's memory. I have heard a price of £119 (sterling inc. VAT) for 2 Meg from {Diamond Computers but their Irish branch quotes £85 per Meg (though they say, a club such as ours should get discounts). Doing some calculations - £119 ÷ 1.15 (VAT) ÷ 0.96 (exchange rate) x 1.23 (IR VAT) and making comparisons doesn't make any sense at all. This memory does auto-configure and is simple to install. Mind you, it does seem puzzling that the A590 comes with stickers designed to prove that you have voided the guarantee and instructions encouraging you to open up and disassemble your drive. Incidentally, it is worth repeating that adding the memory to an A590 is very simple -

just make sure you have the correct size and type of screwdrivers and some work space; put the chips in the right way around and set a jumper. Say no more!

If you are pricing/purchasing, you should reckon on about IR£35 per 512K of RAM (using the new chips). The 'underneath' board version will cost extra, obviously. It has the board itself and the clock: IR£50-60 seems reasonable. All internal boards are more expensive - particularly the older

ones. The cost of R.AM chips has come down significantly in recent times so you are very foolish to buy without getting advice. Getting RAM is useful (apart from the 'I've got + Meg - what do you have?' one-upmanship). I, personally, find that 2 Meg is now a comfortable minimum with which to work.

Next, another drive? At this stage, if you can afford both you will have considered the A590 but you might still want an extra drive anyway. Again

prices seem to vary wildly. You should expect to pay around IR £TO-80 for no external dive. CUG! has been quoted €58 plus VAT but it is posible

20 de better. Many companies in the UK have drives priced around f0 Which might work out cheaper if the Irish YA isn't collected. I suggest you Theck out Evesham Micros, Megaland and Dimension, to name but a fe. incidentally, which drive you get doesn't really matter. Some are quiter than others, some smaller, some a nicer colour. What is important is the length of the cable, an on/off switch and a through port. Remember, it is possible to have a df2: and a d3: but having both definitely requires that they be externally powered. I have successfully connected up a df2:, for example.

In the end, however, the decision lies with yourself. Get second, third and fourth opinions. I have often said that if I got anything good out of the group, it was the advice that counted the most. What's more, it came free.