Beiträge von thierer

Zitat von r.cade

I would have loved to have built or bought one of these just for the little speed boost using DD, but this project never progressed?

If dolphin support is all you're after, that isn't a feature which is specific to the lpc version of the firmware. It also works with a avr m1284p, you just need a board where the parallel port pins are broken out. (You'd also have to adapt the firmware configuration and build the firmware yourself, as from what I understand none of the binaries from sd2iec.de have support built in).

Zitat von Markus64

Zitat von Asklia

Aus 2 x 8k kann in einem Emulator aber auch ein 16k ROM werden. In einem EPROM sind FF für ungenutzte Speicherstellen übrigens der normale Zustand.

ich hab das verwendete ROM File auch nicht gefunden, nur im MAME Quellcode auf GitHub den Hinweis darauf und auf ROM Seiten die Prüfsumme .

https://github.com/mamedev/mam…centronics/epson_fx80.cpp

Dies sind die MAME ROMs. Laut Kommentar im Sourcecode allerdings für einen FX80+.

Zitat von GoDot

Zitat von thierer

[Edit]$f53d ist die Suche nach dem Blockheader. Wenn es da wirklich beim Warten auf das nächste Byte hängt, dann hat das wohl kaum etwas mit der Übertragung zu tun, sondern etwas anderes ist faul.[/Edit]

Der Hänger erfolgt immer unmittelbar, bevor ein Zugriff auf die Disk stattfindet (Puffer füllen). Es geht offenbar nicht um einzelne Bytes.

Was ich meinte ist, dass das BVC an $f53d auf das nächste Byte vom Lesekopf wartet (das wird in der Floppy dadurch signalisiert, dass die Hardware das V-Flag setzt). Da kann es eigentlich nicht hängen, weil ständig neue Bytes kommen.

Hast du mal überprüft, dass das Problem auch auf Original-Hardware auftritt?

Zitat von GoDot

Edit: in der Floppy steht das System auf $F53D (BVC).

Bei mir ist es jetzt sowohl mit als auch ohne JD jeweils zweimal ohne Hänger durchgelaufen. Bisher noch nicht auf echter Hardware getestet (nur VICE 3.9 und MiSTer C64 core), aber bei dir hängt es ja offenbar auch in VICE? Ändert sich etwas, wenn du vorher mal "restore default settings" machst?

[Edit]$f53d ist die Suche nach dem Blockheader. Wenn es da wirklich beim Warten auf das nächste Byte hängt, dann hat das wohl kaum etwas mit der Übertragung zu tun, sondern etwas anderes ist faul.[/Edit]

Zitat von GoDot

Ich hab jetzt v3.9 am Start, aber in die Floppys kann ich nicht reingucken. Was muss ich dafür tun?

Im Monitorfenster dev 8: (oder eben die entsprechende Geräteadresse), zurück mit `dev c:.

Gibt es das Programm zum Reproduzieren (es wird ja nicht die Releaseversion sein)?

Zitat von WebFritzi

Zitat von thierer

dir kommt es aber vermutlich nur auf via Kernal gesendete Kommandos an und die sollten funktionieren.

Genau. Interessante Info. Ich schau's mir mal an - scheint mir aber ein bisschen zu viel Aufwand zu sein nur um ein paar Videos von GUI64 zu machen.

Noch als Nachtrag: Falls du mit "zu viel Aufwand" meinst, dass du erst ein xum1541 kaufen müsstest: 1. Solltest du dann darauf achten, dass entweder dein sd2iec oder das xum1541 Pullup Widerstände an den IEC-Leitungen hat, weil sonst funktioniert es nicht. Meiner Erfahrung nach gehen in beiden Fällen die meisten Designs inkl. der original Zoomfloppy davon aus, dass sie an Commodore Hardware angeschlossen werden und deshalb mutmaßlich keine brauchen. 2. Alternativ kannst du mir eine PN mit deiner Adresse schicken, dann schenke ich dir eines.

Zitat von WebFritzi

Zitat von thierer

dir kommt es aber vermutlich nur auf via Kernal gesendete Kommandos an und die sollten funktionieren.

Genau. Interessante Info. Ich schau's mir mal an - scheint mir aber ein bisschen zu viel Aufwand zu sein nur um ein paar Videos von GUI64 zu machen.

Den eigentlichen Nutzen würde ich auch eher darin sehen, dass du damit in VICE debuggen kannst.

Zitat von WebFritzi

Zitat

Please excuse the bad video quality. Vice can unfortunately not emulate SD2IEC devices.

Falls du ein xum1541 Gerät besitzt (Zoomfloppy oder ähnlich), dann kannst du mit dessen Hilfe evtl. in VICE das sd2iec als "Real Device (OpenCBM)" ansprechen. Dazu in den Einstellungen unter Peripheral devices -> Drive auf der gewünschten Laufwerksseite "IEC device" aktivieren und unter "IEC device type" entsprechend auswählen. OpenCBM muss natürlich installiert sein.

Das unterstützt grundsätzlich nur das original CBM DOS Protokoll (also keine Schnelllader oder ähnliches), dir kommt es aber vermutlich nur auf via Kernal gesendete Kommandos an und die sollten funktionieren.

Zitat von Smasher777

Diese Probleme treten nur mit diesem Laufwerk auf, ein anderes funktioniert völlig problemlos am gleichen C64, mit dem gleichen Netzteil und den gleichen Kabeln. Auch funktioniert das andere Laufwerk problemlos in OpenCBM.

Ich kann den Fehler also auf dieses Laufwerk eingrenzen.

Hast du denn auch noch ein zweites serielles Kabel im Zugriff? Falls ja: Wie verhält sich das Problemlaufwerk, wenn du das funktionierende Laufwerk in Reihe dahinter anschließt (eingeschaltet und natürlich auf eine andere Geräteadresse konfiguriert)?

Zitat von TurboMicha

du schreibst aber gerade, "ich hatte bisher auch "8 an 1"-> ist doch auch o.k! (das ist ja das, wo mich Perser "ausgelacht" hat

-> da habe ich auch Pin8-C64 an Pin1-Centronic... Ich habe auch NICHT gesagt, dass du M (C64) an 1 (Centronics) machen sollst...!

Habe ich auch nicht so verstanden. Ich habe das deshalb gemacht, weil ich überzeugt war, dass mein Testprogramm mit beiden Varianten ("8 an 1" und "M an 1") funktioniert, ich das aber nicht einfach behaupten wollte, ohne es auch konkret getestet zu haben.

Zitat von TurboMicha

(aber beim "normalen C64-Centronic Kabel ist das wohl "Normal" so M=1, B=10 (8 garnicht angeschlossen!),

dass ist ja gerade das "besondere" bei der Verschaltung am TESA.

Die Variante "M an 1" mag verbreiteter sein, so exotisch ist "8 an 1" aber auch nicht, die Variante ist naheliegend. Mein Kabel war ja auch so und das hatte ich auch bewusst so gemacht. Beide Varianten haben Vor- und Nachteile, der Vorteil von "8 an 1" ist eben, dass es unabhängiger von der Ansteuerung durch die Software ist, wie man im vorliegenden Fall ja sieht.

Zitat von TurboMicha

=> Die Frage bleibt mir bei deinem Kabel...-> wohin geht B-C64 ?? an 10 oder 11 von Centronics ?

Ich habe B an 10 (ACK). Ob ACK oder BUSY (11) ist in der Praxis aber egal, funktioniert beides.

Zitat von TurboMicha

Dann habe ich das gleiche noch mit dem "Standard-Kabel" ( M=1 , B=10) gemacht...

UND siehe da... nun funktionieren BEIDE Kabel Varianten,.. es bleibt auch nichts hängen.. und Drucker bringt KEINE Endlosschleife

auch mit dem zweiten Kabel, drei gleiche Ausdrucke:

Verstehe ich das richtig, dass "nun" bedeutet "mit dem umgebauten C64" (im Unterschied zum Ultimate64)? Dh während mit dem Ultimate nur das "Tesa-Kabel" funktioniert, funktionieren mit umgebauten C64 beide Kabel-Varianten? Gehe ich dann auch recht in der Annahme, das der "C64" in dem Test mit meinem Programm, bei dem auch nur das "Tesa-Kabel" funktioniert hat, auch das Ultimate war?

Zitat von ClausS

Da wird soweit ich sehe auch das Bit 2 gesetzt. Und ich habe im Quellcode keine Stelle gefunden, in der es wieder geloescht wird.

Ja, ok, dann ist das unnötig. Und das DDR wird auch richtig gesetzt, dann ist das auch redundant es bei der Initialisierung nochmal zu setzen.

Zitat von TurboMicha

ich habe dich so Verstandem, dass es zum Test vom Drucker geht und habe daher einen "normalen" echten C64

extra mit original Kernel .. kein JIFFY den Drucker anschlossen:

Genau! Braucht aber keinen Hexmodus, das druckt nur eine Zeile Text, das sollte jeder Drucker können.

Zitat von TurboMicha

JA. der Drucker druckt.. aber NUR mit dem Kabel, wo B=11 und , 8=1 ist..

(also nicht das "normale" Kabel.. sondern die "Parser"-Variante )

Und mit "normal" meinst du die Variante, bei der STROBE an PA2 angeschlossen ist (also M an 1)?

Das kann ich weder nachvollziehen noch reproduzieren. Ich hatte bisher auch "8 an 1", und habe das jetzt zum Test auf "M an 1" umgebaut und es funktioniert wie (von mir ) erwartet ebenfalls. Bist du sicher, dass diese exakte Kombination aus "normalem" Kabel, C64 und Drucker mit anderer Software funktioniert?

Zitat von TurboMicha

wenn der Drucker ausgeschaltet ist,. oder offline.. dann bleibt dein Programm auch nach RUN "stehen",

Das ist zu erwarten. Es wird nach jedem Byte auf die Rückmeldung des Druckers gewartet, dass er es verarbeitet hat. Und die kommt eben nicht, wenn er ausgeschaltet oder offline ist.

Zitat von TurboMicha

wenn ich dann den Drucker einschalte und drucke, oder wenn er "An" war und ich ihn von "Offline" nach "Online" schalte,

kommt das Programm zurück zum Basic-Cursor..

Aber ohne dass etwas gedruckt wird? Das Programm kehrt erst zurück, nachdem es jedes Byte gesendet und zu jedem Byte die Empfangsbestätigung vom Drucker erhalten hat. Das würde bedeuten, der Drucker hat den Empfang bestätigt, dann aber nicht gedruckt.

Zitat von TurboMicha

du den letzten 3 Treibern von ClausS komme ich leider erst später..

Das ist der eigentlich interessante Test. Mein Programm war nur ein Versuch, das Problem einzugrenzen. Wenn es mit mindestens einer der Versionen von ClausS funktioniert, dann ist der Rest hinfällig.

Zitat von ClausS

Zitat von TurboMicha

wenn ich dann aber den Druck starte, bleibt der komplette Rechner mit folgendem Menü hängen: (kann nur noch Resetet werden),

UND der Drucker macht keinen Mucks,.. ich habe beide Kabel probiert: (natürlich bringt RETURN auch KEINE Abbruch )

Zitat von ronduc

ist bei mir genauso, Druck starten geht nicht, Programm hängt sich auf.

Ich habe die von mir hochgeladene Version nochmals getestet, unter VICE funktioniert der Hexdump.

thierer , hat das eventeull was mit dem FLAG2 zu tun?

Wäre naheliegend, der Grund ist mir aber zumindest nicht offensichtlich.

Aufgefallen ist mir:

1. Dass du bei der Initialisierung kein LDA $DD00 / ORA #$04 / STA $DD00 machst. Das scheinen aber die TESA-ROMs selber zu machen, also sollte es kein Problem sein. Falls aber doch, dann würde es das Verhalten zumindest mit einem PA2-Kabel erklären: Ich hatte gestern geschrieben, dass dann ggfs. das erste Byte "verschluckt" würde, das war aber zu kurz gedacht: Da der Drucker das Byte nie erkennen würde, würde er es auch nicht bestätigen und die Schleife damit hängen.
2. Vielleicht ziehst du das LDA $DD0D in der eigentlichen Byte-Ausgaberoutine doch besser ganz an den Anfang, vor das PLA. Sonst könnte es zum gleichen Problem kommen, wenn ein PC2-Kabel verwendet wird und der Drucker sehr schnell ist (wie das der Fall sein könnte, wenn es gar kein echter Drucker, sondern eine Emulation ist).

TurboMicha  ronduc Kommt denn gar nichts beim Drucker an? Also offline/online erzeugt auch gar keine Ausgabe? TurboMicha du hast ja wohl auch beide Typen von Kabeln, hat es mit beiden nicht funktioniert?

Das angehängte Programm läuft auf einem C64 und verwendet (wenn ich keinen Fehler gemacht habe ) praktisch identischen Code wie das Sonderprogramm. Einfach mit RUN starten, es sollte dann "DIES IST EIN DRUCKER-TEST" auf einem über Userport angeschlossenen Drucker ausgeben. Das funktioniert bei mir auf dem C64 mit EPSON LQ-850, bei euch auch? Es sollte auch mit allen Kabeltypen funktionieren, getestet habe ich es aber bisher nur mit einem PC2-Kabel.

Zitat von ClausS

Bitte probiert mit dem Treiber den Hexdump an einem Drucker, mit einem 'normalem' Kabel, und gebt mir Rueckmeldung, ob es bei euch klappt.

Ich habe es mangels geeigneter Hardware nicht auf solcher getestet, aber es kann m.E. nicht funktionieren (und deaktiviert nebenbei auch noch den IEC-Bus). Ich habe meine Kommentare direkt in den Code geschrieben:

Zitat von Bobbel

Also, so baue ich mir ein TESA-Kabel:

Genau!

Wobei die Bezeichnung "TESA-Kabel" nahelegt, dass es nur mit der TESA-Software funktioniert; dem ist nicht so, es funktioniert (mit den oben genannten Einschränkungen) generell, aber eben auch mit der TESA-Software.

Allerdings: Die Frage ist, wie relevant es für dich überhaupt ist, dass es mit der (unmodifizierten) TESA-Software funktioniert? Die scheint ja nur diesen Facit-Drucker ansteuern zu können, und zwar in einem Modus, der zu nichts gängigem (z.B. Epson) kompatibel ist. Dh um wirklich direkt aus der TESA-Software drucken zu können, bräuchtest du nicht nur das Kabel, sondern auch den passenden Drucker, den du vermutlich nicht hast?

Und falls ClausS die Software so modifizieren würde, dass sie ein anderes, gängigeres Druckerprotokoll spricht, dann könnte er vermutlich auch den PA2-STROBE einbauen, so dass es dann wieder egal wäre, wie das Kabel aufgebaut ist.

Aber ändert nichts an der grundsätzlichen Aussage, dass ein Kabel wie oben skizziert für beide Szenarien funktioniert.

Zitat von Bobbel

Ich hatte so eine einfache Frage, jetzt sind wir schon auf Seite 4 und ich bin mir immer noch unschlüssig wie ich das Kabel löten soll

Falls es bei der Entscheidung hilft: Ich habe bei meinem eigenen Kabel Userport FLAG2 mit Drucker ACK und Drucker STROBE mit Userport PC2 verbunden.

1. Ob FLAG2 mit BUSY oder ACK verbunden ist, ist in der Praxis irrelevant. Es macht auch keinen Unterschied bei der Ansteuerung, die Aussage in dem von dir zitierten Text ist falsch.
2. Die Frage hast du zwar eigentlich nicht gestellt, aber: STROBE an PC2 oder PA2 ist nicht ganz so irrelevant, da du aber den Tesa SX64 erwähnst und wir ja gelernt haben, dass der PA2 gar nicht bedient, beantwortet sich diese Frage m.E. auch von selbst. Der Vorteil von PC2 ist, dass es grundsätzlich funktioniert, egal ob die Software ein separates STROBE über PA2 erzeugt oder nicht, der Nachteil, dass damit theoretisch auch Zeichen beim Drucker landen können, die gar nicht für ihn gedacht sind, weil jeder Schreib- oder Lesezugriff auf das Portregister dazu führt, dass der Drucker ein Zeichen liest.

Hier jetzt ein python Skript, das einen Mitschnitt auswertet, dabei anhand der hoffentlich konstanten Initialisierungs-Präambel auch mehrere Drucke in der gleichen Datei erkennen kann und diese dann in aufsteigend numerierte PNG-Dateien schreibt (bestehende Dateien gleichen Namens werden ohne Nachfrage überschrieben).

Zum Testen außerdem noch eine Logdatei mit dem Etikett von gestern und noch zwei weiteren von der gleichen Diskette.

Zitat von ClausS

Ich habe dabei den 'Drucker" mit folgenden Einstellungen verwendet:

Unter "Driver" muss "RAW" ausgewählt sein, sonst kann es nicht funktionieren. Außerdem ist wichtig, nach dem letzten Druck im Menü noch "File -> Printer/plotter -> Send formfeed to userport printer" auszuwählen (oder VICE zu beenden), sonst ist die Datei höchstwahrscheinlich nicht vollständig.

Als Basis habe ich den aktuell neuesten SVN-Stand r45384 genommen, das mag auch noch relevant sein.

Ich habe mal VICE krude gepatcht um die Druckdaten anzugreifen, anhand des Manuals einen simplen Interpreter geschrieben und ihn auf das Etikett BFTESA LUX MITTE von der Diskette tesa lux tesa cal.d64 losgelassen:

Die mitgeschnittenen Druckdaten und das Ergebnis hänge ich an, der Code ist mir noch zu peinlich, den muss ich erst aufräumen . Das ist mit "Normaldruck"; "Kontrastdruck" liefert das visuell exakt identische Ergebnis. Ich hab's mir noch nicht genauer angeschaut, aber vermutlich wird wirklich einfach die gleiche Zeile mehrfach gedruckt.

Den Patch für VICE hänge ich auch an, das ist aber wirklich nur für diesen Zweck; ich habe vom VICE-Code keine Ahnung, wer weiß, was ich alles kaputt gemacht habe. In der Dump-Datei hängt am Anfang auch immer noch Müll (bei mir 2 Bytes, kA, ob das auch mehr werden kann), den man abschneiden oder beim Auswerten ignorieren muss.

Zitat von Snocksman

Einmal 3,3V/8MHz und einmal 5V/16MHz... Welche Version wird für so ein XUM1541 denn benötigt ?

5V / 16 MHz

Zitat von mist64

66 "s-grafik demo": S-Grafik Demo

66 "s-grafik": S-Grafik (Basic Lader)

81 "master mind": Master Mind

84 "datasette musik": Musik aus der Datasette

136 Aufruf Summe arithmetische Reihe

Diese sind in meinem PR von vorgestern (?) enthalten.

Zitat von Asklia

Wenn der 367 als U3 bereits den C64 blockiert, wie du sagst: Gemäss Schaltplan gehen etliche C64 Signale lediglich IN den Buffer 367.

Aber Ausgang 1Y4 geht auf das OE des DB Latches und Ausgang 2Y2 direkt auf R/W des C64.

Zitat von Asklia

Was bedeuten denn die beiden 367 Fixes auf der Github Seite? Dort ist für mich unverständlicher Code und leider keine Beschreibung.

Der "Fix" scheint darin zu bestehen, dass die Bedeutung von a/b falsch als 3a/3b abgebildet wurde (gemäß Datenblatt ist die Aufteilung tatsächlich 4a/2b):

Auf die Schnelle erkenne ich nicht, dass das ein Problem für die Schaltung wäre, weil die Belegung scheint unverändert. Weckt aber mein Misstrauen gegenüber der ganzen Umsetzung (die abgesehen davon im README auch als "untested" bezeichnet wird) und ein Kommentar wie "Fixed errors (by ignoring them)" tut sein übriges.