Viele Monate hat es gedauert, denn Eric Smith mußte alle seine Arbeitskraft in verschiedene Jaguar-Spiele stecken. Doch nun liegt endlich eine neue offizielle" MiNT-Version vor. Um Verwechslungen vorzubeugen, hat sie nun die Versionsnummer 1.12 bekommen und darf wie versprochen - auch in fertig übersetzter Form weitergegeben werden. Eine genaue Übersicht über die einzelnen Archive können Sie Abbildung 1 entnehmen. Von besonderer Bedeutung ist, daß man MiNT nun auch kommerziellen Produkten beilegen darf. Damit ist einer der größten Hinderungsgründe für die Entwicklung von MiNT-Dateisystemen beseitigt. Wichtig ist auch, daß die aktuelle MiNT-Version recht gut mit MetaDOS zusammenarbeitet, so daß man die verschiedenen Treiber der CD ROM-Anbieter besser in ein MiNT-System einbinden kann.
Aber es gab auch noch Neuerungen im Funktionsumfang: schon immer hatten die MiNT-Dateisystemtreiber die Möglichkeit, beliebig" lange Disklabels zu behandeln. Diese Funktionen wurden bislang nur in der Emulation von "Fsfirst()/ Fsnext()" benutzt, die zu alledem auch noch Labels mit mehr als acht plus drei Buchstaben unmöglich machte.
Die neuen Aufrufe Dreadlabel()" und "Dwritelabel()" (siehe Abbildung 2) erlauben es nun, auch längere Labels zu benutzen und zu erfragen, sofern es das jeweilige Dateisystem unterstützt (ISO9660 auf CD-ROMs, Mac Dateisysteme usw.). Auch die nächste MetaDOS-Version (2.50) wird diese Aufrufe unterstützen, wenn der entsprechende DOS-Treiberste bereitstellt.
Auch Dpathconf()" wurde erweitert: neue Opcodes erlauben die Abfrage, welche Teile der XATTR-Struktur überhaupt sinnvolle Daten enthalten. So kann beispielsweise ein Desktop selbst erfragen, ob es überhaupt sinnvoll ist, für eine Datei etwa Unix-Zugriffsrechte anzuzeigen.
Zum Thema TOS-Programme auf anderen Hardware-Plattformen" gibt es ebenfalls ein paar neue Informationen: nach Absprache mit Eric Smith wurde festgelegt, wie die Cookies _MCH" und _VDO" zu setzen sind. Zusätzlich wurde der Cookie MNAM" definiert, über den man den Namen der Hardware erfragen kann. Im einzelnen:
Für den Cookie SND" mußte übrigens nichts Neues festgelegt werden, da er sowieso aus einer bitweisen Aufzählung besteht und daher auf fremden" Plattformen auf Null gesetzt werden kann. Diese neuen Definitionen dürften nicht nur für die MagiC-Portierung auf den Mac, sondern auch für andere Projekte (Janus, Eagle, Medusa) von großem Interesse sein.
Vor 8 Monaten sprach ich bereits schon mal vom ATAPI"-Standard, der den Anschluß von CD-ROMs und Streamern an den IDE-Bus möglich machen soll. Seit Juni ist nun Version 1.2 des Standards (ATA Packet Interface for CD-ROMs", SFF-8020) veröffentlicht. Zu den Urhebern gehören die meisten Großen der Branche: Sony, NEC, Mitsumi, Western Digital, Quantum usw. Die Version für Streamer soll später folgen. Was besagt dieser Standard, und inwiefern ist er für ATARI-Besitzer interessant? Nun, viele ATARIs (ST mit entsprechender Erweiterung, Falcon, Medusa) haben nunmal eine IDE-Schnittstelle, und es ist nicht einzusehen, warum man sie nur für Festplatten benutzen sollte. Beim ATA-Protokoll (AT Bus Attachment") werden Kommandos und ihre Parameter in spezielle Hardware-Register geschrieben. Das Packet Interface hingegen benutzt zwar noch diealten" Register, packt aber Kommandonummern und Parameter in ein 12 oder 16 Bytes langes Kommandopaket. Manchem mag dies vom SCSI-Protokoll her vertraut vorkommen, und auch indem zuständigen Ausschuß des Small Factorm Form Committee" hat man das offenbar gemerkt. Und so entsprechen die benutzten Kommandopakete - von ein paar Erweiterungen und prinzipbedingten Abweichungen abgesehen genau denen des SCSI-Protokolls. Damit müssen vorhandene SCSI-CD-ROM-Treiber vermutlich nur an einer Stelle erweitert werden.
Da praktisch jeder heute verkaufte PC über eine IDE-Schnittstelle verfügt, darf man davon ausgehen, daß ATAPI CD-ROMs in großen Stückzahlen über den Ladentisch gehen werden. Das wird sich beiden Preisen bemerkbar machen und im Zweifelsfall auch die Preise von SCSIGeräten positiv beeinflussen.
Bleibt vielleicht noch die Frage: was ist eigentlich der Unterschied zwischen "ATA" (AT Bus Attachment) und IDE" (Integrated Drive Electronics)? Nun, ATA" ist die korrekte Bezeichnung, "IDE" hingegen die, die fast jeder benutzt.
Dreadlabel() und Dwritelabel()
/* #defines für PureC */
#define Dreadlabel(a,b,c) gemdos(0x152,(char *)a,(char*)b,(int)c)
#define Dwritelabel(a,b) gemdos(0x153,(char *)a, (char *)b)
long Dreadlabel (const char *path, char *label, int len);
long Dwritelabel (const char *path, const char *label);
Dreadlabel()" liefert inlabet"den Namen des auf path" liegenden Dateisystems zurück. Mit len" gibt man an, wie viele Zeichen in label" passen. Wenn der Name länger ist, liefert das Betriebssystem den Fehler ENAMETOOLONG (1001) zurück. "Dwritelabel()" schreibt den in label" angegebenen Namen auf das durch "path" ausgewählte Dateisystem.
MiNT 1.12, von ATARI "für alle" freigegebene Version
mint112b.zoo(91828 Bytes) - Binaries und Copyright-Bestimmungen
mint112d.zoo(104546 Bytes)- Dokumentation
mint112s.zoo (363187 Bytes)- Quelltexte
MiNT-Libraries (Patchlevel 44, mit viel interessantem Beispielcode):
mntinc44.zoo (117845 Bytes)- Headerfiles
mntlib44.zoo (463858 Bytes)- die C-Quelltexte
(zum Übersetzen wird GCC oder PureC sowie wg. langer Dateinamen das Minix-Dateisystem unter MiNT benötigt)
mntolb44.zoo (313542 Bytes) - fertig übersetzte Bibliotheken für GCC
Diese Dateien sollten in jeder besser sortierten Mailbox zu finden sein (zum Beispiel: Maus MS2, 0251 f77262). Leser mit Internet-Zugang können die Dateien u.a.auch auf den ftp-Servern atari.archive.umich.edu" und ftp.uni muenster.de" Im Verzeichnis atari/Mint/Kernel" bzw. atari/Mint/lib" finden. Selbstverständlich kann es sein, daß bis zum Erscheinungstermin eine neue MiNT-Version oderneue Libraries (Patchlevel>= 45) vefügbar sind.