Hi,

(Image = Diskettenabbild)

der Beitrag über ATR Images im Magazin ist mir nicht entgangen, ebenso wenig die Tatsache, daß zum Softwarewettbewerb 2019 ein Beitrag auf einem 133 KB statt 130 KB ATR Image eingesendet wurde.

Grundsätzlich kann von der Definition her ein ATR quasi jede Größe haben, angefangen von einem einzigen Sektor in einfacher Dichte bis hin zu 65535 Sektoren in doppelter Dichte.

Was sich mir eher nicht erschließt ist, wie es dazu kommt, daß für die Standardformate von echten Atari Disketten offenbar so viele abweichende, in der Regel verkürzte ATRs im Umlauf sind.

Schließlich ist es ja wohl eher nicht so, daß man ATRs auf dem Atari mit seiner eingeschränkten Speicherkapazität hortet sondern auf einem PC, wo es bei den gängigen Speicherkapazitäten doch wohl sowas von egal ist, ob das ATR mit vollen 90 KB oder tricksig verkürzt mit 86 KB gelagert wird.

Was ich auch nicht verstehe ist - und das soll gegen niemanden ein Vorwurf sein - ist, wie es dazu kommt, daß aus einer 130 KB Atari Diskette ein 133 KB ATR werden kann. Gibt es denn da noch Soft- und oder Hardware, die die ATRs falsch erstellen?

Bei APE zum Beispiel kann man beim Erstellen zwischen vordefinierten Größen und freier Dimensionierung auswählen. Die voreingestellten Größen stimmen. Da ist nix zu groß oder zu klein. Gleiches gilt für Geräte wie dem SIO2USB.

Irgendwelche Hinweise?

Moin,

ich kann da nur vermuten - ich verwende "seit Anbeginn der Zeit" (c) nur "offizielle" Software, zuerst SIO2PC von Nick Kennedy unter plain old DOS, nach Wiedereintritt in die A8-Welt dann APE registriert von AtariMax. Ich erzeuge ATRs nur damit.

Diese ganzen "krummen Dinger" kommen wohl durch Tools zustande, auf direkt auf dem PC/Mac zur Erzeugung eines ATR genutzt werden, vermutlich von den Emulator-Fetischisten, die wenig bis gar nichts auf echter HW machen

Eigentlich dachte ich, das Thema wäre in Zeiten, wo man selbst auf dem Dorf mindestens 1 MBit/s hat, vorbei, aber offenbar ja doch nicht...

Gruß, Jürgen

Hallo Zusammen,

Das mit dem 133KB Image war bei meiner Einreichung...

Ich hatte ein Image vom.AtariWiki verwendet, das die richtige Größe hatte, vermutlich ist entweder beim speichern auf den PC ( Ich nutze Linux) oder beim kopieren auf die SD Card da was geschehen. Aber da ich mit den Images nicht Probleme hatte (auch nicht mit SIO2USB) ist mir das nie aufgefallen.


Gruß, Holger ( Der wider der Vermutung von Jürgen mit echter Hardware programmiert )

Rockford hat geschrieben:Das mit dem 133KB Image war bei meiner Einreichung...

Was war da denn genau mit dem Image? 130 vs 133 hört sich erst mal stark danach an als ob SI ("k") und binäre ("ki") Einheiten ducheinandergeraten wären.

130kiB sind ziemlich genau 133kB (die 16 Byte ATR Header und die 0.1 kB hinter dem Komma mal salopp ignoriert).

Das 130KB (sic!) ATR von hier https://atariwiki.org/wiki/attach/Atari ... /130KB.atr sieht jedenfalls OK aus.

so long,

Hias

Hi,

Rockford hat geschrieben:Der wider der Vermutung von Jürgen mit echter Hardware programmiert

Jürgen hat ja gar nicht vermutet, daß _Du_ nicht auf echter Hardware programmierst, gell ?

Aber ich fürchte, daß Jürgen recht hat mit der Annahme, daß es durchaus so einige Leute gibt, die A8 komplett auf dem PC machen.

HiassofT hat geschrieben:hört sich erst mal stark danach an als ob SI ("k") und binäre ("ki") Einheiten ducheinandergeraten wären.

Das ist zumindest in Windows eine ziemlich gute Quelle für Ablesefehler. Wenn man da per Rechtsklick auf eine Datei deren Größe nachschauen will und dann unglücklich bei 'Größe auf dem Datenträger' nachschaut, dann hat auch eine Datei mit nur 1 Byte Inhalt auf einem Datenträger mit 64K Clustern eine Größe von 64 KB. Deutlich besser ist direkt darüber die Anzeige in Bytes. Aber ich hab selber auch schon oft genug auf den unteren Wert geguckt.

So sollte ein ein ATR von einer MD-Disk meiner Rechnung nach ungefähr 133136 Bytes groß sein.

CU, Erhard

Hallo Zusammen,

Nun scheint sich das ja geklärt zu haben, prima

Hmmm,

ich vermute mal einen Schritt weiter, das gesendete ATR war nicht 133.136, sondern 143.xxx Bytes groß. Von einem Autor erhalten wir seit ein paar Jahren ca. 140kbyte große ATR Images, keine Ahnung warum genau. Ich dachte bisher, da würde eine alte DOSen Version von SIO2PC (2.x oder 3.x) dahinterstecken, da diese halt einen Bug hat und Medium/Enhanced density mit 140k statt 130k erstellt. Aber vermutlich ist es doch ein anderes Programm, dass dies macht... naja, ich kann das Image ja problemlos auf eine reale 130k Disk kopieren.

Werde Frederik mal darum bitten, mir das ATR Image zu mailen, damit ich mir dessen genaue Größe mal anschauen kann.

gängige/standard ATR-Größen:
90k = 92.176 Bytes
130k = 133.136 Bytes
180k = 183.936 Bytes

Viele gekürzte ATR Images stammen von COM/XEX Dateien, die in ATR umgewandelt wurden, z.B. MakeATR, ATR Util, Xboot und anderen XEX2ATR Konvertern (und PC-Usern, die zu faul sind XEX-Dateien in richtige/volle ATR Images umzuwandeln). Einige Besitzer von A8 Flash-Cartridges nutzen auch gekürzte ATR-Images wenn das XEX nicht direkt laufen will, da die Flash-Carts von der Größe her schon etwas beschränkt sind (z.B. 512k oder 4MB)... hatte von Yellowman z.B. mal ein Flash-Image (für die 4MB flashcart.) auf dem div. gekürzte ATR Images drauf waren (und einige dieser XEX2ATR Tools nutzen z.T. einen spez. Bootloader, der viele XEX Dateien lädt, die von sonst keinem Bootloader laufen wollen)...

CharlieChaplin hat geschrieben:gängige/standard ATR-Größen:
90k = 92.176 Bytes
130k = 133.136 Bytes
180k = 183.936 Bytes

90 KiB und 130 KiB ok,

180 KiB als ATR werden bei mir sowohl unter Linux als auch Win10 mit 183.952 Bytes angelegt von Altirra, makeATR und RespeQt.

Korrekt.
180k ATR = 183.952 Bytes
(Die von mir angegebene Länge war XFD, daher 16 Byte kürzer.)

Hallo Leute

Die meisten kurzen ATRs stammen wahrscheinlich aus der Zeit, als Speicherplatz noch nicht in Giga- oder Terabyte ausgedrückt wurden. Wenn Speicherplatz Mangelware ist, muss man irgendwo sparen. Dabei sind wohl eigene auf die Idee gekommen, die leeren Sektoren aus den ATRs raus zu werfen.

Tschüß

Mathy

CharlieChaplin hat geschrieben:Die von mir angegebene Länge war XFD, daher 16 Byte kürzer.

Ah, wieder etwas gelernt. XFD habe ich ewig nicht benutzt.

Vielleicht wäre es hilfreich, derartige Informationen zu sammeln und ggf. in der Mag-Beilage als Beitrag einzubringen.

CharlieChaplin hat geschrieben:Hmmm,

ich vermute mal einen Schritt weiter, das gesendete ATR war nicht 133.136, sondern 143.xxx Bytes groß. Von einem Autor erhalten wir seit ein paar Jahren ca. 140kbyte große ATR Images, keine Ahnung warum genau.

...

Hallo Andreas,
Das war damals ich, mir ist es tatsächlich erst letztes Jahr durch den Hinweis von Frederik aufgefallen. Das war ein geschickt zusammen gestelltes ATR mit TB XL und Zusätzen drauf, welches ich von irgendwo her hatte und tatsächlich wurde es klaglos von allen SIO Lösungen geschluckt.

Aufgrund dessen habe ich dann für den Wettbewerb das ATR vom Atariwiki genommen.

Gruß, Holger

Durch die Diskussion ist mir aufgefallen, dass mein dir2atr Tool keine Optionen hatte um schnell und einfach Images in SD/ED/DD/QD Standard-Grössen zu erzeugen. atariserver kann das seit Ewigkeiten, aber in dir2atr musste man die Anzahl der Sektoren und ggf die Double-Density Option bisher manuell setzen.

Das habe ich nun nachgeholt, dir2atr entsprechend erweitert und die neuen Versionen (190808) auf meine Homepage hochgeladen.

Wie gehabt für Windows User die "Atari Tools for Win32" https://www.horus.com/~hias/atari/#tools-win32 und für Linux/Mac User den Sourcecode zum selbercompilieren im AtariSIO Paket https://www.horus.com/~hias/atari/#atarisio

Nun gibt's "-S", "-E", "-D" und "-Q" Optonen um SD/ED/DD/QD images zu erzeugen. zB für ein 130k/ED image:

Code: Alles auswählen

dir2atr -E image.atr directory-mit-den-files

Tip: wenn ihr dir2atr auf ein leeres Directory loslässt erzeugt es ein leeres DOS2.x (oder MyDOS) image. So könnt ihr recht einfach leere images machen.

Tip 2: dir2atr kann auch XFD und DCM images erzeugen (falls das irgendwer möchte) - einfach "image.xfd" bzw "image.dcm" statt "image.atr" angeben.

so long,

Hias

Hi,

bei einer 180 KB Disk müßte das entsprechende ATR meines Wissens 183.952 Bytes groß sein.

Die Größen berechnen sich wie folgt (wenn ich mich nicht irre):

Bei SD/MD, also Disketten mit 128 Byte Sektoren: Anzahl der Sektoren * 128 +16

Bei DD/QD ..., also Disketten mit 256 Byte Sektoren: (Anzahl der Sektoren -3) * 256 + 3 * 128 + 16

CU, Erhard

Meine Schnellschussreaktion (die daran lag, dass die Einreichung vier Stunden vor der Deadline kam und ich dem Autor gerne noch die Chance geben wollte, etwaige Fehler zu beseitigen) hatte den Hintergrund, den CharlieChaplin schon erwähnt hatte, nämlich, dass das Image im Vorjahr 140kB groß war. Da mir macOS nun 133kB bei einem 133.xxx Byte großen Image anzeigt (also die SI-Einheit kB korrekt verwendet), vermutete ich wieder ein ähnliches Problem, denn in den Regeln stehen 90 bzw. 130 kB (wo es dann eigentlich KiB heißen müsste). Da ich mir in der geringen verbleibenden Zeit nicht noch die Ursache dieses Unterschieds anschauen wollte, habe ich da erst einmal einen Warnhinweis geschickt. Letztlich hat sich noch alles vor Ende der Deadline klären lassen und das Image ist konform.

Vor dem Hintergrund der möglicherweise auch streng auslegbaren Definition des Kopierschutzes, sollte man vielleicht diese Teile der Regeln auch noch lockern / entfernen, denn letztlich ist ja nur wichtig, dass sich aus dem ATR ohne weitere Zusatzsoftware eine "echte" Diskette schreiben lässt. Und gleiches gilt auch für den "Kopierschutz" von Dungeon Master II.

Hi,

vielleicht so ähnlich wie

"beziehungsweise muß einem Datenträgerformat entsprechen, daß mit einer Atari 1050 ohne Erweiterung gelesen und geschrieben werden kann (720 oder 1040 Sektoren a 128 Byte)"

???

CU, Erhard

Ja, das klingt doch sinnvoll...