Individual Computers kündigt in Stockholm neue C64 Hardware an

Es gibt 346 Antworten in diesem Thema, welches 57.587 mal aufgerufen wurde. Der letzte Beitrag (20. Oktober 2008 um 13:50) ist von Cyberdyne.

  • Zitat

    Wenn ich Dich nicht fragen darf, dann frag ich eben alle anderen

    die probleme mit g64 sind im wesentlichen folgende:

    1. können die änderungen in der datenrate (die speedzones) nicht beliebig oft und beliebig genau definiert werden, weil das das g64 format ansich nicht her gibt (für sehr viele anwendungen reicht es aber trotz allem aus)
    2. stehen im g64 keine richtigen rohdaten (flusswechsel) sondern die daraus entstehenden gcr daten. das hat ein paar nachteile, zb den das sogenannte "weakbits" (die durch "ungültige" rohdaten entstehen) nicht, bzw nur mit trickserei dargestellt werden können.

  • die probleme mit g64 sind im wesentlichen folgende:

    1. können die änderungen in der datenrate (die speedzones) nicht beliebig oft und beliebig genau definiert werden, weil das das g64 format ansich nicht her gibt (für sehr viele anwendungen reicht es aber trotz allem aus)

    2. stehen im g64 keine richtigen rohdaten (flusswechsel) sondern die daraus entstehenden gcr daten. das hat ein paar nachteile, zb den das sogenannte "weakbits" (die durch "ungültige" rohdaten entstehen) nicht, bzw nur mit trickserei dargestellt werden können.

    Danke für die Antwort :)
    Zu 1. : Die Byte Auflösung ist nicht ideal, aber wie Du schon schreibst vermutlich ausreichend. Was ein größeres Problem sein könnte ist auch, dass die im GCR Format definierten Bits immer Vielfache von 8 sein müssen. Das könnte auf einer richtigen Disk evtl. anders sein. Man könnte sogar Prüfen dass dem nicht so ist, wenn man gemein ist :) Die Umdrehungsgeschwindigkeit könnte man aus der Länge des Tracks ableiten ... Aber irgendwie muss es dann zu den Speed-Bytes passen.

    Zu2.: Das höre ich jetzt zum ersten mal. Also wenn Du mit "Die daraus enstehenden GCR Daten" den Input zum Schiebregister meinst, dann haben wir ein größeres Problem, weil der bei 1541 und 1571 so viel ich weiss anders ist ... Ich dachte schon, dass die Roh-Flußwechsel gespeichert werden. Aber hier sieht man schon das Problem: Es herrscht eine gewisse Verwirrung was es nun ist. Die Daten auf der Disk oder die Daten am Schieberegister. Wären es die Daten am Schieberegister, dann könnte man nicht viel damit anfangen, weil ein Kopierschutz die Speed-Zone ja ändern kann und weak bits dann bei jeder Umdrehung einen anderen Wert liefern. Aber eben für jede Speed-Zone andere Werte .

    Kann mich jemand definitiv aufklären was nun gespeichert wird ? Was das Schieberegister ausspuckt oder was auf der Disk ist ?

  • Kein Problem - die GCR-Daten liegen ohnehin im Ram, nicht etwa die Sektordaten. Ich hätte gedacht, daß die 1541u das schon kann. Tatsächlich ist es sogar einfacher, ein G64-Archiv in den Puffer zu legen als ein D64, weil das ein Umwandlungsschritt weniger ist.

    Geil. :) Jetzt wird es interessant. Wie gesagt: Wenn das kompatibel ist und auch in der Praxis funktioniert, hast du mich schon fast als Käufer gewonnen (wenn du "ekelige" Testdaten/-disketten brauchst, schick mir mal 'ne Mail).

    Das 1541u kann GCR mit der letzten BETA-Firmware. Die Tests, die damit durchgeführt wurden sahen auch äußerst vielversprechend aus, so dass es für mich mittlerweile einen Kaufgrund gäbe.

    Wie sähe es denn mit einem weiteren, speziellen (Low-Level)-Format aus. Also dass man die "Rohdaten" aus dem Catweasel direkt in das Chameleon schiebt? Damit wäre man dann doch noch kompatibler (vorausgesetzt die Emulation spielt mit)?

    Zitat


    Das "andere" Format das Du meinst, ist wahrscheinlich DFI, nicht FDI.

    Nein, FDI, Das erstellt das kommerzielle Disk2FDI:
    Bitte melde dich an, um diesen Link zu sehen.
    (Ich hoffe, das ist der richtige Link. :))

    Weitere Infos hier:
    Bitte melde dich an, um diesen Link zu sehen.

    Ich habe mir das noch nicht genauer angeschaut, es soll aber einige(?) Limitierungen des GCR-Formats aufheben... Ah, genau, das Tool verwendet auch das Indexloch beim Auslesen. Das war ein Vorteil gegenüber mnib... :)

    Zitat

    Doch, habe ich schon realisiert. Nagelneue 5,25" Disketten,

    Äh - du meinst richtige "normale" Disketten? Die verschieben aber nur das Problem des Zerfalls. Ich meinte mehr einen Ersatz, der eine Diskette richtig ersetzt oder besser gesagt "emuliert". Es gibt doch diese MP3-Konverter fürs Autoradio. Das ist eine Kassette, die man in das Autoradio schiebt und dann über ein Kabel an den MP3-Player anschließt. Sowas in der Art hätte ich gerne für Disketten. :) Ich weiß, ist ein bisschen schwer zu realisieren... ;)

  • Zitat

    weil ein Kopierschutz die Speed-Zone ja ändern kann und weak bits dann bei jeder Umdrehung einen anderen Wert liefern. Aber eben für jede Speed-Zone andere Werte .

    interessanter ansatz :) müsste man fast mal ausprobieren ... :=)

    Zitat

    Kann mich jemand definitiv aufklären was nun gespeichert wird ? Was das Schieberegister ausspuckt oder was auf der Disk ist ?

    definitiv ersteres

  • interessanter ansatz :) müsste man fast mal ausprobieren ... :=)


    definitiv ersteres

    Und wenn ich Dir jetzt sage dass ich einige G64 Images kenne in denen mehr als 2 mal hintereinander "0" drin steht ? Das wäre doch unmöglich, wenn dort nur Schieberegister Daten stünden. Im Schieberegister können ja niemals mehr als 2 mal 0 ankommen.

  • Zitat

    Und wenn ich Dir jetzt sage dass ich einige G64 Images kenne in denen mehr als 2 mal hintereinander "0" drin steht ? Das wäre doch unmöglich, wenn dort nur Schieberegister Daten stünden. Im Schieberegister können ja niemals mehr als 2 mal 0 ankommen.

    das könnte dann so eine trickserei sein um weakbits (zb) zu erzeugen ... oder jemand hat die gaps einfach voller nullen gemacht (das sollte die emulation nicht stören).... weiss der geier :) es sind aber definitiv gcr daten, einfach mal nach "g64 image format" googlen

  • das könnte dann so eine trickserei sein um weakbits (zb) zu erzeugen ... oder jemand hat die gaps einfach voller nullen gemacht (das sollte die emulation nicht stören).... weiss der geier :) es sind aber definitiv gcr daten, einfach mal nach "g64 image format" googlen

    Ich kenn das Format fast auswendig. Hab schon früher gegoogelt. Ich bin mir eigentlich ziemlich sicher dass es genügend G64 gibt die ungültiges GCR enthalten. Kannst Du eine Quelle angeben die eindeutig sagt, dass es der Output vom Schieberegister ist, der gespeichert wird. Diese Info konnte ich nicht ergoogeln :) Aus dem Begriff "GCR" lässt sich das nicht ableiten.

    Mal ganz abgesehen davon, dass es dann mit dem G64 Format nicht möglich wäre jeden Kopierschutz nachzumachen. Entweder man macht das exakte Timing nach und bekommt die Flusswechsel als Input, oder man verwendet den Output vom Schieberegister und weiss was man tun muss um einen speziellen Kopierschutz auszutricksen.

    Also stellt sich für eine 100%tige Nachbildung der 1541 doch die Frage ob überhaupt Daten existieren, die diese Hardware als Input verwenden könnte.

  • Zitat

    Ich bin mir eigentlich ziemlich sicher dass es genügend G64 gibt die ungültiges GCR enthalten. Kannst Du eine Quelle angeben die eindeutig sagt, dass es der Output vom Schieberegister ist, der gespeichert wird. Diese Info konnte ich nicht ergoogeln Aus dem Begriff "GCR" lässt sich das nicht ableiten.

    mmmh nein. "gcr" heisst in dem fall wohl nicht "gültiges gcr" sondern eher "als gcr dekodierte rohdaten". in der emulation sieht das wohl so aus das das was im image steht in das "schieberegister" *rein* geht. müsste ich aber auch nochmal genau nachguckn, die floppy emulation in vice ist etwas wirr :)

    Zitat

    Mal ganz abgesehen davon, dass es dann mit dem G64 Format nicht möglich wäre jeden Kopierschutz nachzumachen. Entweder man macht das exakte Timing nach und bekommt die Flusswechsel als Input, oder man verwendet den Output vom Schieberegister und weiss was man tun muss um einen speziellen Kopierschutz auszutricksen.

    das ist soweit ich weiss auch richtig, eine ganze reihe g64 sind wohl nachträglich gepatcht, so das sie dann in der emulation funktionieren. ich glaube auf der webseite vom c64 preservation project steht dazu ein bischen was.

    Zitat

    Also stellt sich für eine 100%tige Nachbildung der 1541 doch die Frage ob überhaupt Daten existieren, die diese Hardware als Input verwenden könnte.

    fdi images würden das leisten können

  • Die Umdrehungsgeschwindigkeit könnte man aus der Länge des Tracks ableiten ...

    Kann man nicht, weil einige Kopierschutzverfahren damit bewusst "spielen".

    Zitat


    Ich bin mir eigentlich ziemlich sicher dass es genügend G64 gibt die ungültiges GCR enthalten.
    [...]
    Mal ganz abgesehen davon, dass es dann mit dem G64 Format nicht möglich wäre jeden Kopierschutz nachzumachen.

    Genau das ist der Fall. :) Du solltest dich mal mit Pete Rittwage in Verbindung setzen, dem Autor der nibtools. Wenn ich jetzt nicht ganz falsch liege, produziert der auch "ungültige" G64-Dateien.

    Zitat


    Also stellt sich für eine 100%tige Nachbildung der 1541 doch die Frage ob überhaupt Daten existieren, die diese Hardware als Input verwenden könnte.

    Das Catweasel könnte solche generieren (bzw. die Software dafür :)). In den .nib2-Dateien der nibtools gibt es auch mehr Infos als in den G64-Dateien. Und wie gesagt, ist FDI da auch etwas im Vorteil.

  • Zitat

    Das Catweasel könnte solche generieren (bzw. die Software dafür ).

    jo.... wenn mir jemand mal einen algoritmus zur erkennung des wraparounds basierend auf den rohdaten (!) verklickern könnte .... dann könnte ich das quasi sofort einbauen =) leider ist das aber alles andere als trivial :/

  • jo.... wenn mir jemand mal einen algoritmus zur erkennung des wraparounds basierend auf den rohdaten (!) verklickern könnte .... dann könnte ich das quasi sofort einbauen =) leider ist das aber alles andere als trivial :/

    Wie machen die das denn beim CAPS-Projekt?

  • Zitat

    Wie machen die das denn beim CAPS-Projekt?

    garnicht. IPF files sind anscheinend simple MFM images (die rücken ja keine infos raus), lediglich für die sector header steht ein bischen mehr in den images. die eigentliche "magie" die dann diese images im emulator lauffähig macht wird dann für jedes spiel extra in deren reader-dll eingebaut. (zumindest sieht es danach aus.) *rohdaten* können die mit dem amiga auch garnicht lesen. deren tools dürften mit mnib vergleichbar sein, die images eher mit d64 als g64.

  • die eigentliche "magie" die dann diese images im emulator lauffähig macht wird dann für jedes spiel extra in deren reader-dll eingebaut. (zumindest sieht es danach aus.) *rohdaten* können die mit dem amiga auch garnicht lesen. deren tools dürften mit mnib vergleichbar sein, die images eher mit d64 als g64.

    Das ist ja mal interessant, wobei ich mir letzteres auch schon gedacht hatte. :) Leider haben die Leute mir vom Projekt bislang auf Anfragen noch nicht geantwortet. Sonst hätte ich die Software selber mal etwas begutachten können.

  • Zitat

    Das ist ja mal interessant, wobei ich mir letzteres auch schon gedacht hatte. Leider haben die Leute mir vom Projekt bislang auf Anfragen noch nicht geantwortet. Sonst hätte ich die Software selber mal etwas begutachten können.

    alleine die tatsache das man die nicht einfach runterladen kann finde ich schon etwas strange ...

    naja mal sehen, es war auch mal angedacht IPF in das imagetool einzubauen, die frage ist nur ob das wirklich sinn macht (wenns wirklich so ist wie oben gesagt ists wohl eher nicht so) ... das imageformat ansich scheint sehr einfach zu sein, die frage ist wie man (legal) an die daten kommt die in der dll stecken.

  • Zitat

    Kann man nicht, weil einige Kopierschutzverfahren damit bewusst "spielen".

    Eine beliebte Methode ist es doch, mehr Daten auf den Track zu schreiben als ein 1541 schreiben könnte. Im GCR Image würde man dann mehr Daten finden als normalerweise möglich. Daraus resultiert dann notgedrungen eine bestimmte "Datendichte". Ich hab mich also falsch ausgedrückt. Die Umdrehungsgeschwindigkeit legt das Laufwerk fest, nur die Geschwindigkeit der Flußwechsel muss im Format definiert werden. Da sind die Speed Bytes nur bedingt geeignet. Aber die Datenmenge würde ziemlich genau festlegen, wie schnell die Flußwechsel aufeinander folgen müssen (In der emulierten Disk) Für die "Standard Speeds" können es die Speed Bytes sogar Byte genau, aber wenn die Datenraten höher bzw. niedriger werden dann wird es schwierig.

    Zitat

    Du solltest dich mal mit Pete Rittwage in Verbindung setzen


    Den habe ich schon öfter belästigt, weil mich das Thema interessiert und er natürlich die beste Adresse ist :)
    Was ich damals mitgenommen habe aus den Diskussionen war eben, dass ich das Gefühl hatte dass es keinen Sinn macht mit dem G64 Format eine genaue Emulation der Leselogik/Des Lesetimings zu machen, weil schlicht die besonders schwierig zu lösenden Kopierschutzverfahren dort nicht so abgebildet sind, dass die Low Level Emulation die Daten als Input verwenden kann. Bei den einfacheren Verfahren geht es gut, aber weak bits zusammen mit höheren/niedrigeren Datenraten und den Umdrehungstoleranzen ... Da ist dann Ende.

    Zitat

    Das Catweasel könnte solche generieren (bzw. die Software dafür :)). In den .nib2-Dateien der nibtools gibt es auch mehr Infos als in den G64-Dateien. Und wie gesagt, ist FDI da auch etwas im Vorteil.

    Eine Format-Definition ist das Eine, aber für einen echten Test braucht man natürlich real existierende Images von einem schwierigen kopiergeschützten Spiel. Gibt es irgendwo Images im FDI Format ?

  • Nochmal zurück zu der PC Tastatur Emulation: Ich frage mich wie die 64er Tastatur hier emuliert wird wenn die Anschlussart über den Expansionsport wandert. Werden hier die üblichen Tastatureingaben abgegriffen ? Wenn nicht, dann wird das ja keine kompatible Geschichte.

  • Nochmal zurück zu der PC Tastatur Emulation: Ich frage mich wie die 64er Tastatur hier emuliert wird wenn die Anschlussart über den Expansionsport wandert. Werden hier die üblichen Tastatureingaben abgegriffen ? Wenn nicht, dann wird das ja keine kompatible Geschichte.

    Es wird kompatibler als Du glaubst, weil eben *nicht* die Tastatursignale, sondern die Daten manipuliert werden, die aus der CIA gelesen werden.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.


  • Eine Format-Definition ist das Eine, aber für einen echten Test braucht man natürlich real existierende Images von einem schwierigen kopiergeschützten Spiel. Gibt es irgendwo Images im FDI Format ?

    Ich habe hier nur Problemkandidaten in den nib-Formaten. FDI wollte ich mir aber eigentlich auch schon längst angeschaut haben (ich komme irgendwie in der letzten Zeit zu nichts mehr :)).

  • Ich habe hier nur Problemkandidaten in den nib-Formaten. FDI wollte ich mir aber eigentlich auch schon längst angeschaut haben (ich komme irgendwie in der letzten Zeit zu nichts mehr :)).

    Bitte schick mir ein Image wenn Du mal Zeit findest :)