Lightning und Nova

[guest522]

Nach viel zu langer Zeit habe ich es heute endlich mal geschafft die Lightning in meinen TT einzubauen.
Nach den ersten Gehversuchen mit einem USB Stick, habe ich natürlich die NOVA dazu eingebaut.
Dabei ist mir golgendes aufgefallen:
Hier schreibt Ihr:

Empfehlung für die Reihenfolge im Autoordner für TOS und Magic:

Zunächst die Nova Treiber in der Reihenfolge EMULATOR.PRG, MENU.PRG, STA_VDI.PRG.

Danach die Lightning VME Treiber in der Reihenfolge USB.PRG, MOUSE.PRG, STORAGE.PRG, KEYBOARD.PRG, BLITZXXX.PRG.

Das klappt bei mir nicht! Der USB Treiber wird nicht geladen. Wenn ich die Reihenfolge umkehre, also erst Lightning dann Nova Treiber, dann funktioniert es.
Jetzt bin ich (mehr als normalerweise) verwirrt...

[czietz]

Was heißt "wird nicht geladen"? Eine Fehlermeldung? Nutzt Du TOS oder MagiC?

[guest522]

Plain TOS.
Die Meldung des Treibers kann ich leider nicht erkennen, die ist zu schnell weg.
USBTOOL sagt "USB driver not loaded"

[czietz]

Plain TOS.
Die Meldung des Treibers kann ich leider nicht erkennen, die ist zu schnell weg.

Die Meldung wäre aber wichtig. Kannst Du ans Ende Deines AUTO-Ordners ein Programm stellen, das auf einen Tastendruck wartet? Oder den Bildschirm abfilmen (Handy, Kamera...), sodass Du das Video später an der richtigen Stelle anhalten kannst?

[guest522]

da scheint was mit den Cookies durcheinander zu geraten:

[czietz]

Die einzige Ursache die mir hierzu einfällt: Der Cookie-Jar ist zu diesem Zeitpunkt voll. Leider legt der USB-Stack (USB.PRG) keinen größeren Jar an, wenn der _USB-Cookie nicht mehr hineinpasst. Das ist ein Verbesserungsvorschlag, den man an FreeMiNT melden sollte. Benutze doch als ersten Programm in AUTO-Ordner ein Programm wie "jarxxx.prg", um einen größeren Jar anzulegen.

[guest522]

Die einzige Ursache die mir hierzu einfällt: Der Cookie-Jar ist zu diesem Zeitpunkt voll. Leider legt der USB-Stack (USB.PRG) keinen größeren Jar an, wenn der _USB-Cookie nicht mehr hineinpasst. Das ist ein Verbesserungsvorschlag, den man an FreeMiNT melden sollte. Benutze doch als ersten Programm in AUTO-Ordner ein Programm wie "jarxxx.prg", um einen größeren Jar anzulegen.

Ja, so ist es. Wenn ich mit CJSIZE.PRG das Jar groß genug mache, klappt es. Nach dem Boot sind 19 Cookies im Jar.

Edit: besser lesbar gemacht, es hat eine "]" beim Quote-Ende gefehlt. Lynxman

[guest522]

Als work-around könnte ich meine Jar Vergrößerung einen Schritt früher machen.

[czietz]

Ich habe unterdessen angeregt, zumindest eine Fehlermeldung auszugeben:
https://github.com/freemint/freemint/issues/105

[guest522]

Danke! Mit der "ein-cookie-früher" Methode läuft es. Ich finde es aber nicht sehr elegant

[Arthur]

Schade das es dafür keinen Automatismus gibt...

[czietz]

Schade das es dafür keinen Automatismus gibt...

In einer idealen Welt würde USB.PRG einen größeren Cookie Jar anlegen und die existierenden Cookies herüber kopieren. Es hat sich nur bislang niemand gefunden, der diese Funktion dort programmiert hat. (Und ich arbeite z.Zt. an anderen USB-Geschichten und habe keine Zeit...)

[1ST1]

Neuen Cookiejar anlegen und alte Cookies rüberkopieren ist aber auch nicht der Weisheits letzter Schuss. Schade, dass der Cookiejar keine dynamisch verlängerbare verkettete Liste ist, sondern scheinbar ein Array fixer Größe. Wenn jetzt jedes Tool den Cookiejar neu anlegt und vorher angelegte Cookies reinkopiert, das ist doch Speicherverschwendung, auch wenn es wahrscheinlich nur recht kleine Dinger sind. Die Idee, vorne als erstes im Autoordner einen ausreichend großen CJ anzulegen, sollte eigentlich reichen? Hat mal jemand einen Link zu jarxxx.prg? Ich glaube, ich lege das mal als erstes in den Autoordner meiner TTs und Falcons und richte damit mal 50 "Slots" an, das sollte auf Ewig reichen...?

[MJaap]

Jarxx.prg is z.B. bei Geneva dabei.

[guest522]

https://www.krauseberlin.de/de/software/cookie.html

[guest522]

Neuen Cookiejar anlegen und alte Cookies rüberkopieren ist aber auch nicht der Weisheits letzter Schuss. Schade, dass der Cookiejar keine dynamisch verlängerbare verkettete Liste ist, sondern scheinbar ein Array fixer Größe. Wenn jetzt jedes Tool den Cookiejar neu anlegt und vorher angelegte Cookies reinkopiert, das ist doch Speicherverschwendung, auch wenn es wahrscheinlich nur recht kleine Dinger sind. Die Idee, vorne als erstes im Autoordner einen ausreichend großen CJ anzulegen, sollte eigentlich reichen? Hat mal jemand einen Link zu jarxxx.prg? Ich glaube, ich lege das mal als erstes in den Autoordner meiner TTs und Falcons und richte damit mal 50 "Slots" an, das sollte auf Ewig reichen...?

So läuft das ja auch nicht. Best Practice ist, dass man nachschaut ob noch genug Platz für das eigene Cookie vorhanden ist. Nur wenn das nicht der Fall ist wird ein neues, größeres (+10) Array angelegt und umkopiert. In der Regel findet das also nicht oft statt.

[mfro]

Schade das es dafür keinen Automatismus gibt...

In einer idealen Welt würde USB.PRG einen größeren Cookie Jar anlegen und die existierenden Cookies herüber kopieren. Es hat sich nur bislang niemand gefunden, der diese Funktion dort programmiert hat. (Und ich arbeite z.Zt. an anderen USB-Geschichten und habe keine Zeit...)

Das scheint mir keine allzugute Idee zu sein.

Der Cookie-Jar gehört dem TOS und die m.E. einzige (saubere) Möglichkeit für einen GEMDOS-Prozess, dem System Speicher zurückzugeben (ihn aus der GEMDOS-Speicherliste auszuklinken), ist, sich per Ptermres() zu beenden. Ich gehe davon aus, USB.PRG soll nicht beendet werden?

So ein Cookie-Jar "Aufblaser" gehört m.E. in den AUTO-Ordner.

[ari.tao]

Jarxx.prg is z.B. bei Geneva dabei.

Ohne genau dieses CookieJar läuft Geneva nicht. Andererseits kann man ihn auch überall sonst einsetzen! Habe ihn deshalb auf allen meinen Boot-Parts.

[laufkopf]

Hilft jetzt nicht mehr wirklich, aber vielleicht ist es ja später nochmal nützlich. Im Anhang ein kleines Programm, dass einfach auf einen Tastendruck wartet. pdf entfernen und entpacken. Mit Quelltext für wen es interessiert.

[ari.tao]

^^-- Ich hatte hier:
       https://forum.atari-home.de/index.php/topic,13120.msg212011.html#msg212011
auch schon mal ein eigenes Gebräu für den Zweck angehängt, nämlich Break.ZIP .