Also so ähnlich wie ein EF3, nur dass auf die SD-Karte ein paar mehr Carts passen.
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von SkulleateR am
Also so ähnlich wie ein EF3, nur dass auf die SD-Karte ein paar mehr Carts passen.
Ach, alles, was nicht timing- oder soundkritisch ist, kann man doch am Emu machen. Interessanter wäre, wie bekomme ich ein Banner aus PrintShop(?) heutzutage auf Endlospapier? Nicht, dass ich das heute bräuchte, aber das ist etwas, was ich mit PC und Laserdrucker nicht so gut machdn kann wie damals mit c64 und 9 Nadler mit Karbonfarbband.
klar kannst du das am emu machen. aber wenn man eine pi1541 auf pdf drucker erweitern könnte wäre das doch auch nicht schlecht.
sorry, aber mich schocken emuś einfach nicht an. gott weiss das ich es versucht hab....
ist aber wahrscheinlich eher schwierig zu realisieren.
ich dachte dabei an eine art druckertreiber für den c64. also der c64 gibt zb. ein geowrite dokument ganz normal
über den bus an den drucker aus. der raspi konvertiert das zu einem pdf dokument, so das man es an einem beliebigen
pc ausdrucken kann.
das hätte den vorteil das man kein drucker an den 64er friemeln muss für den es eh keinen treiber gibt.
Die Idee hatte ich auch mal, aber bisher gar nicht weiter darüber nachgedacht
Korrigiert mich, wenn ich falsch liege: es ginge ja nur darum, am Userport (oder ggf. serielle Schnittstelle) die Daten entgegenzunehmen (inkl. Ack, Busy etc) und das ESC/P Protokoll zu implementieren, richtig?
Was sind die höchsten Baud-Raten mit denen man rechnen oder umgehen können muss? Das Timing ist auf jeden Fall entspannter als am Bus (Expansionsport)...
So... die EF und MD Emulation ist jetzt im Repo, falls jemand einen Blick darauf werfen möchte. Mal sehen, was als nächstes kommt... FC3/AR6?
sorry , aber ich verstehe immer noch nicht was das ding kann...
brauch man da hardware? wenn ja was?
gibt es einen schaltplan und wie wird das ding mit dem Cevi verbunden.
Das "Ding" kann diverse Hardware emulieren, die man am Bus/Expansionsport des C64 betreiben kann, z.B. Geo/NeoRAM, Dual-SID + FM Expander, ROM/Flash Carts (z.B. Easyflash oder MagicDesk ROMs laufen lassen).
Hardware die man benötigt ist auf dem Bild auf der Github-Seite zu sehen: im Prinzip ein paar Levelshifter und Multiplexer. Wenn die Schaltung konvergiert, werde ich das mal in Form bringen (PCB). Der "Schaltplan" ist übrigens auch im Repo: https://github.com/frntc/RasPI…face/RasPIC64_Circuit.jpg
tuxer hier nochmal als Bild:
rechts oben auf dem Steckbrett ist das "Interface" (Levelshifter etc.). Ich stelle mir das so vor, dass das auf eine Platine in etwa so groß wie ein normales Cartridge passt und der Raspberry auf eine Buchsenleiste kopfüber draufgesteckt wird. Der Rest ist dann sozusagen Software-Defined Cartridge.
sieht doch schon gut aus. mit dem rpi als "co-prozessor" könnte man doch eine ganze menge machen.
die ganzen erweiterungen die man so gebrauchen kann, könnte man dann in software machen, wenn ich das richtig verstehe ?
Inspired by this project, I created an interface board to connect to the Raspberry Pi.
Maybe this could be of interest to some in this thread. See https://github.com/KimJorgensen/C64_Pi_Interface
Schöne Grüße aus Dänemark
Vorweck muss ich erwähnen das ich überhaupt keine Ahnung von der Materie habe.
Soweit ich weiß hängt die SCPU auch nur am Expansionport. Könnte das also theoretisch der Raspi auch emulieren?
Inspired by this project, I created an interface board to connect to the Raspberry Pi.
Maybe this could be of interest to some in this thread. See https://github.com/KimJorgensen/C64_Pi_Interface
Very neat! Reminds me of VidHD for the Apple II (https://www.vintageisthenewold…eo-card-for-the-apple-ii/).
I had a quick glance at your repo. The communication via the CPLD is unidirectional, right? (of course, running Raspbian you don't want to mess with the bus more than necessary... I tried the SID emulation including paddles and even some fake video streaming while running Raspbian and that was quite unreliable).
Pausing the CPU might be an option (your #2) when you switch to bare metal and have the communication bidir.
How much does the system as a whole depend on the real/physical VIC? Could it be replaced by some simple dummy for clock generation etc and let your hardware do the rest? Because if you manage to do this (option #2 plus the latter) you'd have a CPU+VIC replacement
In any case, even at this level a great achievement! In case you have one of these dev boards surplus...
I was also considering using a CPLD (for more flexible multiplexing -- mapping the inputs exactly as I need them for a particular application), but 1) I like the simplicity of only using 257 and 245 (even available as DIP), and 2) I have no experience with CPLDs...
sieht doch schon gut aus. mit dem rpi als "co-prozessor" könnte man doch eine ganze menge machen.
die ganzen erweiterungen die man so gebrauchen kann, könnte man dann in software machen, wenn ich das richtig verstehe ?
Ja, das ist/war mein Spaßvorhaben damit. Ich behaupte jetzt mal, alles was die IO-Ranges und ROMs nutzt (also auch Freezer) kann man machen. Alles was asynchron mitlaufen kann (wie z.B. SID und FM) geht ebenfalls recht einfach.
Das Easyflash und Magic Desk fand ich eine "massentaugliche" Anwendung (GeoRAM und Freezer würde ich noch dazuzählen), daher habe ich das erstmal umsetzen wollen.
Soweit ich weiß hängt die SCPU auch nur am Expansionport. Könnte das also theoretisch der Raspi auch emulieren?
(... das ist auch 2. Teil der Antwort auf MC64's Frage)
Ja im Prinzip. Bisher nutze ich den Standard RasPi, der eigentlich zu wenig GPIOs hat -- daher multiplexe ich die auch, aber bei einer SuperCPU und auf REU müsste man alle Adressleitungen und die m.W. auch bidirektional treiben. Das mit einem Standard RasPi wird vermutlich zu Timing-kritisch. Daher habe ich mir mal einen RasPi Compute Modul beschafft (48 statt 26 GPIOs) damit sollte das gehen... steht auf meiner Liste, etwas Geduld
sieht doch schon gut aus. mit dem rpi als "co-prozessor" könnte man doch eine ganze menge machen.
natürlich kann man auch beliebige eigene Coprozessoren umsetzen (oder direkt den ARM nutzen). Der Flaschenhals ist der Transfer, zumindest solange ich noch keinen DMA Transfer implementiert habe. Dann wäre vermutlich die schnellste Variante (Leute die sich auskennen mögen mich hier bitte korrigieren):
LDA absolute address # z.B. etwas aus der IO Range, Zähler auf dem RPi
STA address+X
usw.
wenn du dma realisieren könntest, wäre das natürlich ne geile sache. man könnte damit z.b. einen blitter realisieren und man hätte dadurch ein derbst schnelles geos.
tuxer hier nochmal als Bild:
rechts oben auf dem Steckbrett ist das "Interface" (Levelshifter etc.). Ich stelle mir das so vor, dass das auf eine Platine in etwa so groß wie ein normales Cartridge passt und der Raspberry auf eine Buchsenleiste kopfüber draufgesteckt wird. Der Rest ist dann sozusagen Software-Defined Cartridge.
kannst du mir sagen wo du die Karte für den Expansionsport her hast?
kannst du mir sagen wo du die Karte für den Expansionsport her hast?
Steht doch drauf...
Ich müßte auch noch ein paar da haben. Wenn Du Interesse hast, schick mir eine PM.
I had a quick glance at your repo. The communication via the CPLD is unidirectional, right? (of course, running Raspbian you don't want to mess with the bus more than necessary... I tried the SID emulation including paddles and even some fake video streaming while running Raspbian and that was quite unreliable).
Yes, the data transfer is unidirectional. If you require bidirectional communication and be able to respond quick enough to emulate a cartridge, I don't think the SMI bus is right choice (besides the issue you mention with running real-time application in Raspbian).
Pausing the CPU might be an option (your #2) when you switch to bare metal and have the communication bidir.
Well, it's my option #3, but your are forgiven . If we had that working it wouldn't be hard to increase the emulated CPU speed and maybe do a SCPU emulation.
Interesting that the Pi computer modules have more GPIO pins, I did not know that.
How much does the system as a whole depend on the real/physical VIC? Could it be replaced by some simple dummy for clock generation etc and let your hardware do the rest? Because if you manage to do this (option #2 plus the latter) you'd have a CPU+VIC replacement
The VIC is also responsible for DRAM refresh, but I'm not sure how hard that would be. What is the use case for replacing the VIC? Would you like to have a replacement for defective ones?
In any case, even at this level a great achievement! In case you have one of these dev boards surplus...
I think I have the spare parts for building another one, except the 25 MHz oscillator. Just send me a PM and we can figure something out.
I was also considering using a CPLD (for more flexible multiplexing -- mapping the inputs exactly as I need them for a particular application), but 1) I like the simplicity of only using 257 and 245 (even available as DIP), and 2) I have no experience with CPLDs...
Yes, your design is quite simple and easy to understand. It was actually my plan to implement your design in the CPLD, but then I got intrigued by getting the SMI bus to work.
Interesting that the Pi computer modules have more GPIO pins, I did not know that.
the drawback which stopped me from using it from the beginning on is that you need an IO board (at least for development) to have all the interfaces and pins.
The VIC is also responsible for DRAM refresh, but I'm not sure how hard that would be. What is the use case for replacing the VIC? Would you like to have a replacement for defective ones?
Although androSID is working on replacements, that's something I had in mind. And just for the fun of it...
wenn du dma realisieren könntest, wäre das natürlich ne geile sache. man könnte damit z.b. einen blitter realisieren und man hätte dadurch ein derbst schnelles geos.
... mit entsprechender Software... oder gibt es sowas via REU?
soweit ich weiß nicht. aber die reu kopiert ja selbständig per dma speicherinhalte von und zum ram des 64ers mit knapp 1mb/sek.
mein gedanke war diese funktion auszubauen. so könnte man vielleicht damit eine funktion realiseren, um z.b. schneller grafiklinien zu ziehen.
so wie der amiga das mit dem blitter macht. man hätte dann das, was anfang der 90ziger als windows beschleuniger verkauft wurde.
geos patchen und man hätte ein flotteres geos.
soweit ich weiß nicht. aber die reu kopiert ja selbständig per dma speicherinhalte von und zum ram des 64ers mit knapp 1mb/sek.
mein gedanke war diese funktion auszubauen. so könnte man vielleicht damit eine funktion realiseren, um z.b. schneller grafiklinien zu ziehen.
so wie der amiga das mit dem blitter macht. man hätte dann das, was anfang der 90ziger als windows beschleuniger verkauft wurde.
geos patchen und man hätte ein flotteres geos.
die REU kopiert m.W. blockweise, was aber nicht bedeutet, dass man einen DMA-Transfer nicht auch anders machen könnte. Ich frage mich nur, wer Geos patchen wollen würde... ich kann sowas nicht...
Zur Geschwindigkeit muss ich meine Aussage von oben, glaube ich, noch korrigeren. Schneller Transfer ohne DMA könnte mit ausgerolltem Code und so laufen:
LDA #$0
STA address1
STA address2
STA address3
...
LDA #$1
STA address4
...
das geht im Limit gegen 985k/Zyklen für STA (=4 für absolute Adressierung, richtig?) ... das wären dann >240kb/s wenn man den Code per EXROM/GAME/IO einblendet
die reu kopiert blockweise, das ist richtig. ich schrieb "funktion ausbauen", erweitern wäre wohl der passendere begriff gewesen.
es war auch nur ein gedanke. weil ich nicht weiß ob man das überhaupt realisieren kann.
ich stell mir das folgendermaßen vor:
im rpi hab ich ein virtuellen c64 bildschirmspeicher. alle interaktionen mit der maus oder tastatur finden zuerst in diesem speicher statt.
der rpi schauffelt das per dma in das c64 video ram.
es geht dabei zwar nur um 9k (8k bildschirm und 1k farbe), aber die frage ist obs unterm strich schneller wäre ? es würde wahrscheinlich auch ein inputlag entstehen.