💾 Archived View for cugi.ie › newsletter › 1989dec.gmi captured on 2024-08-18 at 17:52:39. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
███████████ █ █ █ ████████████████
█ █ █ █ █ █ █
█ ████████ █ █ █ █ █ █████████████ █
█ █ █ █ █ █ █ █ █ █ █
█ █ █████ █ █ █ █ █ █ █ ██████████ █ █
█ █ █ █ █ █ █ █ █ █ █ █ █ █ █
█ █ █ █ █ █ █ █ █ █ █ █ █ █ █
█ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █
█ █ ███ █ █ ██ █ █ █ █ ████ █ █ █ █ █
█ █ █ █ █ █ █ █ █ █ █ █ █
█ ████ █ ████ █ █ ███████ █ █ █ █
█ █ █ █ █ █ █ █
█████ ██████ ██████████ █ █ █
Chairman's Review of the Year
A590 Hard Disk Reviewed
Amiga Graphics Programming
Virtual Floppies on the A590
Experiences of a Sysop
Chairman Geoffrey Reeves Treasurer Brian Ward Membership Secretary Shane Broadberry Chief Librarian Tom Kinsella Amiga Librarian Rocco Matassa PC Librarian Brain Ward C64 Librarian Steve Kemp C128 Librarian Geoffrey Reeves Communications Liam Murphy Newsletter Editor Eddy Carroll
CUGI Meetings are held every second Friday at 8:00 PM in the computer room at St. Andrew's College, Booterstown. All correspondance should be addressed to:
CUGI.
c/o St. Andrew's College.
Booterstown
Blackrock.
Co. Dublin.
Volume 2 Number 1
December 1989
Editorial Eddy Carroll 2 Review of 1988/89 Geoffrey Reeves 3 Commodore's A590 Hard Drive Declan NicArdle 6 Microcomputer Interfacing Part 3 John Pelan 8 DOS & That Brian Ward 12 Virtual Floppies on the A590 Eddy Carroll 18 Lost at 'C' Rocco Matassa 22 Experiences of a Sysop Marc Whisker 24 Writing for the CUGI Newsletter Eddy Carroll 27 Amiga Graphics Programming Shane Broadberry 28 Trials and Tribulations Stephen 34 Amiga Public Domain Releases Eddy Carroll 35 Utopia Stephen McGerty 37 Stephanie's problem Page Stephanie 38 Puzzle Page Rocco Matassa 40
Welcome once more to yet another issue of the Newsletter. Once again, I can report that this issue is bigger than ever before! Who would have thought that in just over a year, it would have grown from an 8 page pamphlet into the 40 page booklet you are currently reading? Certainly not me.
This is the second issue to be produced using Amiga TEX and it is coping with the task admirably. It seems that each issue will get a little easier; as time goes by, I am building up a file of useful macros which make it easier to obtain special effects. This issue, you get a real inch symbol for 3.5″ disks! (Previously, you had to be content with 3.5" disks.) You also get to see signal names as they appear on circuit diagrams (like RESET for example). Typography seems to bring out a pedantic streak in people (in me anyway) but hopefully the results are worth it.
This issue sees very little on the C64, I'm afraid. In fact, John Pelan's article on interfacing is the only one which has any relevance to the C64 at all. I know there are C64 owners out there, so how about a few articles!
On the other hand, there are a good number of Amiga articles, which seems to indicate that more and more members are having a go at programming it. It is not an easy route for those previously used to the C64; you have to learn C, and come to terms with the Amiga's hundreds of ROM functions (compared with the C64's 20 odd kernel calls). The reward is the ability to make your machine do anything your imagination can dream up - and in the meantime, you'll have a lot of fun getting there. As Geoff's report of the year mentions, CUGI is doing rather well financially at the moment with the result that a few books on C are being purchased. Those interested in dabbling could do worse than borrowing one for a fortnight and finding out what it's all about.
Since the A.G.M., Rocco has taken over the post of Amiga Librarian, which I have had to give up due to pressure of studies. Rocco tells me he has great plans afoot, so you should be seeing some changes soon.
Final note: This issue contains a brief writing guide for would-be authors who are thinking of submitting material to the Newsletter. It's not intended
to scare people off; if you haven't got the time to pay heed to all the details mentioned, that's okay (after all, I suppose that's the job of the editor) but it would be nice if you could keep them in mind. The deadline for articles for the next Newsletter is 16th February 1990.
That's it for now. Have a good Christmas, and a happy new decade!
E.C.
by Geoffrey J. Reeves
Having had such a successful year, I thought that it might be an idea to remind the membership of some of the events and highlights of the last year.
Having been involved with CUGI since it began back in the long distant past, I can say with assurance that this year was definitely the best. It is
not simply a case of pointing the finger or directing the credit to any one aspect of the group but rather to an overall growth.
Financially, our group is very healthy - each member who didn't make it to the A.G.M should have nevertheless got a copy of the accounts. If you
didn't, then remind us. In summary, we began the year with just under £250 in our current account (and a similar amount in a deposit account). By the end of year, this had risen to just under £500. During the year, about £2000 passed through our hands, the major payments being the purchase of disks (over £750), rent of the room and photcopying (£165) and the cost of obtaining about TO disks for our C128 library (£130 - ouch!). The future looks good because we should be getting in more funds (we raised this year's subscription) and we will not have to pay our fee to Compunet. This will allow us to expand the library - books are expensive - and to purchase some items of hardware to lend to the membership. By popular acclaim, we hope to get a (stereo) sound sampler in the near future, the idea of buying a Genlock having been put 'on hold' for the moment.
CUGI is currently worth about £2000 and has no liabilities. Our assets include over 500 P.D. disks, a couple of modems, a software library, a book
library, an Amiga disk drive, an EPROM programmer and 2 C64s (for spare parts only). You can borrow hardware items if you ask in advance sometimes another member may have what you require on loan already.
As you will have gathered, the library has grown dramatically in size and range over the last year. Strictly speaking, there is more than one
librarian these days to cover the different computers. We hope to produce a catalogue soon to make it easy for all of us to see what is actually in the
library but please, bear with us - there's a lot of it and it must be done properly. In the meantime, talk to Tom the librarian or write and we will
look after you.
No review of the year could omit the very item you are reading - the Newsletter! I recall vividly, the committee meeting which suggested its rebirth. "Just a Newsletter, i.e. 4 sides of A4 including the cover", we agreed. Well, just look at it now it has become an excellent production supported by many of the members - this is not a committee newsletter for the members, by the members and all that. Do keep supporting it; send articles, reviews, puzzles, jokes, anything at all. Make them short, long, whatever ... but do contribute. For goodness sake, why not even write a letter to the Newsletter and we can start a Letters Page?
The Newsletter is, of course, one of the ways that we keep in touch with our Associate Members and we hope that despite the fact they they cannot
attend meetings, they avail of all our services. There has been some 'hitches' in the past but I think that this year, we have got a fast and efficient service in operation. If we haven't, YELL! In case you are wondering what happens when you write and don't always get a speedy reply, I better tell you how it works in practice. All enquiries end up in my cubby hole in St. Andrew's and are passed on at the next meeting (committee or general). If you are
very unlucky, this might not be for the best part of a week. However, this is hopefully not too common. Then, replying can involve contacting other
members etc. - more delay. If there is a problem, we want to hear about it. We know how useful CUGI is to each of us and we would like you to get
the same value from it.
Those of you who did make it to meetings (and didn't fall asleep ...ahem) will have enjoyed (we hope) topics from areas such as graphics, games and
hardware. We showed you Digipaint, Sculpt 3D, PhotoLab, DeLuxe Paint I and an excellent public domain Mandelbrot generator. Incidentally, if you can get DeLuxe Paint II (free with new 'Batman' Amigas, and apparently available with the 'Batman' ' extras for £20 in town) and send away to get it upgraded to DeLuxe Paint III, you will be very happy - DP III is fabulous (if you have at least 1 Meg).
We also demonstrated Sim City, Kennedy Approach (ugh! the C64 version was better - seriously), Zany Golf and Star Trek (public domain, brilliant but it takes up three disks). Battle Chess was simply incredible - chess will never be the same again! On the hardware side, someone else's 1541 disk drive was given some switches to allow easy device number changing live in front of an audience - the amazing thing was that it actually worked! We also reviewed (re-reviewed?) the Sound Sampler and Sound Expander for the C6+. excellent items and great fun. Incidentally. one of our members has successfully attached the Sound Expander kerboard to his Amiga; next, we need some software! On the C6t, we replaved Paradroid, a classic. We also brought in a guest speaker (Kieran Caulfield) who with his Genlock VCR and a stooge entertained us for an evening - you had to be there!
So apart from buying 10,000 disk labels (these are nearly all gone!), staging a couple of table quizzes, and some of us visiting the Commodore Show in June, it was a fairly quiet year, really. I know the committee enjoyed it and we all hope you did too. For our troubles, the A.G.M. ended up with the same crew being re-elected for another year. We'll take it as a vote of confidence! If you have forgotten who we are or what we do, check the list on the inside front cover.
So, what's ahead? Well, on the Amiga side, the new A590 hard drive is catching on and the long awaited Kickstart / Workbench 1.4 looks interesting, to say the least. The new boards inside the current A500 allows for 1 Meg (without the A501 expansion memory), though I'm told some track cutting may be required. That would allow owners to upgrade to 1.5 Meg quite easily (and up to 3.5 Meg if you have an A590). There isn't much happening with the C64 these days but we still support it - we've tons of stuff for it. Anyway, 1990 looks good at this point in time for all of us, so on behalf of the Committee, I'll wish you all a Merry Christmas and a Happy New Year.
Here's a useful tip for Amiga 'power users' which was posted to Usenet recently. Most of the time, the keyboard repeat speed (settable in Preferences) is perfectly adequate. However, there are times when it would be nice to be able to speed it up temporarily while scrolling around with the cursor keys for example.
One neat way of doing this is to use one of the public domain keymap editors. Edit your favourite keymap, and look at the definitions for the standard cursor keys. These are of the form ESC[A (or B or C or D). Now, change the definitions associated with the ALT cursor key combinations. Just set them to be the same as the standard cursor key definitions, but enter each sequence several times. So, for cursor up, you might use ESC[A ESC[A ESC[A. Now when you press ALT ↑, it will move three times as fast as normal - instant turbo control!
You could also do this using SHIFT instead of ALT but quite a few programs use the shifted cursor keys for other functions so it's best to leave them alone.
[p6]
by Declan McArdle
After giving lots of your hard-earned cash away to the salesman, he'll give you a big (and I mean huge, considering the contents) box with the words A590 splattered all over it. Inside it, you get the A590 drive itself, a power supply brick', two disks of installation software, a grounding shield and a user's manual.
It's simple to install - just remove the cover of the expansion bus on the left-hand side of the A500, then insert the grounding shield in between the bottom of the A500 motherboard and the sheet of plastic just below the motherboard. Line up the A590 with the expansion bus and slot it in. Now insert the power supply cable into the back of the A590 and turn it on. Turn on the A500 power supply and all going well, the hard drive will autoboot, assuming you are using KickStart V1.3. The drive comes with with WorkBench and Extras already installed on it.
One important thing to note about the A590 is that the A500 won't power up unless the A590 is powered up as well.
The A590 is another Commodore three-in-one. What it comprises of is as follows:
1. A 20 Meg Epson disk drive: 613 cylinders (0-611, with 612 reserved for parking on), 17 sectors per cylinder, 4 heads, average access time 80ms. (Using DiskPerf3 with a 32K buffer, I've got about 185K read/sec and 155K write/sec.)
2. A 2 Megabyte RAM expansion board containing sockets for 16 256*4 DRAMS CMOS type 120ns or faster.
3. A SCSI interface for adding on additional drives, laser printers etc.
The hard disk drive itself can be removed from inside the A590 chassis and replaced with either a SCSI drive or another ST-506/XT type, as there is a jumper inside to determine whether the internal drive is XT or SCSI.
The RAM expansion board can be found by removing the drive and the Platiorm on which it rests. A PCB called the Party Mix' is now visible.
[p7]
This has sockets for 16 CMOS 256*4 1Mbit DRAMs 120ns or faster. The RAM can be added in either 512K, 1Mb or 2Mb configurations. A jumper must be switched according to the amount of memory you have added.
There is an external 25 pin SCSI connector at the back of the unit. This can be used to support up to 7 additional devices. At the back of the unit can also be found 4 dip switches. They do the following:
Dip #1 Enables or disables AutoBooting
Dip #2 Used if more than one logical drive at a physical address
Dip #3 Enables or disables longer wait for drive(s) to be recognised
Dip #4 Reserved
As mentioned above, you get two disks of software. One is a RAM test disk. The program on this disk will check the chips in the 16 sockets and tell you which are faulty, if any. By default, the A590 RAM maps in at $200000 to $3FFFFF. The second disk contains the hard drive partitioning software. The program is called HDToolBox and has the following options:
Change drive type Set drive type to XT or SCSI Modify bad block list Stops AmigaDOS from using bad sectors Low level format drive Does just that Partition drive Break the drive up into logical sections Verify data on drive Verify all the data on the physical drive Save changes to drive Make permanent the changes you just made Exit & Help These should be obvious
There are lots of nice options in the software, including allowing you to reserve an area of the disk for some special use, such as UNIX (tm), AMAX or virtual floppy disks (see elsewhere in this issue for details on the latter).
Overall, I think that the A590 is a neat little invention. It will transform the life of many an Amiga user. If you think that 20 Megs is too small for your needs, don't forget that it can be easily supplemented or replaced internally. I've had mine for over 2 months and I'm very pleased with it.
[p8]
Part 3 - Centronics and other parallel things by John Pelan
Speed. That's what we all like to see. We want faster clock speeds and fewer instruction cycles so that those Space Invaders move that little bit faster and those Mandlebrot sets take seconds rather than hours. There's little point however in speeding up your engine if your interfaces and peripherals get left behind in a cloud of dust or slow it down to a near standstill. So it's rather a good idea to speed up everything else with it.
Putting 'go-faster' stripes on your serial cable may make you the envy of your friends but won't enhance your data transmission rates. You see, with any serial means of communication, all those lovely bytes that reside together in memory get split up into their component bits. This slows things down. So wouldn't it be a good idea to keep all the bits intact and send them down the cable in parallel?
This is exactly what Centronics (the printer manufacturers) did when they designed the now standard, universally accepted Centronics printer interface, often just called THE parallel interface in fear of law suits. The reason their design was so successful wasn't just because of the tremendous speed offered by the standard but also because of its inherent simplicity. Unlike the RS-232C interface, the Centronics interface uses normal 0 volt (low) and 5 volt (high) logic levels (TTL) to convey the data and so very cheap and readily available chips can be used to implement it. Also, because the data is in 8-bit form, no additional work is needed to process the data as it's in the same form as is used inside the actual computer.
How does the Centronics interface work? Just look at the cable and all will be revealed. As with any electrical link there is a common or ground line (GND) to which all voltages are referred. There are then eight lines for the data (i.e. one for each bit) and three handshaking lines to keep the data flowing smoothly, called
______ ___ STROBE, ACK and BUSY
The bars refer to a logical inversion, or NOT. This is a very common notation in digital design work and means quite simply that a signal is the opposite to which its logic level would imply.
Before any data can be sent across a Centronics cable, it's wise to see if the other end is ready for it. This is the function of the Busy line which means 'Busy' when high and 'Ready for Data' (not busy) when low. When a byte is presented across the data lines and is stable, the
______ STROBE
line goes
[p9]
from high to low briefly (about 0.5 microseconds) to signal that the data is valid. The far end (usually a printer) reads the data and then pulls the
___ ACK
line low (briefly as well) to say that the data has been acknowledged. Thus we have a simple and very fast procedure to transfer a byte at a time.
Provision has been made for additional lines from the printer to signal things such as PAPER OUT, ERROR and SELECTED (i.e. is the printer online) but these aren't always used. There is often a
_____ RESET
line as well which enables the printer to be reset (as if switched off and on) by the computer.
C-64 owners can easily implement a Centronics interface with a simple cable and a small piece of machine code because the user port offers all the required lines at the correct voltage levels. This highlights how flexible a user port can be (last time we used it as part of an RS-232C interface). Here are the necessary connections:
User Port Centronics A GND <---> 33 GND ___ B FLAG <---> 10 ACK C PBO <---> 2 DATA 1 D PB1 <---> 3 DATA 2 E PB2 <---> 4 DATA 3 F PB3 <---> 5 DATA 4 H PB4 <---> 6 DATA 5 J PB5 <---> 7 DATA 6 K PB6 <---> 8 DATA 7 L PB7 <---> 9 DATA 8 ______ M PA2 <---> 1 STROBE N GND <---> 16 GND
The user port connector is a 2x 12 0.156" edge connector and the Centronics connector is a 36-way 'Centronics' plug. Note that the BUSY signal line isn't implemented. This cable will work with most C64 software that has a Centronics option, like Easyscript. It's very easy to write a piece of machine code that will let you redirect output to a parallel printer (for Listings etc.) but I'll leave this as an exercise. Don't spend too long on it.
Amiga users already have a Centronics interface and some fairly nifty device drivers that are a pleasure to use. Bear in mind that you've got both PRT: for driving printers and PAR: for raw data.
The Centronics interface is a semi-synchronous system which means that the receiver is told when the bytes are arriving, unlike the asynchronous
[p10]
RS-232C (which has to work out when each bit is arriving) and a fully synchronous system (which 'expects' the data). It is a half measure between a ver fast but complicated synchronous system and a slower asynchronous system.
You may have noticed that the Centronics interface is uni-directional, i.e. one way only. That's fine for things like printers that don't usually have much to say but for two-way communications, it's insufficient. It isn't too complicated to add on a few more control lines to implement bi-directional communications. All you really need is a means of dictating who talks and who listens, and a protocol for turning the talker and listener around.
The IEEE-488 (GPIB/HPIB) bus does just this and has the added bonus of allowing many listeners on the same bus. It's used primarily for computer control of scientific instruments and data-logging. In fact, the serial port on the Vic-20, C64, C128, C16 and Plus 4 is a cut down version of this! It has the flexibility of the parallel IEEE-188 system with the low cost of a serial system, but as every user knows, it is dreadfully slow.
SCSI (pronounced 'skuzzy"), the Small Computer Systems Interface, is another parallel system which is designed to link very fast computers and peripherals together, like hard drives, CD ROMs and laser printers. It can handle speeds up to 1.5 MBytes per second in asynchronous mode and 4 MBytes per second in synchronous mode. It is an eight bit wide system like the Centronics system so will eventually be phased out when 16-bits become the norm for parallel communications. The IPI (Intelligent Peripheral Interface) will thus succeed it. In a few years time, SCSI and IPI may be the only communications interfaces you'll ever need!
But back to the present. The Centronics interface can be persuaded to do many more things than just talk to printers. After all, it is has 9 data output pins and 2 data input pins which can be used for a huge number of applications. Here are a few suggestions.
Eddy and myself have both used the Centronics interface to connect an Amiga to a C64. One can use a 6502 cross-assembler (like DASM) to senerate code for the C64 on the Amiga (at a much higher speed than the C64 could manage). The code can then be copyed over PAR: to a C64 which has been effectively set up as a printer. i.e. the C64 waits for
______ STROBE
reads the data and then siguals
___ ACK.
If you are clever, you can utilize the first two bites of the file that point (in lo/hi format) to the memory destination. This means you can very quickly load machine code programs straight into
[p11]
the C64 and run them immediately. This is great for software development and it's very cheap.
Clearly when up to eight on/off control lines are required, a Centronics interface will be of use. This could include stepper-motor control, mains control (both on/off and variable control) and control of digital electronics circuits like an EPROM programmer for example.
Not only can you use the interface as a means of output but if you are fortunate enough to have a Centronics port that's driven by a general purpose interface chip (like the 8250 on the Amiga or the 6526 on the C64) then you can program the chip to take input too. This means writing your own software, but it leads to greater fexibilty and often much more fun.
You are quite at liberty to change and perhaps improve upon any protocol by simply changing the software. Feel free to do it to a Centronics interface as well as any other, perhaps for a networking application?
In the next installment I'll go into greater detail about user ports and digital control with a few projects for you to build.
[p12]
A PC is a very powerful machine if you know how to talk to it. However, it you have the misfortune to have bought an Amstrad, then you immediately have a problem, and it's called The Manual. Never before have I seen a book so thick that tells you absolutely nothing. As one of the committee said, "It's all there, but you need a book to find out where to look." So, if like me you were or are absolutely thick when it comes to MS-DOS, then I hope the following will be of some benefit.
Before we start, I'd like to give you a little history lesson as to the origins of DOS.
Some History Development of MS-DOS/PC-DOS began in October 1980, when IBM began searching the market for an operating system for the as yet unreleased IBM PC. Microsoft had no real operating system to sell, but after some research licensed Seattle Computer Products' 86-DOS, which had been written by a man named Tim Patterson for use on the company's line of 8086, S100 bus micros. This was hurriedly polished up and presented to IBM for evaluation. IBM had originally intended to use Digital Research's CP/M operating system, which was the industry standard at the time. Folklore reports everything from obscure legal entanglements to outright snubbing of the IBM representatives by Digital. Regardless, IBM found itself left with Microsoft's offering of "Microsoft Disk Operating System 1.0". An agreement was reached between the two, and IBM PC-DOS 1.0 was ready for the introduction of the IBM PC in October 1981. IBM subjected the opeating system to an extensive quality-assurance program, found well over 300 bugs, and decided to rewrite the programs. This is why PC-DOS is copyrighted by both IBM and Microsoft.
It is sometimes amusing to refect on the fact that the IBM PC was not originally intended to run MS-DOS. The target operating system at the end of the development was for a (not yet in existence) 8086 version of CP/M. On the other hand, when DOS was originally written the IBM PC did not yet exist! Although PC-DOS was bundled with the computer, Digital Research's CP/M-86 would probably have been the main operatins system for the PC except for two things - Digital Research wanted $495 for CP/M-86 (considering PC-DOS was essentially free) and many software
[p13]
developers found it easier to port existing CP/M software to DOS than to the new version of CP/M.
MS-DOS and PC-DOS have been run on more than just the IBM PC and clones. There was an expansion board for the Apple Il that allowed one to run (some) well-behaved DOS programs. There are expansion boards for the Commodore Amiga 2000, the Apple Macintosh Il, and the IBM RT PC allowing them to run DOS, and the IBM 3270 PC, which ran DOS on a 68000 microprocessor. The Atari ST can run an emulator program and boot MS-DOS.
DOS version nomenclature: major.minor.minor. The digit to the left of the decimal point indicates a major DOS version change. 1.0 was the first version. 2.0 added subdirectories, etc. 3.0 added file handles and network support. The first minor version indicates customization for a major application. For example, 2.1 for the PCjr, 3.3 for the PS/2s. The second minor version does not seem to have any particular meaning. The main versions of DOS are:
PC-DOS 1.0 October 1981 Original release PC-DOS 1.1 June 1982 Bugfix, double sided drive support MS-DOS 1.25 June 1982 For early compatibles PC-DOS 2.0 March 1983 For PC/XT, many UNIX-like functions PC-DOS 2.1 October 1983 For PCjr, bugfixes for 2.0 MS-DOS 2.11 October 1983 Compatible equivalent to 2.1 PC-DOS 3.0 August 1984 For PC/AT, network support PC-DOS 3.1 November 1984 Bugfix for 3.0 MS-DOS 2.25 October 1985 Extended foreign language support PC-DOS 3.2 July 1986 3.5 inch drive support for Convertible PC-DOS 3.3 April 1987 For PS/2 series
Some versions of MS-DOS varied from PC-DOS in the available external commands. Some OEMs (Original Equipment Manufacturers) only licensed the basic operating system code (the xxxDOS and xxxBI0 programs, and COMMAND.COM) from Microsoft, and either wrote the rest themselves or contracted them from outside software houses like Phoenix. Most of the external programs for DOS 3.x are written in 'C' while the 1. and 2.x utilities were written in assembly language. Other OEMs required customized versions of DOS for their specific hardware configurations, such as Sanyo 55x and early Tandy computers, which were unable to exchange their DOS with the IBM version.
[p14]
At least two versions of DOS have been modified to be run entirely out of ROM. The Sharp PC5000 had MS-DOS 1.25 in ROM, and the Toshita 1100 and some Tandy models have MS-DOS 2.11 in ROM.
The Disk Operating System (DOS) and the ROM BIOS serve as an insulating layer between the application program and the machine, and as a source of services to the application program.
The system hierarchy may be thought of as a tree, with the lowest level being the actual hardware. The 8088 or V20 processor sees the computer's address space as a ladder two bytes wide and one million bytes long. Parts of this ladder are in ROM, parts in RAM, and parts are not assigned. There are also 256 "ports" that the processor can use to control devices.
The hardware is normally addressed by the ROM BIOS, which will always know where everything is in its particular system. The chips may usually also be written to directly, by telling the processor to write to a specific address or port. This sometimes does not work as the chips may not always be at the same addresses or have the same functions from machine to machine.
DOS consists of four components:
• The boot record
• The ROM BIOS interface
• The DOS program file
• The command processor
The boot record begins on track 0, sector 1, side 0 of every diskette formatted by the DOS FORMAT command. The boot record is placed on diskettes to produce an error message if you try to start up the system with a nonsystem diskette in drive A. For hard disks, the boot record resides on the first sector of the DOS partition. All media supported by DOS use one sector for the boot record.
Interface The file IBMBIO.COM or IO.sys is the interface module to the ROM BIOS. This file provides a low-level interface to the ROM BIOS device routines and may contain extensions or changes to the system board ROMs. Some
[p15]
compatibles do not have a ROM BIOS to extend, and load the entire BIOS from disk (Sanyo 55x, Viasyn).
The actual DOS program is file IBMDOS.COM or MSDOS.SYS. It provides a high-level interface for user (application) programs. This program consists of file management routines, data blocking/deblocking for the disk routines, and a variety of built-in functions easily accessible by user programs.
When a user program calls these function routines, they accept highlevel information by way of register and control block contents. For device operations, the functions translate the requirement into one or more calls to IBMBIO.COM or MSDOS.SYS to complete the request.
The Command interpreter, COMMAND.COM, consists of several parts. The resident part resides in memory immediately following IBMDOS.COM and its data area. This portion contains routines to process interrupts 22h (Terminate Address), 23h (Ctrl-Break Handler), and 24h (Critical Error Handler), as well as a routine to reload the transient portion if needed. For DOS 3.×, this portion also contains a routine to load and execute external commands, such as files with exensions of COM or EXE.
When a program terminates, a checksum is used to determine if the application program overlaid the transient portion of COMMAND.COM. If so, the resident portion will reload the transient portion from the area designated by COMSPEC= in the DOS environment. If COMMAND.COM cannot be found, the system will halt. DOS 3.3 checks for the presence of a bard disk, and will default to COMSPEC=C:\. Previous versions default to COMSPEC=A:\. Under some DOS versions, if COMMAND.COM is not immediately available for reloading (i.e. swapping to a foppy without the COMMAND.COM file on it) DOS may crash.
All standard DOS error handling is done within the resident portion of COMMAND.COM. This includes displaying error messages and interpreting the replies of Abort, Retry, Ignore, Fail.
An initialization routine is included in the resident portion and assumes control during startup. This routine contains the AUTOEXEC.BAT file handier and determines the segment address where user application programs may be loaded. The initialization routine is then no longer needed and is overlaid by the first program COMMAND.COM loads. AUTOEXEC.BAT may be a hidden file.
[p16]
A transieut portion is loaded at the high end of memory. This is the command processor itself, containiug all of the interual command processors and the batch file processor. For DOS 2.x, this portion also contains a routine to load and execute external cominands, such as files with extensions of COM or EXE.
This portion of COMMAND.COM also produces the DOS prompt (such as "A>"), reads the command from the standard input device (usually the keyboard or a batch file), and executes the command. For external commands, it builds a command line and issues an EXEC function call to load and transfer control to the program. COMMAND.COM may also be a hidden file.
For Dos 2.x, the transient portion of the command processor contains the EXEC routine that loads and executes external commands. For DOS 3.x, the resident portion of the command processor contains the EXEC routine.
The system is initialized by a software reset (Ctrl-Alt-Del), a hardware reset (reset button), or by turning the computer on. The Intel 80x8x series processors always look for their first instruction at the end of their address space (OFFFFOh) when powered up or reset. This address contains a jump to the first instruction for the ROM BIOS.
Built-in ROM programs (Power-On Self-Test (POST) in the IBM) check machine status and run inspection programs of various sorts. Some machines set up a reserved RAM area with bytes indicating installed equipment (AT and PCjr).
The ROM routine looks for a disk drive at A: or an option ROM (usually a hard disk) at absolute address C:800h. If no floppy drive or option ROM is found, the BIOS calls int 19h (ROM BASIC if it is an IBM) or displays an error message.
If a bootable disk is found, the ROM BIOS loads the first sector of information from the disk and then jumps into the RAM location holding that code. This code is normally a routine to load the rest of the code off the disk, or to 'boot' the system.
[p17]
The following actions occur after a system initialization:
1. The boot record is read into memory and given control.
2. The boot record then checks the root directory to assure that the first two files are IBMBIO.COM and IBMDOS.COM. These two files must be the first two files, and they must be in that order (IBMBIO.COM first, with its sectors in contiguous order). IBMDOS.COM need not be contiguous in version 3.x.
3. The boot record loads IBMBIO.COM into memory.
4. The initialization code in IBMBIO.COM loads IBMDOS.COM, determines equipment status, resets the disk system, initializes the attached devices, sets the system parameters and loads any installable device drivers according to the CONFIG.sys file in the root directory (if present), sets the low-numbered interrupt vectors, relocates IB-MDOS.cOM downward, and calls the first byte of DOS. CONFIG.SYS may be a hidden file.
5. DOS initializes its internal working tables, initializes the interrupt vectors for interrupts 20h through 27h, and builds a Program Segment Prefix for COMMAND.COM at the lowest available segment. For DOS versions 3.10 up, DOS initializes interrupt vectors for interrupts OF through 3Fh.
6. IBMBIO.COM uses the EXEC function call to load and start the top-level command processor. The default command processor is coM-MAND.COM.
Most of the above information is taken from the DOS technical reference disk in the CUGI PC library, which is available from your local librarian at a very reasonable cost. Next issue I will go on to talk about some of the more useful DOS commands.
[p18]
by Eddy Carroll
Since Commodore released the A500 hard disk unit, a great number of Amiga users have bought one (I personally know of at least 6 people who have got one within the past month or so). You can find a review of the hard disk itself elsewhere in this issue. What I want to talk about here however is how to setup a virtual floppy on your hard disk. Although the method can be adapated to work with almost any size and type of hard disk, I'll be assuming the A590 is used throughout. Interested parties should be able to modify the appropriate numbers to suit their own system.
A virtual floppy is simply a section of your hard disk (880K or so) that has been configured to look like a foppy drive to AmigaDOS. With the exception of specialised disk editors that access the trackdisk.device directly, all programs will think that the virtual floppy is a real floppy disk. There is one big advantage however - speed. The virtual floppy will operate at the speed of the hard drive, rather than the floppy drive. This makes virtual floppies great for when you are doing work that you would normally do on a floppy disk, whether it's making up a disk for a friend or just having a look through the latest public domain disk. Because AmigaDOS thinks that it's a real drive, you can use the DISKCOPY command to copy real disks to and from it. You can have as many virtual floppies as you like; the only limit is on how much of your hard disk you want to devote to them and how much memory you have.
So, how do you setup a virtual foppy disk? First of all, let's take a little mathematical digression to find out what numbers we need to use to fool AmigaDOS. Those who are not interested in the theory can safely skip on a paragraph or two. The A590 currently comes with either an Epson or Western Digital hard drive unit installed, and these are configured slightly differently. The Epson has 17 sectors/track, 4 heads and 612 cylinders for a total of 41616 blocks, whereas the Western Digital has 27 sectors/track, 2 heads and 782 cylinders for a total of 42228 blocks. This makes the calculations slightly different for each drive. I'll use the Epson drive as an example, but further on, there is a table listing the correct values to use if you have the Western Digital drive.
As noted above, the Epson drive has 41616 available blocks. AmigaDOS really only cares about block numbers - it uses the head and cylinder layout to help optimise performance, but nothing drastic happens if we cheat a little bit. Let's rearrange the figures. A standard foppy disk has 2 heads
[p19]
and 11 sectors/track, giving 22 blocks per cylinder. A hard disk using these figures has 1891 cylinders available (i.e. 41616/22), numbered 0 to 1890.
Now, decide how many virtual foppies you want and multiply this number by 80 (the number of cylinders on a standard foppy disk). Subtract the result from 1890, and then add 1 to your answer to get the starting cylinder of the first virtual floppy. For example, if you wanted two virtual floppies, subtracting 160 and adding 1 gives 1731. Now, multiply this starting cylinder by 22 to find out the starting block, and divide this number by 68 (the number of sectors/track times the number of heads on the hard drive) to get the starting cylinder in terms of the original layout. In the example, 1731 times 22 is 38082, and dividing by 68 gives 560. Now, subtract one from this starting cylinder of the virtual floppy to get the ending cylinder of the rest of the hard drive.
To make things easier, the following tables gives the necessary figures for 1 up to 5 virtual floppies. Use the first table if you have the Epson drive, the second table if you have the Western Digital drive.
No. of VFs | High Cyl on HD | VF LowCyl | VF HighCyl
1 584 1811 1890
2 559 1731 1810
3 533 1651 1730
4 507 1571 1650
5 481 1491 1570
(Partition values for Epson hard drive unit)
No. of VFs | High Cyl on HD | VF LowCyl | VF HighCyl
1 748 1893 1918
2 715 1759 1838
3 683 1679 1758
4 650 1599 1678
5 617 1519 1598
(Partition values for Western Digital hard drive unit)
Armed with the appropriate figures from above, the next step is to repartition your hard drive. Commodore supplies a very nice program with the A590 that makes this easy. However, since you have undoubtedly already started filling up your hard disk, you'll need to make a backup of it first.
[p20]
There are several public domain hard disk backup utilities available, aud a mumber of good commurtial ones too. Qutarterback is recommended. Of course, sensible people have already backed up their drive, right?
Okay: Run the HD Tools program that comes on the A590 system disk Click on the "Advanced Options" gadget to reveal the starting and ending cylinder gadgets. Select the rightmost partition for editing (if you only have a single partition, it will already be selected), and change the High Cylinder number from 611 to the "High Cyl ou HD" listed in the table.
Save this new information. answering in the affirmative to the program's dire warning that all the information ou your hard drive will be erased At this stage, there should be an empty area at the righthand side of the partition diagram. This represeuts the space used by the virtual floppies.
Now, reformat your drive and restore your previous backup. The hard work has been done. All that now remains is to setup a mountlist for the floppy drives, so that AmigaDOS kuows about them. The mountlist is a file in the DEvs: directory which is used by the MOUNT command when you mount a new device to tell AmigaDOS about it. Edit the existing mountlist file DEVS:MOUNTLIST on your hard disk. and at the start, add a number of entries like the following, one for each virtual floppy.
/* First virtual floppy */ FFO: Device = xt.device Unit = 0 Surfaces = 2 BlocksPerTrack = 11 Reserved = 2 Interleave = 0 LowCyl = VF LowCyl; HighCyl = VF HighCyl; Buffers = 9 BufMemType = 0 Mount = 1 StackSize = 4000 # /* End of first virtual floppy */
The name of the above floppy drive is FFO:, though you could call it something else if you like (perhaps DF2:). Each virtual drive must have a different name however.
You should replace "VF LowCyl" and "VF HighCyl" with the actual mubers given in the table. For example. if you are setting up three virtual
[p21]
floppies. you will have three entries like the above (FFO:, FF1: and FF2:). The first uses the starting and ending cylinders give in the first row of the table, the secoud uses the values in the secoud row aud so on.
You can adjust the Buffers figure up or dowu to allocate more or less memory to the virtual #oppy for bufferiug. More buffers iucrease access speed but use up memory. 9 buffers use arouud 5K of memory. You should leave all the other figures well alone.
Having got this far, all that remains to do is to mount each virtual floppy. You can do this using the MOUNT commaud. In the CLI, type MOUNT FFO:, MOUNT FF1: etc. You need a separate MOUNT command for each virtual floppy. You may like to add these to your startup-sequence or alternatively, you can do it manually whenever you first want to access the virtual foppy. AmigaDOS will gleefully tell you it is not a DOS disk the first time you mount it: you can format it by typing:
FORMAT DRIVE FFO: NAME "Virtual Floppy" QUICK NOICONS
(AmigaDOS will tell you to insert the disk to be formatted, but just press RETUR). Make sure you do NOT accidentally type DHO: instead of FFO:! (You may laugh, but a certain committee member did just that ... luckily, he had a backup.)
To copy floppy disks to virtual foppies, you can use the DISKCOPY command in the CLI. For example:
DISKCOPY DFO: TO FFO:
Unfortunately, Workbench has a bug which prevents you copying to a virtual floppy by just dragging a disk icon on top of it. However, you can get around this by doing the following. First of all, open up the System drawer on the Workbench disk. Now, click on the icon of the disk you are copying from, and then hold down SHIFT and click on the icon of the disk you are copying too. Finally, with SHIFT still held down, double-click on the DiskCopy icon in the System window. Now the copy should proceed as normal.
If it all seems a little complicated, take beart. As long as you have a backup copy of your hard disk, you can't do any serious damage, and the benefits of virtual floppies are well worth any small inconvenience involved in setting them up.
[p22]
by Rocco Matassa
Have you ever thought about programming? When I bought my first computer (a Commodore 64), the industry was just graduating from the computer kit stage. Up until then, people had circuit boards in home made cases linked to bare keyboards, hexpads or just numeric entry pads, and a B&W TV set. The original computer people were hobbyists in the real sense, software was not commercially available. The original computer club was a programmer's club, where people actually learned to program in machine code. Assembly language was a luxury, and a high level language like BASIC was unknown outside of a mainframe.
The first generation of home computers, a computer ready to use on removal from its packaging, brought the general public (those who could not afford a mainframe or time on one) face to face with the future. The staggering growth of the computer industry, from the ZX80 through to today's home computer, the likes of the Atari ST, Commodore Amiga, Apple Mac, IBM PC and Archimedes, is a perfect example of the real interest people have in technology, and a desire not only to be aware of it, but to be familiar with it.
The power of today's home computer is so great that small computers now replace large expensive systems with no loss of capability. On the contrary, it has resulted in more power in the hands of more people, thereby increasing productivity. The present generation of small computers and the new generation of home computers are now almost comparable in power. The new 32 bit computers are bridging that gap. This year for the first time, IBM have released figures indicating that its sales of PC's are virtually equal to its sales of mainframes, and they expect them to outsell the mainframes next year.
Once again, have you ever thought about programming? When I bought my C64, I intended to learn to program. I did teach myself assembler and I could read and understand programs, but I never went further than doctoring programs to get infinite lives, uncountable wealth or disabled baddies. I adopted a similar attitude with the Amiga, intending to learn a little programming, however I was shocked to find the level of complexity had increased so much that I was in fact a computer novice again. The CLI for instance was as complex (if not more so) than C64 BASIC. Programming, even in BASIC required you to load the environment first and presented you with an unfamiliar user interface. My one impression was that the next
[p23]
generation of computer might as well be (if I could not learn to program this one) a games machine for all the use I would be able to make of it.
The advantage of a club like this one is that there are people who are good programmers and able to advise and help, therefore I sought advice. The answer was C, a high level language like BASIC, but with the advantages of assembler. The one thing about C that attracted me was portability. If I could learn this lauguage, my programs would have a fair chance of running on other machines, including the successor to this computer. In effect, a language with a reasonable life expectancy. In any event, C or its successor would probably have enough in common to reduce the learning period, if one proved necessary.
With this in mind, I set out to learn C. Well, first things first. I need a book on C, obviously, how many could there be? A lot. C of course, Which C, Turbo C, Quick C, C++...? Just C, and make sure it's the new ANSI standard one. There are a lot of primers. The one I eventually picked was C: Step-by-Step by Howard W. Sams & Company.
The next thing I quickly realized was that one book was not enough; a further book such as Advanced C on the Amiga will be necessary if I want to use machine specific routines, like those which control the windows and interface with Intuition, the Amiga's operating system. Well, I am eighty odd pages into the book and learning. I can recommend learning a language like C.
I know from being on the committee (and you should know, as it was mentioned at the last two meetings) that the club will be purchasing books for the Amiga library, including some C primers, for lending purposes. A course of sorts is also planned, which I look forward to. Who knows, a year from now maybe we can have an assembly language course for the Amiga. Anyone out there willing...?
[p24]
by Marc Whisker
Well here it is, my second (gasp!) article for the CUGI newsletter. I still know of a few people who haven't written any articles yet! Well, enough about that, let's get to the subject of this article - the exciting experiences of running Niteline BBS.
This article looks like it's continuing from the last one; I remember saying something about obtaining BBS-PC! software from SK for IR£70. I have been told too many times that I was ripped off, and I agree, I was. But unfortunately, that's life. Since buying this software and using it, I have realised how awful it is. If you are going to start up a BBS, don't for Godsakes buy BBS-PC! (I'll sell it to you for a tenner!)
Running a BBS can be one of two things depending on how interested you are. It can either be very, very boring and a waste of your time, or else it can give you lots of fun and enjoyment, depending on how you run the BBS. Luckily for me, it was the latter (i.e. good fun). Setting up the BBS was quite interesting and funny, I can vaguely remember. I had this huge 300 bps (yuk!) modem that was as dumb as you could get. I also had a D25 lead to connect it to the computer. I rigged it up to the Amiga and started the BBS on a trial run for 3 days at 300 bps. Surprisingly, the software didn't object greatly to the modem and it worked like clockwork. The only small problem with it was that the remote caller had to drop the line when BBS-PC! gave the "Connection Terminated" message, otherwise a few problems did arise. I got about 8 calls during the 3 nights, all of which were new users and I can even remember message #1 from myself to All welcoming everyone. I'm afraid I can't remember the first caller anyone else know? Or want to claim the title? At that stage, I was using the menus supplied with the BBS. They were awful - 40 column with very basic functions (and I don't mean BASIC as in the language),
After those three days, I took the board down for about a week to completely change the setup to suit my needs. I changed various menus and had two menu sets (one of 40 columns and one of 80 columns). No ANSI colour menus yet. For those of you who don't know much about communication via modem, ANSI stands for American National Standards Institute. These are the people who came up with ANSI codes which are used nearly all the time in computers, from printer escape codes to BBS menus.
So I set the BBS up again after a week, still at 300 baud. I then got a loan of a WS4000 modem which supported 1200/75 as well as 300/300 from
[p25]
Fergus McDonald, my Co-Sysop. This gave the board a massive boost; even though it was runing from 9 pm to 9 am, I was getting about 3 callers per night which at the time I thought was pretty good. Fergus then suggested IBM graphics menus. He noticed one time when he was online to Niteline that it was using the IBM character set and technically should support IBM ANSI graphics. So first of all, I photocopied all 300 pages of the manual of BBS-PC! and gave it to him, and he set about doing some menus with colour and graphics. When the first few came my way and I compiled them, they were very nice, as anyone who has used them will verify. I decided then to add ANSI colour to the normal menus, giving 4 menu sets - 40 column, 80 column, 80 column colour and 80 column IBM colour.
The BBS was really getting quite popular by now and I must say a big thank you to all CUGI members for allowing me to borrow the Amiga second disk drive for about 6 months. I then heard about some cheap WS3000 modems - the version that supports all speeds up to 2400 bps! This was a really good offer at only Stg£150, which worked out at about I£181. This was one hell of a scenario; sometimes I really wonder was it worth it. It came through and was caught by customs, so I had to pay extra on it, sigh. When I got it home and connected it to my Amiga, the damn thing didn't do anything more than the WS4000. No 1200/1200 bps, never mind 2400/2400. I phoned up the man in England about it and I had to send it back and get it fixed. But first I cheated - I swapped the high speed board in my modem with Geoff's (thanks for that, Geoff) and discovered that my WS3000 now worked fine at 2400. This isolated the problem as being on the high speed board. So I sent that by itself back to the UK to be fixed, and got it back about 3 weeks later. I plugged it in to the modem and got the green light, and now Niteline operated at all speeds from 300 to 2400. I was very pleased with this.
My user list shot up dramatically from 50 to 150 in less than 2 weeks! I was now receiving 12-15 calls per night and it was very popular. The highest message number at this stage was about 3500 and this was mid-summer about July. I went on holidays to England and while I was there bought myself an external Amiga disk drive so that I could return the other one to CUGI. How pleased they were with this. Also while I was on holidays, I had a few strange users, like Mr X from Y. Quite funny, a bit of a joker I think. He didn't do anything to the BBS and as expected, he was on the user list and in the caller log.
The next major thing that happened was the Infomatique hack. The only reason this is related to my board is that both use the same software.
[p26]
I didn't get too worried as there wasn't 110 megs of data on my BBS to destroy and I backed it up on a daily basis. However, I did get a caller to my board by the same name as the hacker of Infomatique. All he did was post 500 null messages thereby scrolling off all the messages on the BBS. He filled up the system disk with null advertisements and the most interesting part of all is that he was in the caller log, but not on the user list. So how could he access messages and ads without registering, as you have to register before you can access anything on Niteline. This proves to me that there must be a "back door" in BBS-PC!, but I don't even know where or how you get to it. Any would-be hacker want to try? Under my supervision of course; I don't want you destroying it all!
Since then, the system has got more popular by the day. I now have 196 users and get 12-15 callers per night with about 100 messages posted per night. There was a Niteline party about 3 weeks ago. All in all, if you don't call Niteline, you don't know what you're missing (plug plug). At present, I am saving the cash for an A590 which should be coming my way in about 6 or 7 weeks. Next summer, I intend to switch the software to Paragon. Briefly, it supports many more powerful options over BBS-PC!, such as Net and Echo Mail, multi-user chat (if you have 2 lines) and of course full shell to DOS from remote, and online live games. However, it needs around 1.5 Megs to run smoothly with online games.
Well for those of you who don't know about Niteline, it runs from 8 pm to 9 am each night and supports all speeds from 300 bps to 2400 bps. The phone number is 01-832714. Also, I'd like to officially announce to all members of Niteline that Niteline Party II will be on Friday 22nd December at 8 pm. Contact me for further details.
Look forward to seeing you on Niteline sometime!
[p27]
by Eddy Carroll
Now that the newsletter has grown to a respectable size, there is quite a bit of material to go through for each issue. I thought it might be useful to give a brief list of guidelines to keep in mind when preparing articles for submission. I'm not trying to pressure anyone into actually following these - as always, any and all submissions are welcome - but if you follow them, you can reduce the amount of work the editor (currently me!) needs to do with your article. Conversely, the longer the editor spends editing an article, the more likely he or she is to start changing other things as well.
If at all possible, please submit your article on Amiga 3.5" disk. If you don't have access to an Amiga, we can handle other formats as necessary. Alternatively, you can transfer your article via modem, either via a BBS such as Infomatique, or directly to the editor.
Try and submit your article in something as close to plain ASCII text as you can manage. If you are writing it using a word processor, use the "Save as ASCII" option if there is one, or 'Print' the file to disk. Any extra formatting codes added by the wordprocessor will only have to be removed later on. Ideally, the file should be formatted with a return at the end of each line, but files which have a return only at the end of each paragraph are okay as well. You should also leave a blank line between each paragraph.
Inside the article itself, items surrounded by quotes should use opposite quotation marks like this' rather than a single quote 'like this'. A500 users may have some trouble tracking down the ' character - you can get it by typing (ALT C. To use "double quotes" you should use two separate quote characters '*like this» instead of the standard "quotation marks"
On a more general note, don't leave space before punctuation marks; always put commas, question marks, full stops and other punctuation tight up against the preceding word, like this, instead of separated by a space the way that one was.
You can emphasise certain parts of your text by inserting the following special sequences. (\it text} puts the enclosed text in italics, (\bf text} puts the enclosed text in boldface and {\sc text} puts the enclosed text In SMALL CAPS.
Finally, read through your article before you submit it! You will be amazed at how many spelling mistakes and missing words you find.
[p28]
by Shane Broadberry
Unlocking the graphics routines available to Amiga programmers can at times seem like an unfruitful occupation - there seem no end of structures, pointers and lists which no matter how they are initialised never seem to yield results quite as expected. In this article, I hope illustrate, using a simple example, just how easy it is to access these routines, and how powerful they really are.
The first thing that we must remember when calling these routines is to open the library which contains them. This may seem like a simple point but it's a very easy one to overlook. When an OpenLibrary () call is made from within a program, this routine checks to see if the library is already open, and if it is open, it will return a pointer to the base address of the library. If the library hasn't already been opened, then the system opens the library and returns a pointer to the base address. Once this is done, all the routines in the library can be accessed, and from within C you need never worry about it again - until the end of the program when of course the library should be closed.
In this example, we're going to open three libraries. The Graphics library contains almost 100 different low level graphics routines which will enable us to deal with the Amiga's graphics right down to the hardware level. Since this library doesn't deal with higher level graphics structures such as windows and gadgets, we'll also open the Intuition library. Finally, we're going to open the Diskfont library, which allows us to find out font information and access the fonts stored on disk.
Assuming that the libraries have been opened successfully, we can start with the actual program. We are going to write a program which will open up a window on the screen, write some text in a custom font (instead of the standard Topaz font) and draw a line. We will then wait for the user to close the window, and exit.
How do we go about opening up a window? First we have to define the kind of window we want; how big we want it, where we want to place it. whether we want to allow the user to move it about, what name we want to call it and so on. Ouce this is done, we can ask Intuition to display our window. The routine we want to call to achieve this is the Open Window() function (sensibly enough). How do we go about telling this function what options we want to use to display our window? Intuition is
[p29]
familiar with the New Window structure (a structure is merely a groupiug of a number of different data types). We initialise this structure to the values We wish associated with our window, what options we want to allow the user, what size and height we want to allow it to be expanded/shrunk to, and a number of other options (for details on the New Window structure and other structures mentioned here, see the Intuition Reference Manual.
Once the structure has been intialised, we can proceed to open the window. When the Open Window() function is called it returns a pointer to a Window structure, or NULL. If the function returns NULL, it means that for some reason our window has failed to open - maybe there is not enough available memory to open up a window of the specified dimensions,
or perhaps there was some fault in the initialisation of our NewWindow structure. Either way we must now exit from our program - to continue from this point would guarantee a visit from the GURU. If the window did open, the value of the pointer returned by the function will be of enormous value to us. If we wish to continue using this window (and do not merely wish to open it, which would be wasteful and pointless) we must make sure this value is not overwritten, because without it we cannot perform any other actions on the window, including closing it. Since the returned value is a pointer to a Window structure, we must declare the value used to hold this pointer as a pointer to a Window structure as well. Failure to do this will at the very least create objections from your compiler.
Members of the Window structure can now be accessed via the 'silly arrow' (ask Ariadne!) which is the standard method for accessing members of structures through pointers. For example, if OurWindow is a pointer to a Window structure, we can access elements in the structure pointed to by OurWindow as follows:
OurWindow-›(member)
If (member) is itself a pointer to another structure, then we can access elements of that structure as follows:
OurWindow-›(member)-›(another structure's member)
In this way, we can access all of the structure elements we need.
The first member of the window structure that we are currently interested in is the RPort (RastPort) member. This variable holds a pointer to our window's RastPort structure, and we need this in order to perform the graphics and text functions we use later in the program. If we look up the Text() function for example, we will find that it requires as its first argument a pointer to a RastPort structure. What does this RastPort
[p30]
structure contain? A RastPort structure basically contains information regarding the writable screen memory, pointers to the individual planes of a particular screen, current pen position for plotting, sprite information etc. Since the Text() function requires a pointer to this structure, we need do nothing more than pass the value obtained from our Window structure. For example:
Text (OurWindow-›RPort, "Hello", 5);
This calls the Text() function with a pointer to our window's RastPort structure, and similarly for Draw(), Move() and other graphics functions.
Now how do we go about using one of the many available fonts for our text? As we've just seen above, the Text() function will allow us to place text in our window (in conjunction with Move() which starts the plotting at a particular point). In order to use a different font for the text, we will have to open a disk font, and tell the Amiga that we wish this font to be used rather than the default Topaz font. The method for doing this is similar to the methods used above in opening a new window. First we must initialise a text structure, the Text.Attr structure, to contain the information about the font we wish to load, its size and name, and how we wish the font to be displayed. When we call the OpenDiskFont() function passing it this information, it will return a pointer to a font structure. This function attempts to open the font defined in our TextAttr structure, or else returns NULL indicating that the font could not be found, or there was some other error. This should be dealt with accordingly.
Once we've opened the font, we must then tell the system to use this particular font (remember, we could be using a number of different fonts throughout the program and we want an easy way of switching between them). We do this using the SetFont() function, which takes arguments a pointer to a RastPort structure and a pointer to a Font structure.
The remainder of the program simply writes some text to the window, which can be resized (although there is no provision for the redrawing the window if the text inside is lost - this could easily be added) and draws a line. Having access to these functions with such ease is a huge boon for Amiga programmers. To be able to use existing fonts and library routines saves enormous amounts of time and effort on the programmer's behalf. To have to recreate the Text() function and design all your own fonts for instance would take a very long time, and although not all of these routines may be suitable for every program you may ever want to write, a large proportion of them need never be written, with the added bonus that you will remain completely compatible with the Amiga environment.
[p31]
/*
* An example of using Amiga Graphics Routines
*/
#include <exec/types.h›
#include <graphics/text.h>
#include <libraries/diskfont.h›
#include <intuition/intuition.h>
#ifdef AZTEC
#include <functions.h>
#endif
#define REV 0
#define OUR RP OurWindow-›RPort
struct IntuitionBase *IntuitionBase;
struct GfxBase struct *GfxBase;
struct DiskfontBase *DiskfontBase;
void cleanup();
void main()
{
struct NewWindow OurNewWindow;
struct Window *OurWindow;
struct TextAttr TxtAtt;
struct TextFont *Font;
/* Open the Intuition, Graphics and Diskfont libraries */
if (! (IntuitionBase = (struct IntuitionBase *)
OpenLibrary ("intuition.library", REV)))
exit (5);
if (! (GixBase = (struct GfxBase *)
OpenLibrary ("graphics.library", REV)))
cleanup(5);
if (! (DiskfontBase = (struct DiskfontBase *)
OpenLibrary ("diskfont.library", REV)))
cleanup(5);
[p32]
/* Initialise OurNewWindow structure */
[p33]
if (! (OurWindow = (struct Window *)OpenWindow (&OurNewWindow)))
puts ("Couldn't open the Window. \n"):
CloseFont (Font) :
cleanup (5) ;
}
SetFont (OUR_RP, Font) ;
/* Tell the Text routine what colour to write the text. */
SetAPen(OUR_RP, 3) ;
Move(OUR_RP, 30, 50) ;
Text(OUR _RP. "Hello World - In a new font!", 28) ;
/* There are 28 characters in the string */
Move(OUR_RP, 30, 70) ;
Draw(OUR_RP, 270, 70) ;
/* Wait for user to close the window */
Wait (1<<OurWindow->UserPort->mp_SigBit);
CloseWindow(OurWindow);
CloseFont(Font) ;
cleanup(0) ;
}
/* Close the libraries that we opened and exit */
void cleanup(status)
int status;
{
if (IntuitionBase)
CloseLibrary(IntuitionBase);
if (GfxBase)
CloseLibrary(GfxBase);
if(DiskfontBase)
CloseLibrary(DiskfontBase);
exit (status);
}
[p34]
by Stephen McGerty
For those of you learning how to use C, here are a few hints that make life a little easier. First, the sacred law
s of the compiling languages.
1. If you forget to save your source code to disk before running your program, it will irrevocably crash your machine. (Exceptions to this rule are only caused by divine intervention or just staggering luck, and never actually happen when needed.)
2. When you and the compiler start to have differing ideas about the definition of a working program, and you start to say things like "I'm sure it's right. and "There is nothing wrong with. 19 ", just remember one thing: you're wrong.
3. The rate of loss of hair is directly proportional to the length of time since you last made a backup (when your machine crashes, which it always does when you haven't saved; see first law).
4. The speed of your reboot sequence is inversely proportional to your frustration with the whole idea of a compiler language.
5. When learning: things start bad, usually get worse, and finally begin to get better.
So in general, when you are starting to learn C, be patient with your programs which cause all sorts of pretty patterns on the screen when they should be playing nice music, and those that make nice music when they should be making pretty graphics.
C is very pernickity about upper and lower case letters. For example, GfxBase is right, while Gfxbase is wrong. The basic C commands should be put in lower case - if, for, while etc. Library routines like Move() and Draw() must be typed correctly - move() and MOVE() are wrong.
Try and structure your program neatly on the screen, so as to avoid putting too many curly brackets in the wrong places. C lets you away with murder. Restrict yourself by sticking to conventions, either your own, or ones you picked up from others. Some people put the curly brackets on the same line as the for, while others put it on a line all by itself. It doesn't matter what you do, so long as you stick to it. This makes reading your own programs a lot easier when you go back over them later.
[p35]
It may sound morbid, but if you keep saying to yourself "I bet this will crash" then you will have less chance of being disappointed than if you say "I bet this will work". In other words, if you come to terms with the fact that you will have a few crashes every now and then, you will have jumped the major hurdle of compiler programming. The rest, I found, involves a lot of experimenting, a good deal of fun, and a gradual reduction in the number of crashes experienced.
____________________
by Eddy Carroll
Since the CUGI Amiga public domain library is currently being reorganised, I thought I'd take a look at what there is to look forward to in the coming months. All the programs mentioned here are currently available on the Infomatique BBS (01-302970) and will shortly also be available through the Amiga library.
Many of you may be familiar with Snipit! on CUGI Disk #16. That nice program allowed you to snip text out of any Intuition window and copy it into the keyboard buffer, as if you had typed it in. Now we have Snap which does the same sort of thing only better. Some of the advantages it offers over Snipit! include:
• Works with any font size up to 16 x 16
• Works out the correct font to use from the window's RastPort
• Works with fonts positioned anywhere in the window
• Rectangular columns of text can be cut out
• Snapped text is stored in the clipboard
• Graphics items can be snapped into a popup window
• Text can be pasted back using a keyboard sequence
• Uses "walking ants" for the selection rectangle
That should be enough to whet your appetite! The current version has a small bug which shows up when pastiug numbers into a window that has redefined the numeric keypad, but a fix for this is imminent. In the meantime, try it - you'll like it.
[p36]
How many times have you tried to put together a fully booting Workbench disk with some extra utilities installed on it, only to find that there isn't enough room to fit everything on? Power Packer is designed to help you get around this problem. It crunches almost all kinds of programs so that they take up typically 20-50% less room on disk. Unlike archive programs such as ZOO, Power Packer uncrunches programs automatically when you run them, so that using a crunched program is just like using the original pro. gram, except for a small additional delay after loading while it decrunches. Depending on the program, it may in fact load quicker than the original, even with this added delay, since there is less data to read from disk.
Power Packer is professional quality software, written completely in assembler for speed. It has a full Intuition interface and offers a large variety of options which allow you to trade off compaction against speed, modify program files in other ways, and convert files crunched using other programs into Power Packer format. It is shareware, with a registration fee of $10.
"Not another IFF picture viewer!", you might be saying to yourself. Well, Zhow does indeed display IFF pictures. However, unlike just about any other viewer I've seen, it can display ALL the IFF pictures I've been able to throw at it, including those impressive overscanned HAM pictures that were originally transferred from a Sun Workstation (you know, the Racing Car, Fighter Jet, Honda etc).
As if that wasn't enough, it also displays them at high speed, runs from Workbench, and can display simple slideshows. Best of all, it handles pictures larger than the full screen, and lets you scroll around them with the mouse. It uses a very clever and intuitive mechanism for this; moving the mouse to any corner of the screen displays that corner of the picture, while moving it to somewhere in between scrolls the picture appropriately. You can also force low resolution mode to be used, for a "zoom-up" effect on high resolution pictures.
All in all, Zhow is the best IFF viewer I have seen for the Amiga. It sets out to do a simple task and does it extremely well.
That's it for this installment. Until next time.
[p37]
by Stephen McGerty
Many yonks ago in a land many minutes away (by Concorde) a bloke named St. Thomas More wrote a book called Utopia. It described a perfect land, where there was no crime, no gambling, no swearing ... in other words, a place which was no fun to live in, as there were no problems in life.
Imagine the perfect computer; biological memory which 'grew' as your needs expanded. Loads of really really fast processors (we're talking fifty Mandlebrots a second for smooth zooming in). Not to mention better than HDTV resolution with an almost infinite number of colours to choose from. Finally, you would need an OS which accepts commands by thought control. Just to make programming a bit easier, you could go to the thing with only the vaguest idea of what you want, and it would write the whole program for you. To finish it off, it would need an infinite capacity storage device which would be as fast as the memory itself (well maybe a teeny bit slower). Yup, all this for £1.95 including a free copy of Batman, a monitor, a laser printer, a desk, a house to put it all in, a plug and an ESB station to plug it into (£1.45 without the copy of Batman).
But seeing as 'Utopia' meant 'nowhere', our wonder Speccy will probably never exist, and so we have to make do with our mere Amigas. Or rather, we should try and make life a bit easier on ourselves and use the right software to protect us from the intricate details of the GURU just as we are trying to do a vital backup. For example, a well known command shell called CSH can make the CLI a hell of a lot easier to use. When using compilers, there is nothing more annoying than having to reboot the machine when your program (which has as many bugs as Gruier cheese has holes) crashes for the hundred and first time.
Now, its all fine and dandy for those people who have Kickstart 1.3. These lucky sods can put all their compiler gunk in the recoverable ram disk, called RAD: (or RAMBO:), and then get the machine to boot off this when their friendly GURU visits them. This makes booting up again a very quick and painless operation.
For those of us left with Kickstart 1.2, it would great to have a short program which makes the RAD: recoverable drive the boot drive. This is basically the message (or rather plea) behind this whole passage. I kuow it is possible to have a bit of code run before the ordinary DFO: bootup (how else do those FastMem killer programs work?) so why not have this bit of code redirect the bootup sequence to RAD:?
[p38]
Dear Stephanie,
I am at my wit's end and you are my only hope. I will tell you what my problem is. I have two sons and they are as different as chalk and cheese. The first is very heavily into computers. He stays up all night playing, programming and de-pesting (or whatever it is) programs. He gets hardly any sleep, doesn't eat meals or if he does it's never with the rest of the family, never goes out with girls, and his friends are the weirdest bunch you have ever seen. Whenever I can get into his room, there are bits of food, wire, solder and clothes everywhere. It's worse than the morning after the monkey's tea party and I'm very proud of him.
My problem is with my other son. He always dresses well. He has lots of normal friends. He studies very hard. His room is always spotlessly clean. He is extremely courteous to his parents, giving them the recognition they deserve. He always eats with the rest of the family and then insists on washing the dishes. He has a girlfriend whom he says he's going to marry some day after he has qualified his accountancy exams and she her law exams. What I want to know, Stephanie, is where did I go wrong with my second son? He is absolutely perfect. So perfect it's sick. I hate what he stands for, and if I hadn't been there when he was born I'd swear he was someone else's child. What can I do Stephanie? Please help me!
Sincerely yours,
Mrs. Smythe-Jones,
Booterstown.
Dear Mrs. Smythe-Jones,
When I read your letter, it sent a shiver of revulsion throughout my body. I had heard that there were such children but only in whispered tones at parties. It is a generally accepted theory that the levels of radiation, smog and all the other pollutants have on certain days ( and they are very few) combined into a cocktail which on the day of birth is the first lungful of air that the child gets, and that this causes a chemical reaction in the brain which ultimately results in the Perfect Euman. There is eztensive research being done on the problem, but as yet they are nowhere near a solution. Your only consolation is that they don't suffer at all, so it's best to let them be, to live out their lives in what they regard as normality.
[p39]
However, you must be warned that some of them have gone on to what they regard to be the ultimate aim in their life. It has happened only once in the history of mankind but we live in terror of a second. Their ultimate air is the "Presidency of the United States" and the last time it happened was when Ronald Reagan was elected.
With deepest sympathy,
Stephie
Dear Stephanie,
I recently got a lovely present of Dolphin DOS for my Commodore 64. It came with nice clear instructions on how to install it. I had no trouble installing it in the 1541 (once I had cut away the obstructing wires). However, it then said to desolder a few things inside the C64 using a 25 watt iron. I tried prising them out with my steam iron (240V - it's all the same, isn't it?) but they wouldn't budge; it was as if they were frozen in place.
This gave me an idea - I turned on the oven to Gas Mark 6 and cooked the circuit board for a little while. When it was a nice golden brown, I took it out and tried with the iron again. This time, everything peeled away nicely. I then proudly inserted the remaining components of Dolphin DOS and connected it all up together.
I plugged it in and turned it on, and there was a loud BANG! Then all the lights went out. I was sure I hadn't read about this particular effect in the manual, but it was too dark to check. I brought it down to the local computer shop, but when the man behind the counter saw it, he made some comment about how I wasn't going to get him on Candid Camera. Some people are so strange ...
Yours Puzzledly,
Fergal O'Flaberty,
West Cork.
Dear Fergal,
I'm afraid I can't help, but I know a man who can! Contact Brian Ward, the CUGI treasurer - he has had ample experience in these matters.
Best of luck,
Stephie
[p40]
by Rocco Matassa
This issue, instead of the crossword (I'm in too good a mood) we will have the anagram. There are five anagrams in each catagory. The prize for the first correct entry received will be ... wait for it ... a holiday for two, to the last remaining bastion of communism in Europe, Albania! Just complete the form on page 197 and you could be pony trekking your way to the best winter holiday of your life. Entries can only be accepted on official forms.
To start you off, these are no light weights.
1. Halt Babs back
2. DP rule peep
3. I'm the Rosa
4. In mine road
5. Tame lilaac
Soaps are not the only place affairs take place, currently.
1. A map Nora
2. Kew weens
3. Used stay, rift
4. When sting
5. Quit some nite
I'll show you something, if you'll show me something.
1. Shout "tee hunt"
2. Heat meat
3. Hint, I'm beacon
4. Lo Green
5. Pits, tie gaming
To round off, how about a little exercise.
1. Moist darts, sup
2. Dr Dan, sang T
3. En-rooks
4. Us skid, "Nay"
5. Cops, Sir Petals