Hallo Besucher, der Thread wurde 8,1k mal aufgerufen und enthält 43 Antworten

letzter Beitrag von daybyter am

SD2IEC via RasPi

    Hallo liebe Community
    Ich finde leider im Netz unertschiedliche Ausführungen zu diesem Thema, jedoch eigentlich auch nichts wirklich konkretes. Ich möchte einen RasPi gerne mal als X1541 Laufwerk ausgeben und einen C64 damit befeuern. Ich habe sogar ein Youtube Video gefunden, wo der Vorgang gezeigt wurde. Ich weiß, es gibt auch so etwas schickes wie ein SD2IEC. Allerdings wollte ich den RasPi mit einem C64 kombinieren und zum einen wäre ein zweiter SD2IEC doppelt gemoppelt, zum anderen wollte ich zum Speichern der PRG-Files und Disk Images ein zentrales Speichermedium haben und nicht zwei (RasPi und SD2IEC SD Card).
    Ich kann mir vorstellen, dass man mit dem RasPi tatsächlich einen simplen IEC-EMU unetrschieben kann. Hardwaretechnisch wäre ja alles da und die unetrschiedlichen Spannungen könnte man ja mit Widerständen oder einem bi-direktionalen Level Shifter angleichen. Aber wie sieht es mit Fastloadern etc aus? Ich kann mir vorstellen, dass ein SD2IEC das Timing locker hinbekommt. Würde das auf einem RasPI in irgendeiner Form auch machbar sein oder ist der einfach zu "unpräzise"? Es gibt soviele Projekte um RasPi und auch um den C64... Aber die beiden Dinger sinnvol zu verbinden habe ich noch nirgends gefunden.

    Prinzipiell besteht das Problem, dass Linux nicht echtzeitfähig ist, der IEC-Bus aber (insbesondere mit Fastloadern) aber timingkritisch ist. Ich weiß nicht, ob es eine Möglichkeit gibt, Linux daran zu hindern, zum unpassenden Zeitpunkt in der Kommunikation dazwischenzufunken (und trotzdem noch sauber zu laufen), aber prinzipiell ist ein System, das den Prozessor exklusiv nutzen kann (Microcontroller ohne 'echtes' Betriebssystem wie Linux) für so eine Aufgabe besser geeignet. Das Betriebssystem ist halt der Master, der die Rechenzeit verteilt.

    Zitat von 1st1

    Und ACSI/SCSI ist nicht timingkritisch? Floppyemulation (wie HxC/Gotek) ist nicht timingkritisch?

    Deswegen werden solche Geräte üblicherweise auch mit einem Controller angesprochen, der die timingkritischen Sachen übernimmt und so das Betriebssystem entlastet.


    Mit Pegelwandlern könnte man bestimmt auch ein gewöhnliches PC-Diskettenlaufwerk am GPIO betreiben, aber hätte dann die gleichen Probleme mit dem Timing.

    Beim Gotek gibt's paar Infos dazu auf der Cortex Amiga Floppy-Seite, ist zwar ein ARM drin, aber ein spezieller:



    Beim Joo.kie.sk-Gerät ist schwer zu sagen, ob der auch die zeitkritische Kommunikation mit abwickelt, oder ob das über Zusatzhardware erledigt wird...


    Ich glaub aber, das Thema hatten wir hier schon mal Forum... da war das Fazit - egal wie man's anstellt - es bleibt fraglich ob's mit dem Raspi klappt.

    Auf dem Gotek der ARM hat 72 Mhz. Im Rapi 2B werkelt einer mit 900 Mhz, also knapp 13x so schnell. Ich behaupte mal, das reicht. (Der Rapi2B sitzt derzeit im CosmosEx) Zeitkritische Sachen kann man auch mit "brachialer" Rechengewalt lösen. :prof: Wahrscheinlich kann der Rapi2B während er eine 1541 (vollständig!) emuliert (1 Mhz, lach!) nebenbei noch Aliens per Seti@Home detektieren.

    Für ARM gibt es schon lange arm2iec und open1541 war auch schon relativ weit. Einen normalen Raspberry für diese Zwecke einzusetzen ist ein bischen über das Ziel hinaus, finde ich.

    Es gibt ja Risc OS für den Raspi. Das hat ein kooperatives Multitasking, sprich jede Anwendung erhält die volle Kontrolle bis sie sie wieder abgibt. Damit lassen sich timingkritische Dinge erledigen, ohne dass man wie bei einem Bare Bones System alles inklusive Dateisystem selber zusammenfriemeln muss...

    ich hab ueber das thema auch schon nachgedcht und moechte noch dazu einwenden, dass selbst auf 'bare metal' das timing nicht unbedingt deterministisch ist. wir haben CPU caches, branch prediction und den video core am PI. alles 'features', die als unsicherheitsfaktoren probleme machen koennen. microcontroller haben das alles meistens nicht, darum macht es sehr wohl einen unterschied. aber dennoch denke, ich dass es machbar ist und bin nach wie vor an so einem projekt interessiert. wobei ich denke, dass der PI noch mehr machen sollte als nur IEC.

    QNX wäre doch was dafür, klein, schnell und Echtzeit :)


    Hat einen Microkernel (ca.11Kb) und passt auf eine 1,44MB Diskette.

    Jetzt nur noch die Diskette in den Raspi kriegen ^^


    Es gibt wohl schon das eine oder andere Echtzeitsystem für den Raspi (o.a. auch RTOS-Abarten). Der Charme einer IEC-Lösung mit dem Raspi: man hat nicht ein weiteres Kistchen rumliegen, Raspberries haben die meisten ja schon (Retropie u.ä.).
    Falls jemand schon an so einem Projekt tüftelt: Burst-Mode mit 1571/1581-Emulation ist ein echtes Alleinstellungsmerkmal ;):D

    Zitat von Tale-X

    Burst-Mode mit 1571/1581-Emulation ist ein echtes Alleinstellungsmerkmal

    In der Tat, an der Stelle sind sd2iec nicht ganz optimal, obwohl die ansonsten ganz gut sind, insbesondere wegen d71 und d81. Die 1541 emulieren macht eine 1541 Ultimate II besser, daher rede ich im Zusammenhang mit dem sdi2ec lieber über d71 und d81. Ggf. auch über dnp - aber das mag Geos nicht so recht.

    Zitat von Draco

    Für ARM gibt es schon lange arm2iec und open1541 war auch schon relativ weit. Einen normalen Raspberry für diese Zwecke einzusetzen ist ein bischen über das Ziel hinaus, finde ich.

    Technisch vielleicht, aber finanziell bewegt man sich unterhalb sd2iec und der ultimate2. Und hat ein Gerät, dass man nach der Spielesession am C64 dann für andere Hobbies/Zwecke einsetzen kann.

    Wäre es dann nicht evtl. sinnvoll, den PI mit einem kleinen Microcontroller Shield ohne weietre Schnittstellen zu versehen? Das könnte ja die Ansteuerung und das Timing übernehmen und gleichzeitig mit dem PI kommunizieren bzgl SD Crad Reader etc. Wäre doch zum einen eine kostengünstige und zugleich wesentlich flexiblere Lösung und zum Anderen für nur geringen Aufpreis auf einen PI machbar. Der preis liegt dann gesamt vlt. auch bei rund 45,- Euro. Aber wie gesagt, man kann den PI dann noch für soviele andere Dinge nutzen. Letztlich ging es mir ja zum einen darum die SD Karte gemeinsam zu nutzen. Also den PI zum Beispiel als RetroPI betreiben und gleichzeitig eine 1541 zu emulieren. Zum anderen mehr Kontrolle über den eigenen SD2IEC zu haben. Whatever. Leider bin ich technisch nichts so versiert als dass ich das selbst n Angriff nehmen könnte.

    Ja, kann man alles machen, am Schluss hat man halt ein paar Wochen Arbeit investiert (eine weitere Schnittstelle µC<=>RasPi zu implementieren dauert schonmal ein paar Tage, bis das richtig funktioniert) und hat dann irgendwas super-fragiles und unhandliches auf dem Schreibtisch statt den typischerweise sehr schön schnuckeligen SD2IEC-Geräten, die es schon gibt.


    Was "Eine xxx MHz-CPU wird's schon schaukeln" angeht: Der IEC-Bus braucht Ansteuerung im unteren µS-Bereich; viele Fastloader kommen bei schon sowas wie <2µS Jitter durcheinander. Interrupt-Latenzen bei typischen Realtime-Betriebssystemen liegen aber im zweistelligen µS-Bereich, auch bei GHz-CPUs. Ganz so einfach ist das also nicht, aber grundsätzlich geht schon was, siehe z.B. 1541-Emul (was leider auch eingeschlafen ist, vielleicht sollte man Diddl nochmal wegen Sourcecode anstupsen), wobei da noch nicht klar ist/war, ob das auch die pingeligeren Fastloader schafft.

    Nur dass das SD2IEC am C128 unter CP/M ne Schnecke ist. Soweit ich sehe, gab's mal für das µIEC eine Burstimplementierung, aber das SD2IEC ist wohl ne andere Baustelle - da gibt's mangels Nachfrage nichts in der Richtung.