zurück : english : front =

16MB RAM Korrektur

Wo die MINERVA-Variante M89 nicht eingesetzt werden soll, hilft ändern des .W-Wertes im ROM-Code an Adresse $04E6 von $D640 in $D680, was eine fehlerhafte .W-Addition durch ihr .L-Aequivalent ersetzt. Damit werden 16MB RAM verfügbar.
Ein anderer Fehler mag noch das LSL.W an der Stelle $0548 sein, das mit dem Wert $E588 zum LSL.L geändert werden kann - zumindest gab es dadurch keine neuen Fehler, ob nun mehr als 16MB möglich sind, wurde (noch) nicht geprüft.
Weitere Maßnahmen sind nicht erforderlich.

Für übergroße Bildschirmmaße wurde in M89 auch die Bedarfsermittlung für den FILL-Puffer modifiziert; einfacher Patch ist hier nicht möglich. Fehler treten jedoch nur sehr selten auf, und nur, wenn FILL benutzt wird und über relativ große Distanzen geht, sodaß die vom Standard-QL bekannten Programme daran kaum scheitern dürften. - Ein Beispiel mit (bisher) nur harmlosen Folgen läßt sich anhand des S.Basic-Programms "arct_dmo" zur IO2-Sammlung beobachten.

Ein noch nicht bearbeiteter Fehler besteht in der Behandlung des SHIFT/LOCK Vectors, dessen Korrektur (aufgrund Platzmangels mir derzeit noch) zu kompliziert ist.

Der Vector "bp_fname" ist ebenfalls nicht ganz in Ordnung, Hinweise dazu weiter unten.

Das erweiterte EX-Kommando

[zurück]

TK2-Special-Jobs


Die "special jobs" des TK2 sind im Grunde ihres Daseins absolut nutzlos, rsp. unnötig:

Sie werden als S.Basic-Procedur des aufrufenden Jobs ausgeführt. Unabhängig davon, ob mit EX, EW oder ET aufgerufen, starten sie sofort und halten das zugrundeliegende S.Basic an. Diese "Jobs" stellen zu nur dem Zeitpunkt ihrer Verwendung vorhandene quasi-residente Proceduren dar. - Wo vielleicht auch der einzige Sinn dieser Jobvariante zu finden sein könnte, aus einer Zeit resultierend, da Speicher noch byteweise gekauft wurde...
Vom erhofften "multi threding" oder gar "multi tasking" kann keine Rede sein. Vom Ansatz her - mit einigem Aufwand - zwar durchaus möglich, auch Versuche mit den IO2-Aufrufen belegen dies, wird dergleichen aber allein schon durch die im TK2 kultivierte Freigabe reservierter S.Basic-Datenbereiche vor(!) Verwendung der dort liegenden Daten unmöglich gemacht.
So ist, wie vermutet, der Nutzen in der Tat höchst zweifelhaft, und sowie es erneut zu der geringsten Speicherknappheit kommen sollte, wird diese Variante wieder entfernt werden.

Die Beschreibung im Original ist unvollständig rsp. irreführend oder mißverständlich; für die Verhältnisse innerhalb solcher - nicht wirklichen - Jobs soll folgendes gelten:


Beim Einsprung in den Code:

 
		D4    1, wenn es eine Eingabe-PIPE gibt, sonst 0
                D5    1, wenn es eine Ausgabe-PIPE gibt, Kanal-ID im Stack
                D6    eigene Job-ID
                D7    Gesamtzahl aller PIESs und Filenamen des Job-Aufrufs
 
                A0    Einsprungadresse zur Ermittlung von Filenamen
                A1    Pointer auf den Parameterstring
                A3(a6) Anfang der name-table der Parameterübergabe
                A4    eigener Stackpointer
                A5(a6) Ende der name-table
 

Auch zu Parametern, die womöglich übergeben werden können, ist nur diffuses Zeug zu finden. Der Code selbst gibt aufgrund seiner extremen Verworrenheit Informationen nur schwer preis, und Versuche ergaben, daß Parameter, wenn überhaupt, kaum in brauchbarer Form in den Aufrufen ankommen; auch der Stackinhalt ist unsicher.

Für die z.B mit { JSR (A0) } erreichbare Routine gilt:

 
	    IN:
		(A3,A6) erster Parameter in standardgemäßer S.Basic-Konvention
 
	    OUT:
		D0 & SR Fehlercode, oder 0 und A1 gilt, oder > 0 und A0 gilt
                D1-D3   Inhalt zerstört
                A0      Kanal-ID wenn der Parameter mit führendem "#" übergeben wurde
                (A1,A6) Pointer auf den als Parameter übergebenen Namen; A1:=0 bei D0>0
 
	    - alle anderen Register bleiben unverändert -
 

In jedem Falle, also auch bei Rückgabe eines String VOR dessen Entnahme, ist der Übergabebereich mit Pointer BV_RIP bereits um die Größe des Datenposten "bereinigt"!

Die etwas seltsame Parameter-Bewertung läuft darauf hinaus:

Eine zweite Hilfsroutine ist über z.B. { JSR 2(A0) } zu erreichen. Mit ihrer Hilfe kann der Kanal zu einem mitgegebenen File- rsp. Device-Namen geöffnet werden:

 
	    IN:
        	D3      OPEN-Modus
                D6      eigene Job-ID
		(A1,A6) Pointer auf den Namen (darf nicht im S.Basic-Puffer stehen)
 
	    OUT:
        	D0 & SR Fehlercode
                D1, D2  Inhalt zerstört
                A0      Kanal-ID (bei erfolgreichem Aufruf)
                (A1,A6) Ptr auf den Namen
 
            - alle anderen register bleiben unverändert -
 

Bei Aufgabe rsp. Beendigung des "Jobs" genügt der gewöhnliche Aufruf der QDOS-Trap MT.FRJOB nicht: Der Trap ist die wirkliche Job-ID mitzugeben, keinesfalls D1:=-1, da dann auch der zugrundeliegende S.Basic-Job entfernt würde, und es muß ein RTS folgen, wobei, wenn das aufrufende Programm nicht mit Fehler (z.B. err.nc, -1) abgebrochen werden soll, zuvor noch D0:=0 zu setzen ist.

[zurück]

XTcc-Felder

"XTcc"-Felder sind im QDOS nicht bekannt. Sie entstanden aus der C68-Praxis, um den Transport über fremde Filesysteme zu erleichtern - wo sie sich bewährt haben, und weshalb sie hier berücksichtigt werden.
Solch ein Feld besteht aus der an das File-Ende angefügten Textmarke "XTcc" mit folgendem .L-Wert für den Datenbereich, entsprechend dem Posten an Position 6 im QDOS-Fileheader.

Aufbau:

 
		..programm..
                dc.l 'XTcc',dataspace
                end             der block muß am file- rsp code-ende stehen
 

[zurück]

Umgehung des Fehlers bei "bp_fname" in MINERVA 1.97

Uneinheitliche Fehlerbehandlung im Original (1.89 und 1.97 untersucht) führt zu abweichender Registerbesetzung, falls keine Parameter übergeben wurden, und dann sehr leicht auch zu Irrläufern durch Stackfehler. In M89 wurde beides korrigiert. M97 läßt sich durch Überschreiben des Wertes $6CEC an Adresse $2330 mit $64EE entsprechend ändern.

Da nicht erkennbar ist, ob dies womöglich gar aus irgendeinem (rätselhaften) Grunde bewußt vorgesehen wurde, hier ein Beispiel zur konfliktfrei einheitlichen Fehlerbehandlung:

Nach Prüfung auf Vorhandensein von Parametern ist der Vectoraufruf risikolos:

 
	    fname   moveq #-15,d0   err.bp vorbereiten
		    pea 8(a3)       einheitlich
		    cmp.l a5,a3
		    bcc.s noname    ? keine parameter
                    move.w 328,a1   vector bp_fname
                    jsr $4000(a1)   >
	    noname  move.l (sp)+,a3
		    move.l $58(a6),a1 string oder nur sicherer wert
		    tst.l d0        flags für ggf. err.bp
                    ..programm..
 

Alternative mit besonderer Fehlerbehandlung:

 
	    fname   pea 8(a3)
        	    pea drop_error(pc)
                    move.l $58(a6),a1
                    move.w 328,a2   vector bp_fname
                    jsr $4000(a2)   >
                    addq.l #4,a7    besonderen fehlerausgang wegnehmen
                    move.l (sp)+,a3
                    bne.s error_exit ?
                    ..programm..
            error_exit
                    ..fehlerbehandlung..
            drop_error
                    move.l (sp)+,a3
                    ..sonderfall..   keine parameter vorhanden
 

[zurück]

BGET

Die Folge

 
		e$ = FILL$(100)
                DIM a$(100) : a$=e$
                DIM b$(9,9,100) : b$(3,3)=e$
                DIM c$(1,200) : c$(0)=e$
                k$ = a$&e$
                BGET #chan,e$,a$,k$(81 TO 180),b$(3,3,1 TO),c$(0,100 TO)
 
holt in jeden der angegebenen Strings 100 bytes aus dem Eingabestrom von #kanal.
Alle Arten Strings für BGET, WGET, LGET müssen vorher bereits besetzt worden sein.
Bei DIMensionierten Strings muß ohne Ausnahme auch der Bereich angegeben werden.
Bereichsangabe ist für jede Art String möglich.

[zurück]

MB - Minerva S.Basic-Job einrichten

Nach einer den MINERVA-ROMs beiliegenden Vorlage

MB [parameter$]

Ohne Parameter Start mit kleinem Fenster für Kanal #0, der zugleich auch als #1 fungiert.
Bis zu 6 solcher Fenster werden im Bild ohne Überschneidung automatisch angeordnet.
Der Job erhält den Namen 'SB.{nn}' mit {nn} als dessen QDOS-Jobnummer, wie sie z.B. für die QLIB-Erweiterungen gilt. Besitzer ist jeweils der aufrufende Job.


Optional ein Parameterstring mit:

[zurück]

TRACE

Einrichtung zur Programmverfolgung im S.Basic. Der Code entspricht bis auf wenige Details (z.B. Fehlerbehandlung "bp_fname") der dem MINERVA-ROM mitgegebenen Vorlage von J.Oakley.

Anzeige

Am Anfang steht die betr. Zeilennummer.
Es folgen durch Semicola getrennt die einzelnen Befehle mit ihrer Positionsnummer in der Zeile.
Ein "." Punkt steht für die Ausführung eines S.Basic-Token.
Locale oder Parameter eines Aufrufs werden durch je eine "~" Tilde markiert.
Ein "=" Gleichheitszeichen deutet Zuweisungen an Variable an.
Bei Zuweisungen aus Funktionen wird der Buchstabe "f" vorangestellt.

[zurück]

HISTORY

Die "HISTORY" von Mr.T? (SMSQ/E) ist ein einfacher String-Stack, Kanal-bezogen oder in global zugänglicher Form. Sie wurde NICHT nach T6 übertragen, könnte aber bei überwältigend deutlich geäußertem Bedarf möglicherweise gleichartig nachgesetzt werden...

[zurück]

Command Line History 1v27

Die vollständige Beschreibung der nach T6 unverändert übernommenen Command Line History von Boris Jakubith befindet sich als QUILL-Dokument im T6-Archiv. Hier als Kurzreferenz:

Als <kanal> gelten S.Basic-Kanäle mit führendem "#"-Zeichen oder QDOS-Kanalnummern.

Zusätzlich in T6:

Ablage automatisch mit <ENTER>, identische Eingabezeilen werden nicht erneut aufgenommen.
Auswahl und "Blättern" in den vorherigen Zeilen durch Cursor hoch/runter,
Übernahme in die Eingabe durch <ENTER>, ggf. nach vorherigem Editieren der betr. Zeile.

History mit max. 100 Zeilen z.B. für den S.Basic-Kanal #0:

HIS_DEF#0,100

Mit der Command Line History wird ein Stapel eingerichtet, in dem alle Eingabezeilen eines CON-Fensters, dem eine solche History zugeilt wurde, der Reihe nach abgelegt und in der umgekehrten Reihenfolge ("LIFO"-Speicher, jüngster Posten zuerst) bei Bedarf entnommen werden. Die Erweiterung hat sich in ausnahmslos allen QDOS-artigen Systemen bewährt.

Das HIS-Device tritt zu Anwendungen hin nicht in Erscheinung; es besteht überlagernd und parallel zur CON-Definition, bei deren Kanälen es ggf. nach den Traps io.edlin und io.fline aktiv wird. Der Name wird nur für den direkten Zugriff z.B. aus Assemblerprogrammen benötigt.

[zurück]

PARVAL

Mit dieser Funktion können die S.Basic-Variablen aus in Strings zusammengesetzten Namen gelesen werden - vergleichbar mit der aus dem "ARCHIVE"-Interpreter bekannten Weise.

Wenn etwa die Namen "CMD1", "CMD2", "CMD3" existieren, so holt folgende Programmsequenz deren Werte in ein Array:

 
		DIM V$(3,300)
                FOR r = 1 TO 3 : v$(f) = PARVAL('CMD'&f)
 

Eine zweite Variante erlaubt den mit der Positionsnummer indizierten Zugriff auf die Variablen aus der Parameterliste von Proceduren und Funktionen im S.Basic:

 
		DEFine PROCedure TEST ( x,y,z )
                LOCal a,b,c,l,r
                 l = 0
                 FOR r = 1 TO PARM%(x,y,z)
                  e$ = PARVAL(#r)
                  a  = LEN(e$) : IF a > l : l=a
                 END FOR r
                 p = f-1
                 DIM p$(p,l+1)
                 FOR r = 0 TO p: p$(r-1) = PARVAL(#r-1)
 

p hat dann die Anzahl übergebener Variabler, deren Werte stehen in p$.
Die Funktion PARM%( parameterliste ) aus IO2 kann benutzt werden, um die Position des letzten besetzten Parameters zu ermitteln. Ohne IO2 kann der Fall e$="-7" als Signal zum Verlassen der FOR-Schleife dienen; dies ist der von PARVAL zurückgegebene Fehlercode bei Indices außerhalb des gültigen Bereichs.

Nebenbei:
Eine erweiterte und vielseitigere Form ist mit Namen "VGET" im Teil "sv0" der IO2-Sammlung enthalten. Damit lassen sich z.B. auch ausführbare Namen von residenten Proceduren und Funktionen samt zu übergebenden Parametern Job-bezogen (so z.B. auch, wenn sie nur in anderen Jobs bekannt sind) aus zusammengesetzten Strings aufrufen.

[zurück]

DIR WDIR WSTAT

Bei zusätzlicher Angabe für den Typencode werden nur die entsprechenden Namen angezeigt:

Der Code für Directory-Files ist im wirklichen QL stets 255, sonst aber nicht unbedingt in allen QDOS-artigen Systemen derselbe (THOR!). Er kann z.B. mit Hilfe von HGET ermittelt werden:

  HGET\"win2_",typ,typ,typ (die ersten beiden posten interessieren hier nicht)
Damit systemunabhängige (aber langsamere) Anzeige nur von Directories: 
  d$="win2_":HGET\d$,t,t,t:DIR d$&"a_",t
oder auch - etwas einfacher - mit FTYP: 
  d$="win2_":DIR d$&'a_',FTYP(\d$)

[zurück]

"wildcard"-Kommandos

Hiermit ist ein wenig salopp und ungenau die unbestimmte Ergänzung fehlender Textteile in (File-)Namen bei einigen Kommandos des TK2 angedeutet. Gelegentlich finden sich kritische Anmerkungen dazu und zu der "Tatsache", daß sie fehlerhaft oder nicht sonderlich brauchbar seien - was m.E. bei aller sonstigen Kritik am TK2 kaum zutrifft.
Zur Klärung darum kurz die Beschreibung aus dem TK2-Handbuch:

"'wild card'-Namen sind eine besondere Art Filenamen, von denen ein Teil als 'wild card' gilt [wie aufschlußreich!] und durch eine beliebige Zeichenfolge ersetzt werden kann. Da der Handlichkeit halber solche Namen normale S.Basic-Namen sein sollen, können sie keine Sonder-, Satz- oder Rechenzeichen enthalten; so würde bei einem Namen myfiles_*_asm etwa der Interpreter die Multiplikation von myfiles_ mit _asm versuchen, nicht aber einen Namen erkennen. Darum gilt hier vereinfachend, daß jeder fehlende Teil eines Filenamen als 'wild card' behandelt wird.

Z.B. findet

WDIR win2_a_tk_t6m97_asm

auch alle Varianten der Art

win2_a_tk_t6m97-nummer_asm

Nötigenfalls wird der wc-Name durch Voranstellen der Datenverzeichenis-Vorgabe ergänzt.

Womit die knappe Beschreibung endet.

So kann z.B. Einsatz der Devicevorgabe auch merkwürdige Namen erzeugen, wie etwa "win2_x_mdv2_x_filename", wenn das in einem voll spezifizierten Filenamen angegebene Device nicht vorhanden ist. Hiergegen gibt es kein verallgemeinerbares Mittel, da nie bekannt ist, welche Devices in einem System zu einen gegebenen Zeitpunkt vorhanden sein werden.

Weiter ist der Zeichenvergleich von der Schreibweise unabhängig beabsichtigt und nicht etwa Fehlfunktion, zu welcher Annahme die Tatsache verleiten mag, daß er im Original keineswegs immer richtig durchgeführt wird. Dabei ist dieser Fehler aber nicht im QDOS und dem gerne als Ursache angesehenen QDOS-Vector zu suchen, sondern allein im TK2 selbst.
Dies wurde mit T6 korrigiert.

Vergleich in Abhängigkeit auch von der Schreibweise der Filenamen ist im S.Basic nicht vorgesehen und wird auch mit T6 nicht durchgeführt. Die daraus mit z.B. dem UQLX erwachsenden Schwierigkeiten müssen dort beseitigt werden. Entsprechende Änderungen im S.Basic rsp. T6 wären nicht QDOS- rsp S.Basic-konform und sind nicht beabsichtigt.

[zurück]

(count)