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.
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
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.
There are two possibilities I think based on your description:
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.
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.