home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ST-Computer Leser 2002 January
/
STC_CD_01_2002.iso
/
UTILS
/
LIBERTY
/
DOKU
/
LIBERTY.TXT
< prev
Wrap
Text File
|
2000-09-07
|
59KB
|
1,347 lines
Liberty
Dokumentation zur Version 1.35
06.09.2000
von
Christian Krüger
Sophienstr. 10a
12203 Berlin
Inhaltsverzeichnis
==================
1 Rechtliches / Copyright
1.1 Haftungsausschlu₧
1.2 Warenzeichen
1.3 Spenden
2 Installation
2.1 Bootreihenfolge
3 Was ist Liberty?
4 Was bietet Liberty?
4.1 CJar-Erweiterung
4.2 Soundfunktionen
4.3 Vektorgrafikfunktionen
4.3.1 Der Konvertierer GM2CKVDI
5 An die programmierenden Zunft
5.1 Allgemeines
5.1.1 Parameterübergabe
5.2 Der Liberty-Cookie & XBIOS-Erweiterung
5.3 Die Liberty-Struktur
5.4 Die Utility-Funktionen
5.4.1 Init_Liberty();
5.4.2 lock_Sema();
5.4.3 release_Sema();
5.4.4 memcpy();
5.4.5 memset();
5.5 Die 'GEMDOS-Erweiterungen'
5.5.1 CK_init_meminfo()
5.5.2 CK_malloc()
5.5.3 CK_realloc()
5.5.4 CK_free()
5.5.5 CK_load_buffer()
5.6 Die 'VDI-Erweiterungen'
5.7 Die 'AES-Unterstützung'
5.8 Die Sound-Funktionen
5.9 Programmbeispiel
6 Ausblick
7 Changes
8 Kontaktadresse
1 Rechtliches / Copyright
**************************
Das Copyright an Liberty und dieser Dokumentation liegt bei Christian
Krüger, Berlin. Die Weitergabe des Programms ist Grundsätzlich frei
(Stichwort FREEWARE), dennoch sind folgende Punkte zu beachten:
∙ Das Programm darf nur mit allen zugehörigen Dateien und in
*unveränderter* Form weitergegeben werden. Entweder unkomprimiert
oder als 'Zip'-Archiv. Folgende Dateien müssen folglich im Archiv
enthalten sein (-> = Ordner):
LIBERTY -> AUTO -> LIBERTY.PRG
DEVELOP -> IBMR.H
VDICODES.H
DOKU -> HTML -> LIBERTY.HTM
LIBERTY.GIF
MYSELF.GIF
UDO_LF.GIF
UDO_RG.GIF
UDO_UP.GIF
LIBERTY.TXT
LIBERTY.H
LIBERTY.HYP
MCSNDPAT -> MACSND.DFY
PATCHY.TTP
SIZEJAR.TTP
GM2CKVDI.TTP
∙ Das Programm darf generell nur kostenlos weitergegeben werden.
Der Upload in gebührenfreie Mailboxen und auf nichtkommerzielle
FTP-Server ist erlaubt und erwünscht.
∙ Dem Archiv dürfen keine weiteren Dateien hinzugefügt werden,
insbesondere keine Mailboxwerbung und keine Werbung für PD-
Serien. Die Umbenennung oder das Umpacken des Archivs ist
unerwünscht.
∙ Das Programm darf anderen Programme beigelegt werden - unter der
Voraussetzung, da₧ ich *vor der Veröffentlichung* darüber
informiert werde und ein eindeutiger Hinweis auf die Versions-
nummer der beigefügten Liberty-Version erfolgt (z.B.
hervorgehoben im 'README').
Auch hier gilt obiges 'Vollständigkeitsprinzip'!
∙ Für die Weitergabe auf Disketten im Rahmen einer Public-Domain-
Serie dürfen keine Gebühren verlangt werden, die einen Betrag von
10 DM (exklusive Versandkosten) überschreiten.
∙ Die Weitergabe via CD-ROM darf nur dann ohne schriftliche
Genehmigung erfolgen, wenn der Preis der CD pro bespieltem
MegaByte 0.1 DM nicht übersteigt!
1.1 Haftungsausschlu₧
======================
Trotz sorgfältiger Entwicklung und umfangreichen Tests kann keine
Gewährleistung für die Richtigkeit des Inhalts dieser Dokumentation
und die einwandfreie Funktion von "Liberty" übernommen werden.
Der Autor kann keine Haftung für irgendwelche direkten oder indirekten
Schäden - einschlie₧lich aber nicht beschränkt auf materielle oder
finanzielle - übernehmen, die durch die Benutzung von "Liberty" oder
dessen Untauglichkeit für einen bestimmten Zweck entstehen.
1.2 Warenzeichen
=================
Innerhalb dieser Dokumentation wird auf Warenzeichen Bezug genommen,
die nicht explizit als solche ausgewiesen sind. Aus dem Fehlen einer
Kennzeichnung kann nicht geschlossen werden, da₧ ein Name frei von den
Rechten Dritter ist.
1.3 Spenden
============
Wie schon erwähnt ist Liberty Freeware. Ich habe aber selbst-
verständlich nichts gegen TOS-Programmentwicklungsstützungskäufe ;-).
Wer mit also eine motivationssteigernde Spende zukommen lassen möchte,
kann das über die Kontaktadresse tun.
Wer keine Lust hat etwas zu spenden und trotzdem meine Motivation
steigern möchte, der sollte sich 'Freedom2' kaufen. Dann bekommt man
wenigstens etwas für's Geld ;-) ...
2 Installation
***************
*(Bitte dieses Kapitel komplett _vor_ der Installation durchlesen!)*
Kopieren Sie einfach 'LIBERTY.PRG' in den AUTO-Ordner ihres Boot-
Laufwerkes.
Nach dem Kopieren von 'LIBERTY.PRG' und dem folgenden Systemstart
installiert sich dann die Library automatisch.
2.1 Bootreihenfolge
====================
'LIBERTY.PRG' sollte physikalisch möglichst früh im AUTO-Ordner
stehen, auf jeden Fall vor (wenn Sie es denn einsetzen) MiNT! Viele
Bootselektoren (z.B. XBOOT) erlauben es, konfortabel die
Bootreihenfolge der AUTO-Ordner Programme zu verändern. Sollten Sie
nicht in Besitz eines solchen Programms sein hilft folgendes:
Betrachten Sie sich ihren AUTO-Ordner im Desktop in unsortierter
Ausgabeart. Hier sollte 'LIBERTY.PRG' möglichst weit vorne stehen. Ein
Ändern der Bootreihenfolge erreichen Sie durch Verschieben des
kompletten AUTO-Ordners in ein anderes Verzeichnis und dem
Zurückverschieben aller AUTO-Ordner-Programme in gewünschter
Reihenfolge in den AUTO-Ordner. (Wer absolut nicht versteht was ich
meine, kann mich unter später genannter Adresse kontaktieren.)
MagiCMac Benutzer müssen den Umweg über Umbenennen der Dateien oder
Bootreihenfolgedatei (wie in der MagiCMac Dokumentation beschrieben)
gehen um Liberty möglichst früh zu initalisieren (MiNT wird wohl
keiner auf Macs benutzen ;-) ).
3 Was ist Liberty?
*******************
Liberty ist eine residente Systemerweiterung. Das bedeutet, da₧ eine
Vielzahl von Funktionen die in Liberty vorhanden sind, anderen
Programmen angeboten werden. Das blo₧e Vorhandensein von Liberty
ändert nicht viel an Ihrem System, sondern die Funktionen der Library
(oder auch Systemerweiterung, folgend Lib genannt) müssen von anderen
Programmen genutzt werden. Freedom2 ist z.B. ein solches Programm.
Freedom2 benutzt viele der Liberty-Funktionen, so da₧ es ohne diese
Lib nicht lauffähig ist.
Nun gibt es (oft zurecht) viele Gegner solcher Systemerweiterungen.
Die Argumente gegen den Einsatz einer residenten Erweiterung sind
meistens folgende:
∙ residente Systemerweiterungen schlucken permanent Speicher, auch
wenn sie nicht benötigt werden
∙ residente Systemerweiterungen werden oftmals nur von wenigen
Programmen unterstützt und viele Funktionen der Erweiterung
werden nicht benötigt, was dann ebenfalls Speicherverschwendung
bedeutet
∙ residente Systemerweiterungen sind gro₧, klobig und unflexibel;
bei Zugriff von mehreren Programmen auf eine Funktion der
Erweiterungen gibt es oft Probleme oder der Rechner wird
'gebremst' (Experten mögen mir verzeihen, da₧ ich hier nicht von
Semaphoren spreche :-) )
Die Vorteile solcher Erweiterungen:
∙ das 'Rad' mu₧ nicht tausendmal neu erfunden werden; Programme
können die angebotenen Funktionen einfach benutzen ohne zu wissen
was sie (die Funktionen ;-)) genau machen (daraus folgt eine
wesentlich kürzere Entwicklungszeit und (hoffentlich) mehr Spa₧
am Programmieren, da man sich auf die programmspezifischen
Probleme konzentrieren kann)
∙ benutzen viele Programme die Systemerweiterung gibt es einen
Speicherspareffekt: die von vielen Programmen benötigten Routinen
der Systemerweiterung sind nur einmal im Speicher und nicht in
jedem der Programme extra vorhanden.
Liberty hat natürlich diese Vorteile und entkräftet zusätzlich mit
seiner Art des Aufbaus die Nachteile:
∙ Liberty verbraucht weniger als 30kB Speicher! (ist also kein
'grober Klotz' wie andere Libs die gleich 300kB oder mehr an
Speicher verschlingen)
∙ Liberty konzentriert sich auf die wesentlichsten Mankos des
Betriebsystems und beseitigt sie; es ist keine GEM-Interface-
Library! (wäre wohl auch sinnlos zu versuchen alle GEM-Lib-
Programmier- Süppchen zu einem Standard zu vereinigen ;-) )
∙ fast alle Funktionen der Lib werden von Freedom2 benutzt (wer
kommt schon ohne aus? ;-) ); von Speicherverschwendung kann bei
Einsatz von Freedom2 folglich nicht gesprochen werden (bei 30kB
ist dieses ohnehin schon ziemlich unglaubwürdig); bereits bei
Einsatz eines zweiten Programms welches Liberty benutzt, tritt
der gewünschte Speicherspareffekt ein
∙ Liberty besteht zu 90% aus hochoptimierten Assembler-Routinen;
nur so konnte die Kürze und Geschwindigkeit der Erweiterung
erreicht werden
∙ alle Funktionen von Liberty sind reentrant und 90% der Funktionen
sind 'Multi-Threading'-fähig (d.h. mehrere Programme können
gleichzeitig eine Funktion von Liberty benutzen ohne sich dabei
gegenseitig zu stören oder zu blockieren)
Überzeugt?
4 Was bietet Liberty?
**********************
Liberty setzt sich aus Funktionen mit den unterschiedlichsten
Aufgabengebieten zusammen. Obwohl daher das Funktionsangebot
vielleicht etwas zusammengewürfelt scheint, ist dem nicht so. Wie
schon erwähnt versucht Liberty die nervensten Schwächen des
Betriebsystems auszugleichen: Funktionen, die immer wieder
programmiert oder eingebunden werden müssen und die viele Programme
benötigen. Das diese Schwächen nicht konzentriert an einer Stelle des
Betriebssystems auftreten ist logisch. So besteht die Lib intern aus
folgenden Teilen:
XBIOS-Erweiterung bzw. Nutzung:
∙ CJar-kompatibele XBIOS Erweiterung, die auf
komfortabele Weise das Erzeugen, Abfragen und Löschen
von 'Cookies' ermöglicht
∙ Soundfunktionen welche eine rechnerunabhängige
Tonausgabe garantieren
Erweiterungen mit GEMDOS-Charakteristik:
∙ eine sehr effiziente und schnelle Speicherverwaltung,
die privaten, globalen, normalen und alternativen
Speicher (wenn nötig) unterscheidet und kleinere
Speicherblöcke in grö₧eren verwaltet sowie für ein
dauerhaftes, sicheres 'malloc' für ACCs unter SingleTOS
sorgt
∙ eine Routine zum Laden einer Datei in einen Puffer
(sollte die Datei mit ATOMIK 3.5 gepackt sein, so wird
diese automatisch ausgepackt!)
Erweiterungen mit VDI-Charakteristik:
∙ eine Vielzahl von sehr schnellen Rastergrafikfunktionen
(Laden von XIMG/GIF, Skalieren etc.)
∙ Vektorgrafikfunktionen (Translation, Rotation,
Skalierung, ...) - damit sind endlich auf einfache und
komfortabele Weise Vektoricons realisierbar
AES-Unterstützung:
∙ Funktionen zum einfachen Einhängen von Funktionen in
einzelne AES- Calls (mit Applikationszustandslisten!)
∙ LIBERTY ist in der Lage (auch wenn kein Programm
Liberty benutzt) defekte AES-Calls (nicht
initalisiertes Global-Field) zu reparieren! Damit wird
u.a. erreicht, da₧ z.B. der Dateiselektor Freedom auch
von ('Schweine'-)Programmen aufgerufen werden kann, bei
denen sonst die normale Dateiauswahlbox erscheinen
würde!
4.1 CJar-Erweiterung
=====================
Liberty legt beim Start im AUTO-Ordner automatisch einen 'Cookie-Jar'
an. Programme die dieses sonst übernommen haben ('CJARxxx.*' etc.)
sind damit überflüssig! Ebenfalls, das für den MiNT Aufsatz 'Geneva'
benötigte 'JARxxx.PRG' ist unnötig. In Liberty sind die Fähigkeiten
dieses Programms enthalten! (JARxxx wurde getestet, für gut befunden
und die Funktionalität (erweitert) aufgenommen.)
Die Grö₧e des 'Cookie-Jar' kann mit dem beigefügten Programm
'SIZEJAR.TTP' verändert werden. In der Grundeinstellung wird beim
Start von Liberty für 32 zusätzliche 'Kekse' (zu den aktuell
vorhandenen Systemcookies) Platz geschaffen. Diesen Wert kann man
wiefolgt ändern:
1. Man kopiert 'SIZEJAR.TTP' in das Verzeichnis in dem 'LIBERTY.PRG'
steht (also normalerweise in den AUTO-Ordner).
2. Man startet das Programm durch Doppelklick und gibt dann die
gewünschte Anzahl an Keksen als Zahl in den erscheinenden Dialog
ein.
3. Nach Beendigung des Programms mu₧ man 'SIZEJAR.TTP' wieder aus
dem AUTO-Ordner entfernen.
4. Beim Neustart des Systems berücksichtigt dann Liberty die
angegebene Anzahl. Fertig!
In der Regel sollte dieses Vorgehen jedoch unnötig sein, da 32
(zusätzliche) Kekse ausreichen und auch keine gro₧e
Speicherverschwendung darstellen.
4.2 Soundfunktionen
====================
Liberty bietet eine komfortable und *einheitliche* Schnittstelle zur
Soundausgabe. Mit Hilfe dieser Erweiterung können (bald) alle Benutzer
von Atari-Kompatiblen in den Genu₧ eines klangvollen Erlebnisses
kommen. Die Zeiten bei denen Programme die Soundausgabe auf bestimmte
Systeme einschränken, oder diese nur mit /käuflichen/ Programmen
garantieren, sollten damit für immer vorbei sein.
Realisiert wurde die Soundausgabe schon für Rechner mit DMA-Sound
((Mega)STE/TT), FalconO3O sowie für Apple-Rechner mit 'MacSound'.
Rechner mit PSG-(Emulation) folgen demnächst.
Bisher hatte ich noch keinen Kontakt zu Medusen oder dem Hades, halte
hier aber eine Anpassung für die exisiterende Soundkarte ebenso wie
für PC's mit XBIOS-Treiber möglich (...legt STARTRACK ein McSn-Keks
an? - Dann funktioniert auch mit dieser Karte schon die Sound-
Ausgabe...).
Wichtig ist nur, da₧ sich ein Anwenderprogrammierer keine Gedanken
mehr um evt. Soundfähigkeiten des Rechners machen mu₧. Das
Vorhandensein von Liberty garantiert ein Ansprechen der
Soundfunktionen, auch wenn diese ohne Treiber funktionslos bleiben.
_*Zum Patchprogramm für MacSound (nur für Apple-Rechner):*_
MacSound (ein Autoordnerprogramm welches MagiCMac beiliegt und XBIOS-
Soundfunktionen zur Verfügung stellt) ist leider nicht so mächtig wie
es anderen Programmen gegenüber vorgibt. Um korrektes Funktionieren zu
gewährleisten, ist es daher nötig MacSound zu patchen. Eine Patchdatei
mit dem entsprechenden Patchprogramm befindet sich im Ornder
'MCSNDPAT'.
Um MacSound zu patchen, mu₧ man folgenderma₧en vorgehen:
∙ Zunächst 'MACSND.PRG' (mü₧te im Auto-Ordner liegen) in das
'MCSNDPAT'-Verzeichnis verschieben.
∙ Nun die Datei 'MACSND.DFY' auf das Programm 'PATCHY.TTP' im
gleichen Verzeichnis ziehen und fallenlassen (Drag&Drop).
∙ Anschlie₧end das Programm 'MACSND.PRG' aus diesem Verzeichnis
(welches nun angepasst ist) wieder in den Auto-Ordner
verfrachten. MagiCMac neustarten, fertig!
Falls irgendwelche Fehler auftreten sollten, handelt es sich wohl
nicht um die Version 1.0 von MacSound (nur diese kann gepatcht
werden)! Sollte man eine ältere Version haben, unbedingt die neuere
besorgen. Ob eine neuere Version als die 1.0 existiert (wenn ja bitte
melden!), kann ich nicht sagen, mir ist jedenfalls keine bekannt. Der
Patch setzt die Versionsnummer übrigens auf 1.01 herauf!
/Bei Fragen oder Hinweisen zu diesem Thema bitte die Kontaktadresse/
/benutzen!/
Nach dem Patchen wurde im Verzeichnis 'MCSNDPAT' das Verzeichnis
'PATCHED' angelegt, welches die Ursprungsversion von MacSound enthält.
Eine Sicherungskopie der Originals wird also automatisch erzeugt.
/An dieser Stelle Dank an Christian Wempe & Holger Weets für ihr/
/Patchprogramm 'DIFFY' bzw. 'PATCHY'. Ich hoffe es ist Ok, da₧ ich/
/'PATCHY' einfach so (einzeln - um Verwirrung zu vermeiden...)/
/beigefügt habe (in eurer Doku steht zu diesem Thema leider nichts),/
/schlie₧lich ist Liberty ja auch Freeware. Das komplette Archiv zu/
/'Diffy 2' sollte man in jeder guten 'Maus / ftp-site' finden./
Ein kleiner Soundtest der Liberty-Funktionen gefällig?
Den Info-Dialog von Freedom2 aufrufen (Klick mit der rechten Maustaste
auf das Freedom2-Logo bei *installiertem* Konfig.CPX) und anschlie₧end
das gro₧e Freedom2-Logo im Info-Dialog anklicken...
Wenn sie einen (Mega)STE/TT/FalconO3O oder MagiCMac mit gepatchtem
MacSound benutzen, dann mü₧ten sie was 'Nettes' gehört haben...
4.3 Vektorgrafikfunktionen
===========================
Vektorzeichensätze und Bezierkurven sollten heutzutage eine Selbst-
verständlichkeit sein. So werden diese Befehle auch von den
Vektorgrafikfunktionen in Liberty ordnungsgemä₧ verarbeitet. Leider
ist das Original-VDI (der Betriebssystemteil der für die Ausgabe von
Grafiken verantwortlich ist) nicht in der Lage diese Befehle zu
verarbeiten und ignoriert sie völlig.
Das bedeutet, da₧ wenn ein Programm die Vektorgrafikdarstellungs-
funktionen von Liberty benutzt und die darzustellende Grafik
Bezierkurven und/oder Vektorzeichensätze enthält, das Ergebnis auf dem
Bildschirm nicht der Originalgrafik entspricht. Dieses trifft aber
selbstverständlich nur für VDIs zu, die diese Befehle nicht verstehen!
Wie alle Funktionen von Liberty sind auch die Vektorgrafikfunktionen
auf Geschwingidkeit getrimmt. Bei der Vektorgrafikausgabe wurde z.B.
ein gro₧er Geschwindigkeitsvorteil dadurch erreicht, da₧ die Ausgabe
_direkt_ an das VDI geleitet wird und die Befehle nicht erst durch einen
TRAP geschickt werden! Das dabei verwendete Verfahren ist keinenfalls
'schweinisch' sondern bekannt! (Für die Experten: Man läd das Register
D0 mit -1 und macht einen TRAP #2 Aufruf. Als Ergebnis erhält man die
Einsprungsadresse des VDI-Dispatchers.)
VDI-Erweiterungen, die das VDI hinsichtlich z.B. einer
Bezierkurvenausgabe erweitern, müssen dieses Verfahren unterstützen
(Profibuch, 10. Auflage, Seite 298 unten)!
'NVDI' (da sauber) hat damit keine Probleme und in Verbindung mit
diesem VDI klappt die Ausgabe obiger Befehle wunderbar (auch wenn
'NVDI' nur als GDOS eingesetzt wird)! Leider kann man das vom
'SpeedoGDOS' nicht behaupten. Diese VDI-Erweiterung versäumt es
offensichtlich obiges Verfahren zu unterstützen und somit ist dieses
Ausgabesystem für Liberty praktisch nicht vorhanden (keine
Bezierkurven und keine Vektorzeichensätze!!!).
Ich wei₧, da₧ diese Tatsache sicherlich einige Leute ziemlich
verärgert und möchte deshalb hier Forderungen nach 'konformer' Ausgabe
über den TRAP vorbeugen:
∙ die oben beschriebene Vorgehensweise ist konform, da sie bekannt
ist und es offensichtlich auch ein Ausgabesystem gibt (NVDI),
welches damit keine Probleme hat; Liberty ist folglich
unschuldig, das Problem liegt beim unvollständigem Ausgabesystem
(SpeedoGDOS)
∙ ein Abändern der Liberty-Vektorgrafikausgabe brächte unzumutbare
Geschwindigkeitseinbu₧en für Benutzer mit konformen
Ausgabesystemen
∙ ich habe wenig Lust die Fehler anderer Programmierer
auszubügeln...
Meine Empfehlung an SpeedoGDOS-Fanatiker die programmieren können:
Programmiert ein Utility welches sich in den TRAP #2 hängt, die -1
abfängt und die Adresse des SpeedoGDOS-Dispatchers zurückliefert. Dann
klappt's auch mit Liberty... ;-)
4.3.1 Der Konvertierer GM2CKVDI
--------------------------------
Um GEM-Metafiles in das Liberty-Vektorformat umzuwandeln ist ein
Konvertierer beigefügt (GM2CKVDI.TTP). Das Liberty-Vektorgrafikformat
kann mehrere einzelne Grafiken enthalten, welche es interessant für
Vektoricons machen.
Da GEM-Metafiles oft sehr 'gro₧zügig' und unpräzise erzeugt werden,
ist es nicht ausgeschlossen, da₧ der Konvertierer bei einigen Dateien
ziemlich komische Ergebnisse erzeugt. Dieses ist abhängig vom Programm
mit dem die Dateien erzeugt wurden. Ausgerichtet ist der Konvertierer
auf Dateien die mit 'Kandinsky (2.01)' kreiert wurden. Hiermit werden
korrekte Ergebnisse erzielt.
_Der Aufruf:_
GM2CKVDI -[cpnswm16h?] metafilename
Die übergebene Datei _mu₧_ mit '.GEM' enden. Die Zieldatei wird im
Verzeichnis der Quelldatei erzeugt und erhält je nach angegebenem
Zieltyp die Dateiendung '.CVD' oder '.C'.
_Die Optionen:_
Für den Übersetzungsvorgang existieren einige Optionen:
-h,-help,-? zeigt eine kurze Hilfe mit Erläuterung der Optionen an
-n setzt im Header der Zieldatei den Namen der Grafik.
Dieser Name kann auch über die Grafik darselbst
definiert sein, indem die Grafik mit dem speziellen Text
'((CN))/NAME/' versehen wird. Dieser Textbefehl wird _nicht_
übersetzt und dient lediglich zum Setzen des
Vektorgrafiknamens im Zieldateikopf.
-s # setzt den Grö₧enma₧stab. Dieser legt die maximale
Ausdehnung der zu erzeugenden Datei fest. Mit diesem
Wert wird natürlich auch die Quantisierung der
Grafikkoordinaten in der Zieldatei bestimmt. Der
Defaultwert ist 255. Der übergebene Wert darf zwischen 1
und 32000 liegen.
-c die Zieldatei wird nicht als Binärfile sondern als C-
Quellcode abgelegt. Besonders dann praktisch, wenn man
die Vektordaten in ein Programm mit einbinden möchte. Um
die Vektordaten einbinden zu können, benötigt man die
'.h'-Dateien im Ordner 'DEVELOP'. Die Dateiendung der
Zieldatei ist in diesem Modus '.C'.
-m die angegebene Quelldatei enthält mehrer Vektorgrafiken
die umgewandelt werden sollen (z.B. bei
Vektoricondateien). Der Konvertierer erkennt die
einzelnen Vektorgrafiken in einer solchen Datei daran,
da₧ die diversen Vektorgrafikobjekte als 'Top-Level-
'Gruppe definiert worden sind (Kandinsky: Gruppieren).
Als 'Top-Level' bezeichne ich alle Gruppen die direkt,
ohne weitere Gruppenauflösung in der Vektorgrafik
erreichbar sind. Diese 'Top-Level-Gruppen' dürfen
folglich problemlos in ihrer (internen) Struktur weitere
Objektgruppen enthalten. Top-Level-Gruppen werden dann
jeweils in der Zieldatei als eigenständige
Vektorgrafiken verkettet. Da es sinnvoll ist, den
Grafiken eigene Namen zu verleihen und über die Option
-n nur ein Name gesetzt werden kann, solte man in jeder
Gruppe den Spezialtext '((CN))/NAME/' ablegen um die
einzelne Grafik später identifizieren zu können.
/Die Vorhergehensweise wird klarer, wenn man eine GEM-/
/ Meta-Datei des Dateiselektors Freedom2 untersucht/
/ (liegen in der Freedom2-Distribution im Ordner/
/ 'VICON\SRC\')./
-16 Farbfixierung nur mit den ersten 16 (Standard-)VDI-
Farben vornehmen. Beim Umwandlungsvorgang werden die
Farben der GEM-Metadatei die noch als Farbanteile
beschrieben sind in absolute VDI-Indizes umgewandelt.
Dieses geschieht nach dem Verfahren 'Best-Fit' mit der
aktuellen Farbpalette. Da es nun nicht ausgeschlossen
ist, da₧ die benutzten Farben der GEM-Metadatei leicht
von den 16 unteren Systemfarben abweichen und als
bestpassenste Farben Farben mit einem Index >16 gefunden
werden, kann man die Suche auf die ersten 16 Farben mit
diesem Schalter beschränken. Da die ersten 16 Farben von
DR festgeschrieben sind, kann man so eine 'farbportable'
CVD-Datei erzeugen.
-w Anzeige des Konvertierungsvorgangs. Alle Übersetzten
VDI-Befehle werden auf dem Bildschirm ausgegeben.
Hauptsächtlich ist der Konvertierer (wie man vielleicht festgestellt
haben wird) für ambitionierte Anwender und Programmierer interessant.
5 An die programmierenden Zunft
********************************
Sie sind Programmierer, die Featureliste von Liberty hat Sie locker
vom Hocker geworfen und Sie sagen sich:"Eine tolle Library, die will
ich auch unterstützen!"
/Kein Problem!/
Einzige Voraussetzung um die Library benutzen zu dürfen: Ich erhalte
ein kostenloses Exemplar des Programms welches die Library benutzt!
Software die den Status 'Public Domain', 'Freeware' oder 'Fairware'
hat, ist davon natürlich ausgenommen ;-).
In der letzten Doku zu Liberty habe ich noch von einer seperaten
Dokumentation für Programmierer gesprochen. Da die Resonanz aber
unerwartet gro₧ war und ich mir die Arbeit zwei Dokumentationen zu
pflegen ersparen möchte, wird die Beschreibung der Liberty-Funktionen
*schrittweise* in diese Doku eingeflechtet.
/Was sie folgend als Beschreibung finden ist *keineswegs* vollständig!!!/
Man kann aber schon damit beginnen seine Programme anzupassen, um so
in den Genu₧ der Liberty-Funktionen zu gelangen. Alles was folgend
dokumentiert ist, wird sich *nicht* mehr ändern und kann demzufolge
problemlos verwendet werden.
5.1 Allgemeines
================
Ich möchte an dieser Stelle nicht alles wiederholen was bereits oben
beschrieben wurde. Daher nur nochmal ein Kurzüberblick über das, was
Programmierer wissen müssen:
∙ Alle Liberty-Funktionen sind reentrant! Man braucht sich folglich
*keine* Gedanken darüber machen, ob eine Funktion schon von anderen
Programmen/Threads benutzt wird!
∙ Bevor man eine Liberty-Funktion aufruft sollte man lediglich
sicherstellen, da₧ die Funktion genügend Stack zur Verfügung hat.
Genügend hei₧t dabei *1k*! Mehr ist auf keinen Fall nötig, dieser
Platz sollte aber bereitgestellt werden.
∙ Liberty verändert keine Registerwerte in einer Funktion.
∙ Wenn eine Liberty-Funktion einen Rückgabewert liefert, sollte
dieser auch geprüft werden, um die korrekte Abarbeitung der
Funktion festzustellen.
∙ AUF JEDEN FALL nur dokumentierte Funktionen und Eigenschaften
nutzen!
∙ Jeden Hinweis auf Umgang mit Funktionen *genaustens* beachten.
Wenn eine Variable als 'Read-Only' gekennzeichnet wurde, sollte
man sie auch nicht überschreiben!
∙ Um Doppeldeutungen zu vermeiden: Ein Programm welches Liberty
benutzt wird folgend immer als 'Applikation' bezeichnet. Das
sollte man im Hinterkopf behalten...
5.1.1 Parameterübergabe
------------------------
Für die Parameterübergabe gelten die Regeln von Turbo C / Pure C:
_Parameterübergabe Pure C (Auszug aus der Online Hilfe von PureC)_
∙ Die ersten drei Variablen vom Typ char, int oder long werden in
den Registern D0, D1, D2 übergeben.
∙ Die ersten zwei Adressparameter (Pointer) werden in den Registern
A0 und A1 übergeben.
∙ Weitere Parameter, die keinen Platz mehr in den Registern D0, D1,
D2, A0 A1 finden werden über den Stack übergeben.
∙ Parameter werden in der Reihenfolge von rechts nach links
übergeben.
_Beispiel:_
extern void lbf(int x1, int y1, int x2, int y2, int *l, int *b, int *f);
main()
{
int x1 = 10, y1 = 10, x2 = 20, y2 = 20, l, b, f;
lbf(x1, y1, x2, y2, &l, &b, &f);
}
Da mehr Werte-, als auch Adress-Parameter an die Funktion "lbf"
übergeben werden, als Register zur Verfügung stehen, benötigen wir
also in jedem Fall den Stack. Der vierte Werte-Parameter mu₧ auf dem
Stack abgelegt werden. Ebenso findet der dritte Adress-Parameter
keinen Platz in den Registern, so da₧ auch dieser auf dem Stack
abgelegt werden mu₧.
In den Registern befinden sich:
D0: x1 (Wert von x1)
D1: y1 (Wert von y1)
D2: x2 (Wert von x2)
A0: &l (Adresse der Variablen l)
A1: &b (Adresse der Variablen b)
Auf dem Stack befinden sich:
&f (hi) (höchstwertiges Wort im Stack)
&f (lo)
y2 (Wert von y2)
Return- (Rücksprungadresse)
Adresse (Stackpointer zeigt hierauf)
Der Adress-Parameter f wird nach der Regel "von-rechts-nach-links"
zuerst auf den Stack gelegt. Danach kommt der Wert von y2 auf den
Stack. Bitte beachten Sie, da₧ die Rücksprungadresse des
Unterprogrammes als letzter "Parameter" auf den Stack gelegt wird, so
da₧ die Parameter im Stack ab dem Offset 4 anfangen. y2 (Offset 4), &f
(Offset 6)!
In C räumt die aufrufende Funktion nach dem Aufruf die Parameter
selbst vom Stack (z.B. mit ADDQ.W #8,A7", nach einem Aufruf mit zwei
Adressparametern). Dies erübrigt sich natürlich, wenn alle Parameter
in Registern übergeben wurden.
5.2 Der Liberty-Cookie & XBIOS-Erweiterung
===========================================
Liberty legt beim Start im Auto-Ordner einen Cookie-Jar an und erzeugt
einen Keks namens 'Lity' dessen Inhalt auf eine Struktur weist, die
dem beigefügten '.h'-File und dem entsprechendem Kapitel (Die
Liberty-Struktur) entnommen werden kann.
Da Liberty XBIOS-Funktionen installiert, die einen komfortablen
Zugriff auf den Cookie-Jar ermöglichen, kann auf sehr einfache Art und
Weise das Vorhandensein von Liberty festgestellt werden.
Dazu ein Ausschnitt aus dem '.h'-File:
#define CJar_xbios 0x434A /* "CJ" */
#define CJar_OK 0x6172 /* "ar" */
#define COOKIE_LIBERTY 0x4C697479L /* "Lity" */
#define CJar( mode, cookie, value ) xbios(CJar_xbios,mode,cookie,value)
Folgendes 'Programm' prüft somit, ob die Systemerweiterung vorhanden
ist:
Liberty_Cookie *libfuncs;
if (CJar(0, COOKIE_LIBERTY, &libfuncs)==CJar_OK)
{
printf("LIBERTY vorhanden!!!");
}
else
{
printf("LIBERTY nicht vorhanden!!!");
}
Bevor ein Programm Liberty benutzt, sollte auf jeden Fall durch obiges
Verfahren festgestellt werden ob Liberty überhaupt vorhanden ist! Ist
dies nicht der Fall mu₧ das Programm gegebenenfalls terminiert werden.
_Zu den verschiedenen Modi:_ Der erste Parameter der dem Makro 'CJar'
übergeben wird, bestimmt den Modus der Cookie-Aufrufs. Im Gegensatz
zum Original 'Cookie Jar Manager' von Dan Wilga (Liberty ist voll zum
'JARXX' kompatibel, man benötigt es also nicht mehr), existieren sogar
3 Modi zur Keks-Manipulation:
∙ Modus 0:
Ermittelt den Wert des Kekses und legt in an der angegebenen
Adresse ab. Übergibt man für 'value' einen NULL Pointer, so wird
lediglich die Existenz des Kekses überprüft.
Bei erfolgreicher Ermittlung des Kekses, liefert der Aufruf
0x6172 (="CJar_OK") zurück sonst einen anderen Wert.
∙ Modus 1:
Erzeugt einen neuen Keks (cookie). Value *zeigt* auf einen Wert der
in den Jar eingetragen wird. WICHTIG! Es wird nicht 'value'
eingetragen sondern der Wert auf den 'value' weist!!! Bei
Übergabe eines NULL-Pointers wird 0 als Kekswert eingetragen.
Existiert der Keks bereits, so wird sein alter Inhalt
überschrieben!
Die Funktion liefert "CJar_OK" bei erfolgreicher Eintragung. -1
wird für den Fall geliefert, da₧ der Cookie-Jar voll ist!
∙ Modus 2:
Entfernt den Keks 'cookie' aus dem Jar. Der Wert von 'value' ist
egal. Liefert bei erfolgreicher Entfernung "CJar_OK" sonst einen
anderen Wert.
5.3 Die Liberty-Struktur
=========================
Der Inhalt des Liberty-Cookies weist auf folgende Struktur:
typedef struct
{
WORD version; /* Hexadezimale Version. (0x0100 = 1.0) */
WORD gdriver; /* Unterstützes Grafiksystem (READ_ONLY!):
* 0 = keins -> Standardformat (SLOW!!!)
* 1 = ATARI Grafiksystem (IBPs)
* 2 = NOVA Grafikkarten (Intel-Zahlenformat)
* 3 = andere Grafikkarten/Mac? (Motorola)
* Wert ist bis zur Version 1.5 ungültig!!! */ */
Lity_Utils *misc_funcs;/* Zeiger auf diverse Routinen */
Lity_GDExt *gd_funcs; /* Zeiger auf die 'GEMDOS'-Erweiterungen */
Lity_VDIExt *vdi_funcs; /* Zeiger auf die 'VDI'-Erweiterungen */
Lity_AESExt *aes_funcs; /* Zeiger auf die 'AES'-Erweiterungen */
Lity_SNDExt *snd_funcs; /* Zeiger auf Sound-Funktionen */
} Liberty_Cookie;
Neben der Versionsnummer und dem Code für das unterstützte
Grafiksystem findet man hier fünf weitere Zeiger auf Strukturen die
folgend erläutert werden.
5.4 Die Utility-Funktionen
===========================
Die Funktionen die man hier vorfindet lassen sich nicht einer
bestimmten Kategorie unterordnen. Die Struktur enthält mehr oder
weniger 'zusammengewürfelte' Funktionszeiger:
typedef struct
{
LONG (*Init_Liberty)(WORD g_handle);
void (*lock_Sema)(BYTE *semaphore);
void (*release_Sema)(BYTE *semaphore);
void (*memcpy)(void *dest, void *src, ULONG len);
void (*memset)(void *dest, int val, ULONG len);
} Lity_Utils;
5.4.1 Init_Liberty();
----------------------
bekommt als Eingabeparameter das Handle der physikalischen VDI-
Workstation, in der Form wie es vom AES-Call 'graf_handle()' geliefert
wird. Der Rückgabewert ist reserviert.
*Diese Funktion ist vor allen anderen Liberty-Funktionen aufzurufen*
*(abgesehen von der XBIOS-CJar-Erweiterung)!*
Da der Aufruf von graf_handle() unbedingt _nach_ einem appl_init() zu
erfolgen hat (Stichwort: korrekte Applikationsprogrammierung), mu₧ der
appl_init()-Aufruf logischerweise vor dem graf_handle()-Aufruf erfolgt
sein. Die Reihenfolge der Initalisierung kann man auch dem
Programmbeispiel entnehmen.
5.4.2 lock_Sema();
-------------------
Setzt (z.B. für Prozesskommunikation) eine Semaphore, dessen Adresse
übergeben wird. Wer mit dem Begriff 'Semaphore' nichts anfangen kann,
wird diese Funktion wahrscheinlich auch nicht benötigen.
5.4.3 release_Sema();
----------------------
Gibt eine 'gelockte'-Semaphore wieder frei.
5.4.4 memcpy();
----------------
Bei dieser Funktion handelt es sich um das altbekannte 'memcpy' jeder
'string.h'-C-Biblothek, welches einen Speicherbereich vorgegebener
Länge kopiert.
Warum dieser Funktion in Liberty aufgenommen wurde?
Weil viele Programme (inkl. Liberty selbst) diese Funktion benötigen
und das Benutzen der Funktion via Liberty ein wenig Speicher bei
Applikation einspart. (Vorausgesetzt man verwendet wirklich *nur* das
Liberty 'memcpy()'!)
5.4.5 memset();
----------------
Für 'memset()' (ebenfalls eine Standard-C Funktionalität) gilt das
gleiche wie schon bei 'memcpy()' beschrieben. Nur das diese Funktion
zum Setzen eines Speicherbereiches auf einen bestimmten Wert verwendet
wird.
5.5 Die 'GEMDOS-Erweiterungen'
===============================
Die Struktur 'Lity_GDExt' enhält fünf Funktionen die alle 'GEMDOS'-
charakteristisch sind. Hauptsächlich dienen die Funktionen der
Kontrolle über die Liberty Speicherverwaltung:
typedef struct
{
Meminfo * (*CK_init_meminfo)(Meminfo *info, BOOLEAN app);
void * (*CK_malloc)(Meminfo *info, const long size, const WORD type);
void * (*CK_realloc)(Meminfo *info, const void *block, const LONG newsize);
void (*CK_free)(const Meminfo *info, const void *ptr);
void *reserved;
void * (*CK_load_buffer)(char *filename, Meminfo *info, WORD type, LONG addmem, LONG *buflen);
} Lity_GDExt;
/Die Form der 'Meminfo'-Struktur entnimmt man der beigefügten '.h'-/
/Datei./
5.5.1 CK_init_meminfo()
------------------------
Eine Applikation die die Liberty-Speicherverwaltung nutzen will, muss
bevor sie Speicher via Liberty anfordern kann drei Dinge tun:
1. Eine globale Variable des Typs 'Meminfo' bereitstellen...
2. Eine globale Variable der Typs 'Meminfo*' (Zeiger auf eine
'Meminfo'-Struktur' anlegen
3. und diese durch Zuweisung des Rückgabewertes der Funktion
'CK_init_meminfo()' initalisieren.
Als ersten Parameter muss man dabei die Adresse der globalen Meminfo-
Variablen übergeben (siehem auch Programmbeispiel).
/Was ist der Sinn dieser Aktion?/
Liberty untersucht je nach Betriebssystem und Startmodus (ACC/APP) ob
es die Meminfoblöcke verschiedener Liberty-Applikationen zusammenlegen
kann, um eine effizientere Speicherverwaltung zu ermöglichen.
Folglich muss der Zeiger den man als Rückgabewert erhält nicht
identisch mit der Adresse des eigenen 'Meminfo'-Blocks sein. *Dieser*
*Zeiger (Rückgabewert) ist aber der einzige, der bei allen*
*nachfolgenden Liberty-Funktionsaufrufen die nach einem entsprechenden*
*Typ verlangen übergeben werden darf.*
_Au₧erdem:_
Jeglicher Inhalt der 'Meminfo' (Struktur-)Variablen darf von der
Applikation *nicht* angetastet werden! Liberty obligt die volle
Kontrolle dieser Struktur! Ein Verändern der 'Meminfo'-Inhalte führt
unweigerlich zur totalen Verwirrung der Speicherverwaltung und
Systeminstabilität ist die Folge!
Der zweite Parameter des 'CK_init_meminfo()'-Calls (app) besagt, ob
die Applikation als eine solche (1) oder als Accessory (0) gestartet
wurde. Zur Ermittlung dieses Wertes verwendet man das landläufige
Verfahren welches im Profibuch (10. Auflage) Seite 541 beschrieben
ist.
/Im Falle der Verwendung von PureC kann man auch gleich die Variable/
/des PureC-Startup-Codes '_app' benutzen (wie auch im/
/Programmbeispiel), oder man setzt den Parameter, für den Fall da₧ die/
/Applikation nur als eine solche und nicht als Accessory gestarted/
/werden darf, gleich statisch auf 'TRUE'./
Noch etwas:
Natürlich sollte man in seiner Applikation nur /eine/ Speicherverwaltung
nutzen. Die Vermischung von Speicheranforderungen via z.B. GEMDOS, C-
Library und Liberty führen zwar nicht zur Applikationsinstabilität,
aber sind alles andere als guter Programmierstil, da schwer
kontrollierbar (welchen Block mu₧ ich wie freigeben) und ineffizient.
Die Verwendung der Liberty-Speicherverwaltung sollte ohnehin alle
Speicheranforderungsbedürfnisse des Programmierers befriedigen und ein
Mischen von Aufrufen unnötig machen.
5.5.2 CK_malloc()
------------------
Diese Funktion fordert Speicher vom System an. Im Gegensatz zum GEMDOS
werden aber kleinere Speicherblöcke automatisch in grösseren Blöcken
gehalten um evt. Betriebssystembeschränkungen zu umgehen. Die
Verwaltung der Blöcke ist äu₧erst effizient, schnell und sollte auf
jedem Fall andern Speicheranforderungsmechanismen vorgezogen werden,
da auch noch andere Argumente für die Verwendung der Liberty-
Speicherverwaltung sprechen:
∙ Liberty sorgt auch bei Accessories unter Single TOS für ein
'festes' Malloc. Normalerweise gehört Speicher, der nachträglich
von Accessories unter Single TOS angefordert wird der aktuellen
Hauptapplikation und /nicht/ dem Accessory. Das führt beim Beenden
der Hauptapplikation zu ungewolltem Speicherverlust seitens des
Accs und ist eine häufige Fehlerquelle.
Dieses Problem existiert bei Verwendung der Liberty-
Speicherverwaltung nicht mehr!
∙ Liberty ermöglicht eine optimale Verwaltung von Speicher auch
unter Systemen mit Speicherschutz ('Memory-Protection').
Bei der Anforderung von Speicher via 'CK_malloc()' kann die
gewünschte Speicherart übergeben werden (Parameter 'type'):
MM_STGLOBAL bei Übergabe dieses Speichertyps fordert Liberty
globales (ungeschütztes) ST-RAM an (z.B. für
'Message-Puffer')
MM_STPRIVATE Liberty fordert privates (geschütztes) ST-RAM an
MM_TTGLOBAL hier fordert Liberty *vorzugsweise* globales
(ungeschütztes) TT-RAM an. Steht nicht genügend
TT-RAM (wird auch als 'Fast-RAM' bezeichnet) zur
Verfügung, wird automatisch (globales) ST-RAM
angefordert.
MM_TTPRIVATE Liberty versucht privates (geschütztes) TT-RAM zu
reservieren. Steht nicht genügend TT-RAM zur
Verfügung, wird automatisch (privates) ST-RAM
angefordert. Dieses ist wohl der am häufigsten
verwendete Typ der Speicheranforderung ('schnell &
sicher').
Das Besondere der Speicheranforderungen seitens Liberty besteht
nun darin, dass die Speicherblöcke je nach tatsächlich
vorhandener Speicherart optimiert gehalten werden. Mit anderen
Worten: Exisitiert nur globaler Speicher (weil z.B. die
Applikation unter einem Betriebssystem gestartet wurde welches
nur 'nicht privaten Speicher' unterstützt) werden alle
Anforderungen von privatem Speicher in Anforderungen von globalem
Speicher umgesetzt. Dieses Verfahren spart dadurch sogar z.T. das
Anfordern von neuen GEMDOS-Systemblöcken und damit Speicherplatz.
∙ Die Speicherverwaltung von Liberty prüft einige Kriterien ob der
von ihr verwaltete Speicher durch eine Applikation korrumpiert
wurde. In diesem Fall erhält man entsprechende Fehlermeldungen
auf dem Bildschirm. So wird man auf Applikationsfehler bei der
Verendung von Speicher hingewiesen, was bei der Entwicklung von
Programmen kein unwesentlicher Punkt ist.
Doch zurück zum 'CK_malloc()':
Neben der Übergabe des zuvor beschriebenen 'Meminfo'-Pointers wird
noch die anzuforderne Blockgrösse in Byte sowie der oben schon
beschriebene Speichertyp mit übergeben. Der Rückgabewert ist ein
Zeiger auf den Block oder 'NULL' falls entsprechener Speicher nicht
angefordert werden konnte (Speicherknappheit).
5.5.3 CK_realloc()
-------------------
Diese Liberty-Routine arbeitet analog zum C-'realloc()' und dem
Liberty-'CK_malloc()'.
/ Eine Speichertypänderung ist *nicht* möglich!/
5.5.4 CK_free()
----------------
ist die Implementierung des C-'free()' der Liberty-Speicherverwaltung.
5.5.5 CK_load_buffer()
-----------------------
Wie oft kommt es vor das ein Programmierer eine Datei in einen Puffer
laden mu₧ und jedesmal die gleiche Sequenz von Funktionsaufrufen
getätigt wird...
Damit sollte nun Schluss sein. Die Parameter der Liberty-Buffer-Lade-
Funktion sollten eigentlich selbsterklärend sein, hier aber trotzdem
die Übersicht:
filename Dateiname der zu ladenen Datei
info der schon bekannte Meminfo-Pointer
type anzuforderne Speicherart
addmem Anzahl der Bytes die zusätzlich anzufordern sind. Diese
sind nach dem Laden der Datei am Ende des Buffers und
unbelegt.
Die Funktion liefert einen Zeiger auf den angeforderten und geladenen
Buffer oder 'NULL' falls ein Fehler aufgetreten ist (Datei konnte
nicht geladen werden, zu wenig Speicher vorhanden etc.).
Jetzt kommt's: Als besonderes Schmankerl kann die Buffer-Laderoutine
aber noch mehr: Dateien die mit dem 'ATOMIK'-Packer gepackt wurden
(ein äu₧erst effzienter Packer dessen Dateien zusätzlich auch noch
flink zu dekodieren sind) werden automatisch ausgepackt!
Das Packen ist z.B. sinnvoll bei MOD-Files, bestimmten Grafikformaten,
archivierten Texten oder sonstigen einteiligen, gro₧en Dateien die
nicht oder sehr selten angetastet werden.
5.6 Die 'VDI-Erweiterungen'
============================
Hier kommt noch etwas hin...
5.7 Die 'AES-Unterstützung'
============================
Hier kommt noch etwas hin...
5.8 Die Sound-Funktionen
=========================
Hier kommt noch etwas hin...
5.9 Programmbeispiel
=====================
Das Programmbeispiel geht davon aus, da₧ die '.h'-Dateien 'LIBERTY.H'
und 'IBMR.H' in Standard-Include-Verzeichnis des C-Compilers liegen.
Das hier gezeigte Beispiel demonstriert die Initalisierung der Library
und Speicherverwaltung unter PureC:
#include <liberty.h>
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <aes.h>
#include <vdi.h>
#include <tos.h>
Meminfo minfo, *mi; /* Applikations Meminfo-Block und Zeiger */
void main(void) /* Dieses Programm macht nix... */
{
Liberty_Cookie *libstruct;
Lity_GDExt *gdfuncs;
int d1, d2, d3, d4, grhandle;
appl_init(); /* ...obwohl es einige Programmierer noch
nicht begriffen haben: DAS GEHÖRT SICH SO! */
if (CJar(0,COOKIE_LIBERTY,&libstruct) != CJar_OK)
{
form_alert(1,"[3][This Application needs LIBERTY to run...][Exit!]");
appl_exit();
return;
}
vh = graf_handle(&d1, &d2, &d3, &d4);
libstruct->misc_funcs->Init_Liberty(grhandle); /* Liberty initalisieren */
gdfuncs = libstruct->gd_funcs; /* ...trägt nur zur
Lesbarkeit bei... */
mi = gdfuncs->CK_init_meminfo(&minfo,_app); /* Speicherverwaltungsinit */
/* HIER STEHT DAS EIGENTLICHE PROGRAMM ! */
/* ...für Meminfos wird jetzt immer 'mi' übergeben !!! */
if (_app) /* Applikation ? */
appl_exit(); /* raus... (MT-OS Behandlung
der Einfachheit wegen
weggelassen) */
else
for (;;) /* Beim Acc sporadisch */
evnt_timer(0,32000); /* beenden */
}
6 Ausblick
***********
Zum Zeitpunkt dieser Veröffentlichung von 'Liberty' sind die Raster-
grafikfunktionen leider alles andere als komplett. Damit aber andere
schon jetzt zumindest in den Genu₧ der restlichen Liberty Funktionen
kommen, habe ich mich dennoch für die Herausgabe der Library im nicht
vollständigem Zustand entschieden.
Erste Erweiterung wird folglich darin bestehen, den Rastergrafikteil
vollständig auszubauen. Aber auch im Vektorgrafikteil fehlen noch
einige wünschenswerte Zusatzfunktionen.
Wie danach die Weiterentwicklung verläuft ist schwer zu sagen.
Hauptsächlich hängt das von meinen eigenen Bedürfnissen ab. Selbst-
verständlich können auch Wünsche anderer Programmierer die Liberty
nutzen (wollen) den Funktionsumfang erweitern. Jedoch werde ich strikt
darauf achten, da₧ Liberty nie mehr als 50k Speicher schluckt und
nicht zum schon beschriebenen 'Klotz' wird.
Welche Funktionen Liberty bietet kann dem 'einfachen' Anwender
eigentlich egal sein. Er kommt meist unbemerkt in den Genu₧ der
Funktion, sobald ein Programm sie benutzt. Das einzige worauf ein
Anwender achten sollte ist, da₧ er möglichst immer die neuste
Liberty-Version installiert hat. Da Liberty benutzenden Programmen
beigefügt werden darf, dürfte diese Forderung leicht zu erfüllen sein.
7 Changes
**********
*Änderungen Version 1.35*
∙ Sag' niemals nie - die Schweinerprogrammbehandlungsroutine wieder
angefasst: Liberty verwaltet nun keinen eigenen Stack für die
Korrektur unsauberer AES-Aufrufe mehr sondern verlässt sich
darauf, dass die unsaubere Applikation selbst genügend Stack zur
Verfügung stellt. Das scheint mit vielen Programmen besser zu
klappen - weniger/keine Abstürze mehr bei
'Problemkindprogrammen'. So funktionieren auch die noch älteren
(und unsauberen) 'Magic-Configurator' Versionen jetzt mit Liberty
(die neueren sowieso).
∙ Die Installation des Cookie-Jars ist für Betreiber älterer TOS-
Versionen (ohne OS-Cookie-Jar) verbessert worden: Liberty legt
jetzt selbsttätig eine Keksdose an und trägt auch schon vier
Standard-Kekse ein: PSG-Audio, ST-Video Hardware, Maschine: ST
und Prozessor '68000'er.
∙ PSG-Soundunterstützung eingebaut. Auch Besitzer eines ST's oder
Hades sollten jetzt in den Genuss der möglichen Soundausgabe via
XBIOS kommen. Leider gibt es noch ein Problem: Ist der
Tastenklick angeschalten und 'kollidiert' die Sampleausgabe mit
der Tastenklicktonausgabe, kann es zu einem 'stehenden' Pfeifton
kommen. Welcher kluge Kopf kann mir bei der Bewältigung des
Problems helfen?
Übrigens: Durch die (jetzt tatsächlich vorhandene) PSG-
Unterstützung sollte es auch keine Probleme mehr mit GEM-Jing
geben! (...das Schweigen im Walde auf STs...)
*Änderungen Version 1.31*
∙ Einen Fehler in der Speicherverwaltung von Liberty behoben, der
dafür verantwortlich war, da₧ unter 'Single TOS' mit alternativem
Speicher bei Anforderung von ST-RAM trotzdem alternatives RAM
angefordert wurde. Dadurch blieb z.B. die Soundausgabe bei obiger
Konfiguration stumm.
∙ Das Problem der Applikations-ID-Vergabe unter NAES gemildert:
Liberty kann nun AES-Calls bis zur AP-ID 128 verarbeiten (war
64). Dennoch: Dadurch das NAES immer die AP-ID seiner Prozesse
hochzählt und unbenutze IDs nicht neu vergibt, ist nach 128
Applikationsstarts Schlu₧ mit den AES-Features von Liberty. Die
Auswirkung: Freedom2 kann nicht mehr von Applikationen mit IDs
jenseits von 128 aufgerufen werden. Das Problem lä₧t sich in
Liberty nicht auf einfache Art lösen, eine weitere Steigerung des
ID-Raumes würde viel zusätzlichen Speicher verschlingen. NAES
verhält sich in diesem Punkt anders, als alle anderen TOS-
kompatiblen Betriebssysteme. Ich hoffe also das sich in NAES da
noch etwas tut ;-).
∙ ...viel, viel zu tun...
*Änderungen Version 1.30*
∙ Ich kann's nicht fassen. Unsaubere Applikation bringen mich
irgendwann einmal noch um den Verstand. In dieser Version habe
ich DEFINITIV die letzte Änderung am
Schweineprogrammbehandlungsteil vorgenommen. Eine
Sonderbehandlung für MTOS/NAES und MagiC soll nun maximale
Kompatibilität auch bei unsauberen Programmen bringen. U.a.
profitieren dadurch auch ältere Versionen von MGCOPY,MGVIEW etc.,
die, was die Sauberkeit der Systemanbindung anging, noch nicht so
prall waren. Die jetzige Schweineprogrammbehandlungsroutine ist
*definitiv* der Weisheit letzter Schluss!
Da OAESis nicht ein vernünftiges appl_find(NULL) anbietet,
sondern ziemlichen Blödsinn macht, kann ich OAESis *nicht*
empfehlen.
Liberty es ist praktisch unmöglich Liberty&Freedom2
unproblematisch unter OAESis zum Laufen zu bringen. Aussagen über
GENEVA und XAES kann ich nicht treffen.
_WICHTIG:_ Damit Liberty ordnungsgemä₧ unter MagiC arbeitet, ist
eine MagiC-Version >= 3.x unabdingbar!!!
∙ Besitzer von Rechnern mit DMA-Sound ((Mega)STE, TT) kommen nun
endlich auch in den Genu₧ der Liberty-Soundfunktionen. Neben Macs
mit 'MACSOUND' und Falcons kommt bei diesen Rechnern nun also
auch Freude auf, wenn man im Freedom2 Info-Dialog auf das gro₧e
'Freedom-Logo' klickt... (wenn die Software der Startrack-Karte
für den HADES auch einen 'McSn'-Cookie anlegt (tut sie das? wer
sagt's mir?), bekommen die HADES-User auch was zu hören...)
∙ Weitere Beschreibungen von Liberty für Programmierer in die Doku
integriert.
*Änderungen Version 1.20*
∙ Endlich arbeitet Liberty mit NAES korrekt zusammen. Was war die
Ursache? Na ? - Die Schweineprogrammbehandlung.
Ohne einen Anruf von Rainer Mannigel (NAES-Entwickler) wäre das
wohl nie etwas geworden. Durch ihn habe ich von einer NAES
internen Sache erfahren und das ermöglichte mir Liberty darauf
abzustimmen.
Ich hoffe den Schweineprogrammbehandlungsteil nun nicht mehr
anfassen zu müssen... ;-)
*Änderungen Version 1.15*
∙ Liberty ist jetzt /noch/ rücksichtsvoller Schweineprogrammen
gegenüber und billigt ihnen mehr SV-Stack zu. (Das kostet 5k
mehr... :-()
Dadurch läuft jetzt Liberty mit dem VT52 Emulator in der Version
1.3 zusammen was einem Benutzer ;-) besonders wichtig war...
∙ Das 'free' der Speicherverwaltung von Liberty erlaubte nicht das
Freigeben eines NULL-Pointers, was aber offiziell dokumentiert
ist.
*Änderungen Version 1.1*
∙ Liberty benutzt jetzt ein anderes Verfahren um schweinische AES-
Calls zu 'reparieren'. Damit sollten (hoffentlich) die Probleme
die im Zusammenhang mit 'Calamus96' auftreten der Vergangenheit
angehören. Ich möchte ausdrücklich betonen, da₧ die Probleme von
'Calamus96'-Modulen ausgehen und Liberty jetzt nur /noch/
rücksichtsvoller mit unsauberen Programmen umgeht.
Gleiches gilt auch für 'OverPaint' (getestet mit der Demo-Version
1.5s).
Ich weise in diesem Zusammenhang darauf hin, da₧ das neue
Verfahren mehr Zeit benötigt und es dadurch zu (merklichen)
Performance-Verlusten bei unsauberen Programmen kommen kann!
(...aber lieber ein langsam ablaufendes Schweineprogramm als ein
abstürzendes... - oder?)
Nochmals meine Bitte an alle Programmierer: Achtet bei AES-
Aufrufen darauf, da₧ ihr einen *korrekten/initialiserten* und
*vollständigen* AES-Parameterblock verwendet!!!
∙ Es liegt ein Patchfile für MacSnd dabei. Das entsprechende
Kapitel beachten!
∙ Die ersten Beschreibungen von Liberty für Programmierer in die
Doku integriert.
...to be continued
8 Kontaktadresse
*****************
Falls Sie irgendwelche Fragen, Probleme oder Wünsche bezüglich Liberty
haben sollten, können Sie mich unter folgender Adresse erreichen:
Christian Krüger
Sophienstr. 10a
12203 Berlin
Internet email: chris@pace.de
*Wichtig:* Wer Kontakt via Sackpost zu mir aufnehmen will, der sollte
(wenn er eine Antwort erwartet) einen an sich adressierten und
ausreichend frankierten Rückumschlag beifügen!
Von privaten Besuchen bitte ich abzusehen, die Erfolgschancen mich
anzutreffen sind ohnehin ziemlich gering.
Au₧erdem bitte ich alle Anwender der Library nur dann zu mir Kontakt
aufzunehmen, wenn unlösbare Probleme oder gravierende Mängel bei der
Installation der Library auftreten! (Ich verstehe darunter das man
sich mindestens 2x die Liberty- Dokumentation durchgelesen hat und
immernoch nicht schlauer ist!!!)
Zeit die ich mit der Beantwortung von Fragen verbringe steht mir nicht
mehr zum Programmieren zur Verfügung... (Ein gutes und hilfreiches
Forum um solche Fragen evt. zu klären stellt die "Hotline der Share-/
Freeware", das Maus-Netz, Gruppe 'atari.soft' dar. Wären hier nicht
viele hilfsbereite und kompetente Menschen zugegen, die bei Fragen zu
Programmen durch ihre Beantwortung für die Programmautoren
einspringen, wer wei₧ ob Liberty hätte jemals entstehen können... Ich
widme daher diese Library allen Atari-Enthusiasten im Maus-Netz -
*Danke!* :-) )
/Rächtzszeibunsfälör by Zeitmangel und Portfolio-Tastatur!/