Mittlerweile ist mir noch eingefallen, dass 133 -> 137 auch ein gekipptes Bit sein könnte.
Wären zwei Bits: $89 = %1000'1001 auf $85 = %1000'0101.
Ups 
Hätte ich besser mal nachgerechnet...
Posts by thierer
-
-
Also ich hab das immer als Keinen Fehler gefunden interpretiert…
Heißt es auch. pgeorgi hat ja geschrieben, dass der Wert richtig abgetippt und auch so in der Prüfsumme berücksichtigt ist, nur war er halt schon bei Erstellung des Listings falsch.
Ich kann mir nur vorstellen, dass da durch irgendein POKE versehentlich eine Speicherstelle geändert wurde
Mittlerweile ist mir noch eingefallen, dass 133 -> 137 auch ein gekipptes Bit sein könnte.
-
Das ist ja ein Ding, vielen Dank fürs Nachforschen! Ich frage mich schon, wie das passieren konnte. Das Listing wird ja automatisch aus dem Originalprogramm erzeugt worden sein und das wiederum aus dem Quelltext. Ich kann mir nur vorstellen, dass da durch irgendein POKE versehentlich eine Speicherstelle geändert wurde und das dann keiner gemerkt hat. Wirft aber schon kein gutes Licht auf die Qualitätssicherung bei HC
Ist der "Peter Menke" aus Brunsbüttel vielleicht hier auch unterwegs, so dass wir ihn fragen können?
-
Langsam wird leider eine defekte PI1541 HAT-Platine wahrscheinlich, oder?
Was passiert, wenn du ohne Hat startest? Bei mir erscheint die Pi1541 Anzeige dann trotzdem.
-
The Arduino Mega has interrupts only on port D and port E. Port E is already allocated by the serial transmission via USB. So you're stuck on Port D and block the I2C port.
I don't know about the specifics of the shield used, but PCINT lines are plenty. I can't see why you shouldn't be able to use Port B.
This isnt an i2c application, so Im not sure why it needs to be on the i2c pins.
If you don't need it just don't use any of the CONFIG_REMOTE_DISPLAY, CONFIG_RTC_DSRTC or CONFIG_RTC_PCF8583 flags.
Also, sd2iec doesn't seem to use the AVR's hardware i2c anyway, so you should be free to use other pins for i2c, if you did.
That all said, I doubt a missing ATN interrupt is the reason for the "LOAD ERROR", anyway. I would expect (haven't checked, though) that 1. this would result in a "DEVICE NOT PRESENT" or "FILE NOT FOUND" error and 2. Jiffy-DOS wouldn't have stricter timing requirements in this regard, so it would already fail with standard serial.
-
Das "Master-Tool" aus Ausgabe 01 und 02/88 hat einen Leveleditor.
Außerdem gab es zum LdM "Suburbia" aus Ausgabe 02 in Ausgabe 03 einen Leveleditor mit Beispiellevel (erfüllt nicht das Kriterium "nicht für ein bestimmtes Spiel", aber dafür "Höhlen").
-
Kommt man damit jetzt auch ungefähr auf die Geschwindigkeit von Nibtools? Das oben liest sich eher so wie "nein".
Ist auch "nein". nibread liest ja nur parallel oder SRQ, das ist nicht vergleichbar. Die Jiffy-DOS Unterstützung leistet auch keinen nennenswerten Beitrag zur Beschleunigung von d64copy. (Der Code-Upload zur Floppy wird beschleunigt, das war's dann im Wesentlichen aber auch).
Wenn doch, müsste die ZoomFloppy das ja am besten auch bekommen.
In dem von mir verlinkten Verzeichnis ist auch eine Firmware-Datei für die Zoomfloppy. Grundsätzlich sind die Boards ähnlich genug, dass es funktionieren sollte, aber ohne Testmöglichkeit kann ich eben nicht 100%ig ausschließen, dass ich einen Fehler gemacht habe.
-
Es ist großartig!
Der Upload des Drive Code geht jetzt blitzartig!Früher war da diese typische Wartezeit bevor das Laufwerk losgelegt hat.
Danke, das freut mich, wenn es dir hilft
! Allerdings braucht nach meiner Erfahrung der Drivecode auch ohne JD Unterstützung nur unter 1 Sekunde, da merke *ich* nicht, wenn das schneller geht... Von welchem Programm & Laufwerk redest du da?Bei größeren Up- und Downloads ist der Unterschied tatsächlich deutlich, aber auch der Einsatz mit MeGALoDOS widerspricht glaube ich meinem "... für die meisten Anwender ..." nicht
. -
Der praktische Nutzen dürfte sich für die meisten Anwender tatsächlich in Grenzen halten. Beschleunigt werden nur Übertragungen, die das originale, serielle IEC-Protokoll verwenden. Und das sind mit opencbm nicht so viele, weil die Tools normalerweise (dh in Kombination mit einer 1541 oder 1571) automatisch auf die "serial" oder "parallel" Transferprotokolle wechseln. Mit "parallel" kann Jiffy-DOS sowieso nicht mithalten (weil *nicht* parallel) und die Seriell-Varianten sind ungefähr auf dem Niveau von Jiffy-DOS.
Es gibt 3 Anwendungsfälle, die profitieren (sollten):
1. Nicht-1541/1571 Laufwerke mit Jiffy-DOS Unterstützung. Da scheint es wohl einige Laufwerke von Drittherstellern zu geben (zB CMD). Die alternativen Transferprotokolle von opencbm funktionieren da evtl. wegen Inkompatibilitäten nicht, dann kann JD nützlich sein. Ich habe aber kein einziges solches Laufwerk, deshalb kann ich es nicht testen. Mit der sd2iec Firmware messe ich für cbmcopy eine 10x Beschleunigung, das ist aber ein rein akademischer Anwendungsfall.
2. Da die Aushandlung und Anwendung des Protokolls für den Host-Computer transparent zwischen xum1541 Adapter und Laufwerk erfolgt, werden auch Übertragungen zwischen einem VICE und einem per opencbm "real device" angeschlossenen Laufwerk beschleunigt. (Braucht aber natürlich trotzdem ein JD ROM im Laufwerk und die Beschleunigung ist mit nur 2x auch nicht gewaltig).
3. Up- und Downloads in/aus dem Floppyspeicher sind auch beschleunigt, aber bei den paar kB RAM fällt es nicht weiter ins Gewicht und das ROM liest man ja nicht so häufig aus...
Wer einen Anwendungsfall (-laufwerk) und/oder Interesse hat, kann sich die für sein Board benötigte, modifizierte Firmware hier herunterladen. Ich rate aber dazu, vorher ein Backup der aktuell geflashten Firmware zu machen. Da ich nur Pro Micro-basierte Boards habe, sind auch nur die getestet.
Speziell an Rückmeldungen (positiv & negativ) zu anderen Laufwerken als 1541 und 1571 wäre ich interessiert. (Wenn mit einem exotischen Laufwerk ohne JD Unterstützung *keine* Probleme auftreten, dann wäre das auch eine hilfreiche Nachricht).
Um mit einer 1541 oder einer 1571 zu testen, muss als Übertragungsprotokoll mit --transfer=original explizit das serielle Originalprotokoll ausgewählt werden! Sonst wird wie oben beschrieben automatisch auf ein anderes Protokoll umgeschaltet und das JD-Protokoll nur für den Upload des Drive-Codes verwendet. Sinnvoll sind Tests auch im Wesentlichen nur mit cbmctrl und cbmcopy. d64copy schaltet mit --transfer=original auch automatisch den "Warp" Modus ab, dadurch ist es dann sowieso langsam.
-
Es müsste Einstellungen serial1 und serial2 geben, und zwar ohne den Zusatz "original". Bitte diese benutzen.
Ja, diese Optionen müsste es theoretisch geben: "Auto (Recommended)", "Original (Very Slow!)", "Serial 1 (Slow!)", "Serial 2" und "Parallel".
[edit]
Falls nicht, dann müssen wir uns nochmal abstimmen (Den Text "seriell (Original)" finde ich im Programmcode von CBM-Transfer nicht. Wir reden schon über dieses Programm?).[/edit]"original" hatte ich nicht gemeint; wenn es damit funktioniert, dann ist das aber auch eine Erkenntnis.
[edit]Sorry, deine Antwort hatte ich noch nicht gesehen.[/edit]
-
Du schreibst, dass du in CBM-Transfer zwischen "auto" und "parallel" umschaltest. Könnte ja sein, dass CBM-Transfer bei "auto" einen eigenen Test durchführt und der für den Hänger sorgt.
Diese Frage hat sich erledigt, ich habe mir den Sourcecode von CBM-Transfer angesehen. Damit wird nur die Option ausgewählt, die dann 1:1 an die --transfer Option von cbmcopy bzw. d64copy durchgereicht wird.
Du könntest aber tatsächlich mal "serial2" auswählen und schauen, ob es dann besser funktioniert.
-
In den CBM-Transfer Einstellungen hab ich nichts verändert, ich probiere bzw. stelle immer von Auto auf Parallelübertragung um. Im August ist ja eine neue Version rausgekommen , aber das behebt das Problem nicht
Hast du denn mal in den Einstellungen nach der "nibtools für D64-Images verwenden" Einstellung gesucht? Das wäre schon interessant. Wenn es mit CBM-Transfer hängt und mit d64copy auf der Kommandozeile nicht, dann ist der naheliegende Schluss, dass entweder CBM-Transfer noch irgendwas anderes macht, das hängt, oder dass es ein anderes Programm verwendet, also zB nibread.
Das mit den Lesefehlern mit d64copy erklärt das zwar nicht, ich vermute aber, dass beides zusammenhängt, sich die Ursache für den Hänger aber einfach identifizieren lässt.
Reine Spekulation, aber wenn das Kopieren mit dem C64 funktioniert, dann könnte ich mir vorstellen dass evtl. die USB-Hardware des neuen Rechners schuld ist? Das ist ja immerhin etwas, das sich geändert hat. Du kannst ja mal einen anderen USB-Port probieren, ob das was hilft.
Und bei JiffyDOS war das Parallelkabel eingesteckt.
Dann weiß ich nicht, was den Unterschied machen soll. Außer, fällt mir gerade ein: Du schreibst, dass du in CBM-Transfer zwischen "auto" und "parallel" umschaltest. Könnte ja sein, dass CBM-Transfer bei "auto" einen eigenen Test durchführt und der für den Hänger sorgt. Gibt es auch eine Option "seriell", mit der du Speeddos und Jiffy-DOS mal probieren könntest?
Tommi_nrw , da du dich ja offenbar mit dem Thema befasst hast: Weißt du zufällig ob Speeddos für den "seriell"-Fall (also kein Parallelkabel angeschlossen) auch modifizierte (dh beschleunigte) Routinen verwendet, oder normal Kernal-Standard?
-
In der Eingabeaufforderung mit d64copy 8 test.d64 , da fängt die Übertragung sofort an [...]
Das deutet aber darauf hin, dass zumindest der Hänger weder an d64copy noch an der Zoomfloppy, sondern eher an CBM-Transfer liegt?
In CBM-Transfer (benutze ich selber nicht) kann man irgendwo einstellen, dass es die nibtools zum Erstellen von D64-Dateien verwenden soll. Hast du das vielleicht aktiviert? Falls ja, ändert es etwas am Verhalten (speziell daran, ob es hängt oder gleich losläuft), wenn du es ausschaltest?
Im Debug steht auch nur read error, soll ich es trotzdem mal posten (in Textdatei) ? Ist ja ziemlich viel.
Das bezog sich auf den Fall "Kopie startet erst nach 35s", da hätte ich nicht viel Text erwartet. Jetzt stellt sich die Situation ja etwas anders dar, da ist das komplette Protokolle tatsächlich Overkill. Du kannst ja mal die ersten Zeilen in denen sich der Fehler zeigt und so etwa 20 Zeilen davor anhängen, vielleicht sieht man da was. (Du solltest aber aufpassen, dass die verwendete Diskette keine vertraulichen Daten enthält, die kann man sonst evtl. aus dem Protokoll auslesen).
Könnte der VIA6522 eventuell ne Macke haben ?
Du schreibst im Eingangspost:
Hab alle meine seriellen Kabel durchgetauscht, alle meine Speeddos Floppys getestet (überall das gleiche Problem)
Da müssten ja dann die VIAs in allen Laufwerken eine Macke haben, oder verstehe ich das falsch? Ich dachte das Verhalten war reproduzierbar?
Am C64 funktioniert diese mit Speeddos. Dann habe ich weiter geschaltet auf Jiffydos seriell funktioniert, und was ich komisch fand
mit Parallelkabel funktionierte das auch, da hab ich die Zeit gestoppt ca. 37s für ein D64.
Mit "funktioniert" meinst du hier, dass du einzelne Programme laden konntest, oder was? Oder hast du auch versucht komplette Disketten am C64 zu lesen oder zu kopieren?
[...] dies habe ich mit dem SpeedDOS Kernal getestet, da waren die Fehler immer da, dann hab ich umgeschaltet und mit JiffyDOS probiert [..]
War bei den Jiffy-DOS Versuchen das Parallelkabel trotzdem noch eingesteckt oder hast du das vorher ausgesteckt?
-
SpeedDOS funktioniert, beginnt aber erst nach 35s die Datenübertragung (parallel), vorher blinkt die Zoomfloppy wie verrückt so das ich dachte, sie wäre abgestürzt
Schön, dass es "funktioniert", aber irgendwas ist da doch faul?
Verstehe ich das richtig, dass das bei Erstellung eines D64-Images mit CBM-Transfer ist?
Kannst du mal versuchen, ob das in der Eingabeaufforderung mit d64copy 8 test.d64 (Laufwerksnummer und Dateiname ggfs. anpassen) auch passiert?
Und falls ja mal mit set XUM1541_DEBUG=9 die Debug-Ausgabe einschalten und dann das Gleiche nochmal probieren:
1. Sobald es hängt mit Control-C abbrechen und die bis dahin erfolgte Ausgabe hier (als Dateianhang) posten.
2. Ein zweites Mal erst kurz nachdem es wieder losgelaufen ist abbrechen (also nach den 35s) und die Ausgabe ebenfalls posten (damit man sieht wo es hängen bleibt und was unmittelbar nachdem es weiterläuft passiert).
mit Parallelkabel funktionierte das auch, da hab ich die Zeit gestoppt ca. 37s für ein D64.
Bei mir dauert ein D64-Image (35 Tracks) mit Parallelkabel (aber ohne Speeddos) knapp 30s. Sind die 37s auch mit Gedenkminute oder ist das deine Messtoleranz?
-
Du musst MOSI, MISO und SCK verbinden
Ach ja, vergessen: Reset ("RST") auch. Dabei ist mir wieder eingefallen, dass du ja ein Bild geschickt hattest, die Anschlüsse scheinen also korrekt beschriftet zu sein.
-
Hätte einen MiniPro mit ISCP Schnittstelle ( TL866A ), aber wo könnte man diese Schnittstelle am Pro Micro anschließen.
Das sagst du jetzt, damit lässt sich doch arbeiten
Du musst MOSI, MISO und SCK verbinden, außerdem braucht der Pro Micro natürlich noch von irgendwo Strom. Wie der Stecker des Mini Pro belegt ist musst du selber rausfinden, wo sie die Leitungen beim Pro Micro liegen siehst du in dieser Übersicht. (Aber Vorsicht, ich glaube bei manchen Clones sind die Pins falsch beschriftet. Die Lage wird aber vermutlich stimmen).
Übrigens der Reset hatte auch keine Auswirkung.
Na, zumindest die Auswirkung, dass der Pro Micro neu gestartet hat, wird es schon gehabt haben...
-
Mir geht es darum, warum bei Verbindung mit den jeweiligen USB-Buchsen
im Gerätemanager die Verbindung USB to serial als COM erscheint und keine direkte USB Verbindung.
Das wird daran liegen, dass auf dem Board ein Programm läuft, das eine serielle Schnittstelle über USB implementiert. Ich könnte mir gut vorstellen, dass die Arduino Laufzeitumgebung für den Pro Micro das automatisch macht, damit sie darüber ihre Ein- und Ausgabe abwickeln kann, wenn USB nicht für etwas anderes verwendet wird. Darüber könnte man dann vermutlich auch einen Reset auslösen. Damit sind wir aber nicht weiter, weil 1. du mit diesem Reset ggfs. auch nur in den gleichen Bootloader kommst, den du mit deinen Mitteln offenbar nicht so einfach programmieren kannst und 2. ob das was hilft auch von der Antwort auf meine oben geäußerte Frage abhängt, ob man mit der Arduino IDE überhaupt externe erzeugte hex-Files programmieren kann (gut möglich, ich weiß aber nicht ob und falls ja wie).
-
Ja, aber man kann auch mit dem Programm ATMEL Flip, das ich im thread #1 als Foto mit der Fehlermeldung dargestellt habe,
diesen mittels .hex File programmieren.
Theoretisch ja, aber ich glaube das Programm kann nur mit dem Original Atmel Bootloader umgehen, der wie Diddl schon geschrieben hat, normalerweise auf den MCUs vorinstalliert kommt. Wie ich geschrieben habe ist der aber bei der Pro Micro Boards üblicherweise durch einen anderen Bootloader ersetzt. Man könnte zwar auch wieder den originalen Bootloader flashen (mit dem Flip dann zusammenspielen würde), das ist aber eher komplizierter als ein Programm zu finden, das mit dem "Caterina" Bootloader zurechtkommt und außerdem könnte man das Hex-File dann auch gleich mit dem dafür notwendigen Programmieradapter + -programm flashen
-
Vielen Dank, aber das ist mit meinen Kenntnissen etwas zu kompliziert.
Welcher Teil ist genau zu kompliziert? Die mit "GND" und "RST" bezeichneten Pins vor dem Programmieren kurzzuschließen ja wohl nicht. Eine andere Sache ist das mit dem Programmieren, wenn du dir das Arbeiten auf der Kommandozeile nicht zutraust wird es vermutlich in der Tat schwierig. Die Arduino Entwicklungsumgebung wird das Board mit den richtigen Support-Files vermutlich programmieren können, aber ob man da fertige, externe hex-Files zum Programmieren einschleusen kann weiß ich mangels Erfahrung damit aber auch nicht. Dazu können vielleicht andere was sagen.
Und der CH340G ist ein IC auf der Unterseite des Pro Micro. Die meisten Arduino Klone verwenden dieses IC für die USB Schnittstelle.
Der 32u4 des Pro Micro hat USB Unterstützung integriert (das ist der Witz des Boards), deshalb hat und braucht das keinen separaten USB/Seriell Baustein.
-
Die Pro Micros haben üblicherweise eine Variante des Arduino "Caterina" Bootloaders. Alle brauchen einen externen Reset, damit sie in den Programmiermodus gehen. Praktischerweise liegen bei den Boards Reset und Masse nebeneinander, so dass man das einfach mit einem Schraubenzieher oder kurzen Draht bewerkstelligen kann.
Dem Original reicht ein Reset, dann wartet er 8 Sekunden im Programmiermodus und startet normal, falls keine Programmierung erfolgt. Das Verhalten der anderen Varianten ist hier beschrieben. Die brauchen innerhalb relativ kurzer Zeit (< 1s) zwei Resets, damit sie in den Programmiermodus gehen.
Welche Version du hast, wirst du durch Ausprobieren rausfinden müssen.
Programmieren geht dann mit avrdude, als Programmieradapter "avr109" angeben. Mit Windows habe ich wenig Erfahrung; keine Ahnung, ob es da auch eine klickbare Lösung gibt...
