Forum64

Hallo zusammen,

wir freuen uns, endlich die öffentliche Beta von KryoFlux präsentieren zu können. Wer die WIPs gelesen hat, weiß, dass wir seit Mitte letzten Jahres intensiv mit der Entwicklung beschäftigt waren. Wir sind jetzt ziemlich ausgelaugt, aber auch sehr froh, dass endlich Licht am Ende es Tunnels zu sehen ist.

Wer noch nicht weiß, worum es geht, sollte sich den KryoFlux Teaser-Trailer ansehen.

Kurzinfo: Mit KryoFlux können gängige Diskettentypen über eine USB-Hardware gelesen werden. Zu den unterstützten Formaten gehören: Acorn Electron, Apple, Amstrad CPC, Archimedes, Atari 8-bit, Atari ST, BBC, Commodore 64, Commodore Amiga, MSX, IBM PC, PC-8801, Sam Coupe, Spectrum und noch einige mehr.

Zum Download der Public Beta geht es hier.

Die nächsten Schritte... Hardware!

Wir würden gerne zum jetzt vorläufig finalen Design noch einige Rückmeldungen abwarten, bevor dann endlich Boards gemacht werden. Wir sind in Sachen Manpower echt am Limit. Lars (Reptile) hat ja schon ein komplettes Design hingelegt, das wir intensiv auf Fehler geprüft haben. Hier ist nichts mehr aufgefallen.

Es haben sich nun diverse Möglichkeiten ergeben, das Board professionell fertigen zu lassen. Allerdings haben zwei der möglichen Partner Probleme mit der Auflösung, da diese nur etwas gröbere DRUs (EAGLE Design Rules, u.a. verantwortlich für die Größe der Bohrlöcher) verarbeiten können. Dafür müsste aber das Layout noch einmal minimal angefasst werden. Wir wollen nun schauen, was der passende gemeinsame Nenner ist und die Sache dann angehen.

Wer EAGLE Files bearbeiten kann, ist herzlich eingeladen uns dabei zu helfen.

Der nächste Schritt wäre dann noch das Einbauen von entsprechenden Bus-Treibern, die auch mit älteren Laufwerken (wirklich alte 5.25" LWs u.a.) klarkommen. Hier wissen wir bereits, was wir machen wollen, es müsste nur noch umgesetzt werden. Auch hier nehmen wir gerne noch Hilfe an.

Die Hardware ist im übrigen Freeware ohne Einschränkungen, jeder kann nachmachen und bauen was er möchte. Wir schränken lediglich die Verwendung der Namen ein. Wer also professionell ein KryoFlux-Board herstellen möchte, braucht unser OK. Der Hintergedanke ist sehr einfach: Wer ein unter diesem Namen hergestelltes Board kauft, sollte sicher sein können, dass es funktioniert. Daher muss in einem solchen Fall eine Freigabe erfolgen.

Die Quelltexte zur Host-Software werden ebenfalls veröffentlicht, aber erst, wenn wir mit der Public Beta durch sind. Hier klammern wir die kommerzielle Nutzung aus, die Hintergründe dürften klar sein. Es soll nicht jemand anderes damit Geld verdienen. Besser machen, schöner machen und auf andere Plattformen portieren darf jeder... und es auch weitergeben. Aber eben nicht zu Geld machen. Sollte Geld fließen, dann für das Projekt softpres.org, damit die weitere Entwicklung finanziert werden kann.

Ich darf noch einmal darauf hinweisen, dass alle vergleichbaren Projekte bei i.d.R. weniger Leistung wesentlich mehr kosten. Uns ist zumindest kein Projekt bekannt, das für lau (vom Material abgesehen) verfügbar ist.

Aktuelle Informationen rund um den Forschritt des Projekts gibt es hier. Dort bitte auch Bug Reports posten, damit wir das Produkt noch besser machen können.

EDIT/remaxx: In den richtigen Bereich verschoben !

Na sicher, Eagle Files liegen natürlich bei. Außerdem kannst Du auch mit einem erhältlichen ATMEL Dev Board schon was funktionierendes löten.

Einfach mal in das Archiv reinschauen. In 9 MB passt viel rein... wobei 90% sowieso für die Microsoft-Komponenten bezüglich der USB-Treiber draufgehen. :-)

Quoted from "sauhund"

da ich schon eine dieser fiess teuren alternativen lösungen habe würde mich eigentlich eher der source dieser software interessieren, löten muss nicht sein das ist doch hoffentlich so weit abstrahiert das der software wurscht ist wo der bitstrom her kommt?

ne, das ist ganz und gar nicht egal. wir haben die erfahrung gemacht, dass viele lösungen am markt die daten irgendwie zurecht "pfuschen". da wird schnell mal ein index-signal mit dem nächsten flux-wechsel kombiniert etc. pp. kryoflux überträgt die daten vom usb adapter so, wie sie auf der disk sind und schreibt dazu ein "echtes" streamfile mit dem realen abbild der daten auf der disk oberfläche. kryoflux wird daher in absehbarer zeit keine andere hardware unterstützen, sondern ist genau auf die kommunikation mit dieser hardware zugeschnitten. das war aber auch nie der plan, darum sollen sich die hersteller kümmern, die die teure hardware verscheuern. aber da hört die motivation meist auf, wenn genügend geräte verkauft wurden. diese lücke wollen wir nicht füllen. wir wollten es endlich mal richtig machen: die hardware so einfach wie möglich, die transfer-software so effizient wie eben möglich und dann, wenn die daten 1:1 im rechner sind, dann kann man sich die sache ansehen und in z.b. sector dumps umwandeln.

Quoted from "sauhund"

apropos, kann die software G64 ?

aus gutem grund nicht. damit könnte sich wieder der verdacht aufdrängen, man hätte was sinnvolles gemacht und seine daten "sicher" und 1:1 gespeichert. G64 ist in der tat "nett" (ich habe selber einige sachen als G64 hier - man nimmt ja, was man kriegen kann, wenn es keine alternative gibt), aber es fehlt an allen ecken und enden, um eine diskette so zu beschreiben, wie das z.b. im kopierwerk gemacht wurde. d.h. wir werden IPF entsprechend erweitern, so dass hier eine echte alternative existiert. in der zwischenzeit kannst du natürlich, sobald verfügbar, den source nehmen, und dir G64 einbauen. nur sinnvoll ist das nicht. denn tools dafür gibt es ja einige, nur gibt es auch gründe, dass immer noch neue lösungen entwickelt werden.

mir fällt im übrigen auf, dass man den fred hier noch gezielter unter transfertools einordnen könnte. mensch, dieses forum ist so gut sortiert, dass ich mich selbst ständig verlaufe. wenn das hier ein mod sieht... gerne mal verschieben. danke!

Quoted from "sauhund"

äh, ich glaub du hast die frage nicht verstanden.... lass das mal meine sorge sein das die daten ok sind zumindest wenn ich die hardwarebeschreibung richtig verstanden hab kann der unterschied jetzt auch nicht wirklich weltbewegend sein

du meinst man soll dann, wie im amiga umfeld anscheinend üblich, dumps machen, die an irgendwelche leute schicken, welche dann diese dumps mit nicht öffentlichen tools in ein undokumentiertes format (ich nehme doch mal an das es keine doku zum ipf format geben wird?) wandeln das dann auch nur mit closed-source libraries verarbeitet werden kann? ich fürchte das ist im c64 umfeld nicht wirklich der richtige ansatz, zumindest bei denen die ernsthaft an dem auslesen von originalen arbeiten wird das sicher nicht auf gegenliebe stossen =P

zu 1.: nein, es wird nur die "eigene" hardware unterstützt, die sich jeder für die materialkosten bauen kann. wer eine andere hardware bedienen möchte, wird dafür eigenen code schreiben müssen.

zu 2.: nein, du hast mich falsch verstanden. du kannst die einwandfreien rohdaten in was immer du willst wandeln. aus diesen daten kann man ipfs machen, aber auch d64, g64 oder was auch immer. du darfst nur nicht von uns erwarten, dass wir code schreiben, der wiederum images erzeugt, die wir selbst für nicht sinnvoll halten. wir hindern ja niemanden daran, das zu tun. es gibt aber hunderttausende von images, die defekt sind, von kaputten disks stammen oder einfach nur beim transport beschädigt wurden. bei ipfs kannst du dir immerhin sicher sein, dass die daten darin funktionieren. wenn dich das format stört, nimm einmal eine der closed source libraries, lade sie auf einem close source windows oder in teilen closed source mac os oder lade sie unter linux... und schreib dir die daten in ein besseres, eigenes container format. ich befürchte nur, ohne das jetzt überheblich zu meinen, dass den meisten hier dafür das verständnis der materie fehlen wird. ich bin mir sogar sicher, dass wenn der analyser, mit dem die ipfs erzeugt werden, frei verfügbar wäre, wir keine signifikante steigerung an neuen, noch nicht gedumpten spielen erfahren würden. wir würden einfach nur tausende von kaputten ipfs zusätzlich rumschwirren haben.

aber das ist ja eben das schöne an kryoflux... jeder kriegt, was er will. die einen dumpen sich damit direkt ihre sector dumps, andere geben uns streamfiles um daraus ipfs zu machen und wieder andere schreiben sich ihre eigenen exportfilter. und "zurück auf disk" ist ja auch noch geplant.

Quoted from "sauhund"

ja genau, das war ja die idee. der teil der die daten von der hardware holt ist doch eh trivial, der interessante teil steckt in den de- und encodern

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.

Quoted

das dumme dabei ist nur, das man aus einem ipf auf die art nicht die infos auslesen kann die man gerne hätte - sondern man muss die daten genauso analysieren wie man es müsste wenn man sie gleich von disk liesst. (und für die images für die das nicht zutrifft braucht man mit grosser warscheinlichkeit auch kein ipf). damit kommt man nicht weit.

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.

Quoted

kann sein. ich beschäftige mich mit der materie aber schon ein wenig länger, länger als es caps und ipf und dieses zeug gibt sogar =P

das macht ja nix. ich habe auch nicht in abrede gestellt, dass du davon ahnung hast.

Quoted

wie genau wird denn sichergestellt das die images auch ok sind? wollt ihr jedes spiel durchspielen? (davon ab, wenn man nicht grad auf planetemu, tosec, oder sonstwas für wirren quellen guckt, dann kriegt man auch eine sammlung in der 99.9% aller g64 in ordnung sind)

die ipfs beruhen auf der analyse der verwendeten codierung. d.h. es wird nicht einfach ein mfm-blob gelesen und gespeichert, sondern eine beschreibung der daten hinterlegt. ganz ganz grob wird hier gegen ein (vom benutzer definiertes) schema validiert, ähnlich wie wenn ein xml gegen seine definition geprüft wird. teilweise werden dazu die kompletten loader disassembliert. archivierung soll eben genau das sein: authentisch und unmodifiziert.

du lässt im obigen beispiel außer acht, dass die genannten sammlungen meist keine defekten images aufnehmen oder eben kennzeichnen. du lässt ebenfalls außer acht, dass es sich im gros der titel eben um cracks handelt, die möglicherweise erheblich modifiziert wurden. 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.

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. das ist jetzt kein schimpfen auf g64, sondern wir sind uns eben sicher, dass wir es heute mit anderer technologie besser machen können. dadurch, dass das ipf "weiß", welcher effekt gewünscht ist, laufen auch timing-kritische sachen einwandfrei. das ipf enthält identische, teilweise sogar detailiertere beschreibungen, was replizierer zum schreiben der disks in den 80er und 90ern benutzt haben. 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.

ich habe dazu lange mit pete rittwage gemailt, der im übrigen ein quell der informationen und auch ein engagierter software archivar ist, und wir sind überein gekommen, dass auch er gerne was besseres nutzen würde. sprich: weg von der original 1541 oder 1571 zum lesen (weil da teilweise auch schon nicht mehr das rauskommt, was auf der disk drauf ist), und hin zu einem universellen tool zum einlesen und einem neuen format. ich freue mich dennoch, dass pete die 64er preservation angestoßen hat. lieber einen titel "nur" als g64, als gar nicht. aber ich denke, wir stimmen überein, dass man, wenn man weiß, man kann es besser, auch besser machen sollte.

abschließend noch ein paar worte zum handling der ipfs: wir sitzen ja nicht jeden abend hier, zählen unsere ipfs und freuen uns, dass wir was haben, was kein anderer hat. die rechtslage verbietet uns leider, die files online zu stellen. wir stehen halt als projekt voll in der schusslinie. private anwender hingegen eher weniger. außerdem sind initiativen wie capsdi ja komplett anonym. wir hegen natürlich immer unterschwellig die hoffnung, dass die community das selbst regelt, immerhin bekommen einsender ja die ipfs retour. was die dann damit machen, liegt nicht mehr in unserer hand.

dass die ipfs nur zentral gemacht werden, hat aber einen weiteren, nicht zu unterschätzenden nebeneffekt. 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.

beste grüße
christian