Hast du es vom Watterott oder direkt von Mouser?
Hallo Besucher, der Thread wurde 51k mal aufgerufen und enthält 147 Antworten
letzter Beitrag von CrazyIcecap am
1541-Emul (zweiter Anlauf)
- Diddl
- Erledigt
-
-
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.
-
Habs von Watterott.
Ich muss eh erst noch die Adapterplatine bauen...weiss einer, wo ich doppelseitige, durchkontaktierte Punktrasterplatinen herbekomme? -
Es geht auch ohne durchkontaktiert: ich habe das Discovery gesockelt (Buchsenleisten) und bin mit Lackdraht durch die Löcher durchgefahren (Discovery "unten" gelötet, ARM2IEC oben). Müsste mit normahlen Draht auch gehen, wenn er nicht zu dick ist.
-
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?
-
Wenn du nur binaries flashen möchtest, dann langt dir das ST-Link Utility.
Wenn du auch Sourcen kompilieren möchtest, dann rate ich zur selben Entwicklungsumgebung die die ich verwende: CooCox 1.50 + Toolchain arm-none-eabi-gcc-4_6
Ist alles frei erhältlich. Nicht mal registrieren ist notwendig ...
-
Wo finde ich denn das ST Link Utility? Irgendwie scheine ich Tomaten auf den Augen zu haben...
-
-
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.
-
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.
Sauber. Das wirdd bestimmt ein schönes Stück Hardware.
-
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.
-
So, Adapterplatine is ferdsch, nu warte ich auf die Beta.....:D
-
Fleissig! Die Beta ist noch nicht so weit. Aber ich lass dir heute Abend einen Entwicklerstand zukommen.
Gesendet von meinem HTC One X mit Tapatalk 2
-
Wunderprächtig, dann weiss ich zumindest schon mal, ob ich alles richtig gelötet hab
-
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:
Code- ### Discovery 32F4 - 1541-Emul v0.01.08 ###
- PCLK1: 42000000
- PCLK2: 84000000
- SYSCLK: 168000000
- -----------------
- initialize SDIO system ...
- using extra ram for virtual CPU: 10000000
- testing vMem, ok
- loading DOS from SD: ok (dos1541.bin)
- (same as internal DOS)
- ::vTrack: opening vTrack buffer ok.
- IEC bus response ok.
- IEC pin change irq ok.
- ----------------------
- starting DOS (fastmode) ...
- ok. 1000.000 cycles in 517 ms.
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.