CharlieChaplin hat geschrieben: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).

Probier's mal mit der Datei hier im Anhang.

Anmerkung: Das ist ein wüster Hack, der aber funktionieren sollte, solange die Dateilänge der Spezialeinträge bei Null bleibt.

Hi,

DjayBee hat geschrieben:Probier's mal mit der Datei hier im Anhang.

Ich will Euren Tatendrang nicht bremsen und finde ihn auch einfach Spitze
Dann müsste auch die Versionsnummer des Progs dazu kommen und/ oder ein Zeitstempel. Die Progs auf den Mag-Disk waren nicht immer die finale Version. Also ein Haufen zusätzlichen Aufwandes.

Da sich aber bewahrheitet, dass es hier Unterschiede gibt

DjayBee hat geschrieben:Der Unterschied liegt im neunten Byte des ATR-Header. Darin wurden Bits 4+5 dereinst von Nick Kennedy mal für Kopier- und Schreibschutz angedacht. Irgendwo anders habe ich dann noch gefunden, dass Bit 1 als Schreibschutz genutzt wird.
In den "falschen" Images ist Bit 1 gesetzt, was evtl. einen Schreibschutz darstellen soll.
Ich hab mir mal ein paar Images runtergeladen und angeschaut.
Die Älteren davon (80, 90, 100, 110, 120, 130-133) haben das Bit nicht gesetzt.
Danach wird es uneinheitlich.
Gesetzt ist es bei 134b, 137, 140, 141b, 142-143
Nicht gesetzt ist es bei 134a, 135-136, 138-139, 141a
Gesetzt ist es meistens (aber auch nicht immer) bei Images deren ZIP-Container einen "_MACOS" Ordner enthält.

.... wäre es schon gut zu wissen und zu notieren welches Programm, welche Bits, in welchem Byte setzt oder löscht. Irgendwann stößt es Irgendwem garantiert wieder auf. Und dann muss die Suche (hoffentlich) nicht wieder von vorn beginnen. Und es erspart Charlie auch die Veröffentlichung der CRC.

dl7ukk

Ich halte die MD5-Vergleicherei von verschiedenen Images für sinnlose Erbsenzählerei. Deshalb auch mein ironischer Post neulich.

Aber wenn man gezielt checken kann, ob die Dateien auf den Disketten unverändert sind, halte ich das für recht sinnvoll. Und das ist auch völlig unabhängig von Hardware oder dem Imageformat und seinem Header.

Hallo Andreas (dl7ukk)

dl7ukk hat geschrieben:nun wird es langsam albern.

Mathy hat geschrieben:Wir brauchen also ein neues Menuprogramm. Am besten eins das vieles selber macht.

dl7ukk

Ich sehe, es besteht Erklärungsbedarf.

CharlieChaplin hat geschrieben:... sieht das Abbuc Menü zwar schön aus, es ist aber leider furchtbar umständlich zu handeln.

Diese Umständlichkeit sollte behoben werden. Der Rechner ist ja deswegen da, weil der Mensch manche Sachen zu langsam und/oder nicht fehlerfrei macht. Die Größe der Diskette und die Größe der vorhandenen Software ist ja vorher bekannt. Per Software müsste es also möglich sein, zu errechnen was passt und was nicht. Und auch wo dann im Directory die Strichlinien hinkommen. Ausprobieren, gucken ob's passt und dann neu anfangen ist ja, wie deinen Namensvetter schon schrieb, nicht das Schönste am Hobby. Am schönsten währe, wenn man diese Rechnerei (lese: die Zusammenstellung der Disketten) auf dem Atari machen kann. Aber wenn das zu lange dauert, müsste es doch auch möglich sein um das auf 'nen moderne(re)n Rechner zu machen. Der moderne Rechner würde dann ein Image (ATR, XFD, ... ) erstellen, dass man nur noch auf 'ner realen Diskette kopieren müsste. (Wenn man die Zusammenstellung auf dem Atari berechnet, würde der Atari natürlich auch die Diskette beschreiben)

Tschüß

Mathy

Hi,

ich möchte an dieser Stelle einmal einige Dinge zu bedenken geben:

1) Angesichts der zehntausenden von Disks die hier durchgerauscht sind ist die Fehlerquote besonders angesichts des Alters verschiedener Komponenten immer noch eigentlich niedrig

2) Die sehr starke Verschmutzung von den Schreib-Lese-Köpfen ist hauptsächlich einem zeitweise vorliegendem schlechten Diskettenmaterial zu verdanken, bei dem die Beschichtung eher am Kopf anstatt an der Disk haften blieb

3) Das ATR-Format in irgendeiner Form zu verdammen hilft hier nicht weiter. Es ist ein wesentlicher Standard. Das von diesem Standard einige Programme in irgendeiner Form abweichen liegt ja nicht am Standard.

4) Daß das zum Erstellen der Master-Images der Magazine verwendete SIO2PC v1.21 im ATR-Header bei Byte 8 Bit 1 setzt ist halt ein bischen blöd, zumindest wenn es um einen Vergleich mit MD5-Prüfsummen geht, wenn ein anderes Programm beim Erstellen der Images dieses Bit eben nicht setzt.

Das könnte man vielleicht einfach dadurch lösen, daß man nach Erstellung der Master-Images mit SIO2PC mit einem HEX-Editor dieses Bit wieder auf Null setzt, und schon paßt alles.

Es gibt m.E. Fälle, wo eine Lösung deutlich schwieriger zu finden ist:

- wenn bei einem Vergleich von einer Disk, die identisch sein sollte mit einem Master aus dem Archiv die Sektordaten abweichen

- bei der Feststellung von Gleichheit von Programmen

Leider schreiben viele Authoren keine Information zur Version in das Programm. So kann es vorkommen, daß man bei einem Programm, wenn man es auf 5 verschiedenen Quellen erhält, keine Gleichheit feststellen kann, auch wenn es eigentlich das gleiche Programm ist. Der eine hat eine kleine Routine zum vorherigen Löschen des RAMs vorangestellt, der nächste hat eine RUN-Adresse drangehängt, der dritte hat das Programm mit einem linksdrehenden Packer gepackt, der vierte hat das Programm mit einem rechtsdrehenden Packer gepackt und die fünfte Version ist unverändert.

Wer sich mal IT-beruflich im Internet rumtreibt und Programme von verschiedenen Herstellern herunterladen muß der kann sehen, daß relativ viele die Authentizität Ihrer Programme mit einer MD5-Prüfsumme absichern.

Beispiele:

Veeam, Backup & Replication -> MD5 Prüfsumme wird dargestellt
Hewlett Packard, Firmwares für Switche -> MD5 Prüfsumme wird dargestellt
WatchGuard, Firmwares für Firewalls und Management-Software -> SHA1 Prüfsumme wird dargestellt

Es ist einfach so: es treten schon mal Fehler beim Herunterladen auf, Datenträger gehen kaputt, Dateisysteme schrotten. Und die einzige Möglichkeit festzustellen, ob die vorhandenen Daten in Ordnung sind ist zu Prüfen, ob die mit der angegebenen Prüfsumme übereinstimmen.

Es würde auch nichts bringen, irgendetwas zwei mal herunterzuladen. Dann wüßte man ja immer noch nicht, ob beim ersten Herunterladen was schief gegangen ist, oder beim zweiten, oder sogar in beiden Fällen.

Ich will wissen, ob die von mir gehorteten Daten in Ordnung sind oder nicht und das will ich auch jederzeit nachträglich Prüfen können. Wem das egal ist dem ist es halt egal.

Wer ATRs ohne den Header prüfen möchte kann diesen ja abschneiden, es gibt sicher für so einige OS Hilfsprogramme, die das hinbekommen.

Mir wäre das zu umständlich gegenüber einem einfachen Vergleich mit einer Prüfsumme.

Wem die Prüfsumme zu umständlich ist der kann ja einen sektorbasierten Vergleich durchführen. Es gibt so einige Programme auf dem A8, die das können. Da ist zum Beispiel ein Sektorkopierer aus den 80ern, der das schon kann. Mein CLI Sektorkopierer (läuft unter SpartaDOS) kann das. Carsten hat mal einen in Forth geschrieben, der kann das glaube ich auch.

CU, Erhard

Erhard hat geschrieben:4) Daß das zum Erstellen der Master-Images der Magazine verwendete SIO2PC v1.21 im ATR-Header bei Byte 8 Bit 1 setzt ist halt ein bischen blöd, zumindest wenn es um einen Vergleich mit MD5-Prüfsummen geht, wenn ein anderes Programm beim Erstellen der Images dieses Bit eben nicht setzt.

Das könnte man vielleicht einfach dadurch lösen, daß man nach Erstellung der Master-Images mit SIO2PC mit einem HEX-Editor dieses Bit wieder auf Null setzt, und schon paßt alles.

Damit ich es richtig machen kann, frage ich zur Sicherheit noch einmal nach:

Wenn ich den Master bekomme, prüfe ich dieses Byte. Ist es gesetzt, ändere ich es.
Dann erstelle ich die physikalische Diskette und prüfe erneut, dieses mal auf dem Atari, ob das Byte gesetzt ist und ändere es gegebenenfalls erneut. Dann habe ich eine physikalische Masterdiskette, wo Byte 8, Bit 1 nicht gesetzt ist und das ist dann mein "Gold Master".

Richtig so? Wenn ja, richten wir uns als Standard-Vorgehen ein und dokumentieren das auch so.

CharlieChaplin hat geschrieben:Last not least, sieht das Abbuc Menü zwar schön aus, es ist aber leider furchtbar umständlich zu handeln.
[...]
Die Trennstriche werden mit dem Dir Master erzeugt, der unterstützt kein ultraspeed, sondern nur normal/slow speed.

Hilft das Miniprog im Anhang?
Es erzeugt aus BASIC heraus 1-9 Trennstriche als nächste(n) Dateieintr(ag/äge). Ggf. noch mit ABC kompilieren, damit es direkt aus dem DOS gestartet werden kann.

Erhard hat geschrieben:4) Daß das zum Erstellen der Master-Images der Magazine verwendete SIO2PC v1.21 im ATR-Header bei Byte 8 Bit 1 setzt ist halt ein bischen blöd, zumindest wenn es um einen Vergleich mit MD5-Prüfsummen geht, wenn ein anderes Programm beim Erstellen der Images dieses Bit eben nicht setzt.

Ich glaube nicht, dass es das SIO2PC ist. Ansonsten müssten ALLE Images das Bit gesetzt haben.

Erhard hat geschrieben:Wer sich mal IT-beruflich im Internet rumtreibt und Programme von verschiedenen Herstellern herunterladen muß der kann sehen, daß relativ viele die Authentizität Ihrer Programme mit einer MD5-Prüfsumme absichern.

Exakt das tut der ABBUC mit den Hashes auf der Downloadseite. Dass die von dir selbst erzeugte ATR davon abweicht, ist ein komplett anderes Thema.

Erhard hat geschrieben:Ich will wissen, ob die von mir gehorteten Daten in Ordnung sind oder nicht und das will ich auch jederzeit nachträglich Prüfen können. Wem das egal ist dem ist es halt egal.

Da es sich hier um dein persönliches Archiv handelt, solltest du dafür auch selbst die Prüfsummen erzeugen; und zwar in einem größeren Block von Dateien, die du dann auch effizient auf einmal überprüfen kannst.
Unter Linux bieten sich hierfür md5sum oder sha1sum an, die alle Dateien eines komplettes Verzeichnises in einer Prüfsummendatei zusammenfassen können. Es gibt sogar eine rekursive Variante, die einen kompletten Verzeichnisbaum bearbeitet. Analoge Programme gibt es auch für Windows.

Alternativ können die "Hardwareenthusiasten" mit einer auf der Diskette befindlichen CRC-Datei direkt die einzelnen Dateien auf der jeweiligen Diskette verifizieren. Das geht natürlich nur, wenn CharlieChaplin sich die Mühe aufhalsen lässt, die CRC-Datei auf der DIskette zu erstellen.

skriegel hat geschrieben:Damit ich es richtig machen kann, frage ich zur Sicherheit noch einmal nach:

Wenn ich den Master bekomme, prüfe ich dieses Byte. Ist es gesetzt, ändere ich es.

Du kannst sogar soweit gehen, dass nur die ersten sechs Byte des 16-Byte-Headers benutzt sind und alle danach $00 sind.

skriegel hat geschrieben:Dann erstelle ich die physikalische Diskette und prüfe erneut, dieses mal auf dem Atari, ob das Byte gesetzt ist und ändere es gegebenenfalls erneut. Dann habe ich eine physikalische Masterdiskette, wo Byte 8, Bit 1 nicht gesetzt ist und das ist dann mein "Gold Master".

Nein, weil die Modifikation nur den Header des ATR Images betrifft. Auf einer echten Diskette hat sie keinerlei Auswirkung, da dort ja nur die Datensektoren von hinter dem Header landen.

Mathy hat geschrieben:Wir brauchen also ein neues Menuprogramm.

Du bist doch einer DOS-Experten:
Welches DOS kann Batchdateien ausführen UND mit Dos 2.5 ED-Disketten umgehen?

Gerne darf das natürlich auch jemand anderes beantworten.

DjayBee hat geschrieben:
Hilft das Miniprog im Anhang?
Es erzeugt aus BASIC heraus 1-9 Trennstriche als nächste(n) Dateieintr(ag/äge). Ggf. noch mit ABC kompilieren, damit es direkt aus dem DOS gestartet werden kann.

Nun,

eine Datei kann einen Dateinamen mit 11 Zeichen (bekannt als 8.3) haben, daher benutze ich in der Directory natürlich auch 11 Trennstriche. 1-9 Trennstriche sind da etwas zu wenig.

Nebenbei, ich habe außer dem DIR Master auch den Dir Wizard (aus einem alten Abbuc Magazin), der unterstützt Speedy ultraspeed und kann auch solche Trennstriche erzeugen. Aber: Spezialeinträge in der DIR haben eine best. Status-Kennzeichnung (ich weiß nicht genau welche) und leider ist die Status Kennzeichnung der Spezialeinträge von DIR Master und DIR Wizard nicht identisch und wenn ich mich richtig erinnere mag das Abbuc Menü die Spezialeinträge vom DIR Wizard nicht.

Ich habe auch ein ML-Programm, das nix weiter kann, als 11 Trennstriche (-----------) in die DIR einzutragen, doch auf jeder Abbuc Diskette steht ja zu Beginn der DIR auch noch drin, um welche Ausgabe (z.B. Nr. 143) es sich handelt, um welches Quartal (z.B. 4. Quartal), welche Seite (z.B. Seite A), usw. usf. Ein Programm, das nur die Trennstriche beherrscht reicht mir also nicht... und wenn ich ein Programm lösche(n muss), dann muss ich meistens auch eine Zeile von Trennstrichen löschen oder "nach oben" verschieben.

Hi,

DjayBee hat geschrieben:

Mathy hat geschrieben:Wir brauchen also ein neues Menuprogramm.

Du bist doch einer DOS-Experten:
Welches DOS kann Batchdateien ausführen UND mit Dos 2.5 ED-Disketten umgehen?

Gerne darf das natürlich auch jemand anderes beantworten.

Bei BiboDos bin ich nicht so sicher, was das "AutoRun" kann, TurboDos kann auch was ?

Auf jeden Fall MyDos (4.50) mit dem Batch File E...? ( sorry, kann das Wort nicht ) Teil der 130XE+ Makro Assembler von T. Karwoth. Ist PD und in der Abbuc-PD. Anleitung habe ich, kann ich suchen, wenn gewünscht.
Evtl. auch im Atari-Wiki.




dl7ukk

DjayBee hat geschrieben:

Mathy hat geschrieben:Wir brauchen also ein neues Menuprogramm.

Du bist doch einer DOS-Experten:
Welches DOS kann Batchdateien ausführen UND mit Dos 2.5 ED-Disketten umgehen?

Gerne darf das natürlich auch jemand anderes beantworten.

DOS 2.5 mit einem mini-Batcheditor (Abtipplisting) aus Antic oder Analog, Turbo-DOS XL/XE, BiboDOS (? Option N - Startup batch ?), XDOS und vermutlich noch andere. Was soll denn mit der Batchdatei ausgeführt werden ?

MyDOS kann DOS 2.5 ED Format zwar lesen, beschreiben aber nur bis Sektor 719 oder 720, da MyDOS ein eigenes ED Format benutzt (2.VTOC in Sektor 359, wenn ich mich nicht irre; bei DOS 2.5 ist die 2.VTOC in Sektor 1024).

Mein kleines Programm legt natürlich 1-9 komplette Trennstriche, also Zeilen mit dem korrekten Status an.
Die Idee für die mehreren Zeilen ist, sie erst einmal als Platzhalter zu verwenden und zum Schluss mittels Disk Editor zum inversen Text zu machen.

Als Erklärung für die Batchfrage:
In Altirra kann ein Hostverzeichnis als Laufwerk H: verwendet werden.
Dort kannst Du alle Dateien für das Magazin sammeln.
Dann editierst du dir nur noch die Batchdatei und kannst dir in Sekunden alle Dateien mit Trennstrichen in der richtigen Reihenfolge automatisch zusammen kopieren lassen.
Den "Header" mit Disknummer usw. erstellst du anfangs nur als 6 Trennstriche und machst erst zum Mastering mit dem Disk Editor deiner Wahl den echten Text daraus. Wobei das Miniprogramm natürlich auch so geändert werden kann, dass der Text damit eingegeben werden kann. Ich hatte nur keine Lust, ein komplexes Stringhandling zu schreiben.

@DjayBee: PN gesendet!

Mathy hat geschrieben:Hallo Leute

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

Tschüß

Mathy

Brauchen wir?
Wann hast Du es fertig?

Erinnerung: Wir haben auch dieses Jahr einen Software Wettbewerb

Hallo,

skriegel hat geschrieben:Damit ich es richtig machen kann, frage ich zur Sicherheit noch einmal nach:
Wenn ich den Master bekomme, prüfe ich dieses Byte. Ist es gesetzt, ändere ich es.

Es tut mir leid, daß die Sache so einen Aufstand verursacht.

Ich kann das gerne für Dich regelmäßig tun, dann brauchst Du Dich nicht damit rumschlagen. Es ist ja auch nicht wirklich viel Aufwand, dieses eine Byte im Bedarfsfall auf #$00 zu setzen.

skriegel hat geschrieben:Dann erstelle ich die physikalische Diskette und prüfe erneut, dieses mal auf dem Atari, ob das Byte gesetzt ist und ändere es gegebenenfalls erneut. Dann habe ich eine physikalische Masterdiskette, wo Byte 8, Bit 1 nicht gesetzt ist und das ist dann mein "Gold Master".

Ein solcher Vorgang ist nicht erforderlich. Der Atari bekommt von diesem Bit im ATR-Header ohnehin nichts mit. Das ATR an sich funktioniert ja auch, wenn dieses Bit gesetzt ist - ich weiß von keinem Programm, was sich an dem gesetzten Bit stört. Es führt halt nur zu unterschiedlichen Prüfsummen.

CU, Erhard

Hi,

DjayBee hat geschrieben:Exakt das tut der ABBUC mit den Hashes auf der Downloadseite. Dass die von dir selbst erzeugte ATR davon abweicht, ist ein komplett anderes Thema.

Da hast Du grundsätzlich recht. Es ist allerdings schade, daß ich in diesem Fall anhand der auf der ABBUC Webseite veröffentlichten Prüfsumme nicht die Integrität der von mir erhaltenen Disk überprüfen kann.

Vielmehr muß ich in dem Fall das ATR herunterladen, dieses gegen die Prüfsumme prüfen um Fehler bei der Übertragung auszuschließen und dann einen sektorbasierten Vergleich mit meiner Disk bzw dem ATR davon durchführen.

DjayBee hat geschrieben:Da es sich hier um dein persönliches Archiv handelt, solltest du dafür auch selbst die Prüfsummen erzeugen;
überprüfen kannst.

Es nützt aber nichts, wenn ich Prüfsummen über Daten erzeuge, von denen ich nicht weiß, ob sie in Ordnung sind.

DjayBee hat geschrieben:und zwar in einem größeren Block von Dateien, die du dann auch effizient auf einmal

Genau so läuft das. Ich prüfe mein Archiv vor jeder Sicherung und zwischendurch bei Änderungen. Rechtsklick auf den in der Hirarchie obersten Ordner -> Prüfsumme verifizieren. 30 Sekunden später bin ich schlauer.

MfG, Erhard

Erhard hat geschrieben:Hi,

Da hast Du grundsätzlich recht. Es ist allerdings schade, daß ich in diesem Fall anhand der auf der ABBUC Webseite veröffentlichten Prüfsumme nicht die Integrität der von mir erhaltenen Disk überprüfen kann.

Hallo Erhard wäre es nicht möglich das du die Prüfsumme einfach berechnest wenn du das Bit im ATR Header setzt und dann vergleichst. Wenn es dann passt ist dein Image OK.

Hi,

tomsmart1 hat geschrieben:Hallo Erhard wäre es nicht möglich das du die Prüfsumme einfach berechnest wenn du das Bit im ATR Header setzt und dann vergleichst. Wenn es dann passt ist dein Image OK.

klar. Das ist nicht viel zusätzliche Arbeit. Die fällt dann freilich für jeden an, der das auch prüfen will und dessen "Imaging Software" wie z.B. APE das Bit auch nicht setzt und vielleicht hat der ein - oder andere nicht die Kenntnisse und / oder will sich nicht damit beschäftigen, in der ATR-Datei mit einem HEX-Editor für Windows oder ein anderes OS rumzufudeln. Das ist vielleicht auch fehleranfälliger als wenn es einfach von vornherein passen würde.

Unterm Bruchstrich ist es nicht nötig, das zig Leute sich in Arbeit stürzen, um es möglicherweise nur "erhardgerecht" passend zu machen.

Aber es ist dann halt zumindest meiner Meinung nach keine runde Lösung.

Ich versuche mal am WE etwas Zeit zu finden und schau mal, ob ich SIO2PC bei mir ans laufen krieg und probier das mal selber aus. Vielleicht gibt es da irgendwo irgendeine Einstellung ... Allerdings hat wenn ich mich recht erinnere zuletzt mein RS232-to-SIO Interface nicht geklappt, vielleicht lag es aber auch nur an RTS/CTS o.ä.

CU, Erhard

Vielleicht kann einer unser C bzw. Java Speziallisten ein kleines Programm schreiben das dieses entsprechende Bit passend setzt ( nach dem allgemeinen verwendeten Standard) und gegebenenfalls dann gleich die md5sum berechnet und dieses Image und die md5sum dann Online stellt.

tomsmart1 hat geschrieben:Vielleicht kann einer unser C bzw. Java Speziallisten ein kleines Programm schreiben

Warum so umständlich und nicht direkt von der bash aus?
echo "0000008: 00" | xxd -r - MAG143A.ATR