Hello, Guest the thread was called33k times and contains 147 replays

last post from CrazyIcecap at the

1541-Emul (zweiter Anlauf)

  • Du hast halt mit der U eine sehr bequeme Möglichkeit die Images zu wechseln.
    Und auch nen Onefiler per DMA in den Speicher zu blasen ist auch recht nett.
    Außerdem bringt es ne REU Emu und nen dedizierten SIDplayer mit.


    Wenn man das alles da noch dranfummeln will kann man sich preislich auch ne U kaufen.


    1541 EMU wird vom Preis immer etwas über den einfachen SD2IEC Lösungen liegen.

  • Du hast halt mit der U eine sehr bequeme Möglichkeit die Images zu wechseln.


    Die Möglichkeit bietet das 1541-Emul auch, über SD2IEC kompatible DOS Befehle und einem Tool am C64.



    Aber wie gesagt, es ist nicht als Konkurrenz zum U2 zu sehen. Es füllt die Lücke zwischen SD2IEC und U2. Vom Preis her liegt es in der Region des SD2IEC / ARM2IEC. Für selbst Löter ist es um 21€ herstellbar. Das Discovery habe ich inzwischen um unter 15€ gesehen.

  • Och, der Hauptkaufgrund für die Ultimate damals war bei mir auch die 1541Emu, wenn dein Gerät da schon fertig gewesen wäre, hätte ich nie soviel Geld für die Ultimate ausgegeben. Beim Chameleon ist das was anderes das ist ein kompletter C64+2x1541+VGAOut+Module inkl Easyflash+Reu+... und andere Cores wie Amiga, Speccy und was sonst so kommen wird gleich mit.


    Also ich sehe dein Produkt durchaus als ernsthafte Konkurrenz zu der Ultimate, aber keine zum Chameleon.

  • Quote

    Die Möglichkeit bietet das 1541-Emul auch, über SD2IEC kompatible DOS Befehle und einem Tool am C64.


    Das ist ja dann wie der Stand-Alone-Modus vom Ultimate 1. Dann fehlen nur noch die drei Knöpfe (ein Image vor, ein Image zurück und Einlegen), dann
    wäre das zumindest ein Ersatz für den Standalone-Betrieb vom Ultimate I.
    Und ein ZUSATZ für die Ultmate II, dass kan ja den Standalone gar nicht ...

  • Wäre schön wenn jemand eine Platine basteln könnte, wo man das Discovery drauf stecken kann.

    Ist das nicht etwas früh? So wie ich das verstanden hatte, hast Du noch nichts außerhalb des Emulators Lauffähiges, oder? Aber das alles mit exaktem Timing hinzubekommen ist doch erst das Kitzelige.


    Gibt's eigentlich die Sourcen auf GitHub oder sowas?

  • Aber das alles mit exaktem Timing hinzubekommen ist doch erst das Kitzelige.


    Das stimmt. Aber da ändert sich aber nichts mehr an der Pin Belegung. Die Hardware steht. Sobald ich dazu komme, mach ich mal ein Schaltbild mit Splan.



    Gibt's eigentlich die Sourcen auf GitHub oder sowas?


    Neumodischer Kram ... ;)


    Sobald der erste Prototyp vorzeigbar ist, gibt es ZIP Files.

  • Hi Diddl,


    anfixen ist ja sowas von gemein :bgdev


    Ich hab' hier auf der Arbeit ein Discovery rumfliegen was momentan nicht gebraucht wird (kann man sich also erst mal ausleihen :P ) ...
    Ich hab' ein arm2iec ....


    OK, am Ende will ich ein anderes Baseboard .... aber:


    Kannst Du bitte mal Dein Wireing zur verfügung stellen .... nachher kippst Du hier einen zip ab und ich bin mal wieder der letzte der das ausprobieren kann weil ich mal wieder keine Zeit zum Löten hab'.


    Gerne auch als PM

  • Dein Wireing zur verfügung stellen


    An sich sehr gerne. Ich wollte es eigentlich nur vermeiden, damit daran noch was ändern kann wenn ich einen Vorteil darin sehe.


    Zur Zeit ist es allerdings erst minimal verdrahtet (IEC teilweise). Für SDIO fehlen Pins. Es fehlen noch die Taster, DIP switch, LED, der USART2, USB Host, parallel IEC, SRQ, Reset ...

  • Das ist meine provisorische Belegung. Ich habe bewusst auf die Drähte verzichtet, weil es nicht zur Übersichtlichkeit beiträgt.


    Das Bild zeigt die Ansicht von oben. Oben (P1, Jp1) und Unten (P2, Jp2) skizziert das Discovery. Dazwischen sieht man die ARM2IEC Belegung (1-54, P1-P18).


    Der USART ist einfach: TXD0 - TXD0, RXD0 - RXD0.
    Angeschlosse am USART2 vom Discovery (PA2, PA3)


    Der IEC Bus liegt erst mal auf PB0-PB2 (ATNi, DATAi, CLKi) und PA1 (DATAo), PA8 (CLKo). Da beim Discovery alle GPIO Pins interruptfähig sind, bleibt das vermutlich auch so.


    Die SD Karte liegt am SDIO Port des Discovery. Leider hat das ARM2IEC nur eine Datenleitung angeschlossen: SD_DI - SD_CMD, SD_DO - SD_D0, SD_CLK - SD_CLK, SD_CD - SD_D3/CD, SD_DET - PA15. SD_WP ist gar nicht angeschlossen, weil µSD unterstüzt sowieso kein WP, und die Zielplattform ist µSD.





    Ich hoffe die Zeichnung ist halbwegs verständlich?

  • Der IEC Bus liegt erst mal auf PB0-PB2 (ATNi, DATAi, CLKi) und PA1 (DATAo), PA8 (CLKo). Da beim Discovery alle GPIO Pins interruptfähig sind, bleibt das vermutlich auch so.


    Tip: Wenn ein Xpresso auf der Platine steckt hängen die IEC-Leitungen ausser Reset komplett an Capture- und Match-Signalen von zwei Timern.


    Tip 2: Auf ARM kommt sd2iec komplett ohne zyklengezählten Assemblercode aus, auch bei den Fastloadern.


    Quote

    Leider hat das ARM2IEC nur eine Datenleitung angeschlossen


    Da die Kartenansteuerung via Hardware-SPI wohl immer noch deutlich schneller sein dürfte als via Software-4-Bit-SD (Hardware-SD gibts im LPC1769 nicht) wäre alles andere auch ziemlich blöd gewesen. =) Reichen dir 3 MByte/s nicht?

  • Ich hoffe die Zeichnung ist halbwegs verständlich?

    Jup - kriegen wir hin :P
    Jetzt muss ich nur noch einen AES basierenden ROM Bootloader für einen M3 bastelen und dann hab' ich auch wieder Zeit zum löten :(


    Edit:
    Obwohl ... ich hab' hier noch nette Flying Leeds ... die sind glaube ich noch besser geeignet (eine Seite Stecker / eine Seite Buchse) :P
    Ich warte dann mal auf die erste SW (mit Emulatoren hab' ich mich noch nie beschäftigt)



    Dank' Dir!!

  • Die SD Karte liegt am SDIO Port des Discovery. Leider hat das ARM2IEC nur eine Datenleitung angeschlossen: SD_DI - SD_CMD, SD_DO - SD_D0, SD_CLK - SD_CLK, SD_CD - SD_D3, SD_DET - PA15. SD_WP ist gar nicht angeschlossen, weil µSD unterstüzt sowieso kein WP, und die Zielplattform ist µSD.

    OK, noch einer - SD_CD (sollte doch Card Detect sein? oder meinst Du DET damit?) geht aber auch nicht bei µSD - oder ich vertue mich jetzt gerade ganz gewaltig! (Bin gerne eines besseren zu belehren)

  • Hast mal ne Quelle, wo man das als normalsterbliche Privatperson günstig erstehen kann? Reichelt?


    Ich habe meine von Watterott um 16,99€ bestellt. Konnte keine günstigere Quelle finden, aber lass mich gerne belehren ... ;)



    Reichen dir 3 MByte/s nicht?


    Doch natürlich reichen 3 MByte/s ganz leicht. Ich versuche nur immer alles unnötig zu perfektionieren. Schlechte Angewohnheit, aber bei einem Hobby ist das ok.



    OK, noch einer - SD_CD (sollte doch Card Detect sein? oder meinst Du DET damit?) geht aber auch nicht bei µSD - oder ich vertue mich jetzt gerade ganz gewaltig! (Bin gerne eines besseren zu belehren)


    Man findet im Netz unterschiedliche Bezeichnungen der PINs der SD Karten. Aber natürlich sind die genormt und die Funktion ist gleich.


    Es liegt daran, dass es 3 Betriebsmodi gibt: 1 Bit (alte SD), 4 Bit (neue SD) und 8 Bit (nur MMC) Modus. Eine SD Karte sollte alle 3 Modi beherrschen, tun sie aber nicht. Je nach verwendeten Modus haben die Pins teilweise andere Belegungen bzw. Bezeichnungen.

  • Es liegt daran, dass es 3 Betriebsmodi gibt: 1 Bit (alte SD), 4 Bit (neue SD) und 8 Bit (nur MMC) Modus.


    Lies doch mal endlich die Specs oder wenigstens Wikipedia-Einträge... MMC bot ursprünglich zwei Modi, den eigenen 1 Bit breiten Modus und optional eine Ansteuerung via SPI, ebenfalls 1 Bit breit. SD hat darauf aufbauend zwei neue Pins eingeführt um zwei und vier Bit breite Transfers nutzen zu können und den SPI-Modus verpflichtend gemacht - schon in der allerersten Version der Spezifikation, die höhere Geschwindigkeit durch 4 Datenleitungen statt einer war ein wichtiges Argument um SD gegen MMC "durchzudrücken". MMC hat natürlich später nachgelegt (MMC Plus) und zusätzliche Pads für bis zu 8 Bit Datentransfer definiert, aber in Kartenform kenne ich sowas nur von Bildern.