Forum64

Quoted from "Diddl"

Werden 8250 Disketten auch gehen?

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

Quoted from "mr.vince"

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
  

Quoted

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.

Quoted from "mr.vince"

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 :)

Quoted from "mr.vince"

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.

Quoted from "mr.vince"

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?

Quoted

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?

Quoted

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

Quoted

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.

Quoted

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 :)

Quoted from "mr.vince"

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

Quoted from "Unseen"

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.

Quoted from "for(;;)"

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.

Quoted from "mr.vince"

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.

Quoted from "mr.vince"

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.

Quoted from "Unseen"

Fang mit dieser Liste an:

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

Und wenn ipf nun noch ein öffentlich dokumentiertes Format ist, dann sind wohl alle glücklich.

Aber egal, ich warte mal auf die Hardware

Quoted from "AntaBaka"

Und wenn ipf nun noch ein öffentlich dokumentiertes Format ist, dann sind wohl alle glücklich.

Aber egal, ich warte mal auf die Hardware

Jepp, seh ich auch so. Wenn das alles wirklich so umgesetzt wird, dann bekommen wir ein schönes Stück Spielzeug

Quoted from "mr.vince"

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? :)

Quoted from "mr.vince"

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)

Quoted from "mr.vince"

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?

Quoted from "mr.vince"

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.

Quoted from "mr.vince"

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)

Quoted from "mr.vince"

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 :)

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

Eine Binary für GP2X wäre nett....

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.

Quoted

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 :)

Quoted

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

Quoted

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).

Quoted

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

Quoted

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 :)

Quoted from "sauhund"

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?

Quoted from "Diddl"

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.

Quoted from "Diddl"

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)

Quoted

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

gibts da überhaupt welche? :)

Quoted from "sauhund"

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.