                          DISKA L[TT OCH R[TT
                                eller

           Diskettens hemlighet, en rysare ur verkligheten



L}t oss b|rja fr}n b|rjan med att ta fram en diskett och unders|ka den noga.
Det {r ju ingen konst att se hur den ser ut utanp}, och om man |ppnar lite 
p} pl}tk}pan |ver spalten f|r l{shuvudet s} kan man till och med ta en titt
p} sj{lva skrivytan. Men sen {r det stopp. D{r finns information nog f|r en
bok med 220 fullskrivna sidor, men den {r en hemlighet mellan datorn och
disketten och du kan bara ta del av det som datorn i all v{nlighet vill visa
f|r dej. Visserligen har du kanske tillg}ng till ett program som kan l{sa
direkt p} disketten, men det har du inte s} mycket nytta av om du {nd} inte 
vet vad informationen betyder.

DISKETTKVALITETEN:

Vi kan b|rja med att konstatera att det p} en Amigadiskett, eller i alla 
fall p} dess f|rpackning, brukar st} DSDD, Double side, High density, double
density, 135 tpi eler n}got i den stilen. Det inneb{r att disketten kan 
klara de krav p} packningst{thet som Amigan st{ller.  andra sidan g}r det
n{stan alltid bra med b}de enkelsidiga disketter och s}dana med s{mre pack-
ningst{thet. Det {r till och med s} att det egentligen {r precis samma dis-
ketter men med lite l{gre kvalitetskrav. Fabrikanten g|r plastmaterialet i 
stora rullar och bel{gger det p} b}da sidor med ett tunt magnetiskt skikt av 
j{rnoxid eller kromdioxid. Sedan provas rullen och om den uppfyller kraven 
f|r High Density p} b}da sidor s} blir det dubbelsidiga disketter av den. Om
bara ena sidan {r bra nog s} blir det f|rst}s enkelsidiga disketter, och om
ingen sida duger s} provas rullen med l{gre packningst{thet osv. [ven om en
diskett bara {r enkelsidig s} har den allts} samma magnetskikt p} b}da sidor
och fungerar dubbelsidigt, fast eventuellt med lite l{gre tillf|rlitlighet.

FORMATTERING OCH SKRIVNING:

Nu har vi allts} disketten framf|r oss, och n{sta steg blir att formattera 
den. Det inneb{r att maskinen f|rser den med ett m|nster av sp}r och sektorer
som beh|vs f|r att data ska kunna skrivas och l{sas. Den provas ocks} genom
att ett datam|nster skrivs in och l{ses igen genast. Amigan tolererar inte en
diskett med fel p} till skillnad fr}n en del andra maskiner som skriver in
p} disketten var felen finns och sedan undviker felaktiga sp}r. Det fungerar
j{ttebra tills man f|rs|ker g|ra diskcopy till en s}n skiva. Det {r b{ttre 
att stoppa en nyformaterad skiva i papperskorgen {n en som {r full med vik-
tiga men ol{sliga data.

Amigadisketten formatteras med 80 sp}r per sida, numrerade 0 - 79. Ett annat
vanligt namn p} sp}r {r cylinder, s{rskilt n{r det g{ller h}rddiskar. De 
b}da sidorna kallas 0 och 1, d{r 0 {r |versidan och 1 undersidan. Varje sp}r
{r indelat i 11 sektorer, nummer 0 - 10. Dessutom finns mellan sektor 10 och 
0 ett s} kallat gap, fyllt med nolltecken. Mellan de |vriga sektorerna finns
inget gap utan de f|ljer direkt p} varandra. Skrivmetoden f|r tecknen {r den
numera vanligaste f|r disketter, MFM, som betyder modifierad frekvensmodula-
tion. MFM-kodning sker alltid blockvis, men storleken p} blocken {r man fri
att best{mma sj{lv. Det g}r till s} att man f|rst g|r ett block med bytes av
alla udda bitar i blocket,skiftade h|ger ett steg, och MFM-kodar dem, sedan
g|r man detsamma med alla j{mna bitar, dock utan att skifta dem h|ger f|re
kodningen, s} egentligen blir alla bitar j{mna. Hur man g|r sj{lva kodningen 
med dess klockbitar och databitar finns beskrivet i Rom Kernel Manual: Exec,
appendix C i form av en k{llkod i C f|r den som MSTE kolla allt sj{lv.

SEKTORER OCH DESS INNEHLL:

Varje sektor inneh}ller 512 bytes data. Vi har allts} konstaterat att en 
diskett rymmer 2 * 80 = 160 sp}r med vardera 11 sektorer, allts} 1760 sekto-
rer om 512 byte, 901120 bytes eller 880 kbyte. Men dessutom har varje sektor
en s.k. header med 32 bytes som identifierar sektorn och dess inneh}ll. F|r
anv{ndaren {r den mest till besv{r eftersom den ibland saknas eller {r fel-
aktig och g|r hela sp}ret ol{sligt. Se upp med en del reparationsprogram som
"reparerar" detta fel genom att formattera om hela sp}ret.

Sektorheadern best}r av

   tv} bytes 00          MFM-kodat till AAAA AAAA

   tv} bytes A1          Standard synkbyte - MFM-kodat A1 utan en av

               klockpulserna, kodat till 4489 4489
   en byte formatbyte    FF f|r Amiga 1.0-format
   en byte sp}rnummer
   en byte sektornummer
   en byte med antalet sektorer till skrivslut (se nedan)

               dessa fyra bytes kodas som ett l}ngord
   16 bytes f|r operativsystemet (se nedan)

   fyra bytes headerchecksumma kodat som ett l}ngord

   fyra bytes datachecksumma kodat som ett l}ngord

H{refter f|ljer 512 bytes data (som kodas som ett block med 512 bytes).

L[SNING OCH SKRIVNING AV ETT SPR:

Sp}rnummer och sektornummer {r naturligtvis konstanta f|r var sektor, men 
antalet sektorer till skrivslut fordrar en n{rmare f|rklaring. Amigan l{ser
varje g}ng in ett helt sp}r och b|rjar d{r huvudet r}kar befinna sig f|r att
spara tid och f|r att det inte finns n}got synkh}l i disketten. F|r att vara 
s{ker p} att alla sektorer blivit inl{sta l{ses dessutom lite mer {n hela 
sp}ret. Sedan g}r maskinen igenon databufferten f|r att avg|ra var f|rsta 
hela sektorn b|rjar. N{sta steg blir att flytta alla data s} att f|rsta posi-
tionen i bufferten sammanfaller med en sektorstart. Eftersom vi b|rjade l{sa
p} ett ospecificerat st{lle s} kan vi nu dela in v}r buffert i tre delar:

   N}gon eller n}gra sektorer
   Sp}rgapet
   Resten av sektorerna

Nu beh|vs siffran f|r antalet sektorer till skrivslut f|r att tala om f|r 
systemet hur m}nga sektorer som finns f|re gapet. P} s} s{tt kan det hitta
den sista databyten f|re gapet, s|ka vidare efter n{sta synkbyte efter gapet
och flytta resten av sektorerna s} att alla sektorerna ligger efter varandra
i bufferten. Vi tar ett exempel:

F|rsta g}ngen ett sp}r skrivs {r det organiserat s} h{r:

GAP, sektor 0, sektor 1, sektor 2, sektor 3, sektor 4, ..... , sektor 10.
Motsvarande v{rden p} antalet sektorer till skrivslut blir:

       11        10        9         8         7                 1

Om vi sedan l{ser in detta sp}r s} skulle resultatet kunna bli:

Skr{p, sektor 8, sektor 9, sektor 10, GAP, sektor 0, ..... , sektor 7, skr{p.

De inl{sta v{rdena p} antalet sektorer till filslut blir:

         3         2         1               11                4

N{r systemet har organiserat om bufferten s} ser den ut s} h{r:

GAP, sektor 8, sektor 9, sektor 10, sektor 0, sektor 1, ..... , sektor 7.

Nu har ocks} antalet sektorer till skrivslut f}tt nya v{rden:

       11        10        9          8         7                 1

Varje g}ng som sp}ret skrivs om s} kommer allts} de ursprungliga sektorerna 
att f} en ny placering i f|rh}llande till gapet och d{rmed f|ljer ocks} att
siffran f|r antalet sektorer till skrivslut anpassas. Den inneb{r ju hur 
m}nga sektorer som finns f|re gapet.

De sexton bytes som {r reserverade f|r operativsystemet {r till f|r att ge
s}dan information att systemet ska kunna reparera trasiga filer och betecknas
tyv{rr som "reserverade f|r framtida bruk" s} d{r finns ingen hj{lp att h{mta
{nnu.

DATABLOCKEN:

Datablocken {r allts} p} 512 bytes vardera. S} som de {r organiserade {r det
emellertid l{ttare att arbeta med 128 l}ngord i st{llet. I de tabeller som 
visar datablocken anges till v{nster hexadressen till den f|rsta byten i det
f|rsta l}ngordet p} varje rad. Alla tal i forts{ttningen f|ruts{tts vara 
hexadecimala om inget annat anges. Det finns ett antal olika typer av data-
block med speciella uppgifter i systemet:

   BOOTBLOCK
   ROOTBLOCK
   SECTORMAP
   FILE HEADER
   FILE LIST
   DIRECTORY
   DATABLOCK


SKIVSTRUKTUREN:

Allt som finns p} disketten utom bootblocken {r relaterat till pekare som 
finns i rootblocket. H{rifr}n utg}r systemet alltid f|r att leta reda p}
ett directory eller en fil.


                
 ___________         ___________         _____________      ______
|           |       |           |       |             |    |      |
| SECTORMAP |<----->| ROOTBLOCK |------>| FILE HEADER |--->| DATA |
|___________|       |___________|       |_____________|    |______|
                          |                                    |
                          |                                 ___|__
 _____________       _____V_____                           |      |      
|             |     |           |                          | DATA |
| FILE HEADER |<----| DIRECTORY |                          |______|
|_____________|     |___________|                              |
                          |                                 ___|__
                          |                                |      |
 _____________       _____V_______                         | DATA |
|             |     |             |                        |______|
|  FILE LIST  |<----| FILE HEADER | 
|_____________|     |_____________|
       |                  |
    ___|__             ___|__
   |      |           |      | 
   | DATA |           | DATA |
   |______|           |______|
       |                  |
    ___|__             ___|__
   |      |           |      | 
   | DATA |           | DATA |
   |______|           |______|   


BOOTBLOCKEN:

Det finns tre block p} en diskett som alltid har samma plats. De tv} f|rsta 
{r BOOTblocken, som alltid finns i sektor 0 och 1. Dessa inneh}ller den kod
som l{ses in n{r maskinen ska bootas. Den placeras p} godtyckligt st{lle i
minnet, s} koden m}ste vara relokerbar, alla adresser m}ste allts} vara rela-
terade till PC (program counter, instruktionspekaren). Det allra f|rsta som
st}r i ett bootblock {r en typangivelse. Antingen st}r det KICK eller DOS\0.
I det f|rsta fallet {r det fr}ga om en kickstartskiva, i det andra fallet en
normal Dosskiva. Observera att \0 {r en beteckning f|r tecknet NULL, allts}
hexv{rdet 00, och inte ASCIItecknet 0. Om det st}r n}got annat i dessa fyra
bytes kommer systemet att v{gra boota fr}n skivan. Den kommer inte heller att
erk{nnas som DOSskiva utan om man l{gger in den kommer en systemrequester med
texten "NOT A DOS DISK". N{sta l}ngord med adressen $004 inneh}ller check-
summan f|r bootblocken. N{stf|ljande l}ngord inneh}ller en helt on|dig upp-
lysning: adressen till rootblocket. Eftersom det alltid finns i block 880
anv{nder systemet inte denna adressangivelse, s} h{r kan du skriva n}got
annat om du vill. Det k|rbara bootprogrammet b|rjar i adress $00C i f|rsta
blocket. P} en bootbar skiva finns allts} ett program, i maskinkod, som
utf|res varje g}ng maskinen bootas om. Detta {r ocks} platsen f|r alla virus
av bootblockstyp. Ett absolut villkor f|r att bootprogrammet ska k|ras {r att
checksumman {r korrekt. Detta faktum utnyttjas listigt av kommandot FORMAT.
Det skriver in typangivelsen DOS\0 och fyller sedan resten av bootblocken med
meningsl|sa data (Det st}r faktiskt mest ordet DOS d{r ocks}, med en del
andra tecken emellan). Ingen checksumma skrivs in, f|r annars skulle systemet
erk{nna skivan som bootskiva och f|rs|ka k|ra ett obefintligt program, och
det leder f|rst}s ofelbart till en visit av GURUn. F|r att f} in bootpro-
grammet k|rs kommandot INSTALL, som allts} kopierar in sitt lilla program i
bootsektorerna och dessutom ber{knar och skriver in checksumman. Systemet
kommer tillbaka fr}n bootkoden med tv} v{rden i D0- resp A0-registren. I D0
finns felkoden. Om allt fungerade s} st}r h{r noll, annars tittar gurun fram
och systemet hamnar i debuggern. Om D0 verkligen {r noll s} st}r i A0 en
startadress. Bootstrapkoden frig|r minnet d{r bootblocken l{stes in, rensar
upp efter sig och hoppar till adressen i A0. 

ROOTBLOCKET:

Detta {r det tredje blocket med en best{md plats p} skivan. Det st}r alltid i
sektor nummer 880 decimalt, 370 hex. Rootblocket inneh}ller framf|r allt pe-
kare till det som finns i skivans huvudbibliotek, b}de filer och underbiblio-
tek. Tabellen nedan visar blockets uppbyggnad. F|rsta och sista l}ngordet {r
blocktypen. F|r rootblocket {r de respektive 00000002 och 00000001. N{sta ord
med n}gon mening {r det fj{rde, p} adress 00C, det anger hur m}nga pekare som
finns i HASH-tabellen, dvs hur m}nga filer och bibliotek som finns under rot-
biblioteket. L}ngord nummer sex, med adress 014, {r checksumman f|r blocket.
Den ber{knas genom att man utg}r fr}n $00000000 och adderar varje l}ngord
i blocket, utom checksumman sj{lv f|rst}s, och summan blir checksumman. Genom
att vid varje l{sning ber{kna checksumman och j{mf|ra med f{lt sex s} kan 
systemet kontrollera att l{sningen {r korrekt. D{remot g}r det inte att be-
r{kna vilken byte som {r fel och inte heller att korrigera ett fel. Omedel-
bart efter checksumman, med adress 018 b|rjar HASH-tabellen som har 72 f{lt
till sitt f|rfogande. Vart och ett av dem pekar allts} p} f|rsta blocket i en
fil eller ett underbibliotek. F|r att kunna l{sa av vad pekaren egentligen
visar p} m}ste systemet l{sa dessa block ett och ett. Det finns allts} inte
n}got egentligt bibliotek som i en del andra system, MS-DOS eller CP/M till
exempel som ju bara blinkar till och st}r hela biblioteket p} sk{rmen. Amiga
m}ste m|dosamt traggla igenom alla pekarna i rootblocket och l{sa alla block
som pekas p}. S{rskilt l}ng tid tar det om man inte har gett utrymme f|r 
extra l{sbuffertar genom kommandot buffers ..., d} m}ste dessutom rotblocket
l{sas om efter varje l{sning av ett annat block. N{sta l}ngord, med adress
138, visar om sectormap {r intakt. Om det inte st}r FFFFFFFF h{r s} kommer
det omedelbart upp en requester som s{ger att "Error validating disk, use
Diskdoctor..etc". N{sta f{lt, 13C, visar p} sectormap. Denna har, som andra
block, ingen fast adress, men p} en helt nyformatterad skiva ligger den i 
block nummer 881 decimalt, 371 hex. 

N{sta ord med betydelse anger tiden f|r senaste {ndring i n}gon fil p} ski-
van. Det {r h{rifr}n systemet l{ser klockans inst{llning om det inte finns 
n}got DATE eller SETCLOCK i s/startup-sequence. P} det s{ttet garanteras det
att det inte kan bli n}gon fil med dateringen "Future" p} bootskivan i alla 
fall. Tiden anges inte precis i klartext inte. I f{ltet f|r dag anges hur 
m}nga dagar som g}tt sedan 1978-01-01, timmar och minuter anges i minuter 
sedan midnatt. Om det d} st}r 00000132 s} betyder det allts} 306 minuter med
decimala tal, allts} {r klockan 05.06 p} morgonen. Sekunderna anges inte i
sekunder utan i IntuiTicks, och av dem g}r det 50 p} en sekund.

Sedan f|ljer diskettnamnet med b|rjan i 1B0. Det {r hela }tta l}ngord, allts}
32 bytes, fast bara 30 f}r anv{ndas f|r namnet. Den f|rsta byten anger
antalet tecken i namnet. Det inneb{r att namnet {r lagrat i form av en BCPL-
str{ng. En AMIGADOS-str{ng har i st{llet ett avslutande NULL och beh|ver
ingen l{ngdangivelse. Faktum {r att str{ngen kan betraktas som en DOS-str{ng
om den antas b|rja i 1B1 i st{llet. Det finns ju 32 bytes reserverade och
namnet {r bara 30 s} den sista byten kommer alltid att vara NULL.I 1E4 b|rjar
sedan ytterligare ett datumf{lt som p} samma s{tt som det tidigare anger n{r
skivan formatterades. Blocket avslutas s} med den andra typangivelsen, som ju
f|r rootblocket skulle vara 00000001.

Tabellen nedan visar schematiskt hur rootblocket ser ut. Eftersom det {r MFM-
kodat som ett enda block s} ser det ju inte ut s} p} skivan utan f|rst sedan
det blivit avkodat. Det finns faktiskt ett par program som l{ser ut informa-
tionen i MFM-format, men de flesta diskeditorer {r v{nliga nog att |vers{tta
}t dej.
 
---------------------------------------------------------------------------
000 |  Typ = 00000002 |                 |                 |  Tabell-l{ngd   
---------------------------------------------------------------------------
010 |                 |   Checksumma    |    H{r b|rjar HASH - tabellen
-----------------------------------------
020 |          som best}r av pekare till f|rsta blocket i alla filer och
--------
030 |          underbibliotek som ing}r i rotbiblioteket. Antalet pekare
--------
               i den framg}r av talet i adressen 00C ovan.
--------
120 |
--------                                -----------------------------------
130 |                                   |  Sectormap OK?  | Pekare sectormap
---------------------------------------------------------------------------
140 |                 |                 |                 | 
---------------------------------------------------------------------------
150 |                 |                 |                 |
---------------------------------------------------------------------------
160 |                 |                 |                 |      
---------------------------------------------------------------------------
170 |                 |                 |                 |
---------------------------------------------------------------------------
180 |                 |                 |                 |
---------------------------------------------------------------------------
190 |                 |                 |                 | 
---------------------------------------------------------------------------
1A0 |                 |Senaste {ndr.:Dag|   Timme/Minut   |    Sekunder
---------------------------------------------------------------------------
1B0 |  Diskettens namn b|rjar h{r och forts{tter --------
---------                                                 \        --------
1C0 |                                                      -------- hit    
---------------------------------------------------------------------------
1D0 |                 |                 |                 | 
---------------------------------------------------------------------------
1E0 |                 | Formattering:Dag| Timme/Minut     |    Sekunder
---------------------------------------------------------------------------
1F0 |                 |                 |                 | Typ = 00000001
---------------------------------------------------------------------------

Utttrycket HASH-tabell fordrar en liten f|rklaring. Olika typer av HASH-
system anv{nds flitigt n{r man vill snabba upp s|kning efter data. Sj{lva
idn g}r ut p} att fil- eller biblioteksnamnet i sig sj{lvt pekar p} adressen
d{r det ska lagras. Eftersom det i v}rt system finns tillg}ng till 72 pekare
m}ste vi allts} p} n}got s{tt r{kna fram ett HASH-v{rde mellan 0 och 71. Den
metod som anv{nds {r ganska l{tt att beskriva:

   1  Omvandla alla tecken i namnet till majuskler (stora bokst{ver).

   2  S{tt startv{rdet p} HASH till $0000.

   3  F|r varje bokstav g|r f|ljande:

      a  Multiplicera HASH med 13.

      b  L{gg till ASCII-v{rdet p} bokstaven.

      c  G|r logisk AND mellan HASH och $07FF.

   4  Dividera sedan HASH med 72.

   6  Resten efter denna division blir HASH-v{rdet.

Det var ju element{rt, och nu {r det allts} s} att HASH-v{rdet pekar direkt
p} en pekare i HASH-tabellen. Det {r bara att g} direkt dit och hitta pekaren
som visar p} filens Fileheader. D{rav f|ljer ocks} att tabellen inte fylls
upp fr}n b|rjan eller slutet, utan det beror enbart p} HASH-v{rdena f|r de
aktuella filerna vilka ord i tabellen som anv{nds. Men om nu det framr{knade
HASH-v{rdet redan {r upptaget? Vi kan ju bara peka p} en fil i taget. Inte
heller kan vi ta n}gon annan ledig plats i tabellen, f|r d} g}r det inte att
hitta filen igen utan att s|ka igenom hela tabellen, och d} har vi f|rlorat
hela vitsen med HASH-metoden. L|sningen p} det dilemmat {r helt enkelt att i
varje block som en HASH-tabell pekar p}, inf|ra en pekare som pekar vidare
mot n{sta block som f}tt samma HASH. P} det s{ttet kan vi f} en l{nkad lista
p} block med samma HASH, och det g}r snabbt att leta sig fram till r{tt fil
eller bibliotek. HASH-tabellen pekar allts} i realiteten p} det f|rsta
blocket i en lista. Vid s|kning efter en fil m}ste man allts} f|rst ber{kna
dess HASH, s} letar man i tabellen, g}r till den sektor som den pekar p} och
unders|ker d{r filnamnet. Om det inte st{mmer, l{ser man pekaren till n{sta
block med samma HASH, g}r dit, osv., tills man antingen hittar filen eller
tr{ffar p} en tom pekare, och m}ste meddela att "File not found".

SECTORMAP:

Efter rootblocket {r det naturligt att behandla blocket sectormap. Detta 
block {r unikt genom att det saknar typangivelse. Det f|rsta l}ngordet {r i
st{llet checksumman och sedan f|ljer l}ngord som vardera anger om 32 olika 
block {r lediga eller upptagna. L{gg m{rke till att tabellen inte b|rjar med 
0 och 1 utan med 2, bootblocken 0 och 1 kommer i st{llet sist. I denna tabell
kontrollerar systemet allts} var det {r till}tet att skriva, och ser till att
h}lla tabellen aktuell s} snart sektoranv{ndningen har {ndrats. En skrivning
p} skivan m}ste allts} b|rja med l{sning av sectormap, sedan {ndras ordet som
anger att sectormap {r intakt, filen skrivs, och slutligen {ndras sectormap-
kontrollordet tillbaka till FFFFFFFF igen. Om denna process blir st|rd s} kan
allts} inte kontrollordet korrigeras, och det visar att sectormap {r ogiltig.
Skivan kan d} inte anv{ndas f|r skrivning utan m}ste rekonstrueras med Disk-
doctor eller n}got annat reparationsprogram. Tabellen visar hur sectormap {r
uppbyggd:

---------------------------------------------------------------------
000 |   Checksumma  |     2 - 33    |    34 - 65    |    66 - 97    |
---------------------------------------------------------------------
010 |    98 - 129   |   130 - 161   |   162 - 193   |   194 - 225   |
---------------------------------------------------------------------
020 |   226 - 257   |   258 - 289   |   290 - 321   |   322 - 353   |
---------------------------------------------------------------------
030 |   354 - 385   |   386 - 417   |   418 - 449   |   450 - 481   |
---------------------------------------------------------------------
040 |   482 - 513   |   514 - 545   |   546 - 577   |   578 - 609   |
---------------------------------------------------------------------
050 |   610 - 641   |   642 - 673   |   674 - 705   |   706 - 737   |
---------------------------------------------------------------------
060 |   738 - 769   |   770 - 801   |   802 - 833   |   834 - 865   |
---------------------------------------------------------------------
070 |   866 - 897   |   898 - 929   |   930 - 961   |   962 - 993   |
---------------------------------------------------------------------
080 |   994 - 1025  |  1026 - 1057  |  1058 - 1089  |  1090 - 1121  |
---------------------------------------------------------------------
090 |  1122 - 1153  |  1154 - 1185  |  1186 - 1217  |  1218 - 1249  |
---------------------------------------------------------------------
0A0 |  1250 - 1281  |  1282 - 1313  |  1314 - 1345  |  1346 - 1377  |
---------------------------------------------------------------------
0B0 |  1378 - 1409  |  1410 - 1441  |  1442 - 1473  |  1474 - 1505  |
---------------------------------------------------------------------
0C0 |  1506 - 1537  |  1538 - 1569  |  1570 - 1601  |  1602 - 1633  |
---------------------------------------------------------------------
0D0 |  1634 - 1665  |  1666 - 1697  |  1698 - 1729  | 1730-1759/0-1 |
---------------------------------------------------------------------

H{r slutar allts} sectormap, och resten av blocket {r odefinierat. Hur ett
sectormapord {r sammansatt visar n{sta tabell, som i |versta raden anger
blocknumret, i andra raden upptaget eller inte ( 1 resp 0 ), och i tredje
raden det resulterande hextalet.

1634  1635  1636  1637  1638  1638  1640  1641  1642  1643  1644  1645 
  0     1     1     1     1     0     0     1     1     0     1     1
                    7                       9                       B

1646  1647  1648  1649  1650  1651  1652  1653  1654  1655  1656  1657
  1     1     1     1     1     0     0     0     1     1     0     1
                    F                       8                       D

1658  1659  1660  1661  1662  1663  1664  1665
  1     1     0     0     1     0     0     1 
                    C                       9

Det hela ger ett l}ngord som {r 79BF8DC9, och som allts} anger hur sektor-
bel{ggningen ser ut inom omr}det 1634 - 1665.


FILE HEADER:

Alla filer har ett huvudblock som ocks} {r filens f|rsta block, FILE HEADER.
H{r hittar systemet alla data som beh|vs om filen, och det {r allts} detta 
block som ska l{sas n{r kommandot DIR utf|rs. Mycket i Fileheaderblocket p}-
minner om motsvarande f{lt i rootblocket. F|rsta typf{ltet {r detsamma, dvs
00000002. N{sta f{lt inneh}ller en egotrippad pekare, den pekar alltid p} sig
sj{lv. Det {r inte s} knasigt som det l}ter, den pekar allts} p} det egna 
fileheaderblocket, och den motsvaras i datablocken av en pekare p} samma 
plats som pekar p} filens fileheaderblock. Det finns allts} n}gon sorts logik
i galenskaperna. N{sta l}ngord anger antalet block i filen. I adress 134(!!)
st}r s} en pekare till filens f|rsta block, allts} det st{lle d{r dess egent-
liga inneh}ll b|rjar. Det {r faktiskt s} att listan b|rjar bakifr}n och
forts{tter mot l{gre adresser. Sj{tte l}ngordet {r checksumman som tidigare,
d{refter b|rjar en motsvarighet till HASH-tabellen, som i fileheadern visar i
tur och ordning p} alla de block som ing}r i filen. Det g|r f|rst}s l{sningen
snabbare eftersom systemet inte beh|ver leta sig fram fr}n block till block
som vid directoryl{sningen. Dessutom ger det en m|jlighet att rekonstruera
resten av filen {ven om ett block skulle vara felaktigt eller ol{sligt. Om
det inte r{cker till med de 72 pekare som f}r plats i fileheaderns tabell s}
forts{tter den i ett block av typen FILE LIST.

Efter tabellen kommer protectflaggorna, allts} rwed som man kan hitta genom
att LISTa en fil. Ordet {ndras naturligtvis fr}n CLI med kommandot PROTECT.
Om det st}r enbart nollor s} betyder det att filen kan l{sas, skrivas, k|ras
och raderas, om flaggordet d{remot {r 00001111, s} hindras alla dessa
funktioner. I systemet 1.1 fungerar faktiskt bara deleteflaggan som den
ska, de andra kan s{ttas men p}verkar ingenting. N{sta l}ngord talar om fi-
lens totala l{ngd i bytes, fileheadern or{knad.

I adress 148 b|rjar texten till den FILE-NOTE som man kan f|rse varje fil 
med. 88 bytes har man p} sig, fast den f|rsta anger l{ngden och kan allts} 
inte utnyttjas av anv{ndaren. Denna FILE-NOTE har en del kn|ligheter med sig,
den |verf|rs inte vid kopiering och den g}r inte att radera. Enda s{ttet att
bli av med den fr}n en fil skulle allts} vara att kopiera filen till en annan
diskett och sedan kopiera tillbaka den igen.

Platsen f|r skivans namn i rootblocket motsvaras exakt av filnamnet i
fileheaderblocket. [ven h{r lagras det i form av en BCPL-str{ng.

Det som betecknats som HASH-pekare i adressen 1F0 {r den pekare till n{sta
fileheader, som l{nkar ihop alla filer med samma HASH. Den {r antingen
$00000000, och det inneb{r att det inte finns fler block i listan, eller
ocks} {r har den v{rdet av ett blocknummer. 
 
Fileheaderblocket avslutas med tv} pekare till f|reg}ende block och n{sta 
block. Allra sist kommer typord nummer tv}, som ska vara FFFFFFFD. F|reg}ende
block f|r en fileheader {r rootblocket, eller om filen ing}r i ett underbib-
liotek, dess directoryblock. N{sta block blir det f|rsta datablocket, eller
om det beh|vs, det f|rsta FILE LIST-blocket.

Fileheaderblocket ser ut s} h{r:
  
---------------------------------------------------------------------------
000 |  Typ = 00000002 |   Sj{lvpekare   |   Antal block   |    
---------------------------------------------------------------------------
010 | F|rsta filblock |   Checksumma    |    H{r slutar tabellen
-----------------------------------------
020 |          som best}r av pekare till alla block som utg|r filen.
--------
030 |          Antalet pekare framg}r av talet i adressen 009 ovan.
--------
              
--------
120 |
--------                                -----------------------------------
130 |              Tabellen b|rjar H[R  |                 | 
---------------------------------------------------------------------------
140 | Protectflaggor |     Fill{ngd     |  Filkommentaren b|rjar h{r
-----------------------------------------
150 |
---------
160 |
---------
170 |
---------
180 |
---------
190 |
---------------------------------------------------------------------------
1A0 |                 |Senaste {ndr.:Dag|   Timme/Minut   |    Sekunder
---------------------------------------------------------------------------
1B0 |      Filens namn b|rjar h{r och forts{tter --------
---------                                                 \            ----
1C0 |                                                       ---------hit    
---------------------------------------------------------------------------
1D0 |                 |                  |                |
---------------------------------------------------------------------------
1E0 |                 |                  |                |
---------------------------------------------------------------------------
1F0 |  HASH-pekare    | F|reg}ende block |   N{sta block  | Typ = FFFFFFFD
---------------------------------------------------------------------------


FILE LIST:

Om det inte finns plats i tabellen i ett fileheaderblock s} forts{tter 
allts} tabellen i ett filelistblock. Det {r mycket likt fileheaderblocket men
en hel del information {r bortskalad. F|rsta typordet {r 00000010, men det 
andra {r samma som i headern, allts} FFFFFFFD. L}ngord tv} {r som vanligt en
pekare till fileheadern, och l}ngord tre anger antalet block i sin tabell,
som ocks} h{r {r maximerad till 72. Sedan f|ljer ingenting alls f|rr{n vi
kommer till de tre sista l}ngorden som {r desamma som f|r headern, allts}
pekare till f|rra blocket, headern eller f|reg}ende filelist, pekare till 
n{sta block, en filelist eller det f|rsta datablocket och s} till sist typen.

Filelistblocket ser ut som nedan:
   
---------------------------------------------------------------------------
000 |  Typ = 00000002 | Fileheaderpekare|   Antal block   |    
---------------------------------------------------------------------------
010 |                 |   Checksumma    |    H{r slutar tabellen
-----------------------------------------
020 |          som best}r av pekare till alla block som utg|r filen.
--------
030 |          Antalet pekare framg}r av talet i adressen 009 ovan.
--------
              
--------
120 |
--------                                -----------------------------------
130 |             Tabellen b|rjar H[R   |                 | 
---------------------------------------------------------------------------
140 |                 |                 |                 |
---------------------------------------------------------------------------
150 |                 |                 |                 |
---------------------------------------------------------------------------
160 |                 |                 |                 |
---------------------------------------------------------------------------
170 |                 |                 |                 |
---------------------------------------------------------------------------
180 |                 |                 |                 | 
---------------------------------------------------------------------------
190 |                 |                 |                 |
---------------------------------------------------------------------------
1A0 |                 |                 |                 |  
---------------------------------------------------------------------------
1B0 |                 |                 |                 | 
---------------------------------------------------------------------------
1C0 |                 |                 |                 |
---------------------------------------------------------------------------
1D0 |                 |                 |                 |
---------------------------------------------------------------------------
1E0 |                 |                 |                 | 
---------------------------------------------------------------------------
1F0 |                 | F|reg}ende block |   N{sta block  | Typ = FFFFFFFD
---------------------------------------------------------------------------



DIRECTORYBLOCK:

Hittills har vi h}llit oss inom huvudbiblioteket, men nu dyker vi ett steg 
ner i filhierarkin och hamnar d} i ett underbibliotek. Det definieras av ett
directoryblock. Antingen det {r ett underbibliotek till huvudbiblioteket 
eller till ett annat underbibliotek s} {r directoryblocken exakt likadana, 
det {r bara den skillnaden ( eller likheten om man s} vill ) att pekarna all-
tid pekar p} sina n{rmaste |verordnade block. Enda s{ttet att f} reda p} vil-
ken niv} i diskstrukturen ett directoryblock befinner sig p}, {r allts} att 
f|lja pekarna upp}t och se hur m}nga steg det {r tills man hamnar i root-
blocket. Och som vi s}g tidigare s} kan man inte heller uppifr}n avg|ra om 
en pekare visar p} en fileheader eller p} ett directoryblock. Operativsyste-
mets s{tt att nysta upp strukturen {r alltid uppifr}n, men du sj{lv och Disk-
doctorn och n}gra till arbetar oftast underifr}n. 
   
Directoryblocket b|rjar som alla andra med ett l}ngord f|r typen, i detta 
fallet liksom rootblocket 00000002. D{remot {r andra typordet inte 00000001,
utan 00000002. Systemet m}ste allts} kontrollera b}da typorden f|r att kunna
se skillnad p} root-, fileheader- och directoryblock. Datablock och filelist
har d{remot unika f|rsta typord. Som andra l}ngord kommer v}r v{n pekaren som
i brist p} annat pekar p} sig sj{lv igen. Efter ett tomt f{lt kommer s} talet
som anger antalet pekare i HASH-tabellen. Checksumman st}r som alltid i posi-
tion sex, och sedan f|ljer direkt HASH-tabellen med plats f|r 72 pekare. Om 
det inte r{cker till, s} forts{tter den i ett efterf|ljande block, vars 
adress st}r i 1F0. Om talet d{r {r 00000000, s} betyder det att det inte 
finns n}got s}dant block. Det efterf|ljande blocket har precis samma uppgift
som filelistblocket som f|ljer efter fileheadern. Som vanligt finns ocks} en
pekare till f|reg}ende block i 1F4, och det {r allts} den som pekar p} antin-
gen rootblocket eller ett |verordnat directoryblock. Sista ordet var allts}
som vanligt det andra typordet. Liksom en fil, s} kan ett directory skyddas
med PROTECT-kommandot. Dess flaggor st}r i 140 och har exakt samma funktion
som i fileheadern. Detsamma g{ller f|r kommentaren, samma funktion, samma
plats och samma f{ltstorlek. Namnet p} biblioteket motsvarar precis
filnamnet, eller diskettnamnet, och dag- och tidf{lten visar p} vanligt s{tt
tiden f|r senaste {ndringen.

HASH-pekaren i 1F0 pekar precis som i fallet Fileheader p} n{sta
directoryblock som r}kat f} samma HASH-v{rde. Finns inget s}dant st}r h{r
bara 00000000.

---------------------------------------------------------------------------
000 |  Typ = 00000002 |  Sj{lvpekare    |                 |  Tabell-l{ngd   
---------------------------------------------------------------------------
010 |                 |   Checksumma    |    H{r b|rjar HASH - tabellen
-----------------------------------------
020 |          som best}r av pekare till f|rsta blocket i alla filer och
--------
030 |          underbibliotek som ing}r i detta biblioteket. Antalet pekare
--------
               i den framg}r av talet i adressen 00C ovan.

--------
120 |
--------                                -----------------------------------
130 |                                   |                 | 
---------------------------------------------------------------------------
140 | Protectflaggor  |                 |                
-----------------------------------------
150 |               
----------
160 |          
----------
170 |     
----------
180 |     
----------
190 |      
---------------------------------------------------------------------------
1A0 |                 |Senaste {ndr.:Dag|   Timme/Minut   |    Sekunder
---------------------------------------------------------------------------
1B0 |  Bibliotekets namn b|rjar h{r och forts{tter ------
---------                                                 \            ----
1C0 |                                                       --------- hit  
---------------------------------------------------------------------------
1D0 |                 |                 |                 | 
---------------------------------------------------------------------------
1E0 |                 |                 |                 |    
---------------------------------------------------------------------------
1F0 |   HASH-pekare   |   F|reg. block  |                 | Typ = 00000002
---------------------------------------------------------------------------



DATABLOCK:

Efter denna l}nga inledning kommer vi s} {ntligen till det som det hela hand-
lar om, konsten att lagra data. Allt vi hittills har behandlat har ju bara 
haft till uppgift att organisera diskettens data. I datablocket g}r det }t
sex l}ngord f|r att sk|ta administrationen, s} det blir bara 488 bytes kvar
som {r disponibla. Tre av f{lten {r gamla bekanta, f|rst naturligtvis typen,
som {r 00000008. N}got andra typf{lt finns inte. Som l}ngord nummer tv} kom-
mer pekaren till fileheadern, och checksumman st}r som vanligt i f{lt sex.
L}ngord nummer tre {r blockets l|pnummer i filen, och f{lt fyra visar hur 
m}nga bytes som finns i dataf{ltet. I alla datablock utom det sista i filen 
st}r det h{r 488. I f{lt fem finns pekaren till n{sta block. Fr}n och med 
adressen 018 kommer s} dataf{ltet med sina 488 bytes.


---------------------------------------------------------------------------
000 | Typ = 00000008 | Fileheaderpekare|     L|pnummer   |   Antal bytes   
---------------------------------------------------------------------------
010 |  N{sta block   |   Checksumma    |   H{r b|rjar dataf{ltet som
----------------------------------------
020 |                                       har plats f|r 488 bytes.
--------
030 |
--------


--------
1F0 |
---------------------------------------------------------------------------


Hur data i filen {r organiserade {r en helt annan historia som n}gon annan
f}r reda ut. [r det en ren ASCII-fil s} g}r det att l{sa den direkt med ett
skivediteringsprogram, men om det r|r sig om IFF-filer eller program s} blir
det inte l{ngre element{rt. Fast det g}r att l{sa klartext {ven i program
ibland. Alla menytexter finns d{r till exempel, och ibland de d{r orden ur
manualen som du m}ste mata in f|r att komma in i programmet.


Av det vi sett av Amigans diskstruktur kan vi dra ett par slutsatser. F|r 
det f|rsta s} g|r fr}nvaron av det annars s} vanliga directoryt med namn och
filstorlekar att det med n|dv{ndighet tar l}ng tid att k|ra ett DIR-kommando.
 andra sidan s} {r ju directorysp}ret en s}rbar punkt i andra system som nu
helt har eliminerats. I Amigasystemet finns vidare en mycket omfattande sam-
manl{nkning av alla block. Inte nog med att man kan f|lja upp strukturen fr}n
roten och ner}t (directorytr{d v{xer upp och ner, det visste ni v{l?), genom
att alla block ocks} har pekare till sina f|reg}ngare s} g}r det att nysta 
upp en hel struktur {ven om rootblocket {r skadat. Det {r ju just en av Disk-
doctorns specialiteter. En skadad sectormap spelar ingen roll alls heller, 
det g}r att rekonstruera disken helt och h}llet i alla fall. Det enda som kan
g} f|rlorat om det intr{ffar l{sfel {r n}got enstaka block i n}gon fil. I 
geng{ld s} hittar reparationsprogrammen ibland de mest h{pnadsv{ckande saker
p} disketterna. Vad s{gs om ett par personliga brev p} en diskett fr}n en 
st|rre programleverant|r? En programmerare hade uppenbarligen anv{nt sin dis-
kett till annat ocks} och sen kopierat med en diskcopyvariant, varvid l|sa 
block med text h{ngde med, och mitt DiskSalv ( fr}n Fish nummer 20, sl}r 
Diskdoctorn med flera stetoskopl{ngder ) pussslade ihop dem igen. Du f}r ofta
mycket mer p} en skiva som }terskapats s} h{r. Fish nummer 61 har ett litet
program som fyller tomma block med ingenting ( hur g}r det till egentligen )
och som verkligen kan rekommenderas f|r den som vill beh}lla sina brev eller
k{llkoder f|r sig sj{lv.

Ta nu fram FileZap eller Mirror Hack eller vad du nu har f|r diskeditor och
g} p} uppt{cktsf{rd p} dina disketter. Men g|r det helst p} en kopia f|rst.
En byte kan som du vet anta 256 olika v{rden, men bara ett {r r{tt, och det
{r inte sv}rt att g} vilse bland alla hextalen i ett block.

Fakta och inspiration till den h{r artikeln kommer fr}n Rom Kernel Manual
och fr}n den tyska tidningen AMIGA fr}n markt & technik. Den kan varmt rekom-
menderas f|rresten. Den har m}nga och bra tekniska artiklar om Amiga, och de
{r betydligt mer faktainriktade {n motsvarande texter i Amiga World med 
flera. Problemet {r bara spr}ket f|rst}s. Visste ni till exempel att en h}rd-
disk kallas Festplattenlaufwerk eller att accesstiden g}r under namnet Zu-
griffsgeschwindigkeit? M}nadens program {r av h|g klass, men {r ofta p} flera
sidor med k{llkod att knappa in om man orkar. Materialet som jag hittade d{r
{r f|rhoppningsvis s} bearbetat och omstuvat ( och r{ttat ) att jag inte g|r
intr}ng i n}gon copyright. Jag tar inget som helst ansvar f|r de fel som 
s{kert finns kvar, och om ni kvaddar era disketter s} f}r ni skylla er 
sj{lva. Men mycket kul kan man ha n{r man gr{ver djupt p} disketterna, och
det {r ju det som {r meningen. Hittar ni n}gra allvarligare grodor i materia-
let s} meddela mej p} n}got s{tt, s} kan det kanske bli en n{stan korrekt 
framst{llning till slut.


Claes G Colmeus  (52)
