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
.
Dies sind die MAME ROMs. Laut Kommentar im Sourcecode allerdings für einen FX80+.
[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?
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]
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)?
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.
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.
ZitatPlease 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.
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)?
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.
(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.
=> 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.
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 Endlosschleifeauch 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?
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.
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.
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?
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.
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.
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.
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
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:
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.
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:
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.
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.
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.
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.
Einmal 3,3V/8MHz und einmal 5V/16MHz... Welche Version wird für so ein XUM1541 denn benötigt ?
5V / 16 MHz
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.
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.
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.
Alles anzeigenAber der einzige Filter auf das Attributbyte eines Verzeichniseintrags ist diese Zeile, die prüft, ob es sich um ein Verzeichnis handelt:
if(uii_data[0]&0x10) { presenttype=1; }
Und er prüft nur Bit 4 und ignoriert den Wert des Archivbits in Bit 5.
Ich habe also noch keine Ahnung, was schief läuft, ich werde mehr testen müssen, wenn ich wieder zu Hause bin.
If the first byte of the directory entry is the attribute byte and the filename starts at offset 1, then I reckon this should be datalength = strlen(uii_data+1) (assuming the filename is really zero-terminated, which the docs you cited don't state):
Otherwise datalength is 0 if no attribute bit is set and the file is skipped.
