Hello, Guest the thread was viewed8.3k times and contains 69 replies

last post from alx at the

FIBR – Der File Browser für Festplatten und Speicherkarten

  • Es geht ja nicht um das Abwägen von Bedürfnissen – Kopieren soll ja kommen. Nur muss erst das Fundament stehen und dann kann man die Funktionen erweitern. Man kann keine Kopierfunktion einbauen, wenn das Laden von Verzeichnissen nicht funktioniert. Sobald alx soweit ist, dass FIBR als Programmstarter funktioniert (das wäre V1), sollen DOS-Funktionen wie Kopieren ja integriert werden (also in V2), sofern die Hardware/Firmware das zulässt. Wie gesagt ist das alles schon vom Konzept her angedacht, nur muss erst die Hardware-Unterstützung, die Grundfunktionen und die Bedienung inkl. der Bildschirmdarstellung sauber sein.


    Wir wollen ja nicht den Fehler der anderen Datei Browser machen, die ich mir angesehen habe, die evtl. ja tolle Funktionen haben mögen (was ich nicht weiß, da sie bei meiner Hardware alle abstürzen) aber entweder nicht mit alternativen Kernels laufen oder mit dem MMC2IEC oder dem iec-ata nicht funktionieren oder gleich beim Testen im Emu abschmieren (com64/xfile). Deswegen wird ja auch zuerst eine Testversion veröffentlicht werden, die nur wenige Funktionen hat aber die auf den unterschiedlichsten Hardware getestet werden soll. Wenn die gefundenen Bugs alle beseitigt sind, geht es um die Erweiterung der Funktionen.

  • Ich meinte ehr, dass vielleicht viel mehr leute wert legen auf Dateibetrachter. Vielleicht ist es für andere viel wichtiger, dass sie möglichst viele Bildformate anschauen können, Text-Viewer oder Editor haben und auch noch gleich einen HEX-Editor dazu. Dann könnte man sich in V2 mehr darauf konzentrieren. Für mich ist halt Kopieren wichtig.
    Testen werde ich gern. Freu mich schon drauf! Hab ja auch einiges an Hardware hier:
    1541 (in allen Formen und Farben), 1570, 1571, 1581, IEC-ATA, MMC2IEC, 1541-III, 1541 Ultimate
    Leider hab ich keine:
    1541 Nachbauten wie Oceanic oder dergleichen, kein Jiffy-DOS, keine Parallel-Speeder, keine CMD Laufwerke, kein IDE64 und kein MMC64


    Aber hier gibt es ja genug Leute zum testen!


    Gruß,
    Cyberdyne

  • Hallo Leute, ich muss auch noch meinen Senf dazu geben.
    Ich habe vor einiiger Zeit eine Möglichkeit gesucht die Hunderte von d64 Files der 64'er CD und Anderen auf meinem C64 direkt verfügbar zu machen. Es sollten alle Files in Directories ( je d64) auf eine CMD HD landen. Also mit cd rein und load run starten.
    Da waren aber auch seq, del, usr, rel, geos, cp/m und weis der Kukug was noch für Zeug dabei.
    Also hab ich ein Basicprogram getippt was das alles kann ( cp/m nicht).
    Später ist dann noch dir hizu gekommen.
    Diese Programm kann folgende Laufwerke bedienen.(getestet) 1541,1571,1581,CMDHD,CMDFD,CMDRL
    CBM 4020,4030,4040,8050,8280,sfd1001,sfd1002,
    (ungetest) D9060.D9090.


    Das gröste Problem war zu wissen wo die Directory ist. Da zb. bei der CMDHD das irgendwo in den 16MB sein kann.
    Das habe ich leicht gelöst, da das Laufwerk mir das verräht, ohne zu wissen was für ein laufwerk verwendet wird.


    open15,8,15
    open2,8,2,"$"
    print#15,"b-p";2;0.get#2,a$:?asc(a$+chr$(0))
    open2,8,2,"$"
    print#15,"b-p";2;1.get#2,a$:?asc(a$+chr$(0))
    Das funktioniert bei allen H und A Geräten, Bei den Disketter vom typ C, und bei den CMB Festplatten muss ein Offset dabei
    und man bekommt Track und Sektor von der Directory.


    Das sollten auch alle neuen Laufwerke in Ihrer Firmware inpementieren.
    Ich versuche das in die iec-ata einzubauen.

  • Das sollten auch alle neuen Laufwerke in Ihrer Firmware inpementieren.
    Ich versuche das in die iec-ata einzubauen.


    Verstehe ich das richtig, du willst die Directorysektoren direkt (und wohl auch noch von Hand via U1/U2) einlesen? Dir ist aber schon klar, dass einige "Laufwerke" gar kein Commodore-kompatibles Dateisystem dahinter haben und damit auch keine Directorysektoren in diesem Format anbieten können?


    Wie verbreitet ist überhaupt die Methode, $ mit Sekundäradresse != 0 zu öffnen? Ich kenne den erst seit ich das Rom-Listing für sd2iec durchwühlt habe, aber das muss ja nichts bedeuten.

  • Hallo,
    mir ist schon klar, das wenn man Fat ,Ntfs oder sonstas für die Datenspeicherung verwendet man da nicht mehr nativ drauf zugreifen kann.
    Aber zB. in der Uhrverseion des IEC-ATA war dir Directory mit !=0 bereits drinn. nur die Bufferkommandos fehlen und die Mödlichkeit durch beschreiben von Directoryblöcke den inhalt in dem tatsächlichen Filesystem zu ändern.
    Da die Meisten Programme 1541 verarbeiten braucht man nur ein Scheiben auf track 18 beachten und da die je 30 byte auswerten .
    da man dem User ja vorher alle Daten gegeben hat weiß das Laufwerk was der User mit dem kommandos meint.
    (zugegeben etwas komplex)