September & October 1989 Newsletter! EDITORIAL 3 NEWS Newsletter Subscriptions 4 Programmers Conference 4 PHOENIX : The Replacement MotherBoard for the Amiga 1000 5 WPCorp Decision on WordPerfect 8 June Amiga DevCon Shows New Commodore Products 8 Microfiche Filer Plus Wins CES Award 9 Our Own BBS ? 9 NEW PRODUCTS Amiga Desktop Video 10 Cheap Handy Scanner 10 C-Ltd Upgrade Drivers and Interface 10 FOR SALE 10 MEMBER FEEDBACK New Virus, ARP NOT Operator, Hitchhikers BBS & PacNet 11 NeXT and UNIX Amigas: 12 Changing the System Font 12 AMax impressions 12 NX1000 Colour Printer Drivers 13 NTSC Sized Screens, Bard's Tale II 13 MEMBERS QUERIES Shell Default Window Size 14 Advanced System Programmers Guide 14 Amiga Self Destruct Facility? 15 LETTERS TO THE EDITOR Amigans Rise Up, or What the Amiga Should Be 16 Mac Trash 19 Slow Newsletters & Newsdisks 19 Amiga Meetings 19 A Mega Amigas 20 Amiga Arcnet ? 20 HyperCard ? 20 CHOOSING YOUR NEXT LANGUAGE As Simple as Kicking a Tyre 21 ARE YOU A REAL PROGRAMMER? 23 ARTICLES Perfect Sound Digitiser and AudioMaster II 24 Four Player Gauntlet 25  Page 1 September & October 1989 Newsletter! CORRECTIONS Kickstart 1.2 & 1.3 co-resident 26 REVIEWS M2Sprint Modula-2 from M2S, Texas 27 INTERLACE & FLICKER FIXERS What is Interlace and Why Doth it Flicker so? 30 Commodore Flicker Fixer 31 C PROGRAMMING SECTION Contents 33 Hints & Tips 34 Problems 35 Topics 37 THE FLAKE REPORT Amiga Hardware Bugs and Fixes 41 Screen colours and other boot things 49 USER GROUP INFORMATION Subscriptions 50 3.5" Disks 50 Newsdisks 50 Public Domain Library 51 Group Meetings and members looking for Amiga owners in their area SOUTH ISLAND 51 NORTH ISLAND 53  Page 2 September & October 1989 Newsletter! EDITORIAL Two bits of wisdom for the month : 1) You know it's time you upgraded your Amiga1000 when someone who's considering buying an Amiga, asks what's an Amiga1000?! 2) You know your computer is a success when Asian clones start to appear, they appeared for the TRS80, AppleII, the IBM PC, and just recently for the Macintosh - so the Macintosh has finally come of age ... Amiga clones just around the corner I expect!!! On a recent Fish disk, there were three programs from NZ, from John Bickers, John Davis, and John Veldthuis - I can't help but have the sneaking suspicion that Fred Fish did it deliberately. There's some plot to infer that all NZ programmers are called John (pity we hadn't sent him anything from John Matthews). Anyone might think you have to be called John to write Amiga programs in NZ ... now I wonder what the J in AJW stands for ... I just did a quick check of our database - we have 23 Johns, 18 Peters, and 12 Davids. Of these 7 Johns, 7 Peters, and 3 Davids claim to be interested in programming. STOP PRESS!!! >>>>>>>>>>> Amiga1000 **** Amiga1000 **** Amiga1000 <<<<<<<<<<<<< Just received last night, before we went to 'press' : An Australian company is hoping to embark on an Amiga1000 upgrade that will allow the use of the Enhanced Chip Set, Flicker Fixer, and an Amiga2000 style expansion slot. So if you've got a trusty old Amiga1000, don't miss this opportunity - see the news release at the end of the news section. ---------------------------------------------------------------- We've just got another price reduction on Nashua disks, we can now sell disks for $23 per box of ten, or $220 per 100, including postage. ----------------------------------------------------------------  Page 3 September & October 1989 Newsletter! NEWS Newsletter Subscriptions This isn't really news as our newsletter subscription went up to $18 for 12 months, over 6 months ago, but I'm still getting $12 subscription renewals. So despite the lack of recent newsletters (due to the a relativistic effect that says the faster I move the less time I have), and not withstanding Ross Deeleys quip that the Wellington newsletter now comes out quarterly!, our newsletter subscription is $18 not $12. (Printed newsletters cost us about $2.50 each including postage!) Programmers Conference Plans for the meeting of Amiga programmers, that we mentioned in the last newsletter, are progressing. We are heading towards a meeting in Wanganui in early February 1990, over a weekend. It's expected people could travel there Friday evening, and the meeting would be during Saturday and Sunday morning, with travel home on the Sunday afternoon. A venue has been found, it includes accommodation etc, and will cost around $12 per night per person, meals would be extra. To be a success we would probably need at least 20 people attending - the whole idea is to learn something about the Amiga through talking to as many other Amiga programmers as possible. Now don't be scared off by thinking this is only for "REAL" programmers, anyone who has invested a bit of time learning about the Amiga and has tried their hand at writing a few programs, is well enough qualified to attend. This is NOT a meeting for people who just use the machine for playing games or as a mere tool (and it should go without saying [but I'll say it anyway] we certainly don't want anyone who just pirates disks) On the question of what we'll do at this meeting, well that depends somewhat upon what you want to do. I expect we'll try to get a few people to give talks on some aspect of Amiga programming, eg A description of what rasters/ viewports/ views/ screens etc are all about, How to program the copper or blitter, Assembly/ C/ Modula/ Draco/ BASIC? programming, User interface design considerations/standards, Resident/re-entrant programs, Interrupt driven music routines, The innards of Kickstart, Stomping on viruses. Then what about a few hands on programming exercises, workshops solving your intransigent program bugs? Well I don't know - you tell us what you want to see. Could everyone who is at all interested please reply. Even if you don't think you'll be coming to this conference we need to know what you'd like to see at such a conference if you could come, why you can't come, and what would induce you to come etc. We don't need absolute yes/no replies immediately, but we really do need a show of hands from all those interested in attending. I shall include a reply form that you can return if you're interested, or contact Liam on (064)55-610, or write to him at 44 Durie Street, Wanganui.  Page 4 September & October 1989 Newsletter! PHOENIX : The Replacement MotherBoard for the Amiga 1000 From the Australian disk magazine, MegaDisk #13 Andrew Wilson, the original developer of the popular Proton memory boards, now making the even more popular 8-meg memory board, has a design plan for a REPLACEMENT Amiga 1000 MotherBoard. The PHOENIX BOARD will include : - FULL SUPPORT for the ECS Chip Set. - The ability to use your existing expansion connector peripherals. - Up to 2 Megabytes of switchable RAM on the main board. - Up to 10 megabytes of INTERNAL, switchable autoconfiguring RAM using an 8 Meg daughterboard. - INTERNAL Real Time Clock and Calendar (500/2000 compatible). - Provision for up to three INTERNAL KickStart ROMs, allowing SWITCHING between KickStart 1.2, 1.3 and 1.4, including provision for INTERNAL KickStart EPROMs allowing customised KickStarts. - INTERNAL Disk Drive Connector allowing internal fitting of DF1:, DF2:, and DF3: (if fitted in a larger case.) - Drive swap switch to allow booting off other disk drives. - A500/2000 style switchable Audio Filter. - INTERNAL space for a 68881 math coprocessor. - FULL B2000 style VIDEO SLOT. - One Amiga 2000 slot, allowing a 2000 board to be plugged in, or a 2000 type multi-slot backplane to be used. (Only in a bigger case) - Provision for a SCSI Port for Hard Disk, CD ROM etc. - BOARD FULLY SOCKETED. OTHER FEATURES THAT WILL BE INCLUDED TIME AND SPACE PERMITTING - Support for 68020/030 and 32 bit RAM/ROM. - KickStart in RAM as per existing 1000. If you have other features that you think should be included, please write them down and send to the address below. We will not be able to put much more on the board but simple, useful things will be of benefit to all. The expected price of the PHOENIX BOARD is $AU600 with 1 Meg of RAM. The board will also be available bare if possible. A trade-in on the old A1000 is also a possibility. The A1000 chips such as the 68000 processor, Denise and Paula custom chips and CIAs will be reused to reduce costs, all other chips will be supplied. The PHOENIX BOARD will be a complete drop in replacement for the existing motherboard and will enable you to continue to use your existing external hardware. We will maintain the position of the 68000 chip in relation to the case internal fittings so that internal memory boards should still work but actually trying these will depend on their availability to us. The advantage of retaining the A1000's keyboard, power supply and mouse will be apparent to all who have  Page 5 September & October 1989 Newsletter! compared theirs to the 500/2000 setup. There is a possibility of a local installation point in each state, so you will be without your computer for the least possible time if you do not feel confident to install the board yourself. We welcome inquiries from suitably skilled individuals or organisations to do this work. The PHOENIX Board will suit all model Amiga 1000s, not just the NTSC versions, and is a local, AUSTRALIAN MADE product. There is one hitch. Andrew Wilson currently has over twenty products in development, including an Audio/Video Digitiser, Colour Splitter, FAX Board for the Amiga, SCSI Board, 68020/68881 Board, A500 Internal 2 Meg board, and a Board allowing Workbench in ROM. As well as all this, he is also struggling to keep up with the demand for his 8 megabyte memory boards, hard drives, and other products. At present, Andrew is doing all the work himself, and as a result, development has a low priority. Of course, the PHOENIX BOARD is on the top of the list, but if present trends continue, it could never eventuate. That's why we need YOUR help. We have formed a company, PHOENIX MICRO TECHNOLOGIES PTY. LTD., that will employ people to assemble, test and market Andrew's present products, leaving Andrew to work on development. The first project of the company will be the PHOENIX BOARD. Development time for the PHOENIX BOARD is expected to be three to four weeks from commencement. If you would seriously be interested in investing in the PHOENIX BOARD, and increasing the potential of your Amiga 1000 to beyond that of even the Amiga 2000, please consider helping us. Place a $100 deposit on the board with us, and in less than three months, you could have a new computer sitting on your desk. Of course, if enough people do not place this deposit with us, the board will never eventuate, and the A1000 will fade into insignificance. People placing deposits with the company will receive a 20 percent discount on the price of their PHOENIX BOARD. Orders will be filled in the order in which they are received, ie first come first served. A closing date for deposits has been set at the 30th of November 1989 at which time we will be able to assess demand and make a decision on the viability of continuing with the project. All deposits will be refunded if, due to lack of response, we do not go ahead with the PHOENIX BOARD project. Once work has started no refunds will be possible. The sooner you place your deposit, the sooner it will all happen. Please consider helping us. You will really be helping yourself. Contact Andrew Wilson on : 0061-8-293-3960 (6-7pm Except Friday) or write to : 2 Meredyth Avenue Millswood South Australia 5034  Page 6 September & October 1989 Newsletter! Send Deposits and Orders to : Spanduct Pty Ltd P.O. Box 41 Goodwood South Australia 5034 ***** TO ENSURE THAT THE AMIGA 1000 SURVIVES INTO THE NEXT DECADE, PLEASE CONSIDER THE ABOVE PROPOSITION. AND PLEASE DISTRIBUTE THIS DOCUMENT AS WIDELY AS POSSIBLE. ***** ROSS MOLDEN. JONATHAN POTTER. ANDREW WILSON. {I rang Andrew tonight, and discussed his project a little. There has been a great deal of interest, and about twenty or thirty orders already. He is fairly confident of fitting all those wish list items onto the board, and keeping the price down to the level stated. Extra things that people have asked for like extra serial ports, battery backed up RAM etc may be accommodated later in a plug in expansion module, like the 256k module on the front of A1000s. There is apparently an American board called the rejuvenator, but that one won't fit into PAL Amigas, only NTSC ones. Andrew has also had interest from A2000 owners, the machines with the original A2000 motherboard (as opposed to the B2000 motherboard), who won't be able use the new Enhanced Chip Set. If enough interest isn't generated, he'll probably develop the thing as time permits, but it wouldn't be finished before the end of next year. At about $NZ800, it will be a bargain in all respects, and below the NZ price of any two of the added features (like SCSI port, added memory, multiple kickstarts in ROM, expansion slots, math co-processor socket etc). If it eventuates, and delivers half of what's promised it'll be a bargain. If you've been holding out on 'upgrading' to a 2000 because it's not worth it (sell your A1000 for $1800 to $2000? and pay $3500-$4000 for an A2000 which only gives you an extra 1/2 meg of RAM and a few empty slots?), then this is your chance (possibly only chance, as Commodore have dropped support for the A1000). Our club will be available to fit the upgrade boards so don't let that deter you. Disclaimer: The club has no vested interest in this project, and is offering no guarantee etc, the enthusiasm expressed herein is my personal wish to see this project go ahead - I'll be sending off $100(Australian!) tomorrow! -Tony Wills.}  Page 7 September & October 1989 Newsletter! WPCorp Decision on WordPerfect Stolen from AmigaTECH_7, Hints&News, (in turn stolen from a letter to Commodore Magazine from WPCorp) A few months back WPCorp announced it was halting further development on the Amiga, and had moved its Amiga staff to other areas. This seemed to be out of step with the company's usual strong support for users of its products and many users protested. In the September issue of Commodore magazine, WPCorp Amiga Products Publicist said this: "Reaction from a large number of Amiga users persuaded WPCorp officials that our position regarding product development for the Amiga should be reconsidered. As a result, WPCorp will continue development of WordPerfect for the Amiga. WordPerfect 4.1 is the most current version. We are currently working on an interim release of the product that will include minor enhancements and fixes problems with the software. As soon as that is released, we will begin working on a new version of WordPerfect. We will also continue to maintain and provide interim releases of WordPerfect Library for the Amiga. As a result of customer requests, WPCorp began preliminary development of a 6.0 version of WordPerfect that includes support for graphics. The current code in WordPerfect 4.1 will not allow the addition of a graphics capability. ... it would take one to two years and maybe more to develop a 6.0 version of WordPerfect. Given the timing and resources available, it is difficult to commit to a 6.0 upgrade at this time. However, development will move incrementally towards that goal. Once again, WordPerfect Corporation is committed to supporting the Amiga market. We regard the Amiga computer and its users very highly and we're proud of our products for the Amiga." June Amiga DevCon Shows New Commodore Products Stolen from AmigaTech_7 from Jon Hunt According to the September issue of Amiga World magazine, the June Amiga Developer's Conference held in San Francisco was a great success, with several new and important Amiga products available. For a start all attendees were given alpha (test) versions of AmigaDOS 1.4. Commodore's A2024 14-inch monochrome monitor was there, sporting resolutions of 1008 x 800 in NTSC, and 1008 x 1024 in PAL. The new Enhanced Chip Set was available, offering several new screen modes and capabilities. The ECS (new Agnus and Denise chips) can address 1MB of RAM compared to the regular 512kB, and allow "big blits" of 32kB x 32kB pixels. The new chips have Kickstart 1.4 routines, enhanced genlock support, Super Hires mode (1280 horizontal pixels per scanline) and Productivity mode (640 x 480, 4 colours) which will require a bi-sync or multi-sync monitor.  Page 8 September & October 1989 Newsletter! Microfiche Filer Plus Wins CES Award Stolen from AmigaTech_7 Microfiche Filer Plus, an Amiga micro-fiche style database published by Software Visions, won a CES Innovations 89 Award in the Business Software category. "We're quite proud that Microfiche Filer Plus has received this award," stated Gary Samad, president of Software Visions. "It's great to see the rest of the computing world recognizing an Amiga product as among the best in a market dominated by Macintosh and PC software." Our Own BBS ? There are plenty of BBSs in Wellington, and a few like Feeling Board, have a reasonable Amiga section, but we don't have one dedicated to our use. BBSs cost money to run (hardware, software, telephone rentals), and those that don't charge anything for use tend to come and go fairly often. Rather than set up our own I suggest we use one that is already set up, but very much under used - the Wellington MicroComputing Society BBS (great name that). This BBS is basically idle most of the time, and has the advantage of running Opus software which allows it to communicate with BBSs around NZ and in Australia. If there is enough interest we can see about getting conferences from other Amiga BBSs fed into it. As an affiliated club we can get full usage of it for $15 per year (about 4c per day!), and if we get enough joining at once we can get this lowered to about $10 each. Things have been setup so you can have a look around - you can log on and read messages, and see what files are available, type out text files, and even upload files, without paying a cent. Keith Stewart is acting as an assistant sysop, and has already uploaded a few files. Even if you don't all rush to pay to use it, you can still upload files for the newsletter/newsdisk to it, and I'll be putting the Programming section, and Newsletter onto it - which you can type out (but not download) even if you haven't joined the BBS. The fee charged actually gives you a form of membership to the WMCS, and goes to pay for the equipment and telephone line rental. Log on and have a look around, if you're interested in joining it then contact me so we can get you on at the reduced rate. Wellington MicroComputing Society BBS (WMCS BBS) - 24 hours, 300, 1200/75, 1200, 2400 Baud. Phone (04) 836-592.  Page 9 September & October 1989 Newsletter! NEW PRODUCTS Stolen from AmigaTECH_7: Hints&News [The following are from Commodore Magazine (US) September issue:] from Jon Hunt Amiga Desktop Video Deluxe Video III from Electronic Arts is due out now. Deluxe Video III offers complete control over the Amiga's graphics, animation and sound, by supporting all Amiga screen resolutions, super bitmaps, MIDI output and IFF standard sound and music files. Anims and AnimBrushes from DPaint III can be imported, and the videos can be played by the Amiga or recorded onto videotape. Cheap Handy Scanner Also just released in NZ is the Lightspeed scanner. Basically an adaptor unit for a PC hand-held scanner, it costs $895 including the scanner unit. No other docs available at this time. C-Ltd Upgrade Drivers and Interface C-ltd have released a set of upgraded drivers (V3.0) for their hard-disk units. These markedly improve the performance of their SCSI hard-disks ( 2-4 times the speed reachable under the old driver ) and also take up less memory. They have decided to make the drivers freely re-distributable, so any C-Ltd owners wishing to get hold of the new drivers may wish to get in touch with AmigaTECH ( as we have copies of them ). They have also released a new, ultra high speed SCSI controller ( they claim diskperf speeds of up to 500k per sec with it ). This is also available as an upgrade to current owners for only US $120. FOR SALE Available from the club: Disk Storage boxes: 80 disk capacity, disk storage boxes. Price - $20 plus postage ($3 to $5 depending on location). 3.5" disks : $23 per 10, $220 per 100. Library case: holds 10 disks, $5 each. Amiga1000 shielded printer cable : $15 (not for A500 or A2000)  Page 10 September & October 1989 Newsletter! MEMBER FEEDBACK New Virus, ARP NOT Operator, Hitchhikers BBS & PacNet from John Veldthuis (Manaia) I was recently given a new virus that is not a boot-block virus. It checks the startup-sequence and finds the first command in it. It then renames this to the devs: directory and changes the name to a series of spaces and shift-spaces. It then copies itself to the c: directory as the old program name. When it is activated it changes the OpenWindow vector in IntuitionBase. It waits until the initial CLI window is opened and then does it's dirty work. After copying itself it will make a screen and show the following message : A computer virus is a disease Terrorism is a transgression Software piracy is a crime This is the cure The rest of the screen has the name of the group on it. It has been done by a pirate cracking team. A dead give away is to look in the devs: directory to see if there is a file that has a name of spaces. My checker will check in memory and if it finds the TTV1 virus, it will disable the RomTag and bring up a requester saying it found it. It also checks for the TTV1 virus every time a disk is put in a drive. Regarding ARP: In the newsletter you said you wanted to do a list of everything but the info files. There is a NOT operator and it is the tilde character. LIST ~*.info will list every file but the .info files. I find this very good. {Yes the new ARP commands are quite versatile, but have you tried DIR ~*.info, it doesn't quite do what you might expect - you get a list of all files in all directories that don't end in ".info". (ie all files, including icons, in all directories as no directories are liable to have a name ending in ".info"!!!). And you haven't even specified the "all" qualifier on the DIR command - very annoying. I would love to be able to do a DIR ~*.info ALL, and have it list all non icon files, but, alas, it doesn't work. -ed} I also saw that the HitchHikers Guide BBS is going onto the PacNet system. Can you please give me their PacNet address number. As I am now on the PacNet, I am trying to find numbers of BBS's in New Zealand that I can use. Can you send me any numbers you now that will allow me on as I can't get anything at all from Telecom. {I have rung their BBS, can't remember their PACNET NUA offhand, if I find it before this goes to press I'll insert the number just here : >>>>> <<< -ed.}  Page 11 September & October 1989 Newsletter! NeXT and UNIX Amigas: from John Bickers I was just reading an article in my one and only copy of UnixWorld, Dec88, called "68000-based UNIX PCs", by James Brunet. Funnily enough, the main thrust of the article was to do with Apple dominating this arena (despite the fact A/UX was somewhat crippled). Anyway, the guy also mentions Commodore and Atari. Ignoring the Atari rubbish, I note that he mentions 3 versions (in beta-testing at the time) of the Amiga 2000, designed to run UNIX. The three configurations are: - 68020, 4Megs of 32-bit RAM - 68030, 4Megs of 32-bit RAM - 68030, 20(!)Megs of 32-bit RAM And the clock speed? 33Mz for all three! I looked up the intro of the NeXT machine in the Nov88 issue of BYTE, and note that the clock speed is 25Mz (8 Megs RAM standard). So given the choice, I would dump NeXT in a split-second. Be interesting to see the relative costs, if this is in fact true. I wonder if the Amiga stuff will ever get into a mainstream article in BYTE? Changing the System Font Stolen from AmigaTECH_7: Hints&News from Jon Hunt It is possible to change the system font using the FastFonts program supplied with Workbench 1.3. Include a line similar to the following in your startup-sequence: FF st.font Next time you boot up on that disk the new font will be used. Note that the font must have 8x8 pixel characters. AMax impressions Stolen from AmigaTech_7 from John Davis We've recently had the opportunity to play around with the AMax Macintosh emulator. I must admit I've been a bit sceptical about what it could do previously, but having used it I am truly amazed. I've yet to find one serious package off the Mac it won't run (but be warned, some packages such as TMON require you to set AMAX to a mac sized screen, not the usual AMax larger size). The general rule seems to be if it will run on a Mac II, it will run on AMAX. Unfortunately this means not many Mac games will run. {What a strange comment?, you want to run Mac games when you've got an Amiga!!? -ed}. Highly recommended. {It has possibilities when it comes to running packages not (yet) available on the Amiga, but to make the most of it you'd probably want a flicker-fixer. When they add hard disk support it'll be really useful. I notice that one of the Atari Mac emulators can now read Mac disks off an ordinary Atari drive - no need for an expensive Mac one. Now how about a MacII emulator, we may then find some software worth emulating! -ed}  Page 12 September & October 1989 Newsletter! NX1000 Colour Printer Drivers Stolen from AmigaTECH_7: Hints&News from John Davis A lot of people have been asking about what is the correct driver to use with the Star NX1000 colour printer. CBM NZ does supply a NX1000c driver, this is often bundled with the printer. However, this is an old 1.2 driver and is not terribly efficient in operation. A far better solution is to use the EpsonX[CBM-mps1250] driver off the 1.3 Workbench disk. This will drive the NX1000 in colour mode if you select COLOUR from the Preferences printer graphics 1 screen. This will give you full colour printouts, and at about three times the speed of CBM's ancient NX1000c driver. NTSC Sized Screens, Bard's Tale II from Russell Robinson Thanks for putting in the last newsletter my request for information about "NTSC only" programs and how to trick them into running. Since your suggestion about resetting DisplayFlags didn't seem to work, I decided to look at the program in question more closely, i.e. disassemble it and try to find out what it is looking at before it puts up the "Sorry, NTSC version only" message. Luckily this was fairly easy to do. The program checks NormalDisplayRows (offset of +216 from GfxBase. If this isn't 200 you get the message. I wrote a short program (in FORTRAN - still the greatest!) to reset this to 200. Once this is done the other program runs fine (with an NTSC size screen). A warning to others about the game Bard's Tale II: don't get it unless willing to either 1) devote a large part of the rest of your life on exploring the numerous (but all boringly similar) dungeons; 2) buy the clue book. Once you get to know how the game works it is difficult to avoid spending too much time at it, at least until the first dungeon is completed. Then the boredom sets in and resorting to the clue book is the best way to proceed. Also, I got so tired of having to retreat from the "beginners's dungeon" (because of rapidly decreasing health and spell points) that I decided to try to create my own super-heros without having to slowly accumulate all the otherwise necessary experience, money, etc. Becoming an arch-mage takes forever! Anyway, by inspecting the character files and how they change with changes in experience, level, gold, etc it was possible to do this without too much trouble. So I now have a paladin, warrior, monk, and two arch-mages with essentially unlimited armour, experience, gold, and spell points. This is a BIG help! Some hints for those still in the first (beginner's) dungeon: if something that flies offers to join your party, accept it. Be sure to make detailed maps adding to them after each move or two (use the pause function to avoid being attacked too often while stopping to do this). But don't expect the princess you rescue to dazzle your eyes with her beauty - the picture you get is the same as the one used for ogres!!  Page 13 September & October 1989 Newsletter! MEMBERS QUERIES Shell Default Window Size from Phil Norton (Blenheim) How do I change the Shell default window size, I have tried the WINDOW= command as on page 1-2 of the Enhancer Software(1.3) Manual. {It depends upon what you mean as the default window size; the WINDOW=Device:XStart/YStart/XEnd/YEnd/WindowName setting in the tooltypes field of the Shell icon (modified using the Info option of the Workbench menu) will open the specified window when you start a new shell from that icon. The keyword must be in upper case, and you must specify all the fields including windowname (even if blank). If it doesn't understand your window specification it will default to opening a NEWCON:0/50/640/80/AmigaShell window, and if the NEWCON device isn't mounted (and you click on CANCEL on the requester that results), it will open a CON:0/50/640/80 window. Examples such as WINDOW=CON:0/0/640/200/MyCLI should work on any system (ADDed as a tooltypes field, no spaces anywhere). (You can also specify devices such as RAW: and AUX: if you wish). The Shell icon just invokes the CLI program in the SYSTEM drawer, there is not a separate program called "Shell". If you really want to change the "default" window size (the window that will appear when nothing else is specified), you can always use a binary file editor such as NewZap and change the NEWCON:... and CON:... strings in the CLI program (do I hear strangulated screams from JJB?)! (NB don't overwrite anything beyond the end of the current window specification or you will corrupt the program) From CLI you can again specify the window to be opened by NewCLI or NewShell, eg NewCLI CON:0/0/640/250/Biggy, or you can be again get out the hatchet and zap the program. Lastly most PopCLI type programs (that open a CLI window when you hold down a couple of keys), allow you to specify the window size when you install the program. -ed.} Advanced System Programmers Guide from Jeff Thomson (Masterton) Have you heard anything about a book by Abacus called "Advanced System Programmers Guide" ? I have the first one (System Programmers Guide) and it is excellent and I have read that this one is available and wondered if you could tell me anything about it. {I haven't seen either, but Gary Walker of Ruralcom lists both on their book price list, so you could ask him. Anyone actually own a copy? -ed.}  Page 14 September & October 1989 Newsletter! Amiga Self Destruct Facility? from Neil Graham (Hokitika) I have been snooping around on various disks, and I have come across a piece of text on block 112 of Elite. This harmless piece of text quite calmly informs you that the program has detected a change made by hackers and that it will damage the CMOS circuitry at any time. Now before anyone says that it is impossible to damage a computer with software, I know of ways to damage the PET2000 with a poke, and a few keys to press to blow the early Apple computers. The big questions are , has an Amiga designer slipped up, can you damage an Amiga with software, and the real biggie, can you put this poke or program into a VIRUS. If all of these get an answer of yes, we are definitely well up the excremental waterway. By the way, any elite owners: type sara instead of the code first time, and when in the game, press help. {Firstly I expect the Elite thing is a bluff, no sane software company would put such an obvious bomb in their program because they'd have their pants sued off them if it went off on a legitimate copy of the program (eg because of disk corruptions etc), and I suspect they'd still be liable if it went off in a 'backup' copy. It may simply be there to cause the software pirates to waste a lot of time searching for the bomb, and hence extend the time it takes them to release a pirated version. Secondly there is not much CMOS circuitry in the machine (a lot of other MOS technology but not much CMOS), perhaps they are talking about the A2000 battery backedup clock - they could no doubt scramble its registers, so that the system can't read the time on startup, so your startup-sequence may abort, hang, or perhaps guru. But that's just a nuisance, not damaging. Thirdly, I wasn't aware of the specific examples you mentioned, but there have been examples of programs damaging hardware - eg on some IBM-PC type systems where the monitor is driven by, rather than synchronised to, the computer video output, it is possible to reprogram the CRT controller to a very high frequency and possibly damaged the monitor before the fuse blows. On the Amiga I expect you can set up some unusual conditions, eg stepping the diskdrive motors rapidly, reprogramming I/O chips so the inputs are changed to outputs so that they are driving against other outputs, that sort of thing may cause overheating, but I expect due to the machine strange behaviour you'd be liable to reboot the machine long before any damage occurs. Lastly, a virus is just a program, and can therefore do anything any other program can do, but I wouldn't worry about viruses destroying hardware until it happens! -ed.}  Page 15 September & October 1989 Newsletter! LETTERS TO THE EDITOR Amigans Rise Up, Mac Trash, Slow Newsdisks, Amiga Meetings, A Mega Amigas, Arcnet, Hypercard from Isaac Freeman. Amigans Rise Up, or What the Amiga Should Be {This letter was received before details of what AmigaDOS 1.4 will probably contain were published. -ed.} I have been throwing around an idea in my head for the last couple of days, and I have decided that it is time to pass it on. For a long time I have considered Commodore to be a kind of necessary evil for the Amiga, putting it on a sound financial platform, but making a lot of mistakes, and generally setting the Amiga back a fair bit. But the ultimate power comes from the public - we are the ones who can decide the success or failure of the computer. So my idea is, if we can get enough people to come together and say what they want from the Amiga, Commodore would be stupid not to pay attention. I'm not talking about anything heavy, like not continuing to support the computer, just a sort of "This is what we want to see." This will mean getting a really good idea of what Amiga users really do want, and if this idea is put into action it will mean getting hold of user groups all over New Zealand, and probably Australia, and asking them to send back details of what they would like to see. {I'm amazed at how well Commodore are developing the Amiga operating system. They're certainly listening to what people want, and appear to be behind the Amiga 100%. It's even conceivable that they know what's required without being told! I might suspect that they'd been listening to my suggestions if I'd actually ever sent them a list, as it is they've certainly implemented most of them anyway! -ed} I don't know if anything like this has been done before (No doubt individuals write to Commodore fairly regularly) or even whether it can be organised, but I thought I would start the ball rolling with my wishlist of Amiga enhancements. Firstly, some ideas for Amiga Dos: * A full redesign (not tacking on new programs) of Workbench, so that it is unnecessary for a user to go to the CLI for things like copying icons from one file to another. This should include full explanations of error codes, so that instead of "Error code 103" in the menu bar, you get a full message explaining that the machine has run out of memory, how much memory the program needs, how much is available, and some helpful advice, like "Try dragging the icon out onto the background and closing all non-essential windows." {I think most of that's coming in 1.4, except the help prompting aspect, that's one area that doesn't seem to been addressed yet ; built in help from Workbench and CLI, it is after all meant to be a user friendly machine! -ed.}  Page 16 September & October 1989 Newsletter! * Adoption of ARP as standard. {They're implementing their own ASL library, it's understandable that they don't adopt PD programs over which they've got no control. -ed.} * Updating and standardisation of programs like IconEd, Notepad, FontEd and AmigaBasic, to provide a standard user interface. Full details of what this standard interface involves released to all developers. {Commodore have defined a number of standards for things like edit menu options, load/save/save-as options, clipboard usage etc. And they will be pushing standards harder in the future. Yes, Commodore should lead the way by conforming to their own standards wherever possible. But you don't want things to be too rigid, with a machine as capable as the Amiga, the programmers imagination should be allowed a fairly long rein. -ed} * A standard system of iconification, working from a gadget on the program window, to replace all the different methods used by PD programs. This could be achieved simply by adopting a particular PD standard. {I agree that a standard form of iconification would be nice, it would be best if it was supported by intuition. A standard iconify gadget, or other device (eg clicking right mouse on close gadget?) is essential. -ed} While I'm at it, Commodore should license other PD and Shareware programs, like DMouse (or Mach if you like). {That's a real problem, they can't really support a program that isn't theirs, and would be in a very difficult situation if they were relying on some PD program and it's author stopped supporting it. Their current practice of implementing popular PD programs in their own fashion, seems to be a reasonable one. After all you want these new features as well integrated into the system as possible, not just tacked on as with most PD stuff. -ed.} * A Dos shell placed somewhere between Workbench and the CLI. Again, this should involve nothing more than the licensing of a PD program like DirUtil or Browser. {I don't want one more level added, I want Workbench enhanced so that it can be used for all file maintenance functions, it looks like Commodore are working on it. -ed.} * FastFileSystem for floppies. {I don't know that I really want that, on floppies it's not going to be that much faster than the standard filing system, and you forgo a lot of the recoverability that is a feature of the standard one. But it looks like it's going to be in the 1.4 ROMs. -ed.} * A new kind of sizing gadget (not necessarily to replace the old kind) with sizers in all four corners of the window. {Could be convenient but certainly not a crucial improvement! -ed.} * Standardisation of all windows and gadgets, including palette sliders, check boxes, radio buttons, the little switches found only in FontEd. {It would be good if there was a nice set of carefully sculpted gadgets available, but perish the thought that everyones programs should look the same! -ed.}  Page 17 September & October 1989 Newsletter! And for the Hardware: * A new architecture independent floppy drive, along the lines of the one in the Mac IIx, which will format up to about 2Mb, and read disks from MS-Dos, OS/2, the Macintosh, the Apple IIGS and the C-64 1581 drive. This should lend significant weight to the Amiga's ability to emulate other computers. {One that could take 8, 5.25, 3.5, 3.0 and 2 inch disks would be a help too!, -ed.} * A new chipset to handle the 1008 by 1024 resolution on the A2024 monitors, remove interlaced screens, boost the number of colours available in 640 by 512 mode to 256 (with similar improvements for other modes), increase the palette to 16.7 million colours, provide the ability the expand Chip Memory to whatever amount the user requires, and abolish the 9Mb Memory limit. This should be made as compatible as possible with the old chipsets. {The new Amiga chipset will give you that sort of resolution on PAL machines. Removing interlaced modes would kill Amiga desktop-video, so leave 'em alone! 256 colours would be nice, but don't stop at 640x512, I want 256 (or more) colours all the way up to 1000x1000 resolution! Separate 'CHIP' memory is a design compromise to maximise performance. What you really want, is to use dual ported memory throughout - but you'll have to take out a mortgage to pay for it! If you can afford more than 9Mb of memory you'd probably own a 68020 or 68030 turbo board already, these chips have a wider address bus, and can therefore access much more memory (eg the CSA board 32bit memory is on a separate bus and not limited by the Amigas 24 bit address bus). Anyway since when was 9Mb a serious limitation!!- ed.} * KickStart made available on a card, so that it can be easily updated. {Why not just put in on a disk (:-)) !! -ed.} * An erasable CD-Rom drive (not WORM), with a driver to run it as a standard AmigaDos device. {How about a CHEAP erasable optical drive, I would be quite satisfied with a WORM drive - if I could afford one, they're still not cheap even in the PC-clone mass market. You should be able to connect one already via an Amiga SCSI controller- you may have to wait for drivers to be written because SCSI isn't all THAT standard! -ed.} * A new Amiga (The Amiga II?) to be released in the middle of the 1990s to regain the technological lead that was lost with the A2000. It should be based on the new Motorla 88100 Risc chip, and be placed to compete with the NeXT. {As John Bickers pointed out, an Amiga3000 can already compete with the NeXT machine, but yes I hope Commodore are already looking ahead to their next machine. -ed.} So that's my input. Now if other members can throw in their ideas (and perhaps edit mine to make them more realistic) we might be able to give Commodore a bit of a push in the right direction.  Page 18 September & October 1989 Newsletter! Mac Trash On a slightly more mundane matter, is there any reason why a driver could not be written for a Mac-style disk independent Trashcan? I don't know a thing about programming (beyond a few words of BASIC), but as far as I can see there shouldn't be much problem in building a cross between a Ram-disk and a Trashcan. Perhaps this will motivate someone to write one (preferably not me!). {Why? Yes I expect it could be done but what is it about their trashcan that you want? I know it does interesting things, like remember where things came from, allowing you to restore them from whence they came, easily. If you only want a Trashcan on the Workbench screen, it would be easy to rename a RAM disk to Trashcan and use it as such! By using an ordinary RAM disk you'd have one that was automatically emptied when you rebooted - if you use a recoverable RAM disk you'd have one that was only emptied upon power off. -ed.} Slow Newsletters & Newsdisks Moving into the depths of total mundanity now, I haven't received a newsletter or newsdisk for well over a month now. Are you saving up for another double issue with several newsdisks? Have you found the disk I was sending backwards and forwards yet? I will send this up on another one, so that if all else fails you can use that. {Newsletters and newsdisks have been a bit slow at appearing, I go out to the mailbox everyday expecting to find one but nothings there. I haven't worked out where they come from, but I expect it works on the same basis as the storks and babies. I haven't found your disk yet (anyone out there got a disk labelled Isaac Freeman?) but I've replaced it, you might even get to see the replacement when the next one of those newsdisk thing turns up here (could the ozone hole be affecting the storks?). -ed.} Amiga Meetings Incidentally, I went to another meeting of the Christchurch Users group recently, after giving them a miss for several months. They have doubled their size since then, but have not become any more organised. Perhaps the meeting I went to was abnormal, but after about an hour of waiting while they got the BBS demonstration off the ground, I found an unused Amiga 500 in the corner, got together with its owner and a number of other people who had come to the meeting to copy PD disks, and half an hour later we managed to get it set up. From the 3 or 4 hours I spent at the meeting I gained three PD disks, talked to a few people and got to read some magazines. I didn't learn anything new about BBS's (and I have never used one before), and I didn't see DeluxePaint III as promised. Perhaps I am expecting too much though - everyone else seemed to enjoy it. {The usual story is - If they aren't doing what you want, then offer your services, and help them do it. From the way John Davis and Jon Hunt got themselves involved with the running of things you can see that they will listen. Here in Wellington I have to admit our meetings are a bit lame, we don't have formal business, speakers, or anything much- just a good chat with everyone else, full access to the PD disks, and purchase of disks etc. I'm no good at getting up and telling people what to do or organising anything, besides I've no time to organise anything anyway. I am surprised that a few people haven't  Page 19 September & October 1989 Newsletter! got up and complained they want more, or perhaps started up their own group (Well come to think of it quite a few have asked about the availability of introductory sessions). Anyway if anyone does want more they'll have to find someone to do it. Civil Defence put it in a nutshell when they say "You are civil defence" - the usergroup is YOU, you get out no more than you put in, no one is paid for their time.} That's about all I've got to say. You can count on me writing again in several weeks time, when my brain becomes full again. {From a later letter} : Workbench 1.4 sounds like a giant leap in the right direction. Commodore seems to have got over its terrible mistakes and is catching up quickly with the Macintosh (The PC was left for dead years ago!). {What is it about a Macintosh that you think is better? -ed.} A Mega Amigas No doubt this will be month-old news by the time this reaches you, but I have read recently that Commodore have shipped a million Amigas. This compares with 2 million Macs, and about 17 million PCs, so the Amiga seems to be gaining a considerable inroads into the market, given its relative youth. {Trouble is that most of those Amigas are Amiga500s - which are perceived as a games machine, so it doesn't actually help when it comes to persuading people to put out more software for the Amiga. -ed.} Amiga Arcnet ? What is this ARCNET that the A560/2060 cards will provide? Will it allow people to connect up their Amigas in the same way as Acorn computers, or will it not be that simple? Will it allow Macs or PCs to be connected into the network as well? {Arcnet is just a type of network interface hardware, allowing the machine to be connected to other machines with similar cards. It depends upon the type of software you use to drive it as to what it's used for (eg whether the machines directly talk to each other, or all just share diskdrives, printers etc connected to a central 'server' machine. The Novel software they mention would allow you to connect to a FileServer running Novell Netware. Such a file server usually contains a large hard disk, and shareable printers. Novel software is available on a large number of machines including IBM-PCs, Macs, and MicroVAXs, so you could presumably connect it to a network containing a variety of machines. Commodore (NZ) would probably like to point out at this point that those products aren't actually available just yet ...- ed.} HyperCard ? Is anything else known about the Hypercard clones? In particular, will they be more-or-less exact copies, exact copies but with Amiga-specific features, or entirely different beasts which have been labelled HyperCard-clones for want of a better description? More to the point, will they exchange stacks with the Mac version (I would consider this the most important factor in deciding whether to buy the program)? Are any prices available yet?  Page 20 September & October 1989 Newsletter! CHOOSING YOUR NEXT LANGUAGE As Simple as Kicking a Tyre from the March 1987, "The C Users' Group Newsletter", p53. With such a large selection of programming languages, it can be difficult to get to know them well enough to choose one for a particular project. Most people, however, have a fairly good idea of how various automobiles compare. So, in order to assist those trying to choose a language, we have prepared a chart that matches programming languages with comparable automobiles. __________________________________________________________________ Daniel Salomon & David Rosenblueth, Department of Computer Science, University of Waterloo, Ontario, Canada N2L 3G1 __________________________________________________________________ Assembler A Formula I race car. Very fast, but difficult to drive and expensive to maintain. FORTRAN II A Model T Ford. Once it was king of the road. FORTRAN IV A Model A Ford. FORTRAN 77 A six-cylinder Ford Fairline with standard transmission and no seat belts. COBOL A delivery van. It's bulky and ugly, but it does the work. BASIC A second-hand Rambler with a rebuilt engine and patched upholstery. Your dad bought it for you to learn to drive. You'll ditch the car as soon as you can afford a new one. PL/I A Cadillac convertible with automatic transmission, a two-tone paint job, white-wall tires, chrome exhaust pipes, and fuzzy dice hanging in the windshield. C A black Firebird, the all-macho car. Comes with optional seat belts (lint) and optional fuzz buster (escape to assembler). ALGOL 60 An Austin Mini. Boy, that's a small car! Pascal A Volkswagen Beetle. It's small but sturdy. Was once popular with intellectuals. Modula II A Volkswagen Rabbit with a trailer hitch.  Page 21 September & October 1989 Newsletter! ALGOL 68 An Aston Martin. An impressive car, but not just anyone can drive it. LISP An electric car. It's simple but slow. Seat belts are not available. PROLOG A prototype concept-car. LUCID Abolish cars and install moving sidewalks through the city. (LUCID is a dataflow language.) SmallTalk Put all the buildings on wheels and move them around the city. Maple/MCSYMA All-terrain vehicles. Will operate on the road (integer and floating-point numbers), off the road (rational numbers), and in the swamp (symbolic expressions). FORTH A go-cart. LOGO A kiddie's replica of a Rolls Royce. Comes with a real engine and a working horn. APL A double-decker bus. It takes rows and columns of passengers to the same place all at the same time. But, it drives only in reverse gear, and is instrumented in Greek. Ada An army-green Mercedes-Benz staff car. Power steering, power brakes and automatic transmission are all standard. No other colours or options are available. If it's good enough for the generals, it's good enough for you. Manufacturing delays due to difficulties reading the design specifications are starting to clear up. Has trouble getting up- to-speed due to all the armour plating.  Page 22 September & October 1989 Newsletter! ARE YOU A REAL PROGRAMMER? [from Bits & Bytes magazine] 1) Which of the following beverages do you prefer? a) Wine c) Beer b) Jack Daniels d) Coke 2) How would you prefer to spend a leisurely Sunday afternoon? a) Watching rugby c) Playing trivial pursuit b) Going to the zoo d) Testing batteries 3) What is your favourite scent? a) Yves st laurent opium c) Old spice b) Oscar de la renta d) Pizza 4) What do you like to wear as casual attire? a) Sports coat, open shirt c) Jeans, sweater b) La coste shirt d) Anything with a T-shirt 5) What is your favourite food? a) Tournedos henri iv c) Hamburger b) Coq au vin d) Coffee 6) What is your favourite non-computer magazine? a) Metro c) Playboy b) Time d) Batman 7) What is your favourite scene in a movie or TV show? a) Hamlet's soliloquy b) James Cagney "I'm on top of the world ma !" scene in White Heat c) scene at end of Dirty Harry where Clint Eastwood says "you've got to ask yourself 'do I feel lucky?' ... well do you punk ?" d) Spock's mind meld with a rock creature called Horta "The pain The pain!!" 8) Who is your favourite actor? a) John Gielgud c) Bruce Willis b) Rod Steiger d) Barney Rubble 9) Who is your favourite actress? a) Ingrid Bergman c) Joan Collins b) Meryl Streep d) Barbi Benton 10)What is your favourite all time movie? a) Ben-hur c) Star Wars b) A passage to india d) Fritz the cat 11)How do you think others perceive you? a) As a person of taste and intelligence b) As an urban professional c) As a potential sex symbol if it weren't for your physique d) As gods gift to the 20th century, and rightly so  Page 23 September & October 1989 Newsletter! ARTICLES Perfect Sound Digitiser and AudioMaster II from John Olsen As some readers will be aware, the Audiomaster software is sold on its own without a digitiser. This is potentially useful to people wishing to construct their own hardware and not wishing to write the software. (personally I find Hardware easier, you can debug it by tracing the little trails of smoke...) However, this may lead to people using the software with incompatible hardware. I recently had the opportunity to try the combination of Audiomaster II and the PS (PerfectSound) Digitiser, using an oscilloscope to look at the control signals on the parallel port, and was at first quite mystified by the waveforms obtained. To check out my suspicions I compared with the signals obtained using the Perfect Sound software. These are quite different. What I found was that if you use the PS digitiser with AudioMaster on stereo you will get samples only from one channel. Thus the two samples will be effectively identical. (The samples will have been taken one after the other, not simultaneously, so they won't be quite identical, but they won't be stereo either.) The AudioMaster signals seem to be intended for a digitiser with two A/D converters which sample each channel at the same time, and are then rapidly transferred to the computer in the interval between samples. This has the advantage that the samples are synchronous, not interleaved as would be the case with PS, which uses one A/D switched between channels. Obviously the reason I was poking around is that I am looking at constructing a digitiser of my own design, probably to go with the AudioMaster software. However I thought this information might be of interest to users of the products mentioned, particularly since the Audiomaster manual does not mention any problem with the PS digitiser. Incidentally no criticism of either product is intended, they both work well in their own environment, they just don't seem to be compatible with each other in stereo. (They work together OK in mono ) The main reason for these notes is that the Audiomaster software manual is remarkably reticent about mentioning names of digitisers, suitable or otherwise. I would have thought they could have provided a list of compatible hardware. Obviously there is more than one way of using the port, and so I suggest that potential buyers of combinations from different manufacturers should try them out fully before purchase. You should digitise in stereo mode, but with signal connected in turn to right only and left only. The signal on the screen display should appear as appropriate on one channel and then the other. With the combination you will get signal on both channels at once for one input and then no signal for the other.  Page 24 September & October 1989 Newsletter! Four Player Gauntlet from John Olsen (Wellington) Players of Gauntlet will be aware that an interface is available to enable the use of two more joysticks, which uses the printer port. This turns out to be quite a simple device. (I haven't seen one, I just had a play with the port while the game was running.) For those who would like one, and are competent to build it, here are the details. (If you can't understand the instructions you are not competent to build it. If you blow up your Amiga trying to make it go, you obviously were not competent. The writer offers no guarantee and will accept no responsibility for any damage to your Amiga.) I understand that details of an equivalent device are already circulating in the public domain. You will need the following:- Number Description 1 25 pin male D connector (not Insulation displacement) 1 Back Shell for above 2 9 pin male D connectors (not Insulation Displacement) 4 3mm countersunk screws Small hook up wire Construction 1. Make two holes for the D connectors to mount inside one half of the shell. These should be as close together and as far from the 25 pin connector as possible. You may need to cut away part of the front 9 pin socket or part of the shell to do this. Check with your joystick plugs in the sockets to find the minimum spacing. This is vital for A500 owners as the infamous overhang on the back of the machine will foul the joystick plug if you get this wrong. I had to modify one of my joystick plugs as I hadn't realised this till the job was done. Owners of other models should check if anything is likely to cause problems. 2. For A500 owners, the shell with the connectors will be the top half. Owners of other machines should decide which half should have the connectors, as I am not familiar with their layout. Remember the joystick plugs are quite long normally, which could foul other devices. 3. Wire the pins as per the table below. Note that the names given to the pins are as per A500. I believe the power (5 Volts) is on a different pin on the A1000. CHECK this in your manual. Note that the connectors normally have very tiny numbers on them so you can tell which pin is which. You need good eyesight to work in electronics!  Page 25 September & October 1989 Newsletter! Port Pin Joystick3 Joystick4 A500 Name Joystick Function 2 1 D0 Up 3 2 D1 Down 4 3 D2 Left 5 4 D3 Right 6 1 D4 Up 7 2 D5 Down 8 3 D6 Left 9 4 D7 Right 11 6 Busy Fire 13 6 Sel Fire 14 7 7 5 Volt Power 5 Volt Power 17-25 8 8 GND Ground Notes. 1. Pins not mentioned are not connected. 2. Pin 14 has 2 wires connected, one for each joystick. 3. The ground from the joystick can go to any of the pins 17 to 25. You can use a separate pin for each joystick socket and leave the other 6 unconnected. 4. Take extra care that you do not short the power as this can damage your Amiga. 5. Joysticks need 5 Volt power if they have an autofire mode. When all the connections are made, assemble the shell, checking as you do so that none of the pins on the sockets foul each other, which could cause a short. Try to keep your wiring tidy as this helps in assembly. Check with a multimeter that there are no shorts once everything is together. Assuming all is well, or has been corrected, plug into the Port, plug in two joysticks, boot up Gauntlet, and try it out. CORRECTIONS Kickstart 1.2 & 1.3 co-resident Andrew McDonald points out that the note in the last newsletter, about switching between AmigaDOS 1.2 and 1.3 ROMs isn't correct. The following works properly : o----o-------- +5v (pin 21 ROM) | | single | | | pole | |_| 10k switch | | O-------+----o-------- ~RomEn (pin 12 V1.2 ROM) | ~RomEn ------O | | (GARY) \ |_| 10k \ | O-------o------------- ~RomEn (pin 12 V1.3 ROM)  Page 26 September & October 1989 Newsletter! REVIEWS M2Sprint Modula-2 from M2S, Texas by John Matthews (Wellington) M2Sprint is more than just a Modula 2 compiler, it is a professional development environment, designed to enhance productivity and fit easily with the Amiga, and other developer tools available, such as ARexx and ARP. M2Sprint comes in several parts, which should be familiar from other systems around. M2E - The Editor. With other text editors available for the Amiga, such as TxEd+, CygnusEd and a wide variety of public domain programs, why force the user into learning a new one ? Well, they don't. Use of this editor is purely optional, but provides so many benefits, and is so easy to use it is a pleasure. M2E provides everything from automatic indentation to case correction and word completion from user definable libraries. Plus, you can call the Compiler and Linker directly with single keypresses, adjust their settings from menus, and save your own default settings. Multiple windows and the ability to be made resident, as well as being just left running in the background increase M2E's usefulness. M2C - The Compiler. As of release 1.11, the M2Sprint compiler is a VERY FAST single pass version, based upon Wirth's latest 'suggestions', with a few enhancements for both the 68000 family, and the Amiga itself. One of my favourites is the INLINE statement, specially designed for interfacing with Amiga libraries. Unlike other compilers, with M2Sprint the INLINE statement can go either in Definition or Implementation modules - that is, either with the specification or code of a module. By placing INLINE statements in the definition module for a library interface and using a compiler option, you don't have to supply a code module, thus giving faster compilation and linking. INLINE statements cause the compiler to place the arguments directly into the correct registers instead of on the stack, thus giving very fast library interfacing. M2C is a very good compiler, one of the new generation creating code comparable with C. As an example consider long integer multiplication and division, 32 bits that is. The 68000 cannot perform these operations, so they must be executed as subroutines, which are generally a few hundred bytes each. M2C knows these routines are best avoided, as they are comparatively slow, so operations involving powers of 2 are converted to arithmetic shift operations. M2L - The Linker. The easiest part of a Modula 2 package, this linker is blindingly fast, limited only by disk speed, it is amazing to watch from ram disks.  Page 27 September & October 1989 Newsletter! Also included in the package are several utilities - M2Prof A code profiler, analyses the time spent in all procedures of a program. M2Batch Generates a Batch Compilation file by analyzing intermodule dependencies. IFF2OBJ Creates a files which can be linked into a program, containing image structures automatically placed Chip Ram at run time. M2Debug A postmortem debugger. By IMPORTing the Debug module, when a crash, or intentional crash (but not the Guru visits it cannot foresee) occurs, you can investigate all variables, the procedure call chain, and the point in the source code where the error occurred, all in separate windows. A very useful feature. After a HALT instruction, and a session in the debugger, you can let your program continue until another HALT or a actual error occurs. The libraries, both Modula 2 and interfaces to the Amiga libraries and devices, also for ARP (version 1.3) and ARexx, are very complete, and very useful. One in particular - SingleCharDOS, FAST double buffered single character input - is so useful the compiler and linker use it for a 30% speed increase over the previous release. With all of these come the full source, and very complete documentation. Having the source code is very useful for minor modifications- if you're careful - and customizations. For instance, the are several versions of the RunTime environment, one stripped down for minimum size - the only one without automatic WorkBench support- ones with ARP support, ones with real support. With the source code, you can actually change these, for instance to replace the long integer routines with the single instruction required for 68020 and 68030 machines, and it is even possible to change the real support to use math chips directly. M2E and M2L can both act as ARexx servers, giving M2E Macro facilities, and allowing access to M2L from other editors. M2C is supposed to have an ARexx server mode, but as yet this does not work, contrary to documentation. Overall the system is very good. It is produced by experts not just in software development systems, but also very competent Amiga developers. M2Sprint will work on any system, under just about any level of hardware/software customisation, providing an environment allowing the rapid development of even large projects.  Page 28 September & October 1989 Newsletter! M2S also provide excellent support, if you're an American. Like many companies nowadays, they provide their major support via Bix, the great American bulletin board. If you really need a response, try phoning them, I got no response to my letter. Mind you, most of my suggestions had been implemented in the new release which I received an order form for - at US$35 - two weeks after the package arrived. This brings up another point: If you order M2Sprint, make it clear you want it AIRMAIL, and will pay the extra. Otherwise, and maybe even then, it will take 11 weeks to arrive via surface mail. M2S promise frequent - every six months at least - optional upgrades. They are already planning another release for November. This upgrade - version 2.0 so it's a major one, and will be priced accordingly, when they decide - will include a Multi-Pass compiler, probably for optimising code developed under the faster, single pass compiler. Also there will be a Source Level Debugger. Minor upgrades may be so minor that M2S won't tell you. They're up to version 1.12 now, which has a few enhancements - Nil dereference checking, the M2C compiler ARexx port now works, there's a new keyword - HANDLER(), if anyone knows what it does, let me know- and other little things. It also hints, via disabled options in the Editor, M2E, that future versions (2.0 probably) will support 68020/68881 code generation. I got version 1.12 from a friend who just bought M2Sprint, but it is not a big enough change for them to let me know. This Modula 2 system provides a very user friendly alternative to C, being almost as powerful, and in many cases much more so. Modula is easier to read, modify and learn, and in this case almost as fast. Inability to link with the standard linkers though makes it unsuitable for writing device drivers and libraries, which appear to need a certain structure for the system to use them. But if you are of the few capable of that complexity, you probably know C already, or can use it if you have to. I prefer Modula 2 for ease of development, and speed of debugging. {I too have bought M2Sprint, and have actually used it for writing a program, whereas I have owned a copy of TDI Modula-II for some time, and never actually written a program using it! The main reason I never got stuck into TDI is time - not enough of it! With M2Sprint I could load up the editor, write something, compile, link, run, all from the editor, all in a matter of minutes. One gotcha for the unwary - as delivered it defaulted to linking in a stripped down runtime library that doesn't support floating point arithmetic, which caused my program to GURU. I must protest that this is the wrong default - the system should default to supporting all the standard Modula-II features, but it defaults to having all runtime checking turned off, and a stripped down library. Two other complaints at this stage are that it limits arrays to a maximum of 32k bytes of storage, and turning on runtime checking causes things to crash (CHK instruction without a CHK handler!). -ed.}  Page 29 September & October 1989 Newsletter! INTERLACE & FLICKER FIXERS What is Interlace and Why Doth it Flicker so? by AJW Most television or computer screens create a picture by scanning an electron beam in a zigzag pattern down a screen coated with phosphor (only the zigs are visible the zags are blanked out [called horizontal blanking]). As it scans, the electron beam is turned on to make the phosphor coating glow, or off to leave it dark (on a colour screen there are three different coloured phoshors, and three electron guns). The phosphor glows very brightly as the electrons hit it, and fades away until the electron beam comes past again. So the whole image is fading away as you watch it. The persistence of the phosphor, and your persistence of vision combine to let you perceive a complete image. Your persistence of vision (ie the slow reaction times of your biological cameras) means you perceive changes faster than about 40 times a second as continuous (eg a light flashing 40 times a second will be seen as a steady light [but at reduced brightness]). At slower rates you see a continuous image that seems to flicker, slower still and you will notice the individual on/off pulses. In NZ, television displays are redrawn at a rate of 50Hz (50 times a second) to be above that critical 40Hz flicker frequency. The exact point at which you notice flickering of the image depends on its brightness and contrast. Due to technological/cost constraints at the time of definition of the standard (the TV standard is over 40 years old) they cheated and only refreshed half of the screen every 50th of a second (every other line), meaning the whole image is in fact only refreshed every 25th of a second. This technique called interlacing is created by displaying two pictures (fields) one after the other, the second is displayed 'overtop' of the first but offset by half a line so as to fill between the lines of the first. I say 'overtop' but in reality the complete image really only exists in the eye of the beholder! They got away with interlaced displays for three reasons, the cruder phosphors used on the early black and white TVs were rather slow (long persistence), the bandwidth of the TV system means you can't successfully transmit high contrast images (or saturated colours), TV images tend to be of moving objects, and the received quality of the image usually means flicker is the least of your problems! Occasionally on TV you see a picture of a high contrast stationary image (like a black and white score board) and flicker is very evident! So flicker is a problem of the TV standard that the Amiga conforms to (which allows it to be used with home TV sets as monitors, and makes it perfect (??) for video applications. Two traditional ways to reduce flicker are, turn down the brightness and contrast and watch it in the dark, use a smoky filter to slightly blur and reduce the contrast of the image, use a monitor with long persistence phosphors. Most computers that are compatible with the TV standard avoid the flicker problem by not interlacing two successive images, instead they use only half the available lines and update the whole screen at 50Hz - eg the Amigas 320x256 and 640x256 modes. The Amiga also gives you the option of creating an interlaced image, giving twice the vertical resolution (512 lines), and making it compatible with TVs,  Page 30 September & October 1989 Newsletter! videos, and TV cameras. Essentially a flicker fixer eliminates 'interlace flicker' by buffering the two interlaced fields and displaying the entire picture at a high refresh rate. I'm not sure exactly what the Microway flickerFixer contains, but the easiest method of doing the job (but maybe not the cheapest) is to have two banks of memory each of which can contain an entire 640x512x 16 colour, or 320x512x 4096 colour picture (or bigger for overscan). The first bank is being continually displayed at a high refresh rate (ie much greater than 40Hz), while the second is receiving an updated image (takes one 25th of a second to receive both interlaced fields). The buffers are then swapped so the second image is displayed while the other is being refreshed. The only problem with this is that you're only shown changes to the screen every 25th of a second, which is noticeable as a delay when watching animations, or with sprite movement (eg slightly jumpy mouse pointer movement) (these problems are evident with the Microway flickerFixer). To avoid these problems it would be better to manage four buffers, each for one field of the display (the same total memory as before). You then display the two most recently updated fields as one screen. This would eliminate most of the display lag. (In fact you only need three field buffers). To avoid any possibility of the display lagging behind, you could either get cunning by using a field buffer with an additional single line buffer and tricky address switching!, or use dual ported memory (expensive). Commodore Flicker Fixer There has been a dramatic price reduction in flicker fixers with the introduction of a flicker fixer direct from Commodore, this is available in New Zealand for about $500, around one third the price the Microway flickerFixer was going for here. I had a chance to play with their flicker fixer when one was made available to Wellington Polytech for evaluation purposes. The board is easy to install, just plug it into the Amiga2000 video slot. It is transparent to software, and you can use your standard monitor at the same time if you wish. You can use a genlock on your Amiga at the same time, but will experience some display problems unless you leave the multisync monitor turned off until the Amiga has started up. It can drive either a VGA type monitor or a multisync monitor. The advantage of using a multisync monitor is that it can double as a standard monitor on the few occasions you don't want to use the flicker fixer output (eg when watching animations etc). If you want the Amiga display to take up the whole screen you may have to adjust the monitor, some are not very adjustable. Commodore can supply and/or recommend a suitable monitor. The good news in this respect is that the monitor can accommodate the largest overscan screen your Amiga can generate. I have seen a comment that it can't handle vertical overscan, you get a maximum of 510 lines, but I haven't verified this. You can use interlace in one of two ways, either redisplay the same information on every second line, or use it to double the vertical resolution. In the first case you eliminate any gaps between scan lines, so things like characters on the screen are better formed, and don't look quite so chunky - aesthetically  Page 31 September & October 1989 Newsletter! pleasing. The second case is much more interesting - you double the vertical resolution, allowing you to have say 60 lines of text on the screen at once - a full printed page! (of course the characters are smaller, but VGA/Multisync monitors are usually high resolution devices so the characters are quite clear). This doubled resolution is almost essential when trying to use desktop publishing or CAD packages. In programs like Professional Page, you really need that extra resolution to view things at low magnification levels. The recent advent of the AMax Macintosh emulator produces yet another need for the flicker fixer, with it installed you can have a full sized Mac screen displayed without your eyeballs falling out. Multisync monitors aren't cheap, the better ones like the NEC multisync are very expensive (~$1800), but you can get cheaper models, eg some reasonable TVM ones can be bought for about $1100. And with VGA monitors becoming popular on IBM-PC clones, their price is relatively reasonable ($1000). The advent of a cheap flicker fixer means Commodore can really push the Amiga in markets like Desktop publishing and CAD, I really hope that Commodore and its dealers will recommend the addition of a flicker fixer and multisync monitor for all serious applications, they could bundle a flicker fixer and multisync monitor together for around $1500, perhaps $1800, if they went for a moderately priced monitor. And remember you would save about half that by not buying the standard monitor. One thing that might occur to someone, is that they won't need a flicker fixer when the new chipset is finally released (one of the new mode will be 640x480x 4 colours, non interlaced), but the flicker fixer will still have an advantage - it will be able to do 640x512x 16 colours, and interlaced HAM pictures, all without flicker, so it'll still be an enhancement. In summary, the best recommendation I can give for this device, is that if I were to buy an Amiga2000, I wouldn't buy an 1084 monitor, I'd get a flicker fixer and a multisync monitor. In fact, crazy as it may sound, I intend to buy one anyway (even though I've got an Amiga1000 which doesn't have a slot for one) - just so I can show Amiga2000s off to their best ability at every opportunity! --------------------------- Since writing the above, I have read an article on MegaDisc #13, that talks about interlace jitter - it attributes the flickering to the imprecise redrawing of scan lines across the screen, where lines are not drawn in exactly the same place each frame, and therefore appear to jitter up and down. I have consulted a couple of people about this, and the consensus is that, that sort of jitter shouldn't be present in a decent video system, and you should be correctable by adjustment of the monitor vertical sync etc. The real jittering of lines up and down that appears as flicker is due to seeing one field after the other displaced by half a scan line, so things appear to be rapidly jumping up and down by that much. eg if you have a monitor displaying a solid white screen, your eyes will first see the first field of white lines with gaps between, then white lines and gaps swapping places during the next field - so the whole screen appears to be 'jittering' up and down at 25Hz.  Page 32 September & October 1989 Newsletter! C PROGRAMMING SECTION by JJB TEMPLAR - Contents. Thingie #4 for the C programming section (0,1,2,3,...) Problems, solutions, or contributions on disk or paper can be directed to: John Bickers, 214 Rata St, Naenae. PH: (04) 672-085. Note that you can get from item to item within the main files by searching on the string ">>". And if you've got problems with programs in this section, feel free to ring! At least one person thought some of these programs didn't terminate. All mine do, but it may be a bit obscure how. So ring! Or read the documentation. That's what it's for. Hints&Tips: 1) Strings. 2) ___fpinit as a stub function. Problems: 1) Amiga.lib. 2) The DOS library jump table. Projects: {not printed here, see complete section on ND #25} 1) Ty1.3 2) Text display programs. Topics: 1) Resident/Re-entrant programs.  Page 33 September & October 1989 Newsletter! C PROGRAMMING SECTION - Hints & Tips. (1) Strings. (2) ___fpinit as a stub function. >> 1 Strings. Something to be aware of: the ANSI standard defines that if two strings are adjacent in the source file, they should be concatenated. For example: char *string = "1st part of string" " - followed by 2nd part.\n"; is equivalent to saying: char *string = "1st part of string - followed by 2nd part.\n"; I noticed this in an old list of the proposed ANSI standard in BYTE, tried it out with Lattice, and presto! This is most useful when using the compiler defined strings __DATE__, __TIME__, etc. For example: char version[] = "1st NZAmigaUG (Wgtn) Ty v1.3 - "__DATE__; is a very easy way to get the date automatically put into a string that can be used without run-time modifications. >> 2 ___fpinit as a stub function. This relates to the discussion of program size optimization in CSection3. Note that it is quite safe to define, say: DEFINE _MemCleanup=___fpinit instead of: DEFINE _MemCleanup=_tstub ; or whatever as long as you aren't using floating point in your program. This can save the few extra bytes of a specific stub function. And since ___fpinit is itself a stub function, it is redundant to say: DEFINE ___fpinit=_tstub to try and save a few bytes. In fact, you add a few bytes of ALV stuff for ___fpinit calls to get to _tstub.  Page 34 September & October 1989 Newsletter! C PROGRAMMING SECTION - Problems. (1) Amiga.lib. (2) The DOS library jump table. >> 1 Amiga.lib. While making programs resident, you may notice that stuff from amiga.lib gets dragged into your program despite your #including the proper proto files. The reason for this is probably that the #pragma definition for some function has been commented out of the proto file, because the function requires more than the 4 args Lattice can currently handle for #pragma definitions. To track down the erring module (you DO have a LOT of modules of source code, don't you?), try dumpobjing all your object modules to a file, and reading through that to find a reference to a function name in amiga.lib. These will have been replaced by direct calls if the #pragma is there for that function. To remove the amiga.lib stuff, there are at least two courses of action: 1) Write your own binding function in assembler to call the ROM function. This is precisely what amiga.lib does, but the advantage of writing your own is you can make use of Lattice conventions regarding __MERGED data (offset to (a4)). The code in amiga.lib does not make use of this, but references the library pointer (and perhaps anything else it needs) via absolute addressing. This can "potentially" stuff up resident code. 2) Write your own function to do whatever it is. The advantage of this is that you don't have to write any assembler code. The assembler is very easy, but you have to be careful with stack offsets for arguments. In my case, I had to replace ModifyProp. This was just a case of setting the PropInfo structure appropriately, then calling OnGadget(). >> 2 The DOS library jump table. Most of the system code for the Amiga is written in C, or in C-oriented assembler. The DOS functions (the process level stuff) are written in BCPL. All the system libraries are accessed via jump tables, so to call a system function you set up a pointer to its library, then jump to an offset from that pointer. The actual location you jump to generally contains an assembler instruction of the format: jmp $ The jmp is 32-bit absolute, which provides an excellent degree of address independence for the libraries. As far as I know, all the C/asm libraries (intuition, graphics, exec, etc) work like this.  Page 35 September & October 1989 Newsletter! The problem is that the twisted people who used BCPL do not use this method. Instead the instruction is something like: moveq #$nn,d0 bra nn Note, for example, that none of the DOS functions have an input argument in d0. Where the trouble occurs is that it is sometimes nice to intercept a library function. Exec provides a function for that purpose, that does the job in a system integrated fashion. This function is SetFunction, which does the following (I assume): Calling: oldfunc = SetFunction(LibBase,offset,func) Where: oldfunc =the old function that you're replacing LibBase =the library base, eg: IntuitionBase offset =the offset within the table func =the function you want to replace oldfunc with This function replaces the table entry with a "jmp func" instruction, and returns the address part of the previous entry. It expects to be working with a clean jmp. So if you use this function on the DOS library, the oldfunc value will be junk, as you'll actually get back the code for the bra instruction. The exact format for the branch instruction is: byte 1 byte 2 byte 3 byte 4 60 00 ?? ?? [bra][8-bit offset = 0][Had problem reading these] I thought this might be an illegal instruction, but I think using an offset of zero is how the 68000 knows the bra has a 16-bit offset in the next word, instead of being a single-word instruction. Anyway, using CodeProbe and a dummy prog, I was able to get the following info: >> The "jump vector" is in fact a moveq followed by a 16-bit branch, and many of the DOS "vectors" branch to the same place. >> DOSBase is at c04b38 (on my machine) Dest of branch is c04b86 (on my machine) Dest of branch is therefore DOSBase + 4e So to intercept a DOS function (that uses this destination, better to be safe and check for each function you want to intercept), the sequence is: >> save value to stuff into d0 before calling DOSBase + 4e >> insert your jmp func stuff >> when func is called, and you want to continue on to the oldfunc, you have to: >> move the proper value into d0 (again, check) >> jsr DOSBase + 4e If you understand the exact relationship between the PC and branch offsets, or you don't mind experimenting, you may want to calculate the appropriate offset from DOSBase at run-time.  Page 36 September & October 1989 Newsletter! C PROGRAMMING SECTION - Topics. (1) Resident/Reentrant programs. >> 1 Resident/Reentrant programs. This is a discussion of what resident/reentrant programs are. It is entirely my understanding of them, and thus may be completely wrong. I am aware that many people have very strange conceptions of reality when it comes to computers (eg: complaining that C doesn't have screen handling functions, or saying that using a report-generator is "real" programming), and I am no exception. Note that there are two other sorts of "resident" programs that I know of. On the Amiga, there are "Launch and Stay Resident (LSR)" programs, which are the cback type (eg: PopCLI, AskTask, Virus_Checker). On other machines there are "Terminate and Stay Resident (TSR)" programs, which are tricks to emulate multi-tasking, and therefore not useful on the Amiga. Some preliminaries: - A "residentable" program is one that can be made resident. - A program is made up of three sections. These are: 1) code: the actual running code, and sometimes constants. 2) data: initialized data (eg: int flag1 = 1;). 3) bss: uninitialized data (eg: int flag1;). These sections are made up of "hunks" of the appropriate type. While a hunk itself is contiguous in memory, a section is not necessarily so. - There are two ways to reference data and bss sections (in Lattice C programs): 1) as an offset to (a4). a4 points to the __MERGED data and bss sections of a program. That is, all the data and bss hunks are joined together into a large __MERGED section, and are referenced from the code section via a 16-bit offset to (a4). These hunks are "near". 2) as an absolute address. Some hunks are too large to fit into the __MERGED section, or must be in CHIP memory (eg: image data), so these are referenced by an absolute (32-bit) address. These hunks are known as "far".  Page 37 September & October 1989 Newsletter! Now on to the discussion... What is a residentable program? An ordinary program is run as follows: 1) load into memory 2) execute 3) unload from memory 4) to run it again, go to step (1). A residentable program is run as follows: 1) load into memory 2) execute 3) to run it again go to step (2). Resident programs are managed by "resident list handlers", which include: WShell, the CBM 1.3 shell, Sharp (ARP Shell), and WBRes. These programs make sure the memory-resident copy is used, and unload it when you want it unloaded. That is, a residentable program does NOT have to be re-loaded from disk (or wherever), in order to run again. It should be obvious to you that if a program uses initialized variable data, the first run of the program may have changed this variable value. So the second run of the program will be different. For example, suppose I had the following program: int flag = 0; void main() { if (!flag) { flag = 1; printf("Pass one!\n"); } else { printf("Pass two!\n"); } } The first run would set the flag variable, so the second run would not have the same result as the first run. This is patently undesirable. So it would seem that a program cannot use initialized data if it wants to be residentable. This is good news for a language like Modula-2, that doesn't formally allow initialized data(!). This is bad news to C programmers, since a lot of nice code is made a lot easier by using initialized variables. Not vital, but VERY convenient. To use initialized variables as well as be residentable, it is necessary to copy the initialized values to a separate area the code can use, for each invocation. This is made fairly easy by the (a4) convention. A startup module can create a new __MERGED section, copy the program's data section to it, then point a4 to the new __MERGED section. This effectively makes the original data section constant, so multiple runs of the same program have no effect on each other.  Page 38 September & October 1989 Newsletter! Initialized data was the main obstacle to residentable programs. The other is self-modifying code. This sort of code is severely frowned upon by most programmers, and is destined to break anyway on the generation of machines using the 68020 chip and higher. There are two types of "self-modifying code": 1) Code that modifies itself! Easy. 2) Constants that the program actually treats as variables. When you define a constant, it is placed into the "code" section of your program. So modifying that constant modifies the "code". Type (1) can be ignored. Lattice C doesn't generate that sort of code, and nobody should. Type (2) however does occur sometimes. The c.o startup module Lattice C provides apparently does this. It is sometimes of no significance, but should be watched out for. It is not significant (yet) if the constant is not initialized. Thus runs following the first are not dependent on the value left in the constant by preceding runs. This WILL become significant when the hardware and/or operating system care about self- modifying code for other reasons. So how do I make my Lattice C (v5) programs residentable? This is actually a doddle. There are a few requirements you must meet: 1) All initialized variables are "near". This is the default on the compiler, and you will only get "far" variables if you specifically declare them as such. 2) All "far" data references are constant. This is the case for image data (compiled with -ad to go into chip memory), for example. This is also the case for amiga.lib absolute references to library bases. 3) You link with cres.o instead of c.o. I used the above process on ty1.3, and get no complaints from WShell's "resi" command, or WShell's resident command usage (or WBRes :-). What is a reentrant program? A reentrant program is a residentable program that can run two or more invocations AT THE SAME TIME. The requirements (beyond those for a residentable program) are: 1) ALL variables must be "near". Since cres does not create copies of "far" variables, multiple invocations would actually use the same far variable, which is catastrophic. 2) There must be ABSOLUTELY NO self-modifying code (of either type). Again, since code is not copied either, at least one of the invocations would be derailed. Unless you want the value to be different for multiple invocations. For example, you could use constant variables as a sort of "shared memory" area to allow multiple invocations to communicate.  Page 39 September & October 1989 Newsletter! If these are met, cres.o is again the startup module to link with. And again, ty1.3 is reentrant with no complaints from WShell. Some notes about the bss section: This is the "uninitialized data" section. It costs very little in terms of program size to use bss hunks, since all they require in the program file is enough information to tell the loader their size, their desired location (if any, eg: CHIP or FAST), and any symbolic info required. The loader allocates a new bss section out of free RAM when the program is loaded. The startup module takes care of initializing the bss section to all zeros. Presumably cres takes care of allocating separate bss sections for multiple invocations of a program running at the same time. And finally, bss hunks are usually merged into the __MERGED data section for reference by the program. And finally: I was extremely impressed by the way Lattice handles this. Very nice indeed. What I had expected to be a "well, maybe..." job of turning ty into a resident AND re-entrant program turned out to be a matter of not quite an hour (tracking down which module dragged in some amiga.lib stuff). Note that ARP has some sort of resident startup code (or function) that does this sort of thing as well. I do not know the details (I don't have access to ARP 1.3 programmer docs), but those ARP fanatics amongst you may want to look into it. This is especially useful for non-Lattice people, who don't have the advantage of cres.o.  Page 40 September & October 1989 Newsletter! THE FLAKE REPORT Amiga Hardware Bugs and Fixes "Flaky" (July 15, 1989) Hacker's slang as meaning: 1. Erratic and/or unpredictable behaviour or experience 2. Sometimes it works; sometimes it don't 3. Primary cause of the following auditory spasms: a. "ARGH!!!!" b. "AH XXXX..." c. "#@&$!" d. "I need a career change; marketing!" Usage: "He's getting FLAKY..." Means: "RUN! HIDE!" A Bruce's Repair quote: "If it works; it won't." Ok folks, I'm compiling a list of what has caused flaky operation of the Amiga computers. This is a very unpopular subject with Amiga worshippers, but it should be one to pay particular attention since it can harm any product faster than obsolescence and DOES cause untold user-hours of frustrations. Flakiness affects everyone and everything from product development to end-users and especially service. If you can add some more to this list, you can give me a call at (415) 525-6973 and ask for Bruce. I'm busy most of the week so the best time is on Sundays in the morning. If you don't mind listening to a morning grouch call any other morning. In particular is a problem of poorly designed, slow-to-access RAM boards. This can be especially prominent with fast expansion devices like hard drives and frame grabbers. Number one on the list of bad boards are all those RAM boards with 150 nano-second RAMs. This is the time it takes the RAM to access valid data. The smaller this number the better. There are a lot of Amigas that need modifications. Starting with the A1000's, the daughter board needs to have its PAL chips wired together to the mother board ground and a wire to the expansion bus to the power supply ground connector. In worst cases, two of the PAL chips must be replaced with faster one's. The best source of PALs has been from Spirit Technologies. The A2000's needed to have the keyboard data and clock line capacitors removed. All the Eltek power supplies needed to be checked that a .01 MFD capacitor was installed across R65 to suppress noise and a "00" with a line through it written on the power supply label. The buffer chips U605 and U602 should be 74ALS245 and not the slower 74LS245. A 3300 ohm resistor should be installed between pin #20 and pin #11 on chip U605's address strobe. The Gary chip has been fixed to allow processor access to the KickRoms and expansion devices without needless co- processor contention. (The MOS Gary) The A500 especially needed a piece of cardboard placed behind the keyboard to prevent the keyboard from shorting to the mother board metal shielding. An authorized transistor kludge must be installed on all but the most recent A500's  Page 41 September & October 1989 Newsletter! to clean up a signal from the Gary chip. The biggest flake generator was and still is the metal shielding on the A500. The main metal shielding had a lip just behind the internal disk drive (i.e just left of the drive as you face the computer) which does cause shorts at the end of the drive ribbon cable. The solution is to bend the lip under the shielding or to put electrical tap over the edge of the lip. Much can be said about poorly written programs. We've all suffered as unpaid and unwilling "beta testers" from companies lacking in product quality. If it works on their machine, it does not necessarily mean that it will work on all Amigas because of hardware, software, update, and user differences. Sometimes they listen to the problems; sometimes they ignore or pacify us with promises, good-will, and just pure charm. Worst case is the buck passing. Badly written programs can go wild and corrupt our system and even ruin DOS file structures. It can be as subtle as corrupting a single bit, presently unused, to wiping out an entire system. Programs can at times work with no apparent trouble until it's discovered later in time. This can lead to blaming the wrong program or hardware as the cause of the problems. This will sound very cynical but don't believe ANY review or even this report of mine. (sigh..) Just take it with a grain of salt. Look over people's shoulders, get the dealers to demonstrate their wares, stop by a free-form users group and judge for yourself. Seek-out end-users of a product. Get to know the modem community of Amiga users. Report problems to the people responsible for the product if you think you've found a consistent problem. Unfortunately, flaky problems are not easily repeatable nor consistent, so it may be hard for them to justify their time to prove, find, and solve the problem beyond a symptom. Static electricity, even when we don't feel or hear the "tingle", can make computer chips flaky. Always touch the power supply case before even getting close to any circuit board or chip. In the situation of the A500, touch the internal disk drive case. A lot of damage has been caused by AGNUS chip installations. CBM has packaged the computer chips without anti-static material and the retailer many times have not Xeroxed the installation instructions for the customers. Topping the list of user burn-outs is improper cable connections or installation. If you can't bet your wallet, don't do it. I'd say a fair retailer AGNUS installation charge should be around $20-$25. Degrees of unfamiliarity with the equipment or the system can cause unpredictable results. I shudder at the thought of what I would do to my present system if I was a new user and not able to access all the books, documentation, experience, and lastly my fellow computists. An old problem with books, documentation, and advice is that a certain level of background knowledge is expected and assumptions about your system are made from all sides of communication. The learning process is a leap frogging of books, notes, magazines, practice, and many times just pure inquisitive hands-on hacking.  Page 42 September & October 1989 Newsletter!  Page 43 September & October 1989 Newsletter! Never assume a computer cable is correct just because it fits. There are unending variations of cables with the same connectors on the ends. Once you've found the purpose and correct cable, it's best to label the connector ends with where they go. It's always good to have a continuity checker and documentation of the pin assignments. The wrong cable can and does burnout computers. Worst case is if it becomes flaky. Ok, the following is are extracts from my notes and take it with a grain of salt for flavouring. Be careful, because it is in a raw state and reaching a conclusion from the notes will have to be tested for other machines. UNSKILLED AND UNKNOWLEDGEABLE ATTEMPTS AT REPAIR OR MAINTENANCE CAN BE EXTREMELY DANGEROUS AND SHOULD BE LEFT TO QUALIFIED TECHNICIANS ONLY. UNAUTHORIZED SERVICE VOIDS YOUR WARRANTY.  All monitors 1) Re-solder HV coil to main board 2) Clean off dust and oil 3) Check for burnt or heated spots 1084 monitor (very similar to 1902A) 1) Intermittents a) Cold solder joints and broken traces especially around daughter boards and HV coil and leads 2) VERY INTERMITTENT "snap!" of video; audibly noticeable. 1084S-Philips (very similar to 1902A) 1) Nothing a) bad R475 (15K 2w flame) damaged from bad C476 (.047uF, 250V) and T402. Between June 88 and Sept 88 require warranty repair. 1084S-P monitor repair kit PN# 314891-01 billed $44 and credited when T402 is returned to parts depot with NARDA form. 1902/2002 monitor 1) Fuse blower a) defective degaussing switch (TH501) b) defective voltage regulator STR30123 (IC501)  Page 44 September & October 1989 Newsletter! A500 1) no mouse movements a) replace burnt EMI401 (1.0 ohm 1/4 watt resistor) 2) flaky computer a) do the 2N3906 kludge b) check main computer shield shorting behind disk drive c) Check solder joints on power socket d) flaky internal disk drive power cord e) check for bent chip pins and for bent connector pins f) check keyboard assembly for flakes 3) Power Supply (PN 312503-05) a) pin1 +5V 4.5A b) pin2 shield gnd __ __ c) pin3 +12V 1A |3 \/4 | d) pin4 signal gnd | 5 | Looking into the plug end e) pin5 -12V .1A |2___1_| 4) Green Screen; 10 short 1 long power LED blink a) clean and re-insert Agnus chip 5) Flaky keyboard assembly with spurious characters or crash with CAPLOCK LED blink a) replace keyboard and tell customer of possibility of a serial device being connected to the parallel connector A1000 1) fast steady power LED blink; dark screen a) 74S51 (U9I) & 74F74 (U8I); Damaged from expansion port 2) no parallel output a) 8520 b) PAULA 3) Goes thru diagnostic blinks but no Kick icon a) Check for internal disk drive "track-zeroing" movement 4) Dead a) check that expansion shield fingers aren't bent to mother board 5) Check for bent connector pins 6) no serial a) check MC1488 & MC1489 b) check PAULA 7) Bad mouse or joy stick movements a) check 74LS157 b) check 8520's  Page 45 September & October 1989 Newsletter! A2000 (see also A500 & A1000 & A2500 for hints) 1) Red screen; power LED blinks 9 short 1 long continuously a) bad ram with open 2) Dark blank screen on power-up; LED dim a) BUSTER 3) System time erratic a) check for noise on TICK line; CBM modification to power supply 4) Bad mouse movements a) 8520 b) clean mouse c) broken wires in mouse cord d) bad 74LS157 (U202) 5) First character from keyboard missing after power-up a) cut out C910 & C911; CBM modification 6) Fuzzy video a) remove a turn from the ferrite beads on the RGB lines 7) White screen; no Workbench Icon; LED bright a) No power to PAULA; R200 (1 ohm resistor) burnt 8) intermittent guru's a) Bad contacts on BridgeBoard (card edge or chips or bus-timing) b) Virus use KV and Sentry program c) Bad program(s) d) Bad ram expansion board with flaky 150ns ram (should be 100ns); AMIGA 25000 (twenty-five thousand) 2MEG board is FLAKY e) use TestMem by Bruce's repair to find bad bits f) CHECK THE CLOCK SIGNALS with scope for proper voltage levels 9) No Red in RGB only (new unit) a) bad solder joint or bad trace under board at RGB connector A) Check for bent connector pins B) No Serial Port a) DTR always on 1) replace MC1488 &/| MC1489 2) bad U301 CIA 3) bad PAULA C) Modifications: a) Replace U602 and U605 (74LS245) with 74ALS245 Make sure that 74XX24(4|5)'s between Agnus & Ram are F types the symptoms include spots appearing on screen b) Cut-out C910 and C911 c) Put noise by-pass cap (.01ufd) on ElTek power supply TICK  Page 46 September & October 1989 Newsletter! line across R65. d) Check for proper usage of ferrite beads at video connector e) put 3300 ohm resistor between #20 & #11 of U605 f) Read TechTopics Issue #25 Section #3 (Apr-May-Jun 89) for details 1) remove R901, C917, C902, C910, C911, C905, C908, C230, C240 2) replace 1.2 KickRom with 1.3 or latest version 3) if U205 & U206 are 74HC244 install RP904, RP905, RP906 (4.7Kx5); if they are not DON'T install (eg 74HCT244) 4) add .01 UFD cap on J300 centre connector to ground pad 5) add 470 ohm resistor to D800 cathode to second pad from the left, under CN605. 4.3 rev boards and up have R1000 left of Q302 instead. 6) if R5719 installed, add 470 ohm resistor between VCC and CPU side of R106. 7) Replace ALL Gary chips (5719) with MOS type p.n. 318072- 01 8) Install new reset chip MITSUMI PST518B into ALL rev 6 boards (see TechTopics 25/3-3.1) D) Bad joy stick moves a) U202 (74LS157) E) Garbage from printer port a) bad U300 CIA A2500 (see also A2000 for hints) 1) Put 3.3k ohm pull-up resistors on pin 11, 12, 13, and 14 on U605 These are buffered AS, UDS, LDS, and R/W signals for the expansion A2XXX Power Supply 1) check diodes and all semiconductors with digital IC-safe ohmmeter 2) use variable transformer to bring AC voltage to operation 3) use 25ohm 10 watt resistor on 5v+ main to load for testing  Page 47 September & October 1989 Newsletter! Amiga Disk Drives 1) Clean with Q-tips and alcohol a) if heads are sticky when they touch each other, clean heads with "KESTER Rosin Residue Remover". 2) "TICK-TICK" (5 ticks/sec noise with spinning disk in drive) a) after cleaning head and spindle, try lightening the pressure of the head spring (problem especially with #? drives) {I thought that noise was caused by damaged disks - loose lining in the disk jacket etc - the problem is associated with particular disks, not disk drives (ie you move the disk to another machine and have the same problem). -ed} 3) Works fine when connected as an Amiga Drive but not when connected to a PC Bridgeboard. a) Replace the 74LS38 with a 7438 chip. 4) intermittent operation a) Broken wires in cable; check daughter board interconnects b) cracked magnetic glass switches c) Magnetic interference: rotate drive 90 degrees & recheck d) Motor spin erratic (on-off); re-solder motor board 1) for Matsushita Drives, surface mount chip located between the drive frame and motor board and behind the eject button has bad contact; wedge with spacer 5) Head "plays like a violin" on the disk a) clean head with rosin remover 6) If a cardboard drive protector is used, check drive head mounts and angles. Advise user of the danger of using head protectors from another drive and the possibility of damage to heads with worn protectors bending the head mount springs. 7) If dogs and cats are within fur range, blow into drive opening. Hard Drive Controllers 1) check voltages & cables 2) check bus buffer chips 3) check daughter board interconnects  Page 48 September & October 1989 Newsletter! A-Live Board (for A500) 1) With time (hours and moon phase) D#aint## will be missing pixels from its picture when loaded; reloading the same picture with D##### will eventually bring back all the missing pixels! This problem happens when the S#### Harddrive is connected between the A-Live and the A500. Other symptoms include the volume names to WorkBench Screen get corrupted but can be read with the INFO command without error! ) UNSOLVED MYSTERY!! a) Gary chip revision? (How do I get the latest version..) b) Power Supply voltage too low? Too high? c) Bus over-load? d) Needs bus termination? e) Needs F, ALS, or HC type chips buffering between video RAM & Agnus? AMIGA RAM BOARDS 1) A1000 Spirit board a) interconnects broken on Spirit Ram Board b) check for correct shorting blocks and wiring 2) Remove and replace 150NS boards with faster ones. 3) Use Bruce's TestMem to find bad chips Amiga Repair paths: A) Get customer to relate what activity was occurring before the onset of the problem. B) Colour of Screen and activity of LEDs 1) Dark screen LED dead or blinking quickly a) Check power supply and TICK line b) Check ALL clocks c) Check power on each individual chip Tips: 1) Bad RAM with an internal OPEN circuit can be checked by "piggy-backing" the ram chip with the same type of RAM 2) Bad RAM with an internal SHORT circuit can be hotter to the touch than the rest of the RAMs 3) Improper removal of chips from sockets with a screwdriver can cut circuit traces under the chip; always check under chips and for damaged socket connections. 5) For the A2000-A2500, put four 3.3K ohm pull up resistors on U605 (74ALS245) a) pin11 to pin20; pin12 to pin20; pin13 to pin20; pin14 to pin20 {An article called "Tips for Smooth Operation of the Amigas" by Nisbett & Takahashi was included in this document at this point, but it's almost identical to their original article published in our newsletter on NZAmigaUG#14. -ed.}  Page 49 September & October 1989 Newsletter! Screen colours and other boot things Amiga ROM startup self checking sequence: 1. Clear all chips of old data. 2. Disable DMA and interrupts during the test. 3. Clear the screen. 4. Check the hardware ...checks to see if 68000 is functioning. 5. Change screen colour. (Blue = BAD) (DarkGray = OK). 6. Do a checksum test on all ROMS. 7. Change screen colour (Red = BAD) (LightGray = OK). 8. Beginning of system startup. 9. Check RAM at $C00000, and move SYSBASE there if it exists 10. Test All CHIP RAM. 11. Change screen colour. (LED : 9short 1long | Green|BAD) 12. Check that software is coming in ok. 13. Change screen colour. (Yellow = BAD) 14. Setup CHIP RAM to receive data. 15. Link the libraries. 16. Check for additional memory and link it. 17. Turn the DMA and interrupts back on (for boot drive) 18. Start a default task. 19. Check for 68010, 68020, and or 68881. 20. Check to see if there is an exception ...processor error 21. If so do a system reset. During this system test the Amiga is sending vital information to the screen with colours. If the system checks out ok, you will see the following sequence : DARK GRAY: The initial hardware tested OK. the 68000 is running and the registers are readable. LIGHT GRAY: The software is coming in and seems OK. WHITE: The initialization test have passed. If something is wrong with your system, you may see the following : RED: If an error was found in ROMS. GREEN: Error found in the CHIP RAM. BLUE: Error was found in the custom chips. YELLOW: If 68000 found an error before the error trapping software (GURU) was running. The Keyboard has its own processor, RAM and ROM. A selftest is performed on power-up in the following sequence : 1. Performs checksum on ROMs 2. Checks 64 bytes of RAM. 3. The timer is tested. 4. Performs handshake with computer and gives results of selftest. If the keyboard does not pass the test it will notify you that it is not working properly. This information is indicated with the blinking of the CAPS-LOCK light : One Blink: Keyboard ROM check failed. Two Blinks: Keyboard RAM checked failed. Three Blinks: Watchdog timer failed Four Blinks: A short between two row lines or special control keys.  Page 50 September & October 1989 Newsletter! USER GROUP INFORMATION (New members please read) Subscriptions 1) Printed newsletter is $18 for 12 months, 2) Newsdisk subscription is $27 for 12 months (10 issues). 3) Levy of $10 for room hire on Wellington members if they attend local meetings. 3.5" Disks : Nashua disks are $2.30 each, blank or containing PD software. Include 20c extra per disk for postage and packing if you're buying less than 10 disks. Disk labels and postage are included if you buy 10 or more disks. Bulk price : $220 per box of 100. 3.5" plastic 'library cases' : each 'library' case holds 10 disks, available for $5.00 each. Amiga Hardware & Software : We can now get a range of Amiga peripheral hardware and software at reasonable prices, let us know what you're looking for. Newsdisks Newsdisks are an extension of the newsletter, and include things like pictures and programs that aren't accommodated as well on a printed medium. If you only read the newsletter and don't see the Newsdisks you are only seeing part of the whole. That's why our newsletter may not seem to include as much as many other computer groups "magazines". If you're doing anything interesting with your computer, exploring a new program, or fighting to get to grips with your machine, then tell us about it. Don't ask us whether we want an article on something, just write it! We prefer all submissions on disk, in any format, we will return all disks, but to facilitate this please mark any submissions clearly with your name. In case members are not sure about Newsdisks, then here is the story : We send Newsdisks to those members who have prepaid for a box of disks to be sent out one by one as newsdisks are produced, or to members who send in their own disks for us to copy onto (please add stamp or 40c for postage, and label disk with your name, and what you want returned on it). As with newsletters you are free to copy any part or all of its contents, and give away copies to anyone you like. (Selling them for more than a blank disk will be considered a criminal act!). You can also ask for Fish disks to be sent out as they arrive. We don't get other PD disks regularly, so don't generally offer to send them out automatically.  Page 51 September & October 1989 Newsletter! Public Domain Library We maintain a library of about 500 public domain disks, copies of which are available free, you supply the disks and postage or purchase blank disks from us. Start by getting a copy of the Public Domain Catalogue disk that lists the contents of the library. =============================================== Group Meetings and members looking for Amiga owners in their area If people wish to be added or removed from this list then let me know. If any details are wrong (especially phone numbers) then let me know. The following list is in geographic order (well sort of) so members can find others near to their area. These entries imply no association at all between this group and those listed. They're just others in your area interested in Amigas, who may or may not be members of this group. SOUTH ISLAND Invercargill, Contact Paul Heye, Phone (021)64-540. Southland Contact : Contact : John Wrigley, Southland Commodore Users Group, c/o 24 Marama Ave. North, R.D. 9, INVERCARGILL. Dunedin Group : The Dunedin Amiga Users Group meet at King's High School, Bayview Road, St Kilda, Dunedin on the first Wednesday of the month. Contact : Asheley Johnston, Phone (024) 55-785. Tuatapere, Contact Malcolm Garrett, Phone (0225) 6156 Te Anau, Contact Graeme McKenzie, Phone (0229) 7728 Amaru, Contact Roger Blackburn, Phone (0297) 47-540  Page 52 September & October 1989 Newsletter! Christchurch Amiga Users Group : Chch AUG meets 2nd Wednesday of each month at Shirley Boys High School, 7.30pm. Contact the secretary for exact details. Contact : Brian Curwood (Secretary), 9 Rowe Place, Shirley, Christchurch. Phone (03) 857-584 or Contact : Greg Evans Phone (03) 668-646 Work (03)229-412 Home Christchurch SIGs : Amiga programming SIG affiliated to CHCH AUG. Meet every Wednesday at the Christchurch Technical Institute, Rm A109, 7.00pm. Contact : Peter McIntyre, PO Box 22-361, CHRISTCHURCH. Phone (03) 892-345. Timaru, Contact Ron Bisset Phone (056) 88-480 or Contact : Owen Dunne, 8 High Street, Timaru. Phone (056) 83-440. WestLand Amiga Users Group : The Westland Amiga Users group has members from Haast to Greymouth, and meets on the first Tuesday of the month at 34 High Street, Greymouth. Contact : Keith Ross, 27 Nelson Street, Greymouth. Nelson Group : Nelson Amiga Users Group meets on the first Wednesday, and the third Thursday of the month, at 7:30pm, in the premises of Ruralcom Electronics Ltd. premises at 140 Tahunanui Drive, Nelson. The different nights are to try and please all the people all the time...... Contact : Gary Walker, Phone (054) 85-494 (after 5pm).  Page 53 September & October 1989 Newsletter! NORTH ISLAND Wellington Group : The next local Wellington group meeting is on Monday 27th November (the meeting following that will be on the 18th of December) at 7:30pm in the Upstairs lecture theatre, Royal Society Building, Turnbull Street, Thorndon, Wellington. If you want to pirate software, DON'T!. Contact : Tony Wills, 156-C Queens Drive, Lyall Bay, Wellington 3. Phone (04) 877-258. | ^ | v | | | | | | \ / | |\ \ / motorway south | | \ \ / off ramp | | \ \ / v / | | \ \/ / | \__/ / | ^ ____ | | / \ | | M | | v | | o | | | | l |______| |___________ | e ______ M HALLWELL | s | | u ___________ | w | | r | _____ | o | | p | |cars_| | r | | h |_____|^|*|Royal | t | | y Society | h | | TURNBULL | | | v ____________ | ^ | | | | | | | | | | | | | | | | ^ | | v | | | | | From Bunny Street Paraparaumu, Contact Kevin Dwen, Phone (058)70-542. Greytown, Contact Campbell Young, Phone (0553)49-546. Masterton, Contact Gerry Kluck, Phone (059)82-947.  Page 54 September & October 1989 Newsletter! Manawatu Group : Manawatu Amiga U.G. meet at 7pm, the last Tuesday each month, in the Bradfield Lecture room, Palmerston North Public Library Contact : Andrew Mercer 86 Long Melford Road, Palmerston North. Phone (063) 82-592. Bulls, Contact Bill Anderson, Phone (0652)49-066. Wanganui Group : General micro computer group, about 50% Amigas, meets on the second Tuesday of each month in the Old Library Building, Queens Park, at 7:30pm. New members and visitors always welcome. A specifically Amiga group now meets at a venue to be arranged, on the 1st Thursday of every month. Contact : Liam Greenwood, Phone (064) 55-610. or Carl Rasmusen, Phone (064)56-583. Hawkes Bay Group : The 'Bay Amiga Computer Club' meets on the first Wednesday of the month (except January) at 7:30pm, Wesley Lounge Conference Lounge, Hastings Street (opposite Municipal Theatre), Hastings. Mail to : P.O. Box 4060, Marewa, Napier. Napier, Contact Trevor Cook (President), Phone (070) 435-074 Havelock North, Contact Ross Deeley (Chief Archivist), Phone (070) 775-959 Waipukurau, Contact Nigel Jones, Phone (0728) 87-006 Pahiatua, Contact Roger Woods, Phone (0650) 23-835. Taranaki Group : Meets at 7:30pm on the fourth Monday of the month at the Foundation for the Blind club Rooms, 131 Vivian Street, New Plymouth. Contact : Mrs Noeline Wagner, 8 Cutfield Street, Inglewood. Phone (067) 68-874. South Taranaki : Meetings at the Eltham Primary School Library, Contact John Veldthuis, Phone (062-4) 8409. Turangi, Contact Robert Montgomery, Phone (0746) 7574 Taupo Contact : Contact : Lewis Klyen, 50 Invergarry Road, Taupo. Phone (074) 89-313 Rawene, Contact Robin Hoare, Phone (088) 7577 Tuakau, Contact Gary Sizemore, Phone (085) 68-054  Page 55 September & October 1989 Newsletter! Kawakawa, Contact Dennis Williams, Phone (0885) 37-954 Te Kuiti, Contact Brian Houston, Phone (081) 3374 or Contact Ewert Tearle, Phone (08133) 751 Rotorua, Contact (Mr) Menno Grondsma, Phone (073) 85-858 Kawerau, Contact Chris Rutter, Phone (076) 38-380 Tokoroa, Contact Rev. Arthur Bruce, Phone (0814) 67-565 Bay of Plenty, Contact Foster Sherburd, Phone (075) 420-199 Cambridge, Contact Andrew Cooke, Phone (071) 277-359 Hamilton Group : Meet 1st and 2nd Thursday of each month (except for January), in the Marist Hall Behind St. Marks, Grey Street, East Hamilton. Contact : Russell Christie, PO Box 176, Ngaruawahia. Phone (07124) 8595 Tauranga Group : Tauranga Amiga Users Group meets regularly, venue to be arranged. Contact : Richard Abba c/o 136 Levers Road TAURANGA Phone (075) 66-860 Waiheke Island, Contact Don Millner, Phone (09) 726-651 or Contact Terry Maguire, Phone (09) 728-590 Orewa, Contact Darrell Crane, Phone (0942) 41-550 Whangarei, Contact Jock Nisbet, Phone (089) 481-436 Northland, Contact Robin Hoare, Phone (0887)57-761 Auckland Group : The Auckland ,"Amiga New Zealand", group meetings are on the first Wednesday of each month, from 7:30pm to 10pm at the St Georges Presbyterian Church Hall, Corner of The Terrace and Anzac Road, Takapuna, Auckland. Contact : Brett Wakefield P.O. Box 89-026 Torbay,  Page 56