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

last post from CrazyIcecap at the

1541-Emul (zweiter Anlauf)

  • Hier die aktualisierte Verdrahtung + einem Foto von meinem Testaufbau:




    Ich habe noch sehr viele Bugs. Von zyklusgenau und optimiert noch gar nicht zu reden. Aber es kommuniziert schon mal so wie es eine 1541 tun soll: LOAD, SAVE, DIRECTORY, Fehlerkanal, Befehle senden funktioniert soweit.


    Die Probleme sind: es schmiert manchmal ab, Diskimage mounten und generell Befehle an den Emu gehen zur Zeit nur über RS232. Befehl "N:xxx,id" (formatieren) geht gar nicht.



    Ich denke für eine Vorabversion der Software ist es einfach noch zu früh. Es solte zumindest stabil laufen und Befehle vom IEC Bus an den Emu funktionieren. Es wird wohl noch zwei Wochen dauern, bis das soweit läuft.

  • Noch ne kurze Frage: Welche Software brauche ich auf PC-Seite? Hab hier grad AVR-Studio 6, das auch Unterstützung für Cortex M bietet. Reicht das? Oder brauche ich da noch was anderes?

  • Das 1541-Emul läuft jetzt superstabil. Wenn ich nicht ab und zu eine neue Software flashen würde, dann würde es kenen Reset mehr benötigen. :)


    Die Bugliste ist jetzt auch überschaubar. Die nächsten Tage wird es ernst mit einem ersten Betastand.



    Auf der SD Karte muss sich mindestens ein D64 befinden und ein binary des 1541 DOS. Das Binary muss exakt 16384 Byte lang sein (Binary ohne Ladeadresse). Getestet ist das DOS der 1541 und der 1541-II.

  • Beim Überfliegen hab ich nichts dazu gefunden: Wie kompatibel ist denn der momentane Stand? Kannst Du ein paar Beispiele nennen, was schon läuft und was noch nicht? Fang doch mal die CSDB-Demo-Charts von oben an, dann gibt's sogar eine Maßangabe dafür: 0% bis 100% der CSDB Demo Top 100 ;)


    Wie Du weißt, ist ein preiswerter, kompatibler 1541-Ersatz am seriellen Port (!) auch ein langersehnter Wunsch von mir. Auch wenn ich dabei die Flinte ins Korn geworfen hab.

  • Beim Überfliegen hab ich nichts dazu gefunden: Wie kompatibel ist denn der momentane Stand?


    Leider habe ich dazu noch kein Testergebnis. Ich tu mich auch sehr schwer mit Echttests. Da ich oft weg bin, hab ich keine C64 Hardware im Zugriff. Und zuhause habe ich auch keinen C64 fix aufgebaut. An den Wochenenden ist es aus diplomatischen Gründen auch oft besser, dies nicht oder nur selten zu tun.


    Zur Zeit teste mit einem Zoomfloppy und mittels Softwaretests. Gestern habe ich einen C64 angeschlossen und ein paar einfache Sachen probiert (load, save, Spacetaxi).


    Ich glaube für serielle Speeder ist es zu früh, noch gibt es Cyklusabweichungen bis 28µs. Ich denke über ein geändertes Konzept nach, wo die CPU direkt im Timer Interrupt läuft. Skoe hat das damals schon so vorgeschlagen. Das Problem dabei, ich müsste die zeitintensiven Sachen auslagern und getrennt von der virtuellen CPU machen.


    Das Wichtigste ist mal, dass ich nun die Sicherheit habe, dass es machbar ist. ^^

  • Du hast PN. Ist ein Entwicklerstand mit dem ich Freitags einige Zeit getestet habe. War noch auf keinem C64 angeschlossen, aber mit dem Zoomfloppy läuft es sehr gut.


    Die bekannten Probleme dieser Version:

    • DOS Kommando N mit ID (formattieren) geht nicht, keine Ahnung wieso.
    • Die virtuelle 6502 CPU läuft nur im Schnitt in der richtigen Geschwindigkeit, an dem Punkt arbeite ich gerade intensiv


    Anschluss an einem C64 ist kein Problem. Alles nur OC deswegen kann kein Schaden entstehen. Die Vorversion lief an meinem C64 tadellos, diese sollte es auch tun.

  • Grad per PN raus, hier nochmal ein Nachtrag: Zumindest mit nem Jiffy-ROM passiert anscheinend etwas: Es wird auf der SD-Karte eine TRKCACHE.BIN mit 280 kb erzeugt. Ansonsten das selbe: Einschalten, dann blinken alle 4 LEDs, danach wander das Licht im Kreis. Auf dem C64 kommt dann Device not present. Welche ROMs hast Du verwendet?

  • Ach so, jetzt hab ich dir schon die PN beantwortet. Also hier nochmals:


    Wenn du dich nach meiner Verdrahtung gehalten hast, dann musst du beide Boards mit Strom versorgen.


    Ich habe dies deswegen so am Laufen, damit ich zum Einen die Debug Ausgaben sehe (ARM2IEC USB Stecker) und flashen kann (Discovery USB Stecker).


    Wenn du die Plus NICHT verbunden hast, dann schliess mal beide USB an. Guck welchen virtuellen COM Port du bekommen hast vom ARM2IEC. Dann starte den PUTTY (oder HyperTerm oder beliebiges Terminal) an diesem COM Port.


    Wenn du jetzt am Discovery einen Reset gibst, sollte die folgende Anzeige kommen:


    Wenn die LED kreisen ist was faul. Sollte in der Anzeige am Terminalprogramm ein Hinweis kommen.


    Jiffy wird vermutlich nicht gehen. Noch nicht. Ich teste mit einem DOS einer 1541 (Datei soll dos1541.bin heissen). Hast du auch an ein D64 File gedacht. Wahrscheinlich schon wenn er den Trackbuffer erstellt hat ...

  • ok, nachdem ich die 1541-bin umbenannt habe, kommt es schon weiter, die blaue led flackert. Allerdings bekomme ich bei Putty über den MCP keine sinnvolle Ausgabe, da kommen nur 4 mal türkisches y, kurze Pause, dann noch eines und das wars. Am C64 immer noch device not present.

  • Wenn die blaue flackert, ist das schon mal sehr sehr gut.


    Beim Putty musst du 115200, 8,N,1 einstellen, dann solltest du Klartext sehen.


    Device not present ist schlecht, kommt bei mir nicht. Dürfte eigentlich nie kommen wenn die blaue LED flackert ...




    Hast die die beiden DATA und die ATN richt verdrahtet?


    Wenn du ATN auf low ziehst, dann sollte schlagartig DATA auch auf low gehen. Zumindest Innerhalb einer µs.