1541-Emul (zweiter Anlauf)

Ich habe mir den Rat von Unseen zu Herzen genommen und die SD Specs studiert. Dabei ist mir aufgefallen, dass der SDIO "1-bit SD data transfer mode" eigentlich mit drei Drähte auskommt. Siehe Bild, grüne Drähte. Der gelbe Draht ist SD detect, um zu erkennen dass eine SD Karte im Slot ist.

Zur Zeit verwende ich zwei USB Kabel, eines für das ARM2IEC board und eines für das Discovery. Deshalb braucht es nur den blauen Draht um die GND zu verbinden.

Damit ich die USB-Uart Bridge des ARM2IEC nutzen kann, muss der dunkelrote Draht die RX Pins verbinden. Dann sieht man im Terminal Window schön was das Discovery so macht ...

Und natürlich die IEC Leitungen. Einfach alle gleichnamigen verbinden, hab es auf der Zeichnung nicht gemacht. ATNi - ATNi, DATAo - DATAo, DATAi - DATAi, CLKo - CLKo, CLKi - CLKi.

Ich hoffe die Verschaltung ist jetzt etwas verständlicher.

Zitat von THaase

Software - I'm missing Software -

Ich muss leider gestehen, ich habe schon den zweiten Milestone verpasst und hinke dem Zeitplan hoffnungslos hinterher.

Die Einarbeitung auf den Cortex-M4 hat mich unglaublich viel Zeit gekostet. Ich dachte sehr blauäugig, dass die Basis Software in kurzer Zeit funktionsfähig sein würde. Aber der Code aus dem Netz funktioniert manchmal nicht oder nicht richtig gut, deshalb habe ich mich mit Dingen beschäftigen müssen, die ich nie eingeplant habe.

Aber die gute Nachricht ist, dass die Basissoftware nun endlich sauber funktioniert und ich mich nun an die Portierung des Emulator machen kann.

Zitat von THaase

Was hast Du als Layout Programm benutzt? BlackBoard ist das nicht, oder?

Ich bin ja kein richtiger Elektroniker, deshalb komme ich mit der gängigen Software kaum zurecht. Mein Bedürfnisse an Grafiksoftware sind "supersimpel" und "Userfreundlich". Sprich, ich benötige Software für einen Voll-DAU.

Deshalb verwende ich die von allen verpönte Software von Abacom. Ich verwende drei Produkte dieser deutschen Firma: SPLAN, SPRINT und Lochmaster. Die Zeichnung oben stammt vom Lochmaster.

Zitat von THaase

Ich glaub' da fehlt noch die TxD Leitung

Ich weiss, aber in der Software gibt es nur Ausgabe, der Emulator nimmt zur Zeit über USART keine Befehle entgegen. Deshalb langt zur Zeit RX vollauf ...

Zitat von Unseen

In dem Bild sind PP0 bis PP7 eingezeichnet, aber nicht PPH_IN und PPH_OUT - willst du das Ding auf Burstnibbler und OpenCBM beschränken?

Sehr guter Einwand! Ich habe mich mit dem parallelen Port bisher noch gar nicht beschäftigt. Aber die beiden Leitungen sind ganz klar notwendig.

An alle, denen das Discovery zu breit, zu kompliziert und was weiss ich noch was ist: Ja, es geht auch jedes andere ST32F407 board. Ich frag mich nur, wo die Leute leistbare F4 boards her bekommen wollen?

Man muss aber erwähnen, die meisten Boards dürften keinen JTAG am board haben, sodass ein externer Programmer notwendig wird.

Nein, dieses Board geht vermutlich nicht so ohne weiteres, weil verschiedene IO belegt sein dürften, ich schau mir das genauer am Wochenende an:

Sicherlich kann man das anpassen, sodass auch dieses Board geht. Aber es hat unnötigerweise externes RAM und Flash, das der Emu sowieso nicht nutzen wird ...

Edit:
Das Board dürfte möglicherweise unverändert funktionieren, der externe Speicher scheint nur die Ports E, F und G zu belegen. Allerdings ist das Board in einer Preisregion, wo man dann schon gleich eine U2 kaufen kann. Zudem hat es außer der geringen Baugröße keinerlei Sondernutzen. Im Gegenteil, man benötigt auch noch einen JTAG Programmer.

Zitat von Unseen

Externes RAM ist toll, ich hätte gerne ca. 1MB davon am LPC1769 mit möglichst hoher Geschwindigkeit... (SPI-RAM ist zu langsam)

Ich gebe dir schon recht. Aber wohl nicht für das ARM2IEC.

Der C64 greift so langsam zu, dass SPI-Ram wohl kaum an die Grenze kommen würde. Selbst wenn der C64 den parallelen Port benützt ...

Naja, Nachteil wäre es keiner, Speicher kann man nie genug haben ...

Neben dem FAT Verzeichnis könnte man auch gleich die eingelegte 1541 Diskette voll im RAM haben. man könnte sogar ein D81 Image im Speicher halten. Man müsste nur noch die Änderungen auf die SD zurück schreiben.

Und der 128MB Flash könnte man fast 800 Disketten einlagern. Allerdings wozu, die SD Karte fasst viel mehr und kostet fast nichts. Außer man will vom C64 aus ganze SD Karten kopieren ...

Auf der anderen Seite, das Modul gibts auch mit 8MB SRAM, - Man könnte auf dem Modul ein embedded Linux drauf laufen lassen.

Projektfortschritt:

Das DOS bootet direkt von der SD Card. Der Trackbuffer wird geöffnet und gegebenenfalls aus dem zueltzt eingelegten D64 Image gezogen. Die virtuelle CPU läuft brav in Echtzeit. Sieht mal vielversprechend aus ...

Die nächsten Schritte sind:

• IEC Leitungen mit dem virtuellen VIA verbinden
• ATN Interrupt
• Anschluss an einem Zoomfloppy zum Test
• Anschluss an einem C64 zum Test

Einfachste Dinge sollten dann schon gehen (Space Taxi).

Mittelfristig die nächsten Schritte sind dann:

• zweiter virtueller IEC Kanal, nach Vorbild der U2
• Befehlsinterpreter an virtuellen IEC Kanal anpassen (mount, unmount, CD, ...)
• Trackbuffer zurückschreiben in Imagefile in Idletime und nach Reset
• G64 Support
• Zyklusgenaue Emulation

Es gibt leider noch eine Änderung der IO Belegung: die PA15 benötige ich für ATNout, damit ich damit eine andere 1541 Floppy anschliessen und steuern kann. Der SD-CD wandert wo anders hin, vermutlich PC6. Werde heute Abend eine neue Zeichnung posten.

Übrigens müssen die übrigen IEC Leitungen (SRQout, RESETout) auf + gelegt werden. Momentan habe ich sie ohne Widerstand auf + gelegt, sollte kein Problem für den 74LS07 sein, habe ich mir sagen lassen. Gegenteilige Meinungen werden gerne diskutiert.

Zitat von Ace

Saubere Sache. Gibts später fertige Bausätze oder wie ist der Vertrieb angedacht ?

Kein Vertrieb geplant. Irgendwer wirds schon bauen, ich hoffe eigentlich stark auf unseren Donald. Das Problem bei den ARM ist die kleine Bauweise. Ich kenne nicht viele die sowas löten können.

Zur Zeit kann man es sich nur selbst zusammenbauen:

o Wenn es jemand eilig hat und es kann, dann baut er sich das aus dem Discovery

o Wenn jemand weniger gut löten kann, dann baut er sich das aus dem Discovery + ARM2IEC (ist halt nicht mehr ganz billig)

o Wenn Geld keine Rolle spielt, dann nimmt der ein HY-STM32F4xxCore144 + ARM2IEC (Prototyp Fotos folgen)

Wenn Donald alles auf eine Platine baut und den F4 bereits vorab auflötet (Löthilfe), dann könnte es wie alles Andere als Bausatz laufen. Die Kosten für den Chip sind gering, sodass es nur etwas teurer als ein SD2IEC kommen könnte.

Die "Luxusvariante" bezieht sich mehr auf die Optik. Das relativ große Discovery sieht nicht gut aus auf dem ARM2IEC, es verdeckt fast alles. Da ist das HY wesentlich zarter.

Zur Zeit ist kein Support für den 128MB Nand (auch nicht der NOR) und dem zusätzlichen 8MB SRAM geplant. Der SRAM des Controller ist mehr als ausreichend. Der NAND würde halt einen Betrieb ohne SD Karte ermöglichen. Nicht so der große Gewinn, jedenfalls nicht bei dem Preis.

Sorry, dieser Beitrag wäre mir fast entgangen, weil wir gleichzeitig gepostet haben ...

Zitat von Manawyrm

Ich nehme an, er wird die Schaltpläne und den Code veröffentlichen, und dann kann sich da jemand anders dran machen...

Schaltpläne wird es so nicht geben, da ich ja nur zwei bestehende Produkte verbinde. Aber natürlich einen Schaltplan, wie die beiden Platinen verbunden sind.

Der Sourcecode wir veröffentlich, sobald die erste öffentliche Beta raus ist. Vorab wird es Testcode geben für Testwillige.

Zitat von Manawyrm

ich würde aber noch nicht sagen, dass wir schon soweit sind.. oder täusche ich mich da?

Naja, ja und nein.

Ja, weil die Schaltung steht eigentlich. Also ist Nachbau erwünscht und auch Nachdenken über eine Platine.

Nein, die Software ist leider noch nicht reif, nicht mal für eine Alpha version. Allerdings kann sich das relativ rasch ändern. Sobald ich was habe, das halbwegs vorzeigbar läuft, gibts eine erste Version für Testwillige.

Cool, dann wird es langsam Zeit für ein fertiges Schaltbild, ich werde versuchen das heute zu erledigen.