Why does Amiga 500 reset when reading a faulty disk

Question

I have a copy of Syndicate disks for Amiga (I have original as well) and apparently the disk is damaged / faulty. It loads up to language selection menu, then tries to read disk and resets the computer... why does it do it instead of throwing read error? The original works okay, so the question is why does the machine reset on read error.

Answer 1

Syndicate uses a standard DOS format, and is completely OS compliant when it comes to disk operations. It also has no physical copy protection.

If the disk sectors where executable itself is stored were corrupt, you'd probably get a message at bootup: failed to load executable, something like that.

Now if one data file is corrupt, and the game doesn't check return value of the Read command, plus the game turns off all system requesters to avoid for instance that they pop up to ask for another disk and destroy the graphical screen set up by the game. So if there's a sector error, the system is silenced and no requester pops up either.

If the file is corrupt or truncated and packed (for instance with RNC packer) the unpacking severely fails and crashes the machine. It's worse when files are packed than when not packed. If a graphical file is damaged but not packed, graphical corruption can happen, and the game could still be playable, but with packed files, the crash is almost guaranteed.

And files in this game are RNC packed all right. For instance INTROPT1.PAK and most .PAK extensions. RNC (Rob Northern Cruncher) unpacking doesn't have safety and crashes when packed data is corrupt.

The disassembly of the relevant parts kind of proves that. This is the read file wrapper which returns the size read in D0:

dos_read:
    MOVEM.L D2-D3/A6,-(A7)      ;fe4d8: 48e73002
    MOVEA.L DosBase,A6      ;fe4dc: 2c79000fe3d0
    MOVEM.L (16,A7),D1-D3       ;fe4e2: 4cef000e0010
    JSR (_LVORead,A6)   ;fe4e8: 4eaeffd6 dos.library (off=-42)
    MOVEM.L (A7)+,D2-D3/A6      ;fe4ec: 4cdf400c
    RTS             ;fe4f0: 4e75

which is called by this routine:

LAB_110D:
    MOVEM.L D6-D7/A5,-(A7)      ;39898: 48e70304
    MOVE.L  (24,A7),D6      ;3989c: 2c2f0018
    MOVE.L  (16,A7),D7      ;398a0: 2e2f0010
    MOVEA.L (20,A7),A5      ;398a4: 2a6f0014
    MOVE.L  D6,-(A7)        ;398a8: 2f06
    MOVE.L  A5,-(A7)        ;398aa: 2f0d
    MOVE.L  D7,-(A7)        ;398ac: 2f07
    JSR dos_read        ;398ae: 4eb9000fe4d8
    LEA (12,A7),A7      ;398b4: 4fef000c
    MOVEM.L (A7)+,D6-D7/A5      ;398b8: 4cdf20c0
    RTS             ;398bc: 4e75

which is called by this routine several times without any error checking:

MOVE.L  D6,-(A7)        ;23afa: 2f06
JSR LAB_110D        ;23afc: 4eb900039898
PEA 8672.W          ;23b02: 487821e0
PEA LAB_1745        ;23b06: 4879000b1fb4
MOVE.L  D6,-(A7)        ;23b0c: 2f06
JSR LAB_110D        ;23b0e: 4eb900039898
PEA 500.W           ;23b14: 487801f4
PEA LAB_147D        ;23b18: 48790003f142
MOVE.L  D6,-(A7)        ;23b1e: 2f06
JSR LAB_110D        ;23b20: 4eb900039898

In the end, it really depends on how the game is coded. Other games could detect the error and stop with a message or a "rainbow screen" (palette cycling indicating that something went wrong). The development cycle of a game has always been very short, and programmers weren't very keen in handling all possible errors, unless they were using & re-using a special game engine from game to game, where errors were handled more properly.

Answer 2

There are two possibilities I think based on your description:

1. The Amiga doesn't have much in the way of graceful error handling at the best of times. The reboot you're seeing is the typical behaviour for Amiga games.

2. The copy protection on your copy of Syndicate is not happy.

For games that are programmed within the normal constraints of AmigaDOS, you may see a standard 'requester' that says "Not a DOS disk in device DF0" or something similar if there is a device fault. Games programmed within AMOS will have graceful error handling provided by the AMOS runtime - I would expect you'd see an error if you removed the disk part-way through a loading screen in Scorched Tanks.

However, most games use their own reading routines accessing the floppy disk hardware directly, with very little no thought spared for error handling. Two cases where a game might possibly be careful are disk swap detection (to give you another chance to put in a good Disk 2 rather than crashing entirely) and save game handling (since the game has to read, write and manage files to some extent).

The normal level-to-level flow of a game with multiple linear stages like Toki would work under the assumption that any code, graphics or music that the game requires will always be available and always be readable. (There isn't much the player can do to help if a game disk is faulty, really.)

So I expect what is happening is your game is blindly loading in some code or resources from your damaged disk into memory, then executing damaged code, or coming up with bad offsets from reading a table of resources (like a game level that now has 99999 width instead of 99). This would then result directly or indirectly in an illegal instruction exception, which is handled by something in the ROM (another answerer may know the exact term and location in ROM for this), which performs the reboot and shows the Guru Meditation message.

The only game I can remember that has what you'd call a 'read error' screen for its normal level loading is Desert Strike, which you can trigger by swapping disks mid-load or inserting the incorrect Disk 2 or 3 from a mis-matched set of DS disks.

It is also possible that a poorly cracked game may spontaneously reboot as part of the copy protection. Certain games would reboot if you fail the manual-based copy protection too many times, and if these checks are insufficiently patched out, the reset might trigger later on in the game if certain conditions are met.