Hallo Besucher, der Thread wurde 5,1k mal aufgerufen und enthält 49 Antworten

letzter Beitrag von Retrofan am

Kein File-Requester in C64-Anwendungen

    Ich will hier nur mal etwas "Dampf ablassen": Was mich bei der Bedienung von vielen C64-Anwendungen nervt, ist das Fehlen eines vernünftigen Datei-Auswahl-Dialogs. Ich habe in letzter Zeit viele Anwendungen ausprobiert, vor allem, um meinen Systemfont in der Praxis auszutesten. (Das schöne ist, dass die Mehrheit aller Anwendungsprogramme den ROM-Zeichensatz des C64 (und wenn man den austauscht, dann halt den neuen) nutzt.) Was damals in den 80ern aber wohl nicht gebräuchlich war, war ein gewisser Komfort beim Laden von Dokumenten. Wählt man einen Menüpunkt, wie "Laden" o.ä., wird man meistens mit einer schnöden Aufforderung abgespeist, doch bitte aus dem Kopf den gewünschten Dateinamen einzugeben (natürlich auch ohne die Möglichkeit, z.B. die Geräteadresse zu wechseln). Warum wird so selten ein Inhaltsverzeichnis angezeigt? Ist das wirklich so kompliziert, diesen kleinen Komfortgewinn zu integrieren? Wenn man Glück hat, gibt es an anderer Stelle die Möglichkeit, das Directory anzuzeigen, um sich dann den gewünschten Dateinamen zu merken, damit man ihn unter "Laden" dann wiederum manuell eingeben kann. Mann, das nervt!


    :cry::grr::aerger::encolere20::bmotz::gahh:


    Hier ein C64-Beispiel für diese Art von "Dialog" und dann ein zum Vergleich früher systemeigener Öffnen-Dialog, wie man ihn sich im Optimalfall wünschen würde. Man sollte dabei bedenken, dass maximal 2 Jahre dazwischen liegen (C64: 1982, Macintosh: 1984), bei der Entstehung der Anwendungsprogramme oft sogar gar keines.


    Zitat von enthusi

    Na dann: frisch ans Werk.

    Häh, soll ich jetzt eine beliebige Anwendung schreiben, nur um da einen File-Requester einzubauen? Oder was soll ich "werken"? Ich kann den vorhandenen Anwendungen ja schlecht neue File-Requester unterjubeln. Es nervt mich halt nur, dass es damals™ so kompliziert war, selbst so einfache Dinge zu tun, wie eine Beispiel-Datei zu laden.


    Zitat von Snoopy

    Heute sind wir schon froh, wenn wir am Morgen nach dem Aufstehen noch unseren Namen wissen.

    Da hast du natürlich auch recht. ;) Aber in meinen aktuellen Fällen weiß ich die Dateinamen überhaupt nicht, weil ich keine von mir erstellten Daten laden wollte, sondern x-beliebige (hoffentlich mitgelieferte) Beispieldateien. Und dann wählt man hoffnungsvoll den Menüpunkt "Laden" und bekommt ein schlichtes "Prompt". :grr:

    Bin mir nicht sicher ob das als "Anwendungsprogramm" zaehlt, aber der Level-Editor von Shadow Switcher (ins Spiel integriert) bietet eine "Show Directory"-Funktion, wenn er nach der Eingabe des Dateinamens fragt ;)


    Ich koennte mir uebrigens vorstellen, dass das langsame Laden der Diskettenlaufwerke ein Grund dafuer ist. Das ist auch der Grund, warum ich diesen Punkt optional eingebaut habe. Denn wenn jemand eh schon genau weiss, welchen Dateinamen er gleich eingeben will, dann ist es evtl. laestig, wenn er erstmal warten muss, bis das Directory geladen wurde.

    Zitat von Retrofan

    Ich kann den vorhandenen Anwendungen ja schlecht neue File-Requester unterjubeln.

    Theoretisch schon ... aber ob das den Aufwand lohnt ist ne ganz andere Frage :)

    Zitat von ZeHa

    Ich koennte mir uebrigens vorstellen, dass das langsame Laden der Diskettenlaufwerke ein Grund dafuer ist. Das ist auch der Grund, warum ich diesen Punkt optional eingebaut habe.

    Das klingt nach einer sehr vernünftigen Begründung. Richtig komfortabel wäre es, wenn man, nachdem man sich sowieso schon fürs directory laden entschieden hat, darin navigieren und ein file auswählen könnte ;)

    Zitat von Zirias/Excess

    aber ob das den Aufwand lohnt ist ne ganz andere Frage

    Das ist halt der Punkt, es ist ja nicht die Ausnahme, sondern eher die Regel, dass es so etwas nicht gibt.


    Ich wollte hier ja auch nur, wie anfangs gesagt, Dampf ablassen – und andererseits auf das Problem hinweisen, damit das bei zukünftigen Apps vielleicht berücksichtigt wird.


    Zitat von ZeHa

    der Level-Editor von Shadow Switcher (ins Spiel integriert) bietet eine "Show Directory"-Funktion, wenn er nach der Eingabe des Dateinamens fragt

    Das ist ja schon ein ausreichend großer Komfort-Gewinn, wenn das in einem gemeinsamen Dialog stattfindet und man nicht aus "Laden" erst wieder heraus muss, um nach einer "Directory"-Funktion zu suchen.

    Ja, da man zum "Laden" ja nur eine einzige Zeile braucht, dachte ich mir, da ist noch genug Platz auf dem Bildschirm :D


    EDIT: Uebrigens verwendet mein Spiel auch den Standard-Font, d.h. die gesamte GUI (sehr schoen ist z.B. auch der "Hilfe"-Screen im Level-Editor) wird dann auch in Deinem Font gerendert.

    Zitat von ZeHa

    Uebrigens verwendet mein Spiel auch den Standard-Font, d.h. die gesamte GUI (sehr schoen ist z.B. auch der "Hilfe"-Screen im Level-Editor) wird dann auch in Deinem Font gerendert.

    Sehr löblich. ;) Aber nicht nur wegen meines Font, wie einige vielleicht meinen könnten, sondern weil ich es mag, wenn eingebaute Systemfunktionen verwendet werden. Beim C64 sind das nicht so viele – aber das CharROM ist halt so eine "Konstante", die von vielen Programmen verwendet wird. Ich fand es in den 90ern auch nicht gut, wenn Atari ST- oder Amiga-Programme selbst gestrickte GUIs hatten, statt die eingebauten Systemfunktionen zu verwenden. Letztere sorgten oft dafür, dass Programme noch liefen, wenn z.B. ein Monitor eine andere Auflösung oder Farbtiefe besaß. Die selbst gestrickten GUIs versagten dann meistens.

    Selbstgestrickte GUIs sind/waren generell ein Graus, auch z.B. unter Windows ;) z.B. die Tools die bei Digitalkameras dabei waren oder solche Sachen... da funktioniert dann nix so wie man es aus anderen GUIs erwartet. Aber gut, wir schweifen ab...

    Das Konzept eines Dateiauswahl-Requesters dürfte vielen Leuten in der ersten Hälfte der Achtziger gar nicht oder zumindest nicht im Detail bekannt gewesen sein. Bis der durchschnittliche Programmierer so etwas bei GEOS oder auf einem ST bzw. Amiga bestaunen konnte, war es locker bereits 1986/1987 - Neuentwicklungen - wo man so etwas von Anfang an hätte berücksichtigen können - gab's danach ja nicht mehr so viele, zumindest was "große" Anwendungen angeht.


    Da es keine fertigen Routinen gibt bzw. gab steht der Programmierer vor der Wahl das entweder selbst zu implementieren, oder es eben so zu machen wie alle anderen auch. Da die meisten Anwendungen ansonsten keine Menü- oder Dialogtechniken einsetzen, hätte man sämtliche notwendigen Techniken (Cursor-Auswahl, Scrolling oder seitenweises Blättern, Diskwechsel usw.) ausschließlich für den Datei-Requester benötigt - und dem Benutzer auch noch erklären müssen, wie das Ding benutzt wird. Oder man nimmt einfach die Directory- und Input-Routinen, die man eh herumliegen hat und macht was alle anderen machen.


    Ein sehr gutes Beispiel wie man so etwas implementieren kann, sind übrigens Startexter und Stardatei: Die haben die Cursor-Menüs, die sie für die umfangreichen Einstellungen eh schon eingebaut hatten, mit einer Verzeichnis-Anzeige und einer Input-Routine kombiniert und so den komfortabelsten Datei-Requester gebaut, den ich in einem C64-Text-UI gesehen habe - der allerdings etwas anders funktioniert als man das erwarten würde (Startexter ist von 1985). Und Startexter hat einen deutlich kleineren Textspeicher als die Konkurrenz, trotz gleichem oder gar geringerem Funktionsumfang: Startexter: 20 KB, VizaWrite: 34 KB.

    Zitat von Korodny

    Das Konzept eines Dateiauswahl-Requesters dürfte vielen Leuten in der ersten Hälfte der Achtziger gar nicht oder zumindest nicht im Detail bekannt gewesen sein.

    Eine systemeigene Dateiauswahl dürfte wahrscheinlich in "freier Wildbahn" zuerst der Mac (bzw. die Lisa) gehabt haben. Wem der schon exotisch vorkam, der war sicherlich nicht im Xerox PARC, um sich sowas mal als Prototyp anzugucken. Also kann man davon ausgehen, dass bis Mitte der 80er solche Konzepte eine Art Geheimwissen waren.


    Aber wie sah es eigentlich mit proprietären File-Requestern einzelner Programme aus? Gab es da z.B. was brauchbares in Word, WordPerfect, DBase etc. unter DOS?


    Auf jeden Fall kann man an solchen "Kleinigkeiten" sehen, was man am programmübergreifenden GUI-Konzept so hat, das geht über Fenster und Maus-Bedienung weit hinaus.


    Zitat von Korodny

    Ein sehr gutes Beispiel wie man so etwas implementieren kann, sind übrigens Startexter und Stardatei

    Das gucke ich mir mal genauer an.


    Zitat von Matthias

    Schöner Font!

    Danke. Kann man hier herunterladen.

    Zitat von Zirias/Excess

    ... Richtig komfortabel wäre es, wenn man, nachdem man sich sowieso schon fürs directory laden entschieden hat, darin navigieren und ein file auswählen könnte

    Der Grund ist: Damals kannte noch keiner Windows (auch nicht den Mac), haben nur in Dos 'rumgemacht = da war das od. ähnliches eben noch normal. Da schrie keiner nach dem Luxus heutiger Köpfe.

    Und zweitens wäre so eine o.g. Funktion in den paar KB des C64 (damals waren sie noch nicht so effizient oder sonst 'was, wie die heutigen Profis mit auch viel mehr Entwicklungs-Möglichkeiten hier..) fast so groß wie ein eigenes Programm geworden (also kein Platz für das eigentliche Programm mehr übrig, auf das es 'damals' auch nur ankam).


    (Die wussten sicher nichmal wie man das überhaupt macht, in Maschinensprache ist so 'was ja auch gleich 'mal um einiges schwieriger mit Dateinamen-Auswahl, dann laden des markierten. U. ggf. auch das buglose rückspringen re-verschmelzen mit dem eigentlichen 'dahinter liegenden' Programm. Der oben gezeigte 68000er Mac ist ja auch eine ganz andere Architektur, da fällt das sicher irgendwo u. spätestens insg. leichter. Mehr Speicher hat er auch.)

    Dazu fielen mir drei Gründe ein:

    1.) (s. ZeHa) Das sehr langsame Laden des Verzeichnisses. Ein C64typisches Problem.

    2.) (s. Korodny) Die Idee eines Dateirequesters war erst recht spät bekannt, nachdem es auf Rechnern mit Bitmapgraphik der breiten Allgemeinheit vorgeführt wurde. Nicht alle Softwareentwickler hatten die Möglichkeit bei Xerox vorbeizuschauen und sich von der Forschungsabteilung inspirieren zu lassen. Für die meisten galt, daß sie entweder Autodidakten waren und auf dem Zielgerät (in der Regel ein Homecomputer) oder einem vergleichbaren gelernt und dabei Konventionen übernommen haben. Oder sie hatten auf einem Großrechner gelernt und damit Kontakt zu textbasierten Terminalausgaben und "Befehlsaufforderungen". Wenn man mit solchen Sachen groß geworden und daran gewöhnt ist, fällt es schwer, sich etwas komplett Neues auszudenken, besonders dann, wenn einem für die Entwicklung eines neuen Features kaum Zeit und Resource (Speicherplatz, Prozessorzeit) bleibt (s.u.).

    Für eine verspätete Verwendung eines Dateirequesters kann u. U. auch gesorgt haben, daß die Anfang der 80er noch übliche Terminalausgabe schlicht sehr langsam und wenn überhaupt nur mit speziellen Steuerbefehlen für einen Dateirequester benutzbar ist. (Für ein Blättern durch das Verzeichnis muß ein Textfenster erzeugt, gelöscht, eventuell gescrollt und der Cursor beim Schreiben in diesem Fenster frei plaziert werden.) Als ein Beispiel und eine Zwischenstufe in der Benutzerführung kann vielleicht das UCSD-Pascal gelten. Hier wurden Programme wie der Compiler oder der Texteditor ganz ohne Befehlseingabe (wie z. B. bei CP/M) mittels einfachem Tastendruck aufgerufen. Daneben gab es ein Programm namens "Filer", welches die Dateiverwaltung übernahm und welches ebenfalls per Tastendruck gesteuert wurde. So konnte man mittels "L" ein Verzeichnis ausgeben und mit "D" eine Datei löschen. Aber auch hier gab es keinen Dateirequester. Theoretisch hätte man bereits den "Filer" so organisieren können, daß er ein Verzeichnis einliest (beim AppleII sehr schnell), am Bildschirm anzeigt, eine Datei mittels Pfeiltasten auswählen läßt und dann per Tastendruck wie gehabt bearbeitet. Dies scheiterte aber daran, daß die Textausgabe auf dem Bildschirm terminalbasiert war, nicht über die nötigen Steuercodes verfügte und an sich sehr langsam war. In klassischen textbasierten Anwendungen war ein Dateirequester also meistens nicht bekannt, aber auch technisch nicht gut umzusetzen. Das änderte sich erst, als Einzelplatzrechner groß und schnell genug waren und über eine frei ansteuerbare Bitmapgraphik verfügten.

    3.) Auch für die Programmierung auf dem C64 gab es handfeste Gründe, warum Programmierer sich nicht darum gekümmert haben. Neben dem genannten Zeitdruck in der Entwicklung oder dem großen Speicherplatzverbrauch gab es auch Probleme beim Programmieren selbst.

    a) Das Verzeichnis muß per Kernal geladen werden. Das schließt oftmals den Gebrauch von Schnelladern aus. Zusätzlich muß ein eigener IRQ ab- und das Kernal-Rom eingeschaltet werden. Nach dem Laden muß entsprechend zurückgeschaltet werden.

    b) Auf eine normale Diskette passen 144 Dateien. Benötigt beim Senden des Verzeichnisses eine Datei im Durchschnitt 16 Bytes für ihre Daten, kommt man so auf 144 * 16 = 2304 Bytes ~ 2,25 KB. Ein Dateirequester muß also im Speicher einen großen Puffer bereitstellen, um überhaupt die Verzeichnisdaten aufnehmen zu können. Wird hingegen das Verzeichnis auf dem Bildschirm direkt beim Laden einfach nur runtergescrollt, wird ein Puffer nicht benötigt.

    c) Die Verzeichnisdaten werden vom Laufwerk strukturell nicht einheitlich (größengleich) rübergeschickt, sondern in einem freien Format, so daß der Programmierer sich die gewünschten Daten (Name oder mehr) aus dem Datenstrom heraussuchen muß.

    d) Das Schlimmste dürfte aber sein, daß zur Weiterbehandlung der Daten Stringoperationen und neue Bildschirmroutinen notwendig sind. Eine Vorgehensweise sieht z, B. so aus: Das Programm lädt das Verzeichnis, fischt sich dabei die Dateinamen heraus, speichert sie in einem Puffer und merkt sich für jeden Namen die Anfangsadresse in einem Array (getrennt für Low- und Highbyte der Adresse). Dieses Array braucht dann nochmals 144 * 2 Bytes. Dann muß man einen Teil dieser Strings je nach Größe des Anzeigefensters untereinander ausgeben. DIe Ausgabe per Kernal-COUT ist dafür zumeist ungeeignet, da sie bei der Speicherbelegung des eigenen Programms stört (Zeropage oder auch $200..$3ff sowie Textbildschirm oder Farbram) oder sich nicht mit der eigenen Grafik verträgt. Für einen Programmierer heißt dies, daß er nur für den Dateirequester auch eine komplett neue Zeichenausgabe entwickeln muß.

    Rechnet man allein den Speicherverbrauch zusammen für Puffer und Programm, so kommt man auf (grob geschätzt) 3 Kilobyte. Dazu gesellt sich der Programmieraufwand allein für den Requester, der ja mit dem eigentlichen Programm nicht viel zu tun hat. Daß unter diesen Voraussetzungen Programmierer damals (wie heute) kaum Lust verspüren, sich damit auseinanderzusetzen, ist auch im Nachhinein nachvollziehbar.

    Ich hatte schon länger mal überlegt, den Dateiauswahldialog den ich ich diversen Tools einsetze mal als konfigurierbare Library zur Verfügung zu stellen. Das würde es zumindest für neue Programme leichter machen, mehr Komfort zu bieten. Hach, der Tag müsste 48h haben...

    GoDots Filerequester braucht rund 500 Bytes Code (plus Darstellung für Fenster und Buttons), der Lesepuffer hat 256 Bytes, der Filenamenspeicher ist der Bildschirmspeicher selber (die Anzeige). Das hört sich nicht so unmöglich an wie in Post #15. ;-)


    Arndt

    In meinen Crazy Light Tools habe ich mir einen gewissen Komfortstandard schon gesetzt. Dazu gehören Maussteuerung und Dateiauswahldialoge. Der nennt sich dort "Directory deluxe" bzw. "Inhaltsverzeichnis deluxe". Die ganze Directory zu laden, ist auf dem C64 gewiss keine sinnvolle Option, weil das ordentlich auf den Speicher gehen würde, und da es nicht nur die 1541 gibt, können das durchaus weit mehr als 144 Einträge sein. Deswegen lade ich sie seitenweise ins Screen-RAM, und man kann dann auf "weiter" klicken, oder auf einen Dateinamen. Bei letzterem erscheint ein Popup-Menü, wo man zwischen Laden, Umbennen und Löschen wählen kann. Bei zu großen Dateien wird das Laden zudem unterbunden, um Overflows im Programm zu vermeiden. Zugegebenermaßen ist das nicht in allen Tools konsequent implementiert, aber Laden geht immer.

    Mehrere Laufwerke war auch mal vorgesehen, ist aber rausgeflogen, weil mir durch die Verfügbarkeit vorhandener Massenspeicher der Komfort auch so gegeben schien, und der Aufwand diese Routinen zu debuggen daher eher nicht mehr.

    Zitat von Retrofan

    Wählt man einen Menüpunkt, wie "Laden" o.ä., wird man meistens mit einer schnöden Aufforderung abgespeist, doch bitte aus dem Kopf den gewünschten Dateinamen einzugeben

    Offenbar haben die Dolphin DOS-Entwickler diesen Mangel auch bemerkt und deswegen CTRL-D mit Directory anzeigen belegt. Das funktioniert immer, wenn ein Programm die Eingabe über das KERNAL macht.