Ich seh das anders. Wenn du eine CMD HDD hast, brüte damit solange rum wie du kannst und willst. Alles gut.
Wenn du keine hast, versuche erst gar nicht eine zu bekommen....
Hallo Besucher, der Thread wurde 16k mal aufgerufen und enthält 170 Antworten
letzter Beitrag von Unseen am
CMD HDD: Welches Netzteil?
- DerSchatten
- Erledigt
-
-
Native Partitionen braucht auch kein Mensch aufn C64.
Stimmt. Wer so wenig mit der Kiste macht wie Du, braucht das auch nicht. Ansonsten ist das Features für Geos und Anwendung brauchbar, die viel Platz benötigen.
Theoretisch könntest Du da sogar d64 Images drauf parken
SuperCPU ist ja auch ein Super Teil aber nur wegen ein Spiel ?
Ein Spiel was direkt dafür entwickelt wurde aber ein kleiner Sack an Software, was dafür gepatcht wurde. Aber stimmt schon, das Ding ist viel zu teuer
und sonderlich kompatibel auch nicht. Da würd ich eher zum gelben Engel greifen. -
Hallo, so ein Quatsch habe ich lange nicht gelesen. Mag ja sein, dass die CMD-HD in die Jahre gekommen ist und die SD auf einem neueren Stand der Technik ist. Aber ich benutze die HD samt RL und SCPU seit Jahren und wüsste nicht wo das Teil schon mal hängen geblieben ist.
Gruß Pusti64 -
Weis nicht. Die 3 D81 Images hier reichen estmal für jeden GEOS Quatsch.
98% aller User hier wollen eh nur zocken. -
Darum ja jeder so wie er es braucht und will.
-
EDIT: Und hatte Skern nicht letztens eine Liste mit Inkompatibilitäten des SD2IEC zu "echten" Laufwerken angefertigt?
wo denn? die würde nicht nur unseen interessieren ... -
Zitat
Eine 1541 Partition verhält sich also nicht gleich wie eine echte 1541 ?
nur auf DOS ebene, so bald code im laufwerk ins spiel kommt wird es nicht klappen. ziemlich exakt genau so wie bei sd2iec o.ä. also -
Eine 1541 Partition verhält sich also nicht gleich wie eine echte 1541 ?
Nein, sie hat nur das gleiche Track/Sektor-Layout, ist in dieser Hinsicht (Position der Directory etc.) also "kompatibler" als z.B. eine 1581. Ein Fastloader braucht aber auch die Hardware der 1541 drumherum. Die 1541U und das TC64 emulieren diese Hardware; das SD2IEC nicht. Eine CMD HD liegt dazwischen, da sie zumindest 6502-basiert ist. Für den durchschnittlichen Fastloader reicht das aber nicht.
-
wo denn? die würde nicht nur unseen interessieren ...Hier - ok, "Liste" war zuviel gesagt.Aber die beiden Probleme (Lesen des T/S-Links über den B-P-Befehl und Auffüllen des Dateinamens mit Shift-Spaces) sind tatsächliche Inkompatibilitäten. Ob die - abgesehen von skern - jemals jemand bemerkt hätte, steht auf einem anderen Blatt.
-
ah der fiese buffer trick... ich erinnere mich
zumindest das leidige virtualfs im vice kann das mitlerweile 
-
Was zum Teufel nutzt denn sowas aus?
-
kA. irgendwer postete hier mal diesen coca-cola-code-generator mumpitz (lustige aufgabe btw: sucht mal den thread hier, oder einen hinweis darauf das selbiger existierte) und weinte bitterlich das jener ohne true-drive emulation im VICE nicht ging. das war bisher das erste und auch einzige programm das mir untergekommen ist
vmtl noch unwichtiger als REL files -
kA. irgendwer postete hier mal diesen coca-cola-code-generator mumpitz (lustige aufgabe btw: sucht mal den thread hier, oder einen hinweis darauf das selbiger existierte) und weinte bitterlich das jener ohne true-drive emulation im VICE nicht ging. das war bisher das erste und auch einzige programm das mir untergekommen ist
vmtl noch unwichtiger als REL files
Das hatte IIRC einen sehr dreckigen Trick verwendet: Irgendwas (Datei oder Directory) wurde geöffnet, wodurch das Laufwerk den ersten Sektor in seinen Speicher geladen hat. Dann wurde die Datei wieder geschlossen und ein Direktzugriffspuffer geöffnet, welcher zufälligerweise (nur "#", nicht "#<zahl>") den gleichen Pufferspeicher im Laufwerk verwendet hat um die Daten auszulesen. Mit dem VICE vdrive geht das nicht, weil das die Puffer ordentlicherweise mit calloc anfordert. Ich meine bei sd2iec hätte es zufälligerweise, aber definitiv nicht per Design funktioniert. -
-
war das nicht das ?
Ja, das sieht verdächtig ähnlich aus. -
-
Yup. Das funktioniert auf JEDER echten CBM/CMD Hardware (kann also kein Zufall sein). Das ist halt erforderlich um die Position des Directorys zu ermitteln, da man ja nicht wissen kann (z.B. in einem Unterverzeichnis einer Native-Partition) wo das DIR sonst zu finden ist. Sollte daher in jeder guten Emulation auch funktionieren.
-
(kann also kein Zufall sein)
das wiederum wage ich zu bezweifeln. das verhalten ansich wurde ganz sicher mehr oder weniger willkürlich im laufe der entwicklung des DOS so festgelegt und dann beibehalten. und CMD hat sich dann aus kompatibilitätsgründen am original DOS orientiert.edit:
ZitatDas ist halt erforderlich um die Position des Directorys zu ermitteln, da man ja nicht wissen kann (z.B. in einem Unterverzeichnis einer Native-Partition) wo das DIR sonst zu finden ist
ich bin mir sicher das wenn irgendetwas zu diesem zweck mit absicht im DOS eingebaut wäre, dieses mit einem deutlich weniger dreckigen hack erreichbar wäre (DOS Kommando o.Ä. wäre ein leichtes gewesen) -
Das funktioniert auf JEDER echten CBM/CMD Hardware (kann also kein Zufall sein)
Doch, das kann durchaus ein Zufall sein. Nur weil eine bestimmte Implementierung die naheliegende Methode ist um ein Problem auf einigen Systemen mit recht ähnlicher Hardware zu lösen heisst das noch lange nicht, dass auch alle Seiteneffekte dieser Implementierung geplante Features sind. Das sieht man gerade beim VICE-VDrive sehr gut: Da VICE auf Systemen mit ganz anderen Speicherverwaltungsmodellen läuft war die naheliegendste Lösung zur Pufferallokation bei "'#" eine deutlich andere(*) als in den Commodore-/CMD-Laufwerken, die mit einer kleinen Anzahl von vordefinierten Puffern in ihrem stark begrenzten RAM auskommen müssen.(*) VICE hat vor dem von sauhund verlinkten Patch für "'#" einfach frische 256 Byte RAM vom Betriebssystem angefordert, die mit 0 initialisiert waren weil das dort nur ein einzelner Funktionsaufruf ist. Nach dem Patch ist die Pufferverwaltung in VICE ein deutliches Stück komplizierter geworden, um die Seiteneffekte der Commodore-Implementierung nachzubilden.
ZitatDas ist halt erforderlich um die Position des Directorys zu ermitteln, da man ja nicht wissen kann (z.B. in einem Unterverzeichnis einer Native-Partition) wo das DIR sonst zu finden ist. Sollte daher in jeder guten Emulation auch funktionieren.
Und wie soll das funktionieren, wenn es diese Position nicht gibt, weil auf dem Medium gar kein Directory im Commodore-Format existiert und das Medium auch nicht im Track/Sektor-Modell der Commodore-Disks organisiert ist? Ausserdem: Wo soll der Vorteil sein, das Directory mit Sektorbefehlen zu lesen statt über "$" (ggfs. mit einer Sekundäradresse ungleich 0) wenn es nur um Lesezugriffe geht?
