Atari im Grafik-Transfer-System

 

Hires Transfer

Beim Gedankenaustausch mit Atari-Andreas kam ein altes Projekt von mir wieder hoch: HRT, die Verschlüsselung von Grafiken als ASCII-Zeichen. Hatte ich bisher nicht so viel Ahnung vom inneren Aufbau der Ataris, wollte ich das jetzt einmal probieren. Zu meiner Freude stellte ich fest, dass die Reihenfolge der Grafik­Bytes auf dem Atari schön linear ist, so bequem kannte ich es bisher nur vom ZX81.

Info: Grafik aus Textdatei

Zwar hatte ich bisher nicht BasiCode dafür verwendet, obwohl die beiden Sachen dem gleichen Grundgedanken folgen - aber jetzt war mal die Zeit reif dafür. Die BasiCode-Festlegungen verbieten maschinenspezifische Sachen (wie das POKEn in Speicherbereiche) nicht von vornherein, halten jedoch dazu an, sie in einem bestimmten Zeilenbereich (20000-24999) unterzubringen und in REM-Zeilen ausführlich zu erklären, damit User anderer Computer dort ihre entsprechenden Routinen erstellen können. So muss ich mich nicht erst in ein anderes Basic hineinfuchsen, sondern kann in einer mir vertrauten Umgebung arbeiten. Es gelang auch recht gut und Andreas stellte es im ABBUC-Forum vor, von dort hagelte es aber Hinweise, das HRT-Format sei nicht stark verbreitet ... das will ich gar nicht abstreiten ;-) ... und es gäbe doch schon Lösungen, Grafiken in Text-Verschlüsselung zwischen unterschiedlichen Computern auszutauschen. Solche Antworten buche ich aber unter der Rubrik "Mit Kanonen auf Spatzen schießen" ab, es geht hier um Sachen auf viel ressourcenreicheren PCs, ein einziges Pixel wird schon mit mehreren Buchstaben verschlüsselt. Kriegt man so ein Instrumentarium in einem 8-bit-Computer und auf 180- oder 360-KB-Disketten unter?

Menü: Grafik aus Textdatei

Leider lassen sich unter Andreas Grafs BasiCode für 8-bit-Ataris (das eigentlich ein eigenständiges Basic ist) die fertigen Bilder nicht speichern, Binärdateien sind in dem "Computer-Esperanto" nicht vorgesehen, da sie ohnehin auf fremden Computern nutzlos sind. Um dennoch auf binäres Speichern zugreifen zu können (das "Graf-Basic" müsste dafür auf dem 8-bit-Atari erweitert werden und mit 6502-Maschinencode kenne ich mich deutlich weniger aus als mit dem des Z80), ging ich die Geschichte nun doch auch im Atari-BASIC an, was soweit klappte. Doch verbreiteter ist heute Turbo-Basic, dessen erste Version einst in der Happy Computer abgedruckt war und das mittlerweile frei verteilbar ist. Das Programm kann auch hier genutzt werden, es besteht Kompatibilität. Der Vorteil ist, dass es deutlich schneller ist, auch zusätzliche komfortable Befehle bereitstellt. Hier gibt es jedoch keinen Bascoder, also setzte ich mir das Ziel, auf der Basis des Graf-Bascoders einen Bascoder für Turbo-Basic zu schreiben. Komplett ist das ohne Maschinencode leider nicht zu schaffen, siehe Textkasten. Auch um die Nutzung des BasiCode-eigenen Kassettenformats werde ich mich nicht kümmern, da es heute vielfältige andere Übertragungswege für ASCII-Dateien gibt.

 


  Unterschiede   BasiCode   Atari

  ASCII       "ATASCII" (leichte Abweichungen)

  Trennzeichen:   CHR$(13)   CHR$(155)

  DATA-Zeilen:

-----  Beispiel:
  Zeichenketten in Anführungsstrichen

25000 DATA 3,12,“Herbert“,7
 
  Zeichenketten ohne Anführungsstriche

25000 DATA 3, 12, Herbert, 7
 

  Stringvariablen:   ohne Dimensionierung verwendbar   Dimensionierung zwingend erforderlich

  RESTORE:   ohne Zeilennummer   nur mit Zeilennummer

  aus/in Datei lesen/schreiben   (nur Strings)   nur Byte-weise

  DEF FN   möglich (mit einer Variablen)   nicht verfügbar

  DIM   Indizierung ab 0   Arrays und Felder ab 0, aber Strings ab 1

  TAB   nutzbar, doch nicht empfohlen   nicht verfügbar

  LEFT$, MID$, RIGHT$       komplett andere Syntax

  String-Verkettung       andere Syntax

  Zeichenketten-Arrays   (nur eindimensional)   nicht möglich, da Schreibweise wie Teilstring-Funktionen von BasiCode
 

      Der Atari ist ein sehr früher Computer der in einigen Punkten von (später etablierten) Standards abweicht.   Nicht alle Inkompatibilitäten lassen sich; unter ausschließlicher Verwendung von Basic-Befehlen umgehen.

 

Info: Grafik aus Textdatei

Als ich damit schon recht weit fortgeschritten war, fiel mir auf, dass ich die meisten Bilder ja von C+4 - Clubdisketten habe. Warum also den Umweg über HRT gehen? Es können doch gleich die Bild-Dateien des Commodore als Quelle dienen, lediglich die Reihenfolge der Bytes ist umzusortieren. Vermutlich wird das Programm so auch attraktiver für die Atari-Nutzer. Aus dem gleichen Grund arbeitete ich auch die Umwandlung aus Speicherabzügen des ZX81 und des ZX Spectrum sowie aus monochromen MS-PaintDateien ein. Nebenbei wird für diesen Weg weniger Speicherplatz auf der Diskette verbraucht: die Bilder müssen nicht unbedingt im Atari-eigenen Format gespeichert werden und die Commodore-Grafiken haben nur 320 Bytes zu viel Länge (der Atari hat 192 Grafikzeilen, die Commodores 200). Die HRT-Dateien beanspruchen mehr Platz, da jedes GrafikByte zwei Buchstaben zum Speichern verwendet.

Als das Programm ausreichend weit gediehen war, nutzte ich Andreas' Angebot, sich als Tester zur Verfügung zu stellen. Am interessantesten fand er die Möglichkeit, aus dem angezeigten Bild eine HRT-Datei zu generieren. Damit können Bilder vom Atari die Reise auf andere Computer antreten, für die es ein ImportProgramm gibt, wie zum Beispiel unsere JOYCE. Schnell versorgte er mich mit solchen verschlüsselten Bildern und die Decodierung auf der JOYCE klappte auch sofort. Er ist von dem Thema ebenfalls "infiziert" und hat auch schon selbst Bilder erstellt (unter Nutzung eines PCs als Zuarbeiter für den Oldtimer). Um den Einstieg zu erleichtert, habe ich das Programm reichlich mit REM - Zeilen, einer Erklärung und weblinks ergänzt. Vielleicht fühlt sich ja ein "alter Hase" herausgefordert, sich der offenen Probleme, vor allem des Bascoders, anzunehmen?

Thomas Rademacher, im Mai 2022