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

letzter Beitrag von C=Mac am

Delco Videoarchiv-System (C128)

  • Im 128'er Sonderheft 22 von Markt & Technik ist auf Seite 119, das Videoarchiv-System Delco abgedruckt.


    Dieses Programm habe ich schon seit Jahren.


    Laut Programm-Info:


    - V 2.21D
    - Programmiert von Detlef Erdmann, 3502 Vellmar
    - © 1987 by Markt + Technik


    Fragen:


    - Gab es davon jemals eine neuere Version?


    - Gibt es noch weitere, vergleichbare Programme für den C128, auch unter GEOS?


    Gruss C=Mac.

  • Ich wollte schnell einen Blick darauf werfen, aber mein Diskimage zu SH22 enthält das Programm nicht: Das Directory von Seite A sagt am Ende "Rückseite bespielt! Bitte wenden" und auf Seite B liest man ziemlich weit unten: "Das Programm Video-Archiv befindet sich auf Disk 2".
    Naja, und ein weiteres SH22-Diskimage hab ich nicht. Im gedruckten Heft wird auch nur auf die Bestellmöglichkeit für eine Heftdisk hingewiesen.


    Laut Text und Listing im Heft ist das ein Basic-Programm mit einer sequentiellen Indexdatei und einer REL-Datei.
    Falls Du eine neue Version suchst, weil die alte verbuggt ist, kann man sich am Basic-Code vergreifen. ;)
    Vergleichbare Programme? Naja, allgemein verwendbare Datenbanken halt...

  • Ob ich damals :D die Disketten gekauft habe oder den Weg des abtippen gegangen bin weiss ich nicht mehr.



    Laut Text und Listing im Heft ist das ein Basic-Programm mit einer sequentiellen Indexdatei und einer REL-Datei.

    Richtig ;)



    Falls Du eine neue Version suchst, weil die alte verbuggt ist, kann man sich am Basic-Code vergreifen.

    Wenn man auch nur die geringste Ahnung von Programmieren hätte, wäre dies möglich.
    Somit bin ich raus.
    Programmieren, äh ja hab ich auch schon gehört :whistling:



    Vergleichbare Programme? Naja, allgemein verwendbare Datenbanken halt...

    Hab mal probiert sowas mit GeoFile zu machen, aber für sowas bin ich schon zu doof.



    Jetzt schon.

    Danke :thumbup:


    Gruss C=Mac.

  • Jetzt schon. :)

    Danke. Ein erster Sehrkurztest im Emu ergibt: Hübsch anzusehen, aber erschreckend langsam, selbst im Menü und bei Texteingaben. Der Programmierer wird doch nicht etwa absichtlich den Tastaturpuffer sabotiert haben?!

  • Bei derart langsamen Programmen sollte man sogar den Tastaturpuffer umgehen, sonst haut der Anwender seine Tasten rein, sieht keine Reaktion, tastet nochmal, und wenn die Kiste wieder zu sich kommt darf er erstmal minutenlang tatenlos zusehen wie der Rechner das alles abarbeitet- unerwünschterweise und ohne saubere Möglichkeit dem Treiben Einhalt zu gebieten...

  • Bei derart langsamen Programmen sollte man sogar den Tastaturpuffer umgehen, sonst haut der Anwender seine Tasten rein, sieht keine Reaktion, tastet nochmal, und wenn die Kiste wieder zu sich kommt darf er erstmal minutenlang tatenlos zusehen wie der Rechner das alles abarbeitet- unerwünschterweise und ohne saubere Möglichkeit dem Treiben Einhalt zu gebieten...

    Bei einem Programmteil, der tatsächlich "etwas tut", stimme ich Dir sofort zu - in MacBootMake wende ich das selbst an einigen Stellen an.
    Aber im vorliegenden Fall kann man nicht einmal per direkt hintereinander getipptem "down, down, right" schnell durch das Menü navigieren, das ist etwas nervig...

  • Ich hab' mir das Programm mal gerade angeschaut.


    Die beiden Menü-Routinen ab 36000 (vertikales Menü) und 36500 (horizontales Menü) sind besonders 'sportlich'. Beide printen jedesmal das komplette Menü neu aus und schalten ggfs. den ausgewählten Menüpunkt auf invers.


    Der Knüller steht aber in Zeile 36520 - da wird eine Leerschleife von 1 bis 500 durchlaufen. Nun ja, ganz am Anfang des Programms steht ja dann die Empfehlung, es mit Austro-Comp zu kompilieren. :whistling: Ohne diese FOR-Schleife war das Kompilat dann wohl zu schnell. ;)


    Auch daß die Eingaberoutine so weit hinten ab Zeilennummer 40000 steht, macht sie nicht schneller sofern das Programm nicht kompiliert wurde.


    Und ja: der Tastaturpuffer wird in Zeile 535 auf ein Zeichen reduziert.




    Edit: auf der Disk ist ja auch noch die Datei "VIDEOARCHIV.COMP" ... hmm ... wollte es ja nur mal anmerken ... vielleicht ...

  • der Tastaturpuffer wird in Zeile 535 auf ein Zeichen reduziert.

    Danke, das hatte ich noch gar nicht gesehen. Die Menüs wären aber wohl auch ohne diesen POKE so langsam, denn es wird zwar erst aus dem Tastaturpuffer gelesen, aber dieses Zeichen dann verworfen und stattdessen mit der Nummer der aktuell gedrückten Taste gearbeitet:

    Code
    1. 36110 if joy(2)<>0 then 36130
    2. 36120 get t$:if t$="" then 36110
    3. 36130 t=peek(212):[...]
    4. [...] if t=84 or joy(2)=4 or joy(2)=5 or joy(2)=6 then [...]
    5. [...] if t=83 or joy(2)=1 or [...]


    Könnte man alles "schön" machen, aber wegschmeißen und neu schreiben wäre wohl weniger Arbeit. ;)

  • Aber im vorliegenden Fall kann man nicht einmal per direkt hintereinander getipptem "down, down, right" schnell durch das Menü navigieren, das ist etwas nervig...

    Etwas nervig ........ sehr diplomatisch ausgedrückt ^^



    Edit: auf der Disk ist ja auch noch die Datei "VIDEOARCHIV.COMP" ... hmm ... wollte es ja nur mal anmerken ... vielleicht ...

    Und das sagst Du erst jetzt :D
    He das Programm kann ja ganz normal bedient werden, ohne dauernd zu warten.
    Und auch die Sortierung am Schluss ist plötzlich recht fix.



    Könnte man alles "schön" machen, aber wegschmeißen und neu schreiben wäre wohl weniger Arbeit.

    Betonung auf "könnte".
    Wenn man es den könnte ;)


    Ich geh mal davon aus, es gab nie eine überarbeitete Version des Programms?
    Dieses ist die einzige Version vom Erdmann.


    Gruss C=Mac.