atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: guest522 am So 27.01.2019, 15:24:09
-
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 (http://wiki.newtosworld.de/index.php?title=Lightning_VME_USB_Interface) 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...
-
Was heißt "wird nicht geladen"? Eine Fehlermeldung? Nutzt Du TOS oder MagiC?
-
Plain TOS.
Die Meldung des Treibers kann ich leider nicht erkennen, die ist zu schnell weg.
USBTOOL sagt "USB driver not loaded"
-
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?
-
da scheint was mit den Cookies durcheinander zu geraten:
-
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.
-
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
-
Als work-around könnte ich meine Jar Vergrößerung einen Schritt früher machen. ::)
-
Ich habe unterdessen angeregt, zumindest eine Fehlermeldung auszugeben:
https://github.com/freemint/freemint/issues/105
-
Danke! Mit der "ein-cookie-früher" Methode läuft es. Ich finde es aber nicht sehr elegant
-
Schade das es dafür keinen Automatismus gibt...
-
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...)
-
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...?
-
Jarxx.prg is z.B. bei Geneva dabei.
-
https://www.krauseberlin.de/de/software/cookie.html
-
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.
-
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.
-
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.
-
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.
-
^^-- 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 .
-
Jarxx.prg is z.B. bei Geneva dabei.
Ohne genau dieses CookieJar läuft Geneva nicht.
Was daran liegt das Jarxx.prg eine XBIOS (https://freemint.github.io/tos.hyp/de/xbios_special.html#CJar) Funktion anlegt. Mit der man auf den Cookiejar zugreifen kann.
-
^^--Wäre das für eigene Prge. wirklich nützlich?
Ich benutze lieber meinen eigene Code.
Um den CookieJar (& auch XBRAs) auszulesen gibt es eine ganze Reihe von Prgen., zB. von Shauri, von Linnhe, den SysInfo_5 und last not least mein BIOX.TOS (auch schon mal irgendwo angehängt). Das letztere ist zwar archaisch, müßte imho aber als .PRG sogar im AUTO\ laufen (habe ich jedoch nie ausprobiert).
Aber das Prg. von A.Krause aus #14 kannte ich noch nicht, danke für´n Link, Idek!
-
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.
Auch noch in Assembler... alter Schwede. :) Ich denke das ist sehr hilfreich wenn es so funktioniert wie zu erwarten. Danke
https://www.krauseberlin.de/de/software/cookie.html
Sieht echt gut aus.
-
Im Anhang meine Listen für Sha´uri und Linnhe.
Hat jmd. Ergänzungen?
-
Auch noch in Assembler... alter Schwede. :) Ich denke das ist sehr hilfreich wenn es so funktioniert wie zu erwarten. Danke
Das funktioniert tatsächlich ;) An physikalischer stelle in den Auto Ordner hinein und es wird gewartet.
Ich mein jedoch mich zu erinnern es gab Programme die nach jedem Programm im Auto Ordner ein Halt bewirkten.
Ich habe keinerlei echte Hardware hier, aber wenn ich kleine Problemchen lese, lade ich mir n Hatari runter und probier es für mich zu lösen. Macht richtig Spaß, wenn es funktioniert.
-
im tos.hyp ist eine lange liste http://toshyp.atari.org/de/003007.html
-
^^-- Die hatte ich mal eingearbeitet - ist aber schon ein Weilchen her...
-
https://www.krauseberlin.de/de/software/cookie.html
Sieht echt gut aus.
Und die Ästhetik wird auch nicht durch Infos gestört. 8)
-
Und die Ästhetik wird auch nicht durch Infos gestört. 8)
Genau, spartanisch aber sehr schick. Nicht mehr und aber auch nicht weniger.
-
mas o menos uiiiiihhhh.... ::)