Meine Schnapsidee: SD2Expansionsport (Cartridge)

Cartridge Lösungen mit SD-Karte gibt es ja ein paar (MMC Replay, Turbo Chameleon, 1541Ultimate, ...)

Trotzdem wäre das interessant SD2IEC quasi parallel angeschlossen und damit viel flotter beim Lesen und Schreiben von Daten...

Schau Dir mal an, wie eine SD Karte per SPI angesprochen wird. Du könntest jeweils 8 Bit in ein Schieberegister schieben und dann parallel in den Expansionport übernehmen.

Den Rest könntest Du per Software machen.

Ist aber recht viel Code, weil Du ja das FAT Filesystem implementieren müsstest.

Das SideKick ist auch nicht viel größer als ein Steckmodul und hat einiges zu bieten. Wäre so meine Idee für eine low cost Lösung am Expansionport. Hat sogar ein OLED drauf und bringt sein eigenes Menü und Filebrowser mit. Mit Adapter auch am C16/+4 und VC20 (noch im Test) anschließbar.

Geht es dir darum Daten parallel zu übertragen, um Geschwindigkeit, oder um was genau ?

1541U II + kennst du aber ?

Wenn es unbedingt eine SD Karte sein soll nimm einen Adapter auf USB

Der Zugriff auf IEEE-488 Geräte funktioniert ja nur mit entsprechender Software im C64. Ich bin nicht sicher, aber ich vermute es gibt nicht viel Software dafür, und schon gar keine die wirklich ein Grund für so ein Projekt wäre, weil sie bei vielen Leuten im Einsatz ist (man möge mich korrigieren wenn ich falsch liege). Daher würde ich auf IEEE-488 Kompatibilität pfeifen, und eher den schnellstmöglichen Zugriff auf die SD-Karte implementieren. Aber wie oben schon gesagt, gibt es grundsätzlich schon Lösungen für schnelle Massenspeicher am Expansionport. Man müsste sich also überlegen, was das Alleinstelliungsmerkmal für eine neue Lösung wäre.

Der Vollständigkeit halber sei hier auch noch das Kung Fu Flash Modul erwähnt. Die Hardware ist sehr kompakt und liefert eigentlich genau das, was Dir vorschwebt: Einen STM32 Controller, der auf der einen Seite mit dem Expansionsport verbunden ist und auf der anderen mit einem SD-Slot, und keine Kabel.

Die aktuelle Firmware bietet sogar Support für d64 Disk-Images. Allerdings ist die Kompatibilität sehr eingeschränkt (weil: keine Kabel).

Ich vermute, man könnte so ein IEEE Disk Cartridge implementieren, indem man eine entsprechende Firmware schreibt, ohne die Hardware zu verändern. Aber wie Claus schon anmerkt: der Nutzen wäre wohl gering. Das müsste einem egal sein.

Schau mal hier:

http://forum.6502.org/viewtopic.php?f=2&t=2693&start=15

Ich hätte da noch eine Frage: Wenn ein gestartetes Programm dann über die Standardroutinen auf die Floppy zugreifen will... wie geht das, ohne den Code zu patchen?

Gar nicht. Das Ansprechen eines IEEE 488 Geräts benötigt komplett eigenen Code, da kann nichts von den seriellen Kernalroutinen verwendet werden.

Es gäbe tatsächlich eine Möglichkeit; und sowohl die Hardware und Software sind als Einzelteile fertig. Lediglich keine Gesamtplatine. Worum geht es?

Man braucht tatsächlich einen IEEE-488 Adapter und ein SD2IEEE, auch PetSD genannt.

Das IEEE Modul ist natürlich für den Expansionsport. Die Wahl ist beliebig; ich selber habe ja zusammen mit einem Kollegen vor 35 Jahren solche Adapter auf der Basis eines 6522, 6526 und 8255 für den c64 und auch 128 hergestellt. Vom 6526 als auch 6522 gibt es Nachbauten hier im Forum; das Echo war aber sehr gering.

JEDES Modul, auch die Module anderer Entwickler, braucht natürlich ein passendes Kernal, mit dem man auch "einfach" zwischen seriell und IEEE umschalten kann. Und das vor allem möglichst kompatibel ist: Beliebte Tests waren damals ein Spiel (Wolfenstein) und die Z80 Karte mit CP/M.

Und an diesen IEEE-Bus kann man dann ein SD2IEEE anschliessen; natürlich kein SD2IEC. SD2IEEE Module - mit oder ohne display - gibt es bereits fertig. Ich selber habe eines in meinem CBM 8032.

Ein fertiges Modul gibt es hier: http://petsd.net/

Ein anderes hier: https://www.thefuturewas8bit.c…re/pet/sd2pet-future.html

Ein drittes hier: https://bitfixer.com/product/petdisk/

Ein viertes hier: http://www.retroswitch.com/products/flyer/

Vor 10 Jahren gab es auch einen Thread hier im Forum, aber die Links und Webseiten dazu sind inzwischen tot.

Je nach Geschmack verbindet man das passende SD Modul mit dem IEEE Modul über die Stiftleiste(n) oder direkt zum Aufstecken das SD2PET auf die Platinenzunge des IEEE Moduls mit 6522. Kernal ist hier in der Wolke und im 6522-IEEE Thread. Notfalls per PN.

Dann hat man ein "schnelles" SD-Floppylaufwerk mit IEEE Bus am C64

Nachteil der IEEE-Lösung: Was anderes als Onefiler wird nicht gehen.

Dann nimmt man doch besser gleich die ganzen Alternativen, die schon genannt wurden: EasyFlash, Kung-Fu-Cart, SideKick, EPROM-Karte, ...

Ohne seriellen Anschluss wird es keine 1541-Kompatibilität geben. Und mit seriellem Anschluss sind wir wieder gleich weit: 1541-U2, SD2IEC, ...

Wobei: Ohne externe Verkabelung und mäßig kompatibel geht es mit einem internen SD2IEC, das ist wohl die sauberste Lösung.

Aber um bei der ursprünglichen Frage zu bleiben ...

-- Ein SD2IEC parallel anschliessen --

Das geht natürlich, mit all seinen Vor- und Nachteilen.

So wie in das SD2IEC verschiedene serielle Speeder implementiert worden sind, kann man auch zb. ein Dolphin DOS implementieren.

Man kann dann das SD2IEC entweder am Userport oder über die gängigen Cartrigde Lösungen anschließen.

Man müsste halt schauen ob am Atmega 1284 noch 10 Pins frei sind oder einen größeren Atmega nehmen oder einen Port Expander.

Tja, das liest wohl jeder anders. Für mich war die ursprüngliche Frage...

— Ein Floppy-Cartrigde ohne Kabel —

Quote from kinzi

Nachteil der IEEE-Lösung: Was anderes als Onefiler wird nicht gehen.

Das stimmt definitiv nicht! Ein (gut gemachtes) IEEE Modul erlaubt auch die Verwendung von Programmen, die Teile nachladen. Auch REL Files; deswegen das Spiel Wolfenstein als Test oder CP/M. Es funktioniert alles, was die Standard-Einsprungadressen bzw. Routinen des Kernals verwendet.

Das gleiche gilt ja für Jiffy-DOS: Auch hier wurde der Kernal angepasst und bleibt kompatibel.

Die "Zwei-Teile" Stecklösung mit IEEE und Pet-SD wäre ohne Kabel...

Quote from Asklia

Das stimmt definitiv nicht! Ein (gut gemachtes) IEEE Modul erlaubt auch die Verwendung von Programmen, die Teile nachladen. Auch REL Files; deswegen das Spiel Wolfenstein als Test oder CP/M. Es funktioniert alles, was die Standard-Einsprungadressen bzw. Routinen des Kernals verwendet.

Und genau das ist das Problem: Kein Spiel, kein Demo, usw. verwendet Kernalroutinen, weil zu langsam. Daher werden (fast) nur Onefiler funktionieren.

Quote from Asklia

Das gleiche gilt ja für Jiffy-DOS: Auch hier wurde der Kernal angepasst und bleibt kompatibel.

Dieser Vergleich hinkt doppelt:

1. Bei JiffyDOS ist der serielle Bus ja trotzdem vorhanden. Ein Demo, Spiel, ..., das selbst einen Schnelllader implementiert, in dem es auf die Busleitungen zugreift funktioniert daher i. A. problemlos.
2. Bei JiffyDOS sind auch noch die normalen Kernal-Routinen vorhanden, wenn das angeschlossene Gerät kein Jiffy hat.

Beides trifft auf ein IEEE-Gerät am Expansionport nicht zu.

Quote from bigby

Tja, das liest wohl jeder anders. Für mich war die ursprüngliche Frage...

— Ein Floppy-Cartrigde ohne Kabel —

Dazu fällt mir auch als erstes das Chameleon an. Andererseits emuliert es derzeit "nur" 1541 ohne Parallelkabel und kann geschwindigkeitsmäßig nicht annähernd mit einem SD2IEC mit JiffyDOS mithalten. Da es mittlerweile fast alle großen Titel auch als EasyFlash gibt, kann aber auch das Chameleon hier Geschwindigkeitsvorteile ausspielen.

Und weil es nicht offensichtlich ist, ob es dem Fragesteller bewusst ist: Das SD2IEC emuliert keine 1541. Es ist ein Massenspeichergerät mit Unterstützung der gängigsten Diskimageformate und Unterstützung für diverse Schnellladeprotokolle, sodaß trotzdem viel Software damit läuft. Software, die darauf angewiesen ist, eigenen Code in der 1541 auszuführen, kann damit nicht funktionieren.

Na, dann haben wir beide aber unterschiedliche Programme in unserer Sammlung. Von einigen neuzeitlichen demos mal abgesehen, funktionieren alle alten Spiele und Programme, von Easyscript, Vizawrite über CP/M bis hin zu Wolfenstein, Beachhead oder Fort Apokalypse prachtvoll auch von einem der grossen Laufwerke. Was es auch war: Damals hatten wir mit den Programmen keinerlei Probleme.

Das ist die gleiche Mär, dass ein 65C02 in der Floppy ja auch nicht gehen würde: Alle meine Laufwerke, gross oder klein, von der 3040/4040, 8250LP, SFD1001, 8280, die klassische 1541 im SX-64 oder 1571 im 128D haben inzwischen einen R65C02 drin, und funktionieren prachtvoll. Da gibt es kaum jemanden, der diese ominösen illegal Ops je verwendet hat. Mit Speedos (8250/SFD), Speeddos (1541) oder Jiffydos (1571/1581).

Aber da gibt es bestimmt eine wichtige Demo (in deiner Sammlung), die würde nicht funktionieren...

Und genau deswegen kann man bei (m)einem IEEE Modul mit zwei Tasten (CTRL und Funktionstaste) zwischen seriell und parallel umschalten.

Gruss (und nichts für ungut)

Quote from Asklia

Aber da gibt es bestimmt eine wichtige Demo (in deiner Sammlung), die würde nicht funktionieren...

Du verstehst das falsch: MIR ist das völlig egal. Ich nehm das SD2IEC, und was da nicht läuft, läuft von der echten 1541.

Aber man sollte so grundlegende Dinge schon vorher anklären und berücksichtigen. Siehe SD2IEC, wie oft kommt da einer vorbei und jammert, dass "XY nicht läuft ..." - und das SD2IEC ist sicher mindestens so kompatibel wie eine IEEE-Expansionportlösung.

Quote from Asklia

Das ist die gleiche Mär, dass ein 65C02 in der Floppy ja auch nicht gehen würde: Alle meine Laufwerke, gross oder klein, von der 3040/4040, 8250LP, SFD1001, 8280, die klassische 1541 im SX-64 oder 1571 im 128D haben inzwischen einen R65C02 drin, und funktionieren prachtvoll. Da gibt es kaum jemanden, der diese ominösen illegal Ops je verwendet hat. Mit Speedos (8250/SFD), Speeddos (1541) oder Jiffydos (1571/1581).

Niemand sagt, dass er nicht läuft. Aber es gibt definitiv Schnelllader, die damit nicht funktionieren, weil sie Illegals verwenden. Mag sein, dass das für viele Leute belanglos ist. Trotzdem sollte man es vorher sagen, bevor die Probleme bei den Leuten auftreten; so wie mit dieser IEEE-Lösung auch.

Das ist doch kein Schlechtreden von diesen Dingen, sondern eine ganz wertvolle Information? Wenn das jemand dann weiß und es trotzdem so haben will, ist doch alles prima? Keine Ahnung, warum man das ins Reich der Märchen reden muss?

Quote from Asklia

Gruss (und nichts für ungut)

Nein, alles gut. Umgekehrt hoffentlich auch.