ABBUC Magazin 030

Vorwort

Liebe Bit Byter!

Schon wieder ein kleines Jubiläum: Das 30. ABBUC-Magazin! Ich möchte mich bei allen bedanken, die durch ihre Mitarbeit dazu beigetragen haben, die Magazine zu realisieren.
Bitte beachtet bei Euren Anfragen, daß die Clubzentrale wegen meines Urlaubs vom 24. August bis zum 28. September geschlossen ist.
Ihr solltet, falls es nicht schon geschehen ist, in Eurem Terminkalender den 24. Oktober vormerken. Da erwarten wir Euch zur diesjährigen Jahreshauptversammlung. Eine Einladung mit Anfahrtplan geht Euch mit gesonderter Post rechtzeitig zu.
Ich wünsche viel Spaß mit den Programmen und beim Lesen.

Euer Wolfgang

Auflösung Preisrätsel Sondermagazin 11

Hier die Auflösung des Preisrätsels aus Sondermagazin # 11. Die Namen der Gewinner findet ihr auf der Diskette unter „Infos aus dem Club“

Hacker: Mißgeschick Firma: Uhrzeit:
D.J.Disk Buffer Barmer Bros. 12.30 Uhr
Speedman falsche Nr. HATARI 10.30 Uhr
Multitasker Systemcrash EiWieGem 13.30 Uhr
Cruncher Logon falsch O.C.B. 09.30 Uhr
Crack-Joe Mittagessen Brotkiste 11.30 Uhr

 

Mitgliedsbeitrag

Hallo Bit-Byter!

Sicherlich könnte Ihr es schon nicht mehr hören, wenn ich Euch an die Mitgliedsbeiträge erinnere. Aber diesmal möchte ich Euch ein dickes Lob aussprechen. In Magazin 24 bat ich Euch zum erstenmal längerfristige Daueraufträge einzurichten, um die Kontokosten und die Buchungsarbeit zu minimieren. Nun ist ein Jahr verstrichen und wir haben gemeinsam erreicht, die Kontogebühren durch die Zinsen der festen Rücklage zu decken – das ist mehr als wir uns vorgenommen hatten! Nochmals vielen Dank.

Für all die neuen Mitglieder hier nochmal zur Erinnerung:

Der Mitgliedsbeitrag beträgt auch im siebten e. V.-Jahr des ABBUC nur

je Monat. Bitte überweist den Betrag per 3-, 6- oder 12-monatigem Dauerauftrag auf unser

Konto 54 000 468
BLZ 426 501 50
Kreissparkasse Recklinghausen

 

The Disassembler v1.1

Programmiert von WosFilm (Schweden)
Distributed by TOP-Magazin, Halle/Saale
Getestet von Torsten Karwoth

Einigen Leuten dürfte der Name (?) WosFilm von einigen Demos bekannt sein. Wer nach dem Starten des kopiergeschützten Programmes aber einen Sinus-Scroller oder Rainbow-Color-Effekte erwartet, wird enttäuscht werden, denn jetzt präsentiert uns WosFilm mal ausnahmsweise keine Demo, sondern ein benutzerfreundliches Werkzeug.

The Disassemnbler kommt mit einer zweisprachigen (Deutsch/Englisch), ca. 18-seitigen DIN-A5 Anleitung und, natürlich, der (leider) kopiergeschützten Programmdiskette. Die Anleitung ist gut gegliedert; ich denke man kann auch ohne Anleitung das Programm sehr einfach bedienen, dank der hervorragenden Benutzeroberfläche!

Die Rückseite dieser Diskette ist unbespielt, und entsprechende Versuche eine SICHERHEITSKOPIE auf die Rückseite zu bringen scheiterten an dem Kopierschutz. Das Programm selber, welches mit DOS 2.5 ausgeliefert wird, kann aber von einem anderen DOS geladen werden (u. a. MyDOS). Sehr gefallen hat mir der Anhang in der Anleitung, in dem alle 6502 (nicht 65C02) Opcodes aufgeführt sind, die The Disassembler versteht.

Im übrigen ist The Disassembler nicht nur ein Disassembler, sondern ein „echter“ Sourcecodegenerator. Es besteht die Möglichkeit, aus einem Programm einen Sourcecode im ATMAS- oder MAC/65-Format zu erstellen. Diesen Sourcecode kann man mit dem jeweiligen Assembler einladen, editieren und neu compilieren! Allerdings darf man an die erzeugten Quelltexte keine allzu großen Anforderungen stellen, es gibt z. B. keine ASC-Zeilen, sondern „nur“ Opcodes und notfalls auch DFBs (bei illegalen Opcodes). Eine Datentabelle oder einen Textstring erkennt The Disassembler leider nicht. Einen sehr großen Pluspunkt bekommt The Disassembler allerdings für die Benutzeroberfläche:

Nach dem Programmstart sieht man einen leeren, umrahmten Bildschirm mit einer Menüzeile. Diese enthält die Menüpunkte INPUT, OUTPUT, SETUP, DISASSEMBLE und DOS. Mit den Cursortasten (ohne Control) kann man einen dieser Punkte auswählen, welcher dann invers dargestellt wird. Mit RETURN wird ein Menüpunkt aktiviert, sodaß ein Urtermenü erscheint. So kann unter INPUT gewählt werden ob man ein File disassemblieren möchte (dieses sollte allerdings einen Binärfile-Header haben, muß aber nicht) oder ob man lieber direkt aus Sekto
ren lesen möchte! Wählt man z. B. File so öffnet sich ein weiteres Fenster mit den Menüpunkten Filename, Analyze und Dir. Wählt man Filename, so muß der Name des zu disassemblierenden Files eingegeben werden. Wählt man Dir, so öffnet sich ein weiteres Fenster und man kann die Laufwerksbezeichnung eingeben. Vorgabe ist dabei D1:*.*. Bei Druck auf RETURN erscheint das Inhaltsverzeichnis der gewählten Diskette (muß ich noch erwähnen, daß dieses in einen eigenen Fenster geschieht?) und man kann ein File mit den Cursortasten auswählen. Der Menüpunkt Analyze zeigt schließlich alle Prcgrammsegmente, aus denen das File besteht (also Adressbereich und lnit/Autorun). Auch mehrteilige Files sind kein Problem.

Wenn man aus Sektoren disassemblieren möchte, kann z. B. der Startsektor gewählt werden, der Offset im Startsektor, die ORG-Adresse, die Anzahl der Sektoren und die Dichte (Single/Double). Ja, man kann sogar wählen, ob der gesamte Sektor disassembliert werden soll oder (falls er doch „Fileweise“ abgelegt wurde) es können die letzten drei Bytes übersprungen werden (File Number/Sector Link)!

Hinter OUTPUT kann die Ausgabe des erzeugten Sourcecodes gewählt werden. So kann festgelegt werden, ob das Sourcelisting auf dem Bildschirm, dem Drucker oder in ein File geschrieben werden soll. Auch die Kombination der drei Punkte ist möglich. Vorgabe für das Ausgabefile ist „D1:NONAME“.

Im Menüpunkt SETUP kann schließlich gewählt werden, ob man einen ATMAS oder MAC/65-Source erzeugen möchte, ob man einen Sourcecode mit oder ohne Label erzeugen möchte und ob alle oder nur die legalen Opcodes erzeugt werden sollen! Von den Labels darf man aber nicht allzuviel erwarten, es werden 3-stellige Label erzeugt, wobei der Bereich von „AA0“ bis „ZZ9“ vorgegeben ist. Das Startlabel läßt sich allerdings einstellen. Leider hat The Disassembler keine vordefinierten Label (wie PORTB ($D301)), es werden immer die hexadezimalen Werte erzeugt (also z. B. „STA $D301“). Dies ist aber kein schwerwiegender Nachteil. Insgesamt kann ich dieses Tool jedem empfehlen, der in die Programmierung des 6502 einsteigen möchte oder einfach nur mal in andere Programme reinschauen will.

Für den Preis von ca. 19,80 DM erhält man ein sehr gutes Tool.

Prädikat: Empfehlenswert!

C-Kurs (Teil 4)

1. C-Entwicklung und Standard

C-Programme bestehen aus einer Folge von (Funktions-)Unterprogrammen. Das Programm aus dem letzten C-Kurs war folgendermaßen aufgebaut:

  1. Compiler-Instruktionen: #include
  2. Deklaration von globalen Variablen: char x;
  3. Hauptprogramm: main() $(
  4. Anweisungen: graphics(), while()…
  5. Funktionsname: func1() $(
  6. Deklaration von lokal. Variab.: int a,b,op; char c;
  7. Anweisungen: print(), switch()…
  8. Aufruf von Hauptfunktion: main()
  9. Funktionsname: func3() $(
  10. Anweisungen: putchar(‚\f‘)
  11. Programmende: exit()

Das extern erstellte Funktionsprogramm func2():

  1. Deklaration von globalen Variablen: int a,b,c,d,e,f;
  2. Funktionsname: func2() $(
  3. Anweisungen: poke(), for()…
  4. Aufruf von Hauptfunktion: main()

Die Grundstruktur dient als Orientierungshilfe, und sollte beim Entwurf Eurer Programme schriftlich festgehalten werden. Dazu könnt Ihr die jeweilige Aufgabe der Funktionen hinzufügen.

Der normale Aufbau eines Funktionskopfes, also func1() $( kann durch Parameter (Namen von Variablen) erweitert werden:

Funktionsname(Parameter)Type Name; Anweisungsblockanfang: $(
1200 func1 (a,b) int a,b; $(
1210 …

Sinn dieser Angabe von Parametern ist, globale Variablen zu vermeiden. Die „Gefahr“ bei der Anwendung globaler Variablen besteht darin, daß diese unbeabsichtigt von anderen Funktionen verändert werden können. Um Parameter innerhalb der Funktion wie Variablen zu nutzen, muß der Parameter deklariert werden, und zwar vor dem Anweisungsblockanfang.

Aufgabe dieser Parameter ist es, Wert von anderen Funktionsprogrammen zu übernehmen oder dort zu verändern. Seht Euch dazu das Beispielprogramm „PARAMETER“ an!

Die bei einem Funktionsnamen angegebenen Parameter werden in der „Fachsprache???“ als formale Parameter bezeichnet. Ihre „Sichtbarkeit“ beschränkt sich (wie bei den lokalen Variablen) auf den Anweisungsblock (Funktionsrumpf). Die von anderen Funktionsprogrammen übergebenen Werte werden als aktuelle Parameter bezeichnet. Für die beiden Parametertypen könnt ihr also gleiche Namen verwenden, nur der Typ (char, int) muß übereinstimmen.

Bei der Parameterübergabe gibt es verschiedene Konzepte. Hie die zwei geläufigsten:

  • CALL BY VALUE: Wertparameter…
  • CALL BY REFERENCE: Referenzparameter…

Referenz bedeutet hier Bezugnahme auf die Adresse des aktuellen Parameters.

In C-Programmen funktioniert die Parameterübergabe nach dem Prinzip CALL BY VALUE. Dies bedeutet, daß beim Aufruf einer Funktion (mit Parameter) die aktuellen Parameter in lokale Variablen der Funktion kopiert werden. Diese lokalen Variablen sind dann innerhalb der Funktion über die Namen der formalen Parameter zugreifbar:

    func1(a): formaler Parameter a
    int a;: lokale Varialbe a $(

Bei dem CALL BY VALUE funktioniert die Parameterübergabe nur in eine Richtung! Wird innerhalb der Funktion die Größe der übergebenen Parameter verändert, hat dies keinen Einfluß auf die aktuellen Parameter außerhalb der Funktion!

Erst seit der objektorientierten Nachfolgesprache C++ ist es möglich, das Prinzip CALL BY REFERENCE anzuwenden. Alle Änderungen, die innerhalb der Funktion an dem formalen Parameter vorgenommen werden, wirken sich auch auf den aktuellen Parameter aus. Es gibt „wie immer“ Ausnahmefälle, z. B. die Arrays (Ferder:intx[10]) in dem „normalen C“. Siehe Programmbeispiel „CALL BY ARRAY“.

Übrigens, wozu das ganze hier gut sein soll, merkt Ihr spätestens, wenn Euer fertiges Programm (z. B. Mathematik) andauernd verkehrte Werte ausgibt.

 

2. Compiler (Allgemeiner Aufbau und Funktion)

Die syntaktische Analyse orientiert sich an der „C-Grammatik“ und dem Index der Grammatik. Die Grammatik besteht aus einer Liste von Regeln. Jede Regel besitzt eine Kennnummer und kann für vorbestimmte Zwecke eingesetzt werden:

Kennnummer        Regel
06 Bezeichner := Buchstabe
10 Buchstabe := ‚a‘

    Buchstabe := ‚z‘

 

 

Da von der Grammatik mehrere Regeln bei einer Programmzeile eingesetzt werden können, wird ein Index benutzt.

Schlüsselnr. Grammatik-Regel/Kennnr./…
30        Buchstabe    10/06/08/…

Die Schlüsselnummer wird auf den Stack der CPU geschrieben, eine Art Merkfach. Hier vergleicht der „Parser“ (Programm zur syntaktischen Analyse) die Regeln mit dem Quelltext und verzweigt dementsprechend. Dadurch entsteht der Ableitungsbaum (sihe C-Kurs 3).

Der Stack ist Bestandteil des RAM-Speichers, in dem Werte und Adressen in einer ganz bestimmten Art für den späteren Begrauch abgelegt werden. Das Prinzip für die Ablage heisst „LIFO“.

LIFO: Last In, First Out.

Das zuletzt abgelegte Byte wird bei Aufruf des Stacks auch wieder als erstes verarbeitet.

In unserem Programmbeispiel wird eine Assemblerroutine aufgerufen. Nach Beendigung des
Unterprogramms soll das Hauptprogramm wieder hiter dem Aufruf fortgesetzt werden. Dazu muß vorher die aktuelle Programmadresse (Programmzeile) bekannt sein. Diese Adresse wird als letztes vor dem Unterprogrammbeginn „auf den Stack oder Stapel gelegt“. Wird das Unterprogramm beendet, holt sich die CPU den zuletzt gespeicherten Wert vom Stack und „arbeitet“ damit weiter. Das war hier natürlich eine sehr grobe und einfache Beschreibung. Es soll lediglich das Grundprinzip des Stacks zeigen.

3. C-Programmierung mit DVC

In den beiden folgenden Programmbeispielen sehr Ihr den Ablauf einer einfachen Parameterübergabe. Das erste Beispiel zeigt das Konzept CALL BY VALUE. Hier werden nur Werte übernommen.

Das zweite Beispiel zeigt das Konzept CALL BY REFERENCE. Hier werden nur die jeweiligen Zeiger auf die aktuellen Parameter übernommen.

Ein Zeiger ist eine Variable, die auf einen Speicherplatz (auf eine andere Variable) „zeigt“. Bei der Deklaration von Feldern (Arrays) werden Zeiger vergeben, z. B.:

Typ -> int a[3]
           /    \
     Zeiger  Elementanzahl

Der Zeiger verweist auf den Anfang des Feldes. Der Inhalt von Variable a ist z. B. A000. Dort beginnt das Feld mit a[0] je nach Typ (int, char) sind dann jeweils zwei oder mehrere Bytes für die Elemente reserviert. Ab A002 folgt dann a[1], ab A004 dann a[2], usw.

Dieses Thema wird uns in den folgenden C-Kursen noch sehr häufig begegnen.

Funktions(Befehls)-Liste:

a. int b. printf()
c. putchar() d. for()

 

1000 /* Programm Nr. 4  PARAMETER */  
1010  
1020 func1(wert) int wert; Funktionsname mit Spezifikation des formalen Paramet.
  Deklaration des formalen Parameters. Jetzt kann der Parameter innerhalb der Funktion ‚func1‘ wie eine lokale Variable verwendet werden.

1030 1040 $(Anweisungsblockanfang1050 1060 printf(„\n\ Wertübernahme: x,y,x+y,wert:%d\n“,wert); 1070 1080 wert++;wert = wert + 11090 1100 $)Anweisungsblockende1110 1120 main() $(Hauptanweisungsblock1130 1140 int x,y,wert;Deklaration der lokalen Variablen1150 1160 x=5;y=10;wert=8Wertzuweisung1170 1180 putchar(‚\f‘); 1190 1200 printf(„\n\ Parameterübergabe: CALL BY VALUE\n“); 1210 1220 func1(x);Aufruf der Funtkion ‚func1‘ mit Übergabe des aktuellen Parameters1230 1240 func1(y); 1250 1260 func1(x+y);Es sind auch Ausdrücke (an Regeln gebundene Verbindungen von Var., Konst. und Funktionsaufrufen mittels arith., log. und relationaler Operatoren (==)) erlaubt, außer ++,-.1270 1280 func1(wert);Da aktuelle Parameter in keinem Zusammenhang mit den formalen Paramtern stehen, kann derselbe Name verwendet werden.1290 1300 printf(„\n\ Parameter:x,y,x+y,wert: %d %d %d %d\n“,x,y,(x+y),wert); 1310 1320 $)Hauptanweisungsblockende

Programmende


 

1000 /* Programm Nr. 5 CALL BY ARRAY */  
1010  
1020 func1(zeig) Funktionsname mit Spezifikation des formalen Paramet. int zeig();
Deklaration des formalen Parameters. Die Feld (Array)-Größe wird hier erst durch (i) in der for-Schleife bestimmt
1030 $( Anweisungsblockanfang
1040  
1050 Int i; Deklaration (lokal)
1060  
1070 for (i=i;i<3,i++) zeig(i)++; Bei jedem Durchgang der Schleife wird der Inhalt der Speicherzellen ab der Adresse, auf den der Zeiger ‚zeig‘ verweist, um 1 erhöht. zeig verweist auf das 1. Element des Feldes zeig(0)=Feldbeginn z. B. A000
1. Element wird um 1 erhöht.
1080  
1090 $) Anweisungsblockende
1100  
1110 main() $( Hauptanweisungsblock
1120  
1130 int x(3); Deklaration
1140  
1150 x(0)=5;x(1)=10;x(2)=8; In C beginnt der Index bei 0 und muß um 1 kleiner bleiben, als die vereinbarte Anzahl der Elemente (3).
1160  
1170 putchar(‚\f‘);  
1180  
1190 printf(„\n\ Parameterübergabe: CALL BY REFERENCE\n“);  
1200  
1210 printf(„\n\ 1.Array-Werte: x(0),x(1),x(2): %d %d %d\n“,x(0),x(1),x(2));  
1220  
1230 func1(x); Aufruf der Funktion
1240  
1250 printf(„\n\ 2. Array-Werte: x(0),x(1),x(2): %d %d %d\n“,x(0),x(1),x(2));  
1260  
1270 $) Hauptanweisungsblockende

Programmende

Um eine Player-Missile-Grafik in C zu schreiben, sollte man sich ein wenig mit binären und hexadezimalen Zahlen beschäftigen. Die einfache Darstellung eines ‚Sprites‘ erfordert einiges an Hardware-Kenntnissen. Mit dem folgenden Programmbeispiel wollen wir versuchen, einen nanh allen Seiten beweglichen ‚Sprite‘ zu programmieren. Für die Vertikalbewegung habe ich zwei Assemblerroutinen eingefügt. Zwar ist eine in C geschriebene Routine wesentlich schneller als in BASIC, aber dennoch zu ‚träge‘.

Die Assemblerroutinen werden im Abschnitt ‚ASSEMBLER-PROGRAMMIERUNG MIT ATMAS II‘ erklärt.

Wichtige Hardware-Adressen:

  dez. (hex.) Inhalt: Wert:
1.) 106 (0x6A) Anzahl der RAM-Pages.
Eine RAM-Page: 256 Bytes
z. B. 192 = 48 KByte
2.) 54279 (0xD407) Obergrenze des verfügbaren RAM-Speichers z. B. 160 = 40 KByte
3.) 559 (0x22F) Kontrollmodus für den direkten Speicherzugriff des Grafikbausteins (ANTIC): Bildschirmgröße, Auflösung, DMA Standard: 34
sonst über 60
4.) 53256 (0xD008) Größe des Players Nr. 1; einfache, doppelte oder vierfache Größe 0; 1; 2; 3 = 0 und 2 identisch
5.) 53248 (0xD000) Horizontal-Register für Player Nr. 1 Player sichtbar zwischen dez. 44 (0x2C) und 220 (0xDC)
6.) 704 (0x2C0) Farbe von Player Nr. 1
Farbe * Helligkeit = 2 * 14
0 – 255
7.) 53277 (0xD01D) Grafikkontroll-Register Schaltet Player und Geschosse ein Player-Grafik aus/an: 0/3
8.) 623 (0x278) Stellung des Joystick Port 1 dez.:

14

10          6

links 11 — 15 — 7  rechts

9          5

13

 

So, und nun noch ein paar wichtige Adressen zum Programm:

1.) c=0xA46A (dez. 42090) Position des Players auf dem Bildschirm
Die Adresse errechnet man so:
Obergrenze des RAM-Speicher = RAMTOP
Standard-Wert von RAMTOP = 192
Speicherbereich reservieren:
RAMTOP=PEEK(106)-16 (16 RAM-Pages): 176
Speicherbereich für Grafikstufe 7:
RAMTOP=RAMTOP-16 (16 RAM-Pages)
RAMTOP-Inhalt jetzt: 160 dez.
Bildschirmanfang: RAMTOP * 256 = 40960
Speicherbereich für Player Nr. 1:POS1024 bis 1279
Position: (RAMTOP * 256) + POS
Position: (160 * 256) + 1024 bis 1279
Programmbeispiel:
40960 + 1130 = hex. A46A
2.) xpos = 110 (0x6E) Wert für horizontale Position des Players Wertbereich: 44 bis 220
3.) vp = 1536 (0x600) Startadresse der ersten Assemblerroutine  
4.) ap = 1600 (0x640) Startadresse der zweiten Assemblerroutine  

Der Aufruf der jeweiligen Routine geschieht hier über eine Funktion z. B. func6() asm 0x640. Der Befehl asm ist gleich dem USR aus dem BASIC.

 

Funktions(Befehls)-Liste:

a. int b. for()
c. poke() d. graphics()
e. return f. while()
g. if() h. peek()

 

1000 /* Player-Missile-Grafik */
 
1010  
1020 int b,a(17),g(29),h(32);  
1030 int c,xpos,ap,vp; Deklaration globaler Variablen
1040   
1050 main () $(  
1060  
1070 c=0xA46A; xpos=110;  
1080  
1090 vp=1536; ap=1600; Startadressen
1100  
1110 g(0)=162; g(1)=17; g(2)=189; g(3)=106; g(4)=164; g(5)=157;  
1120  
1130 g(6)=107; g(7)=164; g(8)=202; g(9)=16; g(10)=247; g(11)=238;  
1140  
1150 g(12)=3; g(13)=6; g(14)=238; g(15)=6; g(16)=6; g(17)=173;  
1160  
1170 g(18)=6; g(19)=6; g(20)=141;  
1180 g(21)=69; g(22)=6; g(23)=173;  
1190  
1200 g(24)=3; g(25)=6; g(26)=141; g(27)=72; g(28)=6; g(29)=96; Ins dezimale Zahlensystem übersetzte Mnemocodes und Werte der Assemblerroutine
z. B. g(0)=162:LDX g(1)=17 dez. Wert: 17…
1210  
1220 for(b=0;b<30;b++) $(  
1230  
1240 poke(vp+b,g(b)); Startadresse vp=1536 wird bei jedem Schleifendurchlauf um 1 erhöht. Der Wert g(b) wird in die jeweilige Speicherzelle kopiert.
1250  
1260 $)  
1270  
1280 h(0)=160; h(1)=17; h(2)=162; h(3)=0; h(4)=189; h(5)=106;  
1290  
1300 h(6)=164; h(7)=157; h(8)=105; h(9)=164; h(10)=232; h(11)=136;  
1310  
1320 h(12)=16; h(13)=246; h(14)=206; h(15)= 69; h(16)=6; h(17)=206;  
1330  
1340 h(18)=72; h(19)=6; h(20)=173; h(21)=72; h(22)=6; h(23)=141;  
1350  
1360 h(24)=3; h(25)=6; h(26)=173; h(27)=69; h(28)=6; h(29)=141;  
1370  
1380 h(30)=6; h(31)=6; h(32)=96; Assembler-Routine PLAY2ASM für die Aufwärtsbewegung
1390  
1400 for(b=0;b<33;b++) $(  
1410  
1420 poke(ap+b,h(b));  
1430  
1440 $( Schleifenende
1450  
1460 a(0)=0; a(1)=0; a(2)
=0; a(3)=24; a(4)=60; a(5)=60; a(6)= 126;
 
1470  
1480 a(7)=90; a(8)=255; a(9)=189; a(10)=90; a(11)=102; a(12)=60;  
1490  
1500 a(13)=60; a(14)=24; a(15)=0; a(16)=0; a(17)=0; Player-Daten: Wichtig sind dabei die drei Nullen am Anfang und am Ende des Datenfeldes. Man kann Sie sich als ‚Rand‘ der Player-Daten vorstellen.
1510  
1520 func1(); Funktionsaufruf
1530  
1540 poke(0xD407,160) Obergrenze des zur Verfügung stehenden RAM-Speichers. 160 RAM-Pages
1550  
1560 graphics(7) Grafikmodus 7
1570  
1580 poke(0x22F,63) DMA-Modus des Antic: Breites Spielfeld
1590  
1600 for(b=0;b<18;b++);  
1610  
1620 poke(c+b,a(b)); Die Player Daten werden in den Speicherbereich RAMTOP * 256 + POS geschrieben, also ab 0xA46A
1630  
1640 $) Scheifenende
1650   
1660 poke(0x2C0,2*14) Farbe Player 1
1670  
1680 poke (0xD000,xpos) Horizontalregister erhält Wert xpos
1690  
1700 poke(0xD01D,3) Player-Grafik wird eingeschaltet
1720  
1730 func2(); Funktionsaufruf
1740  
1750 $) Hauptanweisungsblockende von main()
1760  
1770 func1() $(  
1780  
1790 for(b=1024;b<2049;b++) $(  
1800  
1810 poke(40960+b,0); Das gesamte Playerdatenfeld wird gelöscht.
1820  
1830 $) Schleifenende
1840  
1850 return; Diese Funktion wird normalerweise zur Wertrückgabe eingesetzt, z. B. return(Wert). return kann aber auch ohne Wertangabe als ‚Sprunganweisung‘ verwendet werden. Die Funktion (hier func1()) wird beendet. Das Programm wird hinter dem Funktionsaufruf fortgesetzt.
1860  
1870 $) Anweisungsblockende von func1()
1880  
1890 func2() $(  
1900  
1910 while(1) $( Endlosschleife
1920 if(xpos>44 && peek(0x278)==11)xpos=1 Solange der Player sichtbar ist und die Joystickstellung nach links gerichtet ist, wird die Horizontalposition um 1 verringert. Effekt: Der Player bewegt sich
nach links.
1940  
1950 poke(0xD000,xpos);  
1960  
1970 if(xpos<204 && peek(0x278)==7) xpos+=1; Player bewegt sich nach rechts
1980  
1990 poke(0xD000,xpos);  
2000  
2010 if(c>0xA400 && peek(0x645)>7 && peek(278)==14) func6(); Player bewegt sich nach oben
0x645 enthält das LOW-Byte der Player-Position. Damit der Player im Bildfeld nicht über den Bildrand verschwindet, sollte das LOW-Byte nicht kleiner als 7 sein.
2020  
2030 if(c<0xA4F0 && peek(0x603)<231 && peek(0x278)==13) func5(); Player bewegt sich nach unten
2040  
2050 if(xpos>44 && peek)0x645)>7 && peek(0x278)==10) $( Player bewegt sich nach links oben
2060  
2070 func(); Funktionsaufruf
2080  
2090 xpos=1;  
2100  
2110 poke(0xD000,xpos);  
2120  
2130 $) if-Anweisungsende
2140  
2150 if(xpos>44 && peek(0x603)<231 && peek(0x278)==9) $( Player bewegt sich nach links unten
2160  
2170 func5();  
2180  
2190 xpos=1  
2200  
2210 poke(0xD000,xpos);  
2220  
2230 $) if-Anweisungsende
2240  
2250 if(xpos<204 && peek(0x645)>7 && peek(0x278)==6 $( Player bewegt sich nach rechts oben
2260  
2270 func6();  
2280  
2290 xpos+=1;  
2300  
2310 poke(0xD000,xpos);  
2320  
2330 $) if-Anweisungsende
2340  
2350 if(xpos<204 && peek(0x603)<231 && peek(0x278)==5 $( Player bewegt sich nach rechts unten
2360  
2370 func5();  
2380  
2390 xpos+=1  
2400  
2410 poke(0xD000,xpos);  
2420  
2430 $) if-Anweisungsende
2440  
2450 $) while-Schleifenende
2460  
2470 $) func2-Anweisungsblockende
2480  
2490 func5() asm 0x600; Die Funktion asm 0x bewirkt, daß ein Maschinenprogramm ab der angegebenen Adresse aufgerufen wird. Nach Ablauf des Unterprogramms (Maschinenprogramm) wird das Hauptprogramm in der nächsten Zeile hinter dem Funktionsaufruf fortgesetzt.
2500  
2510 func6() asm 0x640;  

Programmende

 

 

4. Einführung in die Maschinensprache

Der 800 XL arbeitet mit dem Mikroprozessor 6502 oder 65C02. Im Computerchinesisch CPU genannt (central processing unit; Zentraleinheit).

Die CPU ‚versteht‘ nur eine Sprache, nämlich Zahlenkombinationen von 0 – 255. Wie Ihr wißt, entstehen die Zahlen aus acht Bits, z. B.

128 64 32 16 8 4 2 1 = Stellenwert
0 0 0 0 1 1 1 1 = dez. 15, hex. A

Das Hexadezimalsystem:

dez. dual hex.
0 0000 0
. …. .
. …. .
9 1001 9
10 1010 A
11 1011 B
12 1100 C
13 1101 D
14 1110 E
15 1111 F

Es werden je 4 Bit umgewandelt, z. B.

1111 1111 1111 1111 = dez. 65535
F F F F = F * Stellenwert
* * * *  
4096 256 16 1 dez. Stellenwert

Das ist der Adressierraum (0 – 65535) des 6502.

61440 + 3840 + 240 + 15 = 65535

Die CPU kann anhand von sogenannten Registern (Accu, X, Y) den Inhalt jeder Adresse lesen oder verändern. Eure CPU hat selbst auch einen internen Speicher, in dem die CPU Daten festhalten kann, die Register:

1. Akkumulator (Accu)

Dieses Register ist bei jeder Operation beteiligt. Es ist direkt mit dem Rechenwerk (ALU = arithmetisch-logische Einheit) verbunden:
Das ist der Teil in der CPU, in der sämtliche arithmetischen Operationen: Add, Sub, Mul, Div und logische: AND, OR, NOT ausgeführt werden.

2. Mehrzweckregister X und Y

Diese beiden Register werden für die verschiedenen Adressierungsarten der CPU verwendet. und eignen sich gut als Zähler (z. B. FOR-Schleife in Assembler).

Die anderen Register werden in den folgenden C-Kursen erklärt.

Der Befehlssatz der CPU ist normalerweise in hex. Code vorhanden. Durch Einsatz eines Assemblers (engl. assemble = montieren) wird dieser Code durch ‚Mnemonics‘ (z. B. LDA = LoaD Accumulator) ersetzt.

Befehl Mnemonic-Code
hex. AD = LDA (absolute Adressierung)
hex. A9 = LDA (unmittelbare Adress.)
hex. A5 = LDA (Zero-Page, absolut)
hex. B5 = LDA (Zero-Page, X)
hex. BD = LDA (absolut, X)
hex. B9 = LDA (absolut, Y)
hex. A1 = LDA (indirekt, X)
hex. B1 =LDA (indirekt, Y)

Wie Ihr hier sehen könnt, kann jeder Befehl in einer ganz bestimmten Adressierungsart verwendet werden.

  1. Absolute Adressierung:
    LDA $XXXX = Inhalt von Speicherzelle XXXX (0 – FFFF) wird in den Accu kopiert.
  2. Unmittelbare Adressierung:
    1. LDA #$XX = hex. Wert XX (0 – FF) wird in den Accu geladen.
    2. LDA #XXX = dez. Wert XXX (0 – 255) wird in den Accu geladen.
  3. Zero-Page-Adressierung, absolute
    LDA $XX = Inhalt von Speicherzelle XX (0 – FF) wird in den Accu kopiert.
  4. Zero-Page-Adressierung, absolute, X
    LDA $01,X = z. B. X-Registerinhalt: 02
    LDA (01+X) = LDA 03 Inhalt von Sp. 03 nach Accu
  5. absolute, X
    LDA $1000,X = z. B. X-Registerinhalt: 02
    LDA ($1000+X) = LDA $1002 Inhalt von Sp. 1002 nach Accu
  6. absolute, Y
    LDA $1000,Y = z. B. Y-Registerinahlt: 03
    LDA ($1000+Y) = LDA $1003 Inhalt von Sp. 1003 nach Accu
  7. indirekte, X
    LDA ($5,X) = z. B. X-Registerinhalt: 03
    $5 + X-Reg. Inhalt: 03 = 08. Die Inhalte von Sp. 8 und Sp. 9 werden als Adresse gewertet.
    z. B.

    Sp. 08-Inhalt = 00 (LOW-BYTE)
    Sp. 09-Inhalt = C0 (HIGH-BYTE)
    Daraus ergibt sich die Adresse: C000. Der Inhalt von Sp. C000 wird in den Accu kopiert. Der max. Wertbereich: LDA ($0 – FF,X). Diese Adressierungart ist nur mit dem X-Register möglich!

  8. indirekte, Y
    LDA ($5),Y = z. B. Y-Registerinhalt: 03. Die Inhalte von Sp. 5 und Sp. 6 werden als Adresse gewertet.
    z. B.

    Sp. 05 = 00 (LOW-BYTE)
    Sp. 06 = C0 (HIGH-BYTE)
    Nun wird zu dieser Adresse der Inhalt des Y-Registers addiert: C000 + 03 = C003. Der Inhalt der Speicherzelle C003 wird in den Accu kopiert. Der max. Wertbereich: LDA ($0 – FF),Y. Diese Adressierungsart ist nur mit dem Y-Register möglich!

Allgemein gesagt werden die verschiedenen Adressierungsarten dazu benutzt, um das Programmieren zu erleichtern, auch wenn es hier noch nicht diesen Eindruck erweckt.

Der Befehlssatz der CPU besteht aus verschiedenen Gruppen von Mnemocodes. Die einfachste Gruppe ist die der Transfer-Befehle. Sinn dieser Befehle ist es, Daten von A nach B zu übertragen. Dies ist gleichzeitig ein Grundkonzept der Assembler-Programmierung, nämlich Daten (hex. Werte) im Adressraum zu verändern, um bestimmte Aktionen, z. B. Farbwechsel des Bildschirms zu erreichen. Hier einige Transfer-Befehle:

  • LDA = LoaD Accu
  • LDX = LoaD X-Register
  • LDY = LoaD Y-Register

Diese drei Befehle sind von der Funktion her alle gleich, sie unterscheiden sich lediglich in den Adressierungsarten.

  • STA = STore Accu
  • STX = STore X-Register
  • STY = STore Y-Register

Diese Befehle bewirken, daß der Inhalt der Register in jede Speicherzelle Eures 800 XL übertragen (kopiert) werden kann, z. B.
STA $1000 = übertrage Inhalt von Accu in die Speicherzelle $1000 = dez. 4096
STX $1000 = …

Auch hier gibt es verschiedene Adressierungsarten

hex. 85 = STA $XX Zero-Page, absolut
hex. 95 = STA $23,X Zero-Page, X
hex. 8D = STA $1000 absolute Adresse
hex. 9D = STA $1000,X absolut, X
hex. 99 = STA $1000,Y absolut, X
hex. 81 = STA ($10,X) indirekt, X
hex. 91 = STA ($10,Y) indirekt, Y

siehe oben LDA-Adressierungsarten!

 

Interne Transfer-Befehle:

Der Datentransfer geschieht hier nur innerhalb der CPU:

  • TAX = Transport Accu to X-Register
  • TAY = Transport Accu to Y-Register
  • TXA = Transport X-Register to Accu
  • TYA = Transport Y-Register to Accu

Durch diese Befehle können die Register untereinander Daten austauschen z. B.: Es soll eine Rechenoperation über den Accu durchgeführt werden. Ein Teil dieser Daten befindet sich in dem X- und Y-Register. Hierfür eignen sich die Transfer-Befehle (TXA und TYA).

TXA = übertrage den Inhalt vom X-REg. in den Accu.
TYA = …

Hier noch mal ein paar Worte zur Einführung. Maschinensprache ist kein ‚leichtverdauliches‘ Thema. Wenn Verständnisprobleme beim Lesen auftreten, keine Bange, mir ging es nicht anders. Was ich damit sagen will, man muß ’ne Menge Geduld und Ruhe mitbringen um sich mit diesem Thema auseinanderzusetzen. Ich habe absichtlich die Adressierungsarten aufgeführt; Ihr werdet mehrere in den Assembler-Routinen finden. Ihr sollt sie heraussuchen und mit den erwähnten Adressierungsarten vergleichen, das erleichtert Euch die Arbeit mit dieser Materie. Für die Assembler-Routinen benötigte ich 1 Woche Lesen und ‚Grübeln‘. fürs Schreiben 1 Tag. Das sollte Euch eher anregen als abschrecken, denn ich bin selbst ein Anfänger.

 

5. Assembler-Programmierung mit ATMAS II

Die Assemblerroutine PLAY1.ASM bewirkt, daß sich der Player1 (Sprite) nach unten bewegt. Um das zu bewerkstelligen, muß man die Playerdaten nach unten verschieben. Die 18 Playerdaten werden durch eine Schleife (ähnlich der for-Schleife) einzeln in andere Speicherzellen kopiert:

VAR1 EQU $A46A
  LDX#17 (Wert dez. 17)
LP1 LDA VAR1,X ($A46A,18 = LDA $A47C)
  STA VAR1+1,X (STA $A47D)
  DEX (X-Register-Inhalt minus 1)
  BPL LP1 (if X-REg.=-1 beende LP1)I

So kann die Schleife als Quelltext aussehen. Die Bedingung für die Schleife ist mit dem Mnemocode BPL LP1 festgelegt. Solange die Operation positive Werte ergibt, wird die Schleife durchlaufen.

Klartext: Wenn der Inhalt vom X-Register negativ ist, wird ein sogenanntes Flag gesetzt, nämlich das Negativ-Flag. Das Negativ-Flag ist Teil (ein Bit) des Statusregisters, worüber ihr Euch jetzt nicht den Kopf zerbrechen braucht. Es kann also nur zwei Werte annehmen: 0 (Flag nicht gesetzt) 1 (Flag gesetzt). In unserem Programm wird der Inhalt des X-Registers bei jedem Durchlauf um 1 vermindert. Wenn das X-Reg. den Wert -1 erreicht hat, wird das Neg.-Flag gesetzt, die Schleife beendet und das Programm wird hinter der Schleife fortgesetzt.

Wir haben hier mit der Schleife 18 Playerdaten (z. B. A47C nach A47D, A47B nach A47C, …) kopiert. 18 Daten deshalb, weil bei X-Reg.-Wert 0 die Schleife auch durchlaufen wird. Da aber der Player seine Position nach dem Aufruf dieser Routine verändert, muß die Assembler-Routine selbst ‚manipuliert‘ werden. Sie beginnt ja immer mit dem Wert VAR1 = $A46A, was mit der Position des Players nach einer Abwärtsbewegung nicht übereinstimmt!

Wie wir wissen, werden die Werte des Programms in ganz bestimmte Speicherzellen ‚geschrieben‘. Jetzt kann man vom Programm aus diese Werte verändern.

Die Startadresse ist OR $600. Ab dieser Adre
sse werden die einzelnen Befehle und Werte von PLAY1.ASM in den Speicher geschrieben.

Speicherzellen Editor des Assemblers
0600: A2 11   LDX#17
0602: BD 6A A4 LP1 LDA VAR1,X
0605: 9D 6B A4   STA VAR1+1,X
0608: …    

 

Uns interessiert hier nur der Inhalt der Speicherzelle $603 und $606. Es handelt sich dabei um das jeweilige LOW-Byte der Adresse $A46A:

$603: 6A $606: 68

Ändern wir diese Werte, so werden beim nächsten Aufruf der Routine die veränderten Werte benutzt, z. B.

INC $603
INC $606

Der Inhalt der Speicherzelle wird um 1 erhöht. Die Playerdaten sind ja nach einer Aufwärtsbewegung um eine Speicherzelle verschoben worden. Also muß beim nächsten Aufruf die neue Startposition der Playerdaten bekannt sein. Das erreichen wir mit dem Mnemo-Code INC:

Startadresse der Playerdaten: A46A
Schleife wird druchlaufen: 18 mal

Inhalt von $603 und $606 wird um 1 erhöht. Nach einem Programmdurchlauf sieht das im Speicher abgelegte Programm PLAY1.ASM so aus:

0600: AD 11   LDX#17
0602: BD 6B A4 LP1 LDA VAR1,X
0605: 9D 6C A4   STA VAR1+1,X
0608: …    

Neue Startadresse der Playerdaten (Player-Positon): A46B

Nehmen wir an, mehrere Aufwärtsbewegungen des Players sind erfolgt. Jetzt soll der Player aufwärts bewegt werden. Also muß der Aufwärtsroutine die letzte Position des Players bekannt sein. Die jeweils aktuelle Position muß der zweiten Assembler-Routine ‚übermittelt‘ werden. Das Prinzip ist das gleiche wie oben.

Wenn die Speicherzelle bekannt ist, die verändert werden soll, kann man sie entsprechend verwenden:

  1. LDA $606
  2. STA $645: Zieladresse der 2. Routine

 

  1. Lade den Inhalt von $606 in den Accu
  2. Kopiere den Inhalt des Accus in die Speicherzelle $645

Die zweite Routine beginnt ab $640. Die Startadresse der Playerdaten steht in $645 (LOW-Byte) und $648 (LOW-Byte).

0640 A0 11   LDY#17
0642 A2 00   LDX#0
0644 BD 6A A4 LP1 LDA VAR1,X
0647 9D 69 A4   STA VAR1-1,X

Wird jetzt die aktuelle Playerposition von PLAY1.ASM ($603 und $606) in die beiden Speicherzellen $645 und $648 kopiert, arbeitet PLAY2.ASM damit weiter. Die zweite Routine beginnt nun immer mit der aktuellen Startposition.

Nach dem Datenaustausch von PLAY1.ASM nach PLAY2.ASM kann das so aussehen:

0640 A0 11   LDY#17
0642 A2 00   LDX#0
0644 BD 6B A4 LP1 LDA VAR1,X
0647 9D 6A A4   STA VAR1-1,X
064A …    

Nun noch der Rücksprung zum Hauptprogramm (PLAYER-MISSILE-GRAFIK):

RTS

Das Unterprogramm wird beendet und das Hauptprogramm hinter dem Aufruf fortgesetzt.

 

Assemblerroutine Name: PLAY1.ASM

 

Editor-Quelltext:
Assembler: ATMAS II Programmhinweise
VAR 1   EQU $A46A Variablendeklaration
ORG $600 ORG: Startadresse Deines Programms.
ORG$… bei jedem Programm verwenden
LDX#17 Das X-Register erhält den dez. Wert 17
LP1 LDA VAR1,X Schleifenanfang mit dem Befehl:
Lade Inhalt der Speicherzelle VAR1 + X also A46A + dez. 17 = A47B
STA VAR1+1,X Kopiere den Inahlt vom Accu in die Speicherzelle VAR1 + 1,X; also A46A+1 + 17 = A47C
DEX Vermindert den Inhalt vom X-Register um 1
BPL LP1 Solange das Ergebnis positiv ist, also der Wert des X-Registers nicht kleiner Null ist, ’springe‘ zum Schleifenanfang LP1 zurück.
INC $603 Erhöhe den Inhalt der Speicherzelle $603 (dez. 1539) um 1.
INC $606
LDA $606
Laden den Inhalt von der Speicherzelle $606 in den Accu.
STA $645 Kopiere den Inhalt des Accu’s in die Speicherzelle $645
LDA $603
STA $648
RTS
Beende Unterprogramm (PLAY1.ASM) und kehre zum Hauptprogramm (PLAYER-MISSILE-GRAFIK) zurück.

Programmende

 

Assemblerroutine Name: PLAY2.ASM

 

Editor-Quelltext:
Assembler: ATMAS II

Programmhinweise

VAR1   EQU $A46A Variablendeklaration
ORG $640 Startadresse der Assemblerroutine
LDY#17 Y-Register erhält den dez. Wert 17
Wert für die Schleifendurchgänge
LDX#0 X-Register erhält den dez. Wert 0 für die Player-Position
LP1   LDA VAR1,X Lade den Inhalt von VAR1,X (A46A + 0) in den Accu
STA VAR1-1,X Kopiere den Inhalt des Accu’s in die Speicherzelle VAR1-1,X (A46A – 1 + 0; A469)
INX Erhöhe den Inhalt vom X-Register um 1
DEY Vermindere den Inhalt vom Y-Re. um 1
BPL LP1 Siehe PLAY1.ASM
DEC $645 Durch die Aufwärtsbewegung geschieht hier genau das Gegenteil von PLAY1. Vermindere den Inhalt von $645 um 1
DEC $648
LDA $ 648
Lade den Inhalt von $648 in den Accu
STA $603 Kopiere den Inhalt vom Accu in die Speicherzelle $603
LDA $645
STA $606
RTS
Beendet das Unterprogramm PLAY2.ASM und kehrt zum Hauptprogramm zurück

Programmende

 

Hinweise zur Programmierung:

Wenn Ihr den Quelltext abgeschrieben habt, macht Ihr folgendes:

<ESC>WD1:PLAY1.ASM<ESC><ESC>:SPEICHERN!
<CTRL-Y>: Aufruf vom Makroassembler
<beliebige Taste>
<CTRL-P>: Aufruf vom Maschinen-Monitor
<D>: Disassemble|Startadresse: 0600 hex.
<X-Taste>: MONITOR
<G 0600>: Programmstart
Jetzt noch mal disassemblieren und sich die veränderten Speicherzellen $603 und $606 ansehen.
<M>FROM:0640 TO:065: Speicherbereich anzeigen lassen, sich $645 u. $648 ansehen und mit $603 und $606 vergleichen.

Wenn Ihr den ATMAS-II-Editor auf dem Bildschirm habt, könnt Ihr sofort loslegen. Ihr braucht keine Zeilennummern eingeben.

Die Befehle (Mnemocodes) schreibt Ihr am besten etwas eingerückt (mit TAB). Verseht den Quelltext mit reichlich Kommentar, damit Ihr Euer Programm auch nach längerer Zeit noch entziffern könnt! Nach Eingabe des Quelltextes von PLAY1.ASM geht am besen wie oben beschrieben vor. Sieht umständlich aus, lohnt aber auf jeden Fall, wenn Ihr den Ablauf des Programms verstehen wollt. Dann löscht Ihr den Textbuffer des Editors: <ESC>K<ESC><ESC>.

Jetzt könnt ihr den zweiten Quelltext PLAY2.ASM eingeben. Danach macht ihr dasselbe wie bei PLAY1.ASM. Noch was, lest Euch die Beschreibung des ATMAS II intensiv durch, sie enthält wichtige Hinweise!

Samoht Esvark

 

Indexlocjhabfrage D-503

Letztes Jahr bestellte ich die Indexlochabfrage vom „EDV-COMPUTER_SHOP“ für die XF 551, um endlich meinen Diskettenbestand voll auszulasten, denn User der XF 551, die nicht über BIBO-DOS oder ein ähnliches Double Density beherrschendes DOS verfügen, werden mir bestimmt bestätigen, daß es sehr riskant ist, den Disketten ein zweites Indexloch zu verpassen, ohne deren Lebensdauer drastisch zu verkürzen. So blieben eben viele B-Seiten der Disketten ungenutzt, weil durch die XF im Normalzustand nicht formatierbar (Es hat halt heutzutage auch nicht jeder einen 1050-User in der Nähe).

So kam mir oben genanntes Teil gerade recht, um meine Speicherkapazität quasi über Nacht zu verdoppeln: Zunächst war ich allerdings etwas geschockt, denn für knapp 30 DeMmchen kam eine ziemlich groß geratene Platine mit sage und schreibe 3 (in Worten: „drei“) Bauelementen (welche das sind, wird hier nicht verraten) plus Bastelanleitung ins Haus geflattert. Die Anleitung erwies sich als exakt und ausreichend, wenn man mal von einem grünen Anschlußdraht absieht, der nach Anleitung eigentlich gelb sein müßte. Gefällig war außerdem, daß man mit dem Messer, Lötkolben und einen schwarzen Filzstift sowie Schraubendreher vollkommen ausreichend ausgerüstet ist. Bereits nach einer halben Stunde war das Teil eingebaut! Davon gingen 10 Minuten sogar noch dafür drauf, zwei passende Schrauben zu suchen, die entweder meiner Lieferung fehlten oder ich auf Grund ihrer Größe vermasselte.

Lange Rede – kurzer Sinn: Das Teil läuft einwandfrei. Auch die bisherigen Funktionen der Stationen bleiben natürlich erhalten. Nur… die Kerbe, die muß natürlich jetzt hinein in die Diskette, aber dafür gibt’s ja genügend Locher.

Reiner Werner

 

Maschinensprache

…soll das Thema einer Artikelserie sein, welche in loser Folge hier zukünftig erschein
en wird.

Zunächst möchte ich einmal voranstellen wie es überhaupt zu diesem Artikel kam. Marcus Witte hatte sich im Sondermagazin Nr. 9 mit einem Aufruf an die Spezis gewendet. Auf Grund dessen hatte ich ihm meine Meinung dazu geschrieben und ihm angeboten bei diversen Problemen auszuhelfen. Marcus wollte keinen Assemblerkurs im herkömmlichen Sinn, sondern mehr Anwendungen mit kommentierten Listings. Das birgt natürlich die Gefahr, daß grundlegende Dinge nicht verstanden werden. Einen Assemblerkurs kann ich schon aus zeitlichen Gründen nicht schreiben und wollte auch nicht, da es bisher in fast allen Magazinen etc. Assemblerkurse gab und gibt. Hier hält mir Marcus entgegen, daß es in dieser Art nichts Vergleichbares gibt und die ABBUC-Leser in der Regel nur dieses Magazin lesen. Die Clubmitglieder sind autark?

Da die Antwort der Spezies bis dato offensteht, versuchen wir das Problem nach dem Motto „Selbst ist der Mann bzw. die Frau“ zu lösen.

Vorab sind jedoch erst einmal einige Konventionen festzulegen:

Alle Programme sind für den ATMASII-Assembler geschrieben. Dieser ist der weitverbreiteste Assembler für unseren XL überhaupt. Desweiteren benötigt er keine Speichererweiterung, sodaß auch Einsteiger die Möglichkeit haben mitzumachen. Da es Konvertierungsprogramme sowohl für den BIBO-Assembler, wie auch für MAC65 gibt, sehe ich hier keine Anpassungsprobleme. Diverse Programmteile werde ich aus zeitlichen Gründen aus mir zur Verfügung stehenden Zeitschriften, meist älteren, entnehmen. Ich bitte hierbei unbedingt das Copyright zu beachten. Ein entsprechender Hinweis wird beim jeweiligen Artikel erfolgen.

Für Fehlerhinweise bin ich jederzeit dankbar. Nobody is perfect!

Dankbar bin ich auch für Themenvorschläge. Ich versuche diese soweit wie möglich zu berücksichtigen. Meine Anschrift findet Ihr am Ende dieses Artikels. Ich möchte jedoch hier einfügen, daß ich nicht auf jeden „Wunsch“ eingehen kann, da der 800XL für mich, neben meinem PC, nur noch ein Hobby ist und ich bei speziellen Themen auch Literatur büffeln muß.

So, nun zum „Eingemachten“:

Da Marcus in seinem Schreiben den Bootvorgang angesprochen hatte, habe ich dieses Thema für den 1. Artikel aufgearbeitet.

STARTPROBLEME?

Zum besseren Verständnis der Materie hole ich hier etwas weiter aus.

Was versteht man nun eigentlich unter „booten“ bzw. „Bootvorgang“? Frei übersetzt kann man das mit „Einschalten“ definieren. Daß der Rechner eingeschaltet wird, also mit Strom/Spannung versorgt wird, ist wohl jedem klar. Wenn das alles wäre, brauchte man darüber kein Wort zu verlieren. Mit dem Einschalten wird jedoch bei jedem Rechner eine spezielle Routine aufgerufen die verschiedene Aufgaben erfüllen muß, wie Variablen/Vektoren/Peripheriegeräte initialisieren, Speicher bereitstellen, Speicher testen etc. Bei unserem 800XL/XE heißt diese Betriebssystem-Routine „powerup-routine“. Diese wird bei jedem Kalt- oder Warmstart aufgerufen. Die Entscheidung ob Kalt- oder Warmstart wird jedoch nicht in dieser Routine, sondern in den vorgelagerten Routinen getroffen. Innerhalb der „powerup-routine“ wird nun die Prozedur „Boot“ für den „Bootvorgang“ aufgerufen. Diese „Bootroutine“ ist aber keinesfalls nur für die Diskettenstation verantwortlich, sondern für alle bootfähigen Pheripheriegeräte wie Cassettenrecorder, Cartridge, Parallelbusgeräte etc.

Anmerkung: Beim Warmstart wird die Bootroutine übersprungen.

Sind alle Anfragen von der „powerup-routine“ durchgeführt und es steht fest, daß von der Diskettenstation „gebootet“ wird, dann kommen wir jetzt zu dem Teil den ich in diesem Artikel näher erläutern will, dem Bootvorgang für die Diskette.

Doch HALT!, bevor ich loslege, ist noch etwas zu klären. Wie kann denn überhaupt eine Diskette gebootet werden, wenn das DOS noch nicht geladen ist? Tatsächlich gibt es innerhalb des Betriebssystems eine Routine, wenn auch eine einfache, die es ermöglicht mit der Diskettenstation zu kommunizieren. Diese Routine nennt sich Resident Diskhandler und ist durch den Label DSKINV ($E453) gekennzeichnet. Resident deshalb, weil die Routine resident im Betriebssystem vorhanden ist und nicht geladen werden muß. Die Routine erledigt sämtliche Initialisierungsaufgaben zum Lesen und Schreiben eines Sektors, zum Formatieren oder zum Lesen des Statusses. Alle entsprechenden Variablen werden initialisiert. Vom Anwender sind lediglich vor dem Aufruf die Pufferadresse, das Kommando, sowie die Sektornummer in die Register einzutragen. Als allgemeiner Rückgabewert ist im Y-Register ein Statuswort enthalten, das im Fehlerfall negativ ist. Weiteres kann dem kommentierten Listing entnommen werden, welches Ihr auf der Diskrückseite findet.

Es wird von der Diskettenstation 1 gebootet. Der 1. Sektor wird in den Cassettenbuffer $400 geladen. Die ersten 6 Bytes dieses Sektors werden ausgewertet. Diese enthalten Informationen ähnlich einem File-Header.

  • Das 1. Byte wird nach DFLAGS ($240) geladen. Diese Byte wird bei den derzeitigen Betriebssystemen nicht benutzt und enthält immer Null.
  • Das 2. Byte wird nach DBSECT ($241) geladen und enthält die Anzahl der zu ladenden Sektoren.
  • Das 3. und 4. Byte werden nach BOOTAD ($242/243) geladen. Diese Bytes enthalten die Ladeadresse des Programms.
  • Das 5. und 6. Byte werden nach DOSINI ($C/D) geladen und enthalten die Initialisierungsadresse des Programms.

Nun läßt sich der 1. Sektor an die inzwischen bekannte Ladeadresse verschieben. Danach werden soviel Sektoren geladen, wie im 2. Byte angegeben und gleich an die richtige Stelle geschrieben. Anschließend wird eine Routine aufgerufen die mit dem 7. Byte beginnt. Hier erfolgt dann die Bootfortsetzung bei mehrstufigen Bootprozessen oder ähnlichen Dingen. Soll die gebootete Software die Systemkontrolle übernehmen, dann muß hier DOSVEC zwingend gesetzt werden. Wenn nicht, dann ist dies aber in BOOTINI erforderlich. Äußerst wichtig ist auf jeden Fall, dem Betriebssystem durch ein gelöschtes Carry-Flag mitzuteilen, daß kein Fehler aufgetreten ist und mit RTS die Kontrolle an das Betriebssystem zurückzugeben. Danach erfolgt ein Unterprogrammsprung durch den Vektor DOSINI, welcher das Programm auf die Adresse BOOTINI (5. und 6. Byte) initialisiert. Dieser Sprung findet auch statt, wenn später einmal RESET gedrückt wird. Nach der Abarbeitung dieser Routine wird nun endlich zur Adresse gesprungen, welche in DOSVEC angegeben ist. Dort steht normalerweise das Hauptprogramm, das ja eigentlich gebootet werden soll.

Das waren dei Erläuterungen zum Bootvorgang von Diskette.

Auf der Diskette befindet sich ein File BOOTBSP.SAC mit kommentiertem Listing. Bevor Ihr das File assembliert, bitte eine leere Diskette in Single- oder Enhanced formatieren. Dann das File in den ATMASII-Assembler laden und assemblieren. Die formatierte Diskette einlegen und das assemblierte File bei $A800 starten. Das Programm ab Adresse $A900 wird nun auf die leere Diskette als Bootfile geschrieben. Danach den Rechner ausschalten und nach einer kleinen Pause, den ICs zu liebe, den Rechner mit gedrückter OPTION-Taste neu booten. Dabei erscheint ein farlbich geänderter Bildschirm mit Text. Das ist das Programm zur Initialisierung über das Label BOOTINI. Nach Drücken der Starttaste springt der Rechner zum eigentlichen Hauptprogramm SCROL, welches wir ja auch DOSVEC gesetzt hatten. Wenn nun die RESET-Taste gedrückt wird, springt der Rechner zur Initialisierungsadresse DOSINI und das ganze Spiel beginnt wieder von vorne.

Die Starttaste wurde nur eingefügt, um den Programmablauf zu verlangsamen und darzustellen. Der Programmtei
l kann jederzeit entfallen.

Alles klar?

Um Rückfragen zu vermeiden, erläutere ich hier zusätzlich noch einiges aus dem Listing. Der Bootgenerator macht nichts weiter als das Bootprogramm auf die Diskette zu schreiben.

Das Bootprogramm wird beim assemblieren in den frien Speicher, hier ab $A900 (ABLAGE) geschrieben. Lauffähig ist es jedoch bei $700 (BOOTADR). Das ist ATMAS-spezifisch und muß an den jeweiligen Assembler angepasst werden. Nach dem 6. Byte wird die Adresse des Hauptprogramms SCROL geladen und nach DOSVEC geschrieben. Anschließend das Carry-Flag gelöscht und mit RTS wieder in die „powerup-routine“ gesprungen. Wie bei der Beschreibung des Bootprozesses bereits erwähnt, muß DOSVEC hier nicht unbedingt gesetzt werden. Es ist ebenfalls möglich, dies innerhalb von BOOTINI vorzunehmen. Prinzipiell hängt es von der zu bootenden Software ab, in welcher Reihenfolge, welche Programmteile, wohin geladen bzw. initialisiert werden soll. Dafür gibt es keine festen Regeln und auch keine Einschränkungen. Wichtig ist zu wissen, was beim Bootvorgang passiert und in welcher Reihenfolge er abläuft, dann kann man ihn auch für eigene Programme verwenden.

Noch etwas zum Abschluß. Der Bootgenerator kann auch für andere Programme genutzt werden. Wenn Ihr schon vorhandene Programme (Source-Code) bootfähig machen wollt, so müßt Ihr lediglich die Lade- und Initadresse Euren Programmen anpassen. Außerdem ist darauf zu achten, daß das Programm in einem Stück im Speicher steht und keine DOS-Zugriffe darin enthalten sind (es ist ja keins geladen).

Dann wünsche ich Allen einen „Guten Start“.

Bis zum nächsten Mal

Gunter

Meine Anschrift:

Gunter Pfannmüller
Fichtenstrasse 12
6360 Friedberg 1

Bitte Rückporto beilegen

 

Megafont Texter

Bezugsquelle:

Power Per Post
Postfach 1640
7518 Bretten
Telefon: 07252/3O58

Preis: 29,80 DM

Der Megafont Texter ist eine Weiterentwicklung des Megafont Displayers, der entstand, als Chistian Krüger mal wieder dabei war einen neuen Zeichensatz zu entwerfen. Da ihm der 8 x 8 Matrix-Standard zu klein war.

Der Megafont Displayer lief unter TurboBasic und hatte ein sehr unkomfortables Handling, sodaß Christian sich daran machte den Megafont Texter zu schaffen.

Soweit zur Entstehungsgeschichte, die mal wieder beweist, daß auch aus einer verrückten Nebenbei-Idee etwas werden kann (kleine Motivation). Mit dem Megafont-Texter aus dem Hause HQ-Software ist es nun möglich, seine selbstgestrickten Graphics-6-Bilder mit wunderschönen Schriftzügen zu versehen. Die Zeichensätze oder Bilder können im Grahik 6-; 7- oder 8-Format gepinselt werden. Für die letzteren Formate ist jeweils ein Konvertierungsprogramm auf der Diskette. Nach dem Laden sieht man das Textfenster, oben die Menüleiste und links und rechts die Bildschirmbegrenzungen. Der Megafont Texter hat wirklich sehr viele Funktionen, die selbst die Anspruchsvollen unter Euch zufriedenstellen werden. Hier mal eine Übersicht:

  • Änderung der Ausgabefarmen
  • Einstellung der Neigungen für kursive Schriften
  • Einstellung der Stärke des Unterstreichens
  • Abstand zu den Buchstaben
  • Abstand zu den Wörtern
  • linke bzw. rechte Bildschirmbegrenzung setzen
  • Abstand zur Unterstreichung u. v. m.

Wie man sieht, eine ganzeMenge Funktionen. Dazu kommen noch extra Tastenbelegungen mit denen man vorgegebene lcons wie z. B. ein Fluchtweg-Schild auf den Screen drucken kann. Im Grunde genommen ist der Megafont Texter ein Programm, das jeder, der im grafischen Bereich tätig ist, besitzen sollte.

Leider verfügt das Programm über keine direkte Druckerausgabe. sodaß man immer ein Druckerprogramm für Graphics 6 benutzen muß. Aber wenn man bedenkt, was das Programm sonst noch alles leistet, kam man darüber wegsehen. Ich kann das Programm weiterempfehlen.

Mike Sloma

 

TurboBasic Tool Disk

Bezugsquelle:

mhs-Studio
Gohliser Str. 21
O-8028 Dresden
Preis: 19.80 DM

Die TB Tool-Disk ist mehr oder weniger eine Hilfe für die TurboBasic – Einsteiger. Sie erklärt anhand von Beispielen die Sonderbefehle des TB, die weniger bekannt sind.

Die Diskette kommt schreibgeschützt und beidseitig bespielt. Wenn man die erste Seite bootet, gelangt man nach einen kleinen Begrüßungstext ins Titelbild. Der Sound ist … na ja, Geschmacksache.

Nach Drücken der Start-Taste kommt man in das gut geordnete Main-Menü. Von hier aus kann man mit einem Joystick in Port 1 per Pfeil den gewünschten Text abrufen, in dem z. B, die Funktionen von BPUT, BGET usw. erläutert werden. Dann gibt es noch ein Untermenü, in dem man aus 11 Demo-Tools auswählen kann. Da sind u. a.:

  • Ein Mini-Dos
  • Picture-Loader
  • PM-Grafik (Bewegung durch MOVE)
  • bewegte Grafik
  • Sound Demo (ohne Sound-Befehle)
  • Disk to Disk Kopierer
  • Hardcopy A4 für 1029
  • bewegte Grafik
  • DLI in Turbo Basic
  • Grafik-Übersichts-Demo
  • Garne (MINI-PAC)
  • Assembler in TB einbinden

Alle Demo-Tools sind vollständig lauffähig und veranschaulichen die Möglichkeiten von Turbo Basic. Im Listing ist alles Schritt für Schritt erklärt, so daß auch Anfänger alles nachvollziehen können. Die Demo-Tools sind für die Weiterverwendung gedacht.

Auf der Seite B der Diskette befinden sich folgende Softwaretools:

1. Graphics 15 Painter 2. Lightpen Painter
3. Bild-Hacker-Lader 4. Hardcopy 1029
5. Zoomer Graphics 8 6. Zoomer Gr. 8 & 15
7. Bild Ausschneider 8. Scanner für 1029

Einige der Tools sind auch für Profis recht nützlich. Jedenfalls kommen Atari-1029-User auf Ihre Kosten.

Fazit: Die Turbo Basic Tool-Disk sollte wenigstens als kleine Hilfe in der Schublade jedes TB-Programmierers liegen‚ da das TB über eine ganze Menge besonderer Befehle verfügt, die es im Atari Basic nicht gibt. Den Einsteigern wird die TB Tool-Disk sehr helfen, den Profis bringt es nichts neues.

Mike Sloma

 

TML Stereo Drum-Editor

Auf der Hobbytronic gab mir Wolfgang den TML-Drumeditor von „The Missing Link“ aus Holland – im Vertrieb von A.N.G. Software Holland – zum Testen. Dieser Testbericht ist eine Zusammenarbeit vom ABBUC e. V. und dem TOP-Magazin, wehalb er auch zeitgleich in bieden Magazinen erscheinen wird.

Das Programm ist in einer normalen „Programmplastikhülle“ verpackt; das sind wir als XL/XE-Besitzer ja mittlerweile gewohnt…
Eine rote Hülle mit dem Titelbild und der Aufschrift TML-Drumeditor packt die Diskette und die Anleitung ein.

Wollen wir erst einmal kl&auml
;ren, was ein Drumeditor eigentlich ist: Vielen Musikstücken würden die Genialität oder die Power fehlen, wenn sie nicht Schlagzeug oder (wie man so schön sagt) Digi-Drums als tolle Effekte integriert hätten.

Beim Black Magic Composer von Gnome Design ist die Funktion, Samples – sprich DigiDrums – einzubinden, schon eingebaut. Dies ist ein starker Vorteil. Hat ein Editor eine solche Funktion nicht (z. B. MASIC oder andere ältere Soundprogramme) können durch Freihalten einer Stimme dann Samples addiert werden.

A.N.G. Software brachte aus diesem Grund den TML-Drumeditor heraus, mit dem es nun auf sehr professionelle und einfach Art möglich ist, solche DigiDrums in seine Musikstücke einzubinden.

Gleich am Anfang stieß ich auf einen großen Nachteil: Ich bin leider nicht der holländischen Sprache mächtig. Die Anleitung war in meiner Testversion leider nur in dieser Sprache abgefaßt. „U heeft de TML-Drumeditor gekocht…“
Dann hörte ich schon auf zu lesen; was wohl der TML-Drumeditor mit kochen zu tun habe?!? (Dies bitte nur als Witz auffassen)

Im Cover fand ich glücklicherweise ein paar deutsche Worte. Dort steht etwas von einer ausgebreiteten Anleitung in drei Sprachen, die dem Programm als Text integriert oder lose beiliegt. Ich habe leider keine andere Anleitung außer der holländischen gefunden. Schon möglich, daß dies wirklich nur eine Testversion ist.

 

Nun aber zum Programm:

Nach dem Einlesen fand ich ein Menü, das mir die sehr gute Möglichkeit bot, das Programm in Deutsch zu bedienen. Dies ist eine wirklich sehr gute Idee: Der TML-Drumeditor kann in drei Sprachen ausgeführt werden: Deutsch, Holländisch und Englisch. Das nennt man „Internationale Software“. PLUSPUNKT!

Die Bedienerführung ist im bewährten Fenster-Menü-Look programmiert. Mit einem Wahlbalken geht man durch ein Menüfenster. Nach dem Anklicken öffnet sich ein neues Fenster, in dem die gewählte Funktion dann abgehandelt wird. PLUSPUNKT also auch für die sehr gute Benutzerführung.

1. Menüpunkt ist der Musterditor:

Hier wird die Folge der Samples nacheinander in einem Pattern festgelegt. Durch einfache Tastenkombinationen kann leicht auf weitere Pattern umgeschaltet werden. Drückt man die Taste P, so kann man sich den gerade gewählten Pattern (Muster) anhöhren (PLUSPUNKT). Durch Eingabe einiger Werte kann zum Beispiel die Samplelänge oder der Kanal geändert werden.

Das Programm heißt TML Stereo Drumeditor. Wie das mit dem Stereo funktioniert oder was da Stereo ist (ob das auf Hardware, durch Einbauen eines zusätzlichen POKEY zurückzuführen ist?) kann ich leider nicht sagen – die Anleitung war ja nur in Holländisch.

Mit H kann ein Hilfsmenü aufgerufen werden, das mich schnell über die Funktionen des Editors aufklärt.

Die 2. Funktion im Hauptmenü ist der Ablauf- oder Songeditor. Hier können die Pattern zusammengesetzt und der Song abgespielt werden.

An 3. Stelle stehen nochmals die Sprachen zur Auswahl: Es kann auch während der Programmausführung die Sprache gewechselt werden.

Im Disk-Menü können dann Pattern, Songs, Samples oder Komplettfiles geladen werden.

Eine komfortable Directoryauswahl erleichtert das Anwählen eines Files. Das DOS-Menü ist ein kleines DOS 2.5 kompatibles MiniDOS mit den wichtigsten Befehlen. VORTEIL: Es kann von hier ungehindert zum Editor zurückgesprungen werden.

Im vorletzten Menüpunkt können verschiedene Parameter geändert werden, wie z. B. Länge, Kanal, Anzahl, Teil, Richtung oder Farbe.

An letzter Stelle steht der EXIT-Befehl – ich glaube, daß jedem klar sein dürfte, was hiermit gemeint ist.

 

Fazit:

VORTEILE:

  • sehr gute Benutzerführung
  • mehrere Sprachen
  • einfache Bedienung
  • große Funktionsvielfalt
  • Einbinden von neuen Samples möglich
  • Stereo-Funktion (?).

 

NACHTEILE:

  • Anleitung nur in … (ähm)
  • keine Demosongs
  • Es kann passieren, daß sich der editierte Song einfach mal ganz schnell verabschiedet, z. B. wenn man das Parameter-Menü aufruft. Eine Sicherheitsabfrage hätte hier sehr gut getan.

Sonst kann ich den TML-Drumeditor nur empfehlen, da sich die Qualität der erstellten DigiDrums wirklich sehen lassen kann. Das Programm kostet ca. 20.– DM und ist entweder direkt bei A.N.G. Software oder biem TOP-Magazin zu bekommen.

Michael Schulz

 

Atari, ZRAM und die Geschichte

Roland Bühler (RoBü) hat mir mit seinem Artikel über die Benutzung von Zusatz-RAM (ZRAM) den Anstoß gegeben, mal wieder ein paar Anmerkungen darüber loszulassen.

Die neueste Speichererweiterung (aus ’90) stammt von Newell Industries, Es gibt sie in zwei verschiedenen Varianten (XL oder XE) zum Selbsteinbau. Die Erweiterung ist dann mit entsprechenden RAMs auf 1, 2 oder 4 (!!!) Megabyte aufrüstbar. Wer sich nur 1 Megabyte in den Rechner einbauen will, kann das beim 130XE auch auf andere Weise erreichen.

Doch zurück zu den Anfängen (back to the roots…)! Bereits 1982 wurde für den ATARI 400/800 z. B. von Axlon eine Speichererweiterung auf 256K angeboten. Die Preise waren für heutige Verhältnisse astronomisch…

Der 800XL kostete in Deutschland bei Einführung ca. 1.200,- DM, die Floppy 1050 ca. 1600,- DM und die Cassette 1010 ca. 250,- DM! Die früheren Preise für den 800er, die 810er Floppy und andere Peripheriegeräte waren noch höher… lmmerhin war das 800er-System schon so ausgereift, daß Schulen und Universitäten damit forschten und lehrten. Heute kaum mehr vorstellbar! Laßt mich noch ein wenig in Erinnerungen schwelgen…

Wer erinnert sich noch an den berühmten Wettstreit der Mikroprozessoren zwischen dem 6502 und dem Z80? Ganze Computerphilosophien wurden darum gesponnen. Die bekanntesten Vertreter der 6502-Sparte:

  • Apple l und II
  • ATARI 400, 800, 600XL, 800XL, 1200XL, 1450XLD, 65XE, 800XE, 13OXE, XE-GS
  • Commodore VC20, C64, CE 64, 4000, 8000

Die Z80-Gladiatoren:

  • Sinclair ZX8O, ZX81
  • NEC PC 8000
  • ORIC 1
  • Colour Genie

Daneben waren nach andere 8-Bit-Prozessoren sehr weit verbreitet. Ich denke da z. B. an den 6803/6809, der ehemaligen Dragon- oder TRS-Besitzern sicher noch geläufig ist.

Da fällt mir ein: Bereits lange bevor ATARIs ST-Reihe erschien, stellte Apple mit dem LISA im Jahr 1983 einen 68000er-Rechner vor. Das System war wie folgt konfiguriert:

  • Grundgerät mit Monitor und zwei eingebauten Floppies
  • 5 1/4″ (860K)
  • separate 77er-Tastatur mit Zehnerblock
  • CPU Motorola 68000
  • RAM 1 Megabyte
  • Screen + Text 40 Zelien mit 132 Zeichen
  • Grafik 720 * 364 Pixel
  • Farbe, schwarz/weiß
  • 2 RS-, 1 V24-Schnittstelle
  • GEM-ähnliche Benutzeroberfläche
  • Maus

ATARI aber gebührt die Ehre, durch niedrigste Preise (power without the price) die 68000er-Technologie einem breiten Anwenderkreis zugänglich gemacht zu haben. Der 130/260/520ST waren auf der CeBit ’85 (damals noch in die Hannover Messe integriert) der Knaller! Zum gleichen Zeitpunkt erschien auc
h der 130XE. Gemessen am neuen Technikstandard eine anachronistische Maschine. Neu war der Speicherausbau bei ATARIs 8-Bit-Rechnern: 128K. Dazu passende Software sollte noch in Massen erscheinen. Viel mehr als ein ‚ATARI Writer Plus‘ ist bei ATARI aber nicht mehr entstanden.

Das Marketing-Konzept verdammte bereits 1985 (!!!) den 8-Bit-ATARI auf einen Museumsplatz. Allein die schon in Kalifornien fertig herumliegende Hard- und Software (XEP80, XC11, XC 12, 65XE(800XE), XF551, Lightgun, verschiedene Games, XE-GS, Drucker, Plotter…) wurde so nach und nach noch auf den Markt geschmissen. Damit sollten wohl die 8-Bit-User bei der Stange gehalten und irgendwann auf die ST-Rechner ‚rübergezogen werden. Unter betriebswirtschaftlichen Aspekten mehr als vernünftig!

Doch was haben schon Frauen-, Auto und Computerwahl mit Vernunft zu tun??? Immerhin wurde mit dem 130XE noch ein neuer Standard gesetzt:

  1. Der User bekommt mehr als 64K Speicher.
  2. Port B der PIA verwaltet dieses Mehr.

Und damit sind wir wieder beim aktuellen Thema. Aber wofür braucht der User mehr Speicher? Der 6502 kann ja nur 64K addressieren, mehr ist nur mit Tricks möglich! Nun, die beliebteste Anwendung dafür ist eine RAMDisk. Meist hatte der User in den 80ern nur eine Floppy, die dann oft nicht ausreichte. Ein zweites Laufwerk im Speicher simuliert, war schneller und billiger als eine zweite 1050. Und im Kopierspeicher konnte man bei genug RAM eine ganze Diskseite in Double Density (180K) unterbringen. Mit nur 64K war man ein armer Disk-Jockey…

Der Wunsch nach mehr Speicher war aber schon bei den 800er-Usern vorhanden. Entsprechend beachtlich war das Angebot an Erweiterungen von kommerziellen Herstellern (aus den USA). Da die Preise dafür noch beachtlicher waren, griffen findige User zur Selbsthilfe. Erweiterungen bis 1 Megabyte wurden für den 800er in Heimarbeit entwickelt. Ein Bastler der ersten Stunde war Claus Buchholz. Seine Schaltungen fanden bald weite Verbreitung, weil sie leicht und preiswert herzustellen waren. 1985 hat er seine Konzepte auf den neuen 8-Bit-Standard (Port 6 der PIA) umgestellt. Die Ideen waren so gut, daß kommerzielle Hersteller (z. B. ICD) diese übernahmen. Auch ich habe eine seiner Ideen (BYTE-Magazin, Sept. ’85) aufgegriffen und für den 800XL weiterentwickelt.

Welchen Anforderungen muß eine Speichererweiterung für XL/XE gerecht werden? Dazu eine Gedankensammlung:

  • ZRAM von mindestens 180K (Copy einer SS/DD-Disk)
  • unter jedem DOS nutzbar
  • aus jeder Programmiersprache ansprechbar
  • von kommerzieller Software nutzbar
  • interner Einbau, damit Schnittstellen freibleiben
  • preiswerter und leichter Einbau
  • zuverlässiger Betrieb (!!!)

Verzichten kann man dabei auf:

  • den getrennten DMA von CPU und ANTIC wegen dazu fehlender Software.
  • den Selbsttest (bei defektem Rechner geht auch der nicht!)
  • Abschirmblech (beim XL)
  • das interne BASIC (weil fehlerhaft).

Damit komme ich zu einer Auswahl an Erweiterungen, die obigen Kriterien gerecht werden:

  • 64K intern für 600XL vom Compy Shop
  • 256K intern für 600XL
    » vom Compy Shop (baut auf 64K intern auf)
    » nach Claus Buchholz von Good Byte
  • 256K für 800XL nach Claus Buchholz
    » Newell Industries
    » ICD
    » ABBUC
    » Good Byte
  • 320K für XL
    » Compy-Shop-Erweiterung
    » Bauplan aus ATmag
  • 192K für XE
    » Bauplan vom ABBUC
    » Compy Shop
  • 320K, 576K, 1088K für 130XE
    » Schaltungskonzept von Scott Petersen; erhältlich beim ABBUC

Was leider fehlt, ist eine zuverlässige 512K-Erweiterung für den 800XL. Könnte mein Urlaubsthema werden…

Mancher wird vielleicht seine RAM-Erweiterung bzw. die bekannter Hersteller vermissen. Leider genügen sie nicht den oben aufgestellten Kriterien. Vor allem Betriebssicherheit und Nutzbarkeit aus jeder Sprache heraus sind wichtig. Die meisten User programmieren sicher ab und an auch in einem BASIC-Dialekt. Zu empfehlen wäre hier MS-BASIC, BASiC XL oder XE und mit Einschränkungen TurboBASIC.

Was nützt einem das tollste ZRAM, wenn man es nicht direkt erreichen kann? Daten, Grafiken und Unterpragramme lassen sich dann nicht mehr einfach im RAM zwischenspeichern. Ein MOVE-Befehl ist allemal fixer und eleganter als ein Zugriff auf eine RAM-Disk. Was man damit erreichen kann, zeigen ‚HIRES DUMP 130XE‘, ‚The Small Printery‘ oder auch ‚Typesetter 130XE‘. Ein besonderer Leckerbissen in der ZRAM-Nutzung sind BASIC XE und SpartaDOS X, die ZRAM für den Programmspeicher bzw. das DOS mitnutzen.

RoBü hat ja im ClubMag #29 aufgezeigt was der User wie mit ZRAM anstellen kann. Das Studium seiner Listings zeigt Euch, wie man die Klippen sicher umschifft.

Wichtig ist, wenn man mit BASIC arbeitet, daß alle Routinen für das Steuern des ZRAM am Programmanfang liegen. Damit ist man immer auf der sicheren Seite (unterhalb $4000). Hinsichtlich des String- bzw. Array-Problems hilft RoBüs Trick mit dem Dummy-String. Schaut mal in die Listings – es lohnt sich! Außerdem muß man natürlich wissen, welche Bänke überhaupt vorhanden sind.

Helfen können dabei die RAM-Tests der verschiedenen DOS, Allerdings decken sie nicht alle Hardwarekonfigurationen ab, sodaß die Testergebnisse mit Vorsicht zu genießen sind. Deshalb habe ich mir für meine BASIC-Programme ein Setup geschrieben, das die gewünschten Kennbytes in Page 4 schreibt. Das Setup testet nicht die eventuell vorhandenen Banks des ZRAM, sondern übernimmt aus einer Tabelle die entsprechenden Bytes. Diese Tabelle habe ich im Laufe der Jahre als Ergebnis meiner vielfältigen RAM-Basteleien zusammengestellt und mit Hilfe einer einfachen Bildverschieberoutine (let’s move…) auf ihren Wahrheitsgehalt getestet.

Wie aber wird nun ZRAM durch ‚Banken‘ erreicht? Fangen wir wieder beim 130XE an. Jede mir bekannte Erweiterung verfügt aus Gründen der Kompatibilität über die XE-Bank. Diese zweiten 64K sind (als Bank betrachtet) über den Wert $E0 in Adresse $D301 (Dez 54017), dem Port 6 der PIA erreichbar. Da ja immer nur 16K eingeblendet werden können, erhält man unter $E0 die ersten 16K. Durch Addition von jeweils $04 zu $E0 kommt man dann an die nächsten 3 * 16K. Dieses ist der ’85 eingeführte XE-Standard.

Doch über Port B der PIA wird nicht nur ZRAM verwaltet. RoBü hat in Mag #29 die Schaltung der 256K-Erweiterung für den 800XL (ohne FREDDY) vom Compy Shop beschrieben und in seinem Schaubild das Port gut veranschaulicht. Eine vergleichende Darstellung XL-XE findet Ihr auch im Bauplan für den 320K-XL aus dem früheren ATARI-magazin.

Freigeworden übrigens ist das Port B der PIA durch die mit dem XL neu eingeführte MMU (Memory Management Unit). Beim 800er wurden hier der 3. und 4. Joystickport verwaltet. Grundsätzlich gilt, daß jede über $D301 selektierte Funktion durch Löschen des für sie zuständigen Bits erreicht wird. Poket mal von ATARI-BASIC aus eine 255 in 54017…! Ein Reset bringt Euch dann wieder ins BASIC zurück. Was war passiert? Nun, das Bit das für das interne BASIC zuständig ist wurde auf 1 gesetzt und dadurch das BASIC abgeschaltet. Das führte natürlich zum Absturz…! Jetzt ist auch der Standardwert von 253 in 54017 nach dem Booten und Einschalten des BASICs klar. Alles andere aus, BASIC ein!

Ein zweiter Versuch dazu! Ladet mal ein sehr langes BASIC-Programm (mindestes 15K) in den Rechner. Nun poket in 54017 den Wert 225. Es passiert offenbar nichts!? Jetzt laßt mal das Programm listen…! Und siehe da, irgendetwas hat einen Teil des Programms verschwinden lassen. Jetzt schnell 253 in die 5
4017 poken und siehe da: Der Rest ist auch wieder da!

Was war das? Nun, wir haben über Port B der PIA den DMA der CPU auf die unteren 16K der XE-Bank umgeschaltet. DMA ist der ‚direct memory access‘ (direkter Speicherzugrift) des Mikroprozessors. Deshalb konnte der Rechner von Adresse $4000 – $7FFF nur die 16K der XE-Bank aber nicht mehr die 16K des ursprünglichen Speichers ’sehen‘! Durch POKE 54017,253 haben wir einfach zurückgeschaltet und unser BASIC-Programm war wieder komplett. Daraus folgt, daß man ganz einfach ‚von Hand‘ auf ZRAM zugreifen kann und daß durch das Banken im Port B die Speicherinhalte nicht verändert werden. Soweit dürften jetzt alle Klarheiten beseitigt sein…

Kommen wir auf die verzichtbaren Features des XL/XE zurück. Getrennter DMA, Selbsttest und internes BASIC werden nicht unbedingt benötigt. Damit bleiben noch zwei Schaltbits in 54017 übrig. Bit 0 für das OS und Bit 4 für den gemeinsamen DMA von CPU und ANTIC auf das ZRAM. Ohne diese beiden Bits liefe der Rechner nicht. Somit erhalten wir 2 ^ 6 = 64 Schaltmöglichkeiten. 64 * 16K = 1024K = 1 MB sind also über Port B steuerbar. Meist begnügt man sich mit weniger ZRAM und erhält stattdessen das interne BASIC und den Selbsttest. Mit zusätzlichem Hardwareaufwand kann man sogar 1MB und alle Systemfeatures über Port B verwalten. Mir ist allerdings niemand bekannt, der jemals solchen Aufwand getrieben hat.

Die Entwickler der verschiedenen RAM-Erweiterungen sind hinsichtlich der für das Schalten erforderlichen Bits verschiedene Wege gegangen. Daher rührt dann auch die vermeintliche Inkompatibilität so mancher Software. Wie kann man dem begegnen? Da auf jeden Fall zwei Bits in 54017 ihre Funktion behalten (OS und CPU-DMA) lassen sich alle anderen 64K- und 16K-Kombinationen leicht berechnen. Das Ergebnis ist die schon angesprochene Gesamttabelle. Insgesamt sind maximal vierundsechzig 16K-Bänke möglich. Diese sind aufgrund der Hardware in 8 Bänken zu 128K (um 1024K) organisiert. Jede dieser 8 Bänke ist wiederum in 8 Bänke zu 16K organisiert. Man merkt, es handelt sich um einen 8-Biter! Braucht man nicht alle Bitkombinationen, weil man weniger als 1 Megabyte einbauen will, sucht man sich die aus, die einem am besten gefallen oder für die man zufällig gerade die passenden Chips in der Bastelkiste hat. Und hier die Tabelle:

128K-Bänke 8 * 16K über Addition von je $02
$00 $00,02,04,06,08,0A,0C,0E
$20 $20,22,24,26,28,2A,2C,2E
$40 $40,42,44,46,48,4A,4C,4E
$60 $60,62,64,66,68,6A,6C,6E
$80 $80,82,84,86,88,8A,8C,8E
$A0 $A0,A2,A4,A6,A8,AA,AC,AE
$C0 $C0,C2,C4,C6,C8,CA,CC,CE
$E0 $E0,E2,E4,E6,E8,EA,EC,EE

Eine reichhaltige Auswahl. Schade nur, daß es bis jetzt kein DOS-Entwickler geschafft hat, anhand dieser Tabelle die tatsächlich vorhandene ZRAM-Konfiguration zu erkennen. Am besten schneiden noch MyDOS 4.5 und SpartaDOS ab. Sie erkennen die meister Kombinationen und können sogar 1 MB als RAMDisk verwalten. Damit wäre der Ausflug in die RAM-Geschichte unseres kleinen Lieblings beendet. Bleibt nur zu hoffen, daß RoBü die nötige Hilfe für seine Betriebssystemergänzung zur Verwaltung von ZRAM bekommt.

Auch die XT/AT-Rechner banken 16K-weise aus dem Bereich 640 – 1024K in den Hauptspeicher. Dafür gibt es Routinen im DOS, sodaß man davon nichts mitbekommt. Wäre eigentich an der Zeit, daß mal einer der Programmiercracks eine entsprechende Routine entwickelt. Was das BASIC XE mit Hilfe der Cartridge bewirkt, sollte auch als Utility zumindest für MyD0S und SpartaDOS verfügbar sein.

Zum Schluß noch ein Wort des Trostes an alle die ZRAM-Besitzer, denen ihr ZRAM bisher wenig Freude bereitet hat. Sollte Euer ZRAM nicht obig aufgeführte Kriterien erfüllen, bombardiert den Hersteller auf Nachbesserung, sucht Euch jemanden zur Hilfe oder verkauft das Teil und realisiert einen der ABBUC-Schaltpläne.

Good Byte

Walter Lojek

 

Waltraud’s Spielecke

Hallo, da bin ich wieder und hoffe, Ihr habt die Sommermonate bisher gut überstanden. Da in unserer PD-Bibliothek die nachfolgenden deutschen Adventures angeboten werden, nehme ich an, daß sie auch gekauft wurden und einige von Euch vielleicht über Lösungen oder Tips froh sind. Außerdem habe ich heute einige sehr tolle Cheats für aktuelle Spiele. Beginnen wir also mit:

HORROR CASTLE

Der Zauberer DRAGAR hat uns in sein Schloß entführt, um mit unserer Lebenskraft seine und die seiner Frau wieder aufzumöbeln. Nicht gerade die feinste Art – aber Zauberer sind nun mal so.

Wir haben jedoch etwas dagegen und müßen versuchen, einen Weg in die Freiheit zu finden. Daß das ein Horrortrip werden wird, ist klar.

Wir befinden uns zunächst in einer Eingangshalle mit einem roten Teppich. Obwohl der ja immer nur für besonders hochgestellte Persönlichkeiten ausgerollt wird, fühlen wir uns nicht geschmeichelt. Wenden wir uns erst einmal nach Westen (der Gestank von dort soll uns nicht stören) und landen in der Küche. Kein Wunder, daß es hier so stinkt! Das Gold nehmen wir natürlich mit und auch das Messer könnte uns später vielleicht helfen. Nun gehen wir wieder nach Osten und zu der knarrenden Tür nach Norden. Die Stille und Dunkelheit im Osten ist unheimlich, deshalb zügeln wir lieber unsere Neugierde.

Nachdem wir die Treppe hochgestiegen und im feuchten Gang mit seinen kleinen Bewohnern nach Norden marschiert sind, stehen wir vor einem Bild. Das kann man wirklich nicht lange ansehen. Wir wollen es auch nicht und schieben es zur Seite. Ein Hebel dahinter reizt zum Ziehen. Es macht ‚Klick‘ – dann passiert nichts mehr! Enttäuscht gehen wir zurück und die Treppe wieder runter. Siehe da – der Hebelzug hat jetzt einen Geheimgang freigelegt, den wir natürlich benutzen. Ohne Vorwarnung sausen wir einige Etagen in die Tiefe und befinden uns an einer Kreuzung. Der Weg nach oben hat sich wieder geschloßen und uns bleibt nur die Flucht nach vorne. Im Norden hören wir ein ekelhaftes Blubbern und im Westen ein unheimliches Keuchen, also wenden wir uns lieber nach Osten.

Hier ist es wenigstens still, wenn es auch dunkel ist und nach Verwesung stinkt (Die Geräusche und Stimmen beim Seitenwechsel sind ein toller Gag des Programmierers!). Na, wo sind wir denn da? Uns stehen die Haare zu Berge! Uns schlottern alle Glieder! Aber wir haben noch soviel Verstand, den Rat zu befolgen. Also schieben wir den Holzbock zur Seite und finden wiederum einen Geheimgang. Den gehen wir runter und sehen einen Raum mit vielen Spiegeln. Und noch etwas! Und dieses Etwas hat es auf uns abgesehen. Es gibt keinen Ausgang! In unserer Not fällt uns das Messer ein. Wir wollen es nach dieser unheimlichen Zerrgestalt werfen – aber wohin? Denken wir an die Spiegel! Wenn du jemanden vor dir als Spiegelung siehst, wo steht er dann? Richtig! Unser Messer trifft genau in die verzerrte Fra
tze und die Gestalt zerfällt zu Staub. Der stinkende Qualm läßt uns für eine Welle „wegtreten“.

Potz Blitz!! Das Satansschloß hat uns ausgespien und als wir wieder bei uns sind, liegen wir davor im Dreck. Plötzlich verdunkelt sich alles und vor uns steht ein schleimiges grünes Monster. Wir fragen es, was es von uns will und es braucht etwas, was wir Gott sei Dank noch bei uns haben. Glücklich trollt es sich von dannen. Und wir? Nun, wir werden wohl ein neues Leben anfangen müssen! 20 Jahre später ist unsere Situation so mies, daß es wohl besser gewesen wäre, hätte uns damals der Zauberer zum „Frühstück vernascht“!


Tips:


WILLE

(Sience-Fiction-Geschichte mit tollen Actionszenen)

Codewörter:

WILLE. Garfield, Crockett, USA, A-HA, (!)‚ 123881, Der Code

Lösung des Mini-Adventures:

Vom Anfangsbild den mittleren Weg nach unten gehen. Noch weiter nach unten und dann rechts das Dynamit nehmen. Vorsicht vor dem Dieb! Mit dem Dynamit ins Anfangsbild und über den rechten Weg nach unten. An der dünnsten Stelle die Wand sprengen. Nun wieder hoch und über den linken Weg nach unten. Dort den Schlüssel nehmen, mit dem wieder in den Raum mit dem Dieb und dann nach links. Hier die Tür aufschließen und die Öllampe nehmen. Nicht von der Schlange erwischen lassen! Nun wieder nach rechts und hoch. Vor dem Angriff der Bienen Licht machen und den Bienen ausweichen. Das Brett nehmen, eine Brücke über den Fluß bauen und rechts den Stock (Flöte?) nehmen. Nun einmal nach unten und nach rechts. Die Schlange betäuben (Stock, Flöte) und den Schatz nehmen. Man kann die Gegenstände durch Berühren nehmen, aber immer nur einen! Will man ihn an gewünschter Stelle anwenden, den Feuerknopf drücken. Bewirkt er nichts, ertönt ein Gong und der Gegenstand verschwindet.

THE SEVEN KEYS

Man muß sieben Schlüssel finden. Die Reihenfolge der Zeitreisen ist unwichtig. Man erhält dann ein Paßwort. Alle sieben Paßwörter muß man zum Schluß nacheinander eingeben, dann kommt ein Nachtrag. Hier sind die Paßwörter für die einzelnen Zeitreisen:

  • Reise 1 = ANCH,
  • Reise 2 = ATARI,
  • Reise 3 = BOMBE,
  • Reise 4 = UNGA,
  • Reise 6 = KNOCHEN,
  • Reise 6 = EHRE,
  • Reise7 = ATOME.

CHEATS:


 

1. Megablast:

Im Titelbild ‚Have Fun‘ eingeben. Es erscheint ein tolles Cheat-Menu. Bei Leben die Zahl 19 eintippen = UE Leben.

 

2. Mission (Shark):

Ergänzung zum Freezer Poke (Sonderdisk Nr. 11). Im Titelbild J.PELC eintippen= UE Leben.

 

3. TacTic (von Uwe Hartwig):

Die ersten drei Levelcodes sind:
10: Mentos,
20: Marzena,
30: Level up.

 

4. Mission Zircon (von T.-P.Müller):

Anzahl Leben während des Spiels: Register $6C0 Leben (= n) bei Spielstart (normal: 3) Sektor 342, Byte: n
UE Leben ein (n = 173 dez) oder aus (n = 206 dez) Sektor 350, Byte 96:n.

 

5. Monster Hunt (von T.-P. Müller)

Zusätzliche Cheats zum Cheat für 255 Leben in Nr. 29

UE Zeit Editor: Sektor 262 (dez), Byte Pos. 35 ($24) in $00 ändern.

Unverwundbarkeit Editor: Sektor 279 (dez), Byte Pos. 121 oder 122 $79 von F0 in EA und Byte Pos. 122 oder 123 $7A von 03 in EA ändern.
Die Unverwundbarkeit hat gegenüber 255 Leben den Vorteil, daß man hier keine Atari-Zeichen und Bonuspunkte verliert. Aber darauf achten, daß man durch die Bonuspunkte nicht mehr als 9 Leben erhält, sonst kommt der Hinweis ‚zuviel Leben‘ und das Spiel beginnt von vorn. Es gibt 22 Level, aber einige wiederholen sich später immer wieder. Da keine Gefahr mehr besteht, ist das Spiel mit diesem Cheat langweilig und nur zum Ansehen aller Level geeignet

 

6. DONALD

Die Run-and-Jump-Fans werden dieses umfangreiche Spiel bestimmt schon haben und sich über die nachfolgenden Cheats freuen.

Cheat 1:
Editor: Sektor 171, Byte Pos. 59 von 05 in FF ändern = 255 Leben.
Freezer: Adresse $ 0406: Leben
(Wer das Spiel kennt, wird verstehen, warum ich diesen Cheat sofort gesucht habe!!)

Cheat 2:
Damit man nicht 40!!! Level durchspielen muß, um endlich auf den Mond zu gelangen, hat Thomas Rosanski diese Änderungen gefunden: (unbedingt Sicherheitskopie!)

Sektor $16A (dez 362), Byte Pos. 60 ($3B) von 44 in 45 ändern, Sektor $16A (dez 362), Byte Pos. 76 ($4B) von 45 in 44 ändern, Sektor $16B (dez 363), Byte Pos. 60 ($3B) von 44 in 45 ändern, Sektor $16B (dez 363), Byte Pos. 28 ($IB) von 45 in 44 ändern.

Die geänderte Diskette laden und HIMALAYA anwählen. Man ist jetzt auf dem Mond. Aber HIMALAYA kann man jetzt   n i c h t   mehr direkt anwählen!

Cheat 3 (ebenfalls von Thomas Rosanski):
Da man mit dieser Änderung im 6. Level nicht zum letzten Ei oben rechts kommt (von unten kann man es mit einem Sprung nicht erreichen, geht man oben von links flach rechts zum Ei, fällt man immer in der Mine nach unten und eine andere Möglichkeit haben wir bisher nicht gefunden), kann man sich so helfen: Im Sektor $34A (dez 842) die Bytes $66 und $67 von 0B in 74 ändern.
Man fällt jetzt nicht mehr nach unten. Ob man in der normalen Version diese Schwierigkeit auch hat, weiß ich nicht, da ich noch keine Zeit hatte, alle 40 Level durchzuspielen. Eine Abspeicher-Funktion wäre bei der Vielzahl der Level sinnvoll gewesen! Auch ein Codewortsystem für die Level der einzelnen Landschaften.

Noch ein Hinweis:
In der PD-Bibliothek könnt ihr auf der PD Nr. 28 jede Menge Tips und Tricks für „Alternate Reality“ von Datasoft finden. Für nur DM 10.- bekommt ihr vier Diskettenseiten, dazu noch sieben Lagepläne auf Papier! Wer dieses Spiel hat und nicht weiterkommt, sollte zugreifen.

Ein Tip (der ABBUC kennt ja Gott sei Dank keinen Konkurrenzkampf):
Bei USER-MAG kann man neuerdings die beiden Spiele „The City“ und „The Dungeon“ erwerben. Ich will damit keine Reklame für diese Firma machen, sondern allen helfen, die diese Rollenspiele schon lange suchen (damit das ganz klar ist!).

So, das war’s mal wieder. Ich hoffe, mein Griff in die Trickkiste hat Euch gefallen und grüße alle mit einem

Good Byte

Waltraud

 

Murphy & Co

Regel über die Perversion der Natur:

  • Man kann nicht erfolgreich vorausbestimmen, auf welche Seite des Brotes die Butter kommt.

 

Gesetz der selektiven Schwerkraft:

  • Ein Ding fällt so zu Boden, daß es den größtmöglichen Schaden anrichtet

 

Jenning’s Folgerung:

  • Die Möglichkeit, daß ein Marmeladenbrot mit der Marmeladenseite nach unten auf den Boden f
    ällt, ist direkt proportional zu den Kosten des Teppichs.

 

Klipstein’s Folgerung:

  • Die empfindlichsten Bauelemente werden zuerst herunterfallen.

 

Anthony’s Werkstattgesetz:

  • Jedes heruntergefallene Werkzeug rollt mit Sicherheit in die hinterste, dunkelste Ecke der Werkstatt.

Zusatz:

  • Auf dem Weg in diese Ecke trifft es auf jeden Fall erst einmal den großen Zeh.

 

Johnson’s erstes Gesetz:

  • Wenn eine mechanische Vorrichtung ausfällt, dann passiert das gerade im unangenehmsten Augenblick.

 

Schmidt’s Gesetz:

  • Wenn man mit einem Maßstab lange genug mißt, zerbricht er.

 

Fudd’s Gesetz der Opposition:

  • Wenn man etwas nur hart genug anschlägt, wird es umfallen.

 

Cahn’s Axiom:

  • Wenn nichts mehr geht, sollte man einfach in der Bedienungsanleitung nachlesen.

 

Murphy’s Gesetz zur Forschung:

  • Genügend Forschung wird ganz bestimmt die eigenen Theorien unterstützen.

 

Maier’s Gesetz:

  • Wenn die Fakten nicht mit der Theorie übereinstimmen, müssen die Fakten vernichtet werden.

Folgerungen:

  • Je umfassender eine Theorie ist, desto besser ist sie.
  • Ein Experiment muß nochmals überdacht werden, wenn mehr als 50 % der erzielten Messungen die aufgestellte Theorie unterstützen.

 

Williams und Holland’s Gesetz:

  • Wenn man genug Daten gesammelt hat, läßt sich mit statistischen Methoden alles beweisen.

 

Edington’s Theorie:

  • Die Zahl der verschiedenen Hypothesen zur Erklärung eines bestimmten biologischen Problems ist umgekehrt proportional zum darüber vorhandenen Wissen.

 

Peer’s Gesetz:

  • Die Lösung für ein Problem verändert die Art des Problems.

 

Young’s Gesetz:

  • Alle großen Entdeckungen wurden aufgrund eines Fehlers gemacht.

Folgerung:

  • Je größer das Kapital, desto länger dauert es, die Fehler zu machen.

 

Hoare’s Gesetzmäßigkeit großer Probleme:

  • Hinter jedem großen Problem steckt ein kleineres, das nur darauf wartet, hervortreten zu können.

 

Fett’s Labor-Gesetz:

  • Wiederhole nie einen erfolgreich verlaufenen Versuch.

 

Wyszowski’s erstes Gesetz:

  • Kein Experiment ist reproduzierbar.

Der Sinnlosigkeitsfaktor:

  • Kein Experiment ist vollkommen unbrauchbar; es kann immer noch als schlechtes Beispiel verwendet werden.

 

Parkinson’s sechstes Gesetz:

  • Der Fortschritt der Wissenschaften verhält sich umgekehrt proportional zur Anzahl der entsprechenden Veröffentlichungen in Fachzeitschriften.

 

Meskimen’s Gesetz:

  • Man hat nie genug Zeit, um etwas richtig zu machen, jedoch man hat immer Zeit, etwas nochmal zu machen.

 

Heller’s Gesetz der Hierachiologie:

  • Der erste Mythos des Managements ist, das es überhaupt existiert.

Johnson’s Folgerung:

  • In Wirklichkeit weiß niemand, was gerade wo in einer Organisation abläuft.

 

 

Dieses ABBUC Magazin erschien ursprünglich als Papierbeilage. Scan, OCR, Digitalisierung und Aufbereitung: Andreas Bertelmann