Die Gerüchte stimmen! Es ist wirklich möglich die Taktfrequenz der CPU und des Blitters einzeln abzuändern. Man kann dabei zwischen den Frequenzen 8 und 16 MHz wählen. Leider ist das entsprechende Register von ATARI nicht dokumentiert worden, weshalb man nicht davon ausgehen kann, daß es in kommenden Modellen der Falcon-Reihe noch vorhanden ist. Eine hübsche Möglichkeit für eigene Experimente bietet es allemal, denn man kann den Falcon somit fast in einen alten STE verwandeln, der auch nur mit 8 MHz betrieben wurde. Einige zeitkritische Routinen könnten nun auf dem Falcon wieder laufen, wie z.B. Disketten-Kopierschutzverfahren u.ä.. In dem gleichen Register existiert auch noch ein Flag welches den Falcon STE-kompatibel machen soll. Dies entspricht einem Umschalten in den Kompatibilitäts-Modus per Desktop aber ohne die Auflösung direkt mitzuändern.
Die angegeben Programme demonstrieren dieses Umschalten, indem sie bei jedem Aufruf den jeweiligen Zustand invertieren.
Natalie Lübcke
* Programm 1: Schaltet die CPU-Frequenz um (8 MHz <-> 16 MHz)
pea cpu8_16(pc) ;Mini-Programm aufrufen
move.w #38,-(sp) ;im Supervisor-Modus
trap #14
addq.l #6,sp
clr.w -(sp) ;und quit
trap #1
cpu8_16:
bchg #0,$ffff8007.w ;toggle Bit 0
rts
* Programm 2: Schaltet die Blitterfrequenz um (8 MHz <-> 16 MHz)
pea blit8_16(pc) ;Mini-Programm aufrufen
move.w #38,-(sp) ; im Supervisor-Modus
trap #14
addq.l #6,sp
clr.w -(sp) ;und quit
trap #1
blit8_16:
bchg #2,$ffff8007.w ;toggle Bit 2
rts
* Programm 3: Schaltet zwischen STE und Falcon030 Modus um
pea STE,F030(pc) ; Mini-Programm aufrufen
move.w #38,-(sp) ; im Supervisor-Modus
trap #14
addq.l #6,sp
clr.w -(sp) ;und quit
trap #1
STE_F030:
bchg #5,$ffff8007.w ;toggle Bit 5
rts
Im Gegensatz zum Falcon030 muß das Multitasking-AES inkl. Desktop bei den ST-, STE- und TT-Rechnern nachgeladen werden, und zwar in Form der Datei „GEM.SYS“. Diese Datei enthält einen Fehler, der beim Einsatz einer MC68010-statt einer MC68000-CPU zum Absturz führt; möglicherweise handelt es sich hierbei um denselben Fehler, der bereits am TOS 2.06 festgestellt worden ist. Der Fehler besteht darin, daß die Systemvariable Jong-frame als Flag für die Abfrage, ob ein MC68030 (mind. MC68020) installiert ist, benutzt wird, was aber nicht richtig ist, da bereits ein MC68010 das erweiterte Stack-Format benutzt. Durch diese falsche CPU-Abfrage wird beim MC-68010 ein Programmteil nicht übersprungen, der das Cache-Control-Register anspricht, das jedoch beim MC68010 noch nicht vorhanden ist, was zum Absturz führt. Der folgende Patch ermöglicht den Besitzern des KAOS-TOS, die bisher den MC68010 uneingeschränkt benutzen konnten, Multi-AES auf ihrem Rechner zu installieren, ohne wieder auf den MC68000 absteigen zu müssen. Dies ist dadurch möglich, daß KAOS-TOS den Prozessortyp in die Variable _longframe schreibt. Wer KAOS-TOS nicht hat, konnte ohnehin bisher keinen MC68010 einsetzen. Daher möchte ich hiermit an ATARI appellieren, den Fehler zu beseitigen, damit alle Besitzer eines ST oder STE in den Genuß eines MC68010 kommen können.
Nun zum Patch für KAOS-TOS-Besitzer (die Befehlsfolge hinter dem Semikolon ist der Hexdump):
tst.w $59e : 4a78 059e
beq.w Adresse ; 6700 002c
muß ersetzt werden durch:
cmp.w #20,$59e ; 0c78 0014 059e
bcs.b Adresse ; 652a
Sie befindet sich bei meinem „GEM.SYS“ (Dateilänge 273903) an der Adresse $6e3a ab Dateianfang. Sollten Sie schon eine neuere Version von „GEM.SYS“ haben, müssen Sie nach der als Hexdump angegebenen Byte-Folge (bis evtl, auf das letzte Byte) suchen lassen, um die Adresse herauszufinden. Anzumerken wäre noch, daß die gepatchte Datei weiterhin auf allen Rechnern mit MC68000 bzw. MC68030 uneingeschränkt lauffähig ist, da ein „normales“ ATARI-TOS _longframe auf 0 bzw. 255 setzt.
Christian Fuchs
CrazySounds hat unter Umständen mit Mag!X-Versionen kleiner 2.0 Probleme: Beim Arbeiten mit CRAZYSND.ACC kann es zur Fehlermeldung „Unbekannter AES-Aufruf“ kommen. Dem Problem kann abgeholfen werden:
Das AES von Mag!X gibt sich als Version 3.9 aus, unterstützt allerdings nicht alle Funktionen der offiziellen AES-Versionen größer V3.31 —> Fehlermeldung. Um CrazySounds von der Verwendung solcher Neuheiten abzuhalten, müssen wir die AES-Versionsabfrage in CRAZYSND.ACC ändern.
Mit dieser kleinen Änderung läuft CRAZYSND.ACC ab sofort auch unter Mag!X V1.11. Allerdings sollte dieser Patch nur eine Notlösung für Mag!X-User sein, da er auf dem Falcon030 u.U. zu kleineren Darstellungsfehlern führen kann.
Richard Kurz
Um die BOOT-Partition (im Beispiel Laufwerk C:) auch für DOS nutzen zu können, geht man wie folgt vor: Im ATonce-Install-Programm wird die TOS-Kompatibilität für C: abgeschaltet. Dadurch wird die Partition-Allocation-Table des DOS nicht mehr virtuell, sondern real verwaltet. Sie liegt dann auf dem log. Sektor 1 von C:. Jetzt wird unter DOS mit FDISK eine primäre DOS-Partition mit maximaler Größe eingerichtet. Diese wird unter DOS formatiert (FORMAT C:), ohne das DOS aufzuspielen. Leider muß die Partition-Allocation-Table z.B. mit den Norton-Utilities nachbearbeitet werden. Der erste Sektor der Partition sollte nämlich direkt hinter der Partition-Allocation-Table beginnen, um möglichst wenig Platz zu verschenken. Das heißt: Den Startsektor um 16 Sektoren vorziehen und die Partitionsgröße in der Tabelle entsprechend vergrößern. Dann muß auch der DOS-Boot-Sektor entsprechend nach vorne kopiert werden. Außerdem muß auf 16Bit-FAT-Einträge gestellt werden. Jetzt muß man zurück in den ATARI-Modus: Mit einem Diskmonitor stellt man im ATARI-Boot-Sektor von C: drei reservierte Sektoren ein (wg. DOS-Boot-Sektor und Partitionstabelle). Außerdem muß man die Anzahl der FAT Sektoren, der Root Directory-Sektoren etc. (nicht jedoch die Gesamtzahl der Sektoren!) im DOS-Boot-Sektor denen des ATARI-Boot-Sektors angleichen. Anschließend wird unter DOS nochmal formatiert und das System aufgebracht (FORMAT C: /S). Dann wird vom ATARI aus der ATARI-Plattentreiber aufgespielt und Laufwerk C bootfähig gemacht. Das war’s.
Der Aufbau der Partition sieht dann wie folgt aus:
Sect | Bedeutung unter TOS | Bedeutung unter DOS |
---|---|---|
0 | Boot-Sektor TOS (1. res. Sekt.) | ex. gar nicht (wäre Sekt.-1!) |
1 | erster reservierter Sektor | Partition Allocation Table |
2 | zweiter reservierter Sektor | Boot-Sektor DOS |
3 | erster FAT-Sektor | erster FAT-Sektor |
4 | zweiter FAT-Sektor | zweiter FAT-Sektor |
Bei BGM-Partitionen sieht’s ähnlich aus: Es soll z.B. Laufwerk D: eine BGM-Partition sein mit zwei physikalischen pro einem logischen Sektor (d.h. Sektorgröße 1024 Bytes). Dann wird folgender Aufbau der Partition angestrebt: Sect = Phys. Sektor relativ zum Partitions-Beginn
Sect Bedeutung unter TOS | Bedeutung unter DOS |
---|---|
0 | Boot-Sektor TOS (1. res. Sekt.) |
1 | erster reservierter Sektor |
2 | zweiter reservierter Sektor |
3 | zweiter reservierter Sektor |
4 | erster FAT-Sektor |
5 | erster FAT-Sektor |
Allerdings muß immer beachtet werden, daß ein ATARI-Sektor bei einer BGM-Partition mehreren Sektoren unter DOS entspricht. Daher müssen unter DOS doppelt so viele FAT-Sektoren eingetragen werden wie im ATARI-Boot-Sektor vermerkt. Die Cluster-Größe unter DOS muß so gewählt werden, daß die Größe eines DOS-Clusters in Bytes der eines ATARI-Clusters in Bytes entspricht.
In diesem Beispiel:
ATARI: Sektorgröße 1024 Bytes, Cluster-Größe 2
-> 2048 Bytes/Cluster
DOS: Sektorgröße 512 Bytes, Cluster-Größe 4
-> 2048 Bytes/Cluster
Der DOS-Boot-Sektor muß unmittelbar vor dem ersten FAT-Sektor rangiert werden, da DOS (zumindest 3.3) scheinbar die Anzahl der reservierten Sektoren ignoriert (während TOS zumindest ab 1.4 diese akzeptiert).
Die grundlegende Idee ist also die: Es existieren zwei Boot-Sektoren für TOS und für DOS, außerdem eine Partition Allocation Table für DOS. Auf die Lage des ATARI-Boot-Sektors in der Partition hat man keinen Einfluß, wohl aber auf die des DOS-Boot-Sektors. Man reserviert jetzt also im ATARI-Boot-Sektor zwei (BGM) oder drei (GEM) Sektoren (inkl. ATARI-Boot-Sektor) und rangiert den DOS-Boot-Sektor in die letzen 512 Bytes des letzen reservierten ATARI-Sektors. Dann gleicht man die Daten der Boot-Sektoren so an, daß man gleiche FAT-Größen (in Bytes) bekommt sowie die gleiche Menge und Größe (in Bytes) an Daten-Clustern. Zu beachten ist außerdem, daß die Root-Directory-Größe so gewählt wird, daß jeweils ganze ATARI-Sektoren belegt werden (sonst könnte es z.B. passieren, daß auf dem ATARI 1024 Bytes reserviert werden (größere log. Sektoren), DOS aber nur einen Sektor zu 512 Bytes benötigt). Mehr steckt eigentlich nicht dahinter. Es fehlt nur noch jemand, der sowohl in DOS als auch in TOS fit ist und ein entsprechendes Installationsprogramm schreibt. Wenn man den Trick aber verstanden hat, geht’ s auch ohne Programm ganz gut.
Torsten Lang