Hi,

1) Gibt es Laufwerke, die die Percom-Kommandos nicht kennen und mit Kommando 33 ein anderes Format als Single (720 SD-Sektoren) erzeugen?

Da muß ich passen. Bei älteren Sparta DOS Versionen ist ein Formatierprogramm bei, daß zum Beipiel das Auswählen von 35-Track Laufwerken gestattet, aber ob da vorher ein PERCOM-Kommando gesendet wird oder was sonst passiert, müßte man ausprobieren.

2) Gibt es Laufwerke, die zwar das Percom-Get-Kommando kennen, aber nicht das Percom-Put-Kommando? (wäre denkbar, wenn das Laufwerk nur ein Format kennt bzw. das Laufwerk ein ATR ist)

Weiß ich auch nicht, aber (bei ATR) sie sollten besser auch das Put-Kommando kennen, dieses aber mit Error beantworten, wenn die geschriebene Konfiguration nicht dem ATR entspricht.

3) Gibt es Laufwerke, die sich zwar über den Percom-Block + Kommando 33 in Medium formatieren lassen, aber nicht mit dem Kommando 34?

Ich kenne kein Laufwerk, daß MD per Percom und $21 macht.

4) Welchen Fehler bekommt man, wenn ein Laufwerk beim Percom-Put-Kommando den Percom-Block nicht mag (weil es das gewünschte Format nicht unterstützt)?
- Error 139, weil der Percom-Block falsch ist
- Error 144, weil es das Kommando nicht ausführen kann

Es muß ein Error kommen. Ein NACK wird gesendet, wenn sich ein Gerät angesprochen fühlt, es das Kommando aber nicht kennt.

5) Welche Laufwerke reagieren allergisch, wenn man ihnen ein Percom-Put ohne voriges Percom-Get schickt (d.h. Überschreiben der Bytes 1, 8-11 im Percom-Block mit irgendwelchen Werten)?

Grundsätzlich sollte keines allergisch reagieren, denn der Benutzer kann auch dann Schrott senden, wenn er vorher den Block gelesen hat. Allerdings sollte es Best-Practice sein, den Block vorher zu lesen, damit man nicht ungewollt z.B. die Steprate verändert. Dafür gibt es ja ein Byte im Percom Block und zum Beispiel das HDI verwendet ihn auch.

Viele Grüße

Erhard

Danke Erhard

Dietrich hat geschrieben:4) Welchen Fehler bekommt man, wenn ein Laufwerk beim Percom-Put-Kommando den Percom-Block nicht mag (weil es das gewünschte Format nicht unterstützt)?
- Error 139, weil der Percom-Block falsch ist
- Error 144, weil es das Kommando nicht ausführen kann

Erhard hat geschrieben:Es muß ein Error kommen. Ein NACK wird gesendet, wenn sich ein Gerät angesprochen fühlt, es das Kommando aber nicht kennt.

Na ja, wenn ich versuche, Sektor 0 von einer Disk zu lesen, kriege ich ein NACK und keinen Error, obwohl das Kommando 'R' natürlich bekannt ist.
Ich sehe das so, dass NACK kommt, wenn das Problem vor dem Bildschirm sitzt (d.h. der Programmierer oder der User ein fehlerhaftes Kommando abschickt) und einen Error, wenn das Kommando OK ist, aber das Gerät ein Problem hat (z.B. Disk schreibgeschützt, kein Papier im Drucker usw.)
So gesehen, würde ich einen NACK beim Datenblock erwarten (weil der falsch ist) - aber sicher bin ich mir da nicht.

Dietrich hat geschrieben:5) Welche Laufwerke reagieren allergisch, wenn man ihnen ein Percom-Put ohne voriges Percom-Get schickt (d.h. Überschreiben der Bytes 1, 8-11 im Percom-Block mit irgendwelchen Werten)?

Erhard hat geschrieben:Grundsätzlich sollte keines allergisch reagieren, denn der Benutzer kann auch dann Schrott senden, wenn er vorher den Block gelesen hat. Allerdings sollte es Best-Practice sein, den Block vorher zu lesen, damit man nicht ungewollt z.B. die Steprate verändert. Dafür gibt es ja ein Byte im Percom Block und zum Beispiel das HDI verwendet ihn auch.

Sorry, habe mich unklar ausgedrückt. Ich meinte mit allergisch, dass das Laufwerk komische Sachen macht (z.B. weil man die Steprate verändert). Welche Laufwerke reagieren darauf?
Wozu sollte man eigentlich die Steprate mit dem Percom-Kommando ändern? Das Laufwerk kann doch selber viel besser entscheiden, welche Steprate es braucht!

Gruß Dietrich

Hallo Dietrich,

Na ja, wenn ich versuche, Sektor 0 von einer Disk zu lesen, kriege ich ein NACK und keinen Error, obwohl das Kommando 'R' natürlich bekannt ist.
Ich sehe das so, dass NACK kommt, wenn das Problem vor dem Bildschirm sitzt ...

Man könnte es so definieren: wenn bei der Ausführung eines Kommandos das Gerät auf ein Problem trifft, dann gibt es ein Error. Beim Lesen von Sektor 0 kommt dann eben ein NACK, weil es Sektor 0 laut Definition nicht gibt und somit das Kommando an sich fehlerhaft ist.

Da ist "meine Grenze" aber sehr viel einfacher und klarer zu sehen und auch zu programmieren, denn sonst muß man hergehen und diese grenzwertigen Ausnahmen abarbeiten. Und es wird bestimmt nicht viele Fälle geben wie ein NACK weil es Sektor 0 nicht gibt aber möglicherweise ein Error beim Lesen von Sektor 5761 auf einer 1.44 MB Scheibe (wo es nur 5760 Sektoren gibt).

Da hilft nur, vorhandene Atari Originalhardware analysieren. Ich denke es steht fest:
- ein dem Gerät unbekanntes Kommando ergibt ein NACK
- ein Fehler bei der Ausführung eines Kommandos ergibt ein ERROR

Bleibt noch zu untersuchen, in welchen Fällen bei einem bekannten Kommando ein NACK gesendet wird, wie z.B. beim Versuch, Sektor 0 zu lesen oder zu schreiben. Wenn die Definition annehmen, daß von vornherein unmögliche Parameter ein NACK verursachen, ergäbe z.B.:

- Track 81 auf eine 80-Track LW ein NACK aber
- 37 Sektoren pro Spur ein ERROR, weil er bei HD ja draufpassen könnte.

Ich meinte mit allergisch, dass das Laufwerk komische Sachen macht (z.B. weil man die Steprate verändert). Welche Laufwerke reagieren darauf?
Wozu sollte man eigentlich die Steprate mit dem Percom-Kommando ändern? Das Laufwerk kann doch selber viel besser entscheiden, welche Steprate es braucht!

Da hast Du schon recht. Ich hab das mit der Steprate damals beim HDI mit in den PRECOM Block übernommen weil es laut Spezifikation dafür halt ein Byte gab und ich ohnehin mit verschiedenen Werten experimentieren mußte. Natürlich könnte ich die Firmware so umschreiben, daß andere Werte ignoriert werden. Aber dieses Problem gilt auch für weitere Bytes des PERCOM Blocks:

Man könnte hergehen, und eine Disk mit 80 Tracks in DSDD formatieren und dann noch einmal mit 77 Tracks in DSSD. Damit hätte man dann eine Disk, wo die ersten 77 Tracks auf beiden Seiten SD sind und die letzten 3 sind DD.

Oder man könnte eine Disk mit 40 Tracks SSSD formatieren, aber das MFM-Bit setzen. Das wäre dann so ein Format wie MD, nur halt noch ein paar Sektoren weniger.

Man muß sich hier wohl entscheiden, ob der PERCOM Block ein Konfigurationsblock ist oder eine den Benutzer einschränkende Auswahlliste. Was wäre wohl der Atari, wenn man die SIO so eingeschränkt hätte, daß der Atari Grenzen deutlich unterhalb des machbaren setzen würde? Blockgrößen nur für Cassette, Drucker und Disk? Dann gäb es wohl recht viele Erweiterungen nicht und vielleicht sehr viel weniger Atari 8-Bit Fans und vielleicht auch keinen ABBUC.

Wenn man Grenzen beim PERCOM Block setzen will dann vielleicht solche, daß man durch Programmierung keine Hardware schrotten kann. Also vielleicht die Anzahl der Tracks, damit das LW den Kopf nicht jedes mal gegen die mechanische Grenze knallt, wobei sich das auch schon fast erübrigt, weil die meisten Laufwerke ohnehin nicht weiter steppen als bis zur innersten Spur (Lichtschranke o.ä.).

Viele Grüße

Erhard