Im Gegensatz zum ATARI ST ist es beim Falcon ohne zusätzliche Hardware (Videointerface) möglich, einen Videorecorder anzuschließen. Von der Benutzung des TV-Ausgangs (Antennensignal) ist wegen der schlechten Qualität abzuraten. Ein Blick ins Handbuch verrät jedoch, daß auf Pin 12 des Monitorausgangs ein Composite-Sync-Signal herausgeführt wird. Dies ist das zusammengemischte RGB-Signal wie es ein Videorecorder verarbeitet. Für das komplette Videosignal wird zusätzlich noch eine Masseleitung benötigt, wie sie an Pin 10, 11 und 5 anliegt. Ohne großen Aufwand kann so schnell und billig ein Videoadapter gebaut werden. Einem Videovorspann mit 256- oder gar 65000 Farben steht also nichts mehr im Wege. Ohne zusätzliche Grafikerweiterungen (Soft-/Hard-ware) ist allerdings der typische ATARI-Rand noch im Bild. Genlockeffekte, wie Stanzen von Schrift sind mit dieser einfachen Lösung natürlich nicht möglich, dafür spart man schließlich auch einige hundert Mark.
Harald Schmitz
Nachdem man mit vst_load_-fonts die Anzahl der zur Verfügung stehenden Fonts ermittelt und geladen hat, kann man mit vst_font einen Font bestimmen. Ein Parameter dieser Funktion ist die Indexnummer des einszustellenden Zeichensatzes. Das Ergebnis dieser Funktion ist die Indexnummer des tatsächlich eingestellten Fonts. Diese Indexnummer und der Name des Zeichensatzes sind das Ergebnis der Funktion vqt_name. Verwendet man nun SpeedoGDOS, so sind für die mitgelieferten Zeichensätze folgende Definitionen hilfreich:
/* SpeedoGDOS Fontnummern 7/93 S.Kaminski */
#define SWISS 3
#define SWISS_ITALIC 4
#define SWISS_BOLD 5
#define SWISS_BOLD_ITAL 6
#define DUTCHROMAN 11
#define DUTCH_ITALIC 12
#define DUTCH_BOLD 13
#define DUTCH_BOLD_ITALIC 14
#define PARK_AVENUE 362
#define MONOSPACE 596
#define BITSTREAM_COOPER 630
#define VAG_ROUNDED 756
#define WINGBATS 3219
#define SYMBOL_
MONOSPACED 9831
Ein Aufruf von vst_font kann also so aussehen:
fn = vst_font(wk_handle, MONOSPACE);
Anschließend kann das Ergebnis entsprechend ausgewertet werden:
if(fn != MONOSPACE) ...
Steffan Kaminski
Durch einen fürchterlichen Systemcrash war ich leider gezwungen, den NVM (der Konfigurations-Speicher unseres geliebten Falcons) neu zu initialisieren. Seit diesem Zeitpunkt bootet der Rechner zu meinem Erstaunen ohne Speichertest und „Schweigeminute“. Durch Vergleich des NVM-Inhaltes mit „unversehrten“ Rechnern fand ich heraus, daß das 10. Byte im NVM normalerweise den Wert 32 (dez.) enthält. Setzt man dieses Byte auf den Wert 0, unterläßt der Falcon030 beim Kaltstart den Speichertest wie auch die Schweigeminute. Anders ausgedrückt findet man sich nach dem Einschalten bereits 20 Sekunden später ohne jeglichen Tastendruck auf dem Desktop wieder - und das obwohl 5 AUTO-Programme, 6 Accessories sowie 16 CPX-Module (beim Start werden die Header gelesen und zum Teil deren Init-Routinen ausgeführt) erledigt wurden. Damit ist das unbeaufsichtigte Bedienen von Modems u.ä. kein Problem mehr, sofern man einen „Einschalter" hat. Hier nun ein Listing (Pascal) zum Löschen dieses Bytes:
Jörg Thiele
;(c)1993 by MAXON-Computer
;**Autor:** Jörg Thiele
program nomemtst;
var
ret: integer;
buffer: byte;
function numaccess (mode, start, count: word; buff: pointer):integer;external;
{$1 num.o}
begin
writeln('Der Speicher wird ausgelesen ...');
writeln;
ret := numaccess (0, 10, 1, @buffer);
if ret <> 0 then halt;( da stimmt etwas nicht...)
buffer := 0;
ret := nvmaccess (1, 10, 1, @buffer);
if ret = 0 then
begin
writeln(#27'b'#11'Alles klar ...'#27'b'#2);
end;
writeln ('Weiter mit <Return>');
readln;
end.
;nvm_access.S
;(c)1993 by MAXON-Computer
;**Autor:** Jörg Thiele
.export nvmaccess
.text
numaccess:
move.1 A0,-(SP)
move.w D2,-(SP)
move.w Dl,-(SP)
move.w DO,-(SP)
move.w #$2E,-(SP)
trap #14
lea $C(SP),SP
rts
.end
Der GFA-BASIC-Compiler macht unter MagiX! Probleme, nach Beenden des Compilierens meldet MagiX! ‘Speicherblock zerstört’.
Ursache: Der Compiler reduziert per MShrink seinen Speicherbedarf auf das Notwendige. Per Malloc fragt er dann nach dem größten verfügbaren Speicherblock und alloziert diese Größe abzüglich 16 KB. Leider geht das Programm davon aus, daß der allozierte Speicher direkt hinter dem vorher geshrinkten Bereich liegt. Im allgemeinen stimmt dies sogar. Unter MagiX! liegt vor dem allozierten Speicherblock (die Adresse, die Malloc zurückgibt) allerdings ein sogenannter MCB, der ‘Memory Control Block’. Dieser enthält:
Der GFA-Compiler überschreibt den MCB. Nach dem Terminieren des Compilers überprüft MagiX!, ob die Kette der MCB s noch in Ordnung ist und meldet den beschriebenen Fehler.
Abhilfe: Man suche mit Hilfe eines Diskettenmonitors die Sequenz:
$4BFA $XXXX $41F9 $YYYYYYYY $4FF9 SYYYYYYYY
Auf den Long-Wert SYYYYYYYY werden $10 addiert, das Ergebnis dieser Addition nennen wir $ZZZZZZZZ. Der Wert $YYYYYYYY kommt 6 mal im Compiler vor. An den letzten drei Stellen des Auftretens wird $YYYYYYYY durch $ZZZZZZZZ ersetzt.
Durch den Patch benutzt der GFA-Compiler die ersten 16 Byte des hinter dem MShrink liegenden Speicherbereiches nicht mehr und überschreibt demzufolge keinen MCB. Das Verhalten des Compilers bleibt trotzdem inkorrekt, da der allozierte Bereich nicht unbedingt hinter dem vom Compiler noch belegten Speicher liegen muß (obwohl dies in der Regel zutrifft).
Christoph Conrad
Als stolzer Falcon030- und MUSiCOM-Besitzer wäre es schön, wenn man den Equalizer des Programms einschalten und gleichzeitig an seiner Diplomarbeit/Tabellenkalkulation etc. schreiben könnte. Dies ist mit einem kleinen Trick unter MultiTOS möglich. Starten Sie MultiTOS, anschließend starten Sie MUSiCOM. Schalten Sie in MUSiCOM die beste Klangqualität ein (16 Bit, 49.2kHz), Button „Effekte benutzen“ zuschalten. Stellen Sie nun den Equalizer so ein, daß Sie den für Sie optimalen Sound erhalten. Verlassen Sie den Equalizer (mit OK+OK). Nun befinden Sie sich in der MUSiCOM-Hauptoberfläche. Hier klicken Sie „Aufnahme“ an und geben in der Fileselectbox einen Namen ein. Welchen Namen und welches Laufwerk Sie anwählen, ist egal, da die Aufnahme sowieso nicht funktionieren wird. Der letzte Schritt ist das Abmelden von MUSiCOM. Dazu wählen Sie in der Menüleiste des Desktops „Extra -> Laufwerke anmelden“ (falls noch nicht geschehen). Es erscheint ein Laufwerk mit der Kennung „U“. Sie öffnen nun dieses Laufwerk und den darin enthaltenen Ordner „PROC“. Hier ziehen Sie die Datei „MUSICOM.OOX“ auf den Papierkorb und bestätigen mit OK das Löschen dieser Datei. Ab diesem Zeitpunkt ist der DSP des Falcon bis zu einem Reset blockiert. Der Vorteil: Guter Sound des Walkmans, ohne den Hauptprozessor zu belasten, denn was kann der DSP schon in einer Textverarbeitung verrichten?
Eduard Koller
Mit den hier aufgelisteten Funktionen ist es sehr einfach, den Cookie-Jar anzuzeigen oder nach dem Inhalt bzw. dem Vorhandensein eines Cookies zu suchen. Das kann zum Beispiel nützlich sein, um zu testen, ob die Funktion FSEL_EXINPUT (AES 91), die normalerweise erst ab TOS 1.04 oder mit Selectric verfügbar ist, benutzt werden kann. Selectric z. B. benutzt den Cookie FSEL, dessen Existenz mit FN Exist_Cookie% ("FSEL") überprüft werden kann. Martin Patzels einfachere (und damit speichersparende) FSel-Box kommt damit leider ins Hintertreffen, weil sie keinen Cookie besitzt. Die FN Cookie_Adr%L liefert einzig und allein die Adresse des Cookie-Jars als Langwort zurück (Inhalt der Systemvariablen $5AO). Um den Cookie-Jar aufzulisten, ist die Funktion FN Get_Cookie$ nützlich. Sie legt in den Rückgabe-String jeweils abwechselnd den Namen (4 Byte) und den „Inhalt“ (auch 4 Byte) des Cookies. Mit der Prozedur PROC Such_Cookie (Cookie$, R Found%, R Value F%L) wird getestet, ob der Cookie mit dem Namen Cookie$ existiert. Tut er das, bekommt Found% den Wert -1 (TRUE), und in Value%L wird sein „Inhalt“ zurückgegeben.
Florian Bucher
' Cookie-Jar Abfrage für OMIKRON.BASIC
'(alle Versionen!)
'(c)1993 by MAXON-Computer
'**Autor:** Florian Bucher
'
IF FN Cookie-Adr%L THEN
Keks$=FN Get_Cookie$
'Ganzen Cookie-Jar in einen String
IF LEN(Keks$) THEN
FOR I%=1 TO LEN(Keks$) STEP 8
PRINT "Keksname: ";MID$(Keks$,1%,4),
PRINT "Inhalt: $";HEX$(CVIL(MID$(Keks$,I%+4,4)))
NEXT I%
ELSE
PRINT "Cookie-Jar leer!"
ENDIF
ELSE
PRINT "Kein Cookie-Jar vorhanden!"
ENDIF
' Wenn TOS-Version >= 1.04 oder
' "FSEL"-Cookie (Selectric) vorhanden
IF WPEEK( LPEEK($4F2)+2)>=$104 OR FN Exist_Cookie%("FSEL") THEN
PRINT "Fsel_Exinput ist möglich!"
ENDIF
END
'
DEF FN Exist_Cookie%(Cookie$)
LOCAL Found%,Xy%L
Such_Cookie Cookie$,Found%,Xy%L
RETURN Found%
'
DEF PROC Such_Cookie(Cookie$,R Found%,R Value%L)
LOCAL Jar%L,Cname%L
Jar%L=FN Cookie_Adr%L
Found%=0
IF Jar%L THEN
REPEAT
Cname%L= LPEEK(Jar%L)
IF Cname%L= CVIL (Cookie$) THEN Found%=-1 :Value%L= LPEEK(Jar%L+4): EXIT
Jar%L=Jar%L+8
UNTIL Cname%L=0
ENDIF
RETURN
'
DEF FN Cookie_Adr%L = LPEEK($5A0)
'
DEF FN Get_Cookie$
LOCAL Jar%L,Keks$
Keks$=""
Jar%L=FN Cookie_Adr%L
IF Jar%L THEN
REPEAT
Cname%L= LPEEK(Jar%L)
IF Cname%L THEN
Keks$=Keks$+ MKIL$(Cname^sL)+ MKIL$( LPEEK(Jar%L+4) )
Jar%L=Jar%L+8
ENDIF
UNTIL Cname%L=0
ENDIF
RETURN Keks$