atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: Nervengift am Mo 12.03.2018, 14:20:00
-
https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/blob/master/README.md (https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/blob/master/README.md)
Wenn ich das jetzt nicht ganz unrichtig verstehe, dann werden auch die Quellen von Magic für den Atari selbst veröffentlicht! :o Wenn dem so ist, wäre das mal echt ein dickes Ding und eine verdammt nette Aktion!
Die Quellen von Magicdesk 4 und 5 sind auf jeden Fall schon online und einiger anderer Magic-Bestandteile auch!
-
Ei, fein, da kommt ja so einiges!
-
Ich bin total aus dem Häuschen, ein Traum wird wahr, ich kann´s noch gar nicht fassen, ich glaub ich krieg Fieber... :'( :) :'( :)
MagxDesk 5.02 ist der von Magx_6.20, also die jüngste Version.
-
Wow.
.
.
.
Ich bin sprachlos.
Jetzt noch die MagiCNet Quellen von Vassilis dazu und MiNT kann einpacken ;-)
MfG
Ektus.
-
Wow.
.
.
.
Ich bin sprachlos.
Jetzt noch die MagiCNet Quellen von Vassilis dazu und MiNT kann einpacken ;-)
MfG
Ektus.
MiNT ist ja schon komplett Open Source und wird noch aktiv weiterentwickelt. Letzteres träfe auf Magic leider nicht mehr zu. Sollte sich letzteres aber ändern, könnte Magic tatsächlich wieder eine Rolle spielen, denke ich.
-
Bei sowas wären dann @czietz @mfro gefragt ;) wäre auf jedenfall eine echt coole Sache. Besonder für die neuen Entwicklungen die es demnächst mal geben wird. aka .....
-
Hää, kann man das dann für die Firebee portieren?
-
Bei sowas wären dann @czietz @mfro gefragt ;) wäre auf jedenfall eine echt coole Sache. ...
Da muss ich Euch - zumindest was meine Person und den Moment angeht - leider enttäuschen. Die Anzahl an Sachen, um die ich mich als Hobby zusätzlich kümmern kann ist leider begrenzt (und mein Herz schlägt für MiNT, ich bin mit Magic nie recht warm geworden).
Ganz abgesehen davon scheint der Upload (noch) nicht komplett zu sein - das wichtigste (der Kernel) fehlt noch. Trotzdem finde ich A.K.'s Schritt auch prima.
-
Hää, kann man das dann für die Firebee portieren?
Wenn alle Sourcen verfügbar sind sollte das gehen.
-
Ich find's gut, dass die Quellen offengelegt werden; wenn auch der Kernel da ist, vereinfacht das z.B. Fehlersuche/Debugging, wenn unter MagiC etwas nicht funktioniert. Aber für eine Weiterentwicklung der Sourcen habe ich beileibe auch keine Zeit. Da geht's mir wie mfro.
-
Ich rechne wie czietz damit, dass es in erster Linie die Fehlersuche vereinfacht. Möglich auch, dass die ein oder andere Routine in einem der anderen offenen Betriebssysteme Verwendung findet. Aber das hängt auch davon ab, unter welcher Lizenz die Quelltexte stehen - diese Entscheidung steht bei MagiC und Geneva noch aus. Mit größeren Updates rechne ich nicht.
Was ich mir wünschen würde, wäre VFAT-Unterstützung für EmuTOS...
-
Ich denke es ist Grundsätzlich abzuwarten wie was kommt.
Ich fand es interesant nicht nur im Disassembling zu sehen wie MagiC die EDITOBJ.SLB installiert. Dazu gibt es eine AES Funktion mit der man alte Funktionen ersetzen oder neue installieren kann. Womit auch genau klar wird warum die SLB nicht mit einem anderm AES funktioniert.
Möglich auch, dass die ein oder andere Routine in einem der anderen offenen Betriebssysteme Verwendung findet.
Kann ich mir nicht wikrlich vorstellen. MagiC ist, meines Wissens nach, komplett in Assembler geschrieben. Gerade bei den Dateisystemen steht es genau so in der Anleitung.
Ich bin auch mal auf die Struktur gespannt, die MagiC beim Milan nutzt um direkt ins TOS zu springen.
-
Ich denke es ist Grundsätzlich abzuwarten wie was kommt.
Ich fand es interesant nicht nur im Disassembling zu sehen wie MagiC die EDITOBJ.SLB installiert. Dazu gibt es eine AES Funktion mit der man alte Funktionen ersetzen oder neue installieren kann. Womit auch genau klar wird warum die SLB nicht mit einem anderm AES funktioniert.
Möglich auch, dass die ein oder andere Routine in einem der anderen offenen Betriebssysteme Verwendung findet.
Kann ich mir nicht wikrlich vorstellen. MagiC ist, meines Wissens nach, komplett in Assembler geschrieben. Gerade bei den Dateisystemen steht es genau so in der Anleitung.
Ich bin auch mal auf die Struktur gespannt, die MagiC beim Milan nutzt um direkt ins TOS zu springen.
Chatter ist eines der Programme, die diese "EDITOBJ.SLB" verwenden und infolgedessen nicht unter MiNT laufen. Ich finde, dass Chatter der beste IRC-Client der Atari-Plattform ist. Wäre echt nicht schlecht, wenn man jetzt mit der Offenlegung des Quellcodes von Magic Chatter z. B. auch auf MiNT protieren könnte.
-
Chatter ist eines der Programme, die diese "EDITOBJ.SLB" verwenden und infolgedessen nicht unter MiNT laufen. Ich finde, dass Chatter der beste IRC-Client der Atari-Plattform ist. Wäre echt nicht schlecht, wenn man jetzt mit der Offenlegung des Quellcodes von Magic Chatter z. B. auch auf MiNT protieren könnte.
Wäre es da nicht einfacher, am Quelltext von Chatter zu arbeiten? Im Gegensatz zu MagiC ist der komplett in C geschrieben...
-
Wurde schon was gesagt wegen dem Kernel?
-
Schade, dass es nicht weitergeht mit den Uploads auf Gitlab. Ich hätte gerne Einblick in die Kernelsourcen, um den Grund für diesen Bug im USB4TOS-Treiber zu verstehen, den ich für die Lightning-Nutzer umgangen habe: https://forum.atari-home.de/index.php?topic=14000.msg226321#msg226321
-
Schade, dass es nicht weitergeht mit den Uploads auf Gitlab. Ich hätte gerne Einblick in die Kernelsourcen, um den Grund für diesen Bug im USB4TOS-Treiber zu verstehen, den ich für die Lightning-Nutzer umgangen habe: https://forum.atari-home.de/index.php?topic=14000.msg226321#msg226321
Vielleicht hilft es ja, eine Fehlermeldung zu diesem Problem im Bugtracker auf Gitlab einzustellen? Dazu ist er schließlich da.
MfG
Ektus.
-
Ich hätte gerne Einblick in die Kernelsourcen, um den Grund für diesen Bug im USB4TOS-Treiber zu verstehen, den ich für die Lightning-Nutzer umgangen habe:
Kannst ja mal in einem anderen Thread schreiben was Du geändert hast.
-
Gerade kam ein neuer Schwung Daten von Andreas online:
https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/AES (https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/AES)
-
Fehlt nur noch der Entwickler, der Magic auf der Firebee zum Laufen bringt. ;D
-
Fehlt nur noch der Entwickler, der Magic auf der Firebee zum Laufen bringt. ;D
... und ausserdem noch VDI, DOS, und BIOS sourcen ;)
-
Fehlt nur noch der Entwickler, der Magic auf der Firebee zum Laufen bringt. ;D
... und ausserdem noch VDI, DOS, und BIOS sourcen ;)
Scheduler/Kern habe ich auch noch nicht gesehen.
-
Gerade kam ein neuer Schwung Daten von Andreas online:
https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/AES (https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/AES)
Und jetzt ist auch „MVDI“ dabei, VDI-Sourcen von den Behnes, für MagiC.
-
Und jetzt ist auch „MVDI“ dabei, VDI-Sourcen von den Behnes, für MagiC.
Wo findest Du dort die Sourcen? Unter https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/VDI liegen nur Binaries. Ich vermute, eben weil sie von Behne & Behne sind und nicht von Andreas Kromke.
-
Und jetzt ist auch „MVDI“ dabei, VDI-Sourcen von den Behnes, für MagiC.
Wo findest Du dort die Sourcen? Unter https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/VDI liegen nur Binaries. Ich vermute, eben weil sie von Behne & Behne sind und nicht von Andreas Kromke.
Jetzt komm mir vor dem ersten Tee nicht mit solchen Details ;-) Ja, die Sourcen fehlen noch. Wobei die Behnes früher nichts gegen OpenSource hatten, für ihren Code, nur konnten sie NVDI wegen div. 3rd-Party-Bestandteile (Vektorscaler) nicht freigeben, und auch manches aus dem Druckbereich war NDA-behaftet vom Druckerhersteller, IIRC.
-
Wo findest Du dort die Sourcen? Unter https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/VDI liegen nur Binaries.
Die Quellen sind nicht da. MagiC sollte man trotzdem schon erstellen können.
Versuche ich i.M. mit der Milan Version und da brauch ich das VDI nicht.
Ich vermute, eben weil sie von Behne & Behne sind und nicht von Andreas Kromke.
Nur bedingt. Der VT52 und die WDialog Funktionen sind auch von Sven und Wilfred Behne. Also einfach mal abwarten.
-
Und jetzt ist auch „MVDI“ dabei, VDI-Sourcen von den Behnes, für MagiC.
Wo findest Du dort die Sourcen? Unter https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/VDI liegen nur Binaries. Ich vermute, eben weil sie von Behne & Behne sind und nicht von Andreas Kromke.
Der Vollständigkeit halber: Seit drei Tagen sind tatsächlich auch die Sources von Magic-VDI verfügbar: https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/VDI/SRC. Offensichtlich habe nun auch die Behnes ihr OK gegeben.
-
Gnarf. Hätten die das nicht ein paar Tage früher machen können? MIttlerweile hatte ich die Sourcen auch schon rekonstruiert.
-
Ist mittlerweile alles vollständig?
-
Ist mittlerweile alles vollständig?
Mehr oder weniger, ja. Scheint aber noch ein paar Diskrepanzen zu geben, die Sourcen von mxvdiknl z.B. entsprechen nicht ganz dem was dort vorher als Objekt-File vorhanden war, und auch im AtariX-Paket verwendet wurde. Habs noch nicht ausprobiert, aber ich denke mal daß das so im moment nicht zusammen funktioniert. Es lässt sich aber ein MagicOS-Kernel damit bauen (ging aber auch schon vorher, mit den rekonstruierten Sourcen).
Was halt noch fehlt ist das eigentliche NVDI, die dort momentan verfügbaren Treiber sind nur für den Emulator brauchbar, und der GDOS-Part, Handling der Fonts etc. fehlt.
-
Was halt noch fehlt ist das eigentliche NVDI, die dort momentan verfügbaren Treiber sind nur für den Emulator brauchbar, und der GDOS-Part, Handling der Fonts etc. fehlt.
Jetzt muss ich als jemand, der sich mit MagiC nur rudimentär auskennt, nachfragen: Was meinst Du mit "nur für den Emulator brauchbar"? Die Treiber hier https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/VDI/SRC/MAGIC.DRV/MFA sind doch für die echte Atari-Hardware. Und NVDI (also Fonts, Druckertreiber etc.) war doch nie Teil von MagiC sondern immer ein separates Produkt, oder? Warum sollte also NVDI bei den MagiC-Sourcen fehlen?
-
Die Treiber hier https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/KERNEL/VDI/SRC/MAGIC.DRV/MFA sind doch für die echte Atari-Hardware.
Ja, aber es sind die Treiber von MagicMac, nicht die von NVDI. Dh. sie benutzen die internen Funktionen von mxvdiknl. Vermutlich sind die Treiber von NVDI ähnlich, aber wie du am Header der Dateien sehen kannst ist das auf jeden Fall eine deutlich ältere Version (basierend auf NVDI 3.0).
Und NVDI (also Fonts, Druckertreiber etc.) war doch nie Teil von MagiC sondern immer ein separates Produkt, oder?
Ja, klar. Wäre halt nur schön wenn man die dabei hätte, ohne hat man dann halt wieder mal kein GDOS, und damit keine Vektor-Schriften. Gerade auf einem Emulator, wo man dutzende von TrueType-Schriften des Hosts nutzen könnte, eigentlich jammerschade.
Aber zur Beruhigung: es ist durchaus möglich damit auch ein MAGIX.RAM für Atari-Hardware zu erstellen:
-
Now mixup EmuTOS and magic :D
-
Ja, klar. Wäre halt nur schön wenn man die dabei hätte, ohne hat man dann halt wieder mal kein GDOS, und damit keine Vektor-Schriften. Gerade auf einem Emulator, wo man dutzende von TrueType-Schriften des Hosts nutzen könnte, eigentlich jammerschade.
Aber zur Beruhigung: es ist durchaus möglich damit auch ein MAGIX.RAM für Atari-Hardware zu erstellen:
Hmmm, und Milan ja, aber Hades? Ich sehe das BIOS nicht. Ist es möglich?
-
Hmmm, und Milan ja, aber Hades? Ich sehe das BIOS nicht. Ist es möglich?
Milan BIOS lässt sich zwar übersetzen, ich bezweifle aber daß es funktioniert (https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/blob/master/MagiC/KERNEL/BIOS/MILAN/MILAN.S#L156)
Da dürfte noch einiges fehlen. Gab es Magic denn für Milan oder Hades mal?
-
Milan BIOS lässt sich zwar übersetzen, ich bezweifle aber daß es funktioniert (https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/blob/master/MagiC/KERNEL/BIOS/MILAN/MILAN.S#L156)
Da dürfte noch einiges fehlen. Gab es Magic denn für Milan oder Hades mal?
Ja, es gibt für beide ein MagiC und nein die oben zitierte Datei passt. Beim Milan erledigt einiges das TOS selbst, damit musste kein eigenes (X)BIOS ins MagiC.
-
Ja, Ich habe MagiC 6.20 in meinem Hades.
-
Beim Milan erledigt einiges das TOS selbst, damit musste kein eigenes (X)BIOS ins MagiC.
Ah ok. Sieht trotzdem seltsam aus, zumindest die Kommentare solte man mal anpassen dann. Braucht man dann auch zwingend NVDI? Sieht nämlich aus als ob dort auch keine VDI Treiber geladen werden.
Bei Hades hab ich nochmal geschaut, wenn ich das richtig sehe muss man dafür die "normalen" Atari-Sourcen übersetzen, aber HADES definieren. Ich gehe dann mal davon aus daß dort auch der Bootloader zum Einsatz kommt?
-
Now mixup EmuTOS and magic :D
Jo, nichts leichter als das bei ~7MB Assembler-Sourcen ;)
-
Now mixup EmuTOS and magic :D
Jo, nichts leichter als das bei ~7MB Assembler-Sourcen ;)
Du hast ja auch schonmal n Megabytes Modula-2 nach C übersetzt ;)
-
Du hast ja auch schonmal n Megabytes Modula-2 nach C übersetzt ;)
Das ist aber schon mehr als 20 Jahre her, man wird ja auch nicht jünger :D
-
Now mixup EmuTOS and magic :D
Jo, nichts leichter als das bei ~7MB Assembler-Sourcen ;)
War ja auch mehr als Joke gedacht ;)
-
Now mixup EmuTOS and magic :D
Jo, nichts leichter als das bei ~7MB Assembler-Sourcen ;)
War ja auch mehr als Joke gedacht ;)
Manchmal kann aus einem Scherz "bitterer" Ernst werden. ;D
-
Now mixup EmuTOS and magic :D
Jo, nichts leichter als das bei ~7MB Assembler-Sourcen ;)
War ja auch mehr als Joke gedacht ;)
Manchmal kann aus einem Scherz "bitterer" Ernst werden. ;D
Vielleicht war das ja meine Hoffnung ? :P
-
Hab ich da gerade "Magic" gelesen? :P
-
Hab ich da gerade "Magic" gelesen? :P
Die KI aus der Flasche! Man wünscht sich etwas und schon kommt ein neues Magic dabei raus (u. a. für die Firebee). 8)
-
schon kommt ein neues Magic dabei raus (u. a. für die Firebee). 8)
Hab ich irgendwas verpasst?
-
Eine berechtigte Frage, deren Antwort auch mich interessiert.
-
Na ja ... in Zukunft muss der Mensch nicht mehr so "triviale" Programmierungsaufgaben erledigen sondern es macht eine KI. Fragt sich dann nur wer die KI programmiert usw. usf. und irgednwie bekomme ich jetzt auch ein wenig Angst. :o
-
Nein aber vielleicht bekommt man ja noch ein paar Optimierungen rein, eventuell Modellabhängige Optimierungen z.b.
-
Hab ich da gerade "Magic" gelesen? :P
Er ist zurück!
-
Da hat man auf jeden Fall viel zu lesen, bei den Magic sourcen - bei so viel Assembly.
-
Nein aber vielleicht bekommt man ja noch ein paar Optimierungen rein, eventuell Modellabhängige Optimierungen z.b.
Das, oder einen besseren Netzwerkstack (von MiNT), der mit mehr Netzwerkkarten umgehen kann (CTPCI, Lightning).
Man darf doch noch träumen, oder (siehe Uhrzeit) ;)
MfG
Ektus.
-
Ihr träumt schon wieder von Leckereien - dagegen wäre ich schon glücklich, wenn ein paar Bugs (zB. der ´Zählfehler´) beseitigt und ein paar Schranken angehoben würden.
-
Iwenn ein paar Bugs (zB. der ´Zählfehler´) beseitigt und ein paar Schranken angehoben würden.
Welche genau meinst du da?
-
^^-- zB. die Beschränkungen im MAGXDESK auf je 200 Zuordnungen von Icons für Ordner, Prgs. & DataFiles *. Oder weitere Bugs in MAGX selbst, wie zB. der absonderliche Unterschied in der Behandlung von ColorIcons auf dem TT iGs. zum F30, oder ...
* Eine Erhöhung auf je 300 wäre schon hilfreich. Noch besser wäre es, das pätschen zu können (habe vergeblich nach einem Patch gesucht, aber anscheinend sind Grenzen durch feste Arrays vorgegeben und darum nicht pätschbar).
-
^^-- zB. die Beschränkungen im MAGXDESK auf je 200 Zuordnungen von Icons für Ordner, Prgs. & DataFiles *
Hm, benutzt denn MAGXDESK jemand? ^^ Das einzige was ich da auf die Schnelle sehe ist
#define MAX_ICNN 500 in Applicat.app.
Oder weitere Bugs in MAGX selbst, wie zB. der absonderliche Unterschied in der Behandlung von ColorIcons auf dem TT iGs. zum F30, oder ...
Das müsstest du schon genauer erläutern. Ein Unterschied war meine ich daß sie eine unterschiedliche Präferenz für 256-Color icons in 256-Color-Auflösung haben. Ansonsten benutzt MagiC die nvdi5.pal wenn das Resource-File selber keine hat, die erheblich unterschiedlich zu der Standard-Palette von MultiTOS ist. Das wird man aber nicht so ohne weiteres ändern können, wenn nicht fast alle Resourcen falsch dargestellt werden sollen. XaAES benutzt im übrigen glaube die gleiche Palette.
Und was meintest du mit "Zählfehler"?
-
Und was meintest du mit "Zählfehler"?
Vermutlich den Fehler bei der Ermittlung der freien Cluster bei FAT32, der nach Schreibzugriffen mit MagiC zuverlässig zu einer Warnung beim Filesystemcheck führt. IIRC wird der Wert irgendwo eingetragen und stimmt nicht.
MfG
Ektus.
-
^^-- zB. die Beschränkungen im MAGXDESK auf je 200 Zuordnungen von Icons für Ordner, Prgs. & DataFiles *
Hm, benutzt denn MAGXDESK jemand? ^^
Sicher. Alle mit 4 MB oder gar weniger RAM (2.5 etwa). Jeder andere Desktop ist viel viel RAM-hungriger.
Und ich fand den gar nicht schlecht. Sicher kann Jinnee mehr, aber zu anderen „Preisen“, sowohl auf einem 68000 oder eben mit 2.5 MB RAM.
Allerdings habe ich auf solchen Kisten aus den gleichen Gründen nur so zwei Dutzend Icon-Zuordnungen.
-
^^-- Auch aus diesem Grund fände ich es gut, wenn die genannten Grenzen pätschbar wären - obzwar jeder ´kleine´ Atari auf 4MB aufgerüstet werden kann und man deshalb auf solche mit nur 2,5MB nicht allzu viel Rücksicht nehmen muß.
Den MagxDesk habe ich immer noch in Benutzung - obwohl ich im F30 und erst recht im TT genügend RAM habe! -, weil er unter Betrachtung der Ergonomie imho von allen der Beste ist! Mit keinem andren kann man so effektiv und zugleich komfortabel die typischen AufräumArbeiten erledigen. Und schnell ist er im Vergleich auch noch: Den Unterschied merkt man sofort, wenn man zB. mal ein Dir.-Fenster mit 400 Einträgen öffnet. Schade, daß er an MAGX gebunden* ist.
Die Grenze von 500 Icons in Applicat.APP ist eine weitere Beschränkung von der genannten Sorte. Ich habe bereits 528 Icons in meiner Cicons.RSC und würde mir wünschen, daß sie mindestens auf 600 erhöht wird. Die von mir genannten Grenzen von je 200 Icon-Zuordnungen sind davon aber unabhängig, und aus meiner Sicht noch viel dringender erhöhungsbedürftig**; ich vermute eher, daß sie in MagxDesk.APP liegen. Während bei Überschreitung der 500er Grenze immerhin gewarnt wird (und die Icons jenseits der 500 dann bloß nicht mehr berücksichtigt werden), haben die drei 200er Grenzen iirc leider keine Warnungen und es kommt bei Überschreitung einfach zu Fehlleistungen.
Der Zählfehler iZshg. mit FAT32 wurde schon mal ausführlich diskutiert (-> Thread "MAGX´ Macken"). Das Ergebnis damals war immerhin, daß er keineswegs nur harmloser, kosmetischer Natur ist. Ob es ausreicht, nur ihn zu beseitigen, oder ob da noch ein weiterer Bug sitzt, das wird sich wohl erst entscheiden lassen, wenn der Zählfehler selbst beseitigt ist.
Der Bug in der Behandlung von ColorIcons auf dem TT hat mit der Palette*** überhaupt nichts zu tun (und höchstwahrscheinlich auch nix mit NVDI), sondern es handelt sich imho ganz offenbar um einen schlichten Bug in der Logik der Cicons-Routine des MAGX. Es gibt ihn nicht auf dem F30, und es gibt ihn nicht in Grafik-Auflösungen >= 8p, aber mit 4p auf dem TT sieht man ihn sofort, und zwar unabhängig vom Desktop: Anstatt die 4p-Images der Cicons darzustellen wird auf ´niedrigere´ Images regrediert. Den Aufwand, die Logik zu korrigieren, halte ich für begrenzt (bloß die Testerei ist nervig, wg. der mit GK nötigen Reboots). Ich hoffe, Thorsten, daß diese Erläuterung ausreicht?
* Ihn zu ´befreien´ wäre wohl etwas aufwändiger, als die Erweiterung der og. Grenzen?
** Denn leider hat der MagxDesk nur eine sehr verbesserungsfähige WildCard-Behandlung...
*** Wie man richtig mit Paletten umgeht, das sollten wir mal in einem anderen Thread diskutieren.
wie jüngst wieder offenbar wurde, gibt es da auch noch Bedarf an Aufklärung (aber nicht bei mir ::) ).
-
Schade, daß er an MAGX gebunden* ist. Ihn zu ´befreien´ wäre wohl etwas aufwändiger, als die Erweiterung der og. Grenzen?
Müsste man sich mal anschauen, ich denke mal es liegt im wesentlichen daran daß
- Die erweiterten AES-Funktionen vorausgesetzt werden. Dürfte sich durch Installation von wdialog.prg ausgleichen lassen. Hast du das schon mal probiert?
- Nachstarten und Kommunikation mit z.B. Applikat.app natürlich unter SingleTOS nicht funktioniert. Das dürfte sich nicht so ohne weiteres beheben lassen. Auch CHGRES, SHUTDOWN.PRG etc. funktionieren dann natürlich nicht.
- Was aber am schwerwiegensten ist: ist vlt. nicht so ganz offensichtlich, aber MAGXDESK selber hat keine Funktion zum kopieren/löschen von Dateien eingebaut, das wird durch nachstarten von MGCOPY erledigt. Auch das würde unter SingleTOS natürlich nicht funktionieren.
- Coloricons werden dann natürlich auch nicht dargestellt, wenn das AES es nicht kann
Die von mir genannten Grenzen von je 200 Icon-Zuordnungen sind davon aber unabhängig
Die Grenze hab ich immer noch nicht gefunden. Hast du vlt. mal ne Datei wo die Grenze nahezu erreicht ist?
Der Zählfehler iZshg. mit FAT32 wurde schon mal ausführlich diskutiert (-> Thread "MAGX´ Macken").
Ah ok. Hatte mich damals wohl nicht so interessiert, weil ich FAT32 nur auf dem PC hatte, und MagicPC das Dateisystem des Hosts nutzt. Schau ich mir mal an.
Den Aufwand, die Logik zu korrigieren, halte ich für begrenzt
Ja, denke auch. Frage wäre halt ob man es dann gleich MultiTOS-kompatibel macht (um überall das gleiche Erebnis zu bekommen) oder nicht. Weiss jetzt auch gar nicht so auf Anhieb was z.B XaAES da macht, müsste ich erstmal nachschauen. Oder zb. NAES.
(bloß die Testerei ist nervig, wg. der mit GK nötigen Reboots).
Naja, geht so. Wenn die "GK" ARAnyM heisst geht der Reboot eigentlich ganz flott ;)
-
^^-- Bin mal gespannt, ob Du den TT-Cicons-Bug im Emulator siehst* (habe da etwas Zweifel, aber wer weiß...).
-------
Das hatte ich befürchtet, daß auch Du, Thorsten, Dich gleich wieder auf die Leckerlis stürzt (die ich ebendieser Befürchtung wg. ganz klein geschrieben habe). Ich schlage vor, erst einmal Schritt für Schrittchen die einfacher zu erledigenden und wichtigeren Dinge anzugehen, zB. wäre die von Dir angesprochene 500er Grenze doch so etwas? Und danach sehen wir weiter... Ich halte nichts davon, erstmal einen großen Berg anzuhäufen - und dann bloß noch festzustellen, daß Zeit & Kraft ja leider, leider begrenzt sind...
Für die 200er Grenzen ist es wohl nötig, sich die Verarbeitung von Applicat.INF & Applicat.DAT anzusehen. Diese hier anzuhängen ist sinnlos ohne die zugeh. Icon-Resource (die ich ja nicht anhängen darf). Vielleicht kannst Du aufspüren, wo in Applicat.APP der Header (samt Kommentar) von Applicat.INF geschrieben wird und Dich von da zurückhangeln bis zu den Arrays. Schon möglich, daß die 200er Grenzen sowohl in Applicat.APP als auch in MagxDesk.APP zugleich hochgesetzt werden müssen. Für Applicat.INF und ~.DAT kenne ich leider keine Beschreibung; was in der .INF steht, das kann man sich mit etwas Phantasie ja noch selbst zusammenreimen, da ASCII, aber die .DAT ist leider ein Bin-File (und ist so dick, da sie vermutlich die ´aufbereiteten´ Icons enthält, also nur diejenigen aus der .RSC, die auch tatsächlich benutzt werden - da bin ich auch erst bei 312 angelangt, weshalb wg. der 500er Grenze zunächst mal eine Neu-Kompilation von Applicat ausreicht).
PS: Selbstverständlich habe ich die angesprochenen Versuche mit WDIALOG schon gemacht - und auch welche mit N_DLG54 (dem lt. FN besseren Ersatz dafür).
* Werde selbst zu einem neuen Anlauf mit den Emulatoren nicht vor Mitte Januar kommen.
-
Bin mal gespannt, ob Du den TT-Cicons-Bug im Emulator siehst*
Ja, muss ich mal schauen. Muss ich erstmal überlegen wie genau man das provozieren kann. Kann aber (halt ohne fVDI/NVDI dann) alle Falcon-Auflösungen darstellen.
Das hatte ich befürchtet, daß auch Du, Thorsten, Dich gleich wieder auf die Leckerlis stürzt
Hä? Wieso?
zB. wäre die von Dir angesprochene 500er Grenze doch so etwas?
Denke mal hab die anderen Grenzen auch gefunden. Mein Fehler war daß ich
#define MAX_PTHN 200
Für die maximal Länge von Programmnamen gehalten haben Scheint aber eine der von der angesprochenen Limits zu sein. Die anderen aind aber
#define MAX_PGMN 300
#define MAX_DATN 300
MAX_PGMN ist wohl die maximale Anzahl von Programmnamen, MAX_DATN die maximale Anzahl von Zuordnungen.
Wenn ich das richtig sehe sind alle diese Beschränkungen nur für APPLICAT relevant, MAGXDESK liest einfach nur die erzeugten Dateien ein. Einziger negativer Effekt die Limits zu erhöhen wäre also daß Applicat selber mehr Speicher braucht, Magxdesk ist davon nicht betroffen. Besser wäre natürlich die Limits ganz los zu werden, ich habe aber mal eine Version erstellt wo einfach nur die Werte geändert sind:
#define MAX_PGMN 400
#define MAX_DATN 400
#define MAX_PTHN 400
#define MAX_LINN 800
#define MAX_ICNN 700
Statischer Speicher erhöht sich dadurch von ~150KB auf ~220KB. Denke mal damit kann man erstmal leben.
die .DAT ist leider ein Bin-File (und ist so dick, da sie vermutlich die ´aufbereiteten´ Icons enthält
Ja, sieht so aus. Vermutlich schneller als die Resource-Datei zu laden, insbesondere wenn man mehrere benutzt.
auch welche mit N_DLG54 (dem lt. FN besseren Ersatz dafür).
Hm, kenn ich nicht. Ist das irgendwo frei verfügbar? BTW, WDIALOG hab ich mittlerweile auch rekonstruiert, inklusive der Drucker-Dialoge. Witzigerweise sind in der Atari-Version auch die Routinen drin um die nativen MagicMac-Dialoge aufzurufen. Was dazu führt daß AtariX an der Stelle kracht, weil die nur für den Apple-68k-Emulator ausgelegt sind. Gilt auch für nachladbare PDLG.SLB.
(edit: Anhang entfernt, neue Version weiter unten)
-
Hallo Thorsten,
wäre es den möglich eine Version zu Kompilieren ? Die eventuell zum Download zur Verfügung gestellt werden kann ? Müßte man eventuell die Seriennummerabfrage raus nehmen ?
Vielleicht erstellt man mal eine Liste oder nimmt das gitlab um bugs zu tracken ?
Ich meine wäre schon eine Coole sache.
-
wäre es den möglich eine Version zu Kompilieren ?
Ja, mittlerweile schon. Gab zwar diverse Schwierigkeiten (AK hatte die Verzeichnisse so tief verschachtelt daß Pure-C dauernd abgestürzt ist, das musste ich erstmal umorganisieren, utf8-Zeichen in den Dialogen sieht auch blöd aus, und irgendwie hat sich der Linker bei mir geweigert die EQUs die irgendwo exportiert wurden in anderen Modulen zu linken).
Die eventuell zum Download zur Verfügung gestellt werden kann
Ja, bin gerade dabei. Muss noch sehen daß alles auch in anderen Umgebungen funkioniert (momentan verwende ich ua. meine eigene PCGEMLIB und die passenden Header dafür). Ausserdem muss ich dann wohl ein paar Zeilen dazu schreiben.
Müßte man eventuell die Seriennummerabfrage raus nehmen ?
Die hatte AK schon entfernt. Da waren nur noch dummy-Routinen, aber die sind mittlerweile auch draussen.
Vielleicht erstellt man mal eine Liste oder nimmt das gitlab um bugs zu tracken ?
Ich werds wohl erstmal auf github hochladen, in meinen account. Dauert aber vlt. noch ein paar Tage.
-
Ich sage da schon einmal Danke an dich für deine Mühen :) Bin aktuell am TT-Beschleuniger Testen und wollte da auch unter Magic einige Tests anstellen. Aber meine Magic Installationen hauen irgendwie nimmer hin ... daher würde mir das sehr gelegen kommen :)
-
Hi Thorsten,
zunächst mal heißen Dank für das neue Applicat.APP.
Natürlich konnte ich trotz Zeitmangel nicht widerstehen, das Teil heute sofort auszuprobieren.
Zunächst die gute Nachricht:
Applicat startet - und die bisher übliche Meldung "Zu viele Icons" bleibt aus!
Und nun, leider, die schlechte:
Obwohl die 200er Grenzen noch nicht erreicht sind, stürzte das Prg. ab beim Versuch einer Icon-Zuweisung -> Anhang. Huch, welcher Fehler ist das? Meine Tabelle geht nur bis 67...
Upps, wieso ist denn das Bild im Anhang neuerdings so riesig?
-
Obwohl die 200er Grenzen noch nicht erreicht sind, stürzte das Prg. ab beim Versuch einer Icon-Zuweisung -> Anhang. Huch, welcher Fehler ist das? Meine Tabelle geht nur bis 67...
Hm, schlecht. Kann ich bei mir nicht reproduzieren. Allerdings ist meine RSC Datei auch deutlich kleiner. Könntest du mir vlt doch mal deine Dateien zukommen lassen? Wenns hier als Anhang nicht geht, gerne als PM.
Upps, wieso ist denn das Bild im Anhang neuerdings so riesig?
War das nicht immer so? Auf jeden Fall steht da bei dir in der APLICAT.INF
WINDOW ICONS 0,0,1004,724
Wenn du das Fenster verkleinerst, wird die Grösse auch beim nächsten Neustart genommen.
-
Mal 'ne Frage zu dem FAt32 Fehler: in dem zitierten Thread sehe ich einen Screenshot, in dem diverse READMEs zu sehen sind. Einige davon enthalten Kommentare von 2014. Sind das deine eigenen oder wo kommen die her? Die entsprechenden Texte kann ich jedenfalls weder im MagicMac noch im AtariX Verzeichnis finden. Was ich jedoch gefunden habe ist
20.2.2000
---------
- Der FSINFO-Sektor bei FAT32-Dateisystemen wird jetzt (hoffentlich)
korrekt behandelt. Das öffnen eines seit dem letzten Bootvorgang
nicht verwendeten FAT32-Laufwerks sollte jetzt deutlich schneller
Die letzte offizielle Version war denke ich vom 2.10.2000 (steht auch so in dem Screenshot).
-
^^-- Diese Textstelle kenne & kannte ich. Ob die darin ausgedrückte Hoffnung sich erfüllt hat, das ist aber unklar. Bitte führe Dich nicht selbst in die Irre, indem Du mit vorschneller Wortwahl von einem FAT32-Fehler sprichst. Unzweifelhaft, weil offensichtlich, gibt es diesen ´Zählfehler´, von dem ich im zitierten Thread schlüssig nachgewiesen habe, daß er keineswegs harmloser/kosmetischer Natur ist, wie manche DiskussionsTeilnehmer zunächst glaubten. Es handelt sich imho um einen Fehler in der Long-Arithmetik, vermutlich ein nicht berücksichtigter Überlauf oä. Ich weiß ja nicht, welche Long-A.-Routinen da benutzt werden, aber ich habe welche kennengelernt (-> Inline-ASM in TDI-M2), in denen ich selbst Fehler beseitigen mußte... - man weiß ja nie, wer von wem was wann & wo abgeschrieben hat...
Mit zu kleinen Partitionen (oder zu kleinen Füllungen derselben) siehst Du den Zählfehler nicht (oder doch? - weiß ich nicht mehr so genau).
Wenn Du Fragen zum alten Thread hast, müßtest Du schon mal etwas genauer sagen, welche Posting-# Du meinst (am besten genau diese # verlinken).
Meine MAGX-Version war übrigens wohl eine der letzten, die ASH überhaupt noch verkauft hat (viieeeel später als Anno 2000).
-------
Noch ein paar Nachbemerkungen zu obigem ScreenSnap (war gestern einfach zu müde dazu): Abgestürzt ist nicht das System, sondern ´nur´ das Applicat; wie man sieht, genau nachdem der Button ´Anmelden´ gedrückt und der Eintrag im Ordner-Fenster schon dargestellt wurde. Zu prüfen wäre imho, ob etwa durch die Erhöhung der Limits zB. eine 64k-Feldgrenze überschritten wird. Was bedeutet ´Fehler #-69´ genau? Vielleicht ´arithmetik overflow´?
Anhänge per PM sind nicht möglich (das solltest Du doch aber wissen). Ich hänge jetzt mal meine Applicat.INF und ~.DAT hier an; wenn ich mich nicht täusche, dann brauchst Du meine Icons.RSC gar nicht zum Test, sondern kannst mit einer beliebigen anderen weitermachen (das ist mir jetzt erst klargeworden), jedenfalls solange Du keine (alten) Zuordnungen löschst.
-------
Weiter frühestens übermorgen.
-
EINSCHUB:
Die angehängte .RSC ersetzt vorteilhaft das Original aus MAGX_6.2; sie sollte imho auch mit dem neuen Applicat.APP funzen; es muß min- eine neue Icon-Zuordnung erfolgen, damit sie wirksam wird! Verwendung wie immer auf eigene Gefahr. Damit kein Mißverständnis aufkommt: Den Test der neuen Version habe ich selbstverständlich mit der dabei liegenden -RSC gemacht.
-
Bitte führe Dich nicht selbst in die Irre, indem Du mit vorschneller Wortwahl von einem FAT32-Fehler sprichst.
In dem anderen Thread sprichst du von Datenverlust und/oder Fehler vom Kopieren von Dateien. Das würde ich schon für einen FAT32 Fehler halten.
Unzweifelhaft, weil offensichtlich, gibt es diesen ´Zählfehler´, von dem ich im zitierten Thread schlüssig nachgewiesen habe, daß er keineswegs harmloser/kosmetischer Natur ist,
Wenn du mit "Zählfehler" nur die falsche Anzeige meinst, würde ich das schon eher als harmlos bezeichnen, auch wenns unschön ist, solange kein Datenverlust passiert.
Es handelt sich imho um einen Fehler in der Long-Arithmetik, vermutlich ein nicht berücksichtigter Überlauf oä.
Ich denke eher nicht. Ich habe im anderen Thread Screenshots angehängt wo das schon bei relativ kleinen Partitionen passiert. Ausserdem ist eher unwahrscheinlich daß zwei Desktops an der gleichen Stelle den gleichen Fehler haben.
Mit zu kleinen Partitionen (oder zu kleinen Füllungen derselben) siehst Du den Zählfehler nicht
s.o. Im anderen Thread sind Screenshots wo das auf komplett leeren Partionen auftritt.
Meine MAGX-Version war übrigens wohl eine der letzten, die ASH überhaupt noch verkauft hat (viieeeel später als Anno 2000).
Meldet die sich mit anderem Datum? Wäre schon mal ineressant zu wissen was da möglicherweise gegenüber den veröffentlichen Sourcen noch verändert wurde. Zur Not würde ich da auch mit einem Disassembler nachschauen.
Zu prüfen wäre imho, ob etwa durch die Erhöhung der Limits zB. eine 64k-Feldgrenze überschritten wird.
Ja, wäre möglich. Müsste ich mal anhand der Grössen der Strukturen nachrechnen. Eigentlich sollte Pure-C da mit 32bit Arithmetik arbeiten, aber wäre nicht das erste mal daß er da Murks macht.
Was bedeutet ´Fehler #-69´ genau? Vielleicht ´arithmetik overflow´?
Das wundert mich jetzt aber schon daß du das nicht weisst ;) In dem Fall wars ein Busfehler.
Anhänge per PM sind nicht möglich (das solltest Du doch aber wissen).
Nein, woher sollte ich das wissen. Hab noch keine versucht zu bekommen oder zu verschicken. Im englischen Forum geht das, deswegen war ich davon ausgegangen.
Ich hänge jetzt mal meine Applicat.INF und ~.DAT hier an;
Ja, danke,schau ich mir mal an.
-
Zu Applicat: den Fehler kann ich immer noch nicht reproduzieren. Wie hast du Applicat gestartet, von MagxDesk aus über "Anwendung anmelden" oder direkt? Problem ist, wenn ich das über "Anwendung anmelden" starte, kommt der Dialog der bei dir zu sehen ist überhaupt nicht. Wenn ich das direkt starte, kommt zwar der Dialog, allerdings ist die Applicat.dat dann nach beenden nur noch ca. 16k gross. Scheinbar brauch doch die dazugehörigen Resource-Dateie(n) -> PM.
32k-Überlaufe scheinen auch auszuscheiden. Bei zwei Strukturen Struktur könnte das passieren, aber dann hätte das auch schon mit den alten Limits auftreten müssen.
Zu deiner Resource-Datei: die kann man so leider nicht verwenden. Da fehlen irgendwie die Icons für "Parent-Verzeichnis" und Drucker (bzw. sehen nicht so aus). Hast du denn ausser den Icons noch was anderes geändert?
-
^^-- Wenn Dir ein Icon nicht gefällt, dann kannst Du ja einfach eine Resource mit einem Dir passenden in GEMDESK\RSC\ hinzufügen und ein anderes zuordnen.
-------
Hast Du denn noch nie einem Objekt im MAGXDESK ein Icon zugewiesen?!
(Wie an obigem ScreenSnap deutlich zu erkennen ist, habe ich den Ordner EXTRA\ ausgewählt (dem bisher noch kein eigenes Icon zugeordnet ist) und dann das Menue ´Optionen/Icon_zuweisen´ angeklickt: Dann startet der MagxDesk automatisch das Applicat.APP nach (mit den richtigen Parametern!)...).
-------
Ei, woher weißt Du denn, daß da ein Busfehler auftritt? Das geht nämlich aus obigem ScreenSnap nicht hervor. Ich habe inzwischen eine Liste mit FehlerMeldungen gefunden, die auch Nummern jenseits von #-67 enthält. Dort ist unter #-69 eingetragen: 68000 Exception (Bomben), aber nicht deren Anzahl... Das könnten also von zwei (bus error (=Zugriff auf nicht vorh. Hardware)) über drei (odd address) usw. bis hin zu elf (spurious interrupt) ziemlich viele Möglichkeiten sein!
-
... Aber meine Magic Installationen hauen irgendwie nimmer hin ...
Warum nicht? Welche Probleme?
-
^^-- Wenn Dir ein Icon nicht gefällt, dann kannst Du ja einfach eine Resource mit einem Dir passenden in GEMDESK\RSC\ hinzufügen und ein anderes zuordnen.
Darum geht es nicht, das ist schliesslich Geschmackssache. Aber die in Applicat.rsc vorhandenen Icons werden z.b. nach einer Neu-Installation genommen. Die muss daher funktionieren ohne daß ich irgendwelche Zuweisungen machen muss.
Hast Du denn noch nie einem Objekt im MAGXDESK ein Icon zugewiesen?!
Nein, hab ich nicht. Hab damals immer nur EASE, und später Jinnee benutzt. Deswegen ja auch meine Frage eingangs. Magxdesk ist zwar schlank und schnell, lässt aber doch einigen Komfort vermissen den andere bieten.
Wie an obigem ScreenSnap deutlich zu erkennen ist, habe ich den Ordner EXTRA\ ausgewählt
Woran soll das zu erkennen sein? Im Desktop-Fenster ist der jedenfalls nicht angewählt.
Ei, woher weißt Du denn, daß da ein Busfehler auftritt?
Ja stimmt, könnte auch eine andere Exception sein. Leider zeigt MagiC das nicht an. Aber in 99% aller Fälle wird das nach einer solchen Programm-Änderung wohl ein Busfehler sein.
-
So, nochmal (vorläufig) letzter Versuch für Applicat. Hab ein paar fehlende Überprüfungen eingebaut, allerdings die meisten beim einlesen der INF-Datei, nicht nach dem Dialog. Vlt. hilft das ja, reproduzieren kann ich den Fehler aber immer noch nicht. Dazu bräuchte ich deine RSC-Datei(en) aus dem GEMDISK\RSC Verzeichnis. Wenn du die nicht zuschicken kannst/willst, komm ich da leider nicht weiter.
Zu deiner RSC-Datei: statt sie in applicat.rsc einzubauen, hab ich sie jetzt in den RSC Ordner von magxdesk gepackt. Dann muss man sie nicht in 3 verschiedene sprach-abhängige Resourcen einbauen, und jeder kann sich selber aussuchen welche Icons er benutzen will. Ich hoffe das ist ok.
-
Thorsten wie hoch siehst du die chance ein Rom Image zu bauen was man direkt ins Rom packen könnte ? So quasi direkt als Ersatz ? Könnte es an meinem TT sogar live Testen da ich Flashroms habe die ich in System Programmieren kann.
-
Thorsten wie hoch siehst du die chance ein Rom Image zu bauen was man direkt ins Rom packen könnte ?
Theoretisch sollte das kein grosses Problem sein, was ich bisher gesehen habe. Alle relevanten Daten liegen sowieso schon an absoluten Addressen im Bereich < $8000, man müsste also nur das eigentlich Programm an die richtige Addresse linken (hab ich zwar mit PureC noch nie gemacht, sollte aber eigentlich gehen, zur Not müsste man ein kleines Hilfs-Programm schreiben). Was mich stutzig macht ist allerdings ein Bug den ich erst letztens beseitigt habe: dort wurde der Falcon-Video-Shifter initialisiert, dann anschliessend auf einen VBL-Interrupt gewartet. Der Exception-Vector dafür war aber an der Stelle noch gar nicht gesetzt, zeigte also immer noch auf die Routine die vom ROM installiert wurde... Schlimmer noch waren stattdessen sämtliche System-Variablen schon gelöscht, sodaß diese Routine, und evtl auftretende MFP interrupts, dann irgendwann ins Nirwana sprangen.
Könnte sein, daß da noch mehr Fallstricke solcher Art verborgen sind, die ich noch nicht gefunden habe.
Könnte es an meinem TT sogar live Testen da ich Flashroms habe die ich in System Programmieren kann.
Wenn du mir sagst wo ich hinschicken soll, kann ich dir gerne mal eine Test-Version zukommen lassen.
-
Hades? Ich sehe das BIOS nicht. Ist es möglich?
Gerade mal getestet. Da scheint noch eine Datei für zu fehlen (hades.inc) scheinbar mit Definitionen für die Hardware-Addressen. Er meckert über solche Sachen wie pci_vga_reg, hlt (head load time) etc. Weiss jemand wo man da Ersatz für finden kann?
-
Weiß nicht ob man die Themen eventuell einmal aufteilen sollte. Aber ich schreibe es jetzt erstmal hier rein.
Unser Thunder IDE Interface besitzt ja die SmartSwap Features was im Grunde nichts anderes macht als die reinen Daten Bytes zu swappen. HDDriver kommt damit klar und da man dort das Software Swappen ausschalten kann und nur Dos Kompatibel erstellen kann.
Wenn man jetzt Magic auf einen dieser Medien installiert dann startet der Kernel und nach dem Reset bleibt er hängen. Meine Vermutung ist das der Kernel quasi prüft um was für eine Partition es sich handelt. Jetzt ist es ja so das bei DOS Partitionen der Typ im hex Format abgelegt ist und bei TOS kompatiblen Partitionen eben BGM, GEM, F32 usw. drin steht. Jetzt wird hier natürlich die Erkennung schief laufen
-
^^-- Antwort im neuen Thread "SmartBoot für MAGX" (https://forum.atari-home.de/index.php/topic,14841.0.html).
-
Hades? Ich sehe das BIOS nicht. Ist es möglich?
Gerade mal getestet. Da scheint noch eine Datei für zu fehlen (hades.inc) scheinbar mit Definitionen für die Hardware-Addressen. Er meckert über solche Sachen wie pci_vga_reg, hlt (head load time) etc. Weiss jemand wo man da Ersatz für finden kann?
Andreas könnte es haben?
-
Unser Thunder IDE Interface besitzt ja die SmartSwap Features was im Grunde nichts anderes macht als die reinen Daten Bytes zu swappen.
Wenn ich das richtig verstanden habe swapped das (im Gegensatz zu einem Twisted Cable) nur die Daten, aber nicht die Kommandos. Aber wann genau swapped er die Daten, erkennt er selbständig irgendwie ob das Medium an einem PC oder Falcon eingerichtet wurde? Wenn das quasi automatisch erfolgt, dürfte das für MagiC eigentlich keinen Unterschied bedeuten. In jedem Fall ist ein ByteSwap aber nur Sache des Treibers (ausser vlt. beim lesen des Rootsectors, da müsste ich mal schauen).
Meine Vermutung ist das der Kernel quasi prüft um was für eine Partition es sich handelt. Jetzt ist es ja so das bei DOS Partitionen der Typ im hex Format abgelegt ist und bei TOS kompatiblen Partitionen eben BGM, GEM, F32 usw. drin steht. Jetzt wird hier natürlich die Erkennung schief laufen
Nicht direkt. Die Partitionskennung wird zunächst mal nur vom Treiber geprüft. Magic versucht dann Getbpb() aufzurufen, wenn das fehlschägt wird die XHDI-Funktion XHInqDev2 aufgerufen. Dort wird dann geprüft, ob "F32" im Partition-Typ steht. Ansonsten werden diverse Daten im Bootsector auf Gültigkeit geprüft. Für andere Partitionen als FAT32 wird da aber nix weiter geprüft.
-
Andreas könnte es haben?
Möglich, aber dann hätte er es vermutlich dabei gepackt ^^ Anfrage ist aber natürlich schon unterwegs.
-
Und noch ein Update zum "Zählfehler": das ganze war eine Kombination von (mindestens) zwei Fehlern. Zum einen ein Fehler in einer 32*32->64 Multiplikation, die nur MagxDesk betraf. Der ist jetzt behoben, und beide Desktops zeigen jetzt die gleichen (unsinnigen) Werte an. Eigentlich recht harmlos, wenn auch unschön.
Der zweite dagegen ist nicht so harmlos: wie in dem anderen Thread beschrieben, gibt es bei FAT32 einen Info-Sector, wo u.a. die Anzahl der freien Cluster und der nächste zu verwendende Cluster steht, damit man nicht jedesmal die ganze FAT abklappern muss (die bei FAT32 recht gross werden kann, zig MB sind da nicht selten). AK hat nur leider vergessen, daß diese Informationen alle im Intel-Format vorliegen. Dementsprechend liest/schreibt MagiC diese Werte im 68k-Format, auch werden dort keine Überprüfungen auf Gültigkeit gemacht. Resultat: wenn die Werte (korrekterweise) im Intel-Format vorliegen (z.B. weil die Partition von Mint beschrieben wurde), wird mit völlig sinnlosen Cluster-Nummer gearbeitet, die möglicherweise sogar ausserhalb der Partitions-Grenzen liegen. Wenn man Glück hat, fängt der HD-Treiber das ab, wenn man Pech hat macht der das nicht, oder die Werte liegen zwar ausserhalb der FAT, aber noch innerhalb der Partition, und die Daten werden dann irgendwo hingeschrieben, nur nicht da wo sie hingehören.
Heisst aber auch im Umkehrschluss: solange man *ausschliesslich* mit Magic auf FAT32 zugreift, dürfte nix gravierendes passieren (ausser da sind noch andere Bugs, natürlich). Kann das nochmal jemand bestätigen? Ich hab es im moment nur mit einer relativ kleinen Partition getestet.
-
Hades? Ich sehe das BIOS nicht. Ist es möglich?
Gerade mal getestet. Da scheint noch eine Datei für zu fehlen (hades.inc) scheinbar mit Definitionen für die Hardware-Addressen. Er meckert über solche Sachen wie pci_vga_reg, hlt (head load time) etc. Weiss jemand wo man da Ersatz für finden kann?
;video auflîsung 2=st high 6=tt high
vidmo: equ 2
vidmo00: equ vidmo*$100
pci_vga_base: equ $80000000 ;screen ram beginn
isa_vga_base: equ $ff000000 ;screen ram beginn
pci_vga_reg: equ $b0000000 ;vga register
isa_vga_reg: equ $fff00000 ;vga register
pci_conf1: equ $a0010000 ;pci config
pci_conf2: equ $a0020000 ;pci config
pci_conf3: equ $a0040000 ;pci config
pci_conf4: equ $a0080000 ;pci config
mem_max: equ $40000000 ;memory maximum 1 GB
;hades hardwareregister
main_status: equ $fff00080
data_reg: equ $fff00082
ldor: equ $fff000c0
ldcr: equ $fff000e0
; Hardwareregister
dmahigh: equ $FFFF8608
dmamid: equ $FFFF860B
dmalow: equ $FFFF860D
gpip: equ $FFFFFA81 ; TTMFP: Interface Port Datenregister
; sonstige Variablen
defhdinf: equ $302 ; Default hdinf. byt 0 -> anzahl versuche byt 1 -> taktrate (hd default)
ed: equ 0 ; clockraten fÅr verschiedene format
hd: equ 2
dd: equ 3
hlt: equ 3 ;head load time in milisekunden (in 1ms schriten 1-128ms)
hut: equ 120 ;head unload time in ms (in 16ms schritten 8-120ms)
Noch etwas?
-
Noch etwas?
Ja, ein paar SCSI-Addressen noch, aber die standen noch als Kommentar irgendwo anders. Den Rest konnte ich mir grösstenteils zusammen reimen. Vielen Dank!
Was mich noch irritiert:
gpip: equ $FFFFFA81 ; TTMFP: Interface Port Datenregister
Hat der Hades den "normalen" MFP gar nicht?
-
Ja, ein paar SCSI-Addressen noch, aber die standen noch als Kommentar irgendwo anders.
Das liegt daran, weil die Routinen eins zu eins den Modifikationen des TOS 3.06 für den Hades entnommen sind.
Was mich noch irritiert:
gpip: equ $FFFFFA81 ; TTMFP: Interface Port Datenregister
Hat der Hades den "normalen" MFP gar nicht?
Doch hat er. Liegt ganz normal an den Adressen wie beim ST/TT.
-
Doch hat er. Liegt ganz normal an den Adressen wie beim ST/TT.
Ah ok. Irritiert war ich, weil "gpip" schon definiert war als die Addresse für den ST-MFP. Bleibt nur noch eine Ungereimtheit: im exception-handler wird der SP auf eine Addresse gesetzt die nirgendwo definiert ist. In der ST-Version wird das nicht gemacht. Da muss ich mir jetzt noch ein freies Plätzchen suchen. Ansonsten lassen sich die Sourcen jetzt zumindest übersetzen. Ob sie auch funktionieren: kA ;)
-
Zu deiner RSC-Datei: statt sie in applicat.rsc einzubauen, hab ich sie jetzt in den RSC Ordner von magxdesk gepackt. Dann muss man sie nicht in 3 verschiedene sprach-abhängige Resourcen einbauen, und jeder kann sich selber aussuchen welche Icons er benutzen will. Ich hoffe das ist ok.
Nein, das ist nicht ok.
Ich verstehe gar nicht, was Du da wohin gepackt hast. In den Ordner GEMDESK\RSC\ gehören afaik nur Icon-Resourcen. Solche habe ich aber oben gar nicht angehängt. Falls Du die in APPLICAT.RSC eingebauten Icons herausgenommen und in eine extra Icon-Datei gepackt hast, so ist das auch nicht ok, denn dann hättest Du schlicht nicht verstanden, warum diese Icons just da sind, wo sie sind, nämlich in APPLICAT.RSC. Es ist allerdings etwas seltsam, wie MAGX bzw. sein APPLICAT seine Icons überall zusammensucht.
-
Das jüngste APPLICAT (aus #76) steigt haargenau an der gleichen Stelle aus, ohne weitere Meldung. Ich habe mal meinen ErrorProzessor in´s System gehängt. Er berichtet folgenden last sigh:
Post Mortem Global Error Context:
Exception 2, is: Bus missing hardware
D0 = 00000001 A0 = 0400F2A8
D1 = 03FDD06A A1 = 00000000
D2 = 0400DC3C A2 = 0401124C
D3 = FFFF0003 A3 = 00000000
D4 = 00000000 A4 = 03FDCB8C
D5 = 00000000 A5 = 0401124E
D6 = 00000000 A6 = 03FD9E8C
D7 = 00000000 A7 = 012B26BA (= SSP)
EID = 02FFFFFF USP = 04011236
SavedSuperStack:
0300 03FD C602 B008 16EE 0729 3290 4E75 0000 0000 0401 123A 0000 00AC 226F
^-ps ^-AcAdr-^ ^-Op ^-SR----^ ^-PC----^
PC = 32904E75, PC^[-9..+5]: ----
No valid M2 Error Dump
-
Und noch ein Update zum "Zählfehler": das ganze war eine Kombination von (mindestens) zwei Fehlern. Zum einen ein Fehler in einer 32*32->64 Multiplikation, die nur MagxDesk betraf. Der ist jetzt behoben, und beide Desktops zeigen jetzt die gleichen (unsinnigen) Werte an. Eigentlich recht harmlos, wenn auch unschön.
Das bestätigt ja, was ich in #69 schrieb. Aber daß auch der Zählfehler für sich allein schon nicht harmlos ist, das hatte ich schon in "MAGX´ Macken" nachgewiesen. Wie auch immer: Sehr erfreulich, daß Du den jetzt beheben kannst und auch gleich noch die Ursache für das ebenfalls in "MAGX´ Macken" diskutierte FAT32-Problem gefunden hast! Danke!
Der zweite dagegen ist nicht so harmlos: wie in dem anderen Thread beschrieben, gibt es bei FAT32 einen Info-Sector, wo u.a. die Anzahl der freien Cluster und der nächste zu verwendende Cluster steht, damit man nicht jedesmal die ganze FAT abklappern muss (die bei FAT32 recht gross werden kann, zig MB sind da nicht selten). AK hat nur leider vergessen, daß diese Informationen alle im Intel-Format vorliegen. Dementsprechend liest/schreibt MagiC diese Werte im 68k-Format, auch werden dort keine Überprüfungen auf Gültigkeit gemacht. Resultat: wenn die Werte (korrekterweise) im Intel-Format vorliegen (z.B. weil die Partition von Mint beschrieben wurde), wird mit völlig sinnlosen Cluster-Nummer gearbeitet, die möglicherweise sogar ausserhalb der Partitions-Grenzen liegen.
Das klingt für mich jetzt so, als ob eigtl. MAGX das richtig macht (da wir ja auf 68k-Maschinen arbeiten) und MiNT da schief liegt - aber bevor hier wieder der übliche Aufschrei kommt, MiNT habe immer Recht: Es ist letztlich egal, bloß muß dafür gesorgt werden, daß beide gleich vorgehen!!
Heisst aber auch im Umkehrschluss: solange man *ausschliesslich* mit Magic auf FAT32 zugreift, dürfte nix gravierendes passieren (ausser da sind noch andere Bugs, natürlich). Kann das nochmal jemand bestätigen? Ich hab es im moment nur mit einer relativ kleinen Partition getestet.
Das kann, wie schon dargelegt, imho nur mit einer Version getestet werden, in der der Zählfehler schon beseitigt ist (also mit Deiner).
Edit.: Da es ja nicht bloß darum geht, sowohl mit MAGX als auch mit MiNT auf die gleichen FAT32-Parts. problemlos zugreifen zu können, sondern auch die Austauschbarkeit mit gewöhnlichen (also für Windows eingerichteten) Medien zu berücksichtigen ist, plädiere ich natürlich in diesem Fall für das Intel-Format, also für die Anpassung von MAGX. Warum also noch etwas testen, was eh angepaßt werden muß...
-
... Der Exception-Vector dafür war aber an der Stelle noch gar nicht gesetzt, zeigte also immer noch auf die Routine die vom ROM installiert wurde... Schlimmer noch waren stattdessen sämtliche System-Variablen schon gelöscht, sodaß diese Routine, und evtl auftretende MFP interrupts, dann irgendwann ins Nirwana sprangen.
Den MAGX-typischen ReBoot/DoppelBoot hast Du doch aber berücksichtigt?
-
Nein, das ist nicht ok.
Na gut, dann nehm ich es halt wieder raus,
Ich verstehe gar nicht, was Du da wohin gepackt hast. In den Ordner GEMDESK\RSC\ gehören afaik nur Icon-Resourcen.
Ja, das ist mir auch klar. Wenn da was anderes als ICONS drin ist, wird die auch gar nicht genommen.
Falls Du die in APPLICAT.RSC eingebauten Icons herausgenommen und in eine extra Icon-Datei gepackt hast
Exakt.
so ist das auch nicht ok, denn dann hättest Du schlicht nicht verstanden, warum diese Icons just da sind, wo sie sind, nämlich in APPLICAT.RSC.
Und ich habe dir oben erklärt, warum man die so nicht in APPLICAT.RSC einbauen kann.
Es ist allerdings etwas seltsam, wie MAGX bzw. sein APPLICAT seine Icons überall zusammensucht.
Finde ich gar nicht mal so verkehrt. Bei vielen Icons kann man die halbwegs sinnvoill auf mehrere RSC-Datein verteilen und behält so vlt. einen besseren Überblick. Z.b ein Datei mit Laufwerks-Symbolen, eine mit Programm-Icons etc.
-
Das jüngste APPLICAT (aus #76) steigt haargenau an der gleichen Stelle aus, ohne weitere Meldung.
Hm seltsam, auch kein Error -69 mehr?
Post Mortem Global Error Context:
Auch seltsam. Sieht so aus als ob da jemand versucht an eine ROM-Addresse zu schreiben ($FDC602) In welcher Konfiguration testet du das?
-
Aber daß auch der Zählfehler für sich allein schon nicht harmlos ist, das hatte ich schon in "MAGX´
Macken" nachgewiesen.
Bitte les nochmal was ich geschrieben habe. Es wurde dort lediglich ein falscher Wert berechnet und angezeigt. Das ist schon eher harmlos und kann auch nicht zu Datenverlusten führen.
Das klingt für mich jetzt so, als ob eigtl. MAGX das richtig macht (da wir ja auf 68k-Maschinen arbeiten) und MiNT da schief liegt
Nein, sicher nicht, Die Werte dort liegen alle im Intel-Format vor, egal auf welcher Maschine. Wird ja auch an anderen Stellen richtig gemacht, nur halt bei diesen zwei Werten nicht.
Das kann, wie schon dargelegt, imho nur mit einer Version getestet werden, in der der Zählfehler schon beseitigt ist (also mit Deiner).
Das könnte man auch jetzt schon testen (natürlich nur mit einer Partition die man entbehren kann, falls da irgendwas fatales passiert). Muss aber nicht sein, ist auch ziemlich zeitaufwendig. Das zu fixen dauert auch noch ein bisschen, würde das schon ganz gerne relativ ausgiebig testen bevor da jemand seine Partionen zerschiesst ;)
-
Das jüngste APPLICAT (aus #76) steigt haargenau an der gleichen Stelle aus, ohne weitere Meldung.
Hm seltsam, auch kein Error -69 mehr?
Mit ´haargenau´ war gemeint: Total gleich wie in obigem ScreenSnap, auch #-69 !
Post Mortem Global Error Context:
Auch seltsam. Sieht so aus als ob da jemand versucht an eine ROM-Addresse zu schreiben ($FDC602)
Ja klar, Dein APPLICAT. Sieht für mich so aus, als ob ein Subroutine-Sprung mißglückt (oder die Rückkehr daraus). Auf dem SuperStack liegt offenbar ein Stück Code genau da, wo eigtl. der ProgramCounter liegen sollte. Eine ROM-Adr.? So hoch? Kann wohl kaum sein. Was liegt denn da.
In welcher Konfiguration testet du das?
Völlig unverändert. Funzt absolut reibungslos mit dem Original seit Jahren. Lediglich das neue Applicat eingewechselt (samt .RSC).
Edit.:
Habe den Test gerade noch mal wiederholt, aber auf dem Falcon anstatt dem TT: Gleiches Bild, bloß der last sigh ist leicht verändert:
Post Mortem Global Error Context:
Exception 2, is: Bus missing hardware
D0 = 00000001 A0 = 00539F8C
D1 = 00507D4E A1 = 00000000
D2 = 00538920 A2 = 0053BF30
D3 = FFFF0003 A3 = 00000000
D4 = 00000000 A4 = 00507870
D5 = 00000000 A5 = 0053BF32
D6 = 00000000 A6 = 00504B70
D7 = 00000000 A7 = 001F939E (= SSP)
EID = 02FFFFFF USP = 0053BF1A
SavedSuperStack:
0300 0050 72E6 B008 360E 0329 3290 2252 0000 0000 0053 BF1E 0000 0049 226F
^-ps ^-AcAdr-^ ^-Op ^-SR----^ ^-PC----^
PC = 00000000, PC^[-9..+5]: ----
No valid M2 Error Dump
-
Mit ´haargenau´ war gemeint: Total gleich wie in obigem ScreenSnap, auch #-69 !
Ok, hatte ich wohl missverstanden. Würde auch keinen Sinn machen, weil dann die Daten im Post-Mortem-Dump gar nicht gültig wären.
Ja klar, Dein APPLICAT.
Naja direkt eher nicht. Vermutlich indirekt, weil vorher irgendwo der Stack zerschossen wurde.
Eine ROM-Adr.? So hoch? Kann wohl kaum sein.
ROM bei ST geht von FC0000 -FF0000, wieso kann das nicht sein?
Was liegt denn da.
kA. Wenn du mal meine Frage beantworten würdest, könnte ich das vlt. sogar sagen. Ist aber eigentlich unerheblich, interessanter wäre zu wissen wie er da hin kommt.
Völlig unverändert.
Echt extrem hilfreich. Welche Maschine? Welches TOS im ROM? Welche MagiC Version? Wieviel Speicher? Was läuft da evtl. noch an residenten Programmen?
0300 0050 72E6 B008 360E 0329 3290 2252 0000 0000 0053 BF1E 0000 0049 226F
^-ps ^-AcAdr-^ ^-Op ^-SR----^ ^-PC----^
kA was du da für ein Tool benutzt, aber die Angaben sind irgendwie unsinnig. Der Stackframe für Bus-Error sieht beim 68030 erheblich anders aus als beim 68000.
-
Ok, nochmal genauer nachgeschaut. Hab mich da irgendwie von den Ausgaben des Tools verwirren lassen. Ausgehend davon daß beide Tests auf einem 68030 liefen (TT/Falcon), ist das einfach ein NULL-Pointer-Zugriff:
0300 0050 72E6 B008 360E 0329 3290 2252 0000 0000
^ ^- Zugriff auf Addresse 0
+ Format 11 frame, Bus-Error
Hilft mir nur irgendwie auch nicht direkt weiter...
-
Kleine Anmerkung am Rande: ich versuche durchaus hier mitzulesen und zu verstehen. Das ist jedoch schon anhand der langen Texte und vor allem der wechselseitigen Zitate überaus schwierig - unabhängig von der Materie.
-
Geht mir genauso. Wollte bloß nicht schon wieder eine Stil-Diskussion vom Zaun brechen...
-
Die post-mortem-dump-area hat doch wohl jedes TOS?
Daß ich den SuperStack auslese, das ist manchmal - aber nicht immer! - hilfreich; da kann auch totaler Quatsch stehen.
Bei einem NilPointer sollte doch aber eine ganz andere Exception kommen? (mit viel mehr als 2 Bömbchen, wo hab´ich denn bloß die Tabelle...)
-
Ja, die hat jedes TOS. Und den Stack musst du auch nicht selber auslesen, die letzten 16 WORDs desselben sind Teil dieser Area. Wie die Daten, die dort stehen, zu interpretieren sind, hängt aber von der Exception ab. Bei den meisten Exceptions sind das die gleichen wie bei einem Trap-Aufruf (also SR, PC und Format-Word bei 68020+), nur bei Bus- oder Addressfehler sind die anders. Und ja, ein Zugriff auf Addresse 0 aus dem User-Modus erzeugt einen Bus-Fehler (Exception #2). Solltest du vlt. einfach mal glauben.
-
^^-- [ironic] Dir glaube ich überhaupt nix >:D [/ironic]
-------
Könnte sein, daß mein ErrorProz. etwas veraltet ist (nur 68000er?).
Hättest Du da etwas besseres anzubieten?
-
Ne da hab ich nix besseres, hab sowas auch eigentlich nie gebraucht. Wenn bei mir irgendwas Bomben schmeisst, dann war's vermutlich eines meiner Programme, da schmeiss ich dann lieber den Debugger an... Macht auch vermutlich nicht viel Sinn da zu versuchen was besseres zu finden, der komplette Bus-Error-Frame von 68030 passt eh nicht in die 16 Wörter, und mehr Platz ist da auch nicht. Ganz zu schweigen von 040/060, die wieder anders sind...
PS.: warte immer noch auf die RSC-Dateien...
-
^^-- Du hast doch mal ´ne Icon.RSC von mir bekommen, mit der Du wunderbar testen kannst, nämlich die ´odd´ Icons, Du erinnerst Dich hoffentlich? (Wahrscheinlich geht´s auch mit einer beliebigen anderen Icon-Resource... oder sogar ganz ohne?). Ich habe das nun mal auf dem F30 für Dich gemacht: Im Anhang der ScreenSnap des Absturzes und hier der last sigh:
Post Mortem Global Error Context:
Exception 2, is: Bus missing hardware
D0 = 00000001 A0 = 005423BC
D1 = 0051017E A1 = 00000000
D2 = 00540D50 A2 = 00544360
D3 = FFFF0003 A3 = 00000000
D4 = 00000000 A4 = 0050FCA0
D5 = 00000000 A5 = 00544362
D6 = 00000000 A6 = 0050CFA0
D7 = 00000000 A7 = 002C1AF6 (= SSP)
EID = 02000000 USP = 0054434A
SavedSuperStack:
0300 0050 F716 B008 360E 0329 3290 FF0C 0000 0000 0054 434E 0000 0013 226F
^-ps ^-AcAdr-^ ^-Op ^-SR----^ ^-PC----^
PC = 00000000, PC^[-9..+5]: ----
No valid M2 Error Dump
Liebe Lads, ich mache jetzt wohl besser mal Weihnachts-Pause.
Ein frohes Fest und einen guten Rutsch an @alle !
Edit.: Versehentlich war ´Zitat´ anstatt ´Code´ eingefügt worden: Geändert.
Die in diesem jüngsten Test verwendeten Konfig.-Dateien sind die auch oben schon verwendeten, die in #69 angehängt wurden. Die hier verwendete Icon-Datei wurde hier angehängt:
https://forum.atari-home.de/index.php/topic,14326.msg226906.html#msg226906
-
^^-- Du hast doch mal ´ne Icon.RSC von mir bekommen, mit der Du wunderbar testen kannst
Nein, kann ich eben nicht, weils nicht die gleiche ist. Die Zuordnungen werden dann nicht gefunden, und auch nicht in die applicat.dat geschrieben. D.h. das Programm verhält sich anders als bei dir, und ich kann den Fehler nicht reproduzieren. Ich versteh auch das Problem nicht, du wolltest die RSC mal hier posten, hast aber jetzt ein Problem damit sie mir zu schicken damit ich dir bei dem Fehler weiter helfen kann? Ist ja nicht so daß ich nix besseres zu tun hätte.
-
So, nochmal neue Version von Applicat, für diejenigen die's testen wollen.
Und als Schmankerl: neue Version des Kernels, der hoffentlich den FAT32-Fehler behoben hat, und neue Version von Magxdesk, die auch nicht mehr den Anzeige-Bug haben sollte.
Beides wurde nach bestem Wissen&Gewissen getestet, aber inbesondere bei dem Kernel natürlich aufpassen auf welche Partitionen man den los lässt. Zu Risiken und Nebenwirkungen fragen Sie Ihren Arzt oder Apotheker... aber nicht mich!
Edit: auf vielfachen Wunsch eines einzelnen, Grenzen für Applicat nochmal erhöht
-
Und als Schmankerl: neue Version des Kernels, der hoffentlich den FAT32-Fehler behoben hat,
Also wenn dann bräuchte ich einen für den Milan.
Allerdings bin ich da im zweifel ob ich das testen soll. Ich hatte nie Probleme mit FAT32 unter MagiC. Die Partition nutzte ich auch von FreeMiNT. Ohne erkennbaren Datenverlust. Und auch eine CF mit der ich den Datenaustausch zum Apfel mache hat nie Auffälligkeiten.
Um die Darstellung der Werte habe ich mich nie gekümmert.
-
Also wenn dann bräuchte ich einen für den Milan.
Kein Problem. Hades-Version ist auch dabei (möglicherweise noch fehlerhaft, siehe andere Thread).
Ich hatte nie Probleme mit FAT32 unter MagiC. Die Partition nutzte ich auch von FreeMiNT.
Datenverluste konnte ich bisher auch nicht provozieren mit der alten Version, aber auszuschliessen ist das nicht. Möglicherweise tritt das auch erst bei grossen Partitionen auf, oder da verbirgt sich noch ein Fehler der mit den bisherigen gefixten gar nix zu tun hat.
Der Anzeigefehler war aber definitiv da, Dfree() konnte unsinnige Werte liefern. Dazu kam noch ein Rechenfehler in MAGXDESK. Beides sollte jetzt behoben sein.
Allerdings bin ich da im zweifel ob ich das testen soll
Natürlich deine Entscheidung, aber ich wäre schon an Feedback interessiert. Bisher ist das ja ziemlich mau hier :(
-
Wie sieht es da mit CT6x aus, muß man da erst noch was patchen? Ist alles so lange her :-(
-
Soviel ich weiss braucht man dafür nur ein anderes Boot-Programm (link wurde hier schon irgendwo gepostet).
-
Allerdings bin ich da im zweifel ob ich das testen soll
Natürlich deine Entscheidung, aber ich wäre schon an Feedback interessiert. Bisher ist das ja ziemlich mau hier :(
Das ist normal erst schreien alle nach dem Quelltext, ist er dann da sind auf einmal alle verschwunden denn sie merken das das Testen arbeit macht.
Ansosnten Glückwunsch die Version funktioniert! :)
Nun zum komischen. Während sich die Anzeige der Werte der besagten Partition nicht geändert habe ist das bei der CF der Fall. Im Original waren die Werte komisch, nun passen sie besser. Verstehen muss man das nicht oder?
Die Partition hatte ich früher mit mkfats aus dem FreeMiNT Paket erstellt. Die CF Karte war so. Hier müste ich testen in dem ich ein CF Karte einmal am Milan formnatiere und dann nochmal um anderen Rechner.
Vielleicht eine bitte. Könntest Du das Systemdatum setzen, damit man erkennen kann welche Version man nutzt. Das befindet sich in magibios.s sowie milnbios.s recht am Anfang. Einfach nach D_DAY suchen.
Danke nochmal für Deine Mühen!
-
Nun zum komischen. Während sich die Anzeige der Werte der besagten Partition nicht geändert habe ist das bei der CF der Fall. Im Original waren die Werte komisch, nun passen sie besser. Verstehen muss man das nicht oder?
Ein bisschen schwierig zu erklären, aber a) Der Anzeige-Fehler war nur in MagxDesk (nicht Jinnie z.B.) und trat auch dort nicht immer auf. b) Solange du ausschliesslich mit MagiC auf die Partition zugreifst, kann es durchaus sein daß auch vorher die Anzeige stimmte.
Könntest Du das Systemdatum setzen, damit man erkennen kann welche Version man nutzt. Das befindet sich in magibios.s sowie milnbios.s recht am Anfang. Einfach nach D_DAY suchen.
Das Problem dabei ist daß man das jedesmal manuell ändern muss (und sich damit auch die Sourcen ändern). Ist halt das Problem daß man aus den Projekt-Dateien von Pure-C keine weiteren Tools wie bei einem "richtigen" Makefile starten kann. Hab ich schon oft verflucht. Ich habs aber jetzt erstmal aktualisiert, und die Infos in eine separate Datei ausgelagert.
Ansonsten sind die geänderten Sourcen jetzt auch auf github (https://github.com/th-otto/MagicMac) verfügbar.
-
Natürlich deine Entscheidung, aber ich wäre schon an Feedback interessiert. Bisher ist das ja ziemlich mau hier :(
Liegt vielleicht auch ein wenig daran, dass DAUS wie meine Wenigkeit nicht so viel mit den Fachausdrücken und vor allem mit den Zusammenhängen anfangen können? :(
Ich würde gerne eine neue oder gepachte Magic Version auf meinem Milan040 ausprobieren. Installiert ist auf dem Raumvogel Magic 6.1. Version 6.2 bzw. das Update auf 6.2 wollte bei mir nie installieren. Das quittierte die Installation immer mit einer Fehlermeldung. :'( Wenn ich eine neue Magic Version ausprobieren soll, dann müsste ich nur wissen welche Dateien ich austauschen muss bzw. anpassen muss. Sonst bekomme ich's nicht wirklich hin, fürchte ich.
Ansonsten finde ich's echt klasse und erstaunlich, dass sich jemand Magic angenommen hat und etwas dran macht. Im Grunde hätte ich das für nicht möglich gehalten. Deswegen vielen herzlichen Dank an alle Beteiligten, die an dem Code schrauben und dafür ihre Zeit opfern. 8)
-
Liegt vielleicht auch ein wenig daran, dass DAUS wie meine Wenigkeit nicht so viel mit den Fachausdrücken und vor allem mit den Zusammenhängen anfangen können? :(
Naja, im Grunde genommen war die Warnung nur eine Vorsichtsmassnahme, bevor hier jemand seine Partionen mit der neuen Version zerschiesst ;)
Ich würde gerne eine neue oder gepachte Magic Version auf meinem Milan040 ausprobieren.
Eine aktuelle Milan Version ist im anderen Thread (https://forum.atari-home.de/index.php/topic,14844.msg234651/topicseen.html#msg234651) angehängt.
Sollte eigentlich reichen magic.ram im Wurzel-Verzeichnis von Laufwerk C: auszutauschen. Die Datei im Archiv heisst mmilan.ram, und muss entsprechend umbenannt werden. Daß man vorher die alte Datei sichern sollte, muss ich hoffe ich nicht erwähnen ;)
Das Installations-Programm hab ich mir ehrlicherweise noch nicht gross angeschaut. Dazu müsste man die entsprechenden Dateien vermutlich auch erstmal auf die korrekten Disketten(-Images) verteilen. Im moment muss man also manuell die einzelnen Komponenten austauschen (was nicht unbedingt verkehrt ist, weil man sie dann auch einzeln testen kann).
-
Ansonsten sind die geänderten Sourcen jetzt auch auf github (https://github.com/th-otto/MagicMac) verfügbar.
Danke!
Ich nehme an Du hast noch nicht Dein letzten Stand drin, denn in MILNBIOS.S fehlt noch das Include für version.inc.
Nur Kommentare:
In vier Dateien wird darauf hin gewiessen das der Compilerschalter -B aktiv sein soll. Da bekomme ich aber Fehlermeldungen, weil einige Symbole dann so gekürzt werden das sie doppelt werden.
Die Dateien sind:
aes/farbic.c
aes/wdialog/fnt_menu.c
aes/wdialog/listbox.c
aes/wdialog/wdialog.c
Das steht ganz am Anfang der Dateien.
-
Ich nehme an Du hast noch nicht Dein letzten Stand drin, denn in MILNBIOS.S fehlt noch das Include für version.inc.
Ja, hatte ich schon geändert, aber vergessen zu "pushen".
In vier Dateien wird darauf hin gewiessen das der Compilerschalter -B aktiv sein soll
Ja, das sind die original-Kommentare von AK. Funktioniert aber mit Pure-C nicht, oder evtl. nur mit dem älteren Assembler (mas.ttp). Mit der aktuellen Version werden dann alle Symbole auf 8 Zeichen gekürzt, was dann natürlich zu doppelten Namen führt (die mxvdiknl.o von gitlab wurde offensichtlich so erzeugt). Die Projekt-Dateien sollten aber passen. Evtl. sollte man die Kommentare entfernen, um Verwirrungen vorzubeugen.
-
Die Projekt-Dateien sollten aber passen.
Wenn man keine CFG-Datei nutzt bei der -B angwählt ist gehen die. 8)
Evtl. sollte man die Kommentare entfernen, um Verwirrungen vorzubeugen.
Das sollte getan werden.
Im Milan Projektfile habe ich noch ein ".C[-2]" eingefügt. Erzeugt dann für C 68020 Code. Macht bei dem geringen Anteil den Bock nicht fett. Trotzdem jede Millisekunde zählt. ;)
In MAGCMACX.PRJ musste noch ein ".S[-S]" rein, damit die mxvdiknl.s durch ging. Das Ergebnis funktioniert auch mit MagiCMacX2. Damit geht das Testen etwas einfacher denn der Neustart vom Milan geht doch etwas zäh.
-
Wenn man keine CFG-Datei nutzt bei der -B angwählt ist gehen die. 8)
Wer macht denn auch sowas ;) Könnte man natürlich explizit setzen, aber das müsste dann in alle Projekt-Dateien rein... sind ja nur 251...
Im Milan Projektfile habe ich noch ein ".C[-2]" eingefügt. Erzeugt dann für C 68020 Code.
Ja, kann man machen. Für die Hades-Version wohl auch.
In MAGCMACX.PRJ musste noch ein ".S[-S]" rein
Stimmt, fehlte generell bei allen Projekt-Dateien für Kernels. Behoben.
Wie lange dauert das übersetzen auf dem Milan so ca?
-
Im Milan Projektfile habe ich noch ein ".C[-2]" eingefügt. Erzeugt dann für C 68020 Code.
Ja, kann man machen. Für die Hades-Version wohl auch.
Yep, vom Prinzip her auch für den TT und Falcon. Vielleicht einfach eine zusätzliche Projektdatei atari020.prj.
Wie lange dauert das übersetzen auf dem Milan so ca?
70 Sekunden, auf eine Milan060 mit 25MHz. Kein Vergleich, ein komplett durchlauf von CAT benötigt fast 6 Minuten.
-
Im Milan Projektfile habe ich noch ein ".C[-2]" eingefügt. Erzeugt dann für C 68020 Code.
Ja, kann man machen. Für die Hades-Version wohl auch.
Yep, vom Prinzip her auch für den TT und Falcon. Vielleicht einfach eine zusätzliche Projektdatei atari020.prj.
Wie lange dauert das übersetzen auf dem Milan so ca?
70 Sekunden, auf eine Milan060 mit 25MHz. Kein Vergleich, ein komplett durchlauf von CAT benötigt fast 6 Minuten.
@KarlMüller Du meinst einen Milan060 mit 50 MHz oder einen Milan040 mit 25 MHz?
-
Yep, vom Prinzip her auch für den TT und Falcon. Vielleicht einfach eine zusätzliche Projektdatei atari020.prj.
Es gibt momentan keine spezielle Version für Falcon/TT, das ist die gleiche wie für ST. C-Code ist nur für File-Selector, Font-Selector etc. vorhanden, da wird man ein paar eingesparte Cycles nicht bemerken. Von daher möchte ich eigentlich vermeiden noch weitere Projekt-Dateien pflegen zu müssen, zumal da möglicherweise sowieso noch welche für verschiedene Sprachen dazu kommen.
ein komplett durchlauf von CAT benötigt fast 6 Minuten.
Meinst du das Maustausch-Programm CAT? Wow, hätte nicht gedacht daß das noch jemand benutzt.
-
Würde es sinn machen speziell für TT das Magic anzupassen ? Ich meine vielleicht ist da sogar noch Optimierungspotential wobei ich sagen muß ähm bei mir rennt es wiiiiieeeee irre.
-
Optimierungs-Potenzial wäre vlt. vorhanden, es gibt immer ein paar Sachen die sich mit '020 Code einfacher/schneller lösen lassen. Ob man das gross merkt wage ich aber zu bezweifeln, die meisten Geschwindigkeitsvorteile sind eigentlich in den VDI-Treibern zu erwarten, und da werden die meisten vermutlich die NVDI Treiber benutzen. Inwieweit die veröffentlichen Treiber-Sourcen der letzten NVDI-Version entsprechen kann ich nicht sagen, sie werden vermutlich ähnlich sein, aber nicht identisch. Da würde ich eher abwarten wollen, ob nicht auch NVDI demnächst freigegeben wird.
-
Größtere Vorteil ist halt das Magic komplett im TT-Ram läuft.. da z.b. mein Rechner momentan einen Datendurchsatz auf dem TT-Ram von 25Mb/s hat spürt man das unheimlich. Werde mal ein Video machen und hochladen wie sich magic auf meinem TT anfühlt :) gut meiner ist nicht ganz so normal wie andere aber dennoch dank der Storm ist das echt Spürbar.
-
Optimierungs-Potenzial wäre vlt. vorhanden, es gibt immer ein paar Sachen die sich mit '020 Code einfacher/schneller lösen lassen. Ob man das gross merkt wage ich aber zu bezweifeln, die meisten Geschwindigkeitsvorteile sind eigentlich in den VDI-Treibern zu erwarten,[…]
Du sagst es. VDI übernimmt NVDI oder NovaVDI, die seriellen Schnittstellen wickelt man über HSMODA ab, BIOS/XBIOS wird keiner groß in moderner Software direkt aufrufen, GEMDOS dürfte bis auf die Speicherverwaltung größtenteils I/O-bound sein.
Daher sehe ich bei kurzem Nachdenken nur zwei Ecken, wo man optimieren kann mit 030-Code: Speicherblöcke löschen oder schieben, falls das irgendwo enthalten ist, gerade bei heutigen Speichergrößen (der wächst dank der Neuentwicklungen ja, und die CPU ist dieselbe wie ’89 :-), sowie im Scheduler, also tief im Kern.
Hm, bei den AES vielleicht auch? Aber wo da?
Und damit kommen wir auf die Diskussion, die kürzlich auf der EmuTOS-ML war: für sinnvolles „Beschleunigen“ müßte man erstmal untersuchen, wo denn nennenswert Zeit verbraten wird im OS, bevor man da Zeit reinhängt an Stellen, die zwar toll zu optimieren sind, aber selten aufgerufen werden oder eh nur 80ms laufen …
-
Das Apollo Team und ich hatten uns Mitte des Jahres das für die Vampire Amiga von Vincent Riviere Entwickelten fVDI Treiber zur Hand genommen und diesen Optimiert, wir haben durch Optimieren der Blitting Routinen fast 300% Leistungszuwachs erzielen können. Ich glaube das man dort auch noch etwas Verfeinerung hin bekommt. Ansonsten Lesen-/Schreiben-/ Kopieren in und aus dem TT-Ram ... man kann diese Daten ganz gut mit Kronos Benchen, da wird der Speicher intensiv benutzt. Aber ich denke das Betrifft wirklich nur diejenigen die keine Grafikkarte habe.
-
Es gibt momentan keine spezielle Version für Falcon/TT, das ist die gleiche wie für ST. C-Code ist nur für File-Selector, Font-Selector etc. vorhanden, da wird man ein paar eingesparte Cycles nicht bemerken.
Ja, die einzige nicht AES Datei in C ist noch die vfat.c im DOS.
Zum Offtop Teil:
KarlMüller Du meinst einen Milan060 mit 50 MHz oder einen Milan040 mit 25 MHz?
Ungenau ausgedrückt ein Milan060 mit 25MHz Bustakt und 50MHz CPU Takt.
Meinst du das Maustausch-Programm CAT? Wow, hätte nicht gedacht daß das noch jemand benutzt.
Gut nutzen ist jetzt etwas übertrieben. Ich benötige es noch für die Archive der Mausgruppen. Hier rechariere ich öfteres mal in den Gruppen wie z.B. Maus.Computer.Atari.Programmieren.
-
ein komplett durchlauf von CAT benötigt fast 6 Minuten.
Meinst du das Maustausch-Programm CAT? Wow, hätte nicht gedacht daß das noch jemand benutzt.
Wieso nicht? Bei mir ist es nach wie vor täglich im Einsatz, Maustausch mit der letzten verbliebenen Maus (Berlin) und per In2CAT mit einem POP3-Postfach.
-
Im Anhang hätte ich die Datei kernel/bios/milan/doc/mmilan.txt. Ich habe die Struktur MILAN_OS an den tatsächliche Zustand angepasst.
In MagicMac/kernel/aes/aesevt.s ist mir was auf gefallen:
* FPU retten
tst.b is_fpu ; LineF- FPU installiert ?
beq.b ad_no_fpu ; nein!
fsave -(sp)
IF MC68060
tst.b 10(sp)
ELSE
tst.b (sp) ; NULL/IDLE/BUSY- Flag
ENDIF
beq.b ad_no_fpu ; NULL
fmovem.x fp0-fp7,-(sp) ; Datenregister
fmovem.l fpcr/fpsr/fpiar,-(sp) ; Statusregister
move.w #-1,-(sp) ; Flag fuer "FPU komplett gesichert"
Es gibt das Symbol MC68060, welches in der Datei explizit gesetz werden muss. So funktioniert das auf dem 60860 nicht richtig. Ich frage mich ob es wirklich Sinn macht da ne spezielle Abfrage zumachen und nicht einfach gernerel die Register der FPU retten. Ob das zeitlich jetzt so ins Gewicht fällt.
-
Im Anhang hätte ich die Datei kernel/bios/milan/doc/mmilan.txt.
Danke dir, ist geändert. Scheint aber nur die Dokumentation zu betreffen, in milan.inc stand das schon so drin.
In MagicMac/kernel/aes/aesevt.s ist mir was auf gefallen:
Huks, das ist natürlich ungeschickt. Muss ich mir mal genauer anschauen, wells auch '030 betrifft.
Ich frage mich ob es wirklich Sinn macht da ne spezielle Abfrage zumachen und nicht einfach gernerel die Register der FPU retten. Ob das zeitlich jetzt so ins Gewicht fällt.
Ich frage mich eher ob das überhaupt notwendig ist, kann mich nicht erinnern daß TOS 3.06 das macht. Auch EmuTOS macht das nicht. Wobei die natürlich auch nur umschalten wenn die App gerade einen AES-Aufruf macht.
-
Den FPU-Check im AES hab ich jetzt geändert. Den Test auf NULL-Frame kann man nicht so einfach rausnehmen wie ich feststellen musste, weil an ein paar anderen Stellen (z.B. wenn eine neue APP gestartet wird) dort lediglich ein NULL-Frame auf dem Stack erzeugt wird. Hoffe das passt für '060, konnte es leider nicht testen weil Aranym kein 060 emuliert, und Hatari beim Versuch abstürzt (könnte das an HDDRIVER liegen? Gibs da ne spezielle Version?)
Bei der Gelegenheit hab ich die CPU/FPU-Erkennung auch geändert, in der "normalen" Version hätte er 060 gar nicht erkannt.
-
Im Anhang hätte ich die Datei kernel/bios/milan/doc/mmilan.txt.
Scheint aber nur die Dokumentation zu betreffen, in milan.inc stand das schon so drin.
Ja, dem ist so. Dort habe ich die Infos auch her.
Den FPU-Check im AES hab ich jetzt geändert. Den Test auf NULL-Frame kann man nicht so einfach rausnehmen wie ich feststellen musste, weil an ein paar anderen Stellen (z.B. wenn eine neue APP gestartet wird) dort lediglich ein NULL-Frame auf dem Stack erzeugt wird. Hoffe das passt für '060,
Also hier funktioniert es. Allerdings hast Du die Variable 'cpu_typ' benutzt bevor sie gesetzt wird. Ich habe das ganze etwas umgestellt.
*
* CPU, Cookies und machine_type
*
move.w #8,stack_offset
jsr get_cpu_typ
move.w d0,cpu_typ
move.w #1,cpu020 ; MATHS.S: 68020-Arithmetik moeglich
jsr get_fpu_typ
cmp.w #40,cpu_typ
bcs.s set_fpu
bne.s set_fpu_060
moveq #8,d0
bra.s set_fpu
set_fpu_060:
moveq #16,d0
set_fpu:
move.b d0,is_fpu
inst_cook:
jsr ivideo ; Videosystem initialisieren
lea cookies,a0
move.l a0,_p_cookies
moveq #NCOOKIES,d0
jsr icookies ; maschinenspez. Cookies
; Wegen eines Fehler im MilanTOS. Es setzt bei einem 060
; nicht den richtigen Wert.
clr.l d1
move.b is_fpu,d1
swap d1 ; Wert
move.l #'_FPU',d0 ; key
bsr putcookie
*
* "soft"-Cookies (_IDT und MagX)
*
'stack_offset' und 'cpu020' habe einfach auf feste Werte gesetzt. Ein Milan kann nur ein 040 oder 060 haben.
Das mit dem falschem Cookie _FPU ist mindestens bis zum MilanTOS Version vom 2003.09.03.
(könnte das an HDDRIVER liegen? Gibs da ne spezielle Version?)
Nein, könnte natürlich sein das da intern Rücksicht auf den Milan genommen wird.
Bei der Gelegenheit hab ich die CPU/FPU-Erkennung auch geändert, in der "normalen" Version hätte er 060 gar nicht erkannt.
Das ist gut für die Falcon ct60 Fraktion. ;-)
Ich habe noch die Datei MagicMac/kernel/bios/milan/doc/milan_hw.txt in einer neueren Version angehängt.
-
Allerdings hast Du die Variable 'cpu_typ' benutzt bevor sie gesetzt wird. Ich habe das ganze etwas umgestellt.
Huch, na sowas. Ist gefixt, danke.
'stack_offset' und 'cpu020' habe einfach auf feste Werte gesetzt. Ein Milan kann nur ein 040 oder 060 haben.
Ich hab jetzt nur die Reihenfolge geändert und den Rest gelassen. Denke mal für die paar Byte lohnt es sich nicht, dort irgendwelche Annahmen zu machen.
Das mit dem falschem Cookie _FPU ist mindestens bis zum MilanTOS Version vom 2003.09.03.
Funktioniert das denn so in Zusammenarbeit mit Milan-TOS? Der cookiejar wird ja scheinbar komplett neu angelegt dort, ich sehe aber z.B. nicht daß dort ein _CPU cookie eingetragen wird. Auch ein paar andere wie _SND, _MCH und _VDO fehlen.
-
Ich hab jetzt nur die Reihenfolge geändert und den Rest gelassen. Denke mal für die paar Byte lohnt es sich nicht, dort irgendwelche Annahmen zu machen.
Das sind keine Annahmen. Der Milan kommt nur mit 040 oder 060 vor und die Funktion get_cpu liefert nur 40 oder 60. Deswegen macht es keinen Sinn 'stack_offset' erst auf sechs und dann immer auf acht zu setzen. Entsprechendes gilt für 'cpu020'.
Funktioniert das denn so in Zusammenarbeit mit Milan-TOS? Der cookiejar wird ja scheinbar komplett neu angelegt dort, ich sehe aber z.B. nicht daß dort ein _CPU cookie eingetragen wird. Auch ein paar andere wie _SND, _MCH und _VDO fehlen.
Das Anlegen der Cookies wird vom MilanTOS erledigt. Dort werden _CPU, _FPU, _VDO, _MCH, _MIL, _PCI, MNAM, _SND, _FDC, _FRB, _AKP, _IDT und EURO angelegt. Im MagiC Quelltext ist das die Funktion 'icookies'. Mein Zusatz hängt direkt hintendran.
-
So fühlt sich das dann aktuell bei mir an ^^
https://youtu.be/u9kvFbmaGZk
-
Nicht übel für so'n altes Schätzchen ;)
-
Mal was praktische. Ich habe eine geänderte Version der Funktion find_icon_pos angehängt.
Auch wenn ich das Iconfiy nicht so oft nutze hatte mich von Anfang angestört das die Icons immer von links nach rechts aufgebaut werden, kommt von MultiTOS. Deswegen habe das Programm ICFS installiert. Nun habe ich mir oben genannte Funktion so umgeschrieben das sie von rechts nach links geht.
Ich weis das ist jetzt etwas spezielles, zumal ich den Abstand von unten noch um 16 Pixel erhöht habe, weil hier Appline läuft. Ich wollte jetzt das ganze nicht aufblähen und das konfigurierbar machen. Ist hier per IF/ELSE/ENDIF im Quellcode.
-
Hm, IF/ELSE seh ich da keine. Find die Idee aber schon ganz sinnvoll, allerdings müsste man das wohl dann konfigurierbar machen irgendwie (gibt mit Sicherheit sonst wieder welche denen das nicht passt).
-
Wenn ich mich hier kurz laienhaft einmischen darf. Vielleicht versteh ich auch nur nicht um was es genau geht.
Wenn man ICFS installiert hat, kann man doch mit dem ICFS.CPX die Einstellungen für die iconifzierten Fenster machen. Also die Fenster, von rechts nach links ablegen lassen und auch die Position etc. einstellen.
-
Hm, IF/ELSE seh ich da keine.
IF 0
Original
ELSE
Neue
ENDIFEs sind zwar nur ein paar Zeilen die ich geändert habe, aber zur Übersichtlichkeit.
Find die Idee aber schon ganz sinnvoll, allerdings müsste man das wohl dann konfigurierbar machen irgendwie (gibt mit Sicherheit sonst wieder welche denen das nicht passt).
Klar, ich frage mich nur was an zusätzlichen Speicher kostet. Beim Milan mag das keine Rolle spielen. Aber wie sieht es beim ST aus.
Was mich auch wundert, wenn ich es richtig gesehen habe, kann ich wenn MagiC auf einen ST läuft alle XBIOS Funktionen vom TT oder Falcon aufrufen. Gehört das nicht beschränkt, also xbios_tab je nach Maschine verkürzt. Wobei bei den TT Funktionen wird die Maschine abgefragt, beim DSP nicht.
Wenn man ICFS installiert hat, kann man doch mit dem ICFS.CPX die Einstellungen für die iconifzierten Fenster machen.
Klar geht das und hatte ich auch so, aber wenn ich jetzt die Möglichkeit habe das ins BS zu verschieben, warum ein zusätzliches Programm starten. Beschleunigt etwas den Bootprozess und es hängt kein weiteres Programm im GEM-Trap. Zumal zumindest bei mir das Programm auch irgendeine Ausgabe macht wo durch T-Con bei jedem Start sich öffnet.
Wie geschrieben ist halt was spezielles von mir. Wollte nur den Quellcode teilen falls jemand sich das auch wünscht.
-
IF 0
Original
ELSE
Neue
ENDIF
Also endweder bin ich blind oder.... in der angehängten Datei seh ich da nix. Habs aber jetzt selber eingebaut.
Klar, ich frage mich nur was an zusätzlichen Speicher kostet.
Speicher weniger, ein bisschen zusätzlicher Code halt. Aber ich hatte auch nicht an ICFS gedacht, wems nicht passt kann das sich das ja darüber einstellen.
Was mich auch wundert, wenn ich es richtig gesehen habe, kann ich wenn MagiC auf einen ST läuft alle XBIOS Funktionen vom TT oder Falcon aufrufen. Gehört das nicht beschränkt, also xbios_tab je nach Maschine verkürzt. Wobei bei den TT Funktionen wird die Maschine abgefragt, beim DSP nicht.
Hm, ja, eigentlich schon. Bzw. müsste man mal genau checken ob da irgendwelche Katastrophen passieren, wenn man Funktionen aufruft für die die entsprechende Hardware garnicht vorhanden ist. Aber vermutlich war das schon immer so, wüsste nicht daß es für ST abgespeckte Versionen gegeben hat.
-
So fühlt sich das dann aktuell bei mir an ^^
https://youtu.be/u9kvFbmaGZk
Da muss man sich anschnallen, und zwar doppelt: a) noch keinen solchen TT gesehen, erhöhte Schwuppdizität! – worauf beziehen sich die 54 MHz?, und b) du darfst bitte nicht so viel schwenken und zoomen mit der Kamera, ich werd da reisekrank :-) Lieber feste Schnitte …
-
Prozesortakt. Dieser TT ist overclocked bis zum Anschlag.
-
Also endweder bin ich blind oder.... in der angehängten Datei seh ich da nix. Habs aber jetzt selber eingebaut.
So hatte ich es gemeint hatte. Bei nächsten wird es besser beschrieben.
MagicMac/kernel/aes/aesmain.s
dsp_xgrf_stepcalc:
cmpi.w #5,4(a1) ; contrl[2] (Laenge intout) == 5 ?
beq.b dsp_appl_getinfo
cmpi.w #1,4(a1) ; contrl[2] (Laenge intout) == 1 ? --> appl_getinfo_str
beq.b dsp_appl_getinfo
pea 10(a4)
pea 8(a4)
pea 6(a4)
Der AES Opcode 130 ist dreimal belegt. Einmal durch xgrf_stepcalc von GEM/3, dann durch appl_getinfo zum dritten gibt es appl_getinfo_str. Beim letzterem ist control[2] = 1 statt fünf und control[3] = 4 statt null, denn hier werden Zeichenketten zurück geliefert. Das wurde irgendwann bei XaAES eingeführt. Deswegen die zusätzliche Abfrage.
-
Das wurde irgendwann bei XaAES eingeführt. Deswegen die zusätzliche Abfrage.
Sollte eigentlich unnötig sein, da man das Vorhandensein sowieso vorher ermitteln muss (also appl_getinfo(96), mit dem normalen interface). Kann aber auch nicht schaden.
PS.: noch ein Bitte: bei neuem Code nach Möglichkeit englische Kommentare benutzen, da wir nun nicht mehr die einzigen sind die das lesen ;)
-
So fühlt sich das dann aktuell bei mir an ^^
https://youtu.be/u9kvFbmaGZk
Da muss man sich anschnallen, und zwar doppelt: a) noch keinen solchen TT gesehen, erhöhte Schwuppdizität! – worauf beziehen sich die 54 MHz?, und b) du darfst bitte nicht so viel schwenken und zoomen mit der Kamera, ich werd da reisekrank :-) Lieber feste Schnitte …
@gh-baden
Das war nur quick und dirty aufgenommen mitm Handy nix geschnitten ^^
Und jep 18Mhz Bus und 54MHz CPU und das Stabil (jetzt) man beachte den Vergleich zum Milan :)
-
Wenn es geht jetzt hier keine Dinge über einen beschleunigten TT austauschen. Dazu was eigenes auf machen.
Danke!
Sollte eigentlich unnötig sein, da man das Vorhandensein sowieso vorher ermitteln muss (also appl_getinfo(96), mit dem normalen interface).
Echt? Kannte ich so nicht. Aber im Vorgriff auf die Erweiterung von appl_getinfo ist es so oder so nötig.
bei neuem Code nach Möglichkeit englische Kommentare benutzen, da wir nun nicht mehr die einzigen sind die das lesen ;)
Ich versuch es. Wobei es gemein ist, ich muss mich ja auch ständig durch irgendwelche englische Texte quälen. ;)
Ich habe mich schon immer gefragt warum MagiC in der Version 6 die Menüzeile nicht grau dastellt trotz das man in der INF beim Parameter _FLG das siebte Bit gesetzt hat. Jetzt weiss ich das dies nur funktionierte wenn man einen unproportionalen Zeichensatz nutzen würde. Also geändert:
MagicMac/kernel/aes/aesmen.s in der Funktion menu_on
* Menue neu eingeschaltet. Auf mich umschalten
move.l a4,menu_app ; Eigner des Menues umsetzen
move.l a4,a0
bsr set_desktop ; und Hintergrund mit umschalten
mon__ismine:
move.l a5,menutree ; Menuebaum merken
* Set menu background color
btst #7,look_flags+1 ; 3D look for menu
beq.b mon_co_end
mon_col_loop:
move.w ob_type(a5),d1
and.w #$ff,d1
cmp.w #$14,d1 ; G_BOX ?
bne.s mon_col_box
andi.w #-$0010,$e(a5)
ori.w #$0008,$0e(a5)
andi.w #-$0071,$e(a5)
ori.w #$0070,$e(a5)
bra.s mon_col_box1
mon_col_box:
ori.w #$0400,ob_flags(a5)
mon_col_box1:
moveq #$20,d1
movea.l a5,a4
lea $0018(a5),a5
and.w $0008(a4),d1
beq.s mon_col_loop
move.l menutree,a5
mon_co_end:
* Proportional-Systemfont: Menuetitel neu ausrichten
tst.w finfo_big+fontmono
bne mon_fontmono
move.w 2*24+ob_head(a5),d0 ; erster Menuetitel
move.w 2*24+ob_x(a5),d7 ; abs. Pos. des ersten Titels
bmi mon_fontmono ; keine Menuetitel
move.w ob_tail(a5),d1 ; rechter Teil (Menues)
mulu #24,d1
move.w ob_head(a5,d1.l),d1 ; erstes Menue
moveq #0,d5 ; Pos. des ersten Titels
mon_title_loop:
mulu #24,d0
lea 0(a5,d0.l),a4 ; a4 = OBJECT *
move.w d5,ob_x(a4) ; x-Pos fuer Menuetitel
mulu #24,d1
lea 0(a5,d1.l),a6
move.w d5,ob_x(a6) ; Position auch fuer Menue
add.w d7,ob_x(a6)
move.l a4,a0 ; OBJECT *
jsr stw_title ; Breite setzen
add.w ob_width(a4),d5 ; Breite addieren
move.w ob_next(a6),d1 ; naechtes Menue
move.w ob_next(a4),d0 ; naechter Titel
cmpi.w #2,d0 ; ist der Parent ?
bne.b mon_title_loop ; nein
move.w d5,2*24+ob_width(a5) ; Breite des Parent setzen
Der Bereich ab "* Set menu background color" bis "* Proportional-Systemfont: Menuetitel neu ausrichten" ist neu. Danach sind zwei Stellen entfallen, die etwa so aussehen.
btst #7,look_flags+1
beq.b mon_2d1
ori.w #FL3DBAK,24+ob_flags(a5) ; Objekt 1: Menueleiste
mon_2d1:
Und wieder ist ein Programm MENU3D aus dem Startordner entfallen. Wenn das so weitergeht dann ist der bald leer. :)
-
Ehm, das ist mir ehrlich gesagt zu unübersichtlich ;) Benutzt du git, oder hast du sonst irgend ne Möglichkeit ein diff vorher/nachher zu machen? Wenn nicht, lieber die geänderte Datei komplett anhängen, solange ich die nicht selber an den gleichen Stellen geändert hab ist das einfacher.
-
Ehm, das ist mir ehrlich gesagt zu unübersichtlich
Naja, in dem Fall wäre es ein einfaches rein kopieren.
Anbei ein diff. Musste ich mit dem Apfel erstellen. Mit der Mupfel kommen immer Leerzeilen zwischen den einzelnen Zeilen.
-
Naja, in dem Fall wäre es ein einfaches rein kopieren.
Danke, war trotzdem einfacher so. Habs jetzt erstmal so eingebaut, aber ein paar Fragen bleiben noch offen: wenn ich das richtig sehen, wurde vorher nur bei allen Menütiteln FL3DBAK gesetzt, die neue Routine macht das jetzt bei allen Objekten. Passt das trotzdem? Ausserdem: gab es womöglich einen Grund warum das nur bei nicht-proportionalen Zeichensätzen gemacht wurde? In objc_sysvar(MX_MENUCOL) ist nämlich die gleiche Abfrage drin.
-
wenn ich das richtig sehen, wurde vorher nur bei allen Menütiteln FL3DBAK gesetzt, die neue Routine macht das jetzt bei allen Objekten. Passt das trotzdem?
Die Routine hat auch bei den Boxen das FL3DBAK gesetzt. Fand ich nicht gut. Nun wird nur die Farbe verändert.
gab es womöglich einen Grund warum das nur bei nicht-proportionalen Zeichensätzen gemacht wurde?
Es ist nur bei proportionalen Zeichensätze aktiv gewesen. Ich kenne keinen Grund, kann mir aktuell auch keinen vorstellen und finde auch keinen Hinweis in der Doku warum.
In objc_sysvar(MX_MENUCOL) ist nämlich die gleiche Abfrage drin.
Stimmt das hatte ich gesehen, aber vergessen zu ändern.
-
Ich versuche gerade, das frisch kompilierte MagiC auf meinem CT63+CTPCUI Falcon zu starten. Dort läuft ja ein modifizierter MaiC-Boooter, der diverse Sachen in der MAGIC.RAM patched, Dabei kommt eine Fehlermeldung:
WARNING ! A part is not patched ! (19/20)
Der Rechner kommt damit nicht bis zum Desktop, sondern hängt nach den Ausgaben von HDDRIVER.
Frohe Weihnachten!
Ektus.
-
Müsste ich mir mal anschauen was der genau macht, vermutlich findet er durch die Änderungen irgendwelche Stellen nicht. Je nachdem wie kompliziert das ist, könnte man evtl. auch den Kernel ändern daß man keinen speziellen Booter für CT60 mehr braucht.
Wenn ich das richtig verstanden habe, patch der im wesentlich
- 030 pmmu Befehle durch nops. Ist IMHO unnötig, weil an allen Stellen wo die benutzt werden ein exception Handler für illegal opcodes verwendet wird. Müsste man aber mal testen.
- Patcht die Stelle wo MagiC versucht den CPU-Typ festzustellen (könnte die sein die nicht gefunden wird, weil sie sich geändert hat). Grund für den Patch ist hier daß MagiC die '060 speziellen Vektoren für unsupported integer instruction etc. überschreibt und nicht wiederherstellt, und damit ein evtl schon installiertes 060 FPSP aushebelt. Das müsste man sicher ändern.
Alternativ könnte man das schon vorhandene FPSP60 ähnlich wie bei der Hades-Version mit in den Kernel packen, allerdings ist das relativ gross, und wird ja bei "normalen" Maschinen nicht gebraucht.
Weisst du zufällig ob da noch andere Sachen gemacht werden?
-
Ich weiß leider nicht genau, was da alles gepatched wird. Es sind jedenfalls 21 Einträge. Ausgaben beim Systemstart (vom Bildschirm abgetippt):
Patch vectors 3
Patch cache 2
Patch vectors 1
Patch vectors 2
Patch CTPCI
Patch PMMU 030 tree
Patch cache 1
Patch DSP
Patch floppy
Patch cache 3
Patch PSG printer
Patch movep 1
Patch movep 2
Patch movep 1
Patch cache 2
Patch reset 1
Patch cache 2
Patch reset 2
Patch CPU type
Patch FPU cookie
Patch context FPU
Diese Änderungen sind zusätzlich zum vorher schon gepatchten Magic.ram und werden bei jedem Systemstart ausgeführt.
MfG
Ektus.
-
Ok, danke, muss ich wohl doch mal in den Quellcode schauen. Einiges kann man vermutlich im Kernel schon ändern, z.B. die movep die vermutlich nur aus Performance-Gründen geändert werden um sie nicht emulieren zu müssen. Auch die CPU/FPU Cookies sollten eigentlich nach den letzten Änderungen schon stimmen. Der Rest ist mir noch ein Rätsel, hoffe mal ich finde da Kommentare im Source ;)
-
Ich habe geseht diese WEBpage auf Gitlab einige Monaten früher. Erste Gedanke war: wunderbar !
Und dann ... nur kleine Teilen von ... Aber es ist was geht heute überall - irreführend Titeln, ziehen Achtung auf jede Preis.
Warum firmen, leute wer arbeitete auf es nicht einfach macht alles öffentlich ? Kein Geld von diese 20-30 Jahr alt OS-en überhaupt.
Tatsachlich Ich habe meine Teorie warum ist so ...
-
Vlt. solltest du nochmal nachschauen. AK hat mittlerweile alles öffentlich gemacht, was von ihm ist. Nicht veröffentlicht sind lediglich NVDI (weil das von Behne&Behne ist), und MagicPC (von Franz Schmerbeck). Der Rest ist komplett vorhanden, und es lassen sich daraus die Magic-Kernel sowohl für MagicMac als auch Atari/Milan/Hades bauen.
Tatsachlich Ich habe meine Teorie warum ist so ...
Schön für dich.
-
Ich habe geseht diese WEBpage auf Gitlab einige Monaten früher. Erste Gedanke war: wunderbar !
Und dann ... nur kleine Teilen von ... Aber es ist was geht heute überall - irreführend Titeln, ziehen Achtung auf jede Preis.
Warum firmen, leute wer arbeitete auf es nicht einfach macht alles öffentlich ? Kein Geld von diese 20-30 Jahr alt OS-en überhaupt.
Tatsachlich Ich habe meine Teorie warum ist so ...
Das ist ein eher düsteres Menschenbild, das du da skizzierst. Andreas Kromke hat praktisch alles veröffentlicht, unter einer liberalen Lizenz. Ich finde das äußerst nett und zuvorkommend von ihm. Wieso du ihm da "clickbaits" und Aufmerksamkeits-Gier unterstellst kann ich nicht nachvollziehen.
-
Ok, danke, muss ich wohl doch mal in den Quellcode schauen. Einiges kann man vermutlich im Kernel schon ändern, z.B. die movep die vermutlich nur aus Performance-Gründen geändert werden um sie nicht emulieren zu müssen. Auch die CPU/FPU Cookies sollten eigentlich nach den letzten Änderungen schon stimmen. Der Rest ist mir noch ein Rätsel, hoffe mal ich finde da Kommentare im Source
Da hast Du Pech ich finde die Quellen nicht wirklich dokumentiert.
Miro Kropacek das bei sich unter github abgelegt: https://github.com/mikrosk/ct60tos/blob/master/MagiC/auto/src/magxboot.l
Allerdings habe die irgendein Fehler deswegen wohl nur als "View Raw". Bei mir verändert qed auch irgendwas beim laden. Ich hatte mal vor längerem begonnen das sauber zu machen, ist aber noch nicht fertig. Wenn Du noch etwas warte willst, dann ich mach es.
Neben dem Bootloader soll MagiC zuvor für den CT60 bzw. CT2 gepacht werden. Dazu gibt es das Programm magic_p.prg. Ich habe mal den relevanten Teil des Programm angehängt. Dort wird nach dem Wert "0xF039" gesucht und dann ein Sprung eingebaut. Wohl aber nur neun mal.
Es hängt noch eine Datei mit einer minimalen Dokuänderung an.
-
Da hast Du Pech ich finde die Quellen nicht wirklich dokumentiert.
Ja, hab ich auch schon festgestellt, Wenn überhaupt, dann in französisch :(
Allerdings habe die irgendein Fehler deswegen wohl nur als "View Raw".
Vermutlich Probleme mit Umlauten. Oder er kann mit der Dateiendung .l nix anfangen.
Wenn Du noch etwas warte willst, dann ich mach es.
Ja, gerne.
Dazu gibt es das Programm magic_p.prg.
Ja, das hatte ich mir schon mal angeschaut. Der Wert 0xf039 ist der Start für die PMMU-030-Befehle (zumindest für die, die MagiC benutzt). Wie gesagt, ich denke das zu patchen ist nicht nötig, müsste aber dann hinterher mal ausprobiert werden. Wenns doch benötigt wird, müsste man das Programm anpassen, nach den letzten Änderungen taucht der Befehl jetzt 10 mal auf.
-
Dazu gibt es das Programm magic_p.prg.
Ja, das hatte ich mir schon mal angeschaut. Der Wert 0xf039 ist der Start für die PMMU-030-Befehle (zumindest für die, die MagiC benutzt). Wie gesagt, ich denke das zu patchen ist nicht nötig, müsste aber dann hinterher mal ausprobiert werden. Wenns doch benötigt wird, müsste man das Programm anpassen, nach den letzten Änderungen taucht der Befehl jetzt 10 mal auf.
Oder gleich eine modifizierte Version der Magic.ram compilieren, die diese Patches nicht braucht (erkennt, auf welcher CPU sie läuft und mit welcher sonstigen Hardware, und sich entsprechend verhält)? Setzt aber voraus, daß jemand den Patch versteht...
Okay, so schlimm sieht der Source des modifizierten magxboot ja gar nicht aus. Wenn Du Probleme mit dem Französisch hast, mein Schulfranzösisch ist zwar reichlich eingerostet, aber die paar Kommentare bekomme ich glaub' ich noch übersetzt :)
MfG
Ektus.
-
Was da gepatcht wird kann man noch relativ einfach verstehen. Die Frage ist nur manchmal, warum die Patches notwendig sind. Bei manchen ist es klar (Cache-Bits sind z.B. beim 030 anders als bei 040/060), bei anderen ist mir das nicht in allen Fällen klar. In jedem Fall ist es aber merkwürdig vorher ein Patch-Programm laufen lassen zu müssen, wenn der Bootloader dann noch weitere Sachen patcht, das sollte man dann (wenn nötig) mit in den Loader packen. Auch scheint er grundsätzlich die Patches auszuführen wenn CPU-Typ = 60, das könnte aber auch ein Milan oder Hades sein, und ein paar der Patches scheinen nur für CT60 relevant zu sein.
-
In jedem Fall ist es aber merkwürdig vorher ein Patch-Programm laufen lassen zu müssen, wenn der Bootloader dann noch weitere Sachen patcht, das sollte man dann (wenn nötig) mit in den Loader packen.
Stimmt, wäre nur Konsequent. Und dann könnte man vielleicht sogar soweit kommen, daß man in 030 und 060 von derselben Partition Booten kann. Das geht nämlich AFAIK derzeit nicht. Wobei es da noch mehr anzupassen gilt (NVDI Bildschirmtreiber zum Beispiel).
MfG
Ektus.
-
Anbei habe ich mal die magxboot.s für den CT60. Ob es besser zu lesen ist leigt natürlich im Auge des Betrachters. Ein bischen verbessern könnte es noch werden, ich habe nicht alles als Makro gemacht.
Auf jedenfall läßt sich diese Version mit PASM übersetzen. Die vorherige war mit Profimat erstellt.
-
Vielen Dank! Das sieht schon mal deutlich lesbarer aus. Hast du das ursprünglich mit TTDigger erzeugt?
Jetzt müsste man noch testen, ob das damit erzeugte Programm auch mit dem alten und/oder neuem kernel funktioniert ;)
Update: da war ein addq.w zu viel nach dem Aufruf des Super Macro am Ende. Wenn man das korrigiert, ist das erzeugte Programm identisch zu der Version 1.02b (abgesehen von memory protection bits die bei bei der original-Version auf global gesetzt sind, dürfte aber denke ich irrelevant sein, da MagiC ja bisher kein memory-protection unterstützt).
-
Das sieht schon mal deutlich lesbarer aus. Hast du das ursprünglich mit TTDigger erzeugt?
Ja, ich habe Digger genommen wegen den Makros. Der erzeugt gleich ansehnlichen Code und wenn man ein Symbol ändert wird es gleich an allen Stellen mit geändert.
da war ein addq.w zu viel nach dem Aufruf des Super Macro am Ende.
Ups, das hätte natürlich nicht passieren soll. Danke für die Kontrolle. Im Prinzip könnte man den Quelltext noch besser machen, nur scheint mir die Arbeit erstmal unnötig.
Was anderes:
Der Ordner xp_rastr.slb (https://github.com/th-otto/MagicMac/tree/master/extensio/xp_rastr.slb) ist leer. Auf Andreas Kromke Seite (https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/tree/master/MagiC/EXTENSIO/XP_RASTR.SLB) sind Quellen drin. Verlogen gegangen?
Bezüglich Sortierung, sollte die load_img.slb (https://github.com/th-otto/MagicMac/tree/master/tools/load_img.slb) nicht auch nach extensio (https://github.com/th-otto/MagicMac/tree/master/extensio)?
-
Danke für die Kontrolle.
Danke eher für deine Mühe. Nach der einen Änderung wird tatsächlich das identische Programm erzeugt, also sehr gute Arbeit.
Im Prinzip könnte man den Quelltext noch besser machen, nur scheint mir die Arbeit erstmal unnötig.
Das passt schon sehr gut. Macros sind eher hinderlich wenn das mal mit einem anderen Assembler übersetzen will, da sind die doch sehr unterschiedlich. Wichtiger wäre eher zu kommentieren, was da gepatcht wird, und warum, aber dazu muss ich erstmal die gepatchten Stellen im Original wiederfinden.
Der Ordner xp_rastr.slb (https://github.com/th-otto/MagicMac/tree/master/extensio/xp_rastr.slb) ist leer.
Ups. Liegt daran daß das Verzeichnis in .slb endet und dadurch komplett ignoriert wird. Sollte jetzt behoben sein. Die Library wird aber auch nirgendwo benutzt, und ist im Archiv vom Emulator auch gar nicht vorhanden.
Bezüglich Sortierung, sollte die load_img.slb (https://github.com/th-otto/MagicMac/tree/master/tools/load_img.slb) nicht auch nach extensio (https://github.com/th-otto/MagicMac/tree/master/extensio)?
Ja, stimmt, könnte man machen.
-
WARNING ! A part is not patched ! (19/20)
Der Rechner kommt damit nicht bis zum Desktop, sondern hängt nach den Ausgaben von HDDRIVER.
Ich wühle mich gerade durch den Source, und eigentlich müsste das Bootprogramm versuchen 19 Stellen zu patchen, und nicht 20. Mit dem aktuellen Kernel sollten davon 3 Stellen nicht mehr gefunden werden die mit der Cpu- und FPU-Typ Erkennung zusammen hängen, und nicht mehr benötigt werden weil der Kernel das jetzt richtig machen sollte.
Benutzt du irgendeine aktuellere (oder evtl. ältere) Version von dem Boot-Programm? Die Version die wir z.Z. verwenden ist aus dem CT60 1.03c Paket.
Was noch interessant wäre zu wissen: ist der _FRE cookie bei dir gesetzt, wenn kein MagiC gebootet wird? Der wird scheinbar vom BIOS angelegt um anzuzeigen daß der Videl eine externe Clock benötigt. In dem Fall würden noch 3 weitere Stellen in magic.ram gepatcht. Ausserdem geht der Cookie, wenn ich das richtig sehe, verloren sobald MagiC gebootet wird, weil MagiC den Cookie-Jar komplett neu anlegt.
Was auch noch gepatcht wird ist die DSP-Initialisierung. Sehe ich das richtig, daß die bereits vom CTBIOS vorgenommen wird?
-
Ok, die Frage bzgl. der Version kann ich möglicherweise selber beantworten: es gibt unter https://github.com/mikrosk/ct60tos/blob/2.01/MagiC/auto/src/magxboot.l scheinbar eine neuere Version als die, die im master-branch von Mikro eingecheckt ist. Siehst du vom Booter eine Meldung "Patch CTPCI" und/oder "Patch boot IDE slave" ?
-
Ok, die Frage bzgl. der Version kann ich möglicherweise selber beantworten: es gibt unter https://github.com/mikrosk/ct60tos/blob/2.01/MagiC/auto/src/magxboot.l scheinbar eine neuere Version als die, die im master-branch von Mikro eingecheckt ist. Siehst du vom Booter eine Meldung "Patch CTPCI" und/oder "Patch boot IDE slave" ?
Weder, noch. Ich habe MAGXBOOT.PRG mit 3680 Bytes und Dateidatum 15.05.2010. Stammt wohl aus einem der beta-Archive von Didier, die ich seinerzeit getestet habe. Eine Datei gleicher Größe mit Datum 23.03.2010 habe ich jedenfalls auch noch gefunden.
MfG
Ektus.
-
Weder, noch. Ich habe MAGXBOOT.PRG mit 3680 Bytes und Dateidatum 15.05.2010.
Hm seltsam. in Miro's repo die aktuelle version ist 3568 bytes, die Version für 2.01 (mit den PCI Änderungen) 3870 (nach Datum kann man bei git leider nicht gehen, das wird jedesmal auf das aktuelle gesetzt). Die 20 Patches die er da finden will deuten jedenfalls auf eine Version hin die schon für CTPCI gedacht ist. Könntest du mal die angehängte Version ausprobieren? Das Boot-Programm ist angepasst, und sollte sowohl mit dem neuen als auch dem original 6.20 Kernel funktionieren.
-
1) Neues Magxboot und alte MAGIC.RAM: System startet
2) Neues Magxboot und neue MAGIC.RAM, ungepatcht: System startet nicht (Reboot wenn eigentlich der Desktop kommen sollte)
3) Neues Magxboot, neue MAGIC.RAM, gepatcht: System friert nach der zweiten Bootmeldung von HDDRIVER ein.
Ich glaub, Du brauchst einen CT60 Falcon mit CTPCI >:D
MfG
Ektus.
-
1) Neues Magxboot und alte MAGIC.RAM: System startet
Na wenigstens etwas.
2) Neues Magxboot und neue MAGIC.RAM, ungepatcht: System startet nicht
Gnarf.
Ich glaub, Du brauchst einen CT60 Falcon mit CTPCI >:D
Ja, denke auch, schenkst du mir einen? :D
Ich könnte natürlich eine Debug version basteln die ein paar Ausgaben macht, dann würde man vlt. wenigstens sehen wie weit er kommt. Zumindest ein paar der Ausgaben landen allerdings lediglich auf dem Bildschirm. Wärst du bereit da noch ein paar Tests zu machen?
Ansonsten müsste ich evtl. mal versuchen Hatari mit 060 emulation zum laufen zu bekommen. dazu bräuchte aber wohl mindestens das für '060 gepatchte TOS 4.04. kA was genau ich da brauche, da es wohl verschiedene Versionen davon gibt, und auch keine Ahnung ob das funkionieren könnte.
-
Ich glaub, Du brauchst einen CT60 Falcon mit CTPCI >:D
Ja, denke auch, schenkst du mir einen? :D
Ich hab' leider nur den einen :(
Ich könnte natürlich eine Debug version basteln die ein paar Ausgaben macht, dann würde man vlt. wenigstens sehen wie weit er kommt. Zumindest ein paar der Ausgaben landen allerdings lediglich auf dem Bildschirm. Wärst du bereit da noch ein paar Tests zu machen?
Im Prinzip schon, aber da der Weihnachtsurlaub gerade vorbei ist, geht es nur am Wochenende.
Wenn nach den Ausgaben jeweils auf eine Taste gewartet wird, kann ich die auch vom Bildschirm ablesen.
Ansonsten müsste ich evtl. mal versuchen Hatari mit 060 emulation zum laufen zu bekommen. dazu bräuchte aber wohl mindestens das für '060 gepatchte TOS 4.04. kA was genau ich da brauche, da es wohl verschiedene Versionen davon gibt, und auch keine Ahnung ob das funkionieren könnte.
Da kann ich überhaupt nicht helfen, Emulatoren habe ich noch nie benutzt, höchstens mal kurz angetestet.
MfG
Ektus.
-
Ich habe geseht diese WEBpage auf Gitlab einige Monaten früher. Erste Gedanke war: wunderbar !
Und dann ... nur kleine Teilen von ... Aber es ist was geht heute überall - irreführend Titeln, ziehen Achtung auf jede Preis.
Warum firmen, leute wer arbeitete auf es nicht einfach macht alles öffentlich ? Kein Geld von diese 20-30 Jahr alt OS-en überhaupt.
Tatsachlich Ich habe meine Teorie warum ist so ...
@Petari!
Bist Du der Betreiber dieser Page (http://atari.8bitchip.info/) und damit Urheber vieler schöner Sachen zum ST?
Falls ja, hast Du nicht auch das MagiC für ROM (LINK finde ich auf Deiner Seite nicht) angepaßt? In diesem Falle kannst Du mir vielleicht helfen - aber ich fange dazu am Besten einen neuen Thread an! Hier nur soviel: Ich habe einen MegaST4, der mit einem Nachbau Deiner IDE Schnittstelle und F-TOS Geschichte erweitert wurde. Verwendet werden hier TOS 1.(0)4, TOS 2.(0)6, Deine (?!?) MagiC ROM Fassung und EmuTOS! Weiteres dann im eigenen Thread, den ich nach Bestätigung anfange!
-
Im Prinzip schon, aber da der Weihnachtsurlaub gerade vorbei ist, geht es nur am Wochenende.
Hm, schade, aber das würde wahrscheinlich dann wohl ziemlich mühselig und langwierig werden.
Was mir noch eingefallen ist: mit gepatchter Version meinst du denke ich eine über die magic_p.prg drüber gelaufen ist. Die Patches die dort gemacht werden, sind noch nicht im neuen bootloader integriert. Da dort eine feste Anzahl von Befehlen gepatcht wird, verpasst er im neuen Kernel eine Stelle. Das dürfte aber die Stelle beim Kaltstart sein, also wenn man alt-ctrl-shift-del drückt.
-
Im Prinzip schon, aber da der Weihnachtsurlaub gerade vorbei ist, geht es nur am Wochenende.
Hm, schade, aber das würde wahrscheinlich dann wohl ziemlich mühselig und langwierig werden.
Was mir noch eingefallen ist: mit gepatchter Version meinst du denke ich eine über die magic_p.prg drüber gelaufen ist.
Genau das.
MfG
Ektus.
-
Ok meine Annahme daß der verpasste Patch harmlos ist war leider falsch. Er verpasst genau die Stelle die neu hinzugekommen ist, und die ist ausgerechnet da wo er versucht den CPU-Typ zu erkennen. Könntest du evtl. das angehängte neue Patch-Programm (magic_p.tos) mal versuchen? Sollte genauso wie der Boot-Loader sowohl mit original als auch mit neuem Kernel funktionieren.
Kernel ist auch nochmal geringfügig geändert, mal schauen ob's hilft ;)
-
...
@Petari!
Bist Du der Betreiber dieser Page (http://atari.8bitchip.info/) und damit Urheber vieler schöner Sachen zum ST?
Falls ja, hast Du nicht auch das MagiC für ROM (LINK finde ich auf Deiner Seite nicht) angepaßt? In diesem Falle kannst Du mir vielleicht helfen - aber ich fange dazu am Besten einen neuen Thread an! Hier nur soviel: Ich habe einen MegaST4, der mit einem Nachbau Deiner IDE Schnittstelle und F-TOS Geschichte erweitert wurde. Verwendet werden hier TOS 1.(0)4, TOS 2.(0)6, Deine (?!?) MagiC ROM Fassung und EmuTOS! Weiteres dann im eigenen Thread, den ich nach Bestätigung anfange!
Ich bin Betreiber. Aber muss sagen das Ich habe arbeitet nur auf English v. Kompletieren English übersetzung. Von letzte MagiC v. - und nur das hat gut IDE boot Code. Das ist nicht auf meine Seite, ich habe publiziert nur auf atari-forum. (AF) . Ich glaube das Ich brauche zum machen neu Seite für das auf mein Atari Abschnitt ...
Flash EPROMs in ST ... Ja, das ist meine Seite, mein Projekt . Sehen Jahr ... - 10 Jahren alt :)
-
Ok meine Annahme daß der verpasste Patch harmlos ist war leider falsch. Er verpasst genau die Stelle die neu hinzugekommen ist, und die ist ausgerechnet da wo er versucht den CPU-Typ zu erkennen. Könntest du evtl. das angehängte neue Patch-Programm (magic_p.tos) mal versuchen? Sollte genauso wie der Boot-Loader sowohl mit original als auch mit neuem Kernel funktionieren.
Kernel ist auch nochmal geringfügig geändert, mal schauen ob's hilft ;)
Kann ich, aber frühestens Freitag Nachmittag. Fernbedienung über 125km ist irgendwie schwierig...
MfG
Ektus.
-
Hatte ich befürchtet, schade. Naja vlt. finde ich noch ein paar Sachen bis dahin. Auf jeden Fall läuft es unter Hatari jetzt schonmal mit 060 (wobei EmuTOS als ROM verwendet wird, darum steht das da auch in der Info-Zeile):
-
der Bug in der Behandlung von ColorIcons auf dem TT hat mit der Palette*** überhaupt nichts zu tun (und höchstwahrscheinlich auch nix mit NVDI), sondern es handelt sich imho ganz offenbar um einen schlichten Bug in der Logik der Cicons-Routine des MAGX. Es gibt ihn nicht auf dem F30, und es gibt ihn nicht in Grafik-Auflösungen >= 8p, aber mit 4p auf dem TT sieht man ihn sofort, und zwar unabhängig vom Desktop: Anstatt die 4p-Images der Cicons darzustellen wird auf ´niedrigere´ Images regrediert.
Kann mal jemand das angehängte Test-Programm in verschiedenen Auflösungen starten (und wenns geht auch auf Falcon/TT) und Screenshots posten wo das nicht das tut was es soll? Ich kann hier irgendwie nichts ungewöhnliches feststellen.
-
Coloricon.prg auf dem Milan mit MagiC-Milan und Ati Rage: Die Icons nehmen beim Deselektieren nicht mehr ihre ursprüngliche Form an.
-
Ja, hab ich auch schon gesehen. Das ist ein Design-Problem, wenn das selektierte Icon eine andere Maske als das normale hat, wird beim deselektieren der Hintergrund nicht neu gezeichnet. Der Fehler tritt bei XaAES auch auf, da hat Atari beim Design nicht richtig nachgedacht.
Hier ging es aber um den Bug den ari.tao beschrieben hat, daß bei 4-Planes ein falsches, oder gar kein Coloricon dargestellt wird. Das kann ich irgendwie nicht reproduzieren.
-
Ok meine Annahme daß der verpasste Patch harmlos ist war leider falsch. Er verpasst genau die Stelle die neu hinzugekommen ist, und die ist ausgerechnet da wo er versucht den CPU-Typ zu erkennen. Könntest du evtl. das angehängte neue Patch-Programm (magic_p.tos) mal versuchen? Sollte genauso wie der Boot-Loader sowohl mit original als auch mit neuem Kernel funktionieren.
Kernel ist auch nochmal geringfügig geändert, mal schauen ob's hilft ;)
Ich habe die beiden Dateien gerade ausgetauscht und die MAGIC.RAM vorher mit dem beiliegenden Patchprogramm bearbeitet. Der Falcon startet erfolgreich auf der Radeon in 1920x1200 und ganz vielen Farben.
Es hilft :)
MfG
Ektus.
-
Hey, vielen Dank für testen, ist ja mal ne gute Nachricht ;)
Interessant wäre vlt noch zu wissen ob es auch läuft ohne magic_p vorher drüber laufen zu lassen. Ansonsten wäre es wohl am sinnvollsten, das mit den in den Bootloader einzubauen..
-
Hier angehängte Zip-Dateien sollten nun der Vergangenheit angehören, denn ab sofort sind automatisch erzeugte Archive (https://bintray.com/th-otto/magicmac-files/snapshots/_latestVersion#files) verfügbar!!!
Die Archive beinhalten alle Atari-Kernels (ausser dem macOS-Kernel für AtariX, da muss ich mir noch was einfallen lassen wie ich das mit dem anderen Repo kombiniere), sowie sämtliche Applikationen.
Ausreden, daß man es nicht selber übersetzen kann, gibt es also nicht mehr ;);););)
-
Hier angehängte Zip-Dateien sollten nun der Vergangenheit angehören, denn ab sofort sind automatisch erzeugte Archive (https://bintray.com/th-otto/magicmac-files/snapshots/_latestVersion#files) verfügbar!!!
Die Archive beinhalten alle Atari-Kernels (ausser dem macOS-Kernel für AtariX, da muss ich mir noch was einfallen lassen wie ich das mit dem anderen Repo kombiniere), sowie sämtliche Applikationen.
Klasse, danke!
-
Getestet auf einer 68000 4MB Maschine ?
Bekomme auf meinem Mega STE beim starten von GemDesk immer die Meldung Speicher Mangel !
-
Nein, aber welches Archiv hast du genommen, das erste? Das hatte noch spinmagc.xfs im XTENSION Ordner aktiv, wenn ja schmeiss das mal raus oder benenn es um, scheint das macht noch etwas Zicken.
Evtl. auch andere Sachen die du nicht brauchst (ramdisk z.B.)
-
magicmac-20190113-094503-bin
Start Ordner alles *.prx und im Xtension Ordner alles *.XFX, sollte also alles aus sein.
-
Was ist der Stand der Dinge? Gibt´s Neuigkeiten?
-
Nur so als Info:
Andreas hat auf GitLab noch die C Quellen zu den IDE Funktionen nach geschoben.
-
Ja, danke, hatte ich schon gesehen. Hatte ich bei meiner Version durch 'ne disassemblierte Version ersetzt. Mal schauen ob beim übersetzen der C-Sourcen tatsächlich das gleiche rauskommt ;)
-
Mir ist aufgefallen das in den Quellen der Bootloader für den Milan fehlt, hängt an. Kann einfach so in das Verzeichnis "kernel ▸ bios ▸ atari ▸ boot" kopiert werden. all.prj noch anpassen.
Das Ganze ist ein disassembling des Original. Ich habe es soweit mit Kommentaren und Funktionen an das schon vorhandene angepasst. Die erzeugte Programmdatei ist zwei Byte größer als das Original, was meiner Meinung daran liegt das einen Fehler in dem Alten gibt und zwar bei den Zeichenketten zur Sprachauswahl.
-
Danke, ist jetzt drin. IDE Routinen sind auch ersetzt.
-
Ich grabe diesen Thread auch mal aus!
Ist es möglich das Magic so zu modifizieren so das es Fastram im ST erkennt ?
Sprich Fastram ab 0x400000 wie es bei der Magnum ST, Monster und auch bei unserer Storm ST der fall ist?
Ich denke Magic würde davon profitieren! Wenn der Kernel direkt ins Fastram geladen wird, gerade wenn Booster im ST verbaut sind!
-
Wenn ich mich nicht täusche, ist das Alt-RAM von der Monster-Karte kein "Fast"-Ram, sprich ist auch nicht schneller als das normale RAM. Ausserdem muss die Erkennung ja schon dann schon vorher laufen, den Magic-Kernel nach dem laden ins Alt-RAM zu verschieben ist nicht so ohne weiteres möglich. Einzige Möglichkeit wäre den boot-loader entsprechend anzupassen. Sicherlich machbar, aber dazu müsste ich erstmal wissen ob sich der Aufwand lohnt, zumal es ja nicht selber testen kann.
-
Generell hast du recht, aber gerade im Zusammenhang mit Beschleunigern ist der Altram schneller als der ST Ram. Ich meine für den TT ist doch auch eine Alt (Fastram) Erkennung drin. Denke das sollte man doch auch nutzen können ?