Hallo Besucher, der Thread wurde 7k mal aufgerufen und enthält 26 Antworten

letzter Beitrag von Mac Bacon am

neue Version von MacBootMake

    Hi!


    Ich hab letztens alte 128er-Sourcecodes aufgeräumt und in der richtigen Reihenfolge in einem Repository gespeichert (damit die veralteten Versionen aus den Augen sind, aber trotzdem nicht verloren - wirklich brauchen werde ich die hoffentlich nie mehr :)).
    Dabei musste ich feststellen, dass in meinem C128-Bootmaker, je nach Version, drei bis vier ziemlich peinliche Bugs drin sind - einer hat sich über zehn Jahre gehalten. Daraufhin konnte ich mich nicht mehr beherrschen und hab eine neue Version gemacht. Bootmaker für den 128er gibt es natürlich wie Sand am Meer; die am ehesten herausstechendsten Merkmale dürften die Erkennung und Unterstützung auch von 1581 und CMD-Partitionen sein.
    Über Testberichte, Kritik etc. freue ich mich - und wenns keiner braucht, isses mir auch egal. :-)=)


    Cu,


    Mac

    Zitat von Mac Bacon

    Über Testberichte, Kritik etc. freue ich mich - und wenns keiner braucht, isses mir auch egal. :-)=)


    Warum steht denn da "OWDY, HACKER." im erstellten Bootsektor?

    Die Anzahl der in den Buffer geschriebenen Bytes hängt von der Länge der Boot-Message und des Dateinamens ab. Mit anderen Worten: am Ende des Bootblocks steht irgendwas, das sich gerade im Laufwerks-RAM befand.


    EDIT: Ich schreibe mal "clear buffer and write 'created by MacBootMake vX' to end of buffer" auf die ToDo-Liste. ;)

    Zitat von Mac Bacon

    Die Anzahl der in den Buffer geschriebenen Bytes hängt von der Länge der Boot-Message und des Dateinamens ab. Mit anderen Worten: am Ende des Bootblocks steht irgendwas, das sich gerade im Laufwerks-RAM befand.


    Ah, das erklärts - ich hatte zuvor den Bootsektor von Ultima 5 in der Datei und sd2iec macht sich ebenfalls nicht die Mühe, den Puffer zu löschen.

    Zitat von Heisenberg

    Wieso steht da "Mac" ??


    Klar, ich hätte das Programm auch "AceBootMake" oder "HeisenbergBootMake" nennen können, hab es aber wegen der potentiellen Verwechslungsgefahr lieber gelassen... :whistling:

    Komisch, ich verbinde Mac eher mit dem goldenen M (ja, ist nur vom Klang her identsich, aber mein Hirn reagiert nun mal auf akustische Ähnlichkeiten). Oder an einen Schotten. An die Apple-Rechner denke ich da eher nicht - schon gar nicht in diesem Forum.

    Gib es bereits eine neue Version von MacBootMake?


    Seit dem 2013-11-21 kann die pre/alpha Versionen von sd2iec auch auf FAT mit Bootsektoren umgehen. (commit)


    Evtl muesste man die Zeilen 1008ff anpassen damit dies auch erkannt wird.
    Ein INSTR auf die Rückgabe von @X? sollte eine sd2iec-Firmware-basiertes Gerät erkennen.


    Bin aber gerade nicht merh der schnellste in Basic ;)

    Zu dem Thema hab ich Unseen eine gepatchte Version von MBM geschickt, aber noch keine Antwort erhalten. Ich würde statt "@X?" bevorzugen, wenn SD2IEC im FAT-Modus einfach statt "A" ein "F" als Format Specifier benutzt - dann könnte MacBootMake (und ähnliche Tools) diesen Fall genauso erkennen und behandeln wie es jetzt schon mit CMD-Native-Partitionen geschieht: Nämlich einfach, indem T1S0 gar nicht allokiert/freigegeben wird.


    EDIT: Und ja, die Änderungen an MBM beschränken sich - neben Datum und Versionsnummer - auf das Hinzufügen von:

    Code
    1. 1019 if a$ = "f" then e = 0:ty = 0:t$ = "SD2IEC (FAT mode)

    Da ich kein SD2IEC habe, kenne ich nicht den aktuellen Stand der Firmware, aber nach der letzten Nachricht von Unseen müsste man statt "f" den Leerstring "" angeben. "f" wäre mir allerdings lieber. ;)

    Zitat von Mac Bacon

    Zu dem Thema hab ich Unseen eine gepatchte Version von MBM geschickt, aber noch keine Antwort erhalten.


    Hmm, laut meiner Forums-Postbox hatte ich darauf eine Antwort geschickt. Nur getestet habe ich die Version nie, weil im Augenblick das Anschliessen des C128 statt C64 etwas umständlich ist.


    Zitat

    Ich würde statt "@X?" bevorzugen, wenn SD2IEC im FAT-Modus einfach statt "A" ein "F" als Format Specifier benutzt


    Ich bin ja immer wieder skeptisch, wenn man an irgendeiner Stelle etwas anders macht als eine 1541 obwohl deren Verhalten genauso einfach nachzubilden ist... Ausserdem würde trotzdem weiterhin gelten, dass alle sd2iec-Erkennungsversuche, die nicht den DOS-Versionsstring oder eine der noch längeren Versionsangaben (zB X?) verwenden jederzeit kaputtgehen können.


    Zitat

    aber nach der letzten Nachricht von Unseen müsste man statt "f" den Leerstring "" angeben. "f" wäre mir allerdings lieber. ;)


    chr$(0) ist nicht der Leerstring, das ist nur ein Bug im BASIC-Interpreter beim Lesen von Zeichen.

    Zitat von Unseen

    Hmm, laut meiner Forums-Postbox hatte ich darauf eine Antwort geschickt. Nur getestet habe ich die Version nie, weil im Augenblick das Anschliessen des C128 statt C64 etwas umständlich ist.

    Ja, ich meinte natürlich eine Antwort, die sich auf die Testversion bezieht. Wenn Du die Version gerade nicht testen kannst, müssen wir halt jemand anderen finden (ich kann es auch nicht, da ich kein SD2IEC habe).

    Zitat von Unseen

    Ich bin ja immer wieder skeptisch, wenn man an irgendeiner Stelle etwas anders macht als eine 1541 obwohl deren Verhalten genauso einfach nachzubilden ist... Ausserdem würde trotzdem weiterhin gelten, dass alle sd2iec-Erkennungsversuche, die nicht den DOS-Versionsstring oder eine der noch längeren Versionsangaben (zB X?) verwenden jederzeit kaputtgehen können.

    Aber der FAT-Modus ist nun mal ein anderes Format, welcher z.B. direkte Blockzugriffe über das raw-Directory nicht nachbilden kann. Genau für solche Unterscheidungen ist das Formatbyte da.
    Um eine generelle SD2IEC-Erkennung geht es hier nicht, denn in z.B. einem d64-File soll MBM ja den normalen 1541/71-Algorithmus benutzen.
    Übrigens muss ich meine Präferenz für "F" etwas relativieren; möglicherweise gibt es esoterische Laufwerke, die damals (tm) tatsächlich dieses Formatbyte benutzt haben (mal skern fragen, der hatte da eine relativ lange Liste). Sollte "F" schon in Benutzung sein, schlage ich "V" (für VFAT) vor.
    In unseren PMs hattest Du ein Nullbyte vorgeschlagen; ist das jetzt so released? Wenn Du unbedingt beim Nullbyte bleiben willst, werde ich mich auch damit abfinden (müssen ;)), aber ein Nullbyte finde ich irgendwie nichtssagend.

    Zitat von Unseen

    chr$(0) ist nicht der Leerstring, das ist nur ein Bug im BASIC-Interpreter beim Lesen von Zeichen.

    Ist klar; da MBM an dieser Stelle tatsächlich GET# benutzt, kommt es aber auf das Gleiche heraus. Tatsächlich hatte ich in der Dir geschickten Testversion noch ein

    Code
    1. if a$="" then a$ = chr$(0)

    hinzugefügt und dann auf Gleichheit mit chr$(0) geprüft, aber vorhin beim Beschreiben der nötigen Änderungen keinen Sinn mehr darin gesehen - genausogut kann man das if/then weglassen und an der entsprechenden Stelle auf Gleichheit mit "" prüfen.

    Zitat von Mac Bacon

    Sollte "F" schon in Benutzung sein, schlage ich "V" (für VFAT) vor.
    In unseren PMs hattest Du ein Nullbyte vorgeschlagen; ist das jetzt so released? Wenn Du unbedingt beim Nullbyte bleiben willst, werde ich mich auch damit abfinden (müssen ;)), aber ein Nullbyte finde ich irgendwie nichtssagend.


    Das Nullbyte hatte ich vorgeschlagen, weil es am codesparendsten ist.


    Wobei die Annahme, dass da ein Byte für "FAT" stehen würde auch falsch ist - der Fall den du gerne geändert haben möchtest ist der Fallback für alles, was kein D64 oder ähnliches Format ist, wo schon ein Directory im passenden Format auf Disk vorliegt. Im Augenblick betrifft das zwar nur Dateien, die direkt im FAT-Verzeichnis liegen (und evtl. noch eine Namenstransformationsdatei haben), aber falls sd2iec mal irgendwann weitere Daisystem- oder Containerformate lernt, dann würde das synthetische Rawdir da das gleiche Formatbyte ausspucken. Ob es da eine vergleichbare Bootsektoremulation gäbe wäre im Einzelfall zu entscheiden.


    Zitat von Unseen

    Tatsächlich hatte ich in der Dir geschickten Testversion noch ein

    Code
    1. if a$="" then a$ = chr$(0)

    hinzugefügt und dann auf Gleichheit mit chr$(0) geprüft


    Beim C128 hat Commodore den BASIC-Interpreter netterweise etwas toleranter gemacht: ASC("") ergibt keinen Fehler mehr sondern liefert 0 zurück.

    Zitat von Mac Bacon

    Wenn Du die Version gerade nicht testen kannst, müssen wir halt jemand anderen finden (ich kann es auch nicht, da ich kein SD2IEC habe).

    Ich hab die Testversion jetzt auch abraXxl zugänglich gemacht.

    Zitat von Unseen

    Beim C128 hat Commodore den BASIC-Interpreter netterweise etwas toleranter gemacht: ASC("") ergibt keinen Fehler mehr sondern liefert 0 zurück.

    An der fraglichen Stelle benutze ich kein ASC(); ich vergleiche direkt mit Stringkonstanten.
    ...und ob die tolerantere Version die bessere ist, wäre vermutlich einen eigenen Thread wert... :whistling:

    Zitat von Unseen

    Ich bin ja immer wieder skeptisch, wenn man an irgendeiner Stelle etwas anders macht als eine 1541 obwohl deren Verhalten genauso einfach nachzubilden ist... Ausserdem würde trotzdem weiterhin gelten, dass alle sd2iec-Erkennungsversuche, die nicht den DOS-Versionsstring oder eine der noch längeren Versionsangaben (zB X?) verwenden jederzeit kaputtgehen können.


    Wird "X?" in sd2iec stabil sein?
    Ich würde vermeiden wollen die Floppy/SD2IEC zu Soft-Resetten, um nicht den Status der Laufwerksnummer oder des Verzeichnisses zu verlieren. Wie verhält sich sd2iec bei @UJ? Wird das Image/Veruzeichnis auf das FAT-Root gesetzt? (kann gerade nicht testen.)


    Zitat von Mac Bacon

    Ich hab die Testversion jetzt auch abraXxl zugänglich gemacht


    Die kann ich nicht aufrufen. Der Zugang zu dem Beitrag ist mir verwehrt.

    Zitat von abraXxl


    Die kann ich nicht aufrufen. Der Zugang zu dem Beitrag ist mir verwehrt.


    Tut mir leid, war mein Fehler. Das hab ich davon, dass ich schlauer sein wollte als die Forums-Software. Inzwischen solltest Du die Version aber haben.