64Net
cbm642
aber hierbei auf die physischen Grenzen meiner Laufwerke, da einige auf dem
C64 erzeugten Archive zu groß für die Disketten geworden sind und Aufteilen
nicht möglich ist.
Ich dachte daher an die Möglichkeit des 64Net, jedoch funktioniert dieses
nicht mehr so recht, denn es werden egal in welche Richtung man kopiert nur
Dateien von 1 Block angelegt, jedoch keine Dateien kopiert.
Woran kann das liegen?
Gibt es auch neuere Software als die Originalsoftware von 1994? Vielleicht
auch für Systeme wie Wheels/WiNGS?
Michael J. Schülke
> Ich bin dabei, alle meine Daten vom C64 von Disk auf CD zu bringen, stoße
> aber hierbei auf die physischen Grenzen meiner Laufwerke, da einige auf dem
> C64 erzeugten Archive zu groß für die Disketten geworden sind und Aufteilen
> nicht möglich ist.
Star Commander?
Gruß,
Michael
cbm642
archiviert.
Möchte mir ungern die Arbeit des erneuten Imaging der Disketten antun, daher
dachte ich an die Variante des Übertragens per 64Net.
Gruß,
André.
"Michael J. Schülke" <news...@mjschuelke.de> schrieb im Newsbeitrag
news:MPG.1ab9a5667...@News.individual.DE...
Michael J. Schülke
> Habe nahezu alle meine Disketten in Images gebracht und auf meiner CMD HD
> archiviert.
Wäre natürlich ganz praktisch gewesen, wenn Du das erwähnt hättest...
Hast Du mal recherchiert, ob (und wie gut) das Filesystem der CMD HD
dokumentiert ist? Evtl. wäre es das einfachste, die HD selbst an einen
SCSI-Controller am PC zu hängen und mit einem kleinen Programm die
Dateien zu extrahieren.
> Möchte mir ungern die Arbeit des erneuten Imaging der Disketten antun
Verständlich.
> daher
> dachte ich an die Variante des Übertragens per 64Net.
http://www.funet.fi/pub/cbm/crossplatform/transfer/transfer.html
hast Du gelesen?
Gruß,
Michael
cbm642
also mit dem Filesystem der CMD HD habe ich keine Ahnung, die Anleitung zu
dieser ist mir zu komplex und für mich unverständlich, habe also keinerlei
Ahnung damit.
Einen SCSI-Controller habe ich nicht im Besitz, sodaß ich die HD direkt an
den PC anschließen könnte.
Die URL muß ich mir erst zu Gemüte führen, vielleicht findet sich dadurch
eine andere Methode.
Gruß, André.
"Michael J. Schülke" <news...@mjschuelke.de> schrieb im Newsbeitrag
news:MPG.1abc3b2ad...@News.individual.DE...
Michael J. Schülke
> also mit dem Filesystem der CMD HD habe ich keine Ahnung, die Anleitung zu
> dieser ist mir zu komplex und für mich unverständlich, habe also keinerlei
> Ahnung damit.
Hast Du einen Link dazu? Dann kann ich mal reinschauen und abschätzen,
wie kompliziert das werden kann.
> Einen SCSI-Controller habe ich nicht im Besitz, sodaß ich die HD direkt an
> den PC anschließen könnte.
Unter 10 Euro beim Online-Auktionshaus Deines geringsten Mißtrauens.
Auch nicht teurer als ein Adapterkabel, vor allem, wenn Du's nicht
selber lötest.
> Die URL muß ich mir erst zu Gemüte führen, vielleicht findet sich dadurch
> eine andere Methode.
Wenn Du schon dabei bist: http://learn.to/quote
Gruß,
Michael
--
Ich habe meinen Keller aufgeräumt: http://flohmarkt.mjschuelke.de
cbm642
nicht. Leider gibt es CMD als solches auch nicht mehr, hat ein gewisse
Maurice Randall (Wheels-Programmierer) übernommen, scheinbar auch selbst
"übernommen", da es dort zu monatelangen Wartezeiten in jeglicher Hinsicht
gekommen ist.
Gruß,
André.
"Michael J. Schülke" <news...@mjschuelke.de> schrieb im Newsbeitrag
news:MPG.1abda2993...@News.individual.DE...
Michael J. Schülke
> Leider gibt es CMD als solches auch nicht mehr, hat ein gewisse
> Maurice Randall (Wheels-Programmierer) übernommen, scheinbar auch selbst
> "übernommen", da es dort zu monatelangen Wartezeiten in jeglicher Hinsicht
> gekommen ist.
Ich weiß; das ist ja quasi ein Dauerthema in c.s.c.
BBS-News
Ich hatte da mal von einem Prog "64HDD" gehoert.
Es soll ein Emul fuer die CBM-Laufwerke sein.
Diese LW's koennen mittel einem 'X1541' oder 'XE1541' Kabel an den PC
angeschlossen werden.
Ob es auch mit der CMD HD funzt entzieht sich meiner Kenntnis.
Vielleicht weiss hier einer mehr darueber bzw. kennt noch ein bessers Prog.
Auwisch, HaJo
Rainer Buchty
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=64hdd&btnG=Google+Search
|> Es soll ein Emul fuer die CBM-Laufwerke sein.
|> Diese LW's koennen mittel einem 'X1541' oder 'XE1541' Kabel an den PC
|> angeschlossen werden.
|> Ob es auch mit der CMD HD funzt entzieht sich meiner Kenntnis.
64hdd ist eine Laufwerksemulation, d.h. der PC tut so, als wäre er das
entsprechende Laufwerk. Der Inhalt ergibt sich aus der zugewiesenen Datei (D64,
D71, D81, T64 und LNX images werden ebenso unterstützt wie "nackte" Files und
Filearchive).
Eine explizite Möglichkeit, CMD HDs zu transferieren, gibt's laut Website
wohl nicht. Angeblich spielt die Pro-Version jedoch mit einigen CMD Tools.
Falls es *da* ein Dump-Programm gibt, ist eventuell nicht alles verloren.
Ansonsten eben doch zu Fuß mit Einzelfile-Copy.
Rainer
Christian Link
On Sun, 14 Mar 2004 22:14:31 +0000 (UTC),
buc...@atbode100.informatik.tu-muenchen.de (Rainer Buchty) wrote:
>64hdd ist eine Laufwerksemulation, d.h. der PC tut so, als wäre er das
>entsprechende Laufwerk. Der Inhalt ergibt sich aus der zugewiesenen Datei (D64,
...aber doch immer noch nur high-level, oder? Das war der eine Punkt,
der mich vom Kauf abgehalten hat. Der zweite ist...:
>D71, D81, T64 und LNX images werden ebenso unterstützt wie "nackte" Files und
>Filearchive).
...aber leider keine P00s. Ja ja, ich weiß, ich mach' hier schon
wieder dern Montchalin ;-), aber Herrgott, es kann doch echt nicht so
schwer sein, die zu unterstützen. Okay, ich weiß nicht, ob Nick
(diesmal der echte, nicht der vollgeschleimte Welte ;-) ...) das nicht
implementieren würde, wenn man ihn nur mal drauf anspräche, aber dazu
hatte ich gerade wegen des obigen Punktes bislang überhaupt noch keine
Motivation.
Wäre trotzdem toll, wenn das irgendwann mal ein Low-Level-Emulator
würde. SX auf den Tisch, Kabel zum PC, und los. Öh, okay, vielleicht
doch lieber einen 128D mit Abschalter für die interne Floppy... Äh,
SCHEISSE, dann hab' ich wieder keinen Monitor... Ähm, gibt es
irgendwas, was ich *nicht* unnötig verkomplizieren kann ;-) ?
Na ja, ging mir nur gerade durch den Sinn, als ich mal wieder 64HDD
las. Langfristig sehe ich das durchaus als probable Alternative zum
voll aufgebauten 128D-Block...
Gruß,
Chris.
Rainer Buchty
Christian Link <C.LinkS...@GMX.NET> writes:
|> ...aber doch immer noch nur high-level, oder? Das war der eine Punkt,
|> der mich vom Kauf abgehalten hat. Der zweite ist...:
Ich zitierte nur die Webseite... Selbst bin ich kein Anwender von 64hdd.
|> Ja ja, ich weiß, ich mach' hier schon wieder den Montchalin ;-)
Wieso, stürzt VICE auf Deinem Compaq immer ab?
|> Wäre trotzdem toll, wenn das irgendwann mal ein Low-Level-Emulator
|> würde.
Die Idee kam mir so beim Lesen der 64hdd-Seiten.
Wie nehmen die Floppyemulation des VICE, basteln die IEC-via-LPT Routinen
dran -- und fertig ist die ultimative 1541-Emulation, die (entsprechendes
Dumpformat vorausgesetzt) auch mit den meisten Custom-Loadern und üblichen
Kopierschutzmechanismen ticken sollte.
Rainer
Wolfgang Moser
Rainer Buchty wrote:
> Christian Link writes:
> |> ...aber doch immer noch nur high-level, oder? Das war der eine Punkt,
> |> der mich vom Kauf abgehalten hat. Der zweite ist...:
>
> Ich zitierte nur die Webseite... Selbst bin ich kein Anwender von 64hdd.
> [...]
>
> |> Wäre trotzdem toll, wenn das irgendwann mal ein Low-Level-Emulator
> |> würde.
>
> Die Idee kam mir so beim Lesen der 64hdd-Seiten.
>
> Wie nehmen die Floppyemulation des VICE, basteln die IEC-via-LPT Routinen
> dran -- und fertig ist die ultimative 1541-Emulation, die (entsprechendes
> Dumpformat vorausgesetzt) auch mit den meisten Custom-Loadern und üblichen
> Kopierschutzmechanismen ticken sollte.
Das gibt es bereits und nennt sich 1541emu:
http://members.surfeu.fi/1541/
Aber auch dieses Teil kommt nicht generell mit allen Custom-
Loadern zurecht. Das Problem ist nicht alleine, dass bis jetzt
das G64-Format ((noch ?) nicht?) unterstützt wird.
Vielmehr dürfte es noch einige Zeit nicht möglich sein, eine
_echtzeitfähige_ Laufwerksemulation mit genügend geringer
Latenz (Verzögerungszeit) zwischen:
LPT-Port-Signalwechsel (Eingang)
||
||
|+----\ Reaktion in der Emulation,
+-----/ Erzeugung einer Antwortreaktion
||
||
/--+|
LPT-Port-Signalwechsel (Ausgang) \---+
Damit das zeitlich exakt dem Vorbild entspricht, müsste jedem
Signalwechsel quasi eine Timestamp angeheftet werden. Die
Emulation müsste dann ihre intere Taktuhr (Systemclock) auf
diese Timestamp synchronisieren. Wird in der Emulation eine
Antwortreaktion erzeugt, die nach außen weitergeleitet werden
soll, so muss diese Antwortreaktion auch wieder eine Timestamp
verpasst bekommen. So weiß dann der äußere Prozess, wie lange
er warten muss, bevor er diesen Signalwechsel dann in
Wirklichkeit auf den LPT-Port geben darf.
Das alles setzt voraus, dass die Emulation um ein zigfaches
schneller als die reale Hardware ist...
Ich habe mal darüber nachgedacht, ob man nicht gar eine Art
vorausschauende Emulation bauen könnte. Wenn also ein von
außen eingebrachtes Signal durch die Emulation abgefragt wird,
dann könnte man mögliche Wege vorausberechnen (Pseudocode):
Get IEC-Port-Data
Isolate CLOCK (AND)
Loop until CLOCK Low
Wait 100ms
Put ATN Low
Würde diese Stelle für 500ms im Voraus emuliert, dann könnte
man bezüglich der externen Schnittstelle sagen, dass wenn:
CLOCK == HIGH ===> keine Änderung
CLOCK == LOW ===> ATN nach 100 ms auf Low setzen
Im letzten Fall kann man erst einmal nicht viel weiter
vorausberechnen bzw. es macht nicht viel Sinn. Nach kurzer Zeit
dürfte sich ein sehr komplexer Baum zwischen externen
Signaländerungen und darauf folgenden Reaktionen ergeben.
Bedenkt man, dass immer nur ein Weg gewählt wird und die anderen
verworfen werden, so wqürde viel Rechenzeit für die Emulation
der später verworfenen Wege verbrannt.
Das Ziel ist ja bloß, die Latenz herunter zu drücken... und
genau die ist derzeit meiner Vermutung nach noch ein Problem
bei der Unterstützung serieler Fastloader, sowie von IRQ-Loadern
mit feingetuntem, synchronem Timing.
Ohne Pentium-Timestampcounter geht da gar nichts. Und ich
vermute mal, das man gleich auch noch ein eigenes Prozesssystem
schreiben kann (natürlich für DOS), um äußeres Signalhandling
und interne Emulation(en) quasi parallel laufen zu lassen.
Womo
--
------ to obtain more infos about me, look up the page ------
---- http://www.wmsr.de pwnah (at) d81 (dot) de ----
BBS-News
"Rainer Buchty" <buc...@atbode100.informatik.tu-muenchen.de>
schrieb im Newsbeitrag :
> 4hdd ist eine Laufwerksemulation, d.h. der PC tut so, als wäre er das
> entsprechende Laufwerk.
>...
> Eine explizite Möglichkeit, CMD HDs zu transferieren, gibt's laut Website
> wohl nicht. ...
>
> Ansonsten eben doch zu Fuß mit Einzelfile-Copy.
Also ich habe ja nun auch eine Notebook als Slave am C64 haengen.
Beide sind mittels Nullmodem-Kabel verkoppelt, d.h. eine Turbo232 - seriell
zum PC.
Auf'm CeVi laeuft Novaterm und auf'm PC ZOC-Term.
Meine BBS auf'm CeVi verschickt die Mails und Progs ueber den PC ins NET.
Da fiel mir ein, dass ich fuer Nico Malecki mal ein Prog auf Basis von
Novaterm erstellt hatte, womit er von zu Hause aus auf seine weiter entfernt
stehende Wetterstation zugreifen konnte um sich die Daten herunter zu laden.
Ich habe es mal auf dem Notebook mit einem einfachern Terminal versucht. Es
gab keine Probls vom Nootebook aus auf die CMD HD an meinem CeVi zu
zuzugreifen und Files herunterzuladen.
Auwisch, HaJo.