atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: ATARIaner am Sa 21.05.2022, 12:19:58
-
Hallo,
nachdem mein Adapter kam und ich den entscheidenden Tip bezügl. der Treiber erhielt, läuft o.g.Rechner mit 1024x768/256 - soweit - so gut…
Mit NVDI kämpfe ich noch, zumindest was „Redirekt“ usw. angeht, aber mit dem T0-Treiber kann ich NVDI aktivieren und es funktioniert grundsätzlich.
Jetzt wollte ich natürlich MagiC in Größe und Farbenpracht genießen, aber da geht garnichts… - und nach dennVersuchen auch nicht mehr im Standard-TOS-Modus?!?
Erst als ich die originalen T0-Treiber erneut in den Auto-Ordner kopiert hatte, ging es wieder in VGA im Standard-TOS-Modus, mit NVDI aber nur noch mit 2 Farben?!?
Wo ist mein Fehler?
Gibt es da vielleicht eine fertige Anleitung?
Danke schon mal
Schönes Wochenende
-
Man kann NVDI5 mit der Option NOVA installieren und zusammen mit dem Nova Treiber nutzen. NVDI läuft dann nur als GDOS. Oder man nutzt NVDI5 mit der Option ET4000 als Treiber zusammen mit der NVDIVGA.INF im Autoordner, das ersetzt komplett den Nova Treiber. NVDI ET4000 ist aber nicht ohne und bis die Installation läuft schwierig. Es gehen mit NVDI ET4000 auch weniger Karten als mit dem Nova Treiber. NVDI ET4000 ist ein wenig schneller als der Nova Treiber.
MagiC läuft problemlos zusammen mit dem Nova Treiber. Am muss mit der Reihenfolge im Autoordner spielen ...
-
Hallo, gut, dann spare ich mir den Kampf mit NVDI direkt, zumindest bis zu dem Zeitpunkt, wo ich denke, mir fehlt etwas…
Dann werd ich wohl das Fahrrad neu erfinden müssen, wenn nicht noch jemand das Geheimnis der Reihenfolge lüftet…
Jetzt versuche ich erst einmal, beide VGA-Signale (ST-Hoch-Adapter/ET4000) an je einem Eingang vom Monitor darzustellen…
MfG
-
Probiere mal
1. Emulator Programm
2. MagiC Booter
3. Menü Programm
4. Sta_vdi Programm
und die beiden BIB Files. NVDI kommt nach Sta_vdi meine ich.
-
So, mal ein Update…
Wenn ich die 3 Programme aus dem T0-Treiber-Paket nehme, habe ich 1024x768/256…
Wenn ich NVDI hinzunehme (Standard-Installation) und es vor STA_VDI starte, hab ich 1024x768/256…
Starte ich NVDI nach STA_VDI, habe ich nur 2 Farben…
Installiere ich NVDI neu und wähle Mega4000, fehlt die NVDIVGA.INF. Wenn ich diese mit dem VMG erzeuge und die möglichen Monitor-Frequenzen eintrage, kommt nichts über die Grafikkarte - damit könnte ich ja leben, da eine Variante mit NVDI ja funktioniert…
Egal, an welcher Stelle ich MagixBoot starten lasse, „…fataler Fehler“ und etwas mit „GEMDOS“
Hat niemand eine ET4000 im MegaST und könnte mal (s)eine funktionierende Reihenfolge preisgeben.
MfG
-
Frage:
Dein Problem ist dass MagiC nur in 2 Farben oder garnicht läuft ?
-
Standart NVDI mit Nova Treiber funktioniert nicht. Entweder im GEMSYS Ordner alle "NVDIDRVx.SYS" Dateien in NVDIDRVx.SYZ umbenennen oder alles löschen und NVDI5 neu installieren mit der Option "NOVA" ...
MagiC mit Nova läuft. Nimm mal das MagiC von Thorsten Otto ...
-
Habe es mal probiert neu zu installieren und mir ist es nicht gelungen. Ohne NVDI geht gar nichts (Offscreen Treiber nicht gefunden) und mit NVDI (Nova) geht es nur in Mono. Ich vermute mal es braucht einen NVDI ET4000 als Treiber anstatt dem Nova Treiber?
-
Ich fasse mal auf die letzten 3 Antworten bezogen zusammen:
Die T0-Treiber funktionieren tadellos und ohne weiteres Zutun…
Wenn ich Standard-NVDI (ohne NOVA und/oder ET4000-Option) nach EMULATOR & MENU aber vor STA_VDI starte, hab ich auch 1024x768/256.
Starte ich Standard-NVDI nach STA_VDI, hab ich 2-Farbe-Modus.
Wenn ich es mit MagiC versuche, ist es egal, ob ich NVDI mitnehme oder nicht und es ist auch egal, an welcher Position MagXBoot startet - Fatal Error …
Ich hatte dann noch NVDI neu installiert, mit ET4000-Option - erst fehlte die NVDIVGA.INF und als ich diese erstellt und mit den Daten zu MegaBus-Karte und Monitor entsprechend gefüttert hatte, war das beste Ergebnis der 2-farb-Modus…
Ich werde noch einmal alles von NVDI löschen und es mit einer frischen komplett-Installation testen, befürchte aber, daß die Grafikoption garnicht angeboten wird, wenn die Treiber nicht geladen sind…
Auf Basis der letzten Info, werd ich den Versuch mit der NOVA-Option auslassen…
Mit freundlichen Grüßen
-
Hmm...
Ich hab MagiC 6.2 grade eben mal selber installiert: https://forum.atari-home.de/index.php/topic,17019.0.html (https://forum.atari-home.de/index.php/topic,17019.0.html)
Der Rechner läuft erst seit heute Mittag, also bin ich selber noch dabei rauszufinden was geht und was nicht funktioniert.
Welche Zusätze hast du denn in deinem Mega ST verbaut ?
-
In meinem MegaST4 sind folgende Komponenten verbaut:
- LightningST
- Cloudy
- Stormy
- MegaBus-Adapter mit ET4000 (T0-Treiber)
Die aktuellen Versuche liefen unter EmuTOS.
Werde es noch mit TOS2.06 gegentesten…
Mit freundlichen Grüßen
-
Also das so ziemlich genau das selbe wie in meinem Mega.
Ich würde es gerne mit EMU testen, hab aber gestern bemerkt dass bei mir 4x TOS 2.06 installiert sind ?!?
Zumindest bietet mir TOSWITCH_4 nur 4x TOS 2.6 an ?!?
-
Also mal ganz Langsam!! Wie Frank schon schrieb!
NOVA VDI konfigurieren, danach dann NVDI Installieren und NOVA auswählen dann werden die Grafiktreiber deaktiviert. Hier läuft bringt NVDI nur noch die GDOS Funktionen hinzu! Also keine andere Geschwindigkeit!
Du kannst nicht beide VDI Treiber installieren das geht nicht! Also wenn dann NVDI mit NOVA VDI Installieren!
Nova VDI läuft wesentlich besser als das NVDI VDI!!!
-
Nova VDI?
Die T0-Treiber sind doch ET4000-VDI, oder bringe ich da etwas durcheinander?
Mit freundlichen Grüßen
-
Alle Treiber von da sind NOVA Treiber ...
https://silicon-heaven.org/atari/nova/
NVDI ET4000 ist z.B. ein NVDI5 mit der Option ET4000 installiert.
-
Mein Fehler, bin auch schon darüber gestolpert, daß die Treiber sich mit NOVA melden…
Obwohl ich eine ET4000 auf dem Adapter habe, soll trotzdem die NOVA-Option bei Indtallation von NVDI5.03 gewählt werden?
Dann werd ich das mal versuchen, hab gerade ALLES, was mit NVDI, MagiC usw. zu tun hat komplett runtergeschmissen…
Na dann schauen wir mal, was das jetzt bringt…
MfG
-
NVDI5.03 gerade frisch installiert - mit NOVA-Option - keine Grafik mehr, auch nicht mehr wenn ich NVDI deaktiviere.
Alle Dateien aus dem T0-Treiberpaket wieder drübergebügelt - nach Neustart wieder 1024x768/256?!?
Eine Idee, was das sein könnte?
MfG
-
NOVA-Option bei der Installation von NVDI heisst schlicht und einfach daß NVDI selbst *überhaupt* keine Screen-Driver installiert. Die müssen dann nachträglich von der NOVA-Distributon installiert werden.
-
Die waren ja schon installiert, ich habe die NVDI-Installation mit aktivierter VGA-Karte gestartet.
Nach der NVDI-Installation und Neustart kam nur noch im ST-Hoch der Hinweis, daß NOVA… installiert wurde, aber über VGA kam nichts mehr.
Hab dann die Treiber aus dem T0-Paket erneut in den AUTO-Ordner kopiert und nach Neustart auch wieder VGA-Modus verfügbar.
Ich kann jetzt auch NVDI wieder aktivieren (nach MENU.PRG und vor STA_VDI.PRG) und habe VGA 1024x768/256
Nach der Installation von MagiC6.20 und Neustart kommt Fehlermeldung „Fataler Fehler im Gemdos“
Bisherige Versuche unter EmuTOS, werde jetzt TOS2.06 gegentesten…
MfG
-
Unter TOS2.06 kommt, wenn überhaupt etwas kommt, 2 Bomben kurz nach MagXBoot - dabei ist es egal, an welcher Stelle MagxBoot gestartet wird…
Das ist ein Dämpfer, gerade unter MagiC wäre diese Auflösung Gold wert…
-
Die MagiC-Installation selbst ist fehlerfrei, sobald ich die NOVA-Treiber deaktiviere, startet MagiC durch und es ist egal, ob TOS2.06 oder EmuTOS vorher aktiviert wurde…
-
Hast du es mal mit TOS 1.04 versucht?
-
NVDI ET4000 + MagiC 6.20 funktioniert einwandfrei gerade probiert mit einem VOFA ET4000 Adapter ...
-
Ja... jetzt gehts bei mir auch nimmer...
Der MagiC-Booter bleibt kommentarlos stehen...
Entweder EMU-TOS, oder wenn mit MinT jemand näherbringen kann, dann eben doch die Nerd-Variante...
-
Bei mir wie oft geschrieben ohne Probleme. MagiC 6.20 + Nova Treiber + NVDI5 (NOVA) ...
Reihenfolge: Magixboot, emulator, xmenu (menu), sta_vdi, nvdi
-
Ohne NVDI (NOVA) geht es auch ...
-
Ich sag jetzt ned was ich falsch hatte... läuft bei mir auch wieder so wie gestern ohne dass ich selber an irgendwas rumgepfuscht hatte... also meine beiträge bitte vergessen.
Selbes Setup wie beim ATARIaner (auch T0-Treiber)... nur eben "bisserl schneller"...
-
TOS1.04 hab ich nicht mehr drin, wozu auch?
Mit VoFaET4000? Ich habe den MegaBus StGA…?!?
Noch etwas kurioses festgestellt…
NVDI5.03 frisch installiert (ohne spezielle Grafik-Option), wird bei SysInfo auch angezeigt, aber Grafikkarte läßt sich nicht aktivieren.
Die T0-Treiber wieder drübergebügelt, Grafik geht, aber auch das NVDI-GDOS wird dann nicht mehr bei SysInfo angezeigt…
-
VOFA oder STGA ist egal, im Prinzip das gleiche. Habe nur die VOFA gewählt weil es da im NVDI ET4000 eine direkte Unterstützung gibt.
-
Heutiges Update:
Nach einigen Fehlversuchen, gelang es mir heute, NVDI5.03 zu installieren, ohne daß es nach der Aktivierung der Grafikkarte nicht mehr aktiv ist.
Jetzt wird bei SysInfo NOVA V3.01 und Speed V5.0 angezeigt - auch nach erneutem Start..,
Auch wenn ich jetzt ohne VGA starte, wird bei SysInfo korrekt NVDI V5.03 und Speedo V5.0 angezeigt.
Vorher war bei Aktivierung von VGA kei GDOS vorhanden und bei Neustart ohne VGA nur noch „intern“ bei VDI und auch kein GDOS….
Jetzt werd ich ganz mutig MagiC probieren, vielleicht wird es ja jetzt etwas…
-
Hier sind die aktuellen Snaps von Thorsten Otto (eine 2021 hatte ich auch benutzt) ...
https://tho-otto.de/snapshots/magicmac/
-
Warum auch immer, jetzt, nachdem die NVDI-Installation ein anderes Ergebnis hatte, hat es auch mit MagiC6.20 geklappt - 1024x768/256 - schöne Arbeitsfläche…
Das Problem war vermutlich die NVDI-Installation vom 5.03 Update-Medium (eine HD-Diskette) - nachdem ich der 5.03 die „fehlende“ Datei „Disk2.SFX“ von meiner V5.0 (zwei HD-Disketten) hinzugefügt hatte, funktionierte es, wie beschrieben. Ich hab auch keine separate Grafikoption gewählt…
Ich vermute mal, daß die Dateien aus dem Snapshot einfach über die installierten drüber kopiert werden, oder doch vor der Installation auf dem Installations-Medium ersetzen?
Was mir negativ auffiel - EmuTOS erkennt die 8MB Alt.-RAM ohne Probleme, aber nach dem Start von MagiC waren sie nicht da. Ich muß es beim Start von MagiC noch einmal initialisieren - wenn man es weiß kein Problem, gab aber kurzzeitig ein weiteres Fragezeichen auf dem Kopf…
Mit freundlichen Grüßen
-
Ich vermute mal, daß die Dateien aus dem Snapshot einfach über die installierten drüber kopiert werden, oder doch vor der Installation auf dem Installations-Medium ersetzen?
Kann man ja nur händisch kopieren. @Thorsten Otto bietet/hat vergessen keinen Installer an. Thorsten kann auch was dazu sagen ob es sich lohnt eine originale ASH 6.20 zu ersetzen?
-
Den Installer hab ich nicht vergessen, war aber zu faul den zu implementieren ;)
Teilweise hatte ich damit auch mal angefangen, aber das wäre echt ne Menge Arbeit, vor allem das alles zu testen. Zumal (in der Original-Version) die Dateien alle in 2 selbst-extrahierenden Archiven sind; das alles zu automatisieren (schliesslich will man das ja nicht nach jedem Build von snapshots händisch neu machen), ist nicht so ganz einfach.
Zumindest bei schon existierenden Installationen sollte man das eigentlich auch so hinbekommen. Die Verzeichnis-Struktur in den Archiven dürfte auf jeden Fall passen.
Ob es sich lohnt, muss man selber entschieden. Im Kernel selber sind ein paar Macken behoben, insbesondere im Zusammenhang mit FAT32 Dateisystemen. In Applicat habe ich mal auf Wunsch eines hier vormals wohl bekannten Users die Grenzen für die Verknüpfungen angehoben. In jedem Fall sollte die Version aber nicht schlechter sein als die originale ;)
-
Neue Dateien drüberkopiert und neue Probleme…,
Irgendwann lief es mit meiner Installation, incl. NVDI5.03 und VGA1024x768/256…
Dann schob ich die neuen Dateien rüber und seitdem gibt es komische Ergebnisse…
Die zusätzlichen 8MB der Stormy sind nur gelegentlich vorhanden, unabhängig davon, wann (wo) ich es nach Magxboot starte und auch egal, ob vorher TOS2.06 oder EmuTOS aktiv waren.
Ebenso merkwürdig, daß das Datum plötzlich unter MagiC 2072 ist und sich nicht einstellen läßt… jeder Versuch beendet nicht nur die App oder das CPX-Modul, nein COPS wird gleich mit rausgeschmissen.
EmuTOS und XBoot zeigen beim Start das korrekte Datum und lasse ich MagiC weg, hab ich unter TOS auch das korrekte Datum und kann es auch mit dem CPX verändern…
Was auch merkwürdig ist, wenn ich bei MagiC unter Einstellungen MGEDIT usw. eintrage und Einstellungen sichere, ist das bei Neustart nicht mehr vorhanden, obwohl ich sehe, daß die MagX.Inf mit dem aktuellen, wenn auch falschem Datum abgespeichert wurde…
Dann kommt auch Fehler bei MAGX.INF…
Ich werd es noch mal aus meiner Installation neu machen, aber ich befürchte, daß sich da ein Fehler eingeschlichen hat.
Wäre super, wenn jemand mal ein Foto vom Inhaltsverzeichnis (Treeview) der Originaldisketten machen könnte, einfach um es mal abzugleichen, ob beim Zusammenstellen etwas schief gelaufen ist.
MfG
-
So, alle Dateien von MagiC gelöscht und frisch installiert…
EmuTOS zeigt korrektes Datum, XBoot ebenfalls und das frisch installierte MagiC hat von Anfang an den Datum-Fehler 2072, jede erzeugte Datei, jeder erzeugte Ordner trägt dieses Datum…
Egal ob CLOCK.CPX oder eine APP zum Uhr stellen, keine Chance, das CPX verabschiedet sich unter Mitnahme von COPS…
Ich hab es mit TOS2.06 und EmuTOS als Basissystem getestet, sogar ohne Grafikkarte (ST-Hoch) und ohne Alt.-RAM - es macht keinen Unterschied…
Wenn doch die MegaST-Uhr vonTOS und egal wie, ohne MagiC korrekt erkannt, ausgewertet und gestellt wird, kann ein Hardwarefehler, die RTC betreffend, ausgeschlossen werden.
Bin gerade dabei, aus dem Snapshot von Github, eine Installation zu erstellen, aber an den 3 SFX-Dateien scheitert es momentan noch, da gehts heute Abend weiter…
Wer hat eine Idee
-
So, hab noch einmal den Falcon ausgepackt und angeschlossen…
Dort ist die gleiche Installation drauf, wie auf dem MegaST und was soll ich sagen, Datum stimmt, kann auch verändert und gespeichert werden und den Jinnee-Fehler mit der Menüleiste gibt es auch nicht…
Keine Ideen, was da faul sein könnte?
Schönes Wochenende
-
Hab es noch einmal neu installiert und nach der Installation die Dateien kontrolliert. Siehe da, die gerade von MagiC erstellte MAGX.INF hat das korrekte Datum..
Die Freude währte nicht lange, denn nachdem ich die Anordnung der Icons meinen Wünschen entsprechend angepaßt hatte und aus „sichern“ ging, hatte diese MAGX.INF wieder ein Datum von 2072…
Hab dann mal meine Backups durchforstet, und ein 6.1er gefunden.
Erst alles von 6.20 gelöscht, dann die Dateien aus dem Backup kopiert und nach einem Neustart war erst einmal alles so, wie es sein sollte. Nach den Einstellungen und Anpassungen gesichert, Datum paßt immer noch…
Werde jetzt mal die Dateien aus dem Snapshot von GitHub drüberbügeln, mal sehen, was dabei herauskommt…
MfG
-
Wenn da ein Bug in der Datums Vergabe ist wäre das wohl was für @Thorsten Otto ...
-
Ja, verfolge das schon seit ein paar Tagen, aber ich kann mich nicht erinnern beim auslesen der Uhr irgendwas geändert zu haben. Auch in der History hab ich nix dazu gefunden. Hört sich auch seltsam an, warum sollte die Datei erst das richtige Datum, und kurze Zeit später ein falsches haben?
Man bräuchte wohl mal ein Tool das die Register der Uhr ausliest, ohne sie irgendwie zu interpretieren, und sich das mal anschauen.
-
Es gab zumindest mal in der letzten Version ein Fehler mit der Echtzeituhr.
From: Andreas Kromke
Newsgroups: Maus.Computer.Atari.Software
Subject: MagiC 6.20 - Uhrenproblem
Maus-ID: A20624@B3
Maus-Ref: A10173@B3
Message-ID: <dc0fb4f6.0109120535.19a5082a@posting.google.com>
References: <dc0fb4f6.0109092314.64660ee5@posting.google.com>
Date: Wed, 12 Sep 2001 15:35:00
Organization: http://groups.google.com/
Gateway: Usenet Gateway @ B3
------------------------------------------------------------------------
Hat sich demnächst erledigt. Ich habe das Problem gefunden und werde
in den nächsten Tagen eine aktuelle Version an ASH schicken. Das
Problem betrifft tatsächlich ausschließlich die Atari-Version und dabei
nur die Mega-ST-Uhr, und zwar sowohl beim Auslesen wie auch beim
Stellen.
In der History zur 6 gibt es auch einen Eintrag (https://github.com/th-otto/MagicMac/blob/cdee5b0fdea0357438262f1a97b508d2467b4f93/doc/magix.6/history.6#L1666-L1670). Sollte somit erledigt sein. Was auch die Infos in der Maus Gruppe sagen. Ist zwar unwahrescheinlich aber vielleicht ist der Code nicht die letzte Version.
-
Update…
Da das Auslesen der Uhr unter EmuTOS und TOS2.06 klappt, egal wann ich einen Ordner oder eine Datei erstelle, gehe ich nicht von einem RTC-Problem aus.
Ich habe jetzt die Dateien aus dem Snapshot über die 6.1 drübergebügelt und kann feststellen, daß das Problem mit der Uhr bisher noch mehr auftrat.
Dafür gibt es 2 andere kuriose Dinge:
1. das ALTRAMON.PRG wird zwar ausgeführt, aber der Speicher von Snapshot-MagiC ignoriert. Dies passierte bei der installierten MagiC6.20 auch gelegentlich und dann war nur knapp 1MB RAM übrig.
Jetzt, mit dem Snapshot-MagiC kommt die Fehlermeldung zu wenig Speicher, was ich bestätigen kann und dann startet es normal in den MAGXDESK und hat dann über 2MB RAM frei?!?
Gibt es eine Idee, warum das Alt.-RAM völlig ignoriert wird?
In der LOG-Datei steht drin, daß das Programm gestartet wurde, wenn ich es unter MagiC erneut ausführe, kommt die Meldung mit …“already…“
MfG
-
Hallo, damit ist zumindest ein Hardware-Defekt gänzlich auszuschließen.
Es scheint dann wohl nur die MegaST-Uhr zu betreffen, da ich dieses Problem weder auf dem TT030, noch dem Falcon030 hatte.
Gibt es da evtl. einen Patch/Fix, den man drüberbügeln kann?
Wobei es bei der jetzigen Version nicht (bisher) mehr auftritt
MfG
-
Auch in den Original-Sourcen ist das BIOS-Datum schon 11.9.2001:
https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/-/blob/master/MagiC/KERNEL/BIOS/ATARI/MAGIBIOS.S#L196
Also gehe ich mal davon aus daß der angesprochene Fehler dort bereits beseitigt ist. Ohne zu wissen was da zuletzt geändert wurde, wäre das ziemlich rumgestochere, zumal es ja offensichtlich nur die MegaST Uhr betrifft.
Der Code zum auslesen/setzen befindet sich hier, falls da jemandem was auffällt:
https://github.com/th-otto/MagicMac/blob/cdee5b0fdea0357438262f1a97b508d2467b4f93/kernel/bios/atari/modules/clock.s#L149
-
Das können wir dann wohl als geklärt betrachten…
Fazit:
Der Fehler mit dem falschen Datum betrifft nur den MegaST und ist ein Fehler, der nur in der Version MagiC6.20 (2000) auftrat und ohne Änderung der Versionsnummer (2001) behoben wurde.
MiT freundlichen Grüßen
-
Fazit:
Der Fehler mit dem falschen Datum betrifft nur den MegaST und ist ein Fehler, der nur in der Version MagiC6.20 (2000) auftrat und ohne Änderung der Versionsnummer (2001) behoben wurde.
Yep.
Ich war der Meinung Du hättest die ganze Zeit schon den Snapshot genutzt.
-
Ich hatte auch vorher den Snapshot benutzt, aber vorher nicht alles gelöscht, sondern nur drüberkopiert. Das hatte aber kein Ergebnis gebracht, da der Rechner nicht mehr mit MagiC startete…
-
Ein update, vielleicht trägt das ja zu einer Lösung bei…
Hatte zuvor ein paar Sachen unter EmuTOS getestet und…
…hab es nun auch noch einmal mit der Snapshot-Version von 6.20 getestet, allerdings ohne zuvor die 6.20 zu installieren - einfach über die Dateien der 6.10 drüberkopiert.
Beim ersten Start kam der Hinweis, WINFRAME.RSC nicht gefunden (diese Meldung kommt immer beim 1. Start nach Kaltstart) und dann der Hinweis, es wäre zu wenig Speicher…
Nach einem Reset kam nur die Meldung, zu wenig Speicher aber nach der Bestätigung dieser Meldung kam MAGXDESK…
ich weiß nicht, was da im Hintergrund abgeht, aber die 8MB Altram sind bis auf 52byte verbraucht und 2,9MB ST-RAM sind noch vorhanden…
Unter 6.10 hatte ich eine ähnliche Menge ST-RAM, aber auch 3 oder 5 MB ALTRAM frei…
Das dürfte wohl kaum normal sein, daß die Snapshot-Version von 6.20 so viel RAM verbraucht, mal sehen, ob ich da was finde, was entsorgt werden kann.
Mit freundlichen Grüßen
-
Habe das mal versucht bei mir mit einer MagnumST, Habe nur Magicboot und MagnumST im Autoordner. Egal welches Programm der beiden als erstes läuft das mit dem Alternate Ram funktioniert nicht. Beim booten kommt der Magnum Treiber auf und macht einen Speichertest von den 8MB und es kommt die Meldung OK ...
@Thorsten Otto ... wo hat denn MagiC da ein Problem?
-
Versuche es mal mit 1-2 Warmstarts, ob das Alt-RAM dann da ist…
Ist zwar alles Andere als normal, aber eine Option…
MfG
-
Nein geht nicht.
-
Aha, da klappt bei mir, zumindest mit der snapshot-Version 6.20 und läßt sich auch replizieren…
Bei der 6.20 korrekt installiert, da kann ich auch so oft RESET drücken, wie ich will, da geht es nicht…
Dein Treiber wird aber auch bei Reset erneut geladen?
Merkwürdig ist es trotzdem…
-
Ich nutze eine Version von 2021 vielleicht liegt es daran oder am Magnum Treiber?
MagiC interessiert mich nicht.
-
MagiC interessiert mich nicht.
äm ja wie jetzt. Hast du das nur getestet um ATARIaner zu helfen?
@Thorsten Otto ... wo hat denn MagiC da ein Problem?
Ehrlich gesagt, im Moment keinen Schimmer. Man müsste sich wohl doch mal anschauen, was der Magnum-Treiber macht, und das in MagiC einbinden. Ansonsten wird es wohl immer Probleme mit der Boot-Reihenfolge geben.
Ich vermute einfach mal das das von dem (zwangsweisen) Doppel-Boot von Magic verursacht wird.
-
MagiC interessiert mich nicht.
äm ja wie jetzt. Hast du das nur getestet um ATARIaner zu helfen?
Ja wollte nur helfen, ich nutze MagiC überhaupt nicht. Leider gibt es keine Quellen der Magnum Treiber. Im EmuTOS ist ein Treiber drin ...
-
Ansonsten wird es wohl immer Probleme mit der Boot-Reihenfolge geben.
Ich vermute einfach mal das das von dem (zwangsweisen) Doppel-Boot von Magic verursacht wird.
[/quote]
Die Bootreihenfolge ändert sich doch wohl nicht mehr, egal wie oft der Auto-Ordner abgearbeitet wird…
Da MAGXBOOT ja einen Kaltstart auslöst, ist von EmuTOS ja auch das erkannte und angemeldete ALTRAM weg und das muß erst wieder durch ALTRAMON korrigiert werden, was es ja auch macht.
Wie sich ja zwischenzeitlich herausstellte, liegt der Fehler, überhaupt ken StormST-Altram zu benutzen an „meiner“ Installation von 6.20. Die Snapshot-Version, über die funktionierende Version6.10 drüberkopiert, erkennt und nutzt es nun auch, allerdings erst nach wiederholtem Warmstart. Negativ ist nur, daß das ALTRAM komplett belegt ist… ganze 52Byte sind noch frei - das kann ja auch nicht ganz stimmen…
Es werden nicht weniger Fragen…
MfG
-
@Thorsten Otto ... mit dem aktuellen Snapshot ...
-
@Lukas Frank : Ist der erste Screenshot "Fehler bei Maddalt" noch unter TOS (falls ja: welche Version?), oder bereits nachdem der MagiC-Kernel gestartet wurde? Der zweite Screenshot "Fremder Speicher" ist sicherlich nur ein Folgefehler. Die Magnum wurde durch den ersten Start ihres Treibers zwar aktiviert, aber nicht beim OS angemeldet und wird daher beim zweiten Start des Treibers für "fremden" Speicher gehalten.
-
Das erste Bild ist vom zweiten Bootdurchgang. Bootreihenfolge ist magicboot und danach magnumst Treiber. Das zweite Bild ist danach vom Desktop aus gestartet.
-
Sorry ...
Ein Schnellschuß von mir. Hatte noch ein TOS 1.04 auf dem Mainboard. Mit TOS 2.06 funktioniert alles wie es soll.
-
Geht nicht, gibts nicht… - aber das sollte doch MagiC egal sein, sollte…
MfG