Hallo Besucher, der Thread wurde 74k mal aufgerufen und enthält 320 Antworten

letzter Beitrag von mr.vince am

alte Disks lesen: KryoFlux Public Beta veröffentlicht

  • Muss ja auch nicht GPL sein (oder dazu kompatibel), muss nur die 10 Punkte erfüllen um der Definition einer Open-Source-Lizenz zu entsprechen.


    open source heißt vor allen dingen das, was es heißt... ein offener quelltext. es gibt keinen grund, sich von der osi vorschreiben zu lassen, ob man kommerzielle ausbeutung erlaubt oder nicht. es wird ja keiner gezwungen, kryoflux zu benutzen. wir offerieren es allen privaten anwendern für eine ebensolche nutzung. wenn beispielsweise eine firma aus dem gebiet der datenrettung kommt, dann ist es nicht verwerflich, wenn sie dafür bezahlen. damit können wir beispielsweise ein noch besseres arm dev kit kaufen. die richtig guten tools sind leider auch richtig teuer und - du ahnst es - wir bekommen sie nicht umsonst, noch nicht einmal, wenn wir unser produkt komplett per gpl freigeben würden. es wird sich von uns sicher niemand ein schickes auto davon kaufen. wir könnten uns aber durchaus vorstellen, davon so manchen titel zu kaufen, der bisher nicht archiviert werden konnte, weil die ebay preise so hoch gehen...


    Zitat


    Ich vermute, dass es genau wegen dieser Closed-Source-Library keinen IPF-Support für VICE geben wird. Der Emulator läuft immerhin auf ziemlich vielen Architekturen und Betriebssystemen, die zwar technisch in der Lage wären das Format zu verwenden, für die es aber die Library nicht in Binärform gibt.


    das ist ja kein hinderungsgrund. winuae z.b. untersützt ipf auch, und es funktioniert vortrefflich. für das compilieren brauchst du ja nur die header, nicht das binary. aber da auch vice wiederum open source ist, ist das ja kein thema, diese anbindung bei bedarf selbst vorzunehmen und hinterher als option anzubieten. wir unterstützen mit win, mac und linux auch gleich die wichtigsten plattformen. wenn dir was fehlt, gerne melden, dann schauen wir, ob wir das bereitstellen können.


    Zitat

    Du machst also das Format für die Fehler in der Laufwerksemulation verantwortlich? Ich weiss nichts über die Interna von CCS64, aber die Laufwerksemulation von VICE bräuchte mal eine starke Überarbeitung um näher an der Realität zu sein. Da sich manche der Emulationsprobleme durch Änderungen an der G64-Datei austricksen lassen (zB die Ausrichtung zwischen den Tracks) wird das eben von einigen Leuten gemacht, denen Funktion wichtiger ist als Genauigkeit.


    anscheinend definiert jeder für sich das format anders / neu, was natürlich käse ist. ich will ja auch nicht an meiner .doc datei was fummeln, wenn ich damit an einen anderen rechner gehe.


    daher spricht doch genau das dafür, ein format zu nehmen, das ordentlich implementiert wurde, eben indem die anbindung gleich mitgeliefert wird. mal davon abgesehen, dass das originaltiming der daten komplett verloren geht, und es also keine möglichkeit gibt, sonderfälle zu behandeln oder gar zu erkennen, ob die daten modifiziert wurden.


    Zitat


    Bis mal jemand keine Lust auf verlorene Highscores mehr hat, das Format reverse-engineert und Schreibsupport dafür baut?


    hm. schon wieder ein pseudo-problem. es gibt doch schreib-support für ipfs. nur werden alle änderungen gegenüber der virtuellen originaldiskette als delta file zusätzlich abgelegt. d.h. du kannst alle änderungen rückgängig machen, wenn du diese zusätzliche datei löschst. du kannst sie aber auch auf deine webpage packen und andere können sie zu ihrem originalimage dazu laden und deine highscore sehen.


    ist nicht so, dass sich dazu nicht schon der kopf gemacht worden wäre.


    noch einmal abschließend: nur weil wir ein projekt nicht zur kommerziellen ausbeutung freigeben, muss das ja nicht gegen die community sein. andere lösungen sind komplett closed source. und ich habe selber genug programme, die z.b. shareware sind, die ich aber einfach genial finde, z.b. total commander. und ccs64 hat auch was für sich, obgleich es dazu keinen source gibt. da wundert es mich, dass nun einschränkungen, die darauf abzielen, dass jemand anderes das zu geld macht, zum problem werden sollen. immerhin versuchen wir eine gesunde balance zu finden, damit jeder sich einbringen und sein lieblingsformat umsetzen kann. nur, wie schon weiter oben geschrieben, muss dieses format ja nicht zwangsläufig von uns umgesetzt werden.


    viele grüße
    christian

  • Ist das sowas wie der CatWeasel - nur besser?



    Supergenial, dann kann ich mir die Arbeit am Xs-1541 sparen wenn da eine bessere Lösung kommt. Mal sehen wie gut das dann läuft mit 1541 und 1571 Disketten. Werden 8250 Disketten auch gehen?


    meine meinung ist natürlich vorbelastet. ich sag es mal so: wir haben kryoflux entwickelt, weil keine andere lösung am markt unseren ansprüchen für lesen und schreiben gerecht wurde. wir hätten sehr gerne eine fertige hardware benutzt.


    8250 support ist hardwaretechnisch schon drin, also das lesen der eigentlichen daten von der oberfläche. ich bin mir aber nicht ganz sicher, ob die daten mit den bisherigen export-filtern für gcr decodiert werden können (nachdem was ich im kopf habe... nein...). wäre schön, wenn uns entweder mal jemand eine frisch formatierte disk schickt, oder mit einem kryoflux ein streamfile schreibt, das wir analysieren können.


    grüße
    christian

  • Zitat von Diddl

    Werden 8250 Disketten auch gehen?


    Wird wohl genauso wie beim Catweasel ein zur Disk passendes Laufwerk brauchen.


    wenn dir was fehlt, gerne melden, dann schauen wir, ob wir das bereitstellen können.


    Fang mit dieser Liste an:

    • Binary for MS-DOS (Pentium-optimized): vice22.zip
    • Binary for MS-Windows 64bit (amd64/x64): WinVICE-2.2-x64.zip
    • Binary for MS-Windows 64bit (ia64): WinVICE-2.2-ia64.zip
    • Binary for Acorn RISC OS systems: vice-riscos2_2.zip
    • Binary for BeOS systems: Please visit the BeOS download page.
    • Binary for QNX systems: Please visit the QNX download page.
    • Binary for OS/2 systems: vice2-2.2.zip.
    • Binary for Solaris / SunOS systems: Please visit the Solaris / SunOS download page.
    • Binary for SCO based systems: Please visit the SCO download page.
    • Binary for Amiga based or derived systems: Please visit the Amiga download page.
    • Binary for Mac OS X systems: Please visit the Mac OS X download page.
    • Binary for GP2X systems: vice-gp2x-2.2.zip
    • Binary for Dingoo systems: SDLVICE-dingoo-2.2.zip
    • Binary for SkyOS systems: VICE-2.2.pkg
    • Binary for Syllable systems: SDLVICE-syllable-2.2.tgz
    • Binary for Minix 3.x systems: vice-minix-2.2.tar.bz2
    • Binary for Atari Mint systems: vice-2.2-1.m68kmint.rpm


    Zitat

    anscheinend definiert jeder für sich das format anders / neu, was natürlich käse ist. ich will ja auch nicht an meiner .doc datei was fummeln, wenn ich damit an einen anderen rechner gehe.


    Gut, nochmal in kleinen, leicht verständlichen Worten: Die Nachbildung der Floppy in VICE ist schlecht. Darum geht eine an sich "gute" G64-Datei nicht immer. Mit einem IPF-VICE wäre das nicht anders. Der Aufbau von G64 ist an dieser Stelle nicht das Problem.

  • ja, nur da bitte ich zu bedenken, dass die software nicht mit der intention des ausschlachtens open source ist (open source ist übrigens nicht automatisch gpl). vielmehr geht es darum, dieses produkt zu verbessern und hoffentlich einen standard zu schaffen, mit dem jeder sehr preiswert seine disks lesen kann. es wäre schön, wenn das berücksichtigt wird.


    du wirst lachen, aber so wie es dir egal sein kann das ich gerne g64 files am ende hätte ist es mir egal welche intention hinter irgendeiner software steckt die nicht das tut was ich will :)


    naja, entweder oder. wenn mir jemand sagt, er kennt sich damit aus, dann ist es wirklich ein leichtes, das zu tun. schau dir mal das hxc projekt an... während andere ständig meckern (damit meine ich nicht dich), dass es closed source ist, hat jean francois einfach mal vorwärts gemacht und seinem projekt die möglichkeit gegeben, ipfs über die lib zu lesen, und füttert das in seinen floppy emulator. es geht also durchaus, und jean francois hat nicht einmal nachfragen müssen, was wohl eher für die qualität der schnittstelle spricht.


    an der stelle frage ich mich ein wenig wie sehr du dich denn damit auskennst. wenn ich einen floppy emu mache (oder ipf im emu lesen will) - DANN gibt einem die ipf library genau die daten die man will (nämlich die die die floppy lesen würde). wenn ich aber die disk mastern, oder auch nur in ein andres format überführen, möchte dann will ich wissen was auf der disk drauf ist, nicht was irgendein controller daraus macht. sprich, es gibt an der stelle keinen unterschied ob die daten aus einem ipf oder direkt vom medium kommen, der analyseaufwand bleibt gleich. und das ist schlicht totaler quark, denn die infos die man will stehen ja schon im ipf drinne, mann kann sie nur aus gott weiss was für bös geheimen gründen nicht lesen.


    du lässt im obigen beispiel außer acht, dass die genannten sammlungen meist keine defekten images aufnehmen oder eben kennzeichnen.


    nein. da das der einzige weg ist sicherzustellen das images in ordnung sind - wie sollte es anders sein?


    Zitat

    du lässt ebenfalls außer acht, dass es sich im gros der titel eben um cracks handelt, die möglicherweise erheblich modifiziert wurden.


    nein, um cracks ging es doch garnicht. dafür benutzt auch niemand g64, wozu auch?


    Zitat

    schaut man sich hingegen g64 von kopiergeschützten originalen an, dann tauchen meist früher oder später probleme auf. images müssen nach dem einlesen gepatcht werden usw..


    was bei g64 fast immer den grund hat das die laufwerksemulation im emu schlicht nicht so prall ist



    Zitat

    bei "paranoia complex" (das gehörig mit megalangen sync-markierungen und sehr exakter zählung trickst) geht das dann soweit, dass ich vom selben spiel drei g64 habe. ein g64 für vice, eines für ccs64 und eines, das ich mit nibtools wieder auf disk schreiben kann, um es am c64 zu spielen. dabei funktioniert letzteres nur mit einem bestimmten laufwerk (in punkto geschwindigkeit) und muss erneut angepasst werden, wenn ich ein anderes lw nehme. das ist nicht nur ätzend, sondern zeigt eben leider auch die limitationen des formats auf.


    nein, tut es genau garnicht. es zeigt die unzulänglichkeiten der floppy emulationen und die probleme beim mastern von komischen formaten auf einer 15x1 auf. das g64 format hat da so gut wie keine schuld, und ein neues format wird nicht auf magische weise die laufwerksemulationen verbessern :) und das mit dem mastern geht nur auf bestimmten laufwerken.... ja, das passiert dir allerdings genauso wenn du die originalen mastering tools (für zb vmax) benutzt. das ist viel mehr (bzw einzig =P) ein problem der cbm laufwerke und ihrer ungenauigkeit. und speziell die tatsache das man oftmals (wie auch bei vmax) die laufwerksgeschwindigkeit runterdrehen muss um mehr bitzellen auf den track zu kriegen als eigentlich draufpassen hat null mit dem g64 format zu tun, sondern schlicht damit das die 15x1 laufwerke nunmal mit einer festen bitrate schreiben.


    Zitat

    im übrigen habe ich auch schon g64 gefunden, die zwar funktioniert haben, aber modifiziert waren (beispielsweise highscore). am g64 kann niemand mehr erkennen, ob die daten authentisch sind. beim ipf ist das kein thema.


    ipf kann man grundsätzlich nicht verändern weil da ein paar crc32 drinne sind? oder wie jetzt? ich verstehe das problem nicht ansatzweise :)


    uns liegen eben alle erzeugten images vor. es gibt konstante gespräche mit archiven und museen, und wir arbeite daran, dass die sammlung auch an einigen offiziellen stellen aufbewahrt wird. damit dürften die archivierten titel dann für (hoffentlich) die nächsten dekaden sicher aufbewahrt sein.


    nicht zugänglich, in einem undokumentierten format.... für mich sieht archivrierung anders aus, aber bitte, kann ja auch jeder machen was er will =P


    Du machst also das Format für die Fehler in der Laufwerksemulation verantwortlich? Ich weiss nichts über die Interna von CCS64, aber die Laufwerksemulation von VICE bräuchte mal eine starke Überarbeitung um näher an der Realität zu sein. Da sich manche der Emulationsprobleme durch Änderungen an der G64-Datei austricksen lassen (zB die Ausrichtung zwischen den Tracks) wird das eben von einigen Leuten gemacht, denen Funktion wichtiger ist als Genauigkeit.


    yep, genau so :) die von ccs64 ist ein wenig besser, aber auch alles andere als perfekt. die in hoxs64 ist schon ziemlich gut, aber auch die stolpert noch über das ein oder andre.


    Echt? Und wie adaptiere dann "relativ easy" die zusätzlichen Signale für hard-sektorierte Disketten?


    wenn du eh mit einem controller wie dem hier, oder dem catweasel, liesst reicht es prinzipiell das (die) indexloch abfragen zu können, alles andere machst du dann einfach in software. ich glaube auf tim manns trs80 webseite gibts links dazu. auf der catweasel mailingliste auf yahoo hat vor einer weile auch mal jemand infos (und ich glaube auch code) gepostet, evtl mal im archiv rumsuchen.


    anscheinend definiert jeder für sich das format anders / neu, was natürlich käse ist. ich will ja auch nicht an meiner .doc datei was fummeln, wenn ich damit an einen anderen rechner gehe. daher spricht doch genau das dafür, ein format zu nehmen, das ordentlich implementiert wurde, eben indem die anbindung gleich mitgeliefert wird.


    äh was? das format ist ziemlich eindeutig definiert. nur ist es eben so das die unterschiedlichen implementationen in den emus unterschiedlich gut sind. das hat mit g64 eher nichts zu tun.


    8250 support ist hardwaretechnisch schon drin, also das lesen der eigentlichen daten von der oberfläche. ich bin mir aber nicht ganz sicher, ob die daten mit den bisherigen export-filtern für gcr decodiert werden können (nachdem was ich im kopf habe... nein...). wäre schön, wenn uns entweder mal jemand eine frisch formatierte disk schickt, oder mit einem kryoflux ein streamfile schreibt, das wir analysieren können.


    es ist genau andersrum :o) 8250 laufwerke haben 100tpi (ja wirklich, nicht 96) - da liesst du mit nem normalen laufwerk nicht viel runter (so ca 1/3 der daten geht), sondern brauchst eins mit eben 100 tpi (quasi unmöglich zu finden). wenn du die daten aber einmal hast kannst du sie genau wie die von andren cbm laufwerken dekodieren, einzig die geometrie ist ein bischen anders.


    Fang mit dieser Liste an:


    powerpc linux auch bitte, ich wills auch benutzen dann =P


  • Fang mit dieser Liste an:

    • Binary for MS-DOS (Pentium-optimized): vice22.zip
    • Binary for MS-Windows 64bit (amd64/x64): WinVICE-2.2-x64.zip
    • Binary for MS-Windows 64bit (ia64): WinVICE-2.2-ia64.zip
    • Binary for Acorn RISC OS systems: vice-riscos2_2.zip
    • Binary for BeOS systems: Please visit the BeOS download page.
    • Binary for QNX systems: Please visit the QNX download page.
    • Binary for OS/2 systems: vice2-2.2.zip.
    • Binary for Solaris / SunOS systems: Please visit the Solaris / SunOS download page.
    • Binary for SCO based systems: Please visit the SCO download page.
    • Binary for Amiga based or derived systems: Please visit the Amiga download page.
    • Binary for Mac OS X systems: Please visit the Mac OS X download page.
    • Binary for GP2X systems: vice-gp2x-2.2.zip
    • Binary for Dingoo systems: SDLVICE-dingoo-2.2.zip
    • Binary for SkyOS systems: VICE-2.2.pkg
    • Binary for Syllable systems: SDLVICE-syllable-2.2.tgz
    • Binary for Minix 3.x systems: vice-minix-2.2.tar.bz2
    • Binary for Atari Mint systems: vice-2.2-1.m68kmint.rpm


    du willst mir sagen, dass du jetzt konkreten bedarf an allen versionen hast? nicht wirklich... :) ich denke, dass wir mit win, mac & linux 99% der anwender abdecken. ist aber kein problem, wenn sich da vorerst kein "offizieller" entwickler ranwagen möchte. wir können das auch selbst implementieren, und dann liegt es im ermessen der community, das in die offizielle codebase zu übernehmen oder als patch einzuspielen. letztlich wird ja auch niemand gezwungen, ipfs zu benutzen. dennoch gibt es viele anwender, die gerne ein ipf benutzen.


    Zitat

    Gut, nochmal in kleinen, leicht verständlichen Worten: Die Nachbildung der Floppy in VICE ist schlecht. Darum geht eine an sich "gute" G64-Datei nicht immer. Mit einem IPF-VICE wäre das nicht anders. Der Aufbau von G64 ist an dieser Stelle nicht das Problem.


    die probleme treten nicht nur mit vice auf, sondern auch mit ccs64 und selbst beim zurückschreiben per nibtools musst du wieder tricksen. das sind natürlich probleme der jeweiligen systeme, aber g64 hängt halt mit dran...


    lass uns fakten festhalten: g64 ist nicht in der lage, alle zustände einer disk für den c64 zu repräsentieren. einen referenzpunkt für daten gibt es nicht, thema index. stattdessen wird das von hand in relation zum trackstart im g64 geschoben um "wide tracks" (also synchron geschriebene tracks) zu erzeugen. es gibt außerdem keine möglichkeit, das originale bitzellen-timing (also die exakte dauer einer bitzelle) zu erhalten. damit ist es fast unmöglich, aussagen über eine mögliche veränderung der daten oder gar masteringumstände des datenträgers zu treffen.


    von daher wird es von uns keinen support für g64 geben, schon alleine nicht, weil das evtl. signalisieren könnte es wäre sinnvoll nach g64 zu dumpen. du kannst aber gerne support für g64 einbauen, daran wird dich niemand hindern, im gegenteil. wir selbst haben aber vor, es gleich ordentlich zu machen. das wäre dann eben ipf...


    grüße
    christian


  • du wirst lachen, aber so wie es dir egal sein kann das ich gerne g64 files am ende hätte ist es mir egal welche intention hinter irgendeiner software steckt die nicht das tut was ich will :)


    du verstehst, dass sowas als aussage nicht gerade motiviert, oder?


    Zitat

    sprich, es gibt an der stelle keinen unterschied ob die daten aus einem ipf oder direkt vom medium kommen, der analyseaufwand bleibt gleich. und das ist schlicht totaler quark, denn die infos die man will stehen ja schon im ipf drinne, mann kann sie nur aus gott weiss was für bös geheimen gründen nicht lesen.


    das hat ja nix mit bös geheim zu tun. es ist nur nicht open source. faktisch ist die disk für die ewigkeit konserviert. ok, wenn eines tages keine windows version mehr aufzutreiben wäre, hättest du vielleicht ein problem. aber bis dahin kannst du doch jederzeit deinen eigenen analyser schreiben. die disk verrottet ja nicht mehr, sie ist bereits für die ewigkeit erfasst. aber wir können das jetzt tagelang drumrum reden. momentan haben wir auch gar keine zeit, das format zu dokumentieren.


    Zitat

    ipf kann man grundsätzlich nicht verändern weil da ein paar crc32 drinne sind? oder wie jetzt? ich verstehe das problem nicht ansatzweise :)


    ne, wir können anhand der raw dumps erkennen, mit welchem gerät eine disk geschrieben wurde. wir können z.b. auf einer disk sehen, welche tracks am normalen heimcompi geschrieben wurden und welche mit mastering-maschinen. damit lassen sich nachträgliche modifikationen erkennen. du weißt also, ob eine disk authentisch ist, oder nicht. und natürlich enthalten ipfs verschiedene schichten an prüfsummen, damit sichergestellt werden kann, dass z.b. bei einer übertragung nichts beschädigt wurde.


    Zitat


    nicht zugänglich, in einem undokumentierten format.... für mich sieht archivrierung anders aus, aber bitte, kann ja auch jeder machen was er will =P


    nicht open source heißt nicht, dass das archiv im fall der fälle nicht den source zur library vorliegen hat.


    Zitat


    äh was? das format ist ziemlich eindeutig definiert. nur ist es eben so das die unterschiedlichen implementationen in den emus unterschiedlich gut sind. das hat mit g64 eher nichts zu tun.


    ja, nur sehr doof dass ich bei g64 files die ich bekomme, immer raten muss auf welchem emu das nun läuft und wo ich was ändern muss. dass ist dann schon ein problem. ich will ja bei einem archivierten file nicht jedes mal raten müssen, was ich tun muss, damit es läuft. das ist ja eben genau nicht der sinn von archivierung.


    Zitat

    es ist genau andersrum :o) 8250 laufwerke haben 100tpi (ja wirklich, nicht 96) - da liesst du mit nem normalen laufwerk nicht viel runter (so ca 1/3 der daten geht), sondern brauchst eins mit eben 100 tpi (quasi unmöglich zu finden). wenn du die daten aber einmal hast kannst du sie genau wie die von andren cbm laufwerken dekodieren, einzig die geometrie ist ein bischen anders.


    ups. übersehen. die dinger sind alles andere als alltäglich. also es sollte natürlich mit einem laufwerk gehen, das 100tpi hat - falls jemand so eines auftreiben kann. ich habe keine ahnung, ob das was wird, wenn wir am stepping eines anderen laufwerks rumfurwerken. großes kunst wird das nicht. :) ich würds trotzdem gerne mal ansehen... wenn jemand eine solche disk bereitstellen kann...


    Zitat


    powerpc linux auch bitte, ich wills auch benutzen dann =P


    ok, das klingt konkret. ich schreibs mal auf die liste. wobei ppc linux auch nicht gerade an popularität gewinnt. ;)


    grüße
    christian

  • du verstehst, dass sowas als aussage nicht gerade motiviert, oder?


    was für eine aussage? das ich mir ein opensourceprogram gerne mal so zurechtfrickel das das das macht was ich will, unabhängig davon ob das irgendwem gefällt oder das so gedacht war?


    also wenn DAS ein problem darstellt, dann solltet ihr auf opensource doch lieber verzichten - das ist doch die grundidee das dann da jeder reinfummeln kann was er braucht, oder nicht? :)


    momentan haben wir auch gar keine zeit, das format zu dokumentieren.


    sorry, aber das kann ich nur unter "blabla" einordnen. dafür wäre seit 2001 nun wirklich mehr als genug zeit gewesen, das ist schlicht nicht gewollt (warum auch immer)


    ne, wir können anhand der raw dumps erkennen, mit welchem gerät eine disk geschrieben wurde. wir können z.b. auf einer disk sehen, welche tracks am normalen heimcompi geschrieben wurden und welche mit mastering-maschinen. damit lassen sich nachträgliche modifikationen erkennen. du weißt also, ob eine disk authentisch ist, oder nicht.


    dir ist aber schon klar das eine nicht unbeträchtliche anzahl c64 originale auf "dem heimcompi" gemastert wurden, weil zb die duplizierer so wirres zeug garnicht duplizieren konnten?


    nicht open source heißt nicht, dass das archiv im fall der fälle nicht den source zur library vorliegen hat.


    was aber nichts daran ändert das ein sinnvolles archivformat nicht nur offen, sondern auch dokumentiert ist. wissen zentral zu konzentrieren und sich von einer einzelnen stelle abhängig zu machen ist grade bei langzeitarchivrierung genau das was man eben nicht will.


    ja, nur sehr doof dass ich bei g64 files die ich bekomme, immer raten muss auf welchem emu das nun läuft und wo ich was ändern muss. dass ist dann schon ein problem. ich will ja bei einem archivierten file nicht jedes mal raten müssen, was ich tun muss, damit es läuft. das ist ja eben genau nicht der sinn von archivierung.


    das ist aber wie gesagt ein problem der emulatoren, nicht des formats. daran wird ein ipf exakt null ändern. (ausser das die dann mangels unterstützung in keinem emu gehen vielleicht =P)


    ok, das klingt konkret. ich schreibs mal auf die liste. wobei ppc linux auch nicht gerade an popularität gewinnt.


    ja stimmt, mein nächster laptop wird auch ARM basiert. schreib das gleich mal mit auf die liste :)

  • verschiedene laufwerke, die verschieden justiert und verschieden schnell sind, lassen sich natürlich bei entsprechend feinem sampling der rohdaten voneinander unterscheiden. ob man all diese nützlichen infos, und eventuell sogar hinweise auf professionelles vervielfältigungs-equipment, verwerfen muss, um sich einem format zu beugen?


    wenn ich die aussage treffe, dass wir keine zeit hatten etwas zu tun, dann stimmt diese aussage, weil wir dinge in unserer freizeit tun und diese frei gestalten. wenn sich niemand berufen gefühlt hat (was man gerne als nicht wollen interpretieren kann, oder den mangel an lust), sich seit 2001 hinzusetzen und hunderte seiten dokumentation zu schreiben, dann ist dem eben so. ob das deshalb blabla ist... ich lasse die anderen sachen daher mal soweit unkommentiert stehen.


    beste grüße
    christian

  • Naja, ich habe mehr als einmal versucht, genau die Funktionen in den Catweasel einzubauen. Gescheitert ist es an der Mär, dass der Catweasel nicht ausreichende Daten liefern würde. Tatsächlich ist die Auflösung des Catweasel größer als die Auflösung des magnetischen Mediums, aber das Gerücht wird trotzdem weiter von den CAPS-Nasen verbreitet. Ich habe eMails, in denen zwar zugegeben wird, dass die Aussage falsch war, aber es wurde öffentlich nie richtig gestellt.


    Warum? Das entzieht sich meiner Kenntnis. Eine Zusammenarbeit habe ich über die Jahre mehrfach versucht, aber sie ist an einer zweifelhaften Politik gescheitert, die jetzt mit dem "open-source"-label zurechtgeschönt wird. Mal sehen wie "open" die Sache wirklich ist.


    Jens

  • Kann mir CatWeasel wirkliche RAW Daten zur Verfügung stellen?


    RAW Daten aus denen man per Software die GCR kodierten Bits extrahieren kann? Für 1541 und 8250 format?


    Liegt es nur an der Software diese RAW Daten richtig zu "interpretieren"?



    Wenn das so ist kaufe ich ein CatWeasel und bastle mir das! Ich weiss haargenau wie die GCR Daten zu interpretieren sind, wenn ich sie in einem File vorliegen habe.

  • Zitat

    verschiedene laufwerke, die verschieden justiert und verschieden schnell sind, lassen sich natürlich bei entsprechend feinem sampling der rohdaten voneinander unterscheiden. ob man all diese nützlichen infos, und eventuell sogar hinweise auf professionelles vervielfältigungs-equipment, verwerfen muss, um sich einem format zu beugen?


    was du da beschreibst ist forensik. dazu nimmt man *grundsätzlich* und *einzig* die rohdaten. schon eine überführung in ein anderes format, welche irgendeine art von interpretation beinhaltet, hat das ergebnis das die daten unbrauchbar und - wie sagst du so schön - nicht mehr "authentisch" sind. wenn du es also "richtig" machen willst werden für den zweck die rohdaten konserviert.


    für sonstige benutzung wiederum sind derartige daten zu 100% prozent überflüssig :)


    Zitat

    sich seit 2001 hinzusetzen und hunderte seiten dokumentation zu schreiben,


    du meinst ich soll mein vertrauen in ein archivformat legen welches nicht nur nicht offen ist, sondern für das nichtmal eine dokumentation *existiert* ? lol? da kann ich ja gleich meine mp3 sammlung nach wma umkodieren.... o_O


    Zitat

    Mal sehen wie "open" die Sache wirklich ist.


    der teil der ipf schreiben soll wird da wirklich interessant, da bleibt ja quasi nur die wahl das format zu öffnen (encoding in der client software) oder den ganzen encoder mit in die ipf library zu stopfen (was mir recht wäre, dann könnte ich auch die daten rauslesen die ich für meine zwecke brauche).

  • Zitat

    Kann mir CatWeasel wirkliche RAW Daten zur Verfügung stellen?
    RAW Daten aus denen man per Software die GCR kodierten Bits extrahieren kann? Für 1541 und 8250 format?
    Liegt es nur an der Software diese RAW Daten richtig zu "interpretieren"?


    genau so funktioniert das, ja


    Zitat

    Wenn das so ist kaufe ich ein CatWeasel und bastle mir das! Ich weiss haargenau wie die GCR Daten zu interpretieren sind, wenn ich sie in einem File vorliegen habe.


    wobei die aktuelle software jedes erdenkliche gcr format eh schon unterstützt, auch das 8250 format, bei denen es wohl bisher exakt einen user gibt der ein passendes laufwerk auftreiben konnte :)

  • wobei die aktuelle software jedes erdenkliche gcr format eh schon unterstützt, auch das 8250 format, bei denen es wohl bisher exakt einen user gibt der ein passendes laufwerk auftreiben konnte :)


    Was wäre ein passendes Laufwerk? Eines aus einer 8250?


    Ich hatte gehofft ein PC Laufwerk (HD Laufwerk) kann "alles" lesen. "Alles" bedeutet für mich 1541, 1571, 4040, 8050, 8250/SFD. Ich habe ein PC HD Laufwerk da, das geht also nicht? Und das 8250 Laufwerk habe ich auch, das geht aber nicht fßür 1541?

  • Ich hatte gehofft ein PC Laufwerk (HD Laufwerk) kann "alles" lesen. "Alles" bedeutet für mich 1541, 1571, 4040, 8050, 8250/SFD. Ich habe ein PC HD Laufwerk da, das geht also nicht? Und das 8250 Laufwerk habe ich auch, das geht aber nicht fßür 1541?


    das pc laufwerk steppt wie schon gesagt mit 96tpi, das in der 8250/sfd aber leider mit 100tpi. so kann man die richtige position um einen track zu lesen nur schwer bis garnicht erreichen. und das laufwerk in der 8250/sfd wiederum hat leider keinen shugart-bus anschluss, so das es an der stelle schwierig wird. das könnte man eventuell mit einem - recht aufwendigen - adapter lösen.

  • Aha! man "trifft" sozusagen die Spur nicht, weil der Kopf immer etwas "daneben" ist!


    Man müsste also eine feinere Kopfbewegung erreichen, wie bei einer CNC Fräse? Zudem bräuchte man verschiedene Köpfe mit unterschiedlichen Spalt Breiten?



    Naja egal, bei der 8250 gibt es ja fast keine kopiergeschützten Disketten.

  • Man müsste also eine feinere Kopfbewegung erreichen, wie bei einer CNC Fräse? Zudem bräuchte man verschiedene Köpfe mit unterschiedlichen Spalt Breiten?


    jo, das wäre wohl der idealfall... ein hochpräziser servo statt dem stepper, und statt dem einen kopf am besten gleich mehrere mit verschiedenen eigenschaften.... leider auch nicht so das erfolgversprechende bastelprojekt :o)


    Zitat

    Naja egal, bei der 8250 gibt es ja fast keine kopiergeschützten Disketten.


    gibts da überhaupt welche? :)

  • gibts da überhaupt welche? :)


    Backup einer 8250-Diskette funzt nicht :(



    Möglicherweise aus C64/1541 Sicht eine stümperhafte, einfache Methode, aber es sieht nach Kopierschutz aus. Wahrscheinlich nur eine spezielle Modifikation der BAM / Header Sektoren.