Hello, Guest the thread was called37k times and contains 147 replays

last post from CrazyIcecap at the

1541-Emul (zweiter Anlauf)

  • Die betroffenen Pins sind LCD Kontrast und IEC Reset. Diese verwenden wir gar nicht beim 1541-Emul.


    Mal abgesehen davon habe ich die neue Platine im Einsatz ...



    Habe die Version die ich dir geschickt habe gestern nochmals geflashed und am C64 angeschlossen. LOAD"$",8 funktioniert tadellos bei mir. Würde mich echt interessieren was da los ist.


    Hast du die serielle Ausgabe jetzt?
    Geht das ARM2IEC in der Funktion als ARM2IEC, also mit dem LPC1769?

  • Merkwürden. Als ARM2IEC hat es einwandfrei funktioniert. Sollte vielleicht heute abend nach der Arbeit noch mal in Ruhe alle Pins checken.
    Mit der seriellen Ausgabe haut es immer noch nicht hin, kann aber auch an dem Rechner liegen. Muss ich mal mein XP-EPROMmer-AVR-PIC-Notebook nehmen statt der Vista-Kiste, die ich grad bekommen hab.

  • Die serielle Ausgabe wäre hilfreich, weil man vielleicht einen Hinweis auf das Problem bekommt.



    Wobei wenn die Blaue flackert ist mal schon ziemlich alles ok. Vielleicht hast du Data und Clock vertauscht? Welchen Verdrahtungsplan hast du denn genommen? Nur der letzte von Beitrag 82 ist ok, die vorher sind falsch beschriftet. Ich habe da DATAo und CLKo vertauscht beschriftet.

  • Der Plan war schon der richtige....nur sollte ich mir wieder angewöhnen, solche Pläne spiegelverkehrt auszudrucken, wenn man quasi von der anderen Seite lötet....dadurch habe ixch bei 2 Pins nen kleinen Dreher gehabt. DATAo statt aussen innen, und bei CLKi genau andersrum.....hargl.
    Mit Putty klappt es jetzt auch, und ich konnte auch schon erfolgreich das directory des gemounteten D64 listen. Wie kann ich das D64 wechseln? Und muss in der seriellen Ausgabe was passieren, wenn ich nen Ladebefehl gebe?

  • Mit Putty klappt es jetzt auch, und ich konnte auch schon erfolgreich das directory des gemounteten D64 listen.


    Großartig, gut gemacht!! :thumbsup:



    Wie kann ich das D64 wechseln?


    Das geht mit dem Befehl LI (load image).


    Wenn du "," eingibst im Putty, dann kommst du einen Kommandozeilen Interpreter. Dort gehen so Kommandos wie "d xxxx" (disassemblieren) und "m xxxx" (memory dump). Und eben unter anderem auch "li xxx.d64" (load image).


    Mit Q oder X verlässt man die Kommandozeile und kehrt zurück zu Emulation.


    Alternativ zu LI kannst du einfach ein D64 auf deine virtuelle Diskette kopieren. Oder den Trackcache löschen, dann nimmt er das erste D64 das er finden kann.



    Und muss in der seriellen Ausgabe was passieren, wenn ich nen Ladebefehl gebe?


    Die serielle Ausgabe endet mit dem Start des DOS, danach werden nur noch Probleme protokolliert.


    ##############


    Deine Hardware ist jetzt voll einsatzbereit.


    Die Software habe ich inzwischen ziemlich umgekrempelt. Die 6502 Emulation läuft jetzt versuchsweise im Timer Interrupt des ARM. Dazu habe ich den Timer 4 verwendet, der ist auf 1µs geeicht und auf "one shot" gestellt.


    Der Timer Interrupt 4 kommt und führt einen 6502 Befehl aus. Danach subtrahiere ich "Echtzeit" von "virtueller Zeit". Eine negative Differenz zeigt, dass die virtuelle CPU hinter her hinkt. Dann führe ich bis zu 30 mal weitere 6502 Befehle aus. Eine positive Zahl zeigt die Anzahl µs die die virtuelle CPU vorläuft (also zu schnell war). Diese Anzahl µs wird als neuer Timerwert gesetzt und der Interrupt verlassen. Wenn die Differenzzeit abgelaufen ist, dann kommt der Timer Interrupt und führt im richtigen Moment den nächsten 6502 Befehl aus.


    Die "Echtzeit" ergibt sich aus dem Zählerstand des Timer 5. Timer 5 ist 32 bit breit und zählt µSekunden seit Programmstart. Die "virtuelle Zeit" ergibt sich aus dem 32 bit Summe der Zykluszeiten der 6502 Befehle die ausgeführt worden sind. Da die virtuelle 6502 CPU mit 1MHz läuft, hat diese Summe ebenfalls die Einheit µSekunden. So sind die 6502 Befehle zumindest am Beginn synchronisiert. Ein exakteres Timing muss man sich eventuell noch beim IEC IO überlegen, für die Fastloader. Vielleicht gehts aber auch so ...


    Soweit die Theorie, aber in der Praxis muss ich vieles im Code verändern. Wenn zb. von der virtuellen 6502 CPU der Schrittmotor gesteuert wird (über das VIA), dann wird ein Spurwechsel angeworfen. Der Spurwechsel verursacht Zugriffe auf die SD Karte. Solche Dinge darf man im Interrupt nicht machen, weil der SD Code nicht reentrant codiert ist. Da steckt noch etwas Arbeit drin ...


    Ich bin nächste Woche nicht da und möglicherweise ohne Internet. Ich werde versuchen den Betastand bis Freitag zu releasen. Aber versprechen kann ich es nicht.


    Wenn inzwischen noch jemand seine Hardware fertig stellt, kannst du ihm gerne diesen Zwischenstand geben zum testen.

  • Der Timer Interrupt 4 kommt und führt einen 6502 Befehl aus. Danach subtrahiere ich "Echtzeit" von "virtueller Zeit". Eine negative Differenz zeigt, dass die virtuelle CPU hinter her hinkt. Dann führe ich bis zu 30 mal weitere 6502 Befehle aus. Eine positive Zahl zeigt die Anzahl µs die die virtuelle CPU vorläuft (also zu schnell war). Diese Anzahl µs wird als neuer Timerwert gesetzt und der Interrupt verlassen.

    Hoffen wir mal, dass das so reicht, das ist aber mindestens knapp. Beispiel: Beim C64DTV ist der CIA nicht 100%ig korrekt implementiert, nach einem Schreibzugriff auf $DD00 werden die CIA-Leitungen einen Takt (also 1µS) zu früh gesetzt. Das hat schon gereicht, damit JiffyDOS (wenigstens das der 1541) nicht mehr funktioniert. Und wenn ich das hier richtig verstehe, ist das Timing "in" einem Befehl bei Deiner Lösung nicht korrekt, sondern nur (in etwa) die Zeiten zwischen Befehlen. Aber bei z.B. STA (4 Takte) wird erst im vierten Takt auch geschrieben, während das bei Dir wohl de facto am Anfang des ersten (emulierten) Takts passiert...? Das wäre also wohl mindestens 3µS zu früh.


    Tipp zum Testen: JiffyDOS (wegen dieser 1µS-Geschichte) und Turbo Disk AKA Fast Load AKA Speeddisk (der synchronisiert sehr selten). Ein bequemes CRC-Testprogramm für das Kernal-LOAD ist bei SJLOAD dabei ("CRCCHECK", kennst Du vermutlich).

  • STA (4 Takte) wird erst im vierten Takt auch geschrieben, während das bei Dir wohl de facto am Anfang des ersten (emulierten) Takts passiert...? Das wäre also wohl mindestens 3µS zu früh.


    Stimmt, das ist aber beim Lesen und beim Schreiben so, daher könnte es sich ausgehen.


    Damit ist man aber längst nicht am Ende der Fahnenstange. Bei bedarf kann man da ja sehr leicht nachbessern, indem man den Zugriff auf die GPIO demensprechend synchronisiert. Vermutlich wird man das auch tun müssen, --> Feinarbeit.



    Tipp zum Testen: JiffyDOS (wegen dieser 1µS-Geschichte) und Turbo Disk AKA Fast Load AKA Speeddisk (der synchronisiert sehr selten). Ein bequemes CRC-Testprogramm für das Kernal-LOAD ist bei SJLOAD dabei ("CRCCHECK", kennst Du vermutlich).


    Danke, werde ich berücksichtigen.

  • Turbo Disk AKA Fast Load AKA Speeddisk (der synchronisiert sehr selten)


    Der ist nett, um wiederholt auftretende Abweichungen zu finden - aber wenn alles global um ein paar Mikrosekunden verschoben ist fällt das möglicherweise nicht auf. Ich wüsste aber auf Anhieb ausser Jiffy auch nichts was dafür empfindlich ist.

  • Diddl: Danke für die Infos. Hatte gestern noch probiert, eines der Programme von Disk zu laden, aber das hat nicht hingehauen.Am C64 schaut es anfangs normal aus, aber er lädt und lädt und lädt....Nach jeweils 5 Minuten Wartezeit für eine Datei mit ca. 30 Blöcken habe ich abgebrochen. Reset am C64. Anschliessendes laden vom Inhalt ging aber wieder problemlos. Merkwürdig.

  • Hatte gestern noch probiert, eines der Programme von Disk zu laden, aber das hat nicht hingehauen.Am C64 schaut es anfangs normal aus, aber er lädt und lädt und lädt....


    Interessant dass bei dir LOAD"$" geht und LOAD"DATEI" nicht?


    Bei mir lief beides tadellos. Wäre interessant, das zu untersuchen. Na mal schauen, inzwischen läuft das eh alles etwas anders, vielleicht behebts sich das.



    Frage: Du hast aber nichts spezielles laufen, Jiffy, AR, FC-III oder sonst ein Speeder?

  • Nein, ganz normaler, unverbastelter C64. Alles andere wäre kontraproduktiv beim aktuellen Stand. Hab ihn vorher noch mit ner echten 1541, einem SD2IEC und dem ARM2IEC getestet.
    Wenn ich den Ladebefehl absetze, kommt halt das Übliche, nur dass er bei Loading.... bleibt. Am M4 leuchten dann die gelbe und rote LED kionstant.

  • quatsch rot, ich meinte grün....die blaue ist in dem fall aus, meine ich, jedenfalls nichts mehr zu sehen. Nach einem Reset des C64 kann ich direkt den Ladebefehl fürs Directory geben, ich muss den M4 nicht resetten.


    Edit: Nach dem Ladebefehl flackert die blaue noch ne Weile weiter und geht dann nach etwa 3-4 Sekunden aus.
    Nach einem Reset des C64 erlischt nach kurzer Zeit die gelbe, und die blaue flackert wieder, dir grüne bleibt an.

  • Nach einem Reset des C64 kann ich direkt den Ladebefehl fürs Directory geben, ich muss den M4 nicht resetten.


    Aha, interessant. Also hängt er irgendwo außerhalb des Interrupts, vermutlich mit gesetztem Interruptflag (SEI), und offenbar wartet er auf eine IEC Leitung.


    Ziemlich strange, kann ich mir im Augenblick nicht erklären. Aber ich lass mir das durch den Kopf gehen und schau mir den Code nochmals genau an.

  • Edit: Nach dem Ladebefehl flackert die blaue noch ne Weile weiter und geht dann nach etwa 3-4 Sekunden aus.
    Nach einem Reset des C64 erlischt nach kurzer Zeit die gelbe, und die blaue flackert wieder, dir grüne bleibt an.


    Die Gelbe ist der Laufwerksmotor. Die Grüne das Laufwerks LED. Also bleibt der motor nach ein paar Sekunden stehen, ein Kanal bleibt offen.


    Der C64 lässt sich mit Run/Stop nicht unterbrechen?

  • Nein, ich muss den C64 resetten. Danach kann ich direkt ohne Probleme wieder das Verzeichnis laden.
    Habe schon mehrere .d64 getestet. Hängt sich immer beim laden auf.
    Ich habe jetzt mal einen kleinen Test mit meinem MMC64 gemacht. Mit dem "D64 reader (fast)" von gregg schmiert der M4 direkt ab. Ein heftiges aufblitzen der blauen LED, und das wars. Mit dem originalen "D64 reader" von Oliver kommt er zumindest etwas weiter, bleibt dann aber auch irgendwann stehen. Das folgt aber keinem Schema, von Track 1 Sector 6 bis Track 5 Sector 11 war alles drin. Wenn er hängt, reicht ein Userport-Reset. Der M4 muss nicht resettet werden.

  • Ich kann das Problem nachstellen. Es passiert nur am C64 und nicht am Zoomfloppy. Der virtuelle 6502 hängt immer an der Stelle $e987 (IEC Senderoutine). Da ist auch eine Verzögerung extra für den "1541" Modus.


    Die virtuelle CPU läuft zeitweise zu schnell. Daher stolpert der C64 manchmal wenn die 8 Bits zu rasch übertragen werden. Der C64 wartet auf das letzte Bit und die virtuelle 1541 wartet auf das Byte Handshake (Data low). Da alles bei gestzetem Interruptbit passiert leuchtet die Blaue voll hell. Sobald jemand das DATA setzt oder den ATN fällt die 1541 in die Warteschleife zurück.


    Müsste sich automatisch geben das Problem, sobald wir halbwegs zyklusgenau sind.



    Wie gesagt, ich bin jetzt 10 Tage weg, leider werde ich wohl keinen Beta Release schaffen vorher, sorry. Wenn ich noch einen Teststand schaffe, dann bekommst du PN.

  • Ich habe dir eine Pre Version der Beta gesendet. Leider konnte ich sie nicht mehr gross testen. Aber ich habe diese Version zumindest mit meinem C64 kurz ausprobiert. Es schaut auf den ersten Blick ganz ok aus. Space Taxi dreimal geladen und auch gespielt, kein Hänger oder sowas.


    Bin schon gespannt was dein C64 dazu sagt. Wenn die bei dir auch läuft, könnte das die erste Beta werden.

  • So, Feierabend....also gleich mal getestet.
    MMC64: Klappt. Zumindest mit dem normalen D64 Reader liest er problemlos die Disk ein.


    Spiel: Winter Games. Fastloader klappt nicht, wäre auch zu schön gewesen :D, aber mit kernalloader einwandfrei.


    Härtetest: Demo. Deus Ex Machinae kommt immerhin bis zum Big Breadbox-Part, aber dann ist Sense. Vorher hat er aber schon mehrmals nachgeladen, und ist auch weiter gekommen als mein letzter Versuch mit dem SD2IEC.
    Definitiv Betawürdig.