atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: ditto am Mi 09.12.2015, 00:51:53
-
Ein ganz merkwürdiges Problem!
Neuerdings zeigt mir mein MegaST nicht mehr alles in Textdarstellung untereinander an, was an Dateien auf der Platte liegt. Für zwei Dateien muß ich nach rechts scrollen.
Schalte ich in den Bildmodus, sind die Dateien normal sichtbar
Der MegaST hat TOS 1.04
Hatte jemand eine Idee dazu?
-
Du hast ja auch neuerdings eine höhere Bildschirmauflösung, dank Mega4000, richtig?
Zwei Spalten bei der Textdarstellung ist das normale Verhalten, wenn Du mehr als 640 Pixel in der Breite zur Verfügung hast.
-
Kann man das wieder ändern?
Ich bin bei sowas ein reines Gewohnheitstier. Das stört mich kolossal.
Die CrazyDots zeigt mir alles untereinander an, wie man es gewohnt ist. Allerdings läuft im MegaSTE
auch TOS 2.06.
-
Ich befürchte, ändern kann man das nur, wenn man TOS (bzw. den Desktop) patcht oder gleich auf TOS 2.06 wechselt. Der Darstellungsalgorithmus in TOS 1.x ist nicht besonders schlau und zeigt immer so viele Spalten, wie maximal auf den Bildschirm passen würden, unabhängig von der tatsächlichen Fensterbreite. Das ist im Icon-Modus und im Text-Modus so, bloß fällt es im Text-Modus normalerweise nicht auf, weil dort die zweite Spalte erst bei mehr als 640 Pixeln Breite angezeigt wird.
-
Vielen Dank, dann mach ich mich mal auf die Suche nach nem Patch oder Tool, womit ich die Darstellung ändern kann.
-
Andere Möglichkeit wäre vielleicht noch ein alternativer Desktop. Da gab es ja einige, auch wenn deren Namen mir gerade nicht mehr einfallen wollen.
-
Mein absoluter Favorit: Gemini ;-)
-
Ich befürchte, das es darauf hinauslaufen wird.
Eigentlich habe ich nichts gegen alternative Desktops, wenn sie nicht Speicher kosten würden.
Um Speicher zu sparen nehme ich NVDI 3.01, dann verbrate ich ihn mit nem alt. Desktop, weil mir die Textdarstellung unter TOS 1.04 nicht gefällt. :(
Wenn ich kein Tool oder Patch finde, probiere ich Gemini mal aus.
Welcher Desktop hat wohl den geringsten Speicherbedarf?
-
Arbeitsspeicher bei einer 4MB Maschine ist ja ein Thema ...
Alternativ würde ich vielleicht ein TOS 2.06 ins Ram laden mit Hilfe des TOS Patch Paketes von Markus Heiden. So ein Desktop verbraucht ja auch einiges an Speicher. Vielleicht mal ältere probieren wie EASE oder der gleichen ...
-
Was spricht denn dagegen, TOS 2.06 in den Mega ST zu packen?
Wenn ich das richtig verstanden habe, sortiert TOS 2.06 "richtg". Oder doch nicht?
-
Es handelt sich nur um meinen Bastel-Rechner, wo nach und nach mal Erweiterungen rein kommen, wenn es sich so ergibt.
Wenn das Projekt mit der Magnum ST klappt, fliegt die 4MB Marpet raus und mit der Magnum kommt dann auch automatisch TOS 2.06.
Deshalb macht es noch keinen Sinn.
-
Das ist ein Normales Verhalten was man sieht wenn die Auflösung größer als ST-Hoch ist, selbst am TT kenne ich das nicht anders, da wirst du dich aber daran gewöhnen, denn ich will meinen das machen alle Desktops.
-
Ich habe inzwischen zwei alt. Desktops ausprobiert.
Unter TOS habe ich 3,27 MB freien Speicher.
Kaosdesk: 3,14 MB freier Speicher
Anzahl der Spalten zur Dateianzeige passen sich der breite des Fensters an.
Ease: 2,51 MB freier Speicher
eine Spalte unabhängig von der Fensterbreite.
Ich teste noch! ;-)
-
Noch soviel freien RAM? Spiegelt der GK-Speicher nicht in den ST-Speicher?
Grundsätzlich kannst du auch Speicher sparen, indem du in alternativen Desktops monochrome Icons benutzt.
Wenn ich Thing mit NVDI 2,5 benutze habe ich noch 3196300 bytes frei (von 4Mb). Anzahl der Spalten zur Dateianzeige passen sich der breite des Fensters an.
Nachtrag: Immerhin lässt sich in Thing die Sortierung der Spalten besser einstellen, anstatt
a.txt b.txt
c.txt d.txt
e.txt f.txt
sortiert Thing auf Wunsch so:
a.txt d.txt
b.txt e.txt
c.txt f.txt
-
Bei 4MB ST Ram habe ich bei 256 Farben und 800x608 unter TOS 2.06 im ROM noch so etwas über 2,6MB an freien Speicher ohne alles ausser NVDI 5 ...
-
Ich denke, dass Teradesk noch am wenigsten Speicher schluckt. Zumindest läuft Teradesk auch auf einem 520er.
-
Thing und Gemini werde ich auch nochmal ausprobieren.
Das sich NVDI 5 alleine 1,4 MB Speicher nimmt, das ist bei einem Ausbau von 4 MB immerhin etwa 1/3 des Gesamtspeichers, finde ich zu viel.
Zumal wir das Thema neulich schonmal hatten und feststellten, das NVDI 5 keine Grafikbeschleunigung in den hohen Auflösungen hat, Version 3 aber wohl, wenn ich mich recht erinnere.
Das stand sogar im Handbuch zur CrazyDots.
-
Ich habe einige Desktops durch und wollte noch kurz meine Ergebnisse mitteilen.
Alle die ich ausprobierte, haben kein Problem die Darstellung der Dateien anzupassen, oder untereinander darzustellen.
Gemini 1.1: 3,02 MB frei
Tera 4.06: 3,06 MB frei
TOS 2.06 zum nachladen: 2,69 MB frei
Multi Tos: 2,38 MB frei
Neodesk war unter 800x608x256 nicht zu gebrauchen. Bild war völlig verzerrt.
Ich werde wohl Tera-Desktop oder Gemini benutzen.
-
So, ich habe in den letzten 3 Stunden oder so mal TOS 1.04 ein wenig disassembliert, bis ich die Stelle gefunden habe, an der die Zahl der Spalten in der Text-Darstellung auf dem Desktop berechnet wird.
Ich habe das dann mal so gepatcht, dass es auch bei 1024 x 768 Pixeln nur eine Spalte darstellt, wie hier gewünscht. (Die Icon-Darstellung ist selbstverständlich unverändert.)
Zumindest im Emulator funktioniert es. Die Screenshots belegen den Erfolg. An echter Hardware kann ich es nicht testen.
@ditto: Kannst Du TOS-(EP)ROMs brennen, um den Patch einzubauen? Sonst muss ich mal gucken, wie man entweder GEMRAM (lädt nur das GEM ins RAM) oder einen der RAM-TOS-Loader verwenden kann, um meinen Patch anzuwenden.
-
Klasse Idee.
Hier im EmuTOS192de ist es auch im Textmodus einspaltig.
-
Es gibt doch schon TOS Patch, kannst du deinen Patch nicht da einbauen ?
-> http://www.markusheiden.de/atari/tospatch.html
-
Es gibt doch schon TOS Patch, kannst du deinen Patch nicht da einbauen ?
-> http://www.markusheiden.de/atari/tospatch.html
Aber dann doch ist meine Namensnennung weg. ;)
Nein, ernsthaft, ich denke, ich kann den Patch dort einbauen.
Bei der Gelegenheit ist mir etwas ganz anderes ausgefallen: Das deutsche TOS 1.04 auf meinem 1040STF (wurde so weit ich weiß vom Vorbesitzer dort eingebaut) ist vom 22.02.1989. TOS Patch erwartet ein deutsches TOS 1.04 vom 06.04.1989, dessen Image man auch im Netz findet. Die Liste auf http://www.atarimuseum.de/tos.htm (http://www.atarimuseum.de/tos.htm) nennt beide Daten für TOS 1.04. (Mein Patch lässt sich auch in beide Fassungen einbauen, nur die zu patchende Adresse ist etwas anders.)
Was also habe ich da auf meinem ST? Eine Pre-Release-Version?
-
Also wirklich, den ganzen Tag nicht viel los. Da sitzt man mal nen paar Stünchen vorm Fernseher, werden gleich neue, bahnbrechende Erkenntnisse gepostet! :D
Wirklich tolle Arbeit, czietz!
Diese Dinge sind für mich wie Chinesisch sprechen. Ich weiß genau, das ich das niemals können werde. Es gibt hier schon einige Talente auf dem Board, wirklich beeindruckend!
Zudem stelle ich immer wieder fest, daß ich mir nen Eprom-Brenner kaufen muß! Leider habe ich keinen und entsprechend auch keine EProms. Kann man daraus nicht nen Mini-Patch für den Autoordner machen? Das wär mir zumindest auf die Schnelle am Liebsten.
Wenn ich das TOS 2.06 nachlade, lande ich bei 2,69 MB freiem Speicher. Das schmerzt schon etwas.
-
Was also habe ich da auf meinem ST? Eine Pre-Release-Version?
Irgend sowas in der Richtung, siehe auch http://toshyp.atari.org/de/010007.html (http://toshyp.atari.org/de/010007.html).
-
Zudem stelle ich immer wieder fest, daß ich mir nen Eprom-Brenner kaufen muß! Leider habe ich keinen und entsprechend auch keine EProms. Kann man daraus nicht nen Mini-Patch für den Autoordner machen? Das wär mir zumindest auf die Schnelle am Liebsten.
Wenn ich das TOS 2.06 nachlade, lande ich bei 2,69 MB freiem Speicher. Das schmerzt schon etwas.
Es gibt leider keinen Betriebssystemaufruf, den ich für den Patch abfangen könnte, sondern ich muss direkt den Code des Desktops patchen. Dafür muss der Desktop im RAM und nicht im ROM liegen. Somit ist ein Mini-Fix (wie z.B. Ataris TOS14FIX.PRG für andere TOS-1.04-Bugs) dafür nicht machbar.
Mit dem von Frank vorgeschlagenen TosPatch ließe sich recht einfach eine RAM-Version des TOS 1.04 mit Patch bauen, die allerdings auch "nur" 64 kB weniger RAM benötigen würde als ein komplettes TOS 2.06 im RAM. Die bessere Lösung wäre, zu verstehen, wie GEMRAM funktioniert. Das lädt immerhin nur das GEM (VDI + AES + Desktop) ins RAM, nicht das komplette TOS.
Irgend sowas in der Richtung, siehe auch http://toshyp.atari.org/de/010007.html (http://toshyp.atari.org/de/010007.html).
Dort steht für die Version vom 22.02.1989 auch nur "Rainbow"-TOS mit den selben GEMDOS- und AES-Versionen wie beim 06.04.1989. Weiß jemand, was die Unterschiede sind?
-
Uff, so einiges Disassemblieren, Coden und Debuggen später habe ich doch einen Weg gefunden, das ganze als kleines, speichersparendes Patch-Programm zu implementieren. Für die Experten: Ich klinke mich in den Line-F-Handler ein, der in TOS 1.04 ja unter anderem vielfach vom AES aufgerufen wird und modifiziere dann die desktop-interne Variable, die die Anzahl an Spalten in der Text-Darstellung enthält auf 1.
Jedenfalls präsentiere ich hiermit DESK1COL.PRG V. 0.5, mit dem der TOS 1.04 Desktop unabhängig von der Bildschirmauflösung (also auch bei mehr als 640x400 Pixeln) im Text-Modus nur eine Spalte darstellt. Das Programm belegt dauerhaft ca. 700 Bytes(!) RAM und kann z.B. im AUTO-Ordner, aber auch durchaus noch später aus einem schon gebooteten System heraus, aufgerufen werden.
Hinweise: DESK1COL.PRG braucht ein deutsches TOS 1.04 vom 06.04.1989. Es lässt sich nur durch Reset wieder deinstallieren. Im Emulator tut es was es soll. Ich konnte keine Nebenwirkungen feststellen, übernehme aber keine Garantie, dass es wirklich fehlerfrei ist. Daher: Erst einmal vorsichtig testen.
-
FANTASTISCH!
Es funktioniert einwandfrei!
Ich habe es in den Auto-Ordner gelegt, neu gebootet und .......alle Dateien untereinander aufgelistet!
Der Speicherverbrauch ist so gut wie nix. Es sind immernoch 3,27 MB frei. Also höchstens ein paar Byte.
Für mich ein erstklassiger Patch, ohne den mein Mega ST mit der Mega4000 auf keinen Fall mehr starten wird!
Vielen, vielen Dank für deine Arbeit und die Zeit, die du investiert hast.
Was mich wirklich wundert, das es über 25 Jahre dauerte, das jemand so einen klasse Patch programmiert hat! :D
-
Ich werde mich von meinem 1024er trennen. Czietz kann bedeutend mehr mit der kiste anfangen als ich. Damit kannste deine roms anpassen und flashen, wie du willst. Sd adapter lass ich drin mit den ganzen partitionen. Bei dir isser besser aufgehoben. Schick mir bitte deine adresse per pm.
-
Zumal wir das Thema neulich schonmal hatten und feststellten, das NVDI 5 keine Grafikbeschleunigung in den hohen Auflösungen hat, Version 3 aber wohl, wenn ich mich recht erinnere.
Das stand sogar im Handbuch zur CrazyDots.
Hm? Wieso sollte das so sein? Genaues Zitat? Es widerspräche allen meinen Erfahrungen mit NVDI, und ich wüßte auch nicht, warum die Behnes das für hohe Auflösungen wieder deaktiviert haben sollten?
-
http://dev-docs.atariforge.org/files/CrazyDots.pdf
Im PDF-Dokument Seite 17, im Handbuch Seite 33
8. Optionales NVDI
Ok, nur die monochromen Auflösungen werden beschleunigt, was bei einer Grafikkarte in den hohen Auflösungen trotzdem unschön ist.
Deine Erfahrungen mit NVDI 5 basieren in den hohen Auflösungen nur auf der monochromen Darstellung?
-
Das zählt aber nicht für NVDI Et4000 ...
@czietz, gute Lösung
-
@czietz: Super Programm, klasse ...
Fehlt noch das Cookie ;-)))
-
Das zählt aber nicht für NVDI Et4000 ...
Von NVDI 5 gibt es meines Wissens nach keine ET4000 Version.
Aber du hast völlig Recht. Wenn man eine 3er oder 4er Version von NVDI ET4000 einsetzt, werden Monochrom und auch Farbauflösungen beschleunigt.
-
Von NVDI 5 gibt es meines Wissens nach keine ET4000 Version.
Es gibt keine speziellen Versionen mehr, sondern ist alles zusammengefasst.
-
Jedenfalls präsentiere ich hiermit DESK1COL.PRG V. 0.5, mit dem der TOS 1.04 Desktop unabhängig von der Bildschirmauflösung (also auch bei mehr als 640x400 Pixeln) im Text-Modus nur eine Spalte darstellt.
Der Vollständigkeit halber: Ich habe noch einen Bug gefunden. Er trat nur auf, wenn man DESK1COL unter einer ungeeigneten TOS-Version starten wollte, wobei sich das Programm (nach einer Fehlermeldung) mit einem Adressfehler (3 Bömbchen) verabschiedete. Ist in der angehängten Version 0.6 gelöst. Sonst haben sich keine Änderungen ergeben.
-
Es ist sogar nochmal 2 Byte kleiner! ;)
Warscheinlich habe ich die richtige TOS-Version, da ich bisher keinerlei Probleme mit dem Patch hatte.
Klasse, ich danke dir.
Liebe Grüße und ein schönes Weihnachtsfest,
Volker