Commodore Amiga 500

Overview

Please note: screenshots in this section were taken using RGB SCART upscaled unless otherwise stated.

You can see an Amiga 500 below (UK version) which looks somewhat like a C64C that has been stretched:

The Amiga 500's keyboard was built in to the unit as typical of microcomputers of the time but the power supply was separate and quite bulky. Two LED's at the top right indicate that the power is on and whether there is disk access (note that varying colours were used for the LED's based on the stock Commodore had at the time). At the back of the computer are the following ports: joystick 1 and 2, Right and Left audio, external disk drive, serial, parallel, power, RGB video and mono composite video.

The computer can be connected to a compatible monitor (e.g. Amiga 1080 monitor) via the RGB video connector but by using the Amiga A520 video adapter a TV or monitor with composite input could be used. It's odd that the computer has a mono composite connector, possibly because Commodore thought it would be useful for word processing (that is, if you are just working with text, a high resolution monochrome monitor would provide for a clearer display) or to encourage customers to buy a colour monitor.

If you are using an Amiga 500 in modern times I highly recommend to use RGB, perhaps using an RGB to SCART lead as the colour composite from the video adapter is quite poor and can make reading on-screen text difficult. Alternatively, it is possible to connect an Amiga 500 to a monitor with VGA input using a suitable lead/adapter but the monitor must be able to support 15KHz input.

A joystick or mouse could be connected to either joystick port depending on the software being used and adapters were made to allow switching between a joystick and mouse on a single port rather than keep plugging and unplugging them. A typical use of the serial port would be for connected to a modem and the parallel port to a printer but it's not too difficult to interface your own circuits with those ports.

The operating system core, called Kickstart, was stored in ROM (version 1.2 or 1.3 were standard for the A500) but to actually be able to use the machine software had to be loaded from a floppy disk or hard disk, such as a bootable game or Amiga OS. Many people called the Amiga's operating system Workbench when actually Workbench is the GUI interface for managing files and launching applications which today we would typically call the desktop.

When the Amiga is powered on you are greeted with the boot screen prompting for the insertion of a floppy disk as follows asking for the Workbench disk:

As previously mentioned you can use other bootable software also.

If you wanted to use the Amiga as a computer to do, for example, word processing or programming, typically you would load the Workbench disk and you can see the startup below:

Information is reported in a shell (a.k.a. CLI for command-line interface) as it runs a startup script, essentially a series of commands to configure the computer. You can think of the shell as the equivalent to the Command prompt program in Windows, accepting commands and processing them.

Notice the mention of no battery backed up clock as there was no real-time clock (RTC) standard on the Amiga 500; you either had to enter the date and time whenever you loaded Workbench or make use of an RTC expansion board. The Amiga 500 plus, a slightly better version of its predecessor, did feature a built-in RTC and battery but on the downside the battery was prone to leak, something to consider should you want to buy one secondhand.

When the startup script has finished the window will close and you will be dropped into the Workbench environment that doesn't look too different from the modern computer interfaces we are familiar with today:

You can see the mouse pointer at the top-left of the screen and the amount of RAM available is reported in the menu bar, which has two buttons (called 'gadgets') on the right which control depth of the whole screen. Yes, the Amiga supports multiple screens and you can switch between them using the depth buttons and can even drag the menu bar down with mouse left-click to peek at the screen behind it.

Icons for the RAM DISK and the Workbench disks are visible and can be opened up to be explored with double left-click but only files with a matching icon file have a visual appearance. While it should be obvious that double clicking the Workbench1.3 icon will open a window showing the contents of the disk and you can do the same for the RAM disk you may wonder what a RAM disk actually is. The RAM disk used a portion of the computer’s RAM to act as a fast drive that files could be copied to or from, growing in size to accommodate files as they are added with its size only limited by how much RAM the system has to spare. Files accessed from the RAM disk are retrieved much quicker than from a floppy disk, making it easier to work with multiple disks with only one floppy drive. Since the files are stored in RAM, however, anything copied to the RAM disk is lost when the Amiga is restarted or powered off but you can create a recoverable RAM disk known as a RAD disk whose contents survive a restart but not power loss.

In the next screenshot we can see that the Workbench disk has been opened, revealing its contents in one window and in the window underneath I have opened up the Utilities drawer (a folder, as we would call something similar nowadays) that is hidden under the menu:

The windows can be moved by left-clicking and dragging it by its title bar, the window can be resized by left-clicking and dragging it by the sizing gadget in the bottom-right, and to move the window behind or in front of others you have to click on the corresponding depth gadget in the top-right. The window can be closed by clicking the close gadget in the top-left and the contents of the windows (the icons) can be scrolled horizontally and vertically by either left-clicking one of the four arrows at the sides or by left-clicking and dragging the scroll bars (if there is space to scroll).

It should be clear now that the left mouse button is used to make selections and as with some modern operating systems right click is used to bring up a menu but with the Amiga the menu items always appear at the top of the screen in the menu bar not in the window itself so in a sense Workbench is sort of like Mac OS.

In the screenshot above I have brought up the menus by pressing and holding the right-mouse button and then I have moved over to the Workbench menu while still holding the right-mouse button. To select a menu option you choose it with the mouse pointer and let go of the right-mouse button which seems quite odd compared to modern systems. Some of the menu options require you to left click an icon first (Info being an example) others do not require a selection first (such as Redraw, found in the Special menu). The menus available will vary depending on whether a program is running (which will have its own menus) or if Workbench is active.

Workbench comes with many useful programs, from Notepad for simple text documents to a clock for displaying the timer to the Say program for speech synthesis but one of the most useful is the Shell program which provides functionality not available in Workbench. You may have noticed the Empty drawer and that is there because there is no means to create a new drawer from within Workbench which is why the Empty drawer is there for you to copy and use by selecting it and then the Duplicate option from the Workbench menu. From the Shell, however, you can create a new drawer using the MAKEDIR command as well as do a lot more. For a list of commands and other useful information please see:

https://dfarq.homeip.net/common-amigados-commands/

In the upcoming image you can see that I have done a directory listing in the Shell using the DIR command:

The Shell doesn't have a close gadget, you have to use the ENDCLI command which was possibly done so you don't accidentally close the window.

There was a lot of software made for the Amiga 500 including games, utilities (e.g., file managers), word processors and art programs with some notable examples being Lemmings, DPaint, WordWorth, Out Run, as well as many demos. Because of the Amiga's internal disk drive some games took advantage of it by saving the player's progress to the disk.

We will now briefly look at a few Amiga games, starting with Life & Death:

Life & Death is a point and click graphical game from The Software Toolworks, released in 1991, in which you try to keep your patients alive by hopefully diagnosing them correctly and administering the right treatment or it's back to class for you. For a full playthrough please see:

A fun platformer called James Pond 2: Codename: RoboCod from Millennium Interactive Ltd., released in 1993, which sees our hero with extendable body attempting to survive 50 levels of platform action. Notice that my copy of the game is a 'cracked' version and this is very common (and consequence of buying a secondhand copy), with a 'trainer' added to the start of the game to allow various cheats to be enabled not normally available.

For a complete walkthrough check out this video:

Next up is Titus the Fox: To Marrakech and Back from Titus France and released in 1991, a platformer that sees Titus trying to save his kidnapped girlfriend Suzy, which means 15 levels to contend with to get her back.

A playthrough of the entire game follows:

To give an idea of some of the other games available for the Amiga have a look at this compilation:

Since the Amiga 500 used floppy disks as its primary storage (unless a hard disk was fitted) and because of how unreliable they are, getting software to load can be difficult, especially as disks have gone bad over the years and can easily be damaged by magnetic forces, rough handling and extreme temperatures.

Here is an example in which I was trying to load a game called Life & Death (which note first loads into the Workbench environment and with a custom mouse pointer) and a read/write error popped up but fortunately the game was able to load after clicking the Retry gadget a few times. Faulty disks can sometimes be fixed although it is recommended to use a dedicated repair software and backups should always be made.

PC's cannot read or write to Amiga floppy disks but an Amiga can read PC disks, and it is possible to transfer files between PC and Amiga using Amiga Explorer-see the Commodore Amiga 600 page for more information. We do also have modern alternatives to a floppy drive such as a GoTek or similar floppy drive emulator which interfaces with the Amiga like a normal floppy drive but uses an SD card or flash drive to contain disk images, providing for more reliable access to files.

Not always are the floppy disks at fault as floppy drives can cause disk errors because of dirt that builds up inside, to clean a floppy drive you can either use a kit or, if you are experienced enough, you can open up the drive and clean the read/write heads with a cotton bud dipped in isopropyl alcohol. Please see the troubleshooting section for further help.

Many of the chips in the Amiga 500 are socketed so it is possible to change them if, for example, an IC has stopped working. The downside of socketed ROM's is that they provide a less reliable connection than soldered chips. Because of this it may be necessary to re-seat the chips if problems develop. The kickstart ROM's are also socketed which means they can be swapped for a newer version.

A familiar screen for many users of an Amiga is the so-called Guru meditation which resulted because of a fatal hardware or software issue and can be thought of as similar to the Blue screen of death known to many Windows users. This is what a user would be faced with (but with a flashing red outline):

The displayed error number, especially in the pre-Internet days, would have been meaningless to most people. The left mouse button can be pressed to reboot the system and provided the error did not happen again the system could be used as normal. Please see the Wikipedia article for more information about Guru meditation:

https://en.wikipedia.org/wiki/Guru_Meditation

The Amiga 500 was the best selling of the Amiga computers, not surprising thanks to its fantastic graphics and sound, at a considerably cheaper price than an IBM or Apple computer even though their audio and graphics capabilities were inferior. It was in Europe that the Amiga 500 sold especially well, not North America where Commodore International was located, and this could have been in part due to consumers in European countries such as the UK opting for using the Amiga as a games machines rather than buying a games console. There is also the factor that in North America IBM PCs were the more common choice for the home as well as for business use.

Amiga 500 computers aren't uncommon today either but as with most vintage computers they can set you back a lot in terms of money so if you would like to experience (or relive) the Amiga a much cheaper option is to use an Amiga emulator, of which WinUAE is a great choice. Here is a guide:

https://www.howtoretro.com/winuae-setup-amiga-emulator/

There is also The A500 Mini, which emulates the Amiga and has 25 games built in. Please see my The A500 Mini page for more details.

Accessories

Amiga Action Replay MK III

Please note: screenshots in this section were taken using RGB SCART upscaled.

The Amiga Action Replay MK III from Datel was released in 1992 and is compatible with Amiga 500, 1000 and 2000, and like the Action Replay devices for consoles the Amiga version was also used primarily to create cheat codes although a lot more advanced and can even be used to test certain features of an Amiga. The A500 and A1000 Action Replay versions plug into the Amiga's left side expansion port whereas the A2000 version needs to be plugged into the Amiga's CPU slot. This section will concentrate on the A500/A1000 version of the Action Replay.

The Action Replay MK III builds on the MK I and MK II by featuring a 256KB O/S ROM which offers a deep trainer, ability to switch between PAL and NTSC (if supported by the Amiga's chipset), keyboard setmap program, file requester and more CLI programs have been added. Here is a link to the manual:

http://amiga.resource.cx/manual/ActionReplayMk3.pdf

Let's take a look at the Action Replay:

Top left of the Action Replay is the 'slomo' (slow-mo) dial which adjusts the speed, below that is a toggle switch to turn slomo on/off, and under the switch is a RED LED that will be illuminated when slomo is on (note that using slomo during disk access may cause issues). To the right of the Action Replay is a 'FREEZE' switch which can be pressed at any time (even when at the 'insert floppy' screen) to access the Action Replay's built-in screen. At the bottom of the Action Replay is the connector that mates with the side expansion port of the Amiga.

What is odd about the Action Replay is that the plastic enclosure does not go anywhere near the connector which not only looks strange but also increases the chance of damage to the circuit board. When inserted into an A500 (see below), however, no part of the PCB is exposed. But it is indeed a bad design since just the act of pressing the freeze button puts pressure on the Action Replay which could cause the Amiga to crash.

In the following screenshot I have pressed the freeze button to enter the Action Replay's built-in screen and it is reported that there is no known virus in memory. I've then typed the 'version' keyword to which is has reported that it's V3.17 and dated 12/17/91 (17/12/1991). After that I typed 'd' to give a disassembly (assembly language instructions) from the point at which the program was frozen (the 'insert disk' screen).

Next we'll look at the preference options screen which can be accessed by pressing F3, starting with the first page. The mouse moves the hand pointer graphic and left-click is used to make selections by clicking on the boxes. It is worth mentioning that certain options, such as 'color control' which lets you change the background and foreground colours, can be useful for testing that the Amiga is working correctly.

On the next page (below) we have some more preference options:

This is only a quick look at the Action Replay and I will be learning more how to use the device and see what it can do such as for programming.

Programming

Please note: screenshots in this section were taken using the WinUAE emulator.

I have many fond memories of using an Amiga 500 including programming the Amiga, mainly in assembly language as well as BASIC, impressed with the graphics and audio capabilities. This section is not intended to be a programming tutorial as such but instead a look back at some software I wrote in 2004 in assembly language on my Amiga 500, to give an idea of how a 'typical' program works, including a game I started writing which I may pick up again soon. However, I will go into detail how the programs work so it would be good to have some familiarity with 68000 assembly language.

If you are very serious about programming the Amiga in assembly language and want an in depth guide then a good book to read is Total AMIGA assembler by Paul Overaa of which you can read online at:

https://amigasourcecodepreservation.gitlab.io/total-amiga-assembler/

I got into assembly language programming on the Amiga 500 thanks to the Amiga Format #39 magazine cover disk which gave away a copy of the Devpac 2 assembler IDE software with example source files from Bullfrog and the magazine contained a tutorial on writing a game. I recently managed to find a scanned in copy of the issue so that I could be reminded how to use the software:

https://commodore.bombjack.org/amiga/magazines/amiga-format/amiga-format.htm

The cover disks can be downloaded from:

https://archive.org/details/amigaformat039disks_1992-10

Note: Devpac is on disk A.

I had already transferred my source files from my floppy disks to my PC and I will be providing them as downloadable from this page should you want to use them. If you want to use any of the files in an emulator such as WinUAE you can set up a hardfile as the folder containing the files on your PC for easy access within Devpac. Be sure to boot the cover disk (or whatever Devpac disk you have) from df0: as running Devpac from other drives I have found causes issues.

After the system boots Devpac will auto run and you can load an assembly language file (or any other text file) using Project->Load. Below is a screenshot showing my game loaded into the Devpac window:

To assemble the source file use Program->Assemble which will present you with a number of options:

If you want to be able to run the program after assembling then set 'Output to' to Memory and if you would to see the listing as it's assembled then change 'List' to Screen but keep in mind especially for a long listing the assembling process will take longer. To write your source as an executable to disk type a filename in the box next to 'Disk:' and then click the 'Disk:' button. Then click on the Assemble button and check what results you get:

If you don't get any errors (as above) then press a key to exit the assembler results and then use Project->Run to start your program. Otherwise, if there are any errors you need to correct them in your listing and then assembler again.

In the screenshot that follows you can see that I had implemented the start of a Mario-like game but this is actually from a different listing, Game (2).s, which we will look at later.

The level blocks actually spell out 3+1=4, if I remember correctly a nod to Sonic 1 in which you would see random words such as 'CPU' in the Spring Yard Zone.

When writing programs in assembly language there is a lot of code required just to do the basics but in Game (2).s I implemented horizontal movement using joystick (in port 2) left/right, horizontal scrolling, and gravity, with the ability to exit the program using joystick fire. Game.s is an earlier version that doesn't have gravity implemented and has a simpler level layout.

Before actually looking at some source code I just wanted to mention briefly Devpac 2's debugger MonAm which displays CPU registers, disassembly and memory values and provides various commands accessed using keyboard shortcuts. MonAm can be accessed using either Project->Debug or Project->MonAm with the difference being the Debug option will display the disassembly and memory dump for your program assembled into memory whereas the MonAm option will prompt you for an executable to load an doesn't require an assembled program in memory. A screenshot of MonAm follows:

Note the bug (spider?) cursor which is kind of fitting as there seems to be no use for the mouse pointer while MonAm is active (there aren't even any menu options). Use Ctrl+C to quit MonAm .

We are going to start with one of my very simple programs that moves an immediate value to a CPU register and we will run it in the debugger so we can see its effect as it doesn't otherwise do anything useful. The source file is called tst1.s and is downloadable from the bottom of this page but I have reproduced it here also:

moveq #$14,D0

rts

All that the program does is move hex value 14 into register D0 using the moveq (move quick) instruction and then terminates the program with rts. To get the program running first load it into Devpac, assemble and then choose Debug from the Program menu. Note the value of D0 in the Registers section, and you should see that the PC register is pointing to the first instruction (moveq) of our program. See that in the Disassembly PC section our program instructions are listed (as well as whatever happens to be in memory after it) and in the Memory area there is a memory dump of our program (and the other data after it). Very helpfully, the debugger will identify Amiga library function calls with their names in the Disassembly PC and Registers sections.

Press ctrl+z and you will see the moveq instruction executed and hex value 14 will be placed in register D0 and that is all our program does:

Use ctrl+z again and the rts instruction will be carried out and you will be returned to the Devpac editor; simple but great for beginners.

Next we are going to look at a more complicated program that I couldn't get working when I first wrote it so it will be a good opportunity to fix the bug(s). The code is supposed to use the DOS routine 'Write()' to display a message in the current window but when it's run it crashes the Amiga, causing a guru meditation. The source file is xWrite.s which is attached at the bottom of the page.

Looking at the first bit of the code which I'll present here tidied up:

;First we need to open up the DOS library using EXEC:

move.l $4,A6 ;Exec.library

lea DOS_lib,A1 ;I.e. dos.libarry

jsr -408(A6) ;Use Exec_OldOpenLibrary() since version no.'s not a problem

move.l D0,DOS_base ;I'll assume there were no problems since DOS.lib is in the ROM....

Keep in mind that this was only test code and is not written in the best way.

We want to use a DOS library function to write text to a window so we have to first open the DOS library using the Exec library. You can learn more about the Amiga libraries at:

https://wiki.amigaos.net/wiki/Libraries

Simply, a library is a collection of routines designed for specific tasks to handle files, graphics, and so on.

Looking at the first line of code above we load the 32-bit value from address 4 into A6 and because I used a 'magic number' it's not obvious what I'm doing. Address 4, known as ExecBase, is the pointer to the memory location where the Exec library is copied into RAM and is the only time we should specify an absolute address certainly when dealing with the O/S but we should really use some kind of identifier rather than just a number. By calling an offset to the ExecBase pointer we can call Exec library functions like we do with the jsr call on line 3 to use OldOpenLibrary().

There is a list of library offsets at:

https://github.com/jotd666/amiga68ktools/blob/master/tools/LVOs.i

Exec's OldOpenLibrary() is what we use to open the DOS library and functions similar to the alternative OpenLibrary() function except that there is no need to specify the version of the library we want access to. On the second line we specify the input parameter to OldOpenLibrary() by setting A1 to point to the string containing the name of the library to open, dos.library. DOS_lib is defined toward the end of the source file:

DOS_lib dc.b "dos.library",0

Going back to the code snippet we call OldOpenLibrary() using jsr and we then place the result in D0, the address of dos.library, into DOS_base, which is declared near the end of the source file:

DOS_base dc.l 0

Since the DOS library is contained in the ROM we always assume that it will be successfully opened and D0 will never be 0 (failed to open the library) but of course that's not good programming practice and is only suitable for rough code.

Let's look at the second section of code:

; Now that we have access to DOS, we can print the message:

move.l D0,A6 ;A6=DOS.base (just a reminder)

jsr -60(A6) ;Use DOS_xOutput() to find handle

The above 2 lines move the pointer to the DOS library into A6 and then calls DOS' Output() function which returns a program's initial output file handle, placed in D0 and will be non-zero if successful. As mentioned previously the program crashes the system if run, either from Devpac or a CLI window but if you step through it using Devpac's debugger it doesn't crash, greatly helping us to identify the issue.

If you step through the code, using ctrl+z (single step) for single instructions and ctrl+t (step over) for jsr calls, we can see that after calling Output() an invalid pointer is returned in D0 (D1 also as Output() puts the result in D1 before copying to D0). I know it's invalid because the debugger shows asterisks and the address is in an area normally unused by the Amiga 500 at least. I don't know why Output() returns an invalid pointer and as far as I can tell I have the right approach for the program since I found someone online using very similar code although their program didn't work either but they were getting zero from Output(). I could wonder if the issue is running the program from Devpac, that is, it doesn't get an output handle but running the executable from a CLI windows causes a crash.

If we continue to step through the code we can see that there isn't actually a serious fault until we try to close the DOS library, which is later on in the code:

; Now that our message has been printed, we should close DOS.lib:

move.l $4,A6 ;Exec.BASE (of course!)

lea DOS_base,A1 ;Address of lib to close

jsr -414(A6) ;Call Exec_CloseLibrary()

rts

We get an illegal instruction warning from the debugger when jsr -414(A6) is called and if instead we run the executable from a CLI window we get a guru meditation that is decoded as 'illegal exception', possibly a similar fault.

The issue is actually really straightforward to fix but is an example of how a small mistake can cause such havoc when programming in assembly. The faulty line is:

lea DOS_base,A1

and in fact should be:

move.l DOS_base,A1

If 'lea' is used then A1 is set to the address of the DOS library pointer DOS_base rather than the address pointed to by DOS_base which is what we want and what we get if 'move.l' is used instead. The reason the system crashes if we give the wrong address to CloseLibrary() is because the function tries to call the DOS library's Close() function which typically decreases a count value which was previously increased when OpenLibrary() called the DOS library's Open() function. So if we give an invalid library address to CloseLibrary() it will eventually call 'random' code (in uninitialised memory, for example) and crash the Amiga.

This is contrasted to earlier in the program when we used:

lea DOS_lib,A1

This is acceptable since we are passing to OpenLibrary() the address of the library string rather than an address held there.

Assembly language is not the only programming language in which you have to be very careful of using pointers correctly as anyone who has programmed using C will likely be able to tell you. As you will see when we look at my game source file later on I clearly realised my mistake but never updated xWrite.s.

Even with the fix, however, the program still doesn't work as intended even though it no longer crashes the Amiga, thankfully. The second fault is actually similar to the first one and is this line:

move.l _message,D2

For reference it is part of this section:

; Now that we have access to DOS, we can print the message:

move.l D0,A6 ;A6=DOS.base (just a reminder)

jsr -60(A6) ;Use DOS_xOutput() to find handle for current window

move.l D0,D1 ;DOS_xWrite requires handle in D1

move.l _message,D2 ;Address of ASCII message goes in D2

moveq #6,D3 ;Length=6 characters

jsr -48(A6)

The problem is that we are setting D2 to the address held at whatever address _message is pointing to which will be the first 4 bytes of the string (so by extreme chance text may actually be displayed but not what we actually wanted to output). We can't use lea as that only works with address registers but all we have to do is add a '#' to ensure we set D2 to the _message address:

move.l #_message,D2

Now we have a fully working program (downloadable as xWrite1V2.s) and if you run it from within Devpac you will hopefully see 'Hello!" briefly appear in the output window, alternatively you can run it from debug and after stepping over Write() press 'v' to switch to the output window to see the message (press 'v' again to go back to the debug window). You can also assemble to disk and run the executable from a Workbench shell.

Successors

In 1992 Commodore officially released an improved version of the original Amiga 500 called the Amiga 500 Plus (a.k.a. A500+) and was mainly sold in Europe. The A500+ features 1MB on board RAM (early versions only had 512KB), new versions of Kickstart (2.04/V37.175) and Workbench (37.67/release 2.04), built-in battery backed real time clock, and new Agnus and Denise chips, bringing small improvements to the Enhanced Chip Set (ECS). Unfortunately, the new Kickstart version did cause some games designed for the Amiga 500 to not run.

In late 1991 some supposed Amiga 500 units actually had the A500+ motherboard installed.

The original model Amiga 500 was discontinued in 1991 and the A500+ in June 1992 and they were followed up with the less successful Amiga 600 released in March 1992; to learn more about the Amiga 600 please go to Commodore Amiga 600.

In April 2022 Retro Games Ltd. released a miniature 'Amiga' system, The A500 Mini, that emulates a number of Amiga computers and has 25 games built in. Please see my The A500 Mini page for more details.

Troubleshooting

Amiga 500 Internal Floppy Drive Cleaning and Maintenance:

All content of this and related pages is copyright (c) James S. 2015-2022