home *** CD-ROM | disk | FTP | other *** search
/ Amiga ISO Collection / AmigaUtilCD2.iso / Programming / Misc / Asm-Course2.lha / Teil24.TXT < prev    next >
Encoding:
Text File  |  1992-09-02  |  10.7 KB  |  259 lines
  1.           A S S E M B L E R - K U R S       (c)  Jeff Kandle 1990
  2.  
  3.                                 24.Teil...
  4.  
  5. So, jetzt wisst ihr ja schon eine ganze Menge ueber den Bootblock. Aber
  6. etwas das wisst ihr noch nicht.
  7. Obwohl ich wiegesagt nicht viel von dem Ganzen Betriebssystem-Krempel halte
  8. gibt es da doch etwas was sich unheimlich toll anhoert und auch toll ist.
  9.  
  10. Obwohl ich, wie ich gerade gemerkt habe, das Kapitel Bootblock nicht
  11. nummerriert habe will ich doch mit der Nummerierung weitermachen.
  12.  
  13. 20.Programmierung des Trackdisk.Device
  14.  
  15. Die ganze Zeit in der wir mit dem Bootblock gearbeitet haben hab ich immer von
  16. Trackdisk.Device geredet. Jetzt will ich mal rausruecken was das tolle an
  17. ihm ist.
  18.  
  19. Erstmal will ich erklaeren was ueberhaupt Devices sind. Es gibt sie fuer
  20. sehr viele Sachen...Tastatur, Drucker...Musik usw.
  21.  
  22. Was ist ein Device ueberhaupt ?
  23.  
  24. Devices sind Programme die wie Librarys geoeffnet werden muessen. Sie haben
  25. dann direkten Draht zu dem Geraet fuer das sie da sind. Sie sind die
  26. verbindungsstelle zum Laufwerk oder zum Drucker. Das Trackdisk Device ist
  27. die unterste ebene bei der Arbeit mit dem Diskettenlaufwerk.
  28.  
  29. Da wie ich gesagt habe das TDD (in zukunft fuer Trackdis...) schon offen
  30. ist, entfaellt das oeffnen komplett. Daran muesst ihr denken falls ihr
  31. dieses Device mal ausserhalb des Bootblocks benutzen wollt.
  32.  
  33. Wenn wir das TDD benutzen so werden wir sehr viel schneller sein als wie
  34. der das AmigaDos selbst, weil wir die sachen erstmal von Hand auf die
  35. Diskette schmeissen, und da natuerlich die optimale Sache einsetzen. Und
  36. die ist nunmal alles hintereinander und in einem durch.
  37.  
  38. Das Betriebssystem macht es etwas umstaendlicher.
  39. Um den Komfort und einfachere Handhabung fuer die Operation mit Disketten
  40. zu gewaehrleisten arbeitet das AmigaDos etwas anders mit dem TDD, als wie
  41. es wir tun. Das Betriebssystem laedt ein File nach dieser Technik ein..
  42.  
  43. Sobald der Name im AmigaDos eingeben wurde sucht es den dafuer zu
  44. staendigen eintrag im Directory.
  45. Sobald es den hat, zieht es sich wichtige Daten aus dem Header. Eine Sache
  46. ist die laenge des Programms, damit es weiss wo es das hinladen kann, und
  47. keine vorhandenen Programme zerstoert.
  48. Desweiteren findet das Dos auch die Adresse des ersten Blocks des Programms
  49. auf der Diskette. Wenn es den hat, veranlasst es das TDD diesen Block zu
  50. lesen. Die letzten beiden Worte dieses Blocks sind die Adressen des
  51. naechsten. So hangelt sich das AmigaDos durch die Disk, bis es das
  52. Komplette Programm drin hat. Dies ist noetig weil das AmigaDos Programme
  53. nicht immer hintereinander auf die Diskette schreibt, sondern immer so nahe
  54. wie moeglich an den Directory Bloecken ran, damit der Schreib/Lese Kopf
  55. schnell das Ziel erreicht.
  56.  
  57. Ihr stimmt mir doch zu das diese Methode sehr umstaendlich ist. Aber sie
  58. hat sich bewaehrt wenn es um geordnete Diskette und Zugriffszeit geht.
  59.  
  60. Aber das TDD kann mehr !
  61.  
  62. Denn das TDD verwaltet die Diskette nicht in Tracks und Sectoren wie das
  63. AmigaDos und die Laufwerke. Fuer das TDD ist die Diskette in Bloecke a 512
  64. Bytes unterteilt, und die sind von Null bis 1760 oder so durchnummeriert.
  65.  
  66. Wenn wir also mit den Amon ein Programm, welches an Festen Adressen, wie
  67. zum Beispiel unsere Intro`s liegt, einfach Block fuer Block hintereinander
  68. auf Disk schreiben, dann kann es das TDD mit einem Schlag einladen, ohne
  69. das man dafuer ein Directory braucht. Den Effekt kennt ihr bestimmt von
  70. manchen Orginalspielen oder MegaDemos kennt, das obwohl sehr viele
  71. Programme auf der Diskette sein muessen, keine Directory vorhanden ist.
  72.  
  73. Und das macht es sehr viel schneller.
  74.  
  75. Ein vergleich..
  76.  
  77. Ich habe mit dem Seka ein Testfile auf Diskette installiert. Es ist 64
  78. Kilobyte lang. Ansonsten war die Diskette leer.
  79. Um dieses File mit Read Image wieder einzuladen braucht der Seka 7
  80. Sekunden.
  81.  
  82. Danach habe ich dasselbe File mit dem Amon auf Diskette geschriebn, und
  83. zwar so wie ich es mit dem TDD laden kann.
  84. Ich habe den Bootblock dafuer geschrieben, indem der Aufruf steht, und ihn
  85. auf die Diskette gelegt.
  86. Da ich das Ende der Bootblock identifikation und der Anfang des Ladens
  87. durch das TDD nicht ermitteln kann, sage ich halt wieviel das Laufwerk
  88. gebraucht vom Booten bis zum drinhaben des Files.
  89.  
  90. Ganze 3.5 Sekunden, fuer alles beide..Das ist doch sehr schnell finde ich.
  91.  
  92. Desweiteren eignet sich das TDD fuer unsere Zwecke, wenn wir mal von
  93. nachladen waehrend ein Programm laeuft reden. Da das TDD einen eigenen task
  94. belegt koennen wir es Synchron zu anderen Sachen laufen lassen. Es ist
  95. naemlich ein toller Effekt wenn nachgeladen wird und ein sogenanntes
  96. `Loading Demo` laeuft.
  97.  
  98. Und da es so toll ist, will ich euch mal zeigen wie man damit umgeht.
  99.  
  100. Erstmal muessen wir uns bevor wir anfangen zu Experimentieren ein Testfile
  101. anlegen. Wir nehmen wie ich ein 64 Kilobyte-File. Damit wir auch sehen das
  102. es ueberhaupt laedt, und wenn, dann wann es fertig ist, schreiben wir noch
  103. ein kleines Prograemmchen davor welches die Bildschirm farbe aendert.
  104.  
  105. Also wir schreiben im Seka folgendes....
  106.  
  107. Org $40000
  108. Load $40000
  109.  
  110. Start:
  111.         Move.w  #$0f00,$dff180
  112.         Bra.s   Start
  113.  
  114. So nun legen ihr eine Formatierte Diskette ein die aber ansonsten leer ist.
  115. Nunja, sie muss nicht leer sein, aber ein Teil der Daten die sich auf ihr
  116. befinden werden Floeten gehen.
  117. Also nachdem die Diskette eingelegt ist, Assemblieren wir das Programm.
  118. Sobald das geschehen ist, schreiben wir das fertige Image auf Disk.
  119. Wir muessen 64 Kilobyte abspeichern, dazu geben wir den Bereich von $40000
  120. bis $50000 an. Sobald sich das Image auf Diskette befindet, muessen wir es
  121. TDD-gerecht auf Disk schreiben.
  122.  
  123. Dazu benutzen wir den Amon...
  124.  
  125. Erstmal laden wir das Image in den Arbeitsspeicher. Das geschieht mit
  126.  
  127. [ 40000 Testfile
  128.  
  129. Jetzt liegen die 64 Kilobyte ab $40000
  130.  
  131. Nun muessen wir sie auf Diskette kriegen. Den Write-Blocks befehl vom Amon
  132. kennt ihr ja schon. Nun muessen wir uns nur noch einen Standpunkt auf
  133. Diskette ausdenken. Dazu nehmen wir den Teil direkt hinter den Bootblocks.
  134.  
  135. Der Befehl lautet
  136.  
  137. > 40000 1 2 80
  138.  
  139. 40000   Von $40000 an
  140. 1       Df1:
  141. 2       ab Block 2
  142. 80      80 Blocks
  143.  
  144. Damit duerfte das File Korrekt geschrieben werden.
  145.  
  146. Jetzt muessen wir uns um den Bootblock kuemmern der das dann wieder
  147. einlaedt.
  148. Wiegesagt muss man sich wenn man mit dem TDD arbeitet nicht mehr um die
  149. Routinen kuemmern die das Ordnungsgemaesse abarbeiten der Bootroutine
  150. organisieren. Wir koennen uns also nur mit dem Aufruf fuer das TDD
  151. kuemmern.
  152. Der Aufruf sieht so aus, das wir dem TDD folgende Daten geben
  153.  
  154. Den Jobcode, ob laden oder speichern
  155. Die Laenge in Bytes
  156. Das Ziel an das es im Speicher geschrieben werden soll
  157. und ab wo das File auf Diskette anfaengt.
  158.  
  159. Nachdem ich das alles geschrieben haben muss ich das TDD nur noch
  160. veranlassen diese Operation auszufuehren. Der Bootblock saehe dann so aus..
  161.  
  162. Da ich die Werte nicht in irgendwelchen Register uebergebe, sondern an ganz
  163. bestimmten stellen im TDD, schreibe ich sie Direkt dort hin, und zwar so.
  164.  
  165. Jobcode nach $1c(a1), also an die 28($1c) Stelle des TDD
  166. Die Laenge in Bytes nach $24(a1)
  167. Ziel im Speicher nach $28(a1)
  168. Ab dem Wievielten Byte auf Disk es anfaengt, dort kann man aber nur
  169. anfaenge von Blocks angeben.
  170.  
  171. Zum Schluss noch eine Routine im Exec, die alles veranlasst. Diese Funktion
  172. heisst DoIO fuer Do Input/Output
  173.  
  174. Danach nur noch der Jmp-Befehl der das geladene ausfuehrt.
  175.  
  176. Das Bootblock-listing sieht dann so aus..
  177.  
  178. Org $40000
  179. Load $40000
  180.  
  181. Kennung:   dc.b "DOS",0
  182. Chksum:    dc.l 0
  183. Rootblock: dc.l 0                       ; Wiegesagt, der Rootblock ist nur
  184.                                         ; bei Diskette mit Directory noetig
  185.                                         ; Deshalb lasse ich ihn weg.
  186.  
  187.         Move.w  #$02,$1c(a1)            ; Jobcode `Lesen` nach $1c
  188.         Move.l  #$10000,$24(a1)         ; Laenge in Bytes nach $24
  189.         Move.l  #$40000,$28(a1)         ; Ziel im Speicher
  190.         Move.l  #$400,$2c(a1)           ; Ab Byte $0400 auf Disk
  191.         Jsr     -$1c8(a6)               ; DoIO
  192.         jmp     $40000                  ; Geladenes anspringen.
  193.  
  194. Das ist doch garnicht so schwer, oder ?
  195.  
  196. Wenn man mehrere Programme, wie zum Beispiel bei einem Megademo, laedt kann
  197. man das Programm auch mit JSR anspringen, nachdem das Intro dann mir RTS
  198. verlassen wird, wird der Bootblock, sofern er nicht zerstoert ist weiter
  199. abgearbeitet.
  200. Deshalb arbeiten die meisten Demosteuernden Bootbloecke so, das sie erstmal
  201. den Teil der das Demo steuert an einen Feste Adresse Kopieren, damit sie
  202. genau wissen wo er liegt, und sicher ist das er Intakt ist.
  203.  
  204. Die Eintragungen in den Registern des TDD sind einfach. Sie entsprechen den
  205. Werten die man auch mit dem Seka hat. Ich rede von der Laenge und der
  206. Adresse.
  207. Mit dem Amon ist das aber etwas anders. Dort werden Anfang auf Diskette und
  208. die Laenge mit der Anzahl der Blocks auf Diskette angegeben. Um diese Werte
  209. zu erhalten, muessen wir die Werte des Bootblocks nur durch 512($200)
  210. teilen.
  211.  
  212. Damit waere der Anfang auf Diskette $400/$200 = 2
  213. Und die Laenge $10000/$200 = 80
  214.  
  215. Somit wisst ihr auch wie ihr den Aufruf
  216.  
  217. > 40000 1 2 80
  218.  
  219. zu verstehen habt...
  220.  
  221. Es stehen bei der Arbeit mit dem Trackdisk.device genau 1760 Blocks zur
  222. verfuegung. Das sind die vollen 880 Kilobyte, die die Diskette hergibt.
  223. Und das ist eine ganze menge, da kriegt man ne` menge Demo rein.
  224.  
  225. Man kann natuerlich auch die beiden Modi kombinieren. Das ist noetig wenn
  226. man zum Beispiel eine Diskette mit vielen Programmen rumgibt die sich die
  227. Leute aber Kopieren sollen koennen, und man ein etwas laengeres Bootintro
  228. hat, dann kann man die Blocks die das laengere Bootintro braucht als Belegt
  229. kennzeichnen. Sie werden dann nicht von AmigaDos benutzt.
  230.  
  231. Man kann, wie ihr gesehen habt, die direkte Adressierung zu benutzen, wie wir
  232. es mit den Intros und so gewoehnt sind. Denn geben ja die Adresse an wo es
  233. hingeladen werden soll. Man kann aber nur wenn man aus dem Bootblock
  234. herauslaedt mit den Werten um sich schmeissen. Sobald aber andere
  235. Programme Laufen sollte man sich entweder vergewissern ob der Bereich frei
  236. ist, oder sich halt von Betriebssystem eine Adresse geben lassen wo es hin
  237. kann. Den sonst stuerzt der Amiga sofort ab wenn ein wichtiges Programm
  238. ueberschrieben wird.
  239.  
  240. Mehr muss eigentlich nicht beachtet werden wenn man mit den TDD arbeitet.
  241. Ich benutze es sehr selten. Es ist auch nur interresant wenn man viel
  242. Demos, MusikShow oder Diashows Produziert und herumreicht. Die Vorteile
  243. liegen dort klar auf der Hand.
  244.  
  245. 1. Die sachen sind alle sehr schnell eingeladen.
  246. 2. Irgendwelche Lamer`s koennen die Diskette nicht zerpfluecken koennen und
  247.   als ihr Werk herumreichen koennen.
  248. 3. Macht es natuerlich noch einen sehr guten eindruck.
  249.  
  250. Ich schaetze die Gruende sprechen fuer sich. Experimentiert noch ein
  251. Bisschen damit rum, und macht mal ein paar Test, von wegen den Zeiten die
  252. Zum laden gebraucht werden, damit ihr sicherer in der Handhabung des TDD
  253. werdet. Denn nicht ist aergelicher als wie wenn man `mal eben` einen TDD
  254. Bootblock schreiben will, alles wieder neu lernen muss.
  255.  
  256. C.U.
  257.  
  258.                 Jeff Kandle
  259.