
<PMOD> Formatsbeschreibung & erklrende Unwissenheit.

Wozu das Ganze ?

In meiner langjhrigen Laufbahn (protz!) als unberechenbarer Assembler-Coder
fiel mir auf, wie inneffizient ich alte Sources wiederverwende oder wie schwer
es wird, Programmteile von Kumpels oder Crewkollegen einzubauen. In letzter
Zeit gestaltete ich meine Unterprogramme etwas transparenter, etwas mehr Zeit-
aufwand, dafr wiederverwendbar (recycelbar ohne grnen Punkt oder gelbe Disk-
ette). Ich bin traditionell Demoprogrammierer, eine Menschengruppe, die sich
mit schwergngigen DRI-Objektformaten- und Linkern einfach nicht anfreunden
mag. Das mag auch noch eine Nachwirkung der ST-Turboass-ra sein, die ja auch
voll linkerlos vonstatten gab bzw. lie sich Turboass nie was von derartigen
Ttigkeiten anmerken. Viele Unterprogramme knnen pc-relativ gestaltet
werden, bzw. sind dies eh schon (Musikdriver...). Das pc-relative Format und
die bergabe von allen Variablen ber Prozeduren ist ja sogar eine ganz mod-
erne Programmiertechnik, OOP-Techniken schachteln ja auch alle Programmteile
voneinander ab bzw. verhindern bergriffe unter den U-Proggys.
Genug geschwalt. Das PMOD-Format ist die Kreation, sicher noch sehr erwei-
terbar, vorerst reicht es. Das PMOD-Format enthlt neben Infos ber Autor und
Routinennamen auch Versionsangaben- und daten sowie Infos ber bentigte Hard-
ware (Erweiterung auf Vektoren geplant, vorerst aber nicht bentigt). Die Auf-
rufparameter etc. erledigen die ".DEF"-Dateien, in denen genauere Formalitten
geklrt sind. Wo liegen jetzt eigentlich die Vorteile ? Nun, alle Angaben
lassen sich in ASCII-Chars im Sourcecode ndern, und der MANAGER behlt den
berblick, wenn auch momentan noch sehr unkomfortabel. Fr 2-3 Unterprogramme
lohnt sich die Sache bestimmt nicht, wer aber auch Unterprogramme etc. weiter-
gibt, ohne eve. gleich den dokumentierten Source mitzugeben ist gut bedient.
Ach so: pc-relative Files werden sehr viel schneller mitassembliert wie dicke
include-Files und rger mit doppelten Deklarationen etc. hat man auch nicht.

PMOD ist ein PC-relatives Format, welches konzipiert wurde, Unterprogramme
oder Unterprogrammsblcke assembliert auszulagern, ohne gleich einen Linker
herzuziehen. Das kommt vorallem Linkerlosen Assemblern zugute (Turbo-Ass),
die Turn-Around Zeit wird ebenfalls sehr gesteigert (keine Erneute Assemblie-
rung wie bei "include"-Files).
PMOD-Module tragen auch Informationen ber Programmierer und Hardwareanford-
erungen. Diese Informationen sind im ASCII-Code vorhanden, knnen also auch
im Debugger erkannt werden.
Um die Einbindung noch komfortabler zu gestalten, sowie Variablen, Register
und Ansprungadressen mit Namen zu versehen, kann auch ein include-File gen-
eriert werden, wenn das PMOD-File nur einbindet, wenn dieses nicht schon vor-
handen ist, kann Variablen etc. mit Namen versehen und Ansprungadressen verge-
ben. Die Einbindung wre dann sehr an "C" angelehnt, deshalb vergebe ich die
Endung ".H" fr diese Files, die komplette Dokumentation zu den einzelnen Mod-
ulen erhalten die Endung ".DEF", reine Textfiles, die als Kommentarzeilen in
den ".H" Files die Assemblierung nur knstlich aufhalten wrden. ".H" Files
und ".INC"-Files mssen im gleichen Ordner stehen, wobei dieser z.B. beim
Turbo-Ass oder beim Easy-Ass ber "PATH" definiert werden kann. Pfadanpassungen
von Fremdmodulen sind also nur bei Neuassemblierung ntig.

Damit nicht jeder seine ultrageheimen Routinen sofort dem Feind ausgeliefert
sehen mu, lscht der Manager auf Wunsch im fertigen Programm alle Header,
d.h. er berschreibt sie mit Mll, was die Routinen genauso sicher macht wie
jedes andere Unterprogramm auch. Es sei denn, man macht sich die Mhe und
entschlsselt Single-Step im Interrupt... Aber wer so bld ist, wird eh nie
ein Programm herausbringen, da die Entwicklung nie unter 7 Jahren gehen wrde,
und wer da noch auf dem Falcon coded mu noch blder sein (aber fragt mich
lieber nochmals im Jahr 2001...).

Genauer ist das Format aufgegliedert:

    DC.B    'PMOD'                  ;  4 Bytes Kennung.
    DC.B    'Modulnamen12345',0     ; 16 Bytes Modulnamen, NULLTERMINIERT
    DC.B    'Autor..........',0     ; 16 Bytes Autor, NULLTERMINIERT
    DC.B    'SMSJUMUJ'              ;  8 Bytes Datum:
                                            SM : Startdatum (Monat, 01-12)
                                            SJ : Startjahr  (Jahr,  85-99)
                                            UM : Letztes Update Monat
                                            UJ : Letztes Update Jahr
                                            Datumsangaben im ASCII-Code:
                                                DC.B '0193' ~ Jan. 1993
    DC.B    'VAVB'                  ;  4 Bytes Version:
                                            VA : Hauptversion
                                            VB : Unterversion
                                            Versionangaben im ASCII-Code
                                                DC.B '0251' ~ Version 2.51
    DC.B    'PR--------'            ;  12 Bytes Hardwareanforderungen:
                                            Byte 11/10: Prozessor (00-60)
                                                DC.B '20----------' ~ 68020
                                            Bytes 9-0:
                                                Keine zwingende Reihenfolge,

Kennungen fr bentigte Hardware:
        "D" - DSP                           "t" - ACIA (Tastatur)
        "1" - FPU-68881                     "M" - ACIA (Midi)
        "2" - FPU-68882                     "A" - Ajax Floppycontroller
        "B" - Blitter                       "f" - FDC-1772 Diskcontroller
        "F" - Falcon-Audio                  "H" - Harddisk
        "E" - STE-Audio                     "m" - MFP
        "V" - Falcon-Video                  "C" - Clock (TT/Falcon)
        "v" - STE-Video                     "N" - NVM-Ram
        "T" - TT-Video                      "V" - VME-Bus
        "Y" - Yamaha-2149                   "R" - Rom-Port
        "P" - Parallel                      "S" - Seriell
        "L" - LAN (Meg STE/TT/F)    "p" - PMMU

Interrupts: Wahrscheinlich werden alle Unterroutinen, die via Interrupt auf-
gerufen werden mssen, aus einer im Hauptprogramm installierten Interruptrou-
tine aufgerufen werden, wie z.B. die meisten Yamaha Soundplayerroutinen (Mad
Max etc.). Aber z.B. Falcon oder STE Protrackerroutinen installieren sich oft
selber komplett, da sie "exotische" Interrupts wie Sample-End oder DSP-Inter-
rupts benutzen. Diese Routinen sollten entweder alle Register selber sichern
und eine Abmeldungsmglichkeit besitzen oder wenigstens im ".DEF"-File genau
Auskunft ber verbogene Vektoren geben. Eventuell wird noch eine Erweiterung
ins Format eingearbeitet, welche dann Interruptinformationen direkt an das
Hauptprogramm weitergeben. Auer Musikanwendungen fallen mir gerade keine Art
von Anwendungen ein, die unbedingt Interrupts benutzten mten und gewinnbrin-
gend ins PMOD-Format gewandelt werden knnten, deshalb fehlen Interruptinfos
vorerst.

Verbesserungsvorschlge an:

Jochen Knaus
Nickeleshalde 19
88400 Biberach
Deutschland