Hello, Guest the thread was called67k times and contains 1195 replays

last post from DKahn at the

Projektvorstellung Sidekick64

  • Also so ähnlich wie ein EF3, nur dass auf die SD-Karte ein paar mehr Carts passen.

    8\|:schreck!::Ssshock:


    :respect: :ilikeit:

  • MC64

    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.

  • 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)...

  • 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.


  • 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?

    2x VC20, unbekannte Anzahl von C64 Brotkästen (KU-14194HB/250407/250425/250466), 2x C64G, 2x C64C transparent Dallas (KU Replika, Reloaded MK2), 1x C128, 2x A500 Rev.3, 2x A500 Rev.5, 3x A500 Rev.6, 4x A500+ Rev.8, 3x A600, 3x A1200 transparent, 2x A1200 Escom, 2x A2000 Rev.6.2, 1x A2000 Rev.4.1, 1x A4000D, 1x MISTICA FPGA16 Acryl, 1x MISTer FPGA

  • 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.

  • 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?

  • 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.