810 und 1050 per SIO unterscheiden

[DjayBee]

Weiß jemand, ob/wie man nur per SIO-Calls eine 810 von einer 1050 unterscheiden kann?

Unterschiedliche Statuscodes bei defekten Sektoren gelten nicht.

[HiassofT]

Einfach ein Enhanced Density Format Kommando ($22) absetzen, bei einer 810 kriegst Du einen Fehler, bei einer 1050 hast Du ca 1min später eine frisch formatierte Diskette :-)

so long,

Hias

[HiassofT]

OK, oder etwas weniger destruktiv könntest Du das $23 diagnostic Kommando verwenden - siehe Altirra Hardware Reference Manual Kapitel 10.15
https://virtualdub.org/downloads/Altirr ... Manual.pdf

Zumindest bei einer 1050 mit original ROM sollte das konsistente Ergebnisse liefern - bei den Happy/Speedy/... Erweiterungen könnt's ein Glückspiel werden ob bzw welche der diagnostic (sub-)Kommandos unterstützt werden.

so long,

Hias

[tfhh]

Moin,

Weiß jemand, ob/wie man nur per SIO-Calls eine 810 von einer 1050 unterscheiden kann?

Nicht verifiziert und nur aus Überlegung / dunkler Erinnerung... ich meine, die 810er mit Standard-Firmware (keine Happy etc.) meldet einen anderen Fehlercode, wenn Du versuchst auf Sektor >720 zuzugreifen. Die 1050 meldet bei einer eingelegten Single Density Disk oder nach Power-On einen anderen Fehler als die 810, aber das mag auch nicht zutreffen oder firmware-abhängig sein. Probier´s mal aus.

Gruß, Jürgen

[Erhard]

Ich habe leider keine 810 ...

aber als ich damals das HDI gebaut habe benutzte ich die Antworten einer 1050 auf Kommandos als Vorlage dafür, wann das HDI wie zu antworten hat.

Da waren dann auch so Sachen dabei wie das Lesen eines Sektors, der nicht innerhalb der Größe des Datenträgers liegt.

Ich glaube, die 1050 antwortet da einfach mit einem NACK auf das Kommando.

Das Laufwerk könnte ja auch auf die Idee kommen, mit einem ERROR zu antworten und bei einer Statusabfrage das Bit für RNF zu setzen. Ich empfände dies aber als falsch, denn einen RNF Fehler sollte es nur dann geben, wenn es den Sektor geben müßte, er aber auf dem Datenträger fehlt.

Wenn also jemand eine 810 ohne Erweiterung hat und derjenige auch bewandert in der Bedienung eines Debuggers (Freezer, Bug/65 o.ä.) ist könnte derjenige einmal einfach bei eingelegter SD Disk Sektor 1 lesen (um zu schauen, ob alles einwandfrei geht) und dann einmal Sektor 721, sich dann den DCB anschauen und das Ergebnis melden.

Wenn man es ganz genau haben will benötigt man einen Logikanalysator, der die Kommunikation auf dem SIO-Bus mitschnüffellt und dann hex-interprätiert darstellt.

Einfacher wäre es mit einem echten SIO-SPY, der Einfachheit halber einer Software auf dem PC, die 2 serielle Eingänge verwendet, um DIN und DOUT auf dem SIO-BUS mitzulesen und passend zum Zeitversatz (am besten mit Echtzeitangaben) in einem Fenster links und rechts entsprechend versetzt darzustellen.

Sowas ließe sich vielleicht auch in abgespeckter Form auf einem Atari realisieren: man führt die Signale von DIN und DOUT über Dioden zur Entkopplung zusammen und dann an den Eingang eines zweiten Atari. Der POKEY und das Programm im Hintergrund haben dann richtig viel zu tun um synchron mit der Kommunikation zu bleiben, sonst können Kommandos, geschriebene und gelesene Daten hinterher nicht auseinander gehalten werden. Und einmal die falsche Bitrate programmiert und dann wäre eh Ende. Sicherlich sollte CMD noch mit INTerrupt verbunden werden damit der spionierende Atari eine Chance hat, den Anfang der Kommunikation zu erkennen, vielleicht auch noch irgendwie CLKout mit CLKin verbinden, da der POKEY ein externes Taktsignal zum Einlesen von Daten verwenden kann. Das darf man dann aber wieder nur während eines Kommandos verwenden weil nur daran der 2. A8 erkennen kann, das der Takt anliegen muß. Dann anhand der Dauer die Geschwindigkeit berechnen und die POKEY-Timer für das Lesen der restlichen Daten programmiern. Natürlich den ganzen Krempel auch noch speichern (am besten in einer großen Speichererweiterung) und für den Benutzer abrufbar machen.

Uuups, da bin ich aber abgeschwoffen ... sry.

CU, Erhard

[DjayBee]

Ich hab's jetzt über die unterschiedlichen Statuscodes für lange (810:$FC, 1050:$F1) und deleted (810:$9F, 1050:$DF) Sektoren gemacht. Die hatte ich schon auf meiner Diskette drauf, hätte aber gerne etwas verwendet, das mit jeder eingelegten Diskette funktioniert.

Ich war mit meiner Anfrage etwas ungenau:
Primär wollte ich herausfinden, ob der jeweils korrekte der beiden obigen Statuscodes zurückgegeben wird. Jetzt zeige ich den erhaltenen Status einfach an und Mensch weiß ja, welches Laufwerk er gerade emulieren will.

Meine Diskette mit dem Testprogramm formatieren ist keine Option.
Die Testbefehle $22 und $23 scheinen auf einigen/vielen modifizierten 1050ern auch nicht vorhanden zu sein, weshalb sie mir nicht universell genug sind.

Und NAKen tun alle Laufwerke wenn sie eine ungültige Sektonummer lesen sollen.

[JoSch]

[..]
Einfacher wäre es mit einem echten SIO-SPY, der Einfachheit halber einer Software auf dem PC, die 2 serielle Eingänge verwendet, um DIN und DOUT auf dem SIO-BUS mitzulesen und passend zum Zeitversatz (am besten mit Echtzeitangaben) in einem Fenster links und rechts entsprechend versetzt darzustellen.
[..]

In aktuellen Respeqt RC kann man schon die Anforderungen des Computers mitloggen, damit man den Code debuggen zu können, ohne sofort in einen Timeout zu rennen.
Würde es für Euch mehr Sinn machen, das Aufzeichnen komplett in eine neue App auszulagern, so dass man eine SIO-Sniffer hätte, der dann die komplette Kommunikation aufzeichnen kann?

[DjayBee]

In aktuellen Respeqt RC kann man schon die Anforderungen des Computers mitloggen, damit man den Code debuggen zu können, ohne sofort in einen Timeout zu rennen.
Würde es für Euch mehr Sinn machen, das Aufzeichnen komplett in eine neue App auszulagern, so dass man eine SIO-Sniffer hätte, der dann die komplette Kommunikation aufzeichnen kann?

Ich brauch das nicht, aber den kompletten SIO-Verkehr sniffen zu können ist sicher eine gute Idee.

Ob's dazu aber ein separates Programm braucht anstatt nur einer Option in RespeQt zweifle ich mal an. Der Wartungsaufwand wird dann ja höher und wenn RespeQt keine Diskimages geladen hat, verhält es sich meines Wissens ja auch komplett passiv. Oder?

[JoSch]

In aktuellen Respeqt RC kann man schon die Anforderungen des Computers mitloggen, damit man den Code debuggen zu können, ohne sofort in einen Timeout zu rennen.
Würde es für Euch mehr Sinn machen, das Aufzeichnen komplett in eine neue App auszulagern, so dass man eine SIO-Sniffer hätte, der dann die komplette Kommunikation aufzeichnen kann?

Ich brauch das nicht, aber den kompletten SIO-Verkehr sniffen zu können ist sicher eine gute Idee.

Ob's dazu aber ein separates Programm braucht anstatt nur einer Option in RespeQt zweifle ich mal an. Der Wartungsaufwand wird dann ja höher und wenn RespeQt keine Diskimages geladen hat, verhält es sich meines Wissens ja auch komplett passiv. Oder?

Nein, RespeQt kann trotzdem den ganzen SIO-Verkehr mithören. Nur wenn die Verbindung explizit gekappt wird, hört RespeQt nicht mehr mit.

[DjayBee]

Mit "passiv" habe ich gemeint "lauscht tut aber nix".

[Erhard]

Hi,

RespeQt kann trotzdem den ganzen SIO-Verkehr mithören.

das stimmt so nicht. Man kann alle "command frames" sehen, aber weder die Datenblöcke des A8 (die RespeQt sehen und anzeigen könnte) noch die Antworten von anderen Geräten (die kann RespeQt nicht sehen) noch Protokollantworten.

CU, Erhard

[JoSch]

Hi,

RespeQt kann trotzdem den ganzen SIO-Verkehr mithören.

das stimmt so nicht. Man kann alle "command frames" sehen, aber weder die Datenblöcke des A8 (die RespeQt sehen und anzeigen könnte) noch die Antworten von anderen Geräten (die kann RespeQt nicht sehen) noch Protokollantworten.

CU, Erhard

Das ist doch ein geteilter Bus. Man müsste doch den kompletten Verkehr sehen können, auch wenn man nicht teilnehmen kann.

[Erhard]

Hi,

Das ist doch ein geteilter Bus. Man müsste doch den kompletten Verkehr sehen können, auch wenn man nicht teilnehmen kann

das wäre der Fall, wenn der Datenverkehr für gesendete und empfangene Daten über die gleiche Leitung gehen würde (1-Wire, I2C).

Der PC mit RespeQt empfängt aber auf der einen Leitung (das, was der Atari sendet) und sendet auf der anderen und auf der Leitung, auf der er sendet senden auch alle anderen Peripheriegeräte.

Auf der Sendeleitung kann er nichts empfangen.

CU, Erhard

[JoSch]

Hi,

Das ist doch ein geteilter Bus. Man müsste doch den kompletten Verkehr sehen können, auch wenn man nicht teilnehmen kann

das wäre der Fall, wenn der Datenverkehr für gesendete und empfangene Daten über die gleiche Leitung gehen würde (1-Wire, I2C).

Der PC mit RespeQt empfängt aber auf der einen Leitung (das, was der Atari sendet) und sendet auf der anderen und auf der Leitung, auf der er sendet senden auch alle anderen Peripheriegeräte.

Auf der Sendeleitung kann er nichts empfangen.

CU, Erhard

Ah jetzt verstehe ich, was Du meinst. Wir bräuchten also einen Mikrocontroller, um TX und RX mitzulesen und dann z.B. per USB an den PC zu geben.

[Erhard]

Hi,

Ah jetzt verstehe ich, was Du meinst. Wir bräuchten also einen Mikrocontroller, um TX und RX mitzulesen und dann z.B. per USB an den PC zu geben

ja, oder 2 genügend schnelle Eingänge am PC.

Auf jeden Fall sollte der PC hinterher anzeigen können was RX und was TX war und am besten noch mit akzeptabel genauer Zeitanzeige.

Mit einem Logikanalysator kommt man zwar in die Richtung und kann sehr genaue Zeiten ablesen, aber da machen lange und viele Datenblöcke keinen Spaß.

CU, Erhard