; Explanation of a (Non) DOS-Disk layout & Important disk-drive information ; ------------------------------------------------------------------------- ; ; Firstly a DS-DD (Double-Sided, Double Density) Disk-drive (like the ones ; in the A500 and A1200, etc) has 2 heads, (upper and lower) ; ; A standard drive can reliably read upto 80 cylinders (a Normal DOS Disk) ; (Although most drives these days since about 1984/5 can read upto 82, but ; these tracks are usually unused by the AmigaOS filesystem for compatiblity) ; ; A disk is therefore 80 cylinders and these are usually numbered in the ; form: 0-79 (this can be different in special cases) ; ; A disk can be sub-divided into what we call 'tracks'.. ; There are 80 lower tracks & 80 upper tracks (total=80+80=160) tracks on ; a dos disk. ; ; A standard disk can also be referred to in 'blocks'. There are 512 bytes in ; 1 block and 11 blocks make up a track. Therefore 22 blocks make up a ; cylinder. So a disk holds 512*22*80 bytes of information. ie; an empty ; disk is in total 901120 bytes of space. The AmigaDOS filesystem therefore ; can format a disk to 880k of diskspace .. ; ; ; ; ; How the BOOTING SEQUENCE WORKS.. ; ------------------------------- ; A disk boots on the amiga from the 1st 2 blocks of track 0. Therefore track ; 0 is GUARENTEED to be in standard readable format that your disk-monitor ; can handle. ; ; Upon turning on the computer, the Amiga ROM checks for a disk in DFx: ; (starting at DF0: and working up on OS2 and above, on OS1.3 it just looked ; at Df0: only) If a valid track is found the OS attempts to read 2 blocks ; (512*2) hence 1024 bytes of data from the disk into memory. The structure ; being as follows ; ; 1st 4 bytes containing the identifier 'DOS' (case sensitive) and a null byte ; This is to tell Amiga DOS is a valid disk,.. eg; ; dc.b 'DOS',0 ; ; Next comes a checksum of the bootblock. If the checksum is not valid the ; OS will not try to execute the bootcode, instead acting like no disk has ; been found. When writing our own bootblock we need to firstly code the ; boot then when its ready calculate a 'boot checksum' on the code... ; the checksum is 4 bytes; hence; ; ; dc.l 0 ;reserved for checksum.. ; ; Next is another 4 bytes.. this time it contains the block number where the ; 'rootblock' should be found. NB: This however is ununsed by the current ; versions of the OS but for compatibilty is usually set to 880. ; ; Finally the main code of the bootblock starts.. hence code starting at ; offset 4+4+4 ($C in hex) is where execution starts from for the bootcode.. ; ; On a normal Workbench CLI style disk.. all the bootblock does is tell ; the ROM to startup multitasking and open the disk operating system and ; enable the Workbench screen, etc. ; ; This is acheived by by a call to exec.libraries 'FindResident'... (see ; the bootblock below) ; ; Low-level disk-drive facts.. (as used by some copy-protection schemes) ; ---------------------------------------------------------------------- ; ; Disk-drives store the data in twice its true form.. In a system called ; "MFM-Encoded Format". The reason for this is physically associated with the ; disk-drive hardware. In order to be able to tell the end or start of tracks ; the disk drive needs to have a marking system inplace. Therefore the data ; we want to store on the disk is encoded in such a way that certain numbers ; will never be produced. These special numbers are called 'Sync's. So the ; disk-drive uses a system of searching for 'Sync' marking in order to know ; when a track starts or stops. (Syncronisation marking) Therefore once the ; data has been read into memory (under disk-dma control) it needs to be ; 'MFM-Decoded'. Standard DOS disks (ie; ones which AmigaDOS can read all use ; a sync mark value of $4489 ) So in order to be readable by DOS the stored ; data it must be encoded & stored on disk with a sync mark of $4489. Copy ; protection schemes can use this to their advatage. Basically they can use ; another unique sync mark hence preventing dos (and thus your disk-monitor) ; from directly being able to read the disk into memory. It doesn`t know the ; sync and so cannot correctly read the data. There are also other more ; complicated issues like 'phantom or fake sync marking, etc. but we`ll leave ; this for now since its quite rare anyway..) The format of normal AmigaDOS ; MFM-Tracks encompasses Header Checksums, etc. and is really quite ; inefficent this is why some coders also use non-dos disk formats. Ie; to ; re-write it in a more efficient manner containing less 'padding' bytes and ; waste hence resulting in more diskspace per block. Doing this we can get ; upto a wopping 984k on a single disk.. but this is beyond the scope of this ; text.. ; ; The flaw here for them (and lucky for us) is that TRACK 0 *MUST* be sync`ed ; with $4489 and hence be DOS readable to be bootable. If it was`nt the game ; could not auto-boot since the boot-sequence wouldn`t understand how to read ; into memory the bootblock and think it was a bad disk... Now that we know ; that the 1st track of a non-dos disk must contain readable data this is our ; 1st place to look. IF the disk is non-dos we cannot look at any other parts ; of the disk until we have looked at the loader 1st. (they will need their ; own *custom* disk-loader if they use such an elaborate non-dos format since ; dos won`t understand how to read it). ; ; The 1st place to look is therefore the 'bootblock'... This will either ; contain the entire custom loader or be a hook to load the custom loader ; in. This may sound confusing; let me try to explain a little,... the ; bootblock is only 1k big and so some custom loaders won`t fit into the boot ; block and hence are stored somewhere else on the disk. Therefore the entire ; role of the bootblock in these cases is to read the 'loader' into memory and ; execute it.. ; ; ; ;