Hallo Besucher, der Thread wurde 3,5k mal aufgerufen und enthält 11 Antworten

letzter Beitrag von Mike am

Aufrüstsatz mit mos VIC 6562 für VC-20 um auf VIC-40-Fähigkeiten (40 Zeichen breiter Bildschirm) zu kommen?

    Hallo,
    auf Secret Weapons of commodore las ich, dass es mal geplant war, dass Commodore Aufrüstsätze für den VC 20 rausbringt.
    Es gab ein geändertes Editor-ROM und einen "neuen" Videochip (manchmal VIC 1.5 genannt) mit Datenblatt...
    Link:
    http://www.floodgap.com/retrobits/ckb/secret/vic40.html


    und das wurde überlegt, als das Projekt "VIC 40" als Nachfolger des VIC 20 am Anrollen war, wurde aber auf Eis gelegt, als der C64 am Entstehen war.


    Kernpunkt des Aufrüstsatzes war dieser Videochip, der den arg beengten Bildschirm 22 Zeichen x 23 Zeilen überwand und 40 * 25 bieten sollte.
    Eigentlich eine hochspannende Angelegenheit.


    Leider ist auf der genannten Seite kein Datenblatt zum MOS 6562 (NTSC-Version) bzw. 6563 verlinkt.
    Immerhin gibt es eine Nahaufnahme von dem Chip und irgendwo ist auch ein Prototyp abgebildet.
    Dieser Rechner wäre dann ein "Missing link" zwischen VC 20 und C64.


    Hat sich schonmal jemand von euch mit der Thematik befasst?

    Im Denial-Forum gab's dazu vor einem Jahr mal einen Thread, mit einem Link auf ein ca. 4,6 MB großes *.pdf-file:


    [ ... Tja. Dann gibt's hier eben keinen Link. Hast PM ]


    Ansonsten gibt's da relativ wenig zu zu sagen. Der 6562 hätte entweder genauso die Badlines gebraucht wie der VIC-II im C64, oder ein doppelt so schnelles RAM-Subsystem. Für beides war die Hardware des VC-20 nicht vorbereitet - die Aufrüstidee mußte man von daher schon abschreiben.


    Es gab noch einen anderen Prototypen, mit einem 6566 SRAM VIC-II - über glue-Logik an DRAM angebunden. Aus dem wurde dann wohl später die Ultimax-Maschine:



    ...


    Der VC-20 kriegt aber auch im Originalzustand brauchbar lesbare 40 Zeichen/Zeile in einer 160x192 Bitmap hin. ;)

    Beim Durchlesen des Dokuments


    :platsch:


    ... wenn man schon die Bildschirmbreite auf 40 erweitert ... muss man dann unbedingt bei 23 Zeilen bleiben? Es ist auch die Rede von 920 Character-pointern.... nunja .. daran sieht man die etwas halbherzige Umsetzung.


    (Bei der Überlegung, was heute mit diesem Design anzustellen wäre, würde aber die RAM-Zugriffszeit weniger eine Rolle spielen. Es würde bei mir zumindest auch noch als retro-authentisch (TM) durchgehen, wenn so ein Design 120 ns RAM erforderte .. schließlich waren mein C 116 und 128 beide mit derart "schnellen" Bausteinen bestückt und es ist somit "historisch verbürgt".)


    Edit: heisst das zugehörige Grafik-Framework rein zuufällig "MINIGRAFIK"? :D

    Der 6562/63 läßt auch eine von 23 Zeilen verschiedene Anzahl Zeilen zu. Siehe Register CR2. ;)


    Zitat von Stephan

    heisst das zugehörige Grafik-Framework rein zuufällig "MINIGRAFIK"?

    Wenn die 40 Zeichen/Zeile *schnell* sein sollen, ja.


    Ansonsten gab's damals™ schon Bildschirmeditoren mit 40 Zeichen/Zeile (etwa FAT-40 oder Petloader). Mit dem Single-Character-API des KERNALs gab's da aber keinen Geschwindigkeitsrausch.

    Dieser Videochip *ist* das VIC-40-Projekt (und geht auf einen 'quick-and-dirty'-Fix aus dem Jahr 1979 zurück, als Jack Tramiel einen Apple-II-Killer haben wollte). Die technischen Probleme wurden ja schon genannt: Der Rechner hätte mit 1,8 MHz laufen müssen, das gibt die Hardware nicht unbedingt her, und der Austausch des Quarzes hätte einen Besuch in der Werkstatt erfordert. Damit war das bilige Aufrüst-Kit also schonmal gestorben. Der VIC-40 als 'richtiger' Computer ist an etwas ganz anderem gescheitert: Das Marketing und die ganze Heimcomputer-Abteilung von CBM hatte keinerlei Interesse an einem Nachfolger für den VC20. Man hatte es ja am Atari VCS gesehen- das lief seit vier Jahren unverändert gut (der große Crash kam erst zwei Jahre später, die letzten VCS-Konsolen gingen Anfang der 90er über den Ladentisch...) und von daher wurden die VIC-40-Leute mehr als schräg angesehen.


    Und *das* ist der Grund, warum die Jungs sich mit dem Rest des Entwicklerteams um Chuck Peddle zusammentaten (der grad zum zweiten Mal CBM verlassen hatte) um deren Idee eiens 'Super-Arcade-Chipsatz' neu aufzusetzen- was dann zum VIC und SID führte. Das andere wäre der 6564/6565 geworden, alias TOI, gestartet als Apple-II-Killer -genau der von eben, der mit dem gepimpten VIC vorgestellt wurde,. weil das TOI-Dingen keine vorzeigbaren Ergebnisse zeigen konnte- und 'irgendwie' zum Videogame-Kern mutiert mit vielen wilden Ideen, aber derart komplex daß nix bei rum kam- was natürlich nicht besser wird wenn Peddle das halbe Entwicklerteam mitnimmt...


    Und die Platine da oben ist tatsächlich der allererste C64- entstanden aus Verzweiflung, weil der schöne neue VIC-SID-Chipsatz zum einen in einem Videospiel namens Ultimax landen sollte, daß mangels Speicher noch nichtmal einen vollen Hires-Screen darstellen konnte, und zum Anderen in einem Bürocomputer namens CBM-II/ PET-II (alias B-500 alias B-128 alias CBM 510/610/720 alias...) der völlig über-ambitioniert war und eigentlich auch nicht unbedingt eine Arcade-Hardware brauchte. Deswgen sind die Jungs kurz vor Thanksgiving 1981 zu Jack Tramiel gegangen und haben ihren 'Consumer Computer' vrogeschlagen, schlank und preiswert wie der VC-20 (oder auch der VIC-40) aber mit 16K oder gar 64K. Und Tramiel hat genau gewußt, daß bis zur Marktreife so eines Rechners 16K völlig out sein würde- deswegen hat der besagte Prototyp von Anfang an 64K RAM gehabt (kann man an den Leiterbahnen sehen) obwohl der Videochip nur 16K nutzen kann. Und man hat ganz offensichtlich auf das BASIC des VIC-40 zurükgreifen können (was nahelegt, daß die PLA in diesem Ur-64er dsa ROM an eine andere Adresse gemappt hat) und auch am Videochip kann man sehen, daß noch etliche vom VIC-40 geerbte EIgenschaften drinstecken- so gibt es nur einen einzelnen Takt (mit dramatischen Problemen in der Video-Darstellung) und noch keinen gemultiplexten Bus. Auch das gerade von CBM Japan eingeführte neue Netzteil mit 9V und 5V Spannung hat er noch nicht. Und wenn man sich die Schaltpläne genauer ansieht, hat es tatsächlich im April 1982 eine kompletrte Überarbeitung des C64 sowie des Ultimax gegeben- vermutlich ist auch da erst die Atari-ähnlöiche Speicherbelegung zustande gekommen.


    Und damit erklärt sich auch, warum in den Serien-Versionen des VIC 6566 (SRAM-Version) die Elektronik für den gemultiplexten Adreßbus der DRAM-Version enthalten ist (das Frühjahrsrätsel 2017 auf CBM-Hackers): Wenn man eh gezwungen war den ganzen Chip nochmal auf links zu drehen hat man es nur *einmal* getan und die Varianten mit geringstmöglichen Änderungen aus einer gemeinsamen Grundlage abgeleitet.

    Vielen Dank für deine und euren Statements ... vermutlich ist es dem Willen zur Knappheit zurückzuführen, dass deine Antwort manches nur verkürzt darstellen konnte, obwohl viel mehr dahintersteckt ..

    Zitat von mc71

    Die technischen Probleme wurden ja schon genannt: Der Rechner hätte mit 1,8 MHz laufen müssen, das gibt die Hardware nicht unbedingt her, und der Austausch des Quarzes hätte einen Besuch in der Werkstatt erfordert.

    Also in meinem VC-20 befand sich seinerzeit "ab Werk" eine 6502A-CPU. Also eine 2Mhz-Version. Da die Takterzeugung defekt war (Aussetzer), musste ich das Teiler-Flipflop auswechseln und einen Sockel einbauen. ich hatte diese Teilerstufe probeweise weggelassen - Eingang und Ausgang probeweise im Sockel gebrückt - , et voila, der Rechner lief mit 2,2 Mhz problemlos! und das trotz uralt-Platinenrevision mit lauter 2114-RAMs.


    Sogar der 1901-Monitor synchronisierte, wenngleich auf einer "oberwelle" des VSYNC-Signals (und zeigte das interlace-artig aufgeteilte Bild auf 4 Kacheln neben /übereinander an), und die Datasette speicherte mit doppelter Geschwindigkeit.


    Ich hätte vermutlich den 6502 in einen weiteren Sockel mit Quarz gesteckt "und fertig ist der Lack" - bei der Hires-Grafikkarte für den CBM-Pet-Rechner 8296 waren m.W. auch mehrere Zwischenstecker im Spiel....

    Zitat von mc71

    Das Marketing und die ganze Heimcomputer-Abteilung von CBM hatte keinerlei Interesse an einem Nachfolger für den VC20

    Warum eigentlich? Ohne eine Begründung ist dieses Argument in keiner Weise nachvollziehbar (wäre eine Art Passepartout-Argument.... a la: "Warum wurde PAULA nicht in der Floppy 1571 eingebaut ? - Antwort: Commodore hatte kein Interesse daran...")

    Zitat von mc71

    was dann zum VIC und SID führte. Das andere wäre der 6564/6565 geworden, alias TOI, gestartet als Apple-II-Killer -genau der von eben, der mit dem gepimpten VIC vorgestellt wurde,.

    Ich verstehe nicht... wenn der 6564 "das andere" (the other..) geworden wäre, dann kann er doch nicht gleichzeitig "genau der von eben" sein, welcher doch der 6562 wäre !?

    Zitat von mc71

    Und man hat ganz offensichtlich auf das BASIC des VIC-40 zurükgreifen können (was nahelegt, daß die PLA in diesem Ur-64er dsa ROM an eine andere Adresse gemappt hat)

    Gibt es dafür irgendwelche offen zugänglichen "Gleichungen" (PLA ausgelesen) oder Belege? Das Basic V2 so (binär) umzupatchen, dass es an der neuen Adresse läuft , wäre keine große Sache gewesen , ist vielleicht nur ein einziges Mal gemacht worden (Analog zum gemultiplexten Bus im VIC, s.u.) und z.b. im DATA-BECKER-Buch "VC20 intern" zumindest in Form einer Tabelle der Entsprechungen (Einsprungpunkte) vorexerziert worden.

    Zitat von mc71

    auch am Videochip kann man sehen, daß noch etliche vom VIC-40 geerbte EIgenschaften drinstecken- so gibt es nur einen einzelnen Takt (mit dramatischen Problemen in der Video-Darstellung)

    Worin sollten denn die "dramatischen Probleme" bestanden haben? ;)


    ich hatte mit meinem VC-20 - abgesehen vom schmalen "Guckloch" (22 x 23 Zeichen) - keinerlei Probleme mit der Darstellung, obwohl er den "schmalen" (filigranen) Zeichensatz der PET-Serie hatte und Farbhilfsträger und Dot-Clock von denselben 4,43 Mhz abhingen.

    Zitat von mc71

    Auch das gerade von CBM Japan eingeführte neue Netzteil mit 9V und 5V Spannung hat er noch nicht.

    Sondern eines mit Nur-5-volt, oder eines mit Nur-9-Volt-Wechselspannung? wäre nett, wenn du dazu noch was wüsstest - denn wissen tust du offenbar sehr viel darüber :)

    Zitat von mc71

    Und wenn man sich die Schaltpläne genauer ansieht, hat es tatsächlich im April 1982 eine kompletrte Überarbeitung des C64 sowie des Ultimax gegeben- vermutlich ist auch da erst die Atari-ähnlöiche Speicherbelegung zustande gekommen.

    Es gibt Schaltpläne dieses Zwischendings?? :)
    Unter welcher Bezeichnung müsste man denn da suchen, bei C64 oder VC-40, und/oder Ultimax, VC-10?
    Als bekennender Anhänger der Commotari-Idee würde mich auch interessieren, was daran genau atari-ähnlich ist.... denn schon die Joystick-Ports waren ja vom Atari (8bit) entlehnt....

    Zitat von mc71

    Und damit erklärt sich auch, warum in den Serien-Versionen des VIC 6566 (SRAM-Version) die Elektronik für den gemultiplexten Adreßbus der DRAM-Version enthalten ist (das Frühjahrsrätsel 2017 auf CBM-Hackers):

    Ist diese Elektronik denn von aussen zugänglich oder durch irgendeine Spezial-Beschaltung aktivierbar (z.b. wie der TED-Testmodus indem man bestimmte Pins an Hochspannung == 12 Volt legt...) ? oder sieht man das nur unter dem Mikroskop (wenn man eines dieser besonders raren Exemplare seziert = schlachtet)?

    Zitat von Mike

    Wenn die 40 Zeichen/Zeile *schnell* sein sollen, ja.

    Nachtrag, ausnahmsweise nicht als Edit:
    Kann MINIGRAFIK denn schneller "blitten" als es ein VC-40 mit seinen generischen Character-Pointern darstellen könnte?


    Insgesamt hat es mich sehr gefreut, heute so früh mit interessanten Details überrascht zu werden, vielen Dank nochmal mc71 und Mike, schönes Wochenende :)

    Zitat von Stephan

    Kann MINIGRAFIK denn schneller "blitten" als es ein VC-40 mit seinen generischen Character-Pointern darstellen könnte?

    Vorab: die Textroutinen gehören nicht zum Kern von MINIGRAFIK und werden nur bei Bedarf nachgeladen.


    Ich habe dann mal die Taktzyklen gezählt. Die innere Schleife blittet eine komplette Textzeile in 8139 Taktzyklen. Also ca. 200 Taktzyklen pro Buchstabe. Oder eben 5400 Zeichen pro Sekunde (bei 1,1 MHz).


    Gegen ein LDA #IMM:STA ABS (+evtl. noch Farb-RAM aktualisieren) kann das natürlich nicht anstinken. Schaut man sich aber die Geschwindigkeit vom KERNAL PRINT an, relativiert sich das mit dem dortigen Overhead wieder. Dazu hab ich folgendes Programm hergenommen:

    Code
    1. 1 PRINT"{CLR}";:T1=TI:FORT=1TO100:PRINT"{HOME}AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    2. 2 PRINT"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    3. 3 PRINT"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    4. 4 PRINT"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    5. 5 PRINT"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    6. 6 PRINT"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    7. 7 PRINT"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    8. 8 PRINT"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    9. 9 NEXT:T2=TI

    Es schreibt in der FOR-Schleife 100x505 "A" auf den Bildschirm, und braucht dazu 1081 Jiffies, also 18 Sekunden. Dies entspricht 50500 Zeichen/18 Sekunden ~= 2800 Zeichen/Sekunde.


    Na? Das ist doch schon mal ein Ergebnis. :D


    Von den 5400 Zeichen/Sekunde in die Bitmap ist noch etwas Overhead abzuziehen. Wenn aber ohnehin nach jeder Zeile gescrollt werden muß (weil z.B. eine große Textdatei angezeigt wird), kommen dann noch mal für jeden Scroll ca. 35000 Taktzyklen dazu (um die gesamte Bitmap eine Textzeile hochzuschieben, damit Platz für die neue Textzeile zu geschaffen wird). Damit kommt eine gescrollte Textausgabe auf 43000 Zyklen/Textzeile und kann damit immer noch ca. 25 Textzeilen pro Sekunde wegschreiben. Aus Sicht des BASIC-Programms, welches die Routinen skriptet, geschieht die Ausgabe einer Textzeile also praktisch instantan. Was hier noch bremst, ist die Key-Repeat-Rate: die liegt nämlich "nur" bei 15/Sekunde.


    ...


    Dem gegenüber hast Du die damaligen Versuche, mit FAT-40, Petloader etc. die komplette Funktionalität des Bildschirmeditors in 40 Zeichen/Zeile zu bekommen. Sämtlicher I/O muß sich durch CHROUT und CHRIN quetschen. Immer nur 1 Zeichen. Damit können diese Programme per se schon mal nicht schneller sein als der originale KERNAL I/O. Weiterhin wird auf jedes Byte in der Bitmap gezwungenermaßen (aufgrund des Einzelbuchstaben-I/O) immer *zweimal* zugegriffen: einmal, um die linke Hälfte zu blitten (wobei die rechte Hälfte sorgfältig bewahrt wird), und dann nochmal um die rechte Hälfte zu blitten (wobei dann die linke Hälfte sorgfältig draußen bleiben muß).


    Genau dieser "Blödsinn" wird u.a. in meinen Routinen vermieden - die blitten immer zwei Buchstaben gleichzeitig.


    Und auf die BASIC-Editor-Funktionalität können meine Routinen heutzutage problemlos verzichten - dazu gibt's ja mittlerweile die Möglichkeit, die Programme auf dem PC und dort im Editor zu schreiben. :D


    Gruß,


    Michael

    Eine (SCREEN-OUT)PUT-Funktion die Print bei längeren Strings ersetzt, wäre da naheliegend...
    ich werde dich zu gegebener Zeit um eine 'Lizenz' für den neuen Kernal bitten :D


    Edit: bei nur 1000 Zeichen-Stellen pro Bildschirm ist dieser in einer halben Viertelsekunde (edit2: nicht Character-pointer, bei 505 wärens eine 1/4 sec.) bereits vollgenudelt - das ist kaum ein Wimpernschlag - von daher, beachtlich!

    Zitat von Stephan

    Eine (SCREEN-OUT)PUT-Funktion die Print bei längeren Strings ersetzt, wäre da naheliegend...

    Das liefe auf eine einfache Speicherkopierfunktion hinaus. Bei einem aufrufenden BASIC-Programm kriegt so eine Routine ihre Leistung aber einfach nicht auf den Boden - wir sind da dann längst über den point-of-diminishing-returns drüber.


    Zitat von Stephan

    ich werde dich zu gegebener Zeit um eine 'Lizenz' für den neuen Kernal bitten

    Na, ja. Die fertigen Routinen sind ohnehin bereits Freeware. Den Source hatte ich seinerzeit in Denial mitveröffentlicht.


    Braucht also keinen neuen KERNAL dazu - und daß Ausgabe in eine Bitmap nicht langsam sein muß, wird hier auch gezeigt.


    Zitat von Stephan

    Edit: bei nur 1000 Zeichen-Stellen pro Bildschirm ist dieser in einer halben Viertelsekunde (edit2: nicht Character-pointer, bei 505 wärens eine 1/4 sec.) bereits vollgenudelt - das ist kaum ein Wimpernschlag - von daher, beachtlich!

    Meine Rechnung geht so: der Bildschirm hat jetzt 40x24 = 960 Zeichen, damit *könnte* die initiale Bildschirmfüllung in ~180 ms erfolgen. Mein Anzeigeprogramm ist da nicht ganz so schnell, da die zugehörige Routine ebenfalls von BASIC aus geskriptet wird und z.B. auch darauf Rücksicht nehmen muß, daß nicht alle Textdateien 24 Zeilen Text oder mehr haben.


    Hier mal der BASIC-Part des Anzeigeprogramms:

    Der initiale Aufbau geschieht in Zeile 16. Überprüft man das mal mit der Jiffy-Clock, kommen 36 Jiffies, also 600 ms (für 23 Textzeilen) heraus. Etwa 400 ms "versickern" also im BASIC-Interpreter. Tja.


    Es lohnt sich aber an der Stelle auch nicht unbedingt, das schneller zu machen, da es ja nur einmal am Anfang ausgeführt wird.

    Ist die Zeile 12 die Stelle, wo man INTERVIEW eingeben kann?
    Trickreich ist ja die Stelle mit den negativen Indizes und der nachgeschobene Argument-String "CODE" nach dem numerischen Sys-Befehl (ist das überhaupt standard Basic v2 oder schon Erweiterung, die im freien Flug untergeschoben wird), dessen Sinnhaftigkeit für mich in Frage steht :D
    Ich weiss ich soll das Programm nicht analysieren sonst wirds Offtopic :D
    Insgesamt 8..9 Sys-Befehle, bis eine Bildschirmmaske aufgebaut wird?


    In Zeile 10 /11 hab ich die Vorbelegung der Konstanten "S" verschoben; das freistehende AD am Zeilenende ist halbwegs wiederauffindbar, aber das Durcheinander dass S nicht direkt vor seiner Verwendung definiert wird, ließ mich stolpern ;)
    Was ist denn der Unterschied zwischen RETURN und @RETURN (oops, i did it again)


    Und nochwas:
    die reinen Millisekunden sind wohl gar nicht so dringlich. Wer will es schon haben, dass lange pixelige (aber im Grund bei der Schnelligkeit sinnlose) Zahlenkolonnen am Auge des Betrachters bitstreamdurchfallartig vorbeirauschen? da - beim Scrolling - kann es ruhig gemächlicher angehen (und das wäre - leicht OT - ebenfalls ein Kandidat für Sweet16 (a.a.O.)) beim wiederholten in-Sich-Kopieren des Bildschirminhalts. Folgerichtig beim Emulator Screen-out extra langsam implementiert ...
    Wo es dagegen richtig schnell sein darf, wenn Bildschirmmasken aus dem Speicher aufgebaut werden, also "Viewer" und "Buttons" und Rähmchen etc., wenn das Environment ein nicht automatisch scrollendes ist.

    Der Reihe nach:

    Zitat von Stephan

    Ist die Zeile 12 die Stelle, wo man INTERVIEW eingeben kann?

    Ja. Oder z.B. INSTRUCTIONS. Da erfährst Du dann, was all die SYS-Befehle mit der Basisadresse S(+x) so machen.


    Zitat von Stephan

    der nachgeschobene Argument-String "CODE" nach dem numerischen Sys-Befehl (ist das überhaupt standard Basic v2 oder schon Erweiterung, die im freien Flug untergeschoben wird)

    SYS57809 geht bereits "ab Werk" und liest die Parameter für LOAD/SAVE ein, bevor mit SYS65493 die KERNAL-LOAD-Routine aufgerufen wird. Dabei wird das eigene Programm übrigens *nicht* unbeabsichtigt neu gestartet (was sonst bei LOAD im Programm passiert). IFPEEK(S) ist nur drin, damit die Library nicht bei jedem RUN neu geladen werden muß.


    Ich habe S übrigens mit Absicht als frühe Variable definiert. Eben weil sie sehr häufig verwendet wird und der Interpreter dann nicht ewig die Variablenliste danach durchsuchen muß.


    Zitat von Stephan

    Was ist denn der Unterschied zwischen RETURN und @RETURN (oops, i did it again)

    Nun ja. Alle "@"-Befehle kommen von MINIGRAFIK. @RETURN bewirkt die Rückkehr in den Textmodus. :D


    ...


    Der obige BASIC-Part ist ja auch nur eine auf's wesentliche reduzierte Anwendung der Textbibliothek. Die Routinen wurden auch schon in wesentlich aufwendigeren Umfeldern verwendet.