Contents | Index | < Browse | Browse >

Written by Anthony Hoffman, includes material from Harry 'Piru' Sintonen and Amiga History Guide.


A3000 Booting Problems

After power on, the Amiga begins executing code from the KickStart ROM which performs a number of tests on the motherboard's hardware.
During this process, the screen colour is updated through dark grey, light grey and finally white. If an error is detected, the screen colour is changed to give some meaning of the error:

RED = Kickstart ROM error Two ICs in A1200, A3000, A4000
BLUE = Custom chip problem Denise Paula Agnus
GREEN = RAM error
YELLOW = The CPU has found an error before the error trapping software (Guru) has been activated.
Also caused when the Zorro riser card is not fitted (OS2.x and 3.x requires the A3000 Zorro riser to be fitted). Common sign of this is when boot colors cycle through grey, white, then yellow.
LIGHT GREEN = CIA problem
LIGHT GREY = if stops at grey, CIA can be defective
BLACK/STRIPES ROM or CIA
BLACK (No video) = refer to comments below

No video (black) can be caused by:

Other errors (generally relating to the keyboard) are indicated by the caps lock LED flashing:
One blink . keyboard ROM checksum error
Two blinks .. RAM failure
Three blinks ... watchdog timer failure



CPU test using caps lock key LED

The caps lock key can be a useful diagnostic feature to see if the CPU is processing data from the CIAs.
When caps lock is pressed, the keycode is buffered in CIA U350 which generates a level 2 interrupt (_INT2) to signal the CPU it has data to be sent. At the same time the keyboard is acknowledged and the caps lock LED is toggled on/off.
The keyboard buffer size in U350 is approx 10-20 bytes, so after this is fill, the CIA stops sending acknowedgements to the keyboard, so the LED no longer turns on and off

In summary, if you repeatedly press caps lock about 20 times and eventually the LED sticks on or off, it means the CIA's buffer is full because the CPU is not running to read the buffered data. Check the no video problems listed above for possible causes of the CPU not running.

If the caps lock LED is reliably turning on and off, it's a good indication that the system ROMs and CPU are running.



White boot screen, but resets continuously

The power supply generates a 50Hz timing "tick" (or 60Hz for America) which is received by CIA U350 for use as an accurate time reference.
If this signal is not present, the computer will enter a continuous cycle of booting to a white screen then resetting.
This can be the case when a 3rd party power supply is used (e.g. an AT power supply) which does not provide the timing tick, or if the standard A3000 power supply develops a fault.
To get around this problem, move motherboard jumper J350 from TIC to VSYNC. VSYNC is derived from the motherboard crystal oscillators, so is not as stable as the mains power supply frequency. Using VSYNC instead of AC mains synchronisation can lead to the system time running fast or slow when the computer is running. The correct time will be restored when the system is rebooted, as the time is re-read from the battery backed real time clock during startup.



A3000 power supply common faults

See the A3000 common faults and repair suggestions here.



Amiga power on procedure
Written by and used with permission from Harry 'Piru' Sintonen.
  1. Power on/reset, early setup
    At power on the amiga hardware is in undefined state. Certain things do happen though, the ROM overlay bit in CIA-A is enabled, and thus the Amiga Kickstart ROM appears at address 0. The M68K reset/poweron cycle fetches two longwords from address 0. Since the ROM is mapped, these two longwords are read from the ROM beginning. For KS 3.1 they are:
    0x11144EF9
    0x00F800D2

    The first longword is the initial SSP (supervisor stack pointer), and the 2nd longword is placed to PC (program counter). The cpu will then begin code execution at address of the PC.

    The kickstart rom early startup will now set up proper temporary SSP pointer (0x400, it will be chipmem once overlay is turned off), checksum the kickstart. If ROM at 0x00f00000 contains valid ID, the execution is diverted there (BPPC uses this for example). The custom hardware is initialized to known state. The overlay is turned off and chipmem will now appears at address 0 (and thus the temp stack will work now). CPU vectors and other low level setup is done. ColdCapture is taken at this point, if available.
    The CPU type is determined.

    The system probes the amount of chip memory, and sets the initial memory header up, from which temporary execbase is allocated. exec.library is initialized, and ranger (slow) memory amount scanned. Exec will now know the chip, slow memory, and have all the functions available. Finally the ROM is scanned for resident tags (basically the individual ROM components initialize later). The residenttag array is priority ordered. The residents are now initialized by calling InitCode(RTF_SINGLETASK, 0);

  2. Initializing RTF_SINGLETASK modules
    One of the very first modules is expansion.library. It will probe the system for Zorro expansions and initialize them. All found expansions are added to expansion.library ConfigDev list.

    exec.library is initialization will now commence, and allocate new execbase. Any info from the old exec is moved to new one. This tries to make sure the exec is moved to fastest possible memory available. At this point supervisor stack is also allocated and SSP is made to point to it. Next the system will prepare itself for multitasking. Various functions are patched depending on the CPU type. Initial task is prepared and fired up. From now on, the system is running with multitasking enabled. CoolCapture vector is run at this point, if available. Next stage of the initialization is entered with InitCode(RTF_COLDSTART, 0). The execution will never return here (if it does, the screen will be rendered all purple and system will hang).

  3. Initializing RTF_COLDSTART modules
    This is the real deal: Most resident modules are RTF_COLDSTART and will be initailized in sequence now, adding various libraries, devices and resources to system as they go.

    trackdisk.device is available in most (if not all?) amigas. It will probe the system for floppy drives and add DFx entry to expansion.library MountList entries. DF0 has higher priority than other possible units.

    Any other media devices (such as scsi.device) will also probe the hardware for existing bootable medium (for hard disk or other block medium it is RDB with bootable partitions) and add the mountable / bootable entries to MountList if found.

    Eventually system runs into bootstap module. This is the final module in which either the user is presented with 'Please insert floppy to boot' -animation, or if any bootable MountList entry is found the system is booted off it. If there is a bootable entry found it is now initialized and booting will commence.

    DFx/trackdisk is special and the floppy disk is probed only at this time. Also, A1200/A600 bootable PCMCIA card is special is handled here. These units are also probed for bootable media while the 'please insert floppy to boot' -animation is played.

    trackdisk.device DFx is special since it will try to load a bootblock off any inserted disk and if proper one is found it will be executed. Normal system bootblock contains a code that will FindResident() dos.library resident and InitResident() it. The bootblock might choose to do something else aswell, such as to load a demo/game using custom loader routines and never return or try continue initializing system.

    For most harddisk controllers the bootblock is just ignored and the bootable MountList entry will internally FindResident() dos.library and call InitResident() for it.

  4. dos.library and RTF_AFTERDOS.
    dos.library will set up itself like any other library. It will also set up system vectors so that initial shell will be able to bring up system components (shell, con, ram, ffs etc).

    At this point "Initial CLI" process is started. It will be fed the highest priority bootable volume from MountList. This entry will become SYS: device. The data is passed to the Initial CLI by sending a startup packet to it using PutMsg(). The very first exec task will now commit suicide by calling RemTask(NULL), and the execution will continue wih the "Initial CLI".

  5. Initial CLI and shell, startup-sequence
    Initial CLI (shell) will parse the input data from the startup packet. This data will indicate that this is the "Initial CLI", and will instruct shell to call special private vector is dos.library to set up further data. This function will among other things set up some initial handlers (PAR, SER, ... CON, RAM), assigns, add some residents such as Shell, handle ks 1.x compatible :devs/system-configuration, set up CLI for the process. At this point any RTF_AFTERDOS residents are executed with InitCode(RTF_AFTERDOS, 0). Finally depending on the expansion.library flags (eb_Flags), force the shell console to open (no EBF_SILENTSTART, not set by KS 1.x bootblock, but set by 2.x+ one), and open :S/startup-sequence of the system disk (no startup file is used if EBF_DOSFLAG is set, this is used by bootmenu "boot with no startup-sequence"). The CLI now has stream to fetch command lines from (startup-sequence), or no stream in which case it will drop into shell prompt.

  6. startup-sequence
    :S/startup-sequence will execute whatever commands are there.

    If EBF_DOSFLAG was set, the shell will wait for user to enter commands.