XS-1541 mit sd2iec Firmware?

Ich habe mal den von Helmut vorgeschlagenen Umbau ausprobiert, mit dem der Hardware-Handshake NDAC IN / DAV OUT künstlich verzögert wird. Der Aufbau beinhaltet einen Poti, mit dem die Verzögerung eingestellt werden kann.
Bei der langsamsten Einstellung, bevor es zum Abbruch kommt, wird ein Directory von einer SFD-1001 mit der atemberaubenden Geschwindigkeit von ca. 16 cps angezeigt.
Der Zugriff aufs petSD funktioniert nur, wenn auch eine CBM-Floppy mit angeschlossen ist, sonst gibts immer nur ?device not present. Die Directory-Anzeige ist dabei (bei normal eingestellter Handshake-Verzögerung) merklich langsamer als von der Floppy.
Allerdings nimmt das petSD auch Einfluß auf die Übertragung zur CBM-Floppy. Wenn die Verzögerung des Handshake normal eingestellt ist, wird die Dirctory-Anzeige von der Floppy merklich langsamer und bricht auch schonmal ab.

Was das jetzt alles zu bedeuten hat, kann ich leider auch nicht sagen, allerdings finde ich es erstaunlich, daß ein aneschlossenes petSD die Übertragung zur Floppy so stark beeinflusst.

Zitat von fachat

Benutzt petSD die IEEE488 routinen des sd2iec?
Die sind m.E. noch nicht ganz ausgereift...

wiso ist sd2iec noch nicht ganz ausgereift?
welche probleme gibt es?

wo gibt es den schaltplan für original sd2iec?

wird den handshake im sd2iec alles softwaremässig gemacht?

oder ist da auch eine hardwaremässige schaltung für handshake wie in eine 1541
und allen anderen cbm-bus geräten, selbst in den druckern.
damit der cbm-bus ohne timing, parallel und leitungs problemen läuft.

da ist hardware handshake aufgebaut (z.b. bei der 1541) mit
74ls86, 74ls14 und 7406 für atn, atna und data
damit man selbst mit einem sehr langsammen prozessor alles einwandfrei,
ohne probleme und ohne großen softwareaufwand lösen kann.

deswegen vermute ich das bei den original versionen, von sd2iec,
zusatzhardware zum avr eingebaut wurde und nicht
an den ca. 50 cent gespart wurde.

Zitat von axorp

wo gibt es den schaltplan für original sd2iec?

Es gibt keinen, sd2iec ist nur die Software.

Zitat

wird den handshake im sd2iec alles softwaremässig gemacht?

Ja

Zitat

deswegen vermute ich das bei den original versionen, von sd2iec,
zusatzhardware zum avr eingebaut wurde und nicht
an den ca. 50 cent gespart wurde.

Es gibt keine Hardware auf der sd2iec läuft, die den ATN-Handshake des seriellen Bus in Hardware implementiert hat.

Zitat von Unseen

Es gibt keine Hardware auf der sd2iec läuft, die den ATN-Handshake des seriellen Bus in Hardware implementiert hat.

schade, so ist der software und timing aufwand sehr groß.
da der avr sehr viele sachen machen muss.

ich habe früher ( vor ca. 30 jahren ) bei meinen entwicklungen
immer ein hardware handshake gemacht.
für cbm-ser.-bus und den ieee488/iec-parallel-bus.

ich bin nicht zuhause, erst anfang nächste woche,
werde nachsehen ob ich es auch mit den ICs 74ls86, 74ls14 und 7406,
bei dem cbm-ser.-bus gemacht habe.

für den parallen bus ieee488/iec-bus habe ich vor ein paar tagen,
in meinen alten unterlagen, nachgesehen.

z.b. 64kb iec-iec druckerbuffer, iec-centronics druckerbuffer,
iec-rs232/v24 buffer interface, iec i/o steuerung usw.

da habe ich die schaltung von commodore in z.b. 4031 oder 2031
mit 74ls86, 74ls14 und 7406 nicht genommen.

sondern eine eigene schaltung mit nur einem IC.
da habe ich den 7433 genommen. der kann auch max. 48mA treiben.
aber nur max. 5V. deswegen musste ich eventuelle überspannungen
mit dioden an +5V und masse ableiten.
meine schaltung bestand aus: 1 x 7433 und 4 dioden 1n4148
(für überspannung wie bei späterem C64) und einem widerstand 10 kohm.

auch bei meiner version vom ieee488-modul für C64 habe ich
hardwarehandshake so vorgesehen. somit war es möglich den
c64 als listener zu betreiben. er verhielt sich wie eine
ieee488 floppy, drucker, erfassungs terminal, i/o-steuerung, messgerät usw.
am ieee488/iec-bus der großen cbm geräte.

im normalen talker modus war es ein normales ieee488-c64 modul.
open mit adresse 4 - 19 war der serielle bus am c64 und
adresse +16 (ab 20) der parallele ieee488 bus im modul.
oder je nach kernal-rom oder software auch umgekehrt.

Zitat von Toast_r

Bei der langsamsten Einstellung, bevor es zum Abbruch kommt, wird ein Directory von einer SFD-1001 mit der atemberaubenden Geschwindigkeit von ca. 16 cps angezeigt.

es geht noch langsammer mit der handshake ausgabe als mit 16 zeichen pro sekunde.

früher (pet) habe ich interface gebaut die nicht mehr
als (1) 2 zeichen pro sekunde ausgeben durften,
z.b. ansteuerung einer ibm-kugelkopf schreibmaschine
mit elektromagneten unter jeder taste (eine spezielle ibm version)
oder ansteuerung eines lochstreifenstanzers usw.

leider würde ich ein petSD benötigen um es untersuchen zu können.
welche handshakesignale da stören.

Zitat von Toast_r

Ich habe mal den von Helmut vorgeschlagenen Umbau ausprobiert, mit dem der Hardware-Handshake NDAC IN / DAV OUT künstlich verzögert wird. [...] allerdings finde ich es erstaunlich, daß ein aneschlossenes petSD die Übertragung zur Floppy so stark beeinflusst.

Wenn ich das richtig verstanden habe, besteht Helmuts Schaltung aus einem Monoflop, das bei der fallenden Flanke von ATN die Signale NRFD und NDAC für eine gewisse Zeit auf low zieht -- mindestens so lange, bis das petSD aus dem Quark gekommen ist, selbiges in Software zu erledigen.
Diese Schaltung wirkt ja nunmal nicht selektiv, muss also Einfluss auf jeden Busteilnehmer haben.

Kompliment an Helmut für eine Schaltungsidee, die tatsächlich gänzlich ohne weitere Ports am AVR auskommt!

Zitat von fachat

Benutzt petSD die IEEE488 routinen des sd2iec?
Die sind m.E. noch nicht ganz ausgereift...

Vielen Dank für die ausgesprochen freundliche Formulierung

Zitat von axorp

wiso ist sd2iec noch nicht ganz ausgereift?

Jetzt tust Du Unseen Unrecht... sein sd2iec ist sicher schon recht ausgereift, was man von meinen Routinen für den IEEE-Bus bestimmt nicht behaupten kann. Ich habe diesen "dirty hack" im anfänglichen Überschwang veröffentlicht, weil es eben dadurch überhaupt möglich wurde, mit dem CBM auf SD-Karten zuzugreifen -- es war nie geplant, das so lange in dieser Form zu lassen. Leider ist es mir trotz intensiver Bemühungen bislang nicht gelungen, den Status Quo zu verbessern, was schon frustrierend ist. Da fängt man schon mal an zu überlegen, ob Programmieren wirklich das richtige Hobby ist, oder ob man nicht doch besser im TV anderen Jungs beim Ball spielen oder Auto fahren zugucken sollte.

Zitat von axorp

welche probleme gibt es?

Nur den üblichen Ressourcenmangel: zu wenig Zeit, zu wenig Gehirnschmalz...

Wenn ich so genau definieren könnte, was eigentlich das Problem ist, wäre ich schon einen guten Schritt weiter. Ich vermute, dass das ATN-Acknowledge in Software gelegentlich doch zu langsam ist und dann das ganze Protokoll aus dem Schritt bringt. Bislang ist das lediglich eine Vermutung. In meinen IEEE-Routinen ist aber noch ein dicker Hund vergraben, der mit dem Timeout zusammenhängt: meine Routinen handeln das komplette IEEE-Protokoll mit Timeout (64 ms) ab. Wenn innerhalb dieser Zeit nicht die erwartete Reaktion kommt, brechen sie die Kommunikation ab und gehen in den Grundzustand. Wie ich das IEEE-Protokoll verstanden habe, sollte es eigentlich komplett ohne Timeout auskommen, da ja alles über Signalleitungen und deren Protokoll abgefrühstückt wird. Ohne Timeout (sprich: unbegrenztes Warten) hängt sich mein Code aber irgendwo auf -- ich konnte nicht klären, wann und wo. Macht man das Timeout zu kurz, ist einer der Busteilnehmer in der kurzen Zeit noch nicht bereit (petSD hat Daten noch nicht von SD-Karte gelesen / CBM hat Daten nicht übernommen), macht man es zu lang, verzögert man die Kommunikation, weil an irgendeiner Stelle in's Timeout gegangen wird -- und das eben erst nach besagter Verzögerung.

Ich denke, man sollte diesen Routinen keine Beachtung mehr schenken, und sich statt dessen auf die überarbeitete Version von A. Fachat konzentrieren, der mit dem IEEE-Bus wesentlich bewanderter ist, als ich es bin. Ich hoffe sehr, dass es ihm gelingt, im Rahmen seines XD2031-Projekts noch stabile Bus-Routinen zu entwickeln.

Zitat von axorp

wo gibt es den schaltplan für original sd2iec?

Wahrscheinlich meinst Du das petSD? In meiner Signatur findest Du den Link auf die Projektseite, dort liegt auch der Schaltplan. Das ist hier aber eher nebensächlich.
A. Fachat entwickelt auf der XS-1541-Hardware, nicht auf petSD-Hardware. Den XS-1541-Schaltplan findest Du hier, im Grunde ist das nur ein AVR (mega644 oder mega1284) an den IEEE-Bus geklöppelt, zusammen mit einer seriellen Schnittstelle -- das kann man etwas Leidensfähigkeit vorausgesetzt auch an einem Nachmittag zusammen löten.

Zitat von axorp

wird den handshake im sd2iec alles softwaremässig gemacht? [...]deswegen vermute ich das bei den original versionen, von sd2iec, zusatzhardware zum avr eingebaut wurde und nicht an den ca. 50 cent gespart wurde.

Geld hat da ganz bestimmt keine Rolle gespielt. Ich habe nie und wollte nie das petSD vertreiben, so dass mir relativ schnurz war, was es kostet. Und Donald, der den Vertrieb dankenswerterweise übernommen hat, hat mir nie Vorgaben gemacht, wie das petSD sein sollte, sondern völlig freie Hand gelassen. Für den (aus heutiger Sicht) Fehler, das ATN-Acknowledge in Software zu machen, sind zwei Gründe maßgeblich:

1.) das petSD sollte einfach nachzubauen sein und alles, was nicht vorhanden ist, muss man weder bezahlen, noch verlöten, noch kann es kaputt gehen.
2.) war ich sehr von der ungeheuren Entwicklungsleistung der Machern der Harmony-Cartridge für das Atari VCS 2600 beeindruckt: da "lauscht" ein ARM am Adressbus der 6507 und entscheidet dann aufgrund der anliegenden Adresse, des geladenen Spiels und des dort verwendeten Banking-Switching-Mechanismus, welches Datenbyte er auf den Bus legt. Dabei steht dem armen ARM noch nicht mal PHI2 zur Verfügung, weil das am Modulport nicht anliegt. Der Buszyklus der 6507 bzw. des 6502 sind einiges schneller, als die IEEE-Bus-Implementierung der CBM-Rechner, die ohne speziellen IEEE-Bus-Controller auskommen muss. Wenn also schon ein 6502-Busprotokoll in Software erschlagen werden kann.... seufz.

fachat: wie ist der Stand der Dinge beim XD2031?

Zitat von axorp

schade, so ist der software und timing aufwand sehr groß.
da der avr sehr viele sachen machen muss.

Finde ich nicht - am serielle Bus hat man immerhin eine Millisekunde Zeit, um auf das ATN zu antworten. Das sind immerhin 8000 Taktzyklen auf dem AVR, einer CPU die viele ihrer Befehle in einem und fast alle weiteren in zwei Taktzyklen abarbeiten kann. Da der Wechsel des Pegels auf ATN einen Interrupt auslöst muss der AVR nicht mal viel CPU-Zeit für die Bearbeitung aufwenden.

(im Gegensatz zu den ersten Platinen mit ATmega32, die für eine andere Software gebaut waren und keinen Interrupt für den ATN-Pin auslösen konnten... die Leitung alle 500 Mikrosekunden pollen geht, ist aber nicht so lustig)

Zitat von fachat

Ich habe mal versucht auszurechnen, wieviel Zeit bleibt: Wenn der PET das ATN setzt, fragt er 9 Taktzyklen später das Acknowledge ab. Mit einem 14MHz Prozessor sind das 126 Taktzyklen.

Autsch, das ist wenig. Kann man an der Stelle "blind" eine Reaktion rausgeben ähnlich wie beim seriellen Bus?

Zitat

Im AVR muss im interrupt:
1) der sende IRQ des UART behandelt werden
2) der recevive IRQ des UART behandelt werden
3) und am wichtigsten der ATN Acknowledge
behandelt werden Auf dem 6502 wäre das alles m.E. kein Problem...

Das liest sich jetzt ein wenig so als ob alles im gleichen Interruptvektor behandelt würde.

Die vergleichsweise geringe erlaubte Interruptlatenz ist natürlich trotzdem lästig, eine CPU mit mindestens zwei (einstellbaren) Interruptprioritäten wäre an der Stelle schon recht hilfreich. Bei einem eventuellen Redesign wäre evtl. ein Blick auf die Xmega-Reihe von Atmel interessant, so weit ich weiss könnte man mit deren Event-System beispielsweise ein Hardware-ATN-Acknowledge zumindest für den seriellen Bus ohne Interrupts bauen - dann reagiert wieder Hardware auf die externe Signaländerung.

Zitat von fachat

Kurzes update: Ich habe jetzt alle drei interrupt routinen zusammen auf ca 85 Zyklen - trotzdem kommt der DEVICE NOT PRESENT noch. Es gibt also noch einen anderen Fehler...

Das ist zu langsam. Der CBM setzt ATN und fragt ein paar µs später den NRFD ab.

Ich habe schon x mal erwähnt, dass es für IEEE-488 diese XOR Hardware braucht, damit das wirklich sauber funktioniert.

Ich weiss, Nils hat es mit dem PETSD auch so geschafft. Aber es ist nicht IEEE konform. Für einen PET mag es gehen, aber es gibt viel schnellere IEEE-488 Controller als den PET. Es sollte eben mit Hardware gemacht werden, damit es innerhalb einer µs reagieren kann, ohne dass ich softwaremässig irgendwie rum pfuschen muss.

Zitat von fachat

Ich habe jetzt alle drei interrupt routinen zusammen auf ca 85 Zyklen - trotzdem kommt der DEVICE NOT PRESENT noch. Es gibt also noch einen anderen Fehler...

Zitat von fachat

das reicht, wie ich oben ausgerechnet habe. Für den CBM-II mit 2MHz allerdings schon nicht mehr wenn er die gleichen Routinen nutzt.

Naja, die werden zumindest "etwas" anders sein, weil die CBM-II-Reihe ein 6525A / SN75160 / SN75161 - Gespann statt 6520 / MC3446 verwendet.

Generell besteht der Unterschied darin, dass man beim MC3446 zwei Leitungen pro Signal verwendet, wobei eine immer Eingang ist (wo man den aktuellen Zustand abfragen kann) und die andere Ausgang, womit man das Signal ggfs. auf low runter ziehen kann. Beim 75160/75161 kommt man mit der Hälfte der Leitungen aus, weil dort die Leitungen bidirektional (also wahlweise als Ein- oder Ausgang) verwendet werden. Dazu muss man natürlich zum passenden Zeitpunkt auch die Leitungen des 6525A als Ein- oder Ausgang umkonfigurieren.
Slaves, die 75160/75161 verwenden (wie z.B. das Diskettenlaufwerk 2031 oder ein petSD) haben es gleich noch einmal etwas "schwerer", weil die Datenrichtung dort auch noch automatisch durch die ATN-Leitung umgeschaltet wird. Da muss man dann darauf achten, dass keine bösen Sachen passieren, wenn der Portbaustein bzw. der Mikrocontroller die Leitung noch als Ausgang konfiguriert hat, der Bustreiber die Leitung durch ATN nun aber auch als Ausgang schaltet, denn dann würden die beiden sich darum streiten, wer denn nun die Oberhand über das Signal gewinnt.

Kann man sich ja mal zu gegebener Zeit z.B. von hier ansehen, was der CBM-II da macht.

Zitat von fachat

Ich habe jetzt alle drei interrupt routinen zusammen auf ca 85 Zyklen

Ist der Timer-Interrupt (Uhr / Tasten) dabei noch aktiv und stört ggfs.?

Die RS232 Sache ist schon mal sehr gut.

Aber richtig gut würde es mit Ethernet laufen ...

Kennst du Nils PETSD? Das wäre schon mal die Hardware dafür. Es gibt da sogar was, das RS232 über Ethernet emuliert. Da müsste man vermutlich PC seitig wenig oder gar nicht ändern.

----

Im übrigen würde es dann auch auf das Zoomfloppy passen. Der USB vom Zoomfloppy kann auch Ethernet over USB machen. Aber auch RS232 mit fast 10 MBit.

Wenn man an die Ethernet-Unterstützung rangeht, wäre es genial, die Funktionalität des Commodore Flyer zu implementieren ....