Posts by M. J.

Quote from LuLe

ohne Timer und Stress die Welten "frei" erkunden

Das ist definitiv die Beschreibung von "Mercenary".

Außerdem kann man bei den meisten Rollenspielen (z. B. Ultima IV + V, Bard's Tale III, Dragon Wars...) die Welt streßfrei erkunden in der Hinsicht, daß diese Spiele nicht wirklich in Echtzeit ablaufen, jederzeit angehalten werden können und die Anfangskämpfe sehr leicht zu absolvieren sind. Abzuraten ist jedoch von den beiden ersten Titeln der Bard's Tale-Reihe, da man dort zu Beginn aufgrund einer unausgewogenen Spielmechanik sehr leicht sterben kann.

Das Textadventure-Genre ist natürlich das Genre, das per Definition schon streßfrei abläuft, da das Spiel in der Regel auf die Eingabe des Spielers wartet. Diesbezüglich gibt es einige Spiele, die über große Welten verfügen, und mit denen man eine ganze Weile Spaß haben kann.

Und falls es gelegentlich ein bißchen Action sein darf, so würde ich noch "Space Rogue" empfehlen. Anders als bei "Elite" gilt es hierbei nicht nur, von Planet zu Planet zu fliegen und dabei zu handeln, sondern auch die Raumstationen rollenspielmäßig zu erkunden und viele Missionen durchzuführen.

Quote from Snoopy

warum wird dieser Bug nicht gefixt?

Leider enthält die Version 2.0 noch weitere Bugs.

<Senf>

1.) Zu dem Vergleich von 3d-Spielen:

Das erwähnte 3d-Programm für den C64 basiert auf der FreeScape-Engine, deren Routinen sehr langsam arbeiten. Anders als 3d-Programme wie "Elite", "Star Wars", "Mercenary" etc verwendet die Engine keine Beschleunigungsmethoden wie z. B. Tabellen für Multiplikation oder Division. Im Gegenteil, der Code ist teilweise extrem schlecht und verbraucht mehr Takte als tatsächlich nötig. Für einen fairen Vergleich sind Spiele der "FreeScape"-Reihe wie z. B. "Driller" daher nicht geeignet. Hierzu müßte man eher ein Programm wie "Mercenary" (Atari: 64 kb Hires-Version) heranziehen, welches auf beiden System sehr ähnlich aufgebaut ist. Daran ließe sich noch am ehesten ermitteln, ob der Atari gegenüber dem C64 einen erkennbaren/spürbaren Vorteil in Hinblick auf Geschwindigkeit hat.

2.) 64 kb vs. 48 kb:

Ich denke nicht, daß 64 kb zwingend notwendig sind für gute Spiele.

a) Das Basic des C64 benutzt - wie bekannt - den Ram-Bereich von $a000-$ffff (24 kb) nicht.

b) Die ersten Modulspiele für den C64 konnten ebenfalls auf den oberen Speicher nicht zugreifen.

c) Auch spätere Spiele mieden oft das Ram im IO-Bereich $d000-$dfff, weil es schwerer zugänglich war (Ausschalten des Interrupts + wiederholtes Umsetzen von $1). Die oben erwähnte FreeScape-Engine z. B. belegt diesen Rambereich bis auf $df00 für eine Kopie der Zeropage nicht. (Ja, man hätte dort eine Multiplikationstabelle anlegen können. Hätte... hätte...)

d) Im Vergleich laufen sehr viele Spiele auf dem AppleII nur mit 48 kb, obgleich dieser mangels Zeichensatzmodus auf die Speicherplatz raubende Bitmapdarstellung und vorab bitweise geshiftete Shapes anstelle von einfachen Sprites zurückgreifen muß. Hier eine kleine Auswahl an 48 kb-Spielen: Bandits, Burger Time, Choplifter, Drol, Elite, Falcons, Frogger, Ghostbusters, Hard Hat Mack, Karateka, Moon Patrol, Situation Critical, Spy vs. Spy sowie diverse Abenteuerspiele (The Mask of the Sun, Gruds in Space, Masquerade, Death in the Caribbean oder die HiRes Adventure von SierraOnline). Die 64 kb des C64 wurden erst dadurch wichtig, weil viele Software-Hersteller unbedingt OneFiler für die Datasette verkaufen wollten, anstelle Daten von einer langsamen und teuren Floppy nachzuladen.

In der Rückschau kommt es mir so vor, als wäre der Atari in der Evolution der Homecomputer an etwas ganz anderem gescheitert. Er war zwar einer der ersten 6502 basierten Computer, doch war in den ersten Jahren seiner Produktion (1979-1982) das Wissen um eine sowohl effiziente als auch effektive Nutzung des Prozessors und der jeweils umgebenden Hardware noch nicht so sehr vorhanden. Dies läßt sich auch an Spielen z. B. für den AppleII oder VC20 erkennen. In einem direkten Vergleich konnte er sich daher nicht ausreichend von der Konkurrenz absetzen, da im Grunde genommen die Spiele Anfang der 80er auf allen Systemen im Vergleich zu späteren Titeln ... sagen wir mal ... nicht so beeindruckend aussahen. Der Atari hatte seine Hochzeit bereits überschritten, als die Softwarehäuser anfingen, ausgefeilte Spiele zu produzieren, und leider gehören diejenigen von Lucasfilm ("The Eidolon", "Koronis Rift", "Rescue on Fractalus") auch zu den letzten, die immerhin zeigen durften, was man aus der Kiste alles rausholen kann. Hätte solch ein KnowHow schon 1982 bestanden, wären die Spiele für den Atari so beeindruckend gewesen, daß es die Konkurrenz aus dem Hause Commodore viel schwerer gehabt haben dürfte. Von daher kann ich denjenigen zustimmen, die vermuten, daß die schlechte Informationspolitik von Atari dazu geführt hat, daß der Rechner im Verhältnis zum C64 im Nachteil war. Mit besserer Software wäre das wahrscheinlich so nicht passiert.

</Senf>

Quote from paranoid64

lda page
clc
adc #$01
and #$04
sta page

Ich befürchte, sowohl die Verundung mit #4 (müßte 3 sein) als auch der Wert an sich ohne die zusätzliche Addition von #'1' dürfte so nicht funktionieren. Probiere es vielleicht mal hiermit:

1. Unterirdische Gänge

kommen gegen Ende vor, wenn man nach den Diamanten sucht.

2. Satellit

Die Kommunikation mit der Zentrale verläuft über Satellit, und die Firma, für die der Spieler arbeitet, heißt NSRT (National Satellite Resource Technology).

3. Nachtsichtgerät

Genannt "goggles" werden im Verlauf des Spiels verwendet.

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

Dieses Gebiet ist gleichzeitig der Namensgeber des Spiels.

5. Ein Fortbewegungsmittel mit einem großen und einem kleinen Rotor rettet Menschenleben.

Naja, ein Helikopter halt. Taucht aber erst gaaaaanz am Ende in der Abschlußsequenz auf. Und stellt den Spieler unweigerlich vor die Frage: Warum um alles in der Welt latsche ich hier die ganze Zeit quer durch den Dschungel und schlage mich mit Rebellen und Einheimischen sowie anderen Dingen herum, wenn dieser Typ da einfach so mit dem Hubschrauber hier hinfliegen kann... Logik????

6. Es gibt drei Schwierigkeitsstufen.

Außergewöhnlich für dieses Spielgenre, aber wahr. Drei leicht verschiedene Lösungswege.

7. Der Autor ist recht bekannt.

Er heißt Michael Crichton, laut Wikipedia ein "US-amerikanischer Schriftsteller, Drehbuchautor, Regisseur, Arzt und Filmproduzent". Er hat das Spiel tatsächlich zuerst unabhängig von dem Softwarehaus Telarium (bzw. Trillium) selbst entwickelt. Als Telarium auf ihn zutrat mit dem Angebot, als Adventure-Autor tätig zu werden, präsentierte er zum großen Erstaunen sein Spiel.

8. Vor allen Dingen für zahlreiche Katastrophen.

u. a. "Andromeda", "Westworld", "Twister" und "Jurassic Park".

9. Der Name des Autors ist in diesem Thread an anderer Stelle bereits gefallen.

Irgendsoein beklopptes Forumsmitglied hat ihn bereits erwähnt.

10. Angeblich wurde das Spiel mehr als 100.000 mal verkauft, größtenteils für den C64.

So ist es. Das Spiel gilt als finanzieller Erfolg.

11. Es gibt aber keinen Eintrag im C64-Wiki.

Da könnte vielleicht mal jemand nachhelfen...

12. Man begibt sich auf eine lange Reise.

Man startet im gemütlichen Büro, fliegt dann zu einem Institut und dann ab in den Dschungel, den man durchqueren muß, um an das Ziel zu kommen.

13. Es stirbt sich sehr schnell.

Oftmals genügt ein Schritt in die falsche Richtung, und man darf neustarten.

14. Und trifft viele verschiedene Charaktere.

Unter anderem auf Rebellen und Einheimische.

15. Guck mal, wer da spricht.

Ein lebendiger Papagei. John Cleese hätte Freude an ihn.

16. 969 072

Sind die Codes für die Satellitenkommunikation.

17. Polly will keinen Cracker, aber P.., eine Frucht.

Paco ist der sprechende Papagei, der einem auf Anfrage hin an einigen Stellen Tips gibt.

18. "Der König von Siam" hat mit dem Autor mal zusammengearbeitet.

"Der König von Siam" war die Paraderolle von Yul Brynner. Man kennt ihn auch als schwarz gekleideter Revolverheld aus dem Film "Die glorreichen Sieben". Diese Rolle griff er Jahre später selbstironisch neu auf in dem Film "Westworld", doch dieses Mal als ein von einem Computervirus infiszierter bösartiger Killerroboter. Michael Crichton schrieb zu dem Film das Drehbuch und führte Regie.

Die Lösung lautet also:

Amazon

Und gewonnen hat -trb-. Gratuliere! Ich für meinen Teil verabschiede mich für heute bzw. für dieses Jahr und wünsche Euch Allen einen

Guten Rutsch ins neue Jahr!
Bleibt bitte gesund und munter.

Quote from daimansion

ich bin raus weil mir echt nix einfällt

Tip: Man kann das Spiel durchaus allein anhand der allgemeinen, d. h. nicht inhaltsbezogenen Hinweise erraten, auch wenn man es nicht kennt.

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

5. Ein Fortbewegungsmittel mit einem großen und einem kleinen Rotor rettet Menschenleben.

6. Es gibt drei Schwierigkeitsstufen.

7. Der Autor ist recht bekannt.

8. Vor allen Dingen für zahlreiche Katastrophen.

9. Der Name des Autors ist in diesem Thread an anderer Stelle bereits gefallen.

10. Angeblich wurde das Spiel mehr als 100.000 mal verkauft, größtenteils für den C64.

11. Es gibt aber keinen Eintrag im C64-Wiki.

12. Man begibt sich auf eine lange Reise.

13. Es stirbt sich sehr schnell.

14. Und trifft viele verschiedene Charaktere.

15. Guck mal, wer da spricht.

16. 969 072

17. Polly will keinen Cracker, aber P.., eine Frucht.

18. "Der König von Siam" hat mit dem Autor mal zusammengearbeitet.

Quote from Tale-X

Und MJ hat nicht von Kontinent gesprochen, was die Möglichkeiten erweitert.

Wie sagte schon Loriot: "Das ist fein beobachtet."

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

5. Ein Fortbewegungsmittel mit einem großen und einem kleinen Rotor rettet Menschenleben.

6. Es gibt drei Schwierigkeitsstufen.

7. Der Autor ist recht bekannt.

8. Vor allen Dingen für zahlreiche Katastrophen.

9. Der Name des Autors ist in diesem Thread an anderer Stelle bereits gefallen.

10. Angeblich wurde das Spiel mehr als 100.000 mal verkauft, größtenteils für den C64.

11. Es gibt aber keinen Eintrag im C64-Wiki.

12. Man begibt sich auf eine lange Reise.

13. Es stirbt sich sehr schnell.

14. Und trifft viele verschiedene Charaktere.

15. Guck mal, wer da spricht.

16. 969 072

17. Polly will keinen Cracker, aber P.., eine Frucht.

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

5. Ein Fortbewegungsmittel mit einem großen und einem kleinen Rotor rettet Menschenleben.

6. Es gibt drei Schwierigkeitsstufen.

7. Der Autor ist recht bekannt.

8. Vor allen Dingen für zahlreiche Katastrophen.

9. Der Name des Autors ist in diesem Thread an anderer Stelle bereits gefallen.

10. Angeblich wurde das Spiel mehr als 100.000 mal verkauft, größtenteils für den C64.

11. Es gibt aber keinen Eintrag im C64-Wiki.

12. Man begibt sich auf eine lange Reise.

13. Es stirbt sich sehr schnell.

14. Und trifft viele verschiedene Charaktere.

15. Guck mal, wer da spricht.

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

5. Ein Fortbewegungsmittel mit einem großen und einem kleinen Rotor rettet Menschenleben.

6. Es gibt drei Schwierigkeitsstufen.

7. Der Autor ist recht bekannt.

8. Vor allen Dingen für zahlreiche Katastrophen.

9. Der Name des Autors ist in diesem Thread an anderer Stelle bereits gefallen.

10. Angeblich wurde das Spiel mehr als 100.000 mal verkauft, größtenteils für den C64.

11. Es gibt aber keinen Eintrag im C64-Wiki.

Quote from Endurion

H.E.R.O.??

Wegen der unterirdischen Gänge und dem Rotor und geretteten Menschen...? Hmm.... Klingt logisch, ist es aber leider auch nicht.

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

5. Ein Fortbewegungsmittel mit einem großen und einem kleinen Rotor rettet Menschenleben.

6. Es gibt drei Schwierigkeitsstufen.

7. Der Autor ist recht bekannt.

8. Vor allen Dingen für zahlreiche Katastrophen.

9. Der Name des Autors ist in diesem Thread an anderer Stelle bereits gefallen.

Quote from Tale-X

Hast Du mal ein Link zu dem Spiel?

Nur Spaß. Spar Dir das neue Rätsel für später.

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

5. Ein Fortbewegungsmittel mit einem großen und einem kleinen Rotor rettet Menschenleben.

6. Es gibt drei Schwierigkeitsstufen.

Quote from Tale-X

Fort Apokalypse?

Tut mir leid, das war es auch nicht.

Tja, da leider, leider niemand das Spiel erraten konnte, folgt hier nun die Auflösung: Es handelt sich bei dem gesuchten Spiel (natürlich) um den allseits bekannten und beliebten Klassiker "Chophacker" von Br0dervision.

Und da Tale-X am nächsten dran war, darf er nun das nächste Rätsel stellen.

Quote from daimansion

Exis - The Planet far away vielleicht?

Bedaure, das ist es auch nicht.

Also wenn es keiner weiß, dann werde ich lösen...

Quote from Endurion

Hacker?

Leider nein.

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

5. Ein Fortbewegungsmittel mit einem großen und einem kleinen Rotor rettet Menschenleben.

Quote from -trb-

Um's nicht zu kompliziert zu machen, hänge ich dir die Datei hier an.

Vielen Dank!

Quote from Tale-X

Gibt ja nicht so viele Spiele mit coolem Nachtsichteffekt auf dem C64... welches wird es wohl sein

Nun, wenn Du meinst, das richtige Spiel zu kennen, darfst Du gerne mal einen Lösungsversuch wagen.

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

4. Ein großes Gebiet auf der südlichen Erdhalbkugel, dessen Name mit "A" anfängt, spielt eine wichtige Rolle.

Quote from Tale-X

ich wollte ja noch unbedingt den Käse unterbringen, der hatte hervorragende Flugeigenschaften...

Jau, der Käse... War der fliegende Käse eigentlich Teil von "Escape from Targ" oder "The Second City"...?

Quote from -trb-

Ob das gesuchte Spiel wohl Mercenary Adventure ist?

Oh, das kannte ich noch gar nicht. Wo kann man das denn runterladen (ftp geht nicht mehr)?

Hier noch einmal die ersten 3 Hinweise:

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

Wie? Es geht noch weiter..? Ach so, ich hatte nicht gelöst...

Tale-X : Wieviel gibst Du mir, damit ich löse? Meine Söldnerseele verlangt ausreichend Geld, damit ich die Flucht antreten kann...

Hier noch ein paar Tips kostenlos hinzu:

- Das Spiel erschien auch auf deutsch.

- Es gibt ein Add-On, das um einiges schwieriger ist als das Original.

- Im Add-On kann man schnell im Gefängnis landen.

- Ein Schwager bereitet Probleme, oder der Spieler ihm.

- Es gibt mehr als einen Weg.

- Ohne zusätzliche Power kommt man nicht weit bzw. hoch.

- Man sollte nur auf den Richtigen schießen.

- Mit Aufzügen geht es auf und ab und mit Transportern irgendwohin.

- Für den 6502 technisch eine Meisterleistung.

- Der Programmierer Paul Woakes ist leider vor einiger Zeit verstorben.

- Die Nachfolgespiele erschienen nicht mehr auf dem C64, sondern auf AtariST und Amiga und hießen "Mercenary II: Damocles" sowie "Mercenary III: The Dion Crisis". Beide sehr zu empfehlen.

- Auf dieser Seite gibt es sehr viele Informationen zu allen Teilen der Serie inklusive einen Port aller Spiele auf den PC.

Ausgerechnet eines meiner Lieblingsspiele...

Ich darf mal aus Indiana Jones Teil 2 zitieren: "Holy smoke... Crash landing..."

1. Unterirdische Gänge

2. Satellit

3. Nachtsichtgerät

Nun, daß deutsche Adventure mit Infocom und Co nicht mithalten können, hat einen einfachen Grund: Sie wurden zumeist von Schülern oder jungen Erwachsenen in der Freizeit als Hobbyprojekt in Basic geschrieben. Dadurch ergeben sich automatisch technische Beschränkungen auch hinsichtlich der Textmenge, aber natürlich ebenso in bezug auf die Erzählung an sich. Nicht jeder Basicprogrammierer ist schließlich auch ein guter Geschichtenerzähler. Bei professionellen Firmen (Infocom, Magentic Scrolls,Trillium etc) haben nicht nur ausgebildete Programmierer am Code gewerkelt, sondern es wurden fürs Erzählen teilweise auch Leute mit schriftstellerischem Hintergrund einbezogen.

Was den Amiga/AtariST anbelangt, so war zu der Zeit mit Ausnahmen wie Magnetic Scrolls der Markt für Adventures bereits so gut wie tot. Ohnehin war der deutsche Markt sehr klein, so daß es sich für professionelle Softwarehäuser kaum lohnte, von sich aus ein Adventure zu entwickeln. Infocom und Magnetic Scrolls haben zusätzlich mit ihrem hohen Niveau der Satzanalyse einen Maßstab gesetzt, der aufgrund der komplizierteren Struktur der deutschen Sprache damals mit herkömmlichen Mitteln nicht erreichbar war, was die Motivation zur Entwicklung ausbremste. Das Aufkommen der Point&Click-Adventure gab dem Textadventure dann den Rest.

Auf älteren Computern wie dem C64 stand ein Programmierer zudem schon zu Beginn vor der Frage, wie er mit der deutschen Schreibung in Form der Umlaute ä. ö. ü und dem ß umgehen soll, da diese von den Rechnern weder bei der Tastatureingabe noch der Zeichenausgabe nativ unterstützt wird. Der Programmierer mußte somit, wenn er tatsächlich vom optischen Eindruck her lesbare Texte gestalten und nicht auf die ae, oe, ue und ss-Schreibweise zurückgreifen wollte, stets seine eigene Zeichenroutine mit eigenem Zeichensatz entwerfen und stand dann auch vor dem Problem, wie er seine deutschen Texte mit Umlaut eingeben soll, d. h. er brauchte bei längeren Texten dafür eigentlich auch noch einen eigenen Editor. Die Einstiegshürde in die Entwicklung von komplexeren Adventures war somit recht groß und vielen Hobbyisten zu umständlich, besonders wenn es sich um ein Projekt in Basic handelte.

Bezüglich der genannten Kriterien für ein Adventure fällt übrigens auf, daß Punkt 4 "Rätsel meist nur von der Sorte "Gegenstand A finden und in Location B benutzen"" quasi das Grundprinzip der Adventure beschreibt. Spiele, die nicht auf diesem Prinzip beruhen, sind mir nicht bekannt. Ich nehme daher an, daß Du meinst, ein Spiel sollte diesen Mechanismus nicht so deutlich aufweisen, doch das ist etwas schwammig. Wäre es vielleicht möglich, daß Du ein paar Beispiele englischsprachiger Adventure benennst, damit man sich besser vorstellen kann, was genau Dir vorschwebt?

Interessante Diskussion hier.

<Senf>

1.) Natürlich ist Pascal standardisiert. Da gibt es zum einen den "Report" von Wirth selbst (1974) sowie nachfolgend die internationalen Standardisierungen von 1983 und 1989 (s. Wikipedia). Ein Compiler, der diese Standards nicht erfüllt, ist kein Pascal-Compiler.

2.) Zu dem Standard gehört selbstverständlich die Möglichkeit eines rekursiven Aufrufs von Unterprogrammen (Prozedur oder Funktion), Pascal geht schließlich auf Algol zurück und wurde von Wirth als Lehrsprache entworfen. Rekursion ist aber unbedingter Teil dieser Lehre. Compiler können als Option zur Codeoptimierung die Möglichkeit anbieten, Rekursion nicht zu gestatten, doch ist dies halt nur optional und nicht der Defaultwert.

3.) Pascal geht über das Konzept der lokalen Variablen hinaus, indem es definiert, daß verschachtelte (lokale) Prozeduren auf die lokalen Variablen der übergeordneten Prozeduren wie globale Variablen zurückgreifen können. Beispiel:

Dies bedeutet, daß beim Aufruf von b unklar ist, wo genau auf dem Stack sich der Wert von "v_a" befindet. Im ersten Fall liegt er in dem Stackframe von a, der sich direkt oberhalb des Stackframes von b befindet. Im zweiten Fall liegt jedoch dazwischen noch der Stackframe von c.

Um den Speicherort von "v_a" zu ermitteln, muß während der Programmausführung bei Zugriffen auf "v_a" der Stack Frame für Frame abgeklappert werden bis zum Stackframe von a, in dem sich der Wert von "v_a" befindet. Wird nun b rekursiv 1000 mal aufgerufen, werden 1000 Stackframes für b angelegt, die bei einem Zugriff auf "v_a" allesamt bei der Suche nach dem Stackframe für a durchlaufen werden müssen.

4.) Ausschnittstypen sind keine eigenständigen Datentypen,. Eine Deklaration wie

sorgt nicht dafür, daß die Variable "byte" weniger Speicher verbraucht oder Operationen auf dieser Variable anders durchgeführt werden als bei "normalen" Integervariablen. Es bedeutet lediglich, daß bei Schreibzugriffen der Wertebereich überprüft und bei Nichtübereinstimmung ein Laufzeitfehler generiert werden soll. Ein Compiler kann diese Information dazu nutzen, Code zu optimieren, dafür vorgesehen ist diese Deklarierung jedoch nicht. Diese Bereichsüberprüfung wurde ähnlich wie die Zugriffstests beim Varianten-Record in den meisten Compilern nicht umgesetzt, d. h. bei Schreibzugriffen wird nicht automatisch getestet, ob der Wert den spezifizierten Anforderungen genügt. Wirth selber hat die Ausschnittstypen in seinen späteren Praxis orientierten Sprachen Modula 2 und Oberon auch entfernt.

5.) Die Verfolgung eines Programmflusses ist keine triviale Angelegenheit. Zwar läßt sich eine eingeschränkte Dead-Code-Optmierung in bezug auf unerreichbaren Code relativ leicht durchführen, indem man alle Unterroutinen, die nicht verwendet werden, aus dem Zwischencode des Compilers entfernt. Dies ergibt jedoch noch keine Aussage darüber, wie die Verschachtelung aussieht.

Erschwert wird das Nachvollziehen des Programmablaufs zusätzlich durch die Verwendung von Prozedur-/Funktionsvariablen. Hierbei wird die Adresse einer Unterroutine in einer Variablen gespeichert und irgendwann später im Verlauf des Programms für einen Aufruf der Unterroutine verwendet. Dabei kann die Variable an andere Programmteile weitergereicht und dort auch verändert werden. Der Programmverlauf ist somit nicht statisch zur Compilezeit direkt ermittelbar. Man könnte auch sagen, daß Prozedurvariablen eine Art Selbstmodifikation des Codes darstellen, obgleich sie nicht direkt auf den Prozessorbefehl einwirken, sondern nur indirekt über Sprungzeiger.

Man stelle sich folgenden Fall vor:

Prozedur A verwendet eine Prozedurvariable, um B aufzurufen. Gleichzeitig kann aber auch C direkt B aufrufen. Die Aufrufe sind (zunächst) nicht rekursiv. Man könnte daher annehmen, daß bei einer Optimierung die lokalen Variablen von B temporär an einer festen Stelle im Speicher stehen, die von weiteren Prozeduren auf dem gleichen Aufruflevel überschrieben werden können. Wenn also A B aufruft, können die Variablen von B direkt hinter die von A gelegt werden, denn B verfügt über den Aufruflevel 2 (A wäre 1). Ruft jedoch A C auf und C wiederum B, so müßten sie hinter C liegen, denn nun verfügt B über den Level 3. Bei der Verwendung von B über eine Prozedurvariable ist jedoch der Aufruflevel von B nicht bestimmt. Man müßte also für B sicherheitshalber einen eigenen Speicherbereich definieren, der garantiert nicht von anderen Prozeduren verwendet wird.

Wenn man jetzt aber noch mitbedenkt, daß A an B eine Prozedurvariable übergeben kann, die dann nicht nur C aufrufen kann, sondern auch A oder B selbst, so erkennt man hier das Potential für eine versteckte Rekursion, die mit einfachen Methoden nicht entdeckt werden kann. Möchte man dies verhindern, muß der Compilerschalter auch dafür sorgen, daß Prozedurvariablen nicht mehr erlaubt sind. Doch dann kommt man zu der Frage, ob eine Sprache mit dieser Einschränkung noch Pascal ist.

Und nur mal so nebenbei:

Persönlich habe ich nie verstanden,, warum man sich in der C64-Szene so sehr gegen die Verwendung einer Hochsprache auf P-Code-Basis sträubt. Hier scheint es nur die Alternativen "Basic", "C" und "Assembler" zu geben, d. h. die einzig wirklich brauchbare Hochsprache ist C, wobei jedoch zwar schneller, aber speicherintensiver Assemblercode generiert wird. Für die zahlreichen Fälle, in denen es nicht so sehr auf Geschwindigkeit ankommt wie z. B. Rollenspiele, Wirtschafts- oder Strategiespiele, Tools wie Spriteeditoren etc, wäre eine Sprache wie Pascal mit einem Compiler, der (schnellen) P-Code erzeugt, eine sinnvolle Alternative hinsichtlich Programmentwicklung und -wartung. Leider scheint man sich aber in C64-Kreisen an den drei erwähnten Sprachen festgebissen zu haben, obgleich sich mit einer Sprache wie UCSD-Pascal (meiner Erfahrung nach) so manches Projekt einfacher realisieren ließe.

</Senf>