012
08.10.2007, 19:58 Uhr
Rüdiger
Administrator
|
| Zitat: | Z1013 schrieb
ok, das wars dann wohl. Ich hab keine Lust noch eine neue Programmiersprache zu lernen.... war wohl doch ne Schnapsidee, obwohl ich kein Alkohol getrinkt  habe |
Du gibst ja schnell auf...
Schauen wir uns doch mal das Thema im Detail an:
a) Bildschirm:
-Die meisten Rechner kännen 80x24 Zeichen darstellen (außer A5120 mit K7023). Bei 64x16 müssten alle Bildschirmfunktionen geändert werden.
-Der 1715 kann als Sonderzeichen dank seines Bildschirmcontroller Rahmensymbole darstellen. Beim A5120 müsste man stattdessen auf "+--+" zurückgreifen
-Wir könnten das INTES-Signal nutzen zur Kennzeichnung markierter Dateien. Beim A5120 unterstützt die K7024 das INTENS-Signal, aber nicht die K7023.
-Wir könnten das INVERS-Signal nutzen als Rollbalken. Beim A5120 unterstützen nicht alle K7024 ein INVERS-Signal.
b) Eingabe
-Tastatur mit Cursortasten wäre kein Problem
-Maus können wir weglassen
c) Die Dateilisten
-Kurzliste wäre möglich
-Detailliste wäre möglich (nur Dateinamen und Dateigröße. Datum gibt's ja nicht)
-Verzeichnisbaumanzeige ist Unsinn bei SCP
-Beim rollbalkenorientierten Programm müssten wir die Dateilisten im RAM halten.
Eine Diskette kann bis zu 255 Dateien haben.
Damit wäre der Speicherbedarf für 2 Listen: 2x 255 Dateien x 8+3 Byte Dateinamen + 2 Byte Dateigröße + 1 Byte Markierung = 7140 Byte. Das ist natürlich eine ganze Menge.
-Sortieren der Listen wäre kein Problem (Kriterien: unsortiert, nach Dateinamen, nach Größe)
d) "Textbetrachter"
brauchen wir nicht, könnte man den Editor dafür nehmen oder ggf. die TYPE-Funktion vom SCP aufrufen.
Schön wäre allerdings die Möglichkeit einer HEX-Anzeige...
e) "Editor"
Der ist relativ aufwendig zu schreiben.
Sein Datenspeicher muss so groß sein, wie die größte zu erwartenden Datei, realistischerweise 16 kByte.
f) "Kopieren"
Das Kopieren von (binären) Dateien geht blockweise.
Um die Geschwindigkeit hoch zu halten (wenig wechselnde Floppy-Zugriffe), sollten die Blockgröße mindestens 5 kByte sein.
g) "Umbenennen"
Sollte kein Problem sein.
g) "Bewegen"
=Kopieren + nachfolgendes Löschen, ist fast kein Mehraufwand
h) "Verzeichnis erstellen"
ist Unsinn bei SCP
i) "Löschen"
Sollte technisch kein Problem sein.
j) "Laufwerk wechseln"
Sollte technisch kein Problem sein.
k) Programme starten
Die einige realistische Chance ist, den Commander zu beenden, dann das Programm per SUB-Datei zu starten und nach dessen Beendigung per SUB-Datei den Commander neu zu starten.
l) "Datei suchen"
Da es nur 1 Verzeichnis gibt, können wir das weglassen
m) "Stapel-Markierung"
Sollte technisch kein Problem sein.
n) "Laufwerksstatus-Anzeige"
Sollte technisch kein Problem sein.
o) Online-Hilfe
Ist nicht notwendig, Könnte ggf. durch Aufruf einer speziellen Textdatei im Editor erfolgen.
p) Speicherplatzbedarf
-Grob addiert sind wir bei 28 kByte Daten, zuzüglich aller normaler Variablen.
q) Performance
-Nach jedem Start von Programmen müsste der Commander neu geladen werden. Wenn keine RAM-Disk (PC1715W, MPC, K8924, A5120.16) dazu zur Verfügung steht, dauert das ziemlich lange
-Zeitkritisch könnte das Sortieren der Dateilisten werden.
-Möglicherweise auch performncekritisch die Bildschirmaktualisierung der Dateilisten (ca 20 Zeilen bei jedem Curortastendruck)
r) Hardwareanpassung
-Wir werden wohl nicht herum kommen, den Rechnertyp per Menü auswählbar zu machen, speziell wegen der unterschiedlichen Bildschirm-Fähigkeiten.
s) Laufwerkstypen
-Sollten eigentlich keinen Einfluss haben. Eventuell wäre über eine Diskettenwechsel-Erkennung nachzudenken (Aktualisierung der Dateilisten)
t) Betriebssystem:
-Sollte eigentlich keinen Einfluss haben.
Als Programmiersprache würde ich persönlich PASCAL vorziehen. Ich finde, es programmiert sich besser damit.
Unter DCP würde ich für das Schreiben so eines Commanders ca. 1 Woche brauchen, unter SCP fehlt mir da die Erfahrung.
--
Kernel panic: Out of swap space.
Dieser Beitrag wurde am 08.10.2007 um 20:23 Uhr von Rüdiger editiert. |
