dl7ukk hat geschrieben:Hi,

DjayBee hat geschrieben:Generell ist es IMHO kein sehr geschickter Ansatz, beim Vergleich von Images auch deren Header in den Vergleich einzubeziehen.
Und wenn ihr zur Archivierung unbedingt ganz exakt genau gleich identische Images haben wollt, macht euch Fluximages und ggf. ein ATX daraus, aber bitte keine ATRs.

... oder ein CRC der Progs gleich auf dem XLE. Auf die Progs. kommt es schließlich an.

Ich kann Walter schon verstehen, er will die ATR Nachvollziehbar und das ganz genau. Da ist doch nix dran' auszusetzen. Übrigens Fluximages sind ggf. eine feine Sache, aber hier keine Lösung (, wenn ich nix übersehen habe).


dl7ukk

Ich verstehe Walter auch, das habe ich ja geschrieben. Und ich denke, ich habe auch deutlich gemacht, dass ich für einen Lösungsansatz dankbar bin, denn ich weiß nicht, wie das zu bewerkstelligen ist. Die Beschreibung, wie ich vorgehe, sollte ja dazu dienen, eventuelle Fehler in diesem Prozess zu erkennen und Lösungen zu finden. Erschwerend kommt ja hinzu, dass bei Walter die B-Seite offensichtlich anders ist, als bei allen anderen. Da gilt es nun herauszufinden, wo da etwas schief läuft. Pauschal mir die Schuld zuweisen und sich beschweren hilft mir nicht gerade sehr, da etwas zu verbessern.
Ich wüsste jetzt auch nicht, wie eine SuperSpeedy dazu käme, eine von 600 Disketten einfach in SD statt ED zu formatieren. Außer Walter hat noch niemand davon berichtet, dass die Disketten (physikalisch und Download) SD wären. Ich, mit meinen eigenen Rechnern und dem mir eigenem Workflow kann das eben bei mir nicht nachvollziehen. Deswegen frage ich ja, wer da ähnliche Erfahrungen macht.

Den Vorschlag mit CRC auf dem Atari finde ich sehr gut. Das würde doch schon mal MacOSX/Windows/Linux-Unterschiede als Fehlerquelle ausschließen, oder?
Auch hier die Frage: Wie wäre da die Vorgehensweise? Ich kenne mich da nicht gut genug mit aus.

DjeyBee schreibt von Flux- und ATX, statt ATR. Auch da kenne ich mich nicht gut genug aus. Wenn mir jemand sagt, wie man das macht, erstelle ich gerne auch ATX statt ATR, wenn das irgendwie hilft.

Aber man sollte vielleicht auch mal schauen, wo da "unterwegs" noch was schiefgehen kann. Die Diskette wird sich auf dem Postweg im Umschlag ja nicht selber umschreiben. Also sollte man auch mal ins Auge fassen, ob vielleicht die Art der Bereitstellung des Downloads Probleme verursachen kann. Wie DjayBee anmerkt, legt OS X ja Fork-files an.

Also nochmal:

Ich verstehe das Problem und bin auch gewillt, im Rahmen meiner Möglichkeiten für eine Verbesserung zu sorgen. Aber dazu brauche ich Eure konstruktive Mitarbeit, denn meine Kenntnisse sind in diesem Fall dazu nicht ausreichend.

Was "moderne" Hard- und Software angeht, kann ich dazu sagen, dass mir hier folgende Systeme zur Verfügung stehen:

MacOS X Big Sur auf MBP
Windows 10 (jeweils aktuelle Version) auf recht moderner Workstation ohne "richtige" serielle Schnittstelle
Windows 7 (offline) auf einem alten Laptop mit "richtiger" serieller Schnittstelle

und ein kleiner Laptop, auf dem ich versuche, ein Linux unterzubringen (ich glaube, Holger hat mir da schon was angeboten, was ich mir noch anschauen muss)

Atariseitig ist auch so einiges an Hardware vorhanden, und selber löten kann ich auch (wer erinnert sich nicht an mein hässliches aber funktionierende SDrive, das ich auf einer Fujiama im kleinen Raum zusammengebraten habe ), aber ich brauche konkrete Vorschläge, wie man das umsetzt.

Also:

dl7ukk hat geschrieben:Hi Thomas

8bitjunkie hat geschrieben:
Also dl7ukk_ Erstens mal bin ich in der Tat erst sieben oder acht Jahre im ABBUC.

Oh, ja, doch, erst ~~ ich hätte geschworen, Du bist schon ewig dabei. Aber so kann man (ich) sich täuschen .

Ich denke auch immer, er sei ewig dabei. Aber nicht einmal Tabaluga oder wie das kleine grüne Ding von ihm heißt, ist eine Atari-Geburt, sondern kommt vom Amiga

skriegel hat geschrieben:
Ich denke auch immer, er sei ewig dabei. Aber nicht einmal Tabaluga oder wie das kleine grüne Ding von ihm heißt, ist eine Atari-Geburt, sondern kommt vom Amiga

Der Amiga ist doch auch ein Atari. Zumindest vom Hardware- und Software-Design her...

Hi,

skriegel hat geschrieben:Den Vorschlag mit CRC auf dem Atari finde ich sehr gut. Das würde doch schon mal MacOSX/Windows/Linux-Unterschiede als Fehlerquelle ausschließen, oder?

Das ist richtig, es würde MacOSX/Windows/Linux-Unterschiede als Fehlerquelle ausschließen

ABER!

Es würde ein Unmenge an zusätzlicher Arbeit bedeuten, die weder Charly noch Du leisten sollten. Vielleicht wäre die Zusammenarbeit mit den Einsendern und eine Datei auf Abbuc.de oder #FujiNet, eine Möglichkeit. Ob es praktikabel ist, kann ich nicht sagen. Die Kryo wird (leider) alle Abweichungen mit aufzeichnen. Aber dafür ist die Kryo ja da.

dl7ukk

skriegel hat geschrieben:Ich verstehe Walter auch, das habe ich ja geschrieben. Und ich denke, ich habe auch deutlich gemacht, dass ich für einen Lösungsansatz dankbar bin, denn ich weiß nicht, wie das zu bewerkstelligen ist.

Daran wollte ich auch gar nicht rumnörgeln.
Ich war nur über die Diskussion zu unterschiedlichen MD5 Hashes der ATRs irritiert. tfhh hatte sich darüber ja auch schon am Anfang von Seite 4 dieses Threads aufgeregt.
Und zum Schluss war dann CharlieChaplin sogar so verunsichert, dass seine seit 25 Jahren verwendete Toolchain evtl. fehlerhaft sein könnte.

Nachzuverfolgen, weshalb eine Diskette falsch formatiert wurde, ist dagegen sinnvoll um zukünftige Fehler zu vermeiden.

skriegel hat geschrieben:Den Vorschlag mit CRC auf dem Atari finde ich sehr gut. Das würde doch schon mal MacOSX/Windows/Linux-Unterschiede als Fehlerquelle ausschließen, oder?
Auch hier die Frage: Wie wäre da die Vorgehensweise? Ich kenne mich da nicht gut genug mit aus.

Das würde auch tatsächlich allen Mitgliedern helfen, die nur mit originaler Hardware arbeiten.
Dazu müssten wir ein Programm auf dem 8-Bitter finden, das CRCs berechnen und vergleichen kann - analog zu md5sum unter Linux.
Der Mehraufwand beim Erstellen der Disketten wäre dann, dieses Programm (sinnvollerweise nur ganz am Schluss des "Masterings") laufen zu lassen und das Ergebnis auf der Diskette abzuspeichern.

skriegel hat geschrieben:DjeyBee schreibt von Flux- und ATX, statt ATR. Auch da kenne ich mich nicht gut genug aus. Wenn mir jemand sagt, wie man das macht, erstelle ich gerne auch ATX statt ATR, wenn das irgendwie hilft.

Das war pure Ironie in Bezug auf die "MD5-Wars". Ein Fluxdump hätte nur die paar wenigen Sonderdisks einen Sinn, die kopiergeschützt sind. Ich hatte da vor einiger Zeit mal welche im Downloadbereich entdeckt, weiß aber gerade nicht mehr, was es war.

skriegel hat geschrieben:Also:

yep, und

Ein CRC-Programm für den Atari gibt es bereits (ich glaube sogar mehrere), eines nahm sogar mal am Abbuc Software Wettbewerb teil (CRC32 von Russ Gilbert anno 2011). Das Programm berechnet *glaube ich* die CRC32 für Atari Dateien, d.h. wenn auf der Magazindiskette 10 Dateien sind hätten wir 10 CRC's, bei 64 Dateien dann eben 64 CRC's. Das Berechnen für eine Datei dauert eine Weile und bei bis zu 64 Dateien eine etwas längere Weile. [Icon Kaffeetasse]

Bin mir nicht sicher, ob das Atari Programm die CRC's nur anzeigt oder auch als Text speichern kann, da ich es nie genutzt habe. Wenn es die CRC's nur anzeigt, müsste man sie danach manuell notieren (altmodisch mit Stift und Papier oder per Word, OO, Excel, etc.). Unter SDX sollte/dürfte es auch ein CRC Programm geben, doch ich nutze SDX nie.

Schneller ginge das ganze Prozedere mit einem Emulator unter full speed und man könnte problemlos einen Screenshot machen. Nur läuft bei mir immer noch ein altes OS (Win XP 32Bit) und demzufolge alte Emulatoren. Und wer weiß, ob die Emulatoren nicht auch irgendwelche Fehler oder Ungereimtheiten mit einbringen. Und dann wäre es ja kein original Atari mehr

Hier mal testweise die CRC32 für Magazin 143 Seite A, erstellt via emuliertem Atari (A800 Win) und dem Programm CRC32N2 von Russ Gilbert. Das Ergebnis wird als ATASCII Text gespeichert, wie zu erwarten hat das Programm ein wenig Probleme bei der "Berechnung" der Spezialeinträge in der Directory (inverse Einträge mit null Sektoren Länge, d.h. nur Anmerkungen in der DIR und keine Dateien).

Auf dem Atari benötigt man für die div. CRC's etwas Geduld, via Emulator mit full speed geht es in wenigen Sekunden.

Hallo Leute

Wir brauchen also ein neues Menuprogramm. Am besten eins das vieles selber macht.

Tschüß

Mathy

Das bisherige ist ziemlich genial. Wäre es nicht schon eine große Hilfe, hätte man ein passendes Autorentool zu Hand, was einiges automatisiert oder zusammenfasst?

Hi,

nun wird es langsam albern.

Mathy hat geschrieben:Hallo Leute

Wir brauchen also ein neues Menuprogramm. Am besten eins das vieles selber macht.

Tschüß

Mathy

dl7ukk

Hi,

nach den ganzen sinnvollen und sinnlosen Beiträgen, wäre es doch sicher zielführender den Ursachen auf den Grund zu gehen.

Mit dem SOP2PC von Nick habe ich immer sehr gern gearbeitet. (Heute benutze ich Hias atarisio auf der Konsole.)

Vor einigen Jahren wurde festgestellt, dass SIO2PC beim Erstellen von DD ATR eigene Wege geht. Die User, welche schon länger dabei sind, wissen wovon ich schreibe.

Wenn es also wirklich nur an diesem 1 Bit liegt,

Rein funktional scheint alles in Ordnung zu sein. Nun hat aber auch Erhard schon öfter angemerkt, dass da irgendein Bit gesetzt ist, was nicht gesetzt sein sollte, aber keinerlei Probleme verursacht.

so sollte es doch ein Leichtes sein das betreffenden Byte mit dem Bit zu ändern. Danach sollten die Prüfsummen der ATR wieder identisch sein. Zum Ändern des Bytes im ATR braucht es nur einen (Hex) Editor. JAC! hatten mal einen in Java(?) geschrieben. Es geht sogar mit einem Emu in BASIC und LW: H: !

Und dann gilt Walter unser Dank, wieder ein Körnchen ATARI - History aufgeklärt zu haben.

Anderenfalls -- ja dann muss die Suche nach den Fehlern weiter gehen.

dl7ukk

Also mal ganz ehrlich. Ich kann den Prüfsummen-Krams nichts abgewinnen.
Dafür ist mir die Lebens-Zeit zu kurz
Eine ATR Datei enthält vorne weg einen Header von 16 Bytes, der wohl unvollständig dokumentiert ist.
Scheinbar wird bei der Erstellung eines ATRs, von verschiedener Software, nur ein Byte verändert.
Deswegen der Aufwand. Nehmt mal die 16 Bytes vorne weg, schnipp, und man erhält die "Otto-Normal-Daten" der Diskette. Jetzt könnte man als Extender, XFD, anfügen. Ja richtig, das alte XFormer "Format".
Nun sollten die Prüfsummen stimmen, wenn die "Otto-Normal-Daten" gleich sind.
Mit einem Hex Editor am PC, Mac oder Diverse, kann man ja auch Dateien vergleichen.

Eure Prüfsummen sind eh Schall und Rauch. Ein ATR ist ja kein genaues Abbild einer echten Diskette.
Warum, es werden die Daten zwischen den Daten ja gar nicht gespeichert.
Bei Medium Density hat man bekanntlich 128 Bytes pro Sektor x 26 Sektoren pro Track x 40 Tracks = 133120 Bytes Daten. Aber auf der Diskette ist noch viel mehr. Ein genaues Abbild ist fast Doppelt so groß.
Sieht man bei den Kryoflux und Super Card Images. Es gibt Daten wie Sync, Header, Gap's und weiß der Geier.
Wird irgendwas bei diesen "Fluss"-Daten geändert, ist es ja fast schon ein Kopier Schutz.
Jetzt könnte man einige Gap's weglassen, und die Abfragen, beim Intro oder so.
Das ATR, wird dann evtl. auf Emulatoren nicht funktionieren, aber die Prüfsummen wären gleich.
Hey, ich habe das ATR auf die Diskette kopiert, aber es läuft nicht. Böse, böse, he, he.

OK, nun zu dem "nur 90 Kb Problem" von GoobByteXL.
Ich habe hier eine Mini-Speedy, Speedy TDS und die Mega-Speedy. Die heißen nicht umsonst Speedy.
Wird eine Diskette eingelegt, wird sofort ganz schnell (Speddy), der komplette Track 0 in das Speedy Ram kopiert. Betätigt man den Floppy Knebel zu langsam, kann die Speedy nicht richtig lesen. Das kann auch passieren wenn die Scheibe zu schwer gängig ist. Es ertönt der Summer (wenn vorhanden) und im Display (wenn vorhanden) steht NF (No Format). Also immer den Knebel mit Schmackes schließen.
Ich hatte auch schon das Problem, das Medium Disketten als Single oder NF (von anderen Floppys erstellt) angezeigt wurden. Meine Speedys wurden alle von TFHH korrekt justiert.
Es kann nun sein, das die Floppy von GoobByteXL, am oberen oder unteren Toleranzbereich liegt.
Vielleicht mal die Speedy slow schalten oder eine andere Floppy nehmen. Ist das immer noch Single, ist das wohl doch ein (sehr unwahrscheinlich, aber nicht auszuschließen) Kopierfehler.

Wird bei der Speedy eine Diskette entnommen, fährt der R/W-Kopf immer gleich auf Track 0. Dies verhindert beim einlegen einer neuen Diskette, das der Kopf über die ganze Scheibe rutscht, falls er auf Track 39 stand.
Bei einer normalen 1050 oder Happy, steht der Kopf irgendwo, und beim einlegen einer Diskette rutscht er auf Track 0. Es gibt ein gepatchtes Happy Os, wo der Kopf, wie bei der Speedy, auch auf Track 0 fährt, wenn die Diskette entnommen wird.
Ganz anders bei dem Super Archiver / Bit writer. Wird hier eine Diskette eingelegt, fährt der Kopf auf Track 39, um nach Daten für den Super Archiver zu suchen, um ihn zu programmieren. Danach fährt der Kopf auf Track 0.

So genug über CRCs und Floppys. Bringe erstmal Shop Pakete zur Annahmestelle.

Hi

Yellow_Man hat geschrieben:Also mal ganz ehrlich. Ich kann den Prüfsummen-Krams nichts abgewinnen.
Dafür ist mir die Lebens-Zeit zu kurz

Das ist doch gerade unsere Leidenschaft, die Leiden schafft. Sonst würden wir Wattwürmer baden ...

Eine ATR Datei enthält vorne weg einen Header von 16 Bytes, der wohl unvollständig dokumentiert ist.
Scheinbar wird bei der Erstellung eines ATRs, von verschiedener Software, nur ein Byte verändert.
Deswegen der Aufwand. Nehmt mal die 16 Bytes vorne weg, schnipp, und man erhält die "Otto-Normal-Daten" der Diskette. Jetzt könnte man als Extender, XFD, anfügen. Ja richtig, das alte XFormer "Format".
Nun sollten die Prüfsummen stimmen, wenn die "Otto-Normal-Daten" gleich sind.
Mit einem Hex Editor am PC, Mac oder Diverse, kann man ja auch Dateien vergleichen.

Auch eine prima Idee, daran hatte ich gar nicht gedacht!........ Danke !!



dl7ukk

dl7ukk hat geschrieben:Hi,

nach den ganzen sinnvollen und sinnlosen Beiträgen, wäre es doch sicher zielführender den Ursachen auf den Grund zu gehen.

Mit dem SOP2PC von Nick habe ich immer sehr gern gearbeitet. (Heute benutze ich Hias atarisio auf der Konsole.)

Vor einigen Jahren wurde festgestellt, dass SIO2PC beim Erstellen von DD ATR eigene Wege geht. Die User, welche schon länger dabei sind, wissen wovon ich schreibe.

dl7ukk

Nun, dieser "Bug" ist in SIO2PC eigentlich auch schon immer behoben. Man hat nämlich einfach mehrere Möglichkeiten ein DD/180k ATR zu erstellen, u.a. eine simple (4 Tasten drücken) und eine "aufwändigere" (5 Tasten drücken).

Die simple Methode unter SIO2PC geht so:
C - für create ATR image
S oder D für single/double density
1 - für LW 1 (oder 2,3, 4 für andere LW)
4 - für 184k Format (angezeigt als 180k ATR)
Damit wird das längere 180k ATR (184.xxx Bytes) erstellt.

Die "aufwändigere" Methode sieht so aus:
C - für create ATR image
S oder D für single/double density (D tippen!)
1 - für LW 1 (oder 2,3, 4 für andere LW)
6 - More, für andere Formate
(es folgt eine sehr unübersichtliche Liste mit vielen Formaten, auch 35 Tracks, 77 Tracks, 80 Tracks, etc.)
3 - für 40 Tracks, DD = 180k ATR (angezeigt als 179K ATR)
Damit wird das kürzere/standard ATR mit 179k bzw. 183.xxx Bytes erstellt.

Wenn man also die "aufwändigere" Methode wählt, hat man standard DD/180k ATR Images, die von Atari 800, Atari 800 Win, Altirra, etc. problemlos akzeptiert werden.

Ich würde mal sagen, es ist jetzt ausreichend erklärt warum es nicht sinnvoll ist die CRC einer zum Download bereit gestellten ATR-Datei mit einer von einer Floppydisk "rückwärts erstellten ATR-Datei" zu vergleichen - außer man kann sicher stellen dass die Ursprungs-ATR mit den gleichen Tools/Einstellungen (1.) "in eine echte Diskette" und (2.) auch beim "Rückwärtserstellen" bearbeitet wurde. Interessant was hier so lernt...

Aber dafür ist meines Erachtens das Angeben einer offiziellen Datei-CRC auch gar nicht gedacht, denn diese Angabe soll nur Sicherstellen das beim Kopieren/Download der Datei der Inhalt nicht verändert wird bzw. eine Veränderung erkannt werden kann. Die Downloadversion und dazugehörige CRC stellt somit die Referenz dar, egal wie (richtig oder falsch) sie erstellt wurde. Das auf dem Server eine korrekte und die letzte Version einer ATR landet (die für die Erstellung der Disketten genutzt wurde) muss sowieso anders sichergestellt werden.

Grüße
Bernhard

Liebe Diskutanten ,

Ich glaube, der Gaul ist jetzt mehr als tot geritten....

Gtx.,
andY

Wenn ich das alles hier so lese, wird mir grade bewusst
was ich alles über den Atari NICHT weiß

Für mich gab (und gibt) es nur zwei Arten von Disketten:

* Die, die fehlerfrei laufen
* und die, die es nicht tun...

andymanone hat geschrieben:Liebe Diskutanten ,

Ich glaube, der Gaul ist jetzt mehr als tot geritten....

Gtx.,
andY

Offensichtich ja nicht. Und warum nicht darüber diskutieren, ich lerne hier gerade auch einiges dazu.

Aber vielleicht meinst Du ja, das hat nichts mit Magazin 143 (Titel dieses Beitrags hier) zu tun? Und ich denke auch, dass das ein "eigenständiges" Thema ist, deswegen nehme ich den "CRC-Strang" hier mal raus (mit Hinweis) und mache ein eigenes Thema dadraus. Wen das nicht interessiert, der braucht das nicht zu lesen und kann hier in diesem Thema über Magazin 143 reden.

skriegel hat geschrieben:
Aber vielleicht meinst Du ja, das hat nichts mit Magazin 143 (Titel dieses Beitrags hier) zu tun? Und ich denke auch, dass das ein "eigenständiges" Thema ist, deswegen nehme ich den "CRC-Strang" hier mal raus...

Ja, das meinte ich vordergründig .
Aber sekundär eben auch, das man aus einer Mücke auch (unnötig) einen Elefanten machen kann....

Aber das ist lediglich meine persönliche Meinung.

Gtx.,
andY

andymanone hat geschrieben:Aber sekundär eben auch, das man aus einer Mücke auch (unnötig) einen Elefanten machen kann....

Aber das ist lediglich meine persönliche Meinung.

Persönliche Meinung ist ja völlig in Ordnung. Aber wenn einen ein Thema nicht interessiert, muss man denen, die es interessiert, ja nicht den Spaß daran nehmen.

Jeder hat halt so seine eigenen Vorlieben. Der eine will alles am liebsten auf echter Hardware machen (da gehöre ich tendentiell auch dazu), der andere nur im Emulator, etc.

Deswegen die Trennung hier. Wen dieses Thema nicht interessiert, der kann ja einfach weiterscrollen.

Also: Weitermachen! Spaß mit Ataris haben!