Wie man "EASTERN FRONT 1941" aus dem Quellcode baut, mit einem #FujiNet.

[tschak909]

Dieses Video zeigt, wie man den Quellcode des #Atari8bit-Spiels Eastern Front: 1941 (Chris Crawford, Atari/APX, 1981) mit Hilfe des #Atari Assembler/Editor-Cartridges und des #FujiNet in eine komplett lauffähige Diskette verwandelt. #retrocomputing #retrogaming

https://youtu.be/o-Syzcwl1Tg

Das #FujiNet wird verwendet, um sowohl vollständige Listings aus dem Assembler zu erzeugen, als auch um PC-lesbare Kopien des Quellcodes auf meinem Netzwerkserver zu speichern, der eine Windows-Dateifreigabe offenlegt.

Da alle hier gezeigten Ressourcen über den apps.irata.online TNFS-Server verfügbar sind, können Sie mit Ihrem #FujiNet mitverfolgen, wenn Sie möchten.

Hinweis: Die Atari Assembler/Editor Cartridge ist sehr langsam. Es gibt viele Bereiche, in denen Stille herrscht, während der Assembler läuft. Ich habe sie aus Gründen der Authentizität eingebaut. Fühlen Sie sich frei, das Kapitel zu lesen!

[Erhard]

Hi Thom,

I just started to watch this video and I must say that it is really cool work (not talking about the time it must have taken to actually produce this video ...).

Not only that the FujiNet is an awsome device - the video shows an almost crystal clear Atari 8-Bit screen plus some small window showing a directory on irata.online blitted in and the video has got nice chapter heading so one can easily re-view a certain part.

I am sure that I will watch that video not only once and I can recommend it to everyone who wants to know about the FujiNet's capabilies and who prefers to be shown how to use something instead of reading large text manuals.

Erhard

[Erhard]

Hi,

one question about N: device translation.

I can remember a former printer interface, that needed translation to for example print an assembler listing.

That very same printer was able to print graphics.

When that graphics data was sent to the printer, the interface replaced a $9B within the graphics data with $0A$0D as well, which led to a corrupt print not only because something different was printed but the lenght of the graphics data did no longer match the -print graphics command- so everthing else after the graphics print was corrupt as well.

My workaround was to replace any $9B within the graphics data with maybe a $9A, so the graphics was a bit incorrect but the print worked.

So is it possible, that using translation mode with the N: device can cause something like this? Maybe it could be necessary to modify a source code in case it contains a $9B somewhere as data to replace that with something like .Byte $9B or if a source code includes an object file that contains a $9B?

Erhard

[tschak909]

There's no need for this, because:

(1) the printer has its own pipeline, which is aware of what mode it is in, for a given target host.
(2) the N: device ntrans is literally meant for translating text files across the network. If you're dealing with anything else, it needs to be turned off.

-Thom

[Erhard]

Hi Thom,

thanks for your reply.

That means one must pay attention to not use mixed file types (text and binary) using the N: device with translation switched on.

I just want to draw attention to it because I think it's easy to miss something like this.

Best, Erhard

[DjayBee]

That means one must pay attention to not use mixed file types (text and binary) using the N: device with translation switched on.

Das hängt nicht am N: Device, sondern am OPEN Befehl.

Code: Alles auswählen

OPEN #1,4,TRANS,"N:FILE"

TRANS=
0 = No Translation
1 = Translate CR (0x0D) to EOL (0x9B) (Macintosh style line endings)
2 = Translate LF (0x0D) to EOL (0x9B) (UNIX style line endings)
3 = Translate CR/LF (0x0D 0x0A) to EOL (0x9B) (PC/Windows style line endings, also default Telnet NVT behavior)

(Ich hoffe, das stimmt noch genau so.)

Siehe: https://forums.atariage.com/topic/29872 ... nt=4513302

[Erhard]

Hallo

Das hängt nicht am N: Device, sondern am OPEN Befehl.

es ist doch wie folgt:

Folgendes Scenario:

- man verwendet N: mit "Translation"
- auf N: sind eine ASM und eine OBJ/DAT (=Binär) Datei
- ich assembliere von N: die ASM-Datei welche die Binärdatei per "Include" einbindet
- die Binärdatei enthält ein oder mehrere Bytes des Wertes 155 bzw $0A, $0D oder $0A0D

Es gibt nun 2 Möglichkeiten.

Wenn man die Binärdatei erst nach N: kopiert und dann wieder liest wird 2x übersetzt und alles sollte (wieder) passen.

Liegt die Binärdatei bereits auf dem Pfad, auf den man dann N: mit Translation öffnet, dann werden die $0A, $0D oder $0A0D Werte der Binäratei beim Assemblieren je nach Modus der "Translation" in $9B übersetzt, oder sehe ich das falsch?

Ich gehe davon aus, daß in den meisten Fällen eine solche Veränderung der Daten nicht gewollt ist.

Ich könnte mir vorstellen, daß ich das leicht übersehen könnte und bei der Fehlersuche, warum meine fertige COM-Datei nicht wie gewünscht funktioniert, würde ich mir die Haare raufen.

Entweder muß man es machen, wie Thom in seinem Video und die Binärdatei über einen anderen Pfad einbinden oder man läßt die Übersetzung (Translation) ausgeschaltet. Das hat dann aber zur Folge, daß man auf dem PC nicht mal eben mit einem beliebigen Editor die ASM Datei bearbeiten kann, weil man bei den meisten Editoren das Zeilenende-Zeichen nicht beliebig einstellen kann.

Ich will hier an nichts rummeckern. Ich will lediglich aufzeigen, daß man sich dieses Verhaltens bewußt sein sollte.

CU, Erhard

[DjayBee]

Folgendes Scenario:

- man verwendet N: mit "Translation"
- auf N: sind eine ASM und eine OBJ/DAT (=Binär) Datei
- ich assembliere von N: die ASM-Datei welche die Binärdatei per "Include" einbindet
- die Binärdatei enthält ein oder mehrere Bytes des Wertes 155 bzw $0A, $0D oder $0A0D

Dieses Szenario ist vermutlich nur lösbar, wie von dir beschrieben.

Du könntest noch schauen, ob der Assembler fürs Öffnen des Quellcodes und zum Einbinden der Binärdatei zwei verschiedene OPEN Befehle/Unterprogramme verwendet und falls ja, bei dem für den Quellcode das AUX2 Byte auf einen passenden Übersetzungsmodus stellen.
Das ist natürlich ein fieser Hack am Programmcode, sollte aber helfen.

[Erhard]

Hi,

Du könntest noch schauen

noch mal: ich will es nicht machen. Ich will nur dafür sorgen, daß andere dies nicht übersehen und sich dann mit einer Fehlersuche rumplagen.