Firebee - Parallele Schnittstelle

[Atari060]

Hab mal mit PAR CP USB versucht Dateien zwischen Firebee und PC zu tauschen. Wie befürchtet hat es nicht geklappt. Für eine Sekunde hat es so ausgesehen als wollte eine Kommunikation stattfinden, aber leider ging es nicht. Wo genau ist denn jetzt da das Problem? Liegt am PIC soweit ich weiß, aber was lief da schief?

VG,

Chris

[mfro]

Hab mal mit PAR CP USB versucht Dateien zwischen Firebee und PC zu tauschen. Wie befürchtet hat es nicht geklappt. Für eine Sekunde hat es so ausgesehen als wollte eine Kommunikation stattfinden, aber leider ging es nicht. Wo genau ist denn jetzt da das Problem? Liegt am PIC soweit ich weiß, aber was lief da schief?

VG,

Chris

Das hat mit dem PIC nichts zu tun, der Fehler wurde kürzlich gefunden und liegt in der FPGA-Konfiguration. Da ist er mittlerweile auch gefixt.

Auch wenn wir damit schon einen deutlichen Schritt vorwärts gemacht haben: drucken kann man im FireTOS leider trotzdem nicht (deshalb wurde diese FPGA-Config auch noch nicht released).

Beim Drucken werden im FireTOS (noch) die originalen TOS 4.04-Routinen verwendet, die leider (bedingt durch den schnellen Prozessor) die Druckersignale nicht lange genug stabil halten, als daß normale Drucker damit zurecht kämen.

In EmuTOS wurden zum Test Warteschleifen eingebaut, mit dieser (noch nicht offiziell verfügbaren Version) hat Drucken dann prinzipiell funktioniert.

Ob die Kommunikation mit/über PAR CP jemals funktioniert oder nicht, hängt davon ab, ob es die (hoffentlich auch irgendwann mal im FireTOS gepatchten) Betriebssystem-Druckerroutinen benutzt oder nicht (also die I/O-Leitungen des Soundchips selber bedient). Dann wäre das nur im Kopierprogramm selbst zu fixen.

[Börr]

Also fehlt nur exaktes Timing im Singlecore oder?

[mfro]

Also fehlt nur exaktes Timing im Singlecore oder?

Was verstehst Du unter "exaktem Timing im Singlecore"?

Es ist schlicht so, daß TOS davon ausgeht, daß das (zweistufige) Umschalten der Soundchip-Register (es muß ja jeweils erst das Register ausgewählt werden, bevor es beschrieben werden kann) in jedem Fall länger dauert als die minimale Länge des Strobe-Signals (wenn ich mich richtig erinnere war's jenes). Das ist bei der Firebee eben nicht mehr der Fall und TOS müsste hier eine Pause einlegen.

[Atari060]

Verstehe. Also wäre es "Didier's" Arbeit das Firetos dahingehend zu Patchen...

[Börr]

und TOS müsste hier eine Pause einlegen.

Dann hängt aber alles wenn es rausschreibt , aber am einfach umzusetzten.

[mfro]

wir reden hier von 750 ns, die so ein Strobe-Signal normgerecht dauern muß.

Reicht nicht wirklich, um zwischendurch eine zu rauchen oder 'nen Kaffee zu trinken

[Börr]

Aber um ein Getriebe zu fisten 

[simonsunnyboy]

Im welchem Teil vom TOS liegt das denn? Vielleicht macht es mehr Sinn, das als nachladbaren Patch einer einzigen BIOS Routine zu realisieren, als das ganze TOS umzupatchen?

Die Hardwareansteuerung muss wahrscheinlich in einem eigenen Thread/Zeitinterrupt laufen, wenn sie im bisheigen Zustand alles hinstellt.

[mfro]

... wenn sie im bisheigen Zustand alles hinstellt...

Wie kommt Ihr denn auf das schmale Brett? Laßt mal die Kirche im Dorf.

Noch mal: das Strobe-Signal der parallelen Schnittstelle muß für 750 ns (das ist der 1,3 millionste Teil einer Sekunde) aktiv bleiben.

Daß das "Alles hinstellt" kann ich nun wirklich nicht erkennen. Ein einziger 8 MHz Taktzyklus eines normalen ST's beispielsweise dauert 125 ns. Würdet Ihr 6 Taktzyklen (also weniger, als ein typischer move.w Befehl braucht) beim ST als "alles hinstellen" bezeichnen? Ich wette, das würde keiner von Euch merken, selbst wenn man die Wartezeit verdoppeln oder gar verzehnfachen würde.

Im TOS gibt's auch sonst nur sehr wenig interrupt-gesteuerte Funktionalität.
Selbst die Funktionen, die Interrupts benutzen (DMA beispielsweise), machen das mit busy-waits (schicken also die CPU in eine Schleife), und pollen ein Interrupt-Register bis die Bedingung zutrifft. Insofern ist das Drucken da in guter Gesellschaft.

Btw.: was kann man mit einem Atari ohne MiNT machen, solange er druckt? Und was nutzt's, wenn man das, was man da machen kann, schneller machen kann?

Seht's doch mal andersrum: wenn man mit der Firebee in der Lage ist, den Druckerport so anzusteuern, daß er halb so lange (oder ein Zehntel so lange) Strobe-Impulse erzeugt als ein ST, Falcon oder TT, dann bedeutet das, daß man auch Übertragungsprotokolle am Parallelport einrichten kann, die doppelt (oder zehnmal) so schnell sind als am ST.

Ich persönlich find' das gar nicht so übel.

[Atari060]

Der Vorteil erschließt sich mir aber nicht, so lange kein Drucker damit klarkommt. Die Firebee soll ja ein Falcon kompatibler Rechner sein, da hätte ich auch gerne eine kompatible Schnittstelle, sonst hätte man die gleich weglassen können, weil veraltet, etc... und da würden mir noch mehr Sachen einfallen (IKBD Port), die ja vorher gewünscht worden sind... ich hätte halt gerne, dass sie eines Tages ein vollwertiger Falcon "Ersatz" wird und dafür brauche ich eine Druckerlösung... Datenschaufeln wäre nur grad schön gewesen, weil ich es gebraucht hätte... 

[mfro]

Der Vorteil erschließt sich mir aber nicht, so lange kein Drucker damit klarkommt.

Du hast ja oben schon geschrieben, was dazu passsieren muß ...

[Mathias]

Ich wundere mich gerade ein bissl warum wir das in der Art nicht im Entwicklerforum besprechen? Find´ ich jetzt nicht besonders schlimm, aber ein bissl schräg, weil bis auf Simonsunnyboy sind wir ja alle dort, …

Und wenn wir momentan schon auf "Total Offen" machen; Roger Burrows hat eigentlich darum gebeten die Neuigkeiten bzgl. der Paralellen Schnittstelle erst zu veröffentlichen, sobald ein offizielles TOS fertig ist und damit umgehen kann. Das hätte auch den Vorteil gehabt, daß wir nicht vermittelt hätten "es ist zwar gefixt, aber drucken geht noch immer nicht" sondern daß wir dann halt sagen hätten können "Drucken geht jetzt auch, und den FPGA haben wir dafür auch gefixt". ;)

Die Diskussion um die 750 ns finde ich auch super :-) Ich denke mfro hat das optimal zusammengefasst. ;)

[1ST1]

TOS anpassen ist das eine, was ist mit Programmen oder Alternativbetriebssystemen, die möglicherweise eigene Druckroutinen mitbringen? MiNT?

[mfro]

Und wenn wir momentan schon auf "Total Offen" machen; Roger Burrows hat eigentlich darum gebeten die Neuigkeiten bzgl. der Paralellen Schnittstelle erst zu veröffentlichen, sobald ein offizielles TOS fertig ist und damit umgehen kann. Das hätte auch den Vorteil gehabt, daß wir nicht vermittelt hätten "es ist zwar gefixt, aber drucken geht noch immer nicht" sondern daß wir dann halt sagen hätten können "Drucken geht jetzt auch, und den FPGA haben wir dafür auch gefixt".

Die Diskussion um die 750 ns finde ich auch super :-) Ich denke mfro hat das optimal zusammengefasst.

Hallo Mathias,

was an "total offen" "schräg" sein soll, erschließt sich mir nicht. Wir beide wissen, daß wir - was "Offenheit" (bei einem "freie Hardware"-Projekt) angeht, etwas unterschiedlicher Meinung sind. Das respektiere ich, aber einen Maulkorb laß' ich mir - mit Verlaub - auch nicht aufsetzen . Hier wurde anständig gefragt und ich habe anständig Antwort gegeben, soweit mir das vernünftig möglich ist.

Bevor der Eindruck entsteht, ich würde gegen den Willen Anderer "interne Geheimnisse" ausplaudern: Roger hat nicht darum gebeten, die Information zurückzuhalten, sondern das offizielle Release der gefixten FPGA-Config. Und zwar deswegen, um nicht außer dem - sowieso geplanten - EmuTOS 0.9.5-Release (das bereits aufwendig genug ist) noch ein Zwischenrelease für die Firebee rausbringen zu müssen. Was hoffentlich jeder nachvollziehen kann. Wer will und es besonders eilig hat, kann sich EmuTOS ja jederzeit selbst compilieren.

Gruß,
Markus

[Mathias]

Hallo Markus!

Hallo Mathias,

was an "total offen" "schräg" sein soll, erschließt sich mir nicht.

Nein, schräg war nicht auf "total offen" bezogen, sondern darauf, daß sich hier eigentlich nur Mitwirkende unterhalten wie wenn manche nichts mit dem Projekt zu tun hätten.

Wir beide wissen, daß wir - was "Offenheit" (bei einem "freie Hardware"-Projekt) angeht, etwas unterschiedlicher Meinung sind. Das respektiere ich, aber einen Maulkorb laß' ich mir - mit Verlaub - auch nicht aufsetzen . Hier wurde anständig gefragt und ich habe anständig Antwort gegeben, soweit mir das vernünftig möglich ist.

Ich schreib´ ja daß ich es nicht schlimm finde, und nein, Maulkörbe verteilen liegt mir fern. Mir gehts darum daß wir als Team Freie Vereinbahrungen treffen die dann auch gemeinsam umgesetzt werden.
Du weißt ja, ich wollte die gefixte FPGA Konfig sehr gerne veröffentlichen und hätte gerne eine Newsmeldung dazu rausgebracht. Ich war aber unsicher und hab euch daher um Rat gefragt, und Roger und Du waren momentan noch gegen eine Veröffentlichung (Du weil Du noch ausführliche Tests angeregt hast, was ja sehr sinnvoll ist). Das habe ich wiederum respektiert und den Plan daher verschoben.

Bevor der Eindruck entsteht, ich würde gegen den Willen Anderer "interne Geheimnisse" ausplaudern: Roger hat nicht darum gebeten, die Information zurückzuhalten, sondern das offizielle Release der gefixten FPGA-Config. Und zwar deswegen, um nicht außer dem - sowieso geplanten - EmuTOS 0.9.5-Release (das bereits aufwendig genug ist) noch ein Zwischenrelease für die Firebee rausbringen zu müssen. Was hoffentlich jeder nachvollziehen kann. Wer will und es besonders eilig hat, kann sich EmuTOS ja jederzeit selbst compilieren.

OK, wenn du das so verstanden hast, dann ist das natürlich auch für mich jetzt klarer. Ich habe es so wahrgenommen, daß Roger sich auch gegen eine Newsmeldung ausgesprochen hat. Ich habe ja im internen Posting explizit erwähnt daß es coole news wären. Ich kann mich aber auch irren, …
Naja ist alles halb so wild. Ich finde es nur ein bissl schade daß es jetzt so "zwischendurch" dasteht. Und bei manchen p.T. Atari-Usern kann ich mir in ein paar Wochen dann sicher anhören daß wir total veraltete News bringen wenn dann auf firebee.org eiin Artikel zum Druckerport kommt, oder daß wir geheimniskrämerisch wären, weil wir keinen täglichen Bericht über unsere Tätigkeiten abliefern. ;-)

[mfro]

TOS anpassen ist das eine, was ist mit Programmen oder Alternativbetriebssystemen, die möglicherweise eigene Druckroutinen mitbringen? MiNT?

MiNT bringt seine eigenen Treiberroutinen für den Parallelport mit.

Wenn ich das auf die Schnelle richtig sehe, wird dort zwischen dem Umschalten der PSG-Register zwei NOP's lang gewartet. Lustigerweise ist NOP beim Coldfire einer der langsamsten "normalen" Befehle im Befehlssatz (lustig, weil "nix machen" besonders lange dauert, was daran liegt, daß beim Coldfire NOP eben nicht nix, sondern gleich die Prozessor-Pipeline mit leer macht) und braucht 6 Taktzyklen.

Die zwei NOP's sind also nach etwa 50 ns rum, was für den Strobe nicht reichen wird, da werden noch ein paar dazukommen müssen. Das ist insofern kein Problem, als daß die Routine sowieso bereits einen eigenen Coldfire-Zweig hat, kann ich also leicht machen.
Bloß komm' ich in den nächsten drei Wochen leider nicht dazu, weil ich außer Landes bin.

[Mathias]

MiNT bringt seine eigenen Treiberroutinen für den Parallelport mit.
(…) Das ist insofern kein Problem, als daß die Routine sowieso bereits einen eigenen Coldfire-Zweig hat, kann ich also leicht machen.

Wie, was, ….? Wir brauchen das FireTOS gar nicht zum Drucken aus MiNT heraus?

[mfro]

MiNT bringt seine eigenen Treiberroutinen für den Parallelport mit.
(…) Das ist insofern kein Problem, als daß die Routine sowieso bereits einen eigenen Coldfire-Zweig hat, kann ich also leicht machen.

Wie, was, ….? Wir brauchen das FireTOS gar nicht zum Drucken aus MiNT heraus?

Jupp.

[Mathias]

Sorry fürs nochmal blöd nachfragen, aber auch wenn FreeMiNT überm FireTOS läuft, und auch fürr die NVDI oder Papyrus Druckertreiber? Das wäre ja eine echte kurzfristige Perspektive!