Hallo zusammen,
im Raspberry Pi Thread wurde ja schon folgendes Projekt erwähnt:
http://www.insentricity.com/a.cl/207
Ich würde gerne den 1541 Emulator aus Frodo missbrauchen um den Raspberry zu einem "vollständigen" 1541 Ersatz zu machen. Der Entwickler nutzt das Ding auch um USB Joypads am C64 zu verwenden.
So wie ich das sehe ist in den Sourcen das ganze soweit abgedeckt was benötigt wird um mit dem IEC zu sprechen. Das ganze liegt hier auf github:
https://github.com/FozzTexx/ninepin/blob/master/README
Leider kapier ich zuwenig von der Elektronik um den IEC mit dem GPIO zu verbinden. Der Entwickler sagt nur "steht alles in der Readme".
Vielleicht hat jemand von euch Lust sich an dem Projekt zu beteiligen oder ihr zieht mir den Zahn
und sagt totaler Unsinn meine Idee :).
Hätte doch Scharm, wäre sogar günstiger als manche fertige SD2IEC oder 1541 Ultimate (ich weiß das da noch viel Arbeit für fehlt um das gleich zu setzen).
Für den Amiga gibt es da ja schon was fertiges:
http://amigadrive.blogspot.de/
Gruß
DerGali
last post from Phasengleich at the
Raspberry Pi als 1541 Emulator
- decoderone
- Thread is marked as Resolved.
-
-
nimm lieber ein sd2iec -
Ich seh aber ReadMe folgendes:
QuoteThe disk drive emulation works with directories and .d64 images. Files
in regular directories are automatically mapped to C64 file
types. Directories can be changed from the C64 side. It is also
possible mount and unmount .d64 images from the C64. There is no
emulation of a real 1541 so fastloaders will not work. -
Ich seh aber ReadMe folgendes:
Danke für den Hinweis, da das erst vor 13 Tagen ergänzt wurde, hat sauhund die neue ReadME wohl nur um wenige Stunden verpasst (hier alle Änderungen). -
Somit hat das Ding schon mal die wichtigsten Eigenschaften eines SD2IEC. Okay, es fehlt die Speeder-Unterstützung. Ansonsten fehlt mir persönlich, zumindest nach dem was zu lesen ist, nichts mehr. Bin mal gespannt was da noch kommt. Vielleicht wird daraus doch irgendwann mal eine richtige 1541 Emulation.
-
mich würde das auch interessieren, habe aber auch erst seit gestern einen pi (version B). was für ein grundsystem (NOOBS?) installiere ich denn da am besten um das emulierte drive zu nutzen?
-
Läuft das nicht Nativ?
-
ja, was ist denn beim pi nativ bzw. welches grundsystem? ich sehe das immer linux dahinter steht, aber ganz blicke ich nicht durch.
-
Nein, es steht NICHT immer Linux dahinter.
Ob es diesem Fall so ist weiß ich nicht.
Sollte der Entwickler jedoch wirklich irgendwann die 1541 zyklengenau, komplett mit allem drum und dran emulieren wollen, geht es MIT Linux schon mal gar nicht. -
In diesem Fall wird mit Linux gearbeitet. Warum sollte der Raspberry Pi das nicht hinbekommen? Ein normaler C64 Emulator mit der 1541 Floppy Emulation funktioniert doch auch. Mir ist klar das es nicht 100 prozentig gehen wird aber bestimmt geht da mehr als beim SD2IEC.
Und die große Frage steht ja immer noch im Raum wie verkabelt man das denn? Den Schaltplan den mir der Entwickler genannt hat gibt es hier:
https://github.com/FozzTexx/ni…da24d4d21d93e38bec81551cb
In der ReadMe steht dazu folgendes drin:
The driver supports both a 3 wire and a 5 wire interface, depending on
what kind of level shifters you have available (and how brave you
are). Switching between 3 wire and 5 wire currently requires
recompiling the module, it should probably be an option when doing the
insmod.If you are using the 3 pin mode, then the CLK and DATA pins are used
for both input and output. You can either use a bidirection 3.3V to 5V
level shifter, or do what I did and use some resistors to make a
voltage divider (see VoltageDivider.png). The voltage divider works
fine for me, but I only have the C64 and the Raspberry Pi on the
bus. Adding other devices could cause the voltage levels to increase
to more than the Raspberry Pi GPIO pins can tolerate. For each pin I'm
using a 1k and 1.5k resistor.In 5 pin mode, 3 pins are used to read the signals, and 2 others are
used to send output. This allows the use of unidirectional level
shifters such as a 74HCT245 and CD4050.Der Entwickler hat mir dazu nur geschrieben, dass es schon mehrere Leute ohne Probleme nachgebaut hätten.
-
Ein normaler C64 Emulator mit der 1541 Floppy Emulation funktioniert doch auch.
Wenn es mehr sein soll als ein SD2IEC dann müssen die 6502 und das Interface Zyklengenau emuliert werden und das ist mit einem Multitasking Betriebssystem so ohne weiteres nicht möglich.
Wie das im Vice gemacht wird weiß ich nicht. Da muss ein C64 Emulator mit einem 1541 Emulator kommunizieren und nicht ein Hardware C64 mit einem Emulator. -
Wenn es mehr sein soll als ein SD2IEC dann müssen die 6502 und das Interface Zyklengenau emuliert werden und das ist mit einem Multitasking Betriebssystem so ohne weiteres nicht möglich.
Doch, zyklengenaue Emulation ist unabhängig vom Betriebssystem darunter gar kein Problem - wenn alle Schnittstellen zur Aussenwelt "langsam" genug sind, d.h. im Falle von VICE müssen nur die Eingaben des Benutzers und die Ausgaben auf dem Bildschirm rechtzeitig da sein. Letzteres muss nur schnell genug sein, um 50 Bilder pro Sekunde zu berechnen und wenn das etwas zu schnell erfolgt ist kann man die Restzeit problemlos mit Warten verbringen (und wenn es einmal kurz zu langsam war sieht man auch nur ein kurzes Ruckeln). Die Kommunikation zwischen dem emulierten C64 und dem emulierten Laufwerk ist da auch kein Problem, der Emulator muss eh mitrechnen, welchen Zeitpunkt er gerade emuliert und kann darüber die Kommunikation zwischen den beiden Komponenten im Gleichschritt laufen lassen.Das ganze wird dagegen deutlich schwieriger, wenn eine emulierte Floppy mit einem echten C64 reden soll (oder umgekehrt): Jetzt muss der Abgleich mit der "Realzeit" nicht die 50 mal pro Sekunde erfolgen die für die Bildschirmausgabe wichtig waren sondern (in erster Näherung, aber deutlich besser wird es auch nicht) es muss jeder Prozessortakt synchron zur Realität umgesetzt werden - 1 Million Synchronisationszeitpunkte pro Sekunde. Wenn man einen davon verpasst ist das deutlich schlimmer als nur ein kurzer Ruckler, denn das echte Gerät läuft trotzdem weiter und die Kommunikation wurde möglicherweise gestört.
-
Es gibt relativ gute Ansätze das Linux auf dem Raspberry Pi zu einem guten RTOS umzubasteln, aber allgemein wird es nicht soo ohne weiteres möglich sein, z.B extern Daten auf den Raspi zu kopieren, weil dafür immer der USB Controller in Software "realtime" interagieren muss. Das dürfte also relativ haarig werden, aber defintiv interessant, ob der Entwickler es hinbekommt Linux genug zu verbasteln
-
Soweit ich weiss, sind EchtzeitDinge in RISC-OS durchaus moeglich.
Bare metal Anleitungen zum Raspi gibt es ebenfalls. RAM ist genug da um einiges zu puffern bevor man auf SD-Karte schreiben muss. -
Jaa, im RISC-OS oder direkt auf Bare-Metal kann das ein verhältnismäßig fetter 1GHz ARM natürlich...
Aber unter einem System was die ganze Zeit wild multitasked?
-
Hier sieht man einen Raspberry PI als 1541-Emulator im Einsatz, anscheinend funktioniert es ganz gut :
[External Media: http://www.youtube.com/watch?v=V7GrOcyTvBQ] -
Hallo!
Bin dabei das mal mit einem PI nachzubauen. Hab mir mal die notwendigen Teile besorgt (Levelshifter, Buchsen usw).
Das kritische Timing wird via "Interrupt Disable" im Kernel Modul realisiert.
Als OS wird glaube ich ein "normales" Pi Linux (z.B. Raspbian) verwendet.
Ich hab jedenfalls alles kompilieren können und das Kernel Modul wird geladen.Das Kernel Modul kann auf 2 Arten kompiliert werden:
1. mit der Spannungsteiler Schaltung (würde ich aber persönlich davon abraten)
2. mit er Levelshifter Schaltung (da sind die GPIOs vom PI besser geschützt)Wie der Levelshifter verdrahtet wird, muss ich mir noch ausmalen, weil es leider kaum bis gar nicht dokumentiert ist.
Wenn ich weitere Infos habe, werde ich euch informieren.LG,
Tulan -
Hallo nochmal!
Also ich habe gestern mal die Schaltung aufgebaut (Levelshifter) und mit dem C64 verbunden. Am PI das Kernel Modul kompiliert und das "ninepin" Programm gestartet.
Ein paar erste Testläufe haben nicht funktioniert. Beim Pi kommt zwar ein Kommando an, leider nicht das richtige.
Ich vermute, dass es sich doch noch um eine Timing Sache handelt.Am Pi kommt z.B. folgendes an wenn ich am C64 LOAD "$",8 aufrufe:
Command: 28 f0 01 00 01 04
oder
Command: 28 00 00 00 00 02
oder
Command: 28 00 02 00 01 00
oder
Command: 28 e0 00 00 00 01usw.
Ich bin mir nicht sicher was genau ankommen sollte, aber im Video kommt das Kommando:
Command: 28 f0 01 00 01 01 4b an (das letzte Byte scheint eine Checksumme zu sein)Ich werde euch weiter berichten, sobald ich neue Ergebnisse habe.
LG,
Tulan -
Ich habe es auch zum laufen bekommen allerdings die Sd Karte inzwischen formatiert weil ich dachte das benutzt eh keiner.
-
decoderone: Darf ich fragen, was du für ein Linux verwendet hast? Irgendwelche Realtime Patches?
Hast du es auch mit den 2 Levelshifterm aufgebaut, oder mit den 6 Widerständen?