atari-home.de - Foren
Hardware => Emulatoren => Thema gestartet von: AndreasKromke am So 23.11.2025, 16:11:04
-
Die Kette von "Atari-High-Level-Emulatoren" MagicMac, MagicMacX und AtariX ist schon länger eine Sackgasse, seit letzteres nicht mehr auf neueren Macs funktioniert.
Aus eher unangenehmem, gegegeben Anlaß (Bewegungseinschränkung, man wird alt, und manche werden halt ein paar Dekaden früher alt als andere, wenn sie überhaupt so alt werden) habe ich gerade viel Zeit, und was hilft gegen Depri? Alkohol oder Hacken.
Jedenfalls hatte ich schon lange den Wunsch, meinem Stiefkind AtariX einen soliden Nachfolger zu geben, und das ist für mich kein proprietäres System wie macOS (bisher mit Carbon) oder Windows, sondern Linux. Weil der Name "Magic Linux" vergeben ist, habe ich "MagicOnLinux" geschrieben.
Hier ist das Repository für MagicOnLinux. Es enthält nur Quellen, das Programm sollte sich aber zumindest unter Ubuntu einfach bauen lassen. Wie man an das "root file system" kommt, ist auch beschrieben. Und nein, komfortabel ist das (noch) nicht, und schön schon gar nicht.
https://gitlab.com/AndreasK/magiclinux
Für das "debugging" habe ich einen Disassembler benötigt. Ich habe deshalb meinen von GEMDOS nach Linux portiert:
https://gitlab.com/AndreasK/disass68k
(Scheiß-Little-Endian...)
[Andere Emulatoren]
Angesichts von Hatari und Aranym ist mein Emulator eher uninteressant, aber ich habe das ja auch für mich gemacht. Meiner ist etwa 20mal so schnell wie Hatari und etwa so schnell wie Aranym ohne JIT. Aranym-jit ist unerreicht, etwa 20- bis 40mal so schnell wie meiner. Grafikausgabe ist noch schneller, weil teilweise nativ. Von der FPU-Emulation ganz zu schweigen...
Wobei Hatari mit Emutos prima, out-of-the-box mit toll geschriebener Anleitung stabil läuft und ich dagegen bei Aranym ohne Afros nur geflucht habe. Mit Afros lief es dann. Mit dem Mauszeiger haben aber Hatari und Aranym derbe Problem, und Drag&Dop geht auch nicht.
[technisches Blabla]
Die letzte, leidlich funktionierende Version, AtariX, habe ich als Grundlage genommen. Ich habe einiges rausgeworfen, aber auch viel hinzugefügt, insbesondere die Fähigkeit, "disk images" sehr einfach einzubinden.
Beim Portieren war nicht nur die proprietäre Apple-API ein Problem, sondern auch meine Kurzsichtigkeit, im Jahre 1994 auf 32-Bit-Call-Back-Zeiger zu setzen. Die habe auch dringelassen und mit einem abenteuerlichen Verfahren weiterverwendet, weil ich keine lauffähige Atari-"tool chain" mehr greifbar hatte, um den MagiC-Kernel zu ändern und neu zu compilieren. Als das System dann so halbwegs lief, habe ich im Emulator den MagiC-Kernel zumindest besser ans neue Dateisystem anpassen können. Ich war nämlich 1994 so kurzsichtig gewesen, das fileID/vRefNum-Schema für das Dateisystem zu verwenden, weil das so bequem schien. Dämlich. Aber ich war halt jung und brauchte das Geld.
Überhaupt war das Neuschreiben des "host file system" eine Sisiphos-Arbeit. Alles von Carbon auf POSIX. Da sind auch noch ein paar Unschönheiten und Fehler drin.
Im Gegensatz zu MagicMacX und AtariX funktionieren jetzt auch die "interleaved plane"-Modi. Da hatte ich nämlich irgendwann Anfang der 2000er natürlich kein Bindestrich Jahre einen kleinen Fehler gemacht...
Wie die anderen Emulatoren beruht auch MagicOnLinux immer noch auf SDL. Mit dem Unterchied, daß auch unter X11 die Umlauttasten funktionieren und nicht nur unter Wayland. Was für ein Quatsch, was da in SDL gemacht wird! Aber wer braucht schon Umlaute?
Im Prinzip müßte sich das Programm mit vertretbarem Aufwand auf macOS portieren lassen, wobei man SDL wohl nachinstallieren kann. Windows hat eine ganz andere Dateisystem-API, soviel ich weiß. Ich habe aber nur einen alten Mac, und Windows tue ich mir nicht an.
-
Cool! Vielen Dank.
Ließ sich problemlos auch auf ARM64-Linux bauen und läuft. Siehe Anhang.
Mit dem Mauscursor habe ich Probleme, er scheint manchmal wild zu springen. Aber vielleicht liegt das daran, dass ich mein Linux-Entwicklersystem per Remote-Desktop erreiche...
-
Liess sich hier auch (relativ) problemlos bauen.
Host-FS scheint noch ein bisschen Probleme zu haben, MagXDesk zeigt immer nur "mehr als xx Objekte" an, aber fast nie alle.
-
BTW: funktioniert auch mit einem just frisch übersetztem Kernel:
-
Deutsche/Englische/Französische Versionen werden jetzt auch automatisch für die snapshots gebaut:
https://tho-otto.de/snapshots/magicmac/magicmac-20251123-180216-bin.zip
Falls die jemand austauschen möchte.
-
Klasse und vielen Dank dafür ...
-
Die Migration nach macOS hat freundlicherweise Claude Code übernommen :)
Muss aber noch eine Konfiguration basteln...
-
Hmm..auf dem Mac scheint keine Auflösung akzeptiert zu werden. Tipps?
-
@AndreasK : hast du einen Account auf https://www.atari-forum.com? Sonst würde ich das dort auch bekannt machen.
-
Cool! Vielen Dank.
Ließ sich problemlos auch auf ARM64-Linux bauen und läuft. Siehe Anhang.
Mit dem Mauscursor habe ich Probleme, er scheint manchmal wild zu springen. Aber vielleicht liegt das daran, dass ich mein Linux-Entwicklersystem per Remote-Desktop erreiche...
Das klingt ja prima. Aber ARM ist ja inzwischen auch little-endian, und wenn niemand Assembler verwendet, sollte das auch keine Probleme machen. Interessant wäre, ob es auch auf 32-Bit geht oder auf big-endian. Theoretisch könnte das funktionieren, weil ich entsprechende Konvertierungen à la be32toh (32-bit big-endian to host endian) verwendet habe, die immer passen sollten.
Der Mauszeiger folgt stumpf bzw. intelligent dem Zeiger des Hosts. Dafür gibt es SDL-Nachrichten, "mouse moved" oder so. Wenn die nicht zeitnah kommen, kann es natürlich ruckeln. Die anderen Emulatoren machen das irgendwie anders, aber ich habe nicht nachgeschaut, wie. Vielleicht greifen sie in eine tiefere Schicht des Host-BS.
-
Liess sich hier auch (relativ) problemlos bauen.
Host-FS scheint noch ein bisschen Probleme zu haben, MagXDesk zeigt immer nur "mehr als xx Objekte" an, aber fast nie alle.
Das ist seltsam. Ist das macOS? Näheres könnte man in den log-Ausgaben per stderr sehen. Dazu mit cmake im Debug-Modus bauen (ist default) und vorher ggf. in config.h die INF und WRN fürs XFS einschalten.
Ich habe noch einen sechzehn alten Mac mit Mojave, der aber schon in Rente ist. Den wollte ich nicht mehr quälen, und ich habe mich schon lange an Ubuntu gewöhnt, das ich auch beruflich genutzt habe.
-
Hmm..auf dem Mac scheint keine Auflösung akzeptiert zu werden. Tipps?
Vermutlich eine Unverträglichkeit im Host-XFS. Ich habe absolut keine Rücksicht auf macOS genommen und ausschließlich Ubuntu Linux verwendet. Die Log-Ausgabe könnte bereits hilfreich sein, die kriegt man über config.h, dort die Zeile fürs XFS auskommentieren, dann per cmake als "debug" bauen. Das Host-XFS ist brandneu und vollständig mit Doxygen-Kommentaren geschrieben, das sollte recht übersichtlich sein.
Ich kann überhaupt Ubuntu Linux empfehlen; es gibt auch ein "GNOME Theme", das das System aussehen läßt wie macOS (viel hübscher als das Ubuntu-Thema), aber leider kochen zunehmend sehr viele Programme ihr eigenes Süppchen bei den Fenster-Rändern, und dann wird es uneinheitlich. Mal sind die Knöpfchen bunt, mal wie im Ubuntu-Thema und manchmal anders häßlich. Wildwuchs wie unter Windows.
-
@AndreasK : hast du einen Account auf https://www.atari-forum.com? Sonst würde ich das dort auch bekannt machen.
Danke, gute Idee, aber ich werde mir selber einen besorgen. Ich bin auch des Englischen mächtig, wenn ich auch seit meinem 11. Lebensjahr mit dem Amerikanischen fremdele. Deshalb habe auch meine Android-Programme immer nur DE und EN-UK oder nur EN-UK geschrieben. Vermutlich sind das die einzigen im PlayStore, die keine US-Lokalisierung haben, es sei denn, es gibt ein paar verrückte Schotten irgendwo, die das auch so machen.
PS: Ich habe erst beim Suchen von Atari-Programmen zum Testen gesehen, daß Du ein Programm namens ORCS geschrieben hast. Sah toll aus, auch wenn ich momentan keinen Resource Editor brauche. Ich habe eine vage Erinnerung, daß ich INTRFACE oder so früher verwendet habe, das ist aber alles sehr lange her, habe ich vergessen.
PS/2: Ich kann mich bei atari-forum.com nicht anmelden. Nach "Submit" erscheint oben immer "Spammers Domain - Stop Forum Spam!". Ob "web.de" in einer "blacklist" ist? Ich schau mal, ob es eine Email-Adresse gibt, an die man sich wenden kann. Sonst könnte ich es nochmal mit meiner gmail-Adresse probieren. Wäre aber blöd.
PS/3: Es gibt bei atari-forum.com ein Formular, um sich an den "Admin" zu wenden. Schaumermal...
-
Hmm... Ich muss wohl warten bis Debian (hab Debian 13) ein Update von Cmake raushaut
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.28 or higher is required. You are running version 3.25.1
-
Hmm... Ich muss wohl warten bis Debian (hab Debian 13) ein Update von Cmake raushaut
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.28 or higher is required. You are running version 3.25.1
Oh, das hatte ich vergessen. Ich habe ja auch Debian und hatte einfach die minimale Version im CMakeLists.txt auf einen niedrigeren Wert geändert. Keine Ahnung, warum dort überhaupt 3.28 steht. Lief ja auch mit einer älteren CMake-Version.
EDIT: Warten ist eher keine Option, es sei denn, Du möchtest auf Debian 14 (in 2027) warten. :)
-
Das ist seltsam. Ist das macOS?
Nein, linux. Passiert scheinbar hauptsächlich wenn ich über M: vom root-Verzeichnis aus starte, dort werden dann nicht alle Directories angezeigt. Sobald ich mein Home-Verzeichnis erreicht habe, scheint es aber zu gehen. Muss mal nachschauen, vlt. liegt das auch an MagiXDesk, evtl. überspringt es Ordner auf die man keinen Zugriff hat?
Nach "Submit" erscheint oben immer "Spammers Domain - Stop Forum Spam!". Ob "web.de" in einer "blacklist" ist?
Das kann gut sein. Die haben dort vor ein paar Monaten einiges getan, um bots in den Griff zu bekommen, die sonst die meiste Zeit das forum lahmlegen oder zumindest verlangsamen.
Sonst könnte ich es nochmal mit meiner gmail-Adresse probieren.
gmail steht mit einiger Sicherheit auch auf der Blacklist. Kontakt mit einem Admin sollte aber gehen.
-
Das kann gut sein. Die haben dort vor ein paar Monaten einiges getan, um bots in den Griff zu bekommen, die sonst die meiste Zeit das forum lahmlegen oder zumindest verlangsamen.
Web.de und GMX sind schon seit "Ewigkeiten" bei Atari-Forum.com auf der Blacklist. Ich habe versucht, den Admins zu erklären, dass United Internet einer der größten Anbieter von Mailadressen in Deutschland ist und es irgendwie ungeschickt ist, den komplett zu blockieren. Aber sie wollen ihre Blacklist nicht anpassen. GMail hingegen soll funktionieren. (Nicht selbst getestet.)
-
Hmm... Ich muss wohl warten bis Debian (hab Debian 13) ein Update von Cmake raushaut
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.28 or higher is required. You are running version 3.25.1
Oh, das hatte ich vergessen. Ich habe ja auch Debian und hatte einfach die minimale Version im CMakeLists.txt auf einen niedrigeren Wert geändert. Keine Ahnung, warum dort überhaupt 3.28 steht. Lief ja auch mit einer älteren CMake-Version.
EDIT: Warten ist eher keine Option, es sei denn, Du möchtest auf Debian 14 (in 2027) warten. :)
Ich hab jetzt die CMakeLists.txt so veränder dass die minimum required version 3.25 ist. Damit läuft es tatsächlich ganz gut. Was mir allerdings ein wenig sauer aufstösst, zum bearbeiten der config (magic-on-linux -e) ist der gnome-text-editor hardcoded in der main.cpp. ich denke hier sollte etwas anderes "eingebaut werden", z.b. als zweistufiger befehle ala:
touch ~/.config/magiclinux.conf
xdg-open ~/.config/magiclinux.conf
das würde den Texteditor öffnen der im System als Default eingestellt ist
-
Ich möchte noch hinzufügen, daß die Abstimmung bzw. API zwischen Emulator und Emulant noch nicht endgültig sein soll. Das ist ein Hack. Ich habe an den Funktionszeigern herumgebastelt, weil ich einen neuen Host-Callback für die disk images brauchte, und darauf geachtet, daß die Gesamtlänge der Übergabestruktur erhalten bleibt. Ich habe mich nämlich nicht getraut, das ganze System innerhalb des Emulators neu zu compilieren. Das Konzept mit den mehreren 32-Bit-Werten pro Methoden-Callback ist aus heutiger Sicht auch unsinnig und sollte raus. Und das Host-XFS sollte Zugriff auf die internen Objekte haben, statt nur mit inode/volume zu hantieren.. Da passiert zuviel noch auf Atari-Seite, weil die Schnittstelle fürs alte MacOS gedacht war. Ich wollte aber erstmal alles zum Laufen bringen. Und die erkalteten sfirst-Objekte müssen nach einiger Zeit automatisch freigegeben werden. Und die HostXFS-Klasse sollte statisch sein. Und das von ChatGPT gestrickte Logo gefällt mir auch noch nicht, weil der Pinguin einen seltsamen Schwanz hat. Muß mal die BUGS.TXT erweitern...
-
Schreib bitte ein "issue"! Du kannst übrigens mit der Kommandozeile einen Editor auswählen. Einfach Parameter "-h" oder "--help". Da gibt es umfangreiche Möglichkeiten.
-
Nein, linux. Passiert scheinbar hauptsächlich wenn ich über M: vom root-Verzeichnis aus starte, dort werden dann nicht alle Directories angezeigt. Sobald ich mein Home-Verzeichnis erreicht habe, scheint es aber zu gehen. Muss mal nachschauen, vlt. liegt das auch an MagiXDesk, evtl. überspringt es Ordner auf die man keinen Zugriff hat?
Das klingt plausibel. Da können auch noch Fehler im XFS sein. Für ein "issue" im Repository wäre ich dankbar, dann kann ich die alle abarbeiten, ohne daß etwas verlorengeht.
-
Die Warnungen wegen der überlangen Dateinamen sind auch unschön. Ich glaube, bei 64 Zeichen ist irgendwo die Grenze. Aber man soll ja auch nicht den Emulator mißbrauchen, um im gesamten Host-Dateisystem herumzupfuschen.
Im übrigen war ich etwas schockiert, wieviele alte Programme nicht nur selber abstürzen, sondern auch das gesamte System in den Abgrund reißen. Das wußte ich nicht mehr, wie verbreitet das ist. Wie so etwas wohl zustande kommt, und kann man das irgendwie verhindern? Ich habe dann längere Testreihen mit Hatari und Aranym/Afros gemacht und festgestellt, daß es dort ähnlich ist. Lustig ist, daß mein allererstes Atari-Programm MATRIX aus dem Jahre 1986 A.D. immer noch läuft. Wenn man damals also "ordentlich" programmiert hätte...
-
Das Konzept mit den mehreren 32-Bit-Werten pro Methoden-Callback ist aus heutiger Sicht auch unsinnig und sollte raus.
Das braucht man eigentlich auch nicht. Auch die this-Zeiger für Member-Funktionen-Aufrufe braucht man nicht: in allen Fällen existiert nur jeweils eine einzige Instanz der jeweiligen class. Das hatte ich in meinem clone schon vor langer Zeit geändert, siehe zB. https://github.com/th-otto/AtariX/blob/dac8e0cdb0de812362a0bc7ebdaad92cf6bd469f/src/AtariX-MT/AtariX/MagiC.cpp#L1298 und https://github.com/th-otto/AtariX/blob/dac8e0cdb0de812362a0bc7ebdaad92cf6bd469f/src/AtariX-MT/AtariX/MagiC.cpp#L1517. Und wenn man dann nur noch die Funktions-Nummer als index nimmt, brauch man auch keine Unterscheidung mehr zwischen 32-bit und 64-bit.
Abgesehen davon sind einige Interfaces sowieso hinfällig: von Atari aus kann man keine mac-68k Funktionen aufrufen, und auch PPC-Bibliotheken nachladen dürfte schwierig sein zu emulieren ;)
-
Das klingt ja prima. Aber ARM ist ja inzwischen auch little-endian, und wenn niemand Assembler verwendet, sollte das auch keine Probleme machen.
Naja, x86_64 hat ggü ARM64 mehr implizite Garantien für die Reihenfolge von Speicherzugriffen und verzeiht daher Programmierung, die auf ARM64 zu Race-Conditions führen kann. Insofern war es zwar erwartet, aber keineswegs 100% sicher, dass es auf ARM64 laufen würde.
-
Aus eher unangenehmem, gegegeben Anlaß (Bewegungseinschränkung, man wird alt, und manche werden halt ein paar Dekaden früher alt als andere, wenn sie überhaupt so alt werden) habe ich gerade viel Zeit, und was hilft gegen Depri? Alkohol oder Hacken.
Ich bzw. wir sind über die deine kluge Wahl erfreut. Danke für die Freigabe von der nächsten Iteration Atari! Gleich heute Abend auf meinem Fedora 43 testen :)
Älterwerden ist blöd, aber deutlichst besser als die Alternative ;)
Im Prinzip müßte sich das Programm mit vertretbarem Aufwand auf macOS portieren lassen, wobei man SDL wohl nachinstallieren kann. Windows hat eine ganz andere Dateisystem-API, soviel ich weiß. Ich habe aber nur einen alten Mac, und Windows tue ich mir nicht an.
Mit OpenCore Legacy Patcher (https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html) könnte man ein neueres macOS auf deinen Mac draufkriegen – falls du sowas willst. Andere Schmerzen mit dem Setup bleiben aber deswegen natürlich weiterhin gültig.
Und das von ChatGPT gestrickte Logo gefällt mir auch noch nicht, weil der Pinguin einen seltsamen Schwanz hat.
Naja, vor allem hat der Hintern des Pinguins drei Streifen, das Atari Logo an der Stelle aber nur einen, oder?
-
Lustig ist, daß mein allererstes Atari-Programm MATRIX aus dem Jahre 1986 A.D. immer noch läuft.
Was macht MATRIX denn? (und generell auch: was machst du sonst noch so mit dem erneuerten Atari?)
-
Lustig ist, daß mein allererstes Atari-Programm MATRIX aus dem Jahre 1986 A.D. immer noch läuft.
Was macht MATRIX denn? (und generell auch: was machst du sonst noch so mit dem erneuerten Atari?)
https://atariuptodate.de/de/4598/matrix
-
Oder vlt. eher das hier: https://github.com/th-otto/MagicMac/tree/master/apps/matrix
-
Mit OpenCore Legacy Patcher (https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html) könnte man ein neueres macOS auf deinen Mac draufkriegen – falls du sowas willst. Andere Schmerzen mit dem Setup bleiben aber deswegen natürlich weiterhin gültig.
(...)
Naja, vor allem hat der Hintern des Pinguins drei Streifen, das Atari Logo an der Stelle aber nur einen, oder?
Die Geschichte mit dem Legacy Patcher kenne ich. Tolle Sache, aber mein Standard-PC mit Ubuntu und Windows (dual-boot mit Umgehung aller Windows-Schikanen wie Echtzeituhr und Überwinterung) läuft schneller und stromsparender als der alte Mac, der auch schon drei teure Grafikkarten durchgebritzelt hat. Und demnächst ist eh Schluß mit macOS für x86.
Und ja, genau, die drei Streifen im Logo sind KI-halluziniert. Ich habe chatGPT zwar noch ein paar Verbesserungswünsche unterbreitet, und dann war auch schon mein Tageskontingent erschöpft. Oder man sagt ja "erschopfen", analog zu "ausgeschalten" und "aufgehangen".
-
https://atariuptodate.de/de/4598/matrix
Richtig. Das ist seit anno tobak unverändert. Seit 2018 sind die Quellen offengelegt in meinem Atari-Magic-Blabla-Sources-Repository. Ich habe das damals im Zuge des Studiums für die Vorlesung "Lineare Algebra" geschrieben, aber auch später nochmal verwendet.
-
Ich bekomme den Emulator zwar kompiliert (nach runtersetzen der cmake version im Fall von Linux Mint), aber nicht so recht ans laufen. Auf openSUSE Tumbleweed gibt es kein gxmessage. Auf Linux Mint kommt eine Fehlermeldung von wegen fehlendem MAGICLIN.OS und der Aufforderung, die Konfigurationsdatei zu reparieren. Der Fehler sollte ja eigentlich bei Tumbleweed dann in der Konsole kommen, tut er aber nicht. Auf beiden Systemen scheitert der Aufruf mit -e mit sh: Zeile 1: gnome-text-editor: Kommando nicht gefunden
Meine Desktopumgebung ist auf beiden Rechnern lxde4.
Mit --editor=geany -e bekam ich die Konfigurationsdatei dann doch bearbeitet.
Die default-Konfiguration schreibt Pfade "~/Documents/Atari-rootfs", was hier doppelt schief geht, weil der Ordner bei mir "Dokumente" heißt und ich beim Tumbleweed-Rechner dort noch einen Unterordner "Atari" angelegt habe und dort erst den Emulator.
Auf dem Linux Mint Rechner habe ich den Emulator jetzt sogar laufen, aber Zugriff auf Laufwerk M: gibt nur "mehr als 0 Objekte".
Auf dem Tumbleweed System kommt nach Reparatur der Konfigurationsdatei ein großes weißes Fenster mit quadratischem grauem Feld in der linken oberen Ecke, so wie in https://forum.atari-home.de/index.php/topic,18379.msg274321.html#msg274321. Die Fehlermeldung dazu bekomme ich mangels gxmessage nicht zu Gesicht. Das wird dann wohl der fehlende Video Driver sein.
Nachtrag: Angeblich soll ja mit guix auch ein gxmessage kommen und in der Dateiliste ist /usr/lib64/guile/3.0/site-ccache/gnu/packages/gxmessage.go aufgeführt, aber das wird nicht aufgerufen (wenn es überhaupt das richtige ist).
Weder dialog noch zenity noch xmessage sind aufrufkompatibel mit gxmessage. Einmal fehlt -wrap, ein andermal -nearmouse.
sudo zypper install SDL2-devel ist für Tumbleweed (hoffentlich) der richtige Befehl zur Installation der sdl2 Entwicklungspakete.
-
Die default-Konfiguration schreibt Pfade "~/Documents/Atari-rootfs", was hier doppelt schief geht,
War bei mir auch so (ebenfalls auf Tumbleweed). Nach dem ersten Start existiert aber eine Datei ~/.config/magiclinux.conf, dort kann man die Pfade einfach ändern.
Auf dem Tumbleweed System kommt nach Reparatur der Konfigurationsdatei ein großes weißes Fenster mit quadratischem grauem Feld in der linken oberen Ecke,
Dann fehlt vermutlich noch was im Atari-rootfs Verzeichnis.
sudo zypper install SDL2-devel ist für Tumbleweed (hoffentlich) der richtige Befehl zur Installation der sdl2 Entwicklungspakete.
Ja, ist es. Ansonsten würde cmake auch die SDL2 Libraries nicht finden.
Zugriff auf Laufwerk M: gibt nur "mehr als 0 Objekte".
WIrd auch das /home Verzeichnis nicht angezeigt?
-
Auf dem Tumbleweed System kommt nach Reparatur der Konfigurationsdatei ein großes weißes Fenster mit quadratischem grauem Feld in der linken oberen Ecke,
Dann fehlt vermutlich noch was im Atari-rootfs Verzeichnis.
Nur was?
Zugriff auf Laufwerk M: gibt nur "mehr als 0 Objekte".
WIrd auch das /home Verzeichnis nicht angezeigt?
Da kommt ein komplett leeres Fenster. Laufwerk C: geht, Laufwerk A: gibt Fehlermeldung.
-
Scheint ein Fehler in MagxDesk zu sein. Ich denke ich habe ihn auch gefunden, muss aber noch ein wenig testen. Hintergrund ist der, das wohl Dxreaddir() einen Fehler liefert wenn die Dateiattribute ermittelt werden sollen (z.B. wegen fehlender Rechte). Auf einem FAT-Filesystem kann sowas eigentlich nicht passieren, weil es dort sowas nicht gibt.
-
Das Dateisystem ist case-sensitive, der Dateiname von magiclin.os muß in Großbuchstaben stehen, wenn er so in der config aufgeführt ist. Oder eben in der config klein schreiben.
-
Ich bekomme den Emulator zwar kompiliert (nach runtersetzen der cmake version im Fall von Linux Mint),
Die Unannehmlichkeiten für andere Linuxe tun mir leid, aber ich mußte mich erstmal vollständig auf das konzentrieren, was ich gewöhnt bin, und ich habe nie ein anderes als Ubuntu verwendet. Deshalb auch "~/Documents" als schnelle, funktionierende und vorläufige Lösung.
Bei Ubuntu wird xmessage mitgeliefert, ohne Nachinstallieren, aber das war so winzig, daß ich eine Lupe brauchte oder gleich ein Elektronenmikroskop. Da ist gxmessage doch wesentlich besser. Daß der Name des Editors fest eingebrannt ist, war auch erstmal eine Notlösung, aber mit der Kommandozeile kann man das ja ändern. Vielleicht könnte man das auch als "cmake"-Parameter einbauen, ich bin aber kein cmake-Profi. Ich hatte auch keine Lust, mit qt oder so eine GUI zu basteln, da habe ich Null Erfahrung. Dafür habe ich viel Ahnung von Android, das nutzt hier aber leider genau gar nichts.
Das graue Quadrat malt der Emulator rein; damit habe ich die SDL-Ausgabe getestet. Normalerweise sieht man das nicht, weil der Emulant ganz schnell drübermalt. Eine Boot-Animation fand ich überflüssig, weil alles eh zu schnell geht. Wenn er seine Kernel-Datei nicht findet, sollte eigentlich eine gxmessage kommen, aber wenn man kein gxmessage hat, klappt das natürlich nicht. Man könnte dann vielleicht eine altherthümliche Tastaturabfrage machen.
Es ist jedenfalls noch viel Raum für Verbesserungen. Wichtiger wäre mir aber, wenn amoklaufende Atari-Programme weniger Schaden anrichten könnten. Vielleicht kann man die Speicherzugriffe besser überwachen, zumindest im "debug mode". Zum Beispiel läuft Gembench nicht, und erinnnere mich dunkel, daß das mal ging. Es gibt auch leider keinen Quelltext dafür.
Ich werde bei Gelegenheit mal über diesen Fred gehen und alle VVs sammeln und in meine Merkliste BUGS.TXT eintragen.
-
So, erstmal ein neues Logo. Ich habe chatGPT diesmal sicherheitshalber ganz genaue Anweisungen gegeben. 8)
-
Ich hatte auch keine Lust, mit qt oder so eine GUI zu basteln, da habe ich Null Erfahrung.
Ich kenne mich ein bisschen mit Qt (und auch Gtk) aus. Die Frage ist nur: braucht man so eine GUI momentan überhaupt? Noch zumindest gibt es noch nicht allzu viele Parameter die man ändern könnte. Reicht es da den meisten, die config-Datei mit einem Text-Editor zu bearbeiten?
-
Ich habe mir das gestern unter Arch Linux gebaut, soweit alles kein Problem. Beim Start jedoch bekomme ich die Meldung
The emulated system could not find a suitable video driver
Review configuration file!
angezeigt und stehe hier auf dem Schlauch.
In der magiclinux.conf habe ich nur atari_kernel_path und atari_rootfs_path an meine Gegebenheit angepasst und etwas mit atari_screen_* rumgespielt, ändert aber nix. Wo sehe ich den Wald nicht?
Bei 1024x728x24b (default) bekomme ich ein Fenster mit grauem Bereich links oben, bei anderen Werten bleibt das ganze Fenster schwarz.
-
Ich habe mir das gestern unter Arch Linux gebaut, soweit alles kein Problem. Beim Start jedoch bekomme ich die Meldung
The emulated system could not find a suitable video driver
Review configuration file!
angezeigt und stehe hier auf dem Schlauch.
In der magiclinux.conf habe ich nur atari_kernel_path und atari_rootfs_path an meine Gegebenheit angepasst und etwas mit atari_screen_* rumgespielt, ändert aber nix. Wo sehe ich den Wald nicht?
Bei 1024x728x24b (default) bekomme ich ein Fenster mit grauem Bereich links oben, bei anderen Werten bleibt das ganze Fenster schwarz.
Nur um sicher zu gehen. Du hast nicht nur die dev Pakete von sdl2 installiert?
-
Ich habe mir das gestern unter Arch Linux gebaut, soweit alles kein Problem. Beim Start jedoch bekomme ich die Meldung
The emulated system could not find a suitable video driver
Review configuration file!
angezeigt und stehe hier auf dem Schlauch.
In der magiclinux.conf habe ich nur atari_kernel_path und atari_rootfs_path an meine Gegebenheit angepasst und etwas mit atari_screen_* rumgespielt, ändert aber nix. Wo sehe ich den Wald nicht?
Bei 1024x728x24b (default) bekomme ich ein Fenster mit grauem Bereich links oben, bei anderen Werten bleibt das ganze Fenster schwarz.
Nur um sicher zu gehen. Du hast nicht nur die dev Pakete von sdl2 installiert?
Nein, bei Arch Linux bekommt man üblicherweise die Binaries und Devs zusammen installiert, also eigentlich alles da, samt SDL1-compat, SDL2 und SDL3.
Das eigentliche MagicOnLinux-Fenster erscheint ja auch, also gehe ich davon aus, dass SDL "funktioniert". Ich baue das aber nochmal neu, um zu sehen, ob ich etwas übersehen habe.
EDIT: Neu bauen geht ja fix :) Aber keine Veränderung und der Build-Output sieht unspektakulär aus.
EDIT2: Mal die Debug-Variante gebaut. Sieht im großen und ganzen gut aus, bis auf drei Zeilen:
(10:04:23) DBG-WRN EventLoop() - unhandled SDL event 772
(10:04:23) DBG-WRN EventLoop() - SDL_CLIPBOARDUPDATE currently unhandled
(10:04:23) DBG-WRN EventLoop() - unhandled SDL event 518
-
Die oben aufgeführten Warnungen sind harmlos, es ist halt noch nicht alles implementiert was geht.
Interessanter wären die restlichen Ausgaben, auch wenn da nichts von Warnung oder Fehler steht. Da müssten auch Meldungen vom Ausführen des Kernels sein (sofern der überhaupt gefunden wurde).
-
[ aber wenn man kein gxmessage hat, klappt das natürlich nicht. Man könnte dann vielleicht eine altherthümliche Tastaturabfrage machen.
Das würde nicht besonders gut funktionieren. Das SDL-Fenster ist dann schon offen, und hat auch den Keyboard-Fokus. Für Eingaben von der Console müsste man erstmal dorthin zurück switchen (ganz abgesehen davon daß man die Meldung wahrscheinlich gar nicht sieht, weil sie vom Fenster überdeckt wird). Schwierig wirds auch, wenn man es später mal nicht aus der console, sondern direkt vom Desktop startet. Dann gibt es nichts von wo man Eingaben machen könnte.
Da sowieso mindestens SDL2 vorausgesetzt wird, wäre es vermutlich am einfachsten, einfach ein neues, simples SDL Fenster mit der Message zu erzeugen.
-
Die Warnungen wegen der überlangen Dateinamen sind auch unschön.
Betrifft u.a. auch C:\AUTO\GEMSYS. Die dort vorhandene Datei MFM16M-1fff.SYS passt nicht ins 8.3 Schema. kA wozu die überhaupt gut ist, ist bis auf ein Byte identisch zu MFM16M.SYS.
-
Scheint ein Fehler in MagxDesk zu sein. Ich denke ich habe ihn auch gefunden,
Genauer gesagt war es eine Kombination von zwei Fehlern: einer in MagxDesk, und ein weiterer in MagicOnLinux. Der in MagxDesk ist jetzt behoben, man sollte also Atari-rootfs/GEMSYS/GEMDESK/MAGXDESK.APP (inklusive Resource-Datei) ersetzen durch die neueste Version. Momentan ist das Archiv https://tho-otto.de/snapshots/magicmac/magicmac-20251125-141201-bin.zip Beim kopieren auf Gross-/Kleinschreibung achten: in meinem ZIP-Archiv ist der Datei-Name klein geschrieben, im vorhanden Atari-rootfs Verzeichnis aber gross.
Einen patch für MagicOnLinux hab ich auch schon gepostet in https://gitlab.com/AndreasK/magiclinux/-/issues/4
-
Die oben aufgeführten Warnungen sind harmlos, es ist halt noch nicht alles implementiert was geht.
Interessanter wären die restlichen Ausgaben, auch wenn da nichts von Warnung oder Fehler steht. Da müssten auch Meldungen vom Ausführen des Kernels sein (sofern der überhaupt gefunden wurde).
Kütt!
(10:04:23) DBG-INF Init() - MultiThread version for Linux
(10:04:23) DBG-INF Init() - 68k trace is emulated (slows down the emulator a bit)
(10:04:23) DBG-WRN EventLoop() - unhandled SDL event 518
(10:04:23) DBG-INF Init() - 68k ROM is write-protected (slows down the emulator a bit)
(10:04:23) DBG-INF Init() - 68k PC is checked for validity (slows down the emulator a bit)
(10:04:23) DBG-INF Init() - Autostart ON
(10:04:23) DBG-INF LoadReloc("/home/larry/Atari-ST/magiclinux/Atari-rootfs/MAGICLIN.OS")
(10:04:23) DBG-INF LoadReloc() - kernel file size = 225447
(10:04:23) DBG-INF LoadReloc() - Size TEXT = 211520
(10:04:23) DBG-INF LoadReloc() - Size DATA = 10648
(10:04:23) DBG-INF LoadReloc() - Size BSS = 21
(10:04:23) DBG-INF LoadReloc() - Size overall, including basepage and stack = 0x000364ee (222446)
(10:04:23) DBG-INF LoadReloc() - Start address Atari = 0x7fe4699f4010 (host)
(10:04:23) DBG-INF LoadReloc() - Memory size Atari = 0x00800000 (= 8192 kBytes)
(10:04:23) DBG-INF LoadReloc() - Load address of system (TEXT) = 0x007c9c10 (68k)
(10:04:23) DBG-INF LoadReloc() - seek to relocation table, file offset 222196
(10:04:23) DBG-INF Init() - MagiC kernel loaded and relocated successfully
(10:04:23) DBG-INF Init() - Atari video mode is 24-bit true colour
(10:04:23) DBG-INF Init() - 68k video memory starts at 68k address 0x00800000 and uses 3145728 (0x00300000) bytes.
(10:04:23) DBG-INF Init() - 68k video memory and general memory end is 0x00b00000
(10:04:23) DBG-INF PixmapToBigEndian() -- Convert Pixmap to big-endian
(10:04:23) DBG-INF Init() - basepage address of system = 0x007c9b10 (68k)
(10:04:23) DBG-INF Init() - address of Atari68kData = 0x007c9ac2 (68k)
(10:04:23) DBG-INF Init() - sizeof(CMagiC_CPPCCallback) = 16
(10:04:23) DBG-INF Init() - sizeof(CMagiC_PPCCallback) = 16
(10:04:23) DBG-INF Init() - OS ROM range from 0x007c9c10..0x007fffe8 (68k)
(10:04:23) DBG-INF init() -- Atari drive C: is not a regular file: "/home/larry/Atari-ST/magiclinux/Atari-rootfs"
(10:04:23) DBG-INF init() -- Atari drive H: is not a regular file: "/home/larry"
(10:04:23) DBG-INF init() -- Atari drive M: is not a regular file: "/"
(10:04:23) DBG-INF CMagiC::CreateThread() - erfolgreich
(10:04:23) DBG-INF AtariInit() - ATARI: First initialisation phase done.
(10:04:23) DBG-INF AtariDebugOut(Grafikausgabe initialisieren)
(10:04:23) DBG-INF AtariDebugOut(VT52 initialisieren)
(10:04:23) DBG-INF AtariDebugOut(BIOS-Initialisierung abgeschlossen)
(10:04:23) DBG-INF AtariBIOSInit() - ATARI: BIOS initialisation done.
(10:04:23) DBG-INF AtariDebugOut(MagiC-VDI initialisieren)
(10:04:23) DBG-ERR hostpath2HostFD() -- host path is located outside Atari drive C: "/usr/share/games/hatari/magiclinux/Atari-rootfs"
(10:04:23) DBG-INF AtariBlockDevice(drv = C:) - hdv_getbpb()
(10:04:23) DBG-INF AtariRwabs() - hdv_rawbs(flags = 0x0000, buf = 0x699f8c8a, count = 1, dev = 2, lrecno = 0)
(10:04:23) DBG-INF AtariBlockDevice(drv = C:) - hdv_rwabs(flags = 0x0000, buf = 0x0000def2, count = 1, recno = 65535, lrecno = 2)
(10:04:23) DBG-INF AtariRwabs() - hdv_rawbs(flags = 0x0000, buf = 0x69a01f02, count = 1, dev = 2, lrecno = 0)
(10:04:23) DBG-ERR hostpath2HostFD() -- host path is located outside Atari drive C: "/usr/share/games/hatari/magiclinux/Atari-rootfs"
(10:04:23) DBG-INF AtariBlockDevice(drv = C:) - hdv_getbpb()
(10:04:23) DBG-INF AtariRwabs() - hdv_rawbs(flags = 0x0000, buf = 0x699f8c8a, count = 1, dev = 2, lrecno = 0)
(10:04:23) DBG-INF AtariBlockDevice(drv = C:) - hdv_rwabs(flags = 0x0000, buf = 0x0000def2, count = 1, recno = 65535, lrecno = 2)
(10:04:23) DBG-INF AtariRwabs() - hdv_rawbs(flags = 0x0000, buf = 0x69a01f02, count = 1, dev = 2, lrecno = 0)
(10:04:23) DBG-INF AtariError(-1)
(10:04:23) DBG-WRN EventLoop() - unhandled SDL event 772
(10:04:23) DBG-WRN EventLoop() - SDL_CLIPBOARDUPDATE currently unhandled
(10:04:23) DBG-WRN EventLoop() - unhandled SDL event 518
------ hier kam das Sub-Fenster wegen "video driver" und habe dann beide geschlossen
(10:04:36) DBG-INF CMagiC::EmuThread() -- MPWaitForEvent
(10:04:36) DBG-INF CMagiC::EmuThread() -- MPWaitForEvent beendet
(10:04:36) DBG-INF CMagiC::EmuThread() -- MPWaitForEvent
(10:04:37) DBG-INF CMagiC::TerminateThread()
(10:04:37) DBG-INF CMagiC::EmuThread() -- MPWaitForEvent beendet
(10:04:37) DBG-INF CMagiC::EmuThread() -- normaler Abbruch
-
(10:04:23) DBG-INF LoadReloc("/home/larry/Atari-ST/magiclinux/Atari-rootfs/MAGICLIN.OS")
(10:04:23) DBG-ERR hostpath2HostFD() -- host path is located outside Atari drive C: "/usr/share/games/hatari/magiclinux/Atari-rootfs"
Sieht so aus als wenn dein Kernel in einem anderen Verzeichnis steht als dein rootfs. Kopiere den doch mal dorthin, und pass den Pfad entsprechend an.
Edit: gerade mal getestet, und mit
[HOST PATHS]
atari_kernel_path = "/usr/share/games/magiclinux/Atari-rootfs/MAGICLIN.OS"
atari_rootfs_path = "/usr/share/games/magiclinux/Atari-rootfs"
funktioniert es (vorrausgesetzt, in dem Verzeichnis sind dann auch tatächlich die benötigten Dateien)
-
Zum Beispiel läuft Gembench nicht, und erinnnere mich dunkel, daß das mal ging. Es gibt auch leider keinen Quelltext dafür.
Dafür rennt aber Kronos, und wie. Das rennt nicht, das fliegt mit Lichtgeschwindigkeit ;) Damit es aber dazu kommt muss man magiconlinux mit "--memsize=WERT" starten (ich hab z.B. 512MB genommen) starten denn ich hab noch nicht kapiert wie der eintrag in der config Datei funktioniert.
-
Huch. 512MB ST-RAM? Witzig.
-
Ich glaube an MagXDesk muss ich nochmal ran. Wegen der Geschwindigkeit, "prellt" die Maustaste, und nach einem Doppelklick krieg ich immer noch weitere Klicks, das macht mich wahnsinnig wenn sich immer gleich zehn Fenster öffnen. Teradesk und Jinnee haben das Problem nicht, auch nicht unter Aranym.
-
Die Warnungen wegen der überlangen Dateinamen sind auch unschön.
Betrifft u.a. auch C:\AUTO\GEMSYS. Die dort vorhandene Datei MFM16M-1fff.SYS passt nicht ins 8.3 Schema. kA wozu die überhaupt gut ist, ist bis auf ein Byte identisch zu MFM16M.SYS.
Die muß weg. Die Originaldatei der Behnes hatte einen üblen Fehler, und ich habe den Treiber für MagicMacX binär gepatcht. Eine Sch..arbeit, den Fehler zu finden.
-
.. Wie wäre es mit "/opt/magiconlinux" als Standard-Pfad statt "~/Documents"? Ändern kann man das ja eh noch in der Konfigurationsdatei. Und da drin dann z.B. "rootfs" oder vielleicht besser "magic_c".
-
Ich hatte auch keine Lust, mit qt oder so eine GUI zu basteln, da habe ich Null Erfahrung.
Ich kenne mich ein bisschen mit Qt (und auch Gtk) aus. Die Frage ist nur: braucht man so eine GUI momentan überhaupt? Noch zumindest gibt es noch nicht allzu viele Parameter die man ändern könnte. Reicht es da den meisten, die config-Datei mit einem Text-Editor zu bearbeiten?
Dazu kommt, daß man für jede neue Option die GUI erweitern müßte. Bei Android ginge das ganz gut, mit dem xml-Zeugs, aber bei Qt? Der Nutzen wäre vermutlich geringer als der Aufwand.
-
.. Wie wäre es mit "/opt/magiconlinux" als Standard-Pfad statt "~/Documents"? Ändern kann man das ja eh noch in der Konfigurationsdatei. Und da drin dann z.B. "rootfs" oder vielleicht besser "magic_c".
Dann fängt man aber wieder mit chown/chgrp an um Schreibrechte zu bekommen. Da fände ich den Ansatz von Aranym oder Hatari besser (~/.aranym bzw. ~/.hatari).
-
Huch. 512MB ST-RAM? Witzig.
Das ging, glaube ich, schon mit dem alt ehrwürdigen STonX. Bin mir aber nicht mehr 1000%tig sicher, musste ich nochmal probieren
-
Irgendein Ordner im $HOME Verzeichnis wäre schon besser denke ich, sonst braucht man root -Privilegien zur Installation. Für tests sicher nicht ideal.
Oder den pfad mit `xdg-user-dir DOCUMENTS`, oder besser noch `xdg-user-dir PUBLICSHARE` erfragen.
-
Das ging, glaube ich, schon mit dem alt ehrwürdigen STonX. Bin mir aber nicht mehr 1000%tig sicher, musste ich nochmal probieren
Geht mit einiger Sicherheit nicht. Ab $E00000 (14MB), oder spätestens ab $FC0000 steht das ROM. Und STonX emuliert komplett die Hardware-Addressen ab $FF0000. Bei MagicOnLinux geht das nur, weil so gut wie keine Hardware-Zugriffe emuliert werden, stattdessen wird alles an den Emulator weitergereicht.
Was mich daran erinnert, mal die ganzen APPS aus MagicMac mit einem geänderten Startup-Code zu linken, der nicht versucht eine SFP004 FPU an $FFFA42 zu finden.
PS:
[ATARI EMULATION]
atari_memory_size = 536870912
funktioniert bei mir problemlos.
-
Und auf dem Apple Silicon Mac ein Schrittchen weiter voran. Die Abfrage der offenen Dateien nach POSIX über /proc/fs muss BSD kompatibel angepasst werden, sind gerade mal drei anzupassende Zeilen. Es hakt aber noch beim Anzeigen der Laufwerksinhalte.
Unter Latest&Greatest Ubuntu für ARM64 konnte ich die Sourcen problemlos kompilieren, aber in QEMU wird der Mauszeiger nicht eingefangen. D.h. Klicks werden ignoriert.
-
Und auf dem Apple Silicon Mac ein Schrittchen weiter voran. Die Abfrage der offenen Dateien nach POSIX über /proc/fs muss BSD kompatibel angepasst werden, sind gerade mal drei anzupassende Zeilen. Es hakt aber noch beim Anzeigen der Laufwerksinhalte.
(..)
Sieht ja schon sehr schön grüüüün aus. Beim Mac müßte man noch beachten, daß das Dateisystem "case insensitive" ist, wenn ich mich recht erinnere. Das kann man theoretisch auch in die config-Datei eintragen für die virtuellen Laufwerke, konnte ich aber nicht testen, und ich weiß auch spontan nicht mehr, was das für einen Unterschied macht.
Die ersten kleinen Korrekturen habe ich übrigens gerade einfließen lassen. Ich empfehle ein "git pull".
-
(10:04:23) DBG-INF LoadReloc("/home/larry/Atari-ST/magiclinux/Atari-rootfs/MAGICLIN.OS")
(10:04:23) DBG-ERR hostpath2HostFD() -- host path is located outside Atari drive C: "/usr/share/games/hatari/magiclinux/Atari-rootfs"
Sieht so aus als wenn dein Kernel in einem anderen Verzeichnis steht als dein rootfs. Kopiere den doch mal dorthin, und pass den Pfad entsprechend an.
Edit: gerade mal getestet, und mit
[HOST PATHS]
atari_kernel_path = "/usr/share/games/magiclinux/Atari-rootfs/MAGICLIN.OS"
atari_rootfs_path = "/usr/share/games/magiclinux/Atari-rootfs"
funktioniert es (vorrausgesetzt, in dem Verzeichnis sind dann auch tatächlich die benötigten Dateien)
Danke, den Hinweis "host path is located outside" hatte ich gar nicht wahrgenommen...
Mein /home/larry/Atari-ST/ ist ein Symlink, damit scheint magiclinux (noch) nicht mitspielen zu wollen. Okay, den ganzen Bums nach /usr/share/games/magiclinux/Atari-rootfs umgezogen, dann verlangt es beim Start aber /home/larry/Documents/Atari-rootfs/MAGICLIN.OS. Wohlan, auch das angelegt und mit MAGICLIN.OS und GEMSYS/ bestückt. So weit so gut, dann meckert magiclinux aber über Drive C:, H: und M: - und endet wieder mit "could not find a suitable video driver"
In magiclinux.conf unter [ADDITIONAL ATARI DRIVES] habe ich noch nichts weiter angelegt.
(07:09:26) DBG-INF Init() - MultiThread version for Linux
(07:09:26) DBG-INF Init() - 68k trace is emulated (slows down the emulator a bit)
(07:09:26) DBG-INF () - 68k ROM is not write-protected (makes the emulator a bit faster)
(07:09:26) DBG-INF Init() - 68k PC is checked for validity (slows down the emulator a bit)
(07:09:26) DBG-INF Init() - Autostart ON
(07:09:26) DBG-WRN EventLoop() - unhandled SDL event 518
(07:09:26) DBG-INF LoadReloc("/home/larry/Documents/Atari-rootfs/MAGICLIN.OS")
(07:09:26) DBG-INF LoadReloc() - kernel file size = 225447
(07:09:26) DBG-INF LoadReloc() - Size TEXT = 211520
(07:09:26) DBG-INF LoadReloc() - Size DATA = 10648
(07:09:26) DBG-INF LoadReloc() - Size BSS = 21
(07:09:26) DBG-INF LoadReloc() - Size overall, including basepage and stack = 0x000364ee (222446)
(07:09:26) DBG-INF LoadReloc() - Start address Atari = 0x7f3d749f3010 (host)
(07:09:26) DBG-INF LoadReloc() - Memory size Atari = 0x00800000 (= 8192 kBytes)
(07:09:26) DBG-INF LoadReloc() - Load address of system (TEXT) = 0x007c9c10 (68k)
(07:09:26) DBG-INF LoadReloc() - seek to relocation table, file offset 222196
(07:09:26) DBG-INF Init() - MagiC kernel loaded and relocated successfully
(07:09:26) DBG-INF Init() - Atari video mode is 24-bit true colour
(07:09:26) DBG-INF Init() - 68k video memory starts at 68k address 0x00800000 and uses 3145728 (0x00300000) bytes.
(07:09:26) DBG-INF Init() - 68k video memory and general memory end is 0x00b00000
(07:09:26) DBG-INF PixmapToBigEndian() -- Convert Pixmap to big-endian
(07:09:26) DBG-INF Init() - basepage address of system = 0x007c9b10 (68k)
(07:09:26) DBG-INF Init() - address of Atari68kData = 0x007c9ac2 (68k)
(07:09:26) DBG-INF Init() - sizeof(CMagiC_CPPCCallback) = 16
(07:09:26) DBG-INF Init() - sizeof(CMagiC_PPCCallback) = 16
(07:09:26) DBG-INF Init() - OS ROM range from 0x007c9c10..0x007fffe8 (68k)
(07:09:26) DBG-INF init() -- Atari drive C: is not a regular file: "/home/larry/Documents/Atari-rootfs"
(07:09:26) DBG-INF init() -- Atari drive H: is not a regular file: "/home/larry"
(07:09:26) DBG-INF init() -- Atari drive M: is not a regular file: "/"
(07:09:26) DBG-INF CMagiC::CreateThread() - erfolgreich
(07:09:26) DBG-INF AtariInit() - ATARI: First initialisation phase done.
(07:09:26) DBG-INF AtariDebugOut(Grafikausgabe initialisieren)
(07:09:26) DBG-INF AtariDebugOut(VT52 initialisieren)
(07:09:26) DBG-INF AtariDebugOut(BIOS-Initialisierung abgeschlossen)
(07:09:26) DBG-INF AtariBIOSInit() - ATARI: BIOS initialisation done.
(07:09:26) DBG-INF AtariDebugOut(MagiC-VDI initialisieren)
(07:09:26) DBG-INF Drv2DevCode(drv = 2) => 0x00010003
(07:09:26) DBG-INF AtariError(-1)
(07:09:26) DBG-WRN EventLoop() - unhandled SDL event 772
(07:09:26) DBG-WRN EventLoop() - SDL_CLIPBOARDUPDATE currently unhandled
(07:09:26) DBG-WRN EventLoop() - unhandled SDL event 518
(07:09:28) DBG-INF CMagiC::TerminateThread()
[HOST PATHS]
atari_kernel_path = "/usr/share/games/magiclinux/Atari-rootfs/MAGICLIN.OS"
atari_rootfs_path = "/usr/share/games/magiclinux/Atari-rootfs"
atari_h_home = YES
atari_h_rdonly = YES
atari_m_host_root = YES
atari_m_host_root_rdonly = YES
atari_temp_path = "/tmp"
[HOST DEVICES]
atari_print_cmd = "echo printing not yet implemented"
atari_serial_dev_path = ""
[ATARI SCREEN]
atari_screen_width = 1024
atari_screen_height = 768
atari_screen_stretch_x = 2
atari_screen_stretch_y = 2
atari_screen_rate_hz = 60
atari_screen_colour_mode = 0
# 0:24b 1:16b 2:256 3:16 4:16ip 5:4ip 6:mono
hide_host_mouse = NO
[SCREEN PLACEMENT]
app_display_number = 0
app_window_x = 4294967295
app_window_y = 4294967295
[ATARI EMULATION]
atari_memory_size = 8388608
atari_language = 0
show_host_menu = YES
atari_autostart = YES
[ADDITIONAL ATARI DRIVES]
# atari_drv_<A..T,V..Z> = flags [1:read-only, 2:8+3, 4:case-insensitive] path or image
-
Die Abfrage der offenen Dateien nach POSIX über /proc/fs muss BSD kompatibel angepasst werden
Was genau meinst du damit? Ich sehe da nirgendwo einen Zugriff auf /proc/fs
-
Die Abfrage der offenen Dateien nach POSIX über /proc/fs muss BSD kompatibel angepasst werden
Was genau meinst du damit? Ich sehe da nirgendwo einen Zugriff auf /proc/fs
Im Zuge geistiger Umnachtung aus der Erinnerung falsch genannt, richtig wäre "/proc/self/fd/" in CHostXFS::hostFd2Path
-
(...)
Sieht so aus als wenn dein Kernel in einem anderen Verzeichnis steht als dein rootfs. Kopiere den doch mal dorthin, und pass den Pfad entsprechend an.
(...)
Eigentlich sollte es derzeit völlig egal sein, von wo der Kernel geladen wird. Bei MagicMacX/AtariX war er noch im rootfs, weil das am einfachsten war und er zusammen mit dem rootfs automatisch lokalisiert wurde. Vielleicht sollte ich das übernehmen. Die Lokalisierung könnte in C:\LANG\FRA und C:\LANG\DE etc., liegen, und der Emulator könnte beim Wechsel der Sprache die Dateien umkopieren, einfach per rsync.
Du brauchst auch erst keine weiteren Laufwerke hinzuzufügen. Standardmäßig solltest Du noch H: haben, mit langen Dateinamen, das ist dein "unix home". Dann gibt es noch M:, das ist das "wurcle directory". Standardmäßig sind die aus Sicherheitsgründen schreibgeschützt, das kannst du in der Konf.datei ändern. Du mußt in Magxdesk erstmal "Laufwerke finden". Das sind noch Altlasten, etwas umständlich.
-
Du brauchst auch erst keine weiteren Laufwerke hinzuzufügen. Standardmäßig solltest Du noch H: haben, mit langen Dateinamen, das ist dein "unix home". Dann gibt es noch M:, das ist das "wurcle directory". Standardmäßig sind die aus Sicherheitsgründen schreibgeschützt, das kannst du in der Konf.datei ändern.
So dachte ich es mir auch, sonst hättest Du wohl explizit darauf hingewiesen oder prominente Beispiele in die .conf eingefügt...
Du mußt in Magxdesk erstmal "Laufwerke finden". Das sind noch Altlasten, etwas umständlich.
Würde ich ja gerne, aber komme nicht über die Fehlemeldung
The emulated system could not find a suitable video driver
Review configuration file!
hinweg.
https://forum.atari-home.de/index.php/topic,18379.msg274359.html#msg274359
-
Eigentlich sollte es derzeit völlig egal sein, von wo der Kernel geladen wird.
Ja, stimmt. Funktioniert auch:
[HOST PATHS]
atari_kernel_path = "/home/sebilla/atari/magicmac/kernel/build/magiclin.os"
atari_rootfs_path = "/usr/share/games/magiclinux/Atari-rootfs"
Auch wenn man MAGICLIN.OS in /usr/share/games/magiclinux/Atari-rootfs entfernt, funktioniert es.
Da muss noch was anderes nicht stimmen bei RealLarry.
Daß er nach /home/larry/Documents/Atari-rootfs/MAGICLIN.OS sucht obwohl in der config angeblich was anders steht, kommt mir ziemlich suspekt vor.
-
Daß er nach /home/larry/Documents/Atari-rootfs/MAGICLIN.OS sucht obwohl in der config angeblich was anders steht, kommt mir ziemlich suspekt vor.
...frag mich mal :D
Aber sei's drum, alles gut und alles wächst und gedeiht noch.
-
The emulated system could not find a suitable video driver
Review configuration file!
Das funktioniert im Prinzip so:
Der Emulator liest die Konfigurationsdatei und die Kommandozeilenschalter. Daraus berechnet er eine Farbdarstellung, z.B. Schwarzweiß, und konfiguriert eine Struktur entsprechend, die er dem MVDI (also dem Emulanten) weiterreicht. Da stehen im wesentlichen Farbformat und Bildgröße drin.
Der Emulant liest dann die Treiber von C:\GEMSYS. Näheres steht in "manual.txt". Standardmäßig braucht er MFM16M.SYS, für 16 Mio Farben. Du müßtest ein Fopen("MFM16M.SYS") sehen. Am besten in config.h alle XFS-Debug-Ausgaben einschalten.
Wenn er keinen passenden gefunden hat, kommt die Fehlermeldung. Du müßtest also mal schauen, ob a) das Fsfirst/next alle Treiber findet und ob dann Fopen den richtigen Treiber versucht zu laden. Vielleicht im host_xfs entsprechende breakpoints setzen.
-
@AndreasK : hast du einen Account auf https://www.atari-forum.com? Sonst würde ich das dort auch bekannt machen.
Ich habe auf meine Anfrage an den Administrator dort keine Antwort bekommen. Ein seltsames Gebaren. Vermutlich geht "gmx.de" auch nicht, und "gmail" will ich nicht. Vielleicht kannst Du da mal eine message droppen. Vielleicht auch mit Link auf dieses Forum, das läßt sich ja ggf. im Browser einfach ins Englische übersetzen.
-
Ja, mache ich.
-
Daraus berechnet er eine Farbdarstellung, z.B. Schwarzweiß, und konfiguriert eine Struktur entsprechend, die er dem MVDI (also dem Emulanten) weiterreicht.
Wobei man da aufpassen muss. Die von Behne zur Verfügung gestellten Sourcen passen nämlich nicht zu dem was AtariX/MagicOnLinux machen. Scheinbar haben die irgendwann die Übergabe umgestellt, die Emulatoren benutzen aber noch eine ältere Schnittstelle (war damals ziemlich aufwendig das auseinander zu frickeln, die ältere Version ist noch ersichtlich wenn man die alte mxvdiknl.o disassembliert, die ursprünglich nur als Object-File vorhanden war). In meinem repo sind die entsprechenden Stellen mit ifdef NEW_SETUP_API markiert.
Aber generell kann das nicht der Grund für den Problem sein, es funktioniert ja bei anderen. Irgendwas scheint da immer noch nicht mit den Pfaden (oder evtl. auch Zugriffsrechten) zu stimmen.
Edit: evtl macht auch diese Zeile in MagIC.cpp Probleme:
pMacXSysHdr->MacSys_pixmap = htobe32((uint32_t) (((uint64_t) &pAtari68kData->m_PixMap) - (uint64_t) mem68k));
MacSys_pixmap und mem68k sind beides Host-Zeiger. Im Kernel wird das als Zeiger auf die Pixmap für die Übergabe genommen, deswegen die Umrechnung. Allerdings ist imho momentan nicht garantiert, daß die Differenz noch im 32bit Bereich liegt.
Edit2: hm, oder auch nicht. pAtari68kData liegt auf den Fall im Atari-Speicher.
-
Der Emulant liest dann die Treiber von C:\GEMSYS. Näheres steht in "manual.txt". Standardmäßig braucht er MFM16M.SYS, für 16 Mio Farben. Du müßtest ein Fopen("MFM16M.SYS") sehen. Am besten in config.h alle XFS-Debug-Ausgaben einschalten.
Tadaa! Und schon funktioniert es.
Verwöhnt, wie man heutzutage ist, ging ich davon aus, dass das gebaute GEMSYS-Verzeichnis bereits alles enthält, was man braucht. Ich habe die fehlendes Dateien aus AtariX-MT/AtariX/rootfs-common ergänzt uns schon ging die Sonne auf.
Einstweilen besten Dank die Tipps!
-
Anleitung lesen hilft ;) Da stand z.B:
cp -rp AtariX/src/AtariX-MT/AtariX/rootfs-common Atari-rootfs
Aber schön, das es jetzt funktioniert.
Ich werde mich die Tage mal daran setzen, zumindest fertige ZIP-Archive zu basteln. Ist im wesentlichen das gleiche wie die schon vorhandenen für AtariX, bis auf die Sache mit der Gross-/Kleinschreibung (MagicOnLinux will auf C: unbedingt alles in Gross haben, weil es praktisch einem FAT Dateisystem entspricht).
Den Emulator selber muss man allerdings immer noch selber übersetzen.
-
@AndreasK : hast du einen Account auf https://www.atari-forum.com? Sonst würde ich das dort auch bekannt machen.
Ich habe auf meine Anfrage an den Administrator dort keine Antwort bekommen. Ein seltsames Gebaren. Vermutlich geht "gmx.de" auch nicht, und "gmail" will ich nicht. Vielleicht kannst Du da mal eine message droppen. Vielleicht auch mit Link auf dieses Forum, das läßt sich ja ggf. im Browser einfach ins Englische übersetzen.
Habe auch eine web.de Mail Adresse.
Greenious muss deine IP freigeben und ältere Browser sind nicht erlaubt, wenn ich einen älteren Browser zum Einloggen benutze wird meine IP sofort wieder gesperrt. Weiss nicht ob das jetzt auch noch so ist ...?
-
Greenious muss deine IP freigeben und ältere Browser sind nicht erlaubt, wenn ich einen älteren Browser zum Einloggen benutze wird meine IP sofort wieder gesperrt. Weiss nicht ob das jetzt auch noch so ist ...?
Was heißt schon älter? Ich habe Firefox und Chrome ausprobiert, und beide sollten ziemlich aktuell sein. Und die Website hat mich nicht gesperrt, sondern gar nicht erst akzeptiert; sinngemäß hat sie gesagt, daß web.de eine Spam-Schleuder sei und ich ein Bot oder Fiesling.
-
Ich hielt die Anleitung für ziemlich sicher. Ich habe sie sogar auf einem "frischen" Recher ausprobiert, für den Fall, daß noch ein Paket o.ä. fehlt. Inzwischen steht auch drin, daß man den überflüssigen Treiber, den mit -1fff, löschen soll. Mittelfristig soll das rootfs vom anderen Repo dann rüberwandern, aber wenn man alle Schritte treu und brav ausführt, sollte das funktionieren.
-
Ich habe Firefox und Chrome ausprobiert, und beide sollten ziemlich aktuell sein.
Da muss erst jemand deine IP freigeben ...
-
Vermutlich geht "gmx.de" auch nicht
Ja, leider. Schrieb ich ja weiter oben. Mit dem von Frank angesprochenen Browser- oder IP-Blocking hat das nichts zu tun, da wäre die Fehlermeldung eine andere.
-
Ich habe den Emulator jetzt auch auf meinem Hauptrechner mit Tumbleweed ans Laufen gebracht. Problem war der Pfad zum Atari-rootfs. Das liegt zwar in ~/Dokumente/Atari/Atari-rootfs, aber wenn ich das so angebe, wird zwar der Kernel gefunden, aber nicht der Gemsys-Ordner. Das home-Verzeichnis liegt auf einer anderen Partition und ist auf dem Bootlaufwerk verlinkt. Scheinbar macht das Probleme, denn wenn ich den kompletten Pfad (/mnt/quellverzeichnis/home/...) angebe, dann funktioniert es.
Sobald der Emulator läuft, schießt ein CPU-Kern auf 100% hoch und bleibt da. Mein Notebook wird dann ziemlich laut :-(
-
ISobald der Emulator läuft, schießt ein CPU-Kern auf 100% hoch und bleibt da. Mein Notebook wird dann ziemlich laut :-(
Ja, das ist normal. Versuch mal den kernel aus meinem ZIP-Archive, da sollte das nicht mehr der Fall sein:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14723 sebilla 20 0 1583896 104196 64744 S 0.664 0.649 0:00.95 magic-on-linux
-
Versuch mal den kernel aus meinem ZIP-Archive, da sollte das nicht mehr der Fall sein:
Hab' ich gerade gemacht, damit ist die CPU-Last wieder normal. Hat aber auch einen Nachteil, weil da der Mauszeiger dann etwas hinterherhinkt.
-
MagicOnLinux goes MagicOnMac
-
MagicOnLinux goes MagicOnMac
Ja her damit! Ich will auch! ;D
-
Sobald der Emulator läuft, schießt ein CPU-Kern auf 100% hoch und bleibt da. Mein Notebook wird dann ziemlich laut :-(
Das Programm "System Monitor" zeigt auf meinem Rechner eine CPU-Last von unter 1,5 %, umgerechnet auf einen Einkernprozessor.
-
Anleitung lesen hilft ;) Da stand z.B:
cp -rp AtariX/src/AtariX-MT/AtariX/rootfs-common Atari-rootfs
Jaja, neenee, das steht aber erst seit gestern da!
-
MagicOnLinux goes MagicOnMac
Kraß! Ich hätte nicht erwartet, daß das so fix geht. Hast Du SDL selbst bauen müssen? Oder über Homebrew? Es gibt ja leider kein "apt get" in macOS.
Mach' doch mal bitte eine Aufzählung der Schritte, die man unternehmen muß, dann gibt es ein "build-for-macos.txt". Ach ja, und irgendwo mußte man ja auch noch ein wenig an den Quellen ändern. Das müßte dann mit #ifdef _APPLE .. #endif oder so ähnlich gehen.
-
(..)
Jaja, neenee, das steht aber erst seit gestern da!
Hier kannst Du die Historie der Datei nachvollziehen. Gitlab lügt nicht:
https://gitlab.com/AndreasK/magiclinux/-/commits/main/README.md?ref_type=heads
-
So aus Rainer Neugier: Wenn ich NVDI (für die Fonts) installieren möchte, dann muss ich doch, wie bei der Firebee, die Treiber löschen oder? Also die Datein hier:
* NVDIDRV1.SYS
* NVDIDRV2.SYS
* NVDIDRV4.SYS
* NVDIDRV8.SYS
* NVDIDRVH.SYS
-
So aus Rainer Neugier: Wenn ich NVDI (für die Fonts) installieren möchte, dann muss ich doch, wie bei der Firebee, die Treiber löschen oder? Also die Datein hier:
...
Okay, hat funktioniert. Was ich aber ein bisschen seltsam finde ist dass die Programme im AUTO-Ordner in die autoexec.bat eingetragen werden müssen. So weit, so ok. Aber ACCs lassen sich so z.B. nicht starten (zum Beispiel Kobold3).
-
So aus Rainer Neugier: Wenn ich NVDI (für die Fonts) installieren möchte, dann muss ich doch, wie bei der Firebee, die Treiber löschen oder?
Kannst du, muss aber nicht. Der MVDI Kernel von MagicOnLInux (oder auch MagcMacX) versucht die gar nicht erst zu laden.
Was ich aber ein bisschen seltsam finde ist dass die Programme im AUTO-Ordner in die autoexec.bat eingetragen werden müssen.
Du kannst AUTOEXEC.BAT im AUTO-Ordner auch löschen, dann wird der ganz normal abgearbeitet. Problem ist nur, daß man dann die Reihenfolge nicht garantieren kann, wenn die wichtig sein sollte.
-
MagicOnLinux goes MagicOnMac
Kraß! Ich hätte nicht erwartet, daß das so fix geht. Hast Du SDL selbst bauen müssen? Oder über Homebrew? Es gibt ja leider kein "apt get" in macOS.
Mach' doch mal bitte eine Aufzählung der Schritte, die man unternehmen muß, dann gibt es ein "build-for-macos.txt". Ach ja, und irgendwo mußte man ja auch noch ein wenig an den Quellen ändern. Das müßte dann mit #ifdef _APPLE .. #endif oder so ähnlich gehen.
Das Lustige und gleichzeitig das Problem daran ist, dass die Mac Migration erstmal nur ein kleines Experiment ohne große Hoffnung war. Ich hatte noch nicht mal das Repository kopiert, sondern nur den aktuellen Stand von MagicOnLInux als ZIP geladen. Und dann spaßeshalber der "KI" Claude Code den Prompt erteilt, aus den Linux Sourcen baufähige Mac Sourcen zu erstellen. Das hat sie dann auch getan, allerdings waren im XFS noch ein paar kleinere Anpassungen nötig. Die habe ich per erweitertem XFS Logging und Xcode Debugging auf dem Fußweg erledigen können.
Die SDL Lib wurde ganz einfach über Homebrew installiert.
Jetzt muss ich nur noch nachvollziehen können, was Claude alles geändert hat. Sollte aber nicht unlösbar sein. Ich kann dazu einen separaten Branch anlegen und erstmal in meinen GitHub Account pushen. Inklusive Build Anleitung natürlich :)
-
(..)
Jaja, neenee, das steht aber erst seit gestern da!
Hier kannst Du die Historie der Datei nachvollziehen. Gitlab lügt nicht:
https://gitlab.com/AndreasK/magiclinux/-/commits/main/README.md?ref_type=heads
Gar kein Zweifel. Habs auch so in meiner Bash-Historie stehen, nur dass ich bei rsync mit --delete gearbeitet hatte. Ich werd' alt. Und man soll nicht mit zwei Augen auf drei Monitoren arbeiten UND nebenbei noch "mal eben schnell" magiclinux bauen und einrichten.
Also alles gut, ich hab nix gesagt, außer Danke für Eure Aufmerksamkeit.
-
Irgendein Ordner im $HOME Verzeichnis wäre schon besser denke ich
Ist IMHO auch schon deshalb besser, weil ja einige Ordner (C:\GEMSYS\HOME z.B.) sowieso Benutzer-spezifische Dateien enthalten. Einen gemeinsamen Ordner zu nehmen wie /opt/magiconlinux (oder /usr/share/games/magiconlinux) macht von daher nicht wirklich Sinn. Das einizige was man da evtl. plazieren könnte wäre der Emulator selber, und der Kernel.
-
(..)
h kann dazu einen separaten Branch anlegen und erstmal in meinen GitHub Account pushen. Inklusive Build Anleitung natürlich :)
Ich bin kein git-Experte. Lade das doch einfach hoch, ich lade es runter und schaue mit meld, was Du geändert hast. Alles andere ist mir zu kompliziert, und mit branches stehe ich auf Kriegsfuß, davon habe ich ein Trauma.
... und geht wahrscheinlich ab wie sow auf dem M4; man erzählt sich ja wahre Wunderdinge von der Singelchor-Performantz, und ich habe nur einen mittelalten i7.
-
Fertige root Filesysteme sind jetzt auch verfügbar unter
https://tho-otto.de/snapshots/magicmac/magiconlinux-de-latest.zip
https://tho-otto.de/snapshots/magicmac/magiconlinux-en-latest.zip
https://tho-otto.de/snapshots/magicmac/magiconlinux-fr-latest.zip
Edit: falls ihr den Emulator schon installiert habt, und evtl. Änderungen an MAGX.INF vorgenommen habt (z.B einfach weil ihr die Einstellungen in MAGXDESK gesichert habt), diese bitte vorher sichern.
-
Die Mac Version nebst IKEA genormter Bauanleitung gibt's hier:
https://github.com/idevelopers/MagicOnLinux/tree/macOS
Das Repository ist ein Fork vom ursprünglichen Repository von AndreasK, d.h. der Branch lässt sich ohne Probleme an den Ursprung verpflanzen und dort verarbeiten. Bin auch nur Branching n00b, aber ein paar Basics reichen hier schon :D
-
Die Mac Version nebst IKEA genormter Bauanleitung gibt's hier:
Hmm... irgendwas klemmt da bei mir:
labdev:~/tmp/MagicOnLinux/build $ cmake -G Xcode ..
CMake Error:
Xcode 1.5 not supported.
-
Hmm... irgendwas klemmt da bei mir:
labdev:~/tmp/MagicOnLinux/build $ cmake -G Xcode ..
CMake Error:
Xcode 1.5 not supported.
Xcode 1.5 ... in welcher macOS/OSX Umgebung versuchst du zu bauen? Es ist doch nicht wirklich Xcode 1.5 installiert? Get ins Jahr 2004 zurück :-X Da hat sogar mein Powerbook G4 eine neuere Version :D
Ich habe hier nur Latest&Greatest macOS 26 (Xcode 26), da läuft es nach der Anleitung. Wäre interessant zu erfahren, wie es sich auf weiteren Systemen verhält. Ich kann später spaßeshalber auch mal meinen G4 anschmeissen.
-
Keine Ahnung wie das zustande kommt. Hab einen MBP M2 mit macOS26 und bin deiner Anleitung gefolgt. Xcod und, über homebrew, pkg-config und sdl2 waren aber bereits installiert
-
Die Mac Version nebst IKEA genormter Bauanleitung gibt's hier:
Schick. Über ein paar der Sachen die du geändert hast war ich auch schon gestolpert:
- __dev_t und __ino_t sollten ersetzt werden durch dev_t (und ino_t kein #ifdef __APPLE__ nötig)
- __S_IWRITE sollte ersetzt werden durch S_IWUSR (ebenfalls kein ifdef nötig)
- <endian.h> (bzw. dessen Ersatz) sollte nur einmal in Globals.h included werden, erspart die ganzen ifdefs in den Sourcen
Ein paar Kleinigkeiten bleiben noch zu tun für macOS (xdg-open gibt es dort logischerweise nicht, und ~/.config ist wohl auch nicht der passende Ort für die Konfiguration-Datei).
In meiner Umgebung (macOS high-sierra, clang 9.0) musste ich noch
target_compile_options(magic-on-linux PUBLIC $<$<COMPILE_LANGUAGE:CXX>:-std=c++11>)
hinzufügen, sonst kennt er nulltptr etc. nicht. (einfach zu add_compile_options hinzufügen geht nicht, weil die Option sonst auch für die mushasi C-Sourcen genommen wird).
Aber ansonsten liess es sich übersetzen, und läuft scheinbar auch. Auch mit der SDL2-Library von MacPorts.
Edit: Wenn ich "Ausschalten" in MagxDesk wähle, kommt zwar die MessageBox, aber wenn ich die bestätige beendet MagicOnLinux sich nicht. Ich muss erst nochmal einmal in das Fenster klicken. Einfach Fenster schliessen geht aber auch.
-
Die Mac Version nebst IKEA genormter Bauanleitung gibt's hier:
Ein paar Kleinigkeiten bleiben noch zu tun für macOS (xdg-open gibt es dort logischerweise nicht, und ~/.config ist wohl auch nicht der passende Ort für die Konfiguration-Datei).
Hier heißt das Tool einfach nur "open". Aber egtl. kann man davon ausgehen dass /System/Applications/TextEdit.app vorhanden ist. Es gibt wohl .config wenn man diverse Pakete mit Homebrew installiert hat aber hier würde ich nicht davon ausgehen dass das vorhanden ist.
-
"open" funckioniert nicht, dafür müsste man erstmal "*.conf" registrieren:
No application knows how to open /Users/sebilla/.config/magiclinux.conf.
Edit: hm ok, "open -e" würde gehen.
-
Ich hab' auch mal Wikipedia aktualisiert: [https://de.wikipedia.org/wiki/MagiC]
Ich muß immer darauf achten, nichts Gutes zu schreiben, wegen Interessenkonflikt.
-
Ich hab' auch mal Wikipedia aktualisiert: [https://de.wikipedia.org/wiki/MagiC]
Ich muß immer darauf achten, nichts Gutes zu schreiben, wegen Interessenkonflikt.
ich habe das noch ein wenig glattgezogen (es stand wo, dass es MagiC nur für Mac und Windows gibt, und dass das ein Nachteil sei), und die englische Version auch etwas aufgefrischt. Aber da steht noch seeehr viel, das müßte „man“ mal strukturierter angehen.
-
BTW, weil du ORCS in MANUAL.TXT und erwähnst daß sharp-s nicht funktioniert, ich habs gerade mal ausprobiert. Kann es sein daß du möglicherweise eine falsche KEYTABLE.SYS verwendet hast?
-
Ja, mache ich.
Hab leider auch noch nichts gehört, kA. was da los ist, normalerweise reagieren die recht schnell. Hast du eine Adresse an die die sich direkt wenden können bei Nachfragen?
-
Noch ein Nachtrag zum Mac port: wenn ich auch unter linux clang statt gcc benutze, muss ich noch -fPIC oder -fPIE verwenden, ansonsten kommt
CMakeFiles/magic-on-linux.dir/src/m68k/m68kcpu.c.o: relocation R_X86_64_32S against symbol `m68ki_cpu' can not be used when making a PIE object; recompile with -fPIE
-
Habe noch einen fix in MagxDesk eingebaut, für die zu schnellen Doppelklicks. Sollte jetzt deutlich angenehmer sein.
Hat schonmal jemand Thing getestet, evtl, auch die neue Version von OL?
-
Die Konfiguration wird auf dem Mac nun in "~/Library/Preferences/" abgelegt.
-
Hat schonmal jemand Thing getestet, evtl, auch die neue Version von OL?
Hab mit den Gedanken gespielt aber hab mich dann für Jinnee entschieden nachdem ich zuerst mit Gemini rumgespielt habe.
-
BTW, weil du ORCS in MANUAL.TXT und erwähnst daß sharp-s nicht funktioniert, ich habs gerade mal ausprobiert. Kann es sein daß du möglicherweise eine falsche KEYTABLE.SYS verwendet hast?
Sorry, hat nix mit der Tastatur zu tun. Offenbar habe ich nicht daran gedacht, daß Du Schweizer bist, daher die schweizerische GUI. Schweizer trinken ja bekanntlich in Massen statt in Maßen und zahlen Busse, auch wenn sie gar nicht einsteigen möchten. 8)
-
Offenbar habe ich nicht daran gedacht, daß Du Schweizer bist
Wie kommst du da drauf? ;)
Wollte eigentlich nur wissen, ob es jetzt funktioniert, oder ob ich tatsächlich was in ORCS fixen muss.
-
PS.: hauptsächlich auf mac hab ich gemerkt, daß einige Dateinamen abgeschnitten werden. Liegt aber nicht am mac port, sondern an
case DP_NAMEMAX: return (drv_longNames[drv]) ? 31 : 12;
Evtl. sollte man dort 255 statt 31 nehmen? Oder _POSIX_HOST_NAME_MAX?
case DP_PATHMAX: return 128;
Scheint mir auch recht willkürlich.
-
Hat schonmal jemand Thing getestet, evtl, auch die neue Version von OL?
Nicht intensiv getestet, aber etwas eingerichtet und herumgespielt und keine Kernschmelze erlebt.
-
Danke, hatte mich nur grundsätzlich interessiert ob es Schwierigkeiten gibt.
PS: ganz schönes Biest geworden, das Programm. ~350K ist ja sogar mehr als Jinnee.
-
Die Konfiguration wird auf dem Mac nun in "~/Library/Preferences/" abgelegt.
Klasse! Ich habe Deine Änderungen, denke ich, alle eingepflegt. Im MACOS.txt habe ich eine Widmung eingefügt, die kann ich auch gern noch ändern (mit allen akademischen Titeln oder Klarname etc.).
Ich habe noch etwas aufgeräumt, und es fehlte noch eine assertion, weil das fcnt(F_GETPATH) eine Mindestpuffergröße voraussetzt. Vielleicht ist das noch nicht die richtige Lösung, aber ich wollte vermeiden, daß ein möglicher Überlauf unbemerkt bleibt.
Testen kann ich leider nix, d.h. ich könnte vielleicht meinen alten Mojave-Mac rauskramen, aber dazu komme ich derzeit nicht, und ich weiß auch nicht, ob das alte Teil noch irgendwie relevant ist.
PS: Einige "defaults" sind in die CMakeLists.txt gewandert.
PS/2: Ich habe den "default"-Namen des Atari-rootfs wieder in MAGIC_C geändert. Das erschien mir passender, denn es gibt ja auch andere Emulatoren. Wer schon eine config-Datei hat, braucht aber nix umzustellen, denn der Pfad steht ja drin.
PS/3: Der Atari-Kernel sollte im Normalfall nicht mehr in der conf-Datei angegeben werden, dann sucht das Programm auf dem Atari-Pfad "C:\". Das ist einfacher als vorher. Man kann aber immer noch einen alternativen Kernel eintragen.
-
Im übrigen war ich etwas schockiert, wieviele alte Programme nicht nur selber abstürzen, sondern auch das gesamte System in den Abgrund reißen.
Evtl. solltest du dafür mal checks (zumindest für die Debug-Version) in getAtariBE16(addr) etc. einbauen.
Das wird momentan meistens in der Art ``getAtariBE16(addrOffset68k + addr);`` benutzt, ohne addr auf eine gültige Atari-Addresse zu prüfen. Wenn das Atari-Programm dort Müll übergibt, liest/schreibt der Emulator von gott-weiss-wo. Oder vlt. solche Zugriffe durch m68ki_atari_read_xx ersetzen.
-
Lokalisierung ist fertig (nur für den "guest", nicht für den "host). Geht über config und Kommandozeile.
Ich habe direkt im AtariX-Repository zwei SHUTDOWN.PRG ge-patch-t, und zwar für EN und FR. Da war eine Abfrage auf die FPU drin, das war nicht schlimm, aber unschön in den Debug-Ausgaben. Die deutsche Version scheine ich irgendwann schon einmal geändert zu haben.
Vermutlich sind nicht alle Systemdateien in EN und FR vorhanden, ich habe nicht auf Vollständigkeit geprüft, möglicherweise ist noch Raum für Verbesserungen.
Man könnte theoretisch Verzeichnisse "ES", "IT" etc. hinzufügen, die müßten dann auch auswählbar sein.
Das Komponieren des "rootfs" wird zunehmend mühsam, mit den vielen Befehlen. Vielleicht baue ich einfach mal eine Script-Datei, oder ich lege den Baum mit ins Repository.
-
Ich habe direkt im AtariX-Repository zwei SHUTDOWN.PRG ge-patch-t, und zwar für EN und FR.
Oh. Das hättest du dir sparen können, die gab es schon fertig kompiliert für de und fr.
eine Abfrage auf die FPU drin, das war nicht schlimm, aber unschön in den Debug-Ausgaben.
Wenn du den fpu-test aus der Pure-C pcstdlib meinst: das habe ich vor ein paar Tagen erst entfernt. Betrifft auch alle anderen Applications.
Vermutlich sind nicht alle Systemdateien in EN und FR vorhanden,
Sollte eigentlich komplett sein. Lediglich für zwei Text-Dateien fehlt noch eine französische Übersetzung.
Man könnte theoretisch Verzeichnisse "ES", "IT" etc. hinzufügen,
Hm, das nutzt aber nicht viel. Weder für den Kernel noch für die Applikationen gibt es ja Anpassungen dafür. Das einzige was wohl dafür vorhanden ist ist eine KEYTABLE.SYS.
Vielleicht baue ich einfach mal eine Script-Datei, oder ich lege den Baum mit ins Repository.
Oder verweist auf meine ZIP-Archive ;)
-
gmail steht mit einiger Sicherheit auch auf der Blacklist. Kontakt mit einem Admin sollte aber gehen.
Es gibt keine Email-Kontaktadresse, sondern nur ein Formular. Ich nehme an, daß meine Anfragen alle in der Rundablage P gelandet sind.
-
(..)
Vielleicht baue ich einfach mal eine Script-Datei, oder ich lege den Baum mit ins Repository.
Oder verweist auf meine ZIP-Archive ;)
Ich denke, ich werde einfach beides machen.
-
Wann enstehen die Dümmsten Ideen? Genau, wenn man langeweile hat und kognitiv nicht ganz dabei ist. :D Jedenfalls hab ich mir den Laptop geschnappt und angefangen mit Google Gemini rumzuspielen.
Dabei kam dann ein grafischer Editor für die config datei von MagicOnLinux raus. Ich bin kein professioneller Programmierer und kann die Qualität des Codes nicht überprüfen aber es hat tierisch Spass gemacht was in den Prompt zu hacken und ein lauffähiges Programm zu bekommen. Die Langeweile war jedenfalls weg.
Das Programm läuft nur mit Linux (vielleicht noch mit MacOS mit Anpassungen) und lädt die config aus ~/.config/magiconlinux.conf (es kann aber auch per --config übergeben werden falls die woanders liegen sollte). Der Code und eine Anleitung zum bauen liegen hier: https://git.theragnarbay.org/ragnar/mol-config
-
Rofl. Hast du es auch getestet? Bei mir lässt er sich zwar übersetzen, tut aber nix (gtk version 3.24.38).
Hatte sowas auch schon angefangen, zu finden hier: https://github.com/th-otto/MagicOnLinux/tree/my/src/gui
Habe noch kein README dafür aber im wesentlichen (Pakete installlieren wie bei dir beschrieben, dann)
$ cd src/gui
$ make
Sollte sowohl mit GTK2 als auch mit GTK3 gehen.
Bin mir aber mittlerweile nicht mehr so ganz sicher ob GTK die richtige Wahl ist. Wenn ich mich recht erinnere, funktionierte das unter macOS nicht so besonders gut. Habs aber noch nicht getestet.
Edit: funktioniert doch. Braucht nur irgendwie ziemlich lange um das Fenster anzuzeigen. Liegt wahrscheinlich an
remote volume monitor with dbus name org.gtk.vfs.GoaVolumeMonitor is not supported
Der macht bei mir die letzte Zeit Faxen.
-
Es gibt keine Email-Kontaktadresse, sondern nur ein Formular. Ich nehme an, daß meine Anfragen alle in der Rundablage P gelandet sind.
Vlt. mal @simonsunnyboy fragen. Der ist einer der admins da drüben.
-
Mit dem Mauscursor habe ich Probleme, er scheint manchmal wild zu springen.
Ich bin übrigens dahinter gekommen, warum das Mauscursor nicht richtig funktioniert. Auf dem ARM64-System ist char standardmäßig "unsigned" [1,2], anders als auf x86_64. Siehe Screenshot. Damit schlagen solche Rechnungen https://gitlab.com/AndreasK/magiclinux/-/blob/368884cb11dd1d64c045dc5958b58303d31e45c9/src/MagiCMouse.cpp#L160-161 natürlich fehl und führen zu völlig falschen Mauspositionen.
Die Lösung ist:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index dd179d0..37c9228 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -10,7 +10,7 @@ else()
find_package(SDL2 REQUIRED)
endif()
-add_compile_options(-Wall -Wextra -Wpedantic -Wno-multichar)
+add_compile_options(-Wall -Wextra -Wpedantic -Wno-multichar -fsigned-char)
file(GLOB_RECURSE m68k src/m68k/*.c src/m68k/*.h)
file(GLOB_RECURSE sources main.cpp src/*.cpp inc/*.h)
Dann klappt's auch mit dem Mauszeiger.
PS: So viel zu "Aber ARM ist ja inzwischen auch little-endian, und wenn niemand Assembler verwendet, sollte das auch keine Probleme machen." ;)
PPS: Nun Issue #15 auf GitLab.
[1] https://lwn.net/Articles/911914/
[2] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#1011arithmetic-types
-
Vielen Dank! Hätte ich nie gefunden.
Wieviel ist eigentlich ein Kilobyte in "imperial units"? Und gibt es auch "middle endian" oder "no endian"?
-
Es gibt noch PDP-Endian: bytes in einem 16-bit wert sind little-endian, aber die beiden 16-Werte in einem 32bit Wert sind in big-endian Order. Dürfte aber keine Rolle spielen, solange du nicht versuchst den Emulator auf VAX zu portieren ;)
-
Es gibt noch PDP-Endian: bytes in einem 16-bit wert sind little-endian, aber die beiden 16-Werte in einem 32bit Wert sind in big-endian Order. Dürfte aber keine Rolle spielen, solange du nicht versuchst den Emulator auf VAX zu portieren ;)
Meine Uni hatte tatsächlich eine PDP-11. Darauf habe ich Prüfungen abgelegt. Das war das einzige Mal, daß ich mit so einem Gerät in „Berührung” gekommen bin. Ich glaube, das Teil war etwa mannshoch und mannsbreit und hatte nur 16 Bit Verarbeitungsbreite. Bei IBM gab es dann noch EBCDIC, das war auch nett.
-
Was ich gerade noch festgestellt habe beim rumprobieren: man bräuchte noch irgendeine APP die Konsolen-Ausgaben abfängt (vlt. in VT52.PRG einbauen?). Diverse "Schweineprogramme" schreiben sonst diverse Log-Ausgaben auf den Bildschirm.
-
Was ich gerade noch festgestellt habe beim rumprobieren: man bräuchte noch irgendeine APP die Konsolen-Ausgaben abfängt (vlt. in VT52.PRG einbauen?). Diverse "Schweineprogramme" schreiben sonst diverse Log-Ausgaben auf den Bildschirm.
Ich nutze T-Con dafür: https://atariuptodate.de/en/1747/t-con
-
(..)
Baut out-of-the-box.
Beeindruckend!
Und schick!
Was für die Perfektion noch fehlt, wären a) bestimmte Laufwerkbuchstaben verbieten (C: und U: z.B.) und b) die Flags aufschlüsseln oder noch c) beim Schweben mit dem Mauszeiger einen Hilfetext einblenden.
Aber ist schon toll, was man so machen kann. Ich habe null Erfahrung mit gtk.
Bleibt die Frage, wie hoch jedesmal der Aufwand ist, wenn sich das Format der Datei ändert. So heißt es jetzt z.B. LANG=de oder LANG=fr, nicht numerisch. Normalerweise kann man das LANG auch weglassen, und LANG=0 ist wie Weglassen, also "default language".
PS: Statt "delete" müßte es "remove" heißen, denn wir wollen ja nix löschen.
PS/2: Und die Grafikmodi sind "interleaved", nicht "interpolated".
PS/3: Und ich hätte natürlich "colour" geschrieben, bin nicht unitistatiamerikophil. :-)
-
Vlt. mal @simonsunnyboy fragen. Der ist einer der admins da drüben.
Ist er nicht nur Moderator? Ich habe gerade mal meinen Kontaktkanal zu einem Admin auf Atari-Forum.com genutzt. Keine Ahnung, ob es was bringt. Kann sein, dass sie bei ihrer Haltung bleiben GMX, web.de und Co nicht zu mögen und auf GMail verweisen. :(
@AndreasK : Falls ich eine positive Antwort bekommen, würde ich mich per PM (in diesem Forum) bei Dir melden.
-
Ist er nicht nur Moderator?
Hm, kA. In https://www.atari-forum.com/memberlist.php?mode=group&g=3506 taucht er auf, in https://www.atari-forum.com/memberlist.php?mode=team allerdings nicht.
-
Aber ist simonsunnyboy hüben wie drüben nicht die selbe Person?
https://forum.atari-home.de/index.php?action=profile;u=1934
-
Ja bin ich denn schon drin?
-
Jetzt brauch ich nur noch nen Browser. HighWire beschwert sich über fehlendes NVDI 3 (was zwar im Prinzip da ist, aber keine Vector-Fonts kann), und NetSurf stürzt gleich beim Start mit Bus-Error ab.
Edit: hm, bei netsurf liegt es daran daß es eine 020 Version ist, und eine FPU haben will. Leider gibt es keine Snapshots für '000.
-
(..)
Baut out-of-the-box.
Beeindruckend!
Und schick!
Danke. Das ganze Ding ist innerhalbe von ner Stunde entstanden
Was für die Perfektion noch fehlt, wären a) bestimmte Laufwerkbuchstaben verbieten (C: und U: z.B.) und b) die Flags aufschlüsseln oder noch c) beim Schweben mit dem Mauszeiger einen Hilfetext einblenden.
Das hatte ich später noch implementiert, außer C: und U: hab ich noch H: und M: aus der Liste ausgeschlossen wenn atari_h_home und atari_m_host_root aktiv gesetzt sind. Tooltips sind ne gute Idee.
Aber ist schon toll, was man so machen kann. Ich habe null Erfahrung mit gtk.
Ich noch viel weniger, mit Hilfe kann ich aus eigener Kraft ein "Hello World" in C schreiben.
Bleibt die Frage, wie hoch jedesmal der Aufwand ist, wenn sich das Format der Datei ändert. So heißt es jetzt z.B. LANG=de oder LANG=fr, nicht numerisch. Normalerweise kann man das LANG auch weglassen, und LANG=0 ist wie Weglassen, also "default language".
Ich hab das genommen was in der Config drin steht (atari_language = 0) und dann angenomme dass 0 = Deutsch, 1 = Englisch und 2 = Französisch ist. Genau beschrieben steht es ja nicht.
PS: Statt "delete" müßte es "remove" heißen, denn wir wollen ja nix löschen.
PS/2: Und die Grafikmodi sind "interleaved", nicht "interpolated".
PS/3: Und ich hätte natürlich "colour" geschrieben, bin nicht unitistatiamerikophil. :-)
Details... ;) Aber bei den Farben 16ip und 4ip wäre ich echt nicht auf interleaved gekommen.
-
Ja bin ich denn schon drin?
Goil!
Ich hätte nicht gedacht, daß das funktioniert.
Mußtest Du viel ändern?
Ein NVDI5 sollte sich doch eigentlich irgendwo im grey net auftreiben lassen. Vielleicht tut's auch ein GDOS. Da war mal was mit Speedo, glaube ich. Ich habe mich nie mit so etwas beschäftigt, weil ich ja die Behne Brothers direkt an der Hand hatte. Das fVDI wird wohl nicht gehen, das geht direkt an die Hardware oder auf den aranym-host, soweit ich weiß.
BDW: Warum gibt es hier keinen Leikbatten?
-
b) die Flags aufschlüsseln
Ganz vergessen, die Flags werden in einem neuen Fenster aufgeschlüsselt wenn ein zusätzliches Laufwerk oder Image hinzugefügt wird. Später, beim modifizieren kann man die Flags auch noch setzen
-
Am Magic kernel musste ich gar nix ändern (wird genauso gemacht wie bei anderen interfaces, MagicOnLinux schreibt eine Funkions-Nummer in die MSysX-Struktur). Interface in MagicOnLinux ist an das Interface von Aranym angelehnt für die Kommunikation mit dem Kernel, nur das halt MACPPC verwendet wird statt Natfeats. Ein Treiber für MagCNet war auch relativ schnell geschrieben.
Ein NVDI5 sollte sich doch eigentlich irgendwo im grey net auftreiben lassen
Ja, hab ich hier, aber noch nicht getestet. NetSurf wäre sowieso die bessere Wahl, bin gerade damit am kämpfen das zu übersetzen.
-
Netsurf scheint die gleichen Farb-Probleme zu haben die auch schon Pierre Ton-That berichtet hat.
Ausserdem kann er momentan keine host-Namen auflösen, muss ich noch schauen woran das liegt.
-
Aber ist simonsunnyboy hüben wie drüben nicht die selbe Person?
https://forum.atari-home.de/index.php?action=profile;u=1934
Ja bin ich. Habe es weitergeleitet und gesagt, daß auch ich von der Blockade dieser Domains nichts halte.
Ich bin da aber nicht Entscheider oder technischer Admin.
-
Ich habe eine web.de Mail Adresse und im Prinzip ist das doch egal man muss nur die IP freigeben also bei mir funktioniert das ...
-
Sodele, nach etwas längeren Meinungsverschiedenheiten zwischen Homebrew, GTK, bzip2 und freetype hab ich es geschafft mein Config Programm auch auf MacOS laufen zu lassen. Der Trick war in /opt/homebrew/opt/freetype/lib/pkgconfig/freetype2.pc die Requires so zu verändern dass dort kein bzip2 mehr steht.
-
Ich habe eine web.de Mail Adresse und im Prinzip ist das doch egal man muss nur die IP freigeben also bei mir funktioniert das ...
Es hat mit der IP-Adresse null-komma-gar-nix zu tun. Du kannst Dich mit einer web.de-Adresse nicht mehr neu registrieren bei Atari-Forum.com. Wenn Du es mir nicht glaubst, probiere es aus. Dann wirst Du die Fehlermeldung ("Spammers Domain - Stop Forum Spam!") auch sehen.
-
Ich habe eine web.de Mail Adresse und im Prinzip ist das doch egal man muss nur die IP freigeben also bei mir funktioniert das ...
Nicht böse gemeint aber warum hakt ihr alle auf der IP-Adresse rum. Kaum jemand hat eine statische IP die man whitelisten könnte. Jeder der noch DSL nutzt bekommt alle 24 Std. automatisch eine neue IP (Zwangstrennung). Bei FTTH sieht es etwas anders aus, Trennung täglich oder der DHCP lease bleibt so lange bestehen wie das Modem an ist.
-
Nicht böse gemeint aber warum hakt ihr alle auf der IP-Adresse rum. Kaum jemand hat eine statische IP die man whitelisten könnte. Jeder der noch DSL nutzt bekommt alle 24 Std. automatisch eine neue IP (Zwangstrennung).
Ist zwar off topic, aber hier gibt es schon lange keine regelmäßige Zwangstrennung mehr. T-Online, VDSL 100 in Oberfranken. Verbindung steht seit 06. November, also fast ein Monat.
-
(...)
Ist zwar off topic, aber hier gibt es schon lange keine regelmäßige Zwangstrennung mehr. T-Online, VDSL 100 in Oberfranken. Verbindung steht seit 06. November, also fast ein Monat.
Ist der 06. November nun vor dem 6. November oder nach dem 6. November? 8)
Und ich könnte zwar meine gmail-Adresse ausprobieren, will ich aber nicht. Ich möchte, daß das alles über die Haupt-Email-Adresse kommt. Dazu kommt, daß gmail auf dem Telefon eine eigene Äpp ist.
-
Ein problem in Netsurf gefunden (genauer gesagt lag das an Mintlib, die Dateinamen wie /etc/hosts nicht nach U:\etc\hosts wandelt, wenn kein Mint läuft). Fix in mintlib ist unterwegs, aber man kann sich auch behelfen indem man
#_ENV UNIXMODE=brU
in MAGX.INF hinzu fügt. Hostnamen werden jetzt aufgelöst, allerdings bekomme ich immer noch Connection timeouts (auch auf nicht-SSL Verbindungen). Die Suche geht also weiter....
Immerhin sind die Farben jetzt richtig, nach den letzten Patches von Andreas.
Es gibt auch noch ein paar Redraw-Probleme wenn man das Fenster vergrössert (tritt unter XaAES komischerweise nicht auf).
-
(...)
Es gibt auch noch ein paar Redraw-Probleme wenn man das Fenster vergrössert (tritt unter XaAES komischerweise nicht auf).
Du kannst das sinnvolle Neuzeichnen ("smart redraw") abschalten. DRIs AES ist da einfach sehr schlecht programmiert, oder das Konzept taugt nix, das Ergebnis ist häßliches Fensterflackern, wie bei Windows damals und teilweise noch heute. Bei MacOS war das immer tadellos. Wenn die Bildfehler dann weg sind, ist das Progamm schlecht geschrieben, und XaAES kopiert DRIs Designfehler.
-
Stimmt, damit geht es besser. Muss aber auch ein Fehler in Netsurf sein, andere Programme kommen ja auch mit Smart-Redraw zurecht.
Werde jetzt erstmal zusehen daß ich meine Patches reorganisiere, da gibt es ja ein paar Überschneidungen mittlerweile.
Treiber für MagCNet habe ich schonmal angehängt. Sourcen dafür sind auf https://github.com/th-otto/magxnet zu finden.
Die Dateien in dem Archiv sind alle GROSS geschrieben, besser wäre es allerdings, zumindest C:\ETC auf ein geeignetes Laufwerk zu legen (und dann etc_path in MAGX_RC.NET entsprechend anzupassen). Wäre vlt. eine Sache die man noch im Magic Configurator ergänzen könnte.
-
Stimmt, damit geht es besser. Muss aber auch ein Fehler in Netsurf sein, andere Programme kommen ja auch mit Smart-Redraw zurecht.
(..)
Richtig. Das schrieb ich ja auch sinngemäß.
DRI-AES hat nur ein Neuzeichungsrechteck, und das ist häufig noch größer als nötig. Tiefenbescheuert.
MagiC hat maximal zwei. Das macht den Bildschirmaufbau bereits wesentlich schöner, mit mäßigem Aufwand.
MacOS hat für jedes Fenster eine Liste aller sichtbaren Rechtecke, ohne Überschneidungen (paarweise disjunkt). Bei einer Fensteroperation (schieben, Größe ändern, Stapelposition ändern, öffnen, schließen) gibt es eine neue Liste. Dann wird quasi die alte Liste von der neuen subtrahiert, unter Berücksichtigung von Verschiebungen, die durch Kopieren des Bildspeichers gelöst werden, und das Ergebnis ist dann eine beliebig lange Liste von neuzuzeichnenden Rechtecken (ebenfalls paarweise disjunkt). Das Konzept ist quasi ideal, was die Eleganz und Ruhe des Bildschirmaufbaus angeht. Kein Flackern, kein Flickern, alles weich und elegant, ohne 3D-Grafikbeschleuniger.
Windows war da irgendwie auch nicht so dolle.
Das Ganze hat sich inzwischen mit dem "compositing window manager" erledigt, mit massivem Hardware-Einsatz; hier ist der Bildschirm eine 3D-Szene, und jedes Fenster liegt im 3D-Raum an einer bestimmten z-Position, der Inhalt ist Textur, und den Rest erlegt die 3D-Grafik-Hardware, auch mit Transparenz, Unschärfen, Abdunkeln etc.
-
So, Patches rebased gegen deinen momentan Stand, verfügbar unter https://github.com/th-otto/MagicOnLinux/commits/PR/ Der Netzwerk-Treiber ist Teil davon.
Netsurf für '000 ist verfügbar unter https://tho-otto.de/download/netsurf/ns000-7057.zip (nur executable, rest in https://ci.netsurf-browser.org/builds/atari/NetSurf-m68k-atari-mint-gcc-7057.zip)
Ach und bevor ich es vergesse: Konfiguration ist wie bei Aranym. Ich habe allerdings nur bridge-Modus getestet, für point-to-point-Modus wäre aratapif erforderlich (ein suid executable).
-
So, Patches rebased gegen deinen momentan Stand, verfügbar unter https://github.com/th-otto/MagicOnLinux/commits/PR/ Der Netzwerk-Treiber ist Teil davon.
Beeindruckend! Genial! Was machst Du beruflich? Informatikprofessor?
Wie ist der Plan? Soll ich das übernehmen (merge), oder möchtest Du das getrennt halten? Eleganter wäre natürlich eine modulare (XCMD-) Lösung, mit einer .so-Datei bzw. .dylib.
Bin gerade beim Versuch, mehr Programme zum Laufen zu bringen bzw. den Totalabsturz zu vermeiden oder wenigstens an den Debug-Ausgaben zu sehen, was die so treiben. Ich habe gerade eine Omikron-Basic-Version auf dem Seziertisch. Das gruselig,. wenn man sich anschaut, was für einen Schindluder die mit den Hardware-Registern treibt.
Im übrigen (denn was zur Hölle ist ein Übriges?) beißen sich solche Versuche mit einem großen Atari-RAM. Wenn man den I/O-Adreßbereich des ST analysiert, dann liegt der irgendwo bei 0x00fxxxxx. Das beschränkt den emulierten (ST-) Speicher auf 15 MB inklusive Bildspeicher. Bei 1280x960x32 bleiben dann etwa 10 MB RAM übrig. Finde ich jetzt nicht weiter schlimm, aber ist zu berücksichtigen. Wenn man nur 0xffxxxxxx analysiert, gibt es diese enge Einschränkung natürlich nicht.
Eigentlich müßte man noch User-Modus-Zugriffe auf die Adressen 0 und 4 abfangen (Busfehler), und wenn man TT-Speicher emulierten wollte, wird es noch komplizierter. Leider vermindert jede Größer- oder Kleiner-Abfrage bei den Speicherzugriffen direkt die Emulationsgeschwindigkeit, weil das ständig in der innersten Emulationsschleife aufgerufen wird. Der Zugriff aufs TT-RAM wäre dann etwas langsamer, nicht schneller. Die Zugriffe auf 0 und 4 baue ich aber erstmal im Debug-Modus ein, für die Fehlersuche ist das wichtig. Eine Überwachung der "exception vectors" ist auch hilfreich, um zu schauen, ob ein Programm daran herumbiegt und sich dann nicht mehr sauber entfernen läßt.
-
Wie ist der Plan? Soll ich das übernehmen (merge), oder möchtest Du das getrennt halten?
Wäre gut wenn du das übernehmen könntest. Ich will ja die User nicht verwirren indem ich ein Konkurrenz-Produkt anbiete ;)
Muss allerdings dazu sagen, daß Netsurf immer noch nicht funktioniert bei mir, bin immer noch auf der Suche.
Eleganter wäre natürlich eine modulare (XCMD-) Lösung, mit einer .so-Datei bzw. .dylib.
Ist denke ich unnötig kompliziert, und führt zu noch mehr System-Abhängigkeiten. Ausserdem müsste so eine sharedlib ja dann erst irgendwo installiert werden wo der Emulator sie finden kann.
Ich habe gerade eine Omikron-Basic-Version auf dem Seziertisch. Das gruselig,. wenn man sich anschaut, was für einen Schindluder die mit den Hardware-Registern treibt.
Ja, Omikron ist bekannt für seine "Schweinereien". In EmuTOS gab es damit auch schon Probleme.
Wenn man den I/O-Adreßbereich des ST analysiert, dann liegt der irgendwo bei 0x00fxxxxx. Das beschränkt den emulierten (ST-) Speicher auf 15 MB inklusive Bildspeicher.
Ich habe bei mir gerade 512MB durchgehendes ST-RAM konfiguriert. Da MagicOnLinux den Kernel ja nicht an die übliche $00e00000 läd, funktioniert das problemlos. Funktioniert natürlich nur, solange die Programme nicht direkt auf die Hardware zugreifen, vor allem nicht auf den Bereich ab $00ff0000. Da MagcMacX/MagicOnLinux aber nur das BIOS emuliert und nicht die Hardware, würden solche Programme sowieso nicht funktionieren.
Eigentlich müßte man noch User-Modus-Zugriffe auf die Adressen 0 und 4 abfangen (Busfehler),
Theoretisch ja. In der Praxis dürfte es aber wohl kein Programm geben das dort Schreibversuche unternimmt. Addressen < $800 sollte man aber abfangen, wobei ich eigentlich nicht erwarte, daß es Programme gibt die dort versuchen im User-Modus zuzugreifen.
und wenn man TT-Speicher emulierten wollte, wird es noch komplizierter.
Könnte man, muss man aber denke ich nicht.
-
Bin gerade etwas am verzweifeln bei den Netzwerk-Problemen. Vlt. kann mir ja jemand auf die Sprünge helfen.
Zusammenfassung:
- Frisch übersetzte Netsurf-Version funktioniert unter Aranym/MiNT. Das sagt mir eigentlich daß es grundsätzlich keine Probleme bei der Netzwerk-Konfiguration gibt.
- Ich verwende die gleichen Einstellungen (inklusive MAC-Addresse & IP-Addresse) auch für MagicOnLinux
- PING.TTP aus dem MagicNet Paket funktioniert. Das sagt mir eigentlich daß der Netzwerk-Treiber für MagcNet grundsätzlich funktioniert.
- auch ein ping das mit der mintlib für freemint übersetzt wurde, funktioniert.
- Aber: wenn ich mit netsurf unter MagicOnLinux versuche eine Seite aufzurufen, bekomme ich Timeouts. Scheinbar kommen dort keine Daten an.
Irgendwelche Ideen? Ich habe es auch schon mit Log-Ausgaben sowohl unter Aranym als auch MagicOnLinux versucht, und versucht die zu vergleichen, sehe dort aber nicht verdächtiges.
Was mich allerdings irritiert: in den folgenden die Log-Ausgaben von Aranym, bei Aufruf meiner eigenen Homepage):
ETH0: packet received (len 90), triggering ETHERNETDriver interrupt
ETH0: recv 90:eth: dst 33:33:00:00:00:01 src 60:31:97:4b:08:28 type 86dd data: 60 00 00 00 00 24 00 01 fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 02
Ethernet: Dispatch 7
ETH0: SendPacket src 20fba152, len 0x3c
ETH0: send 60:eth: dst ff:ff:ff:ff:ff:ff 00 00 00 00src 00:41:45:54:48:30 type 0806 arp: hws 0001 prs 0800 hwl 06 prl 04 opcode 0001 src 00:41:45:54:48:30 192.168.1.7 00 00 00 00 00 00 00 00 00 01 3adst ff:ff:ff:ff:ff:ff 192.168.1.1 data: 00 00 00 01 00 05 02 00 00 82 00 56 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
27 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 7d 00 00
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0x5a
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba160, len 0x5a
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
Ethernet: Dispatch 2
ETH0: packet received (len 60), triggering ETHERNETDriver interrupt
ETH0: recv 60:eth: dst 00:41:45:54:48:30 src 60:31:97:4b:08:28 type 0806 arp: hws 0001 prs 0800 hwl 06 prl 04 opcode 0002 src 60:31:97:4b:08:28 192.168.1.1 dst 00:41:45:54:48:30 192.168.1.7 data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0x3c
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba160, len 0x3c
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
Ethernet: Dispatch 7
ETH0: SendPacket src 20fba044, len 0x4a
ETH0: send 74:eth: dst 60:31:97:4b:08:28 src 00:41:45:54:48:30 type 0800 ip: hl 45 tos 00 length 60 ident 1 frag 0000 ttl ff proto 01(ICMP) csum 3867 src 192.168.1.7 dst 192.168.1.1 data: 03 02 fc fd 00 00 00 00 46 00 00 20 00 00 40 00 01 02 43 2d c0 a8 01 01 e0 00 00 01 94 04 00 00 11 0a ee f5 00 00 00 00
ETH0: packet received (len 170), triggering ETHERNETDriver interrupt
ETH0: recv 170:eth: dst 33:33:00:00:00:16 src aa:f3:a0:bf:1c:4e type 86dd data: 60 00 00 00 00 74 00 01 fe 80 00 00 00 00 00 00 64 16 36 ff fe bf 51 5c ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 16 3a 00 05 02 00 00 01 00 8f 00 7e 80 00 00 00 05 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 fb 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff 0d 96 58 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff bf 1c 4e 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff bf 51 5c 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 6a
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0xaa
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba060, len 0xaa
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
ETH0: packet received (len 60), triggering ETHERNETDriver interrupt
ETH0: recv 60:eth: dst 01:00:5e:00:00:01 src 60:31:97:4b:08:28 type 0800 ip: hl 46 tos 00 length 32 ident 0 frag 4000 ttl 01 proto 02(IGMP) csum 432d src 192.168.1.1 dst 224.0.0.1 data: 94 04 00 00 11 0a ee f5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ETH0: waiting for int acknowledge with pending irq mask 01Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0x3c
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba060, len 0x3c
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
ETH0: packet received (len 90), triggering ETHERNETDriver interrupt
ETH0: recv 90:eth: dst 33:33:00:00:00:01 src 60:31:97:4b:08:28 type 86dd data: 60 00 00 00 00 24 00 01 fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 01 3a 00 01 00 05 02 00 00 82 00 56 96 27 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 7d 00 00
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0x5a
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba160, len 0x5a
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
Ethernet: Dispatch 7
ETH0: SendPacket src 20fba044, len 0x4a
ETH0: send 74:eth: dst 60:31:97:4b:08:28 src 00:41:45:54:48:30 type 0800 ip: hl 45 tos 00 length 60 ident 2 frag 0000 ttl ff proto 01(ICMP) csum 3866 src 192.168.1.7 dst 192.168.1.1 data: 03 02 fc fd 00 00 00 00 46 00 00 20 00 00 40 00 01 02 43 2d c0 a8 01 01 e0 00 00 01 94 04 00 00 11 0a ee f5 00 00 00 00
ETH0: packet received (len 170), triggering ETHERNETDriver interrupt
ETH0: recv 170:eth: dst 33:33:00:00:00:16 src aa:f3:a0:bf:1c:4e type 86dd data: 60 00 00 00 00 74 00 01 fe 80 00 00 00 00 00 00 64 16 36 ff fe bf 51 5c ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 16 3a 00 05 02 00 00 01 00 8f 00 7e 80 00 00 00 05 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 fb 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff 0d 96 58 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff bf 1c 4e 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 01 ff bf 51 5c 02 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 6a
ETH0: waiting for int acknowledge with pending irq mask 01
Ethernet: Dispatch 2
Ethernet: Dispatch 5
ETH0: ReadPacketLength: 0xaa
Ethernet: Dispatch 6
ETH0: ReadPacket dest 20fba060, len 0xaa
Ethernet: Dispatch 2
ETH0: IRQ acknowledged
Ethernet: Dispatch 2
Ethernet: Dispatch 2
Ethernet: Dispatch 2
ETH0: int acknowledged, pending irq mask now 00
Ethernet: exit
ETH0: Stop thread
Irgendwie sehe ich da überhaupt keine Pakete für die eigentliche Seite. Sie wird aber korrekt angezeigt.
Zur Konfiguration:
- 60:31:97:4b:08:28 ist die MAC-Addresse von meinem Router (192.168.1.1)
- 00:41:45:54:48:30 ist die MAC-Addresse des Emulators (192.168.1.7)
-
Ich kenne mich mit Netsurf nicht aus. (U.a. weil ich Web-Browsen auf TOS-Systemen für ein sinnloses Unterfangen halte ;) ). Aber kannst Du ausschließen, dass Deine Webseite von einem früheren Aufruf im Browser-Cache liegt und daher gar nicht neu übers Netzwerk angefragt wird?
Ich würde mich an das Problem langsam herantasten und erst einmal einen simpleren Client (FTP, Telnet, ...) testen.
-
(U.a. weil ich Web-Browsen auf TOS-Systemen für ein sinnloses Unterfangen halte ;) ).
Auf "normalen" TOS-Systemen: da stimme ich dir zu. Aber in schnellen Emulatoren durchaus praktikabel. Es geht mir mir auch nicht primär um Netsurf, sondern hauptsächlich generell um Netzwerk-Zugriff über den Host.
Aber kannst Du ausschließen, dass Deine Webseite von einem früheren Aufruf im Browser-Cache liegt und daher gar nicht neu übers Netzwerk angefragt wird?
Ja, kann ich denke ich.
Ich würde mich an das Problem langsam herantasten und erst einmal einen simpleren Client (FTP, Telnet, ...) testen.
Simpler als ping? ;) Aber ich schau mal. ftp und telnet laufen allerdings keine Server bei mir, wenn das nicht klappt kann es auch an der firewall liegen.
-
Hast du schon das DNS im Auge? Was ist wenn die die IP statt der Webadresse eingibst?
-
Eigentlich ein guter Tip, aber daran liegt es nicht. Auch bei Eingabe einer IP bekomme ich Timeout. Und ping funktioniert auch bei Eingabe eines Hostnamens.
PS: wer ftp etc. testen will: im Treiber-Archiv fehlt dafür noch eine C:\etc\services Datei. Kann man aber wohl vermutlich von überall her kopieren.
-
Hmmm... Ich werfe mal ein paar Schlagwörter in den Raum:
- Firewallregeln die den Transfer blockiern
- NAT Regeln richtig?
Du könntest auch mal probieren ob Cab läuft und was dann passiert. Ansonsten fällt mir noch der WebOne Proxy (oder Sqquid aber den zu confen ist ne eigene Nummer) ein. Geht es damit?
Wenn alles nichts hilft musst du wohl den traffic mit ncap/wireshark sniffen
-
Hab' jetzt von von Thorsten Otto alles übernommen, was mit Netzwerk zu tun hat. Ich hoffe, ich habe die richtige Version erwischt. Testen kann ich es leider nicht.
-
Danke. Leider haben sich durch meinen Code eine paar Probleme für macOS ergeben. Sollten mit https://github.com/th-otto/MagicOnLinux/commit/bfc8df76f86944d77d150e0f2c327b61e287a7ab behoben sein. Vermutlich funktioniert das TunTap-Gedöns unter macOS aber sowieso nicht, in Aranym gab es das zwar auch mal für alte Darwin-Versionen, aber mittlerweile wird dort BPF verwendet, was aber noch nicht portiert ist. Ausserdem würde das auch ein suid-executable (bpf_helper) benötigen.
Ausserdem fehlt für macOS noch ein `include <time.h>` in conversion.h (ist nicht in oben gelinktem commit, weil ich das bei mir schon vorher irgendwo eingefügt hatte).
PS.: falls solche detallierte Diskussionen hier stören, gerne auch per email
-
Hab' jetzt ein Nutzerkonto bei "atari-forum.com". Meine email-Adresse ist nicht mehr auf der blacklist.
-
Hab' jetzt ein Nutzerkonto bei "atari-forum.com". Meine email-Adresse ist nicht mehr auf der blacklist.
Sehr schön. Ich wollte auch gerade kommentieren, dass ich heute vom kontaktierten Admin dort eine Antwort bekommen hatte, wonach web.de und GMX nun nicht mehr pauschal ge-blacklist-et seien.
-
(..)
Sehr schön. Ich wollte auch gerade kommentieren, dass ich heute vom kontaktierten Admin dort eine Antwort bekommen hatte, wonach web.de und GMX nun nicht mehr pauschal ge-blacklist-et seien.
Es hat sich doch gelohnt, hartnäckig zu bleiben. Ich habe übrigens meinen Nutzernamen jetzt mit dem englischen Forum harmonisiert, damit man mich wiedererkennt und auch ich nicht durcheinanderkomme. Und dann habe ich mir noch einen abgebrochen, weil ich mich "vorstellen" sollte. Na gut, kann man ja machen. Ist ja kein Forum mit Millionen von Mitgliedern.
-
Bin da gerade auf ein Problem gestoßen, dessen Ursache etwa im Jahr 2005 entstanden ist. Damals habe ich für MagicMacX zwei anscheinend ungültige 68k-Opcodes für die Kommunikation mit dem PPC-Host verwendet. Jetzt wollte ich meinem Disassembler beibringen, die korrekt zu behandeln, ohne aus dem Tritt zu geraten, d.h. den nächsten Opcode zu verschlucken. Und - voilá - mein Disassembler hatte recht, und der von mir verwendete 68k-Emulator Musashi hatte unrecht. Die Opcodes waren scheinbar ungültig. Nämlich doch nicht. Und nun?
Die neue Musashi-Emulator-Version, die ich früher oder später verwende möchte (kann wohl auch Fließkomma) erfordert nicht nur große Umbauten, sondern dekodiert die Befehle cmp2 und chk2 anscheinend auch korrekt. Das sind selten verwendete Befehle im 68020-Befehlssatz.
Wenn ich jetzt alles umbaue auf andere Opcodes, welche Programme laufen dann nicht mehr? Thorstens Netzwerktreiber nutzt den Opcode 0x00c0. Noch jemand? Oder ist das alles? Ich könnte mir andere Opcodes suchen, wenn es noch welche gibt, oder man könnte dahinter immer ein "nop" schreiben. Dann wäre sichergestellt, daß der chk2-Befehl ungültig ist.
Bitgefusel für Insider:
0x00c0 0000 decodiert zu cmp2.b d0,d0
0x00c0 4e71 decodiert zu DC.W $c0; nop
-
Bitgefusel für Insider:
0x00c0 0000 decodiert zu cmp2.b d0,d0
0x00c0 4e71 decodiert zu DC.W $c0; nop
Mit welchem Disassembler? $00c0 is kein gültiger opcode, weder für 68000 noch für 68020+, von daher sehe ich da eigentlich kein Problem (data-register direkt, wie oben ausgegeben, ist keine gültige Addressierungs-Art für cmp2) Nur für Coldfire ist das ein gültiger opcode (bitrev.l d0), aber das kann man hier wohl vernachlässigen ;) (Die von den NatFeats verwendeten Opcodes wären für ColdFire ebenfalls gültig).
die korrekt zu behandeln, ohne aus dem Tritt zu geraten, d.h. den nächsten Opcode zu verschlucken.
Warum verschlucken? Nach dem Opcode kommt nix mehr was zum Interface gehört, Parameter werden in Registern übergeben??
Thorstens Netzwerktreiber nutzt den Opcode 0x00c0.
MVDI und dein HostXFS.s nutzen den ebenfalls.
Die neue Musashi-Emulator-Version, die ich früher oder später verwende möchte
In https://github.com/th-otto/AtariX/tree/master/src/AtariX-MT/AtariX hatte ich das schon umgestellt auf 3.4 (soviel ich weiss die letzte Version). Die Umstellung war, wenn ich mich recht erinnere, nicht allzu dramatisch. Fließkomma-Befehle konnte die aber auch noch nicht.
Fliesskomma korrekt zu emulieren ist sowieso so eine Sache. Problem ist daß bei den meisten Compilern double nur 64bit ist, womit sich die 68k-Fließkomma-Werte nicht korrekt darstellen lassen. Und long-double ist nicht überall verfügbar. Selbst wenn, gibt es da kleine aber feine Unterschiede in der externen Darstellung (nicht nur endian-Probleme, 68k speichert die ohne implizites integer-Bit und hat dadurch 1 bit mehr für die Mantisse als z.B. x86).
Edit: oh, sehe gerade, unter https://github.com/kstenerud/Musashi gibt es eine deutlich neuere Version.
-
$00c0 is kein gültiger opcode, weder für 68000 noch für 68020+, von daher sehe ich da eigentlich kein Problem (data-register direkt, wie oben ausgegeben, ist keine gültige Addressierungs-Art für cmp2)
Danke! Ich hatte mich dumm und dusselig gesucht nach einer Liste der 68k-Befehle und ihrer Codierung. Ich habe ausschließlich "68000_68010_68020_Primer.pdf" gefunden. Das Dokument ist sehr unübersichtlich, und Deine Information fehlt dort. Kennst ein besseres Dokument im pdf-Format?
PS: Hier ist es hübsch: https://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/chk2.HTML. Dort steht auch, welche Adressierungsarten erlaubt sind. Und tatsächlich, da ist einiges verboten.
PS/2: Disassembler ist korrigiert, und tatsächlich ergeben sich einige Unterschiede, anhand derer ich sehen kann, daß die Korrektur erfolgreich war.
-
Danke! Ich hatte mich dumm und dusselig gesucht nach einer Liste der 68k-Befehle und ihrer Codierung.
Das PRM kennst Du sicherlich? https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf
-
Danke! Ich hatte mich dumm und dusselig gesucht nach einer Liste der 68k-Befehle und ihrer Codierung.
Das PRM kennst Du sicherlich? https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf
Nee, bei NXP hätte ich zuletzt gesucht. Aber schönes Dokument, da scheint alles Wichtige drinzustehen Danke!
-
Ich habe tagelang nach dem Gelbfehler im Vierfarb-Interleaved-Modus gesucht, der nur mit NVDI auftrat, und schließlich habe ich als Alternativstrategie nicht mehr im NVDI weitergesucht (fünf Megabyte disassembly...), sondern den schon als fehlerhaft erkannten MVDI-Treiber repariert und schließlich erfolgreich gebaut (verdammter pasm...). Der liegt jetzt erstmal im Programm-Repository, aber sollte noch in das Repository der Kernel-Quellen rein. Ursache ist ein typischer Copy-Paste-Fehler, d.h. die falschen Zeilen wurden aus Unachtsamkeit aus dem 16-Farb-Treiber unverändert übernommen. :)
-
Nice. Hab die Änderungen auch bei mir übernommen. War hoffentlich der letzte Copy/Paste error dieser Art ;)
verdammter pasm
Do NOT use PASM, as it corrupts "label(pc)" addressing
Was genau meinst du damit? Die Treiber wurden alle mit PASM übersetzt, hab da bisher noch nichts festgestellt. Welchen Assembler hast du denn dann genommen? Denke nicht, daß die Syntax ohne Änderungen von anderen Assemblern geschluckt wird.
BTW, bei dir in den Original-Sourcen ist immer noch der Aufruf von MM_init: https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/-/blob/master/MagiC/KERNEL/VDI/SRC/MAGICVDI.2/MXVDIKNL.S?ref_type=heads#L1432-L1433
Dieser wandelt den alten PixMap-Pointer in die neue VDI_SETUP_DATA-Struktur um. Das funktioniert aber eigentlich nicht mit den MAC-Treibern, weil die immer noch einen PixMap-Pointer erwarten: https://gitlab.com/AndreasK/magiclinux/-/blob/main/kernel/VDI/DRIVERS/MAC/SRC/MFM4IP.S?ref_type=heads#L257-259
-
Der PASM hat den 4IP-Treiber kaputt-assembliert, d.h. der erzeugte Code war kaputt. Ich hatte ihn im Modus "create DRI object file" aufgerufen, wie ich das immer mache. Mein Disassembler hat dann gezeigt, wo das Teil Mist gebaut hatte. Ich habe dann schließlich die Behnesche prj-Datei verwendet und es mit PureC gemacht, mit der GUI.
Ich habe dann den älteren MASM ausprobiert, und der hat an den Stelle, an denen der PASM Mist gebaut hatte, eine Fehlermeldung ausgespuckt und sich geweigert, das Programm zu assemblieren. Gut so!
Ursache ist wohl, daß die Behne Brothers PC-relativ von TEXT nach BSS referenzieren. Das geht natürlich eigentlich nicht, und weil ich das im Kernel nicht mache, tritt der Fehler nicht auf. Schwein gehabt. Der MASM weigert sich. Gut. Der PASM kann das vermutlich, aber nicht im DRI-Modus, d.h. er glaubt, daß er kann, kann es aber nicht und schreibt an alle solche Stellen eine Null als 16-Bit-Offset. Dumm gelaufen bzw. maximal gemein und fies.
DIe Kernel-Quellen muß ich eh mal abgleichen; ich habe mir einen "issue" geschrieben, als Erinnerung.
PS: Die Quellen für PASM wären nett...
PS/2: Heute das ganze Fsfirst/next/Dopen/read/closedir-Zeugs aufgeräumt. Hoffentlich nicht verschlimmbessert, habe es noch nicht ausgiebig getestet.
PS/3: Jemand eine Idee, warum Signum 3 und 4 wild mit der Maus herumhüpfen und unbedienbar sind? Ich sehe da auch keine Hardware-Zugriffe, und die Grafik scheint OK zu sein. Alt-Cursor geht ja auch nicht, weil die Maus immer zurückspringt. Ich schau mal, ob ich die SDL-Funktion zum Mauszeigerverschieben aufrufen kann.
-
Ich habe dann schließlich die Behnesche prj-Datei verwendet und es mit PureC gemacht, mit der GUI.
Das dürfte eigentlich keinen Unterschied machen. PASM ist nicht in die IDE integriert und wird auch dort extern geladen. Und bei den automatischen Builds (in aranym) wird der auch von einem Mupfel-Skript aufgerufen. Einziger Unterschied ist vermutlich, daß er dann kein DRI-Objekt erzeugt (wozu auch, macht eh nur Probleme mit den 8-Zeichen langen Namen).
d.h. er glaubt, daß er kann, kann es aber nicht und schreibt an alle solche Stellen eine Null als 16-Bit-Offset. Dumm gelaufen bzw. maximal gemein und fies.
Dürfte eigentlich nur passieren, wenn das label nicht bekannt ist. In dem Fall müsste es eigentlich vom Linker angemeckert werden. Weisst du noch die Stelle die kaputt geht? Dann könnte ich das mal in dem Treiber aus meinem Archiv kontrollieren.
Die Quellen für PASM wären nett...
Hust. Hatte ich vor langer Zeit mal reverse-engineered. War noch nicht ganz perfekt (es gibt da eine ziemlich umfangreiche Funktion von ca 1400 Sourcelines in C, die noch nicht exakt den gleichen Code erzeugt wie das original). Aber insgesamt ist der Code soweit, daß ich damit eine neue Version kompilieren kann. Bei Interesse kann ich dir mal ne Einladung schicken.
PS.: PASM hat noch einen anderen unangenehmen Bug, den ich noch nicht gefunden habe. Eigentlich kommt er auch mit Dateien zurecht, die nur LF als Zeilenende haben. Manchmal scheint es aber vorzukommen, daß er dann den gleichen Befehl zweimal ausspuckt (bisher meist bei "nop" der Fall gewesen, wo das normalerweise nicht weiter tragisch ist, aber ansonsten natürlich Murks).
-
Einziger Unterschied ist vermutlich, daß er dann kein DRI-Objekt erzeugt (wozu auch, macht eh nur Probleme mit den 8-Zeichen langen Namen).
Genau. Aber ich verwende den aln (ich hatte damals wichtige Gründe dafür, und der war immer zuverlässig), und der will DRI-Objektdateien.
(..)Weisst du noch die Stelle die kaputt geht? Dann könnte ich das mal in dem Treiber aus meinem Archiv kontrollieren.
Einfach pasm -v -b MFM4IP.SYS. Dann z.B. mit disass68k.sh -ac3 kontrollieren oder alternativ mas statt pasm.
Das mit den pasm-Quellen ist sehr interessant! Aber mit dem Debuggen von pasm würde ich mich verzetteln. Es wäre nur schön, wenn man diesen Fehler in irgendeinem ERRATUM dokumentieren könnte. Übrigens hatte ich noch offiziell eine Version (so etwas habe ich immer freundlicherweise von ASH bekommen) etwa vom Januar 1993 (?), und aus ominöser Quelle habe ich jüngst ein Archiv gefunden mit einem pasm vom Juni desselben Jahres. Das ist hoffentlich das neueste.
-
Einfach pasm -v -b MFM4IP.SYS.
Huks, tatsächlich.:
--- ok 2025-12-15 13:10:28.479910052 +0100
+++ wrong 2025-12-15 13:10:32.613225013 +0100
@@ -80,7 +80,7 @@
[000000ec] 4258 clr.w (a0)+
[000000ee] 20f9 0000 04ea move.l $000004EA,(a0)+
[000000f4] 7027 moveq.l #39,d0
-[000000f6] 247a 03e6 movea.l $000004DE(pc),a2
+[000000f6] 247a 0000 movea.l $000000F8(pc),a2
[000000fa] 246a 002c movea.l 44(a2),a2
[000000fe] 45ea 000a lea.l 10(a2),a2
[00000102] 30da move.w (a2)+,(a0)+
"wrong" wurde mit -b übersetzt, und die Instruktionen kommen von sowas wie "move nvdi_struct(pc),a2", wobei nvdi_struct im BSS-Segment iegt. Frage mich nur, ob hier nicht der Linker der ist der den Murks baut. Aber einer von beiden sollte auf jeden Fall meckern.
Da ich bei mir beim übersetzen aber DRI nicht benutze, sind die binaries dort nicht betroffen.
Einfach Abhilfe wäre auch, dort entweder nicht pc-relative zu benutzen, oder die Variablen nicht ins BSS zu legen.
Übrigens hatte ich noch offiziell eine Version (so etwas habe ich immer freundlicherweise von ASH bekommen) etwa vom Januar 1993 (?), und aus ominöser Quelle habe ich jüngst ein Archiv gefunden mit einem pasm vom Juni desselben Jahres. Das ist hoffentlich das neueste.
Da wäre ich sehr daran intereressiert.
-
"wrong" wurde mit -b übersetzt, und die Instruktionen kommen von sowas wie "move nvdi_struct(pc),a2", wobei nvdi_struct im BSS-Segment iegt. Frage mich nur, ob hier nicht der Linker der ist der den Murks baut. Aber einer von beiden sollte auf jeden Fall meckern.
Sach ich ja. Und es liegt natürlich nicht am Linker, sondern das Format gibt das nicht her.
Mein Debugger übersetzt auch .o-Dateien, inklusive aller Symbole. Du mußt, glaube ich, "-n" spezifizieren, weil der faule Assembler den Code nicht markiert, wie er es tun müßte. Dann kannst Du genau sehen, wer schuld ist.
Bei atari-forum.com gibt es einen Faden "A couple abandonware apps", dort findet man zwar nicht alles Mögliche, aber alles mögliche. Schau dort mal nach!
-
das Format gibt das nicht her.
Eigentlich schon. Der linker sieht ja, wo die Referenz erfolgt, und wo das Symbol liegt das referenziert wird. Der Assembler sieht das nur, wenn das Symbol bekannt ist, was aber nicht unbedingt der Fall sein muss.
Bei atari-forum.com gibt es einen Faden "A couple abandonware apps", dort findet man zwar nicht alles Mögliche, aber alles mögliche. Schau dort mal nach!
Dann scheine ich die wohl zu haben ;) Die Version von der ich ausgegangen bin, meldet sich mit Jun 21 1993
-
Oliver Buchmann himself war so nett, auch die ASH-Website entsprechend zu aktualisieren: https://www.application-systems.de/magicmacx/ (https://www.application-systems.de/magicmacx/).
Vielen Dank dafür!
-
Fliesskomma korrekt zu emulieren ist sowieso so eine Sache. Problem ist daß bei den meisten Compilern double nur 64bit ist, womit sich die 68k-Fließkomma-Werte nicht korrekt darstellen lassen. Und long-double ist nicht überall verfügbar. Selbst wenn, gibt es da kleine aber feine Unterschiede in der externen Darstellung (nicht nur endian-Probleme, 68k speichert die ohne implizites integer-Bit und hat dadurch 1 bit mehr für die Mantisse als z.B. x86).
Edit: oh, sehe gerade, unter https://github.com/kstenerud/Musashi gibt es eine deutlich neuere Version.
Die FPU-Unterstützung in Musashi läuft offenbar ohne "long double", daher signifikant langsamer als möglich, aber ist vermutlich nicht ganz zu Ende gedacht. Zitat:
extern void m68040_fpu_op0(void);
extern void m68040_fpu_op1(void);
extern void m68881_mmu_ops(void);
Das wirkt etwas seltsam. Die PMMU ist bekanntlich 68851 und nicht 68881, außerdem fehlen dem 68040 ein paar FPU-Befehle, die man softwaretechnisch nachrüsten müßte -- oder man tut so, als ob die FPU vollständig wäre. Eigentlich schwebte mir die Konfiguration 68020+68882 vor, das macht am wenigsten Umstand, und eine PMMU ist "teuer". Wäre das ein 68EC040 (EC für economy class)? Ich habe die Übersicht verloren.
Außerdem ist der Emulator komplizierter geworden; die eigentlichen Funktionen werden erst generiert, möglicherweise im make-Prozeß, d.h. es gibt eine Art template und einen Code-Generator.
Ist vielleicht den Aufwand doch nicht wert. Schneller würde es vermutlich auch nicht.
-
MMU macht vermutlich wenig Sinn im moment, solange das nicht vom Kernel unterstützt wird. Ausserdem würde es den Emulator deutlich langsamer machen (bei Aranym ist es etwa 50% der non-JIT version).
FPU wäre aber schon ganz nett. Es gibt vermutlich ein paar Programme die für 030+FPU übersetzt wurden und dadurch momentan nicht funktionieren.
Wäre das ein 68EC040 (EC für economy class)?
68LC040 = keine FPU
68EC040 = keine FPU, keine MMU
außerdem fehlen dem 68040 ein paar FPU-Befehle, die man softwaretechnisch nachrüsten müßte -- oder
man tut so, als ob die FPU vollständig wäre.
Aranym tut auch so als ob die FPU vollständig wäre. Ist natürlich eigentlich nicht ganz richtig, aber wenn man die korrekt emuliert, müsste man auch ein FPSP in den Kernel packen (oder nachladen).
-
Ich sachs euch, nehmt mir die KI weg, das führt zu nix ;D . Dieses mal ist ein Bootmanager für MagicOnLinux ausgekommen. Probiert es aus. https://git.theragnarbay.org/ragnar/mol-boot
-
(..)
Wenn die KI jetzt auch noch die Schreibfehler beseitigen würde, dann wäre ich restlos überzeugt. Solange tröste ich mich damit, daß ich es noch besser kann. 8)
Aber ansonsten: Bin beeindruckt!
Übrigens ist bei den Einstellungen ein relativer Mausmodus dazugekommen, extra für Signum.
-
Apropos Einstellungen: In Optionen/Einstellungen/Kopieren-Löschen kann man den Kobold aktivieren. Installiert isser, aber MoL (Magic on Linux) meckert, es sei nicht installiert. Wie kann ich MoL davon überzeugen, bzw. wo einstellen, dass es Kobold findet?
-
Eintrag in magx.inf hinzufügen:
#_ENV KOBOLD=C:\WO\IST\KOBOLD.PRG
-
Eintrag in magx.inf hinzufügen:
#_ENV KOBOLD=C:\WO\IST\KOBOLD.PRG
Danke, macht Sinn (ist alles schon so lange her), aber tutet nicht.
...
#_ACC C:\AUTO\ACCS\
#_APP C:\GEMSYS\MAGIC\START\
#_SCP C:\GEMSYS\GEMSCRAP\
#_TRM C:\GEMSYS\GEMDESK\VT52.PRG
#_ENV HOME=C:\GEMSYS\HOME\
#_ENV TEMP=C:\GEMSYS\GEMSCRAP
#_ENV TMPDIR=C:\GEMSYS\GEMSCRAP
#_ENV KOBOLD=C:\UTILS\KOBOLD35\KOBOLD_3.PRG
#_SCP C:\GEMSYS\GEMSCRAP\
...
-
Mal Kobold Version 2 versucht? Bin mir gerade nicht was MagxDesk da unterstützt.
-
Mal Kobold Version 2 versucht? Bin mir gerade nicht was MagxDesk da unterstützt.
Gerade nachgeholt, aber selbe Fehlermeldung. Schaunwamal, wer da was zu nachliefern kann. Keine Eile, alles gut.
-
Apropos Einstellungen: In Optionen/Einstellungen/Kopieren-Löschen kann man den Kobold aktivieren. Installiert isser, aber MoL (Magic on Linux) meckert, es sei nicht installiert. Wie kann ich MoL davon überzeugen, bzw. wo einstellen, dass es Kobold findet?
Ist Kobold überhaupt gestartet oder wenigstens als ACC installiert?
-
Apropos Einstellungen: In Optionen/Einstellungen/Kopieren-Löschen kann man den Kobold aktivieren. Installiert isser, aber MoL (Magic on Linux) meckert, es sei nicht installiert. Wie kann ich MoL davon überzeugen, bzw. wo einstellen, dass es Kobold findet?
Ist Kobold überhaupt gestartet oder wenigstens als ACC installiert?
Gute Idee! Vorhin beides ausprobiert, aber immer noch die selbe Fehlermeldung.
-
Gute Idee! Vorhin beides ausprobiert, aber immer noch die selbe Fehlermeldung.
Wenn Du sicher bist, daß Du alles richtig gemacht hast, kannst Du ja mal die HostXFS-Debug-Meldungen einschalten. Dort siehst Du u.a., wenn vergeblich versucht wird, auf Dateien oder Ordner zuzugreifen. Du mußt dazu in config.h die entsprechende Zeile aktivieren und das Programm neu, im Debug-Modus compilieren; letzteres ist im README beschrieben. Du könntest auch den schon compilierten Emulator in bla-release umbenennen, dann kannst Du zukünftig auswählen, ob Du die Release- oder Debug-Version starten möchtest. Oder umgekehrt die Debug-Version bla-debug nennen, dann wird die Release-Version weiterhin mit dem Programmsymbol angezeigt. BDW: Vielleicht wäre es eine gute Idee, das cmakefile so zu erweitern, daß die Debug-Version einen anderen Namen kriegt.
-
Top, danke! Das krisch' hin. Ich geb dann die Tage laut...
-
Nur um sicher zu gehen, du hast den Kobold als ACC in C:\AUTO\ACCS kopiert (warum die da liegen und nicht auf c:\ weiss ich auch nicht) und in in den Einstellungen von Magxdesk den Kobold aktiviert? Hier funktioniert es ohne Probleme. Achte auch darauf dass der Dateiname in Großbuchstaben ist (das macht aber magiconlinux automatisch beim kopieren).
-
in C:\AUTO\ACCS kopiert (warum die da liegen und nicht auf c:\ weiss ich auch nicht)
Sicher Geschmackssache. Mir gefällt das auch nicht besonders, aber immer noch besser als im Root-Verzeichnis. Man kann das auch ändern in MAGX.INF
#_ACC C:\AUTO\ACCS\
was aber dann zu Schwierigkeiten bei der Einrichtung führt, da das Standard-rootfs die ACCs auch dort liegen hat. Insbesondere funktioniert dann die neue Option zum wechseln der Sprache nicht mehr.
Also besser dort belassen. Ist ja bei linux auch nicht anders, die Standard-Pfade sind vom System vorgegeben.
Im Grunde genommen auch relativ egal, Hauptsache man weiss wo sie zu finden sind ;)
-
Beim Ausprobieren von irgendwelchen arbitrarischen Programmen bin ich auf die Idee gekommen, man könnte ja noch die alten Ur-ST-Funktionen zum Ändern der Farbpalette einbauen. Wenn die Behnes schon einmal die ST-kompatiblen Treiber für ST-mittel und ST-niedrig geschrieben haben...
Eine üble Bitfuselei. Erkenntnis: Programme schimpfen auf Xbios und lesen und schreiben stattdessen brontal und überflüssigerweise von den und in die Paletten-Register, die Schlingel! Oder immer abwechselnd Register und Xbios. Also noch ein Registermodell für die 16 Palettenregister eingebaut, aber ach: Die lesen und schreiben auch noch mit 32-Bit-Zugriffen zwei Farben gleichzeitig, die Knilche. Also reingefrickelt, aber ach: Jetzt drehen sie mit Setscreen() an der physikalischen Bildschirmadresse herum. Also auch das noch reingefrickelt, aber ach: Jetzt schreiben sie hinter dem 32000-Byte-Bildspeicher herum, wenn auch noch innerhalb von 32k. Das könnte ich auch noch tolerieren, aber mir reicht's erstmal für heute.
Das Programm, das ich zum Testen verwendet habe, kenne ich nicht einmal; es heißt CSB.PRG und startet mit einer Animation. Die ging vorher gar nicht, und jetzt kann man immerhin etwas sehen. Der Konfigurations-Parameter für MoL heißt dabei "-g320x200x4ip". Das ist das Synonym für "ST low".
-
Die ACCs liegen im AUTO-Ordner, damit sie nicht das Wurzelverzeichnis verseuchen, und traditionell werden sie ja auch automatisch geladen. Besser wäre "GEMSYS/MAGIC/START", das ist die moderne Variante.
Man kann die ACCs jederzeit per Doppelklick nachladen. Warum denn auch nicht? Und man kann sie über den Task-Manager wieder rauswerfen.
Übrigens haben mir beim Testen irgendwelche Programme den START-Ordner mit OLGA und BUBBLE und anderen gefüllt, was dazu führte, daß plötzlich Fehlermeldungen im Textmodus mitten auf dem Bildschirm erschienen und das System lahmlegten, irgendwas mit Runtime Error in Line 20 o.ä.. Vielleicht ein BASIC-Compilat. Jedenfalls müßt Ihr aufpassen, den START-Ordner von Müll sauberzuhalten. Oder der Emulator hat noch Inkompatibilitäten.
-
Nur um sicher zu gehen, du hast den Kobold als ACC in C:\AUTO\ACCS kopiert (warum die da liegen und nicht auf c:\ weiss ich auch nicht) und in in den Einstellungen von Magxdesk den Kobold aktiviert? Hier funktioniert es ohne Probleme. Achte auch darauf dass der Dateiname in Großbuchstaben ist (das macht aber magiconlinux automatisch beim kopieren).
Kobold als Programm oder ACC läuft soweit, das ist bei mir nicht das Problem. Aktiviert in MoL ist es, und wenn ich Dateien von einem Fenster ins andere droppe (also ohne Kobold), erscheint die erwähnte Warnung. Egal ob Kobold auf dem Desktop aktiv ist oder nicht, ebenso egal ob v2 oder v3.
Mit anderen Desktops funktioniert es, aber da wird Kobold nicht nur aktiviert, sondern auch der Pfad zu Kobold muss gesetzt werden.
-
Wenn Du sicher bist, daß Du alles richtig gemacht hast, kannst Du ja mal die HostXFS-Debug-Meldungen einschalten. Dort siehst Du u.a., wenn vergeblich versucht wird, auf Dateien oder Ordner zuzugreifen. Du mußt dazu in config.h die entsprechende Zeile aktivieren und das Programm neu, im Debug-Modus compilieren [...]
Habsch gemacht. zumindest meine alten Augen sehen da nix auffälliges (aber das heißt j auch nix) und auch im Live-Log passiert gerade einmal nichts, wenn ich eine Datei von hier nach da schiebe - außer eben der "Kobold nicht installiert" Fehlermeldung.
Als Bettlektüre das Debug-Output anbei.
-
Als Bettlektüre das Debug-Output anbei.
Ja, die XFS-Meldungen sind anscheinend o.B.
Aber:
DBG-WRN m68k_write_memory_16() -- 68k vec 0x000000a8 := 0x00000001 (Trap 10) by process C:\AUTO\ACCS\KOBOLD.ACC
Das ist schon übel. Wer macht sowas?
-
DBG-WRN m68k_write_memory_16() -- 68k vec 0x000000a8 := 0x00000001 (Trap 10) by process C:\AUTO\ACCS\KOBOLD.ACC
Das ist schon übel. Wer macht sowas?
Vielleicht jemand, der ungeprüft einem Nullpointer (+ Offset in ein Array / eine Struct) folgt. Müsste man sich im Debugger ansehen.
-
Vielleicht jemand, der ungeprüft einem Nullpointer (+ Offset in ein Array / eine Struct) folgt. Müsste man sich im Debugger ansehen.
Sehr gut diagnostiziert. Und auf dem Original-Atari wäre das in tausend Jahren nie jemandem aufgefallen.
Übrigens startet dieses Spiel CSB jetzt leidlich, mit 32768 statt 32000 Bytes Bildspeicher und dem ganzen Bildschirmadressen- und Paletten-Gedöns. Ich hab's mal mit Hatari ausprobiert, das ist schon beeindruckend: mit Ton und synchroner Start-Animation. Die Farben stimmen bei mir möglicherweise noch nicht ganz, aber es kann sein, daß innerhalb der Animation die Farbpalette nicht synchron aktualisiert wird. Ist auch eher so ein Gimmick, denn zum Spielen gibt's ja Hatari .. wenn nur der Mauszeiger dort nicht immer in der Bildschirmmitte wie angenagelt kleben bliebe, das NÄRFT.
-
wenn nur der Mauszeiger dort nicht immer in der Bildschirmmitte wie angenagelt kleben bliebe, das NÄRFT.
Ja, Aranym hat da auch so Probleme damit manchmal. Ist halt nicht einfach Host/Emulation Maus zu synchronisieren, wenn man im Grunde nichts über das TOS weiss, und lediglich die Hardware emuliert. MagicOnLinux hat es da deutlich einfacher.
Bei Hatari kommt noch dazu, daß viele Spiele ihre eigenen Routinen für ACIA haben, und TOS dafür gar nicht benutzen. Da kann der Emulator gar nicht wissen, wo die gerade die Atari-Maus darstellen.
-
Die Position des Atari-Mauszeigers findet man in den "negativen LineA-Variablen".
-
For convenience:
-a, --atari-screen-mode=mode Atari compatibility mode st-low/mid/high, overrides --geometry
Mit dem Parameter "-a st-mid" kann man z.B. jetzt einfacher die Auflösung 620x200 bei 4 Farben einschalten, wobei in diesem Fall automatisch die vertikale Größe des Fensters verdoppelt wird.
Ich habe noch einen ärgerlichen Fehler behoben, der bewirkte, daß man manchmal das Programm mit "kill -9" beenden mußte, weil es sich nicht sauber beenden ließ.
Die Unterstützung des ganzen G'lump mit physikalischen und logischen Bildschirmadressen und Farbtabellen über Xbios oder Register führt lediglich dazu, daß einige Spiele nun ihr Intro anzeigen können und erst dann irgendwo hängenbleiben. Das dient eigentlich eher der Analyse, warum irgendwas nicht funktioniert, z.B. weil es auf irgendwelche Hardware-Register wartet.
Generell gefällt mir die Angabe des Farbmodus als Parameter noch nicht, das ist alles inkonsistent. Die Modi sollten wie bei den Grafiktreibern heißen, also bspw. 4ip für vier Farben und 16ip für 16 Farben, nicht nach der Bit-Tiefe, das sorgt für Verwirrung.
-
Endlich mal ein Programm zum Laufen gebracht, das vorher nicht funktionierte: MonST ist ein fieser Debugger, der Auflösung und Bildschirmadresse über Registerzugriffe abfragt bzw. sogar ändert. Der funktioniert jetzt zumindest in "ST-high". Hat keine große Relevanz, ist eher Spielerei.
-
Mit dem Einbau einer Tonausgabe würde man ein Riesenfaß aufmachen; Hatari hat da so ein highly sophisticated Programm, das den Yamaha-Chip emuliert. Einfacher wären erstmal der Tastenklick und Glocke; SDL kann wohl WAVs o.ä. abspielen. Aber woher kriege ich passende Tondateien? Ob es da frei verfügbare gibt, wo man sich bedienen kann? Ansonsten bliebe noch Selbermachen, also Klavier, Klopfen, Pizzicato oder Singen zum Beispiel.
-
Den tastenklick fand ich immer nervig, vielleicht wäre das eine Alternative?
https://freesound.org/people/BryanSaraiva/sounds/820351/
Dort finden sich auch andere Sounds die Creative commons sind
-
Hatari hat da so ein highly sophisticated Programm, das den Yamaha-Chip emuliert.
Direkt die Hardware zu emulieren widerspricht imho der Philosophie. Besser wäre es vermutlich, eine Schnittstelle für GSXB zur Verfügung zu stellen.
SDL kann wohl WAVs o.ä. abspielen.
Ja, WAV sollte immer gehen. Aber vermutlich willst du für Sound sowieso SDL-Mixer benutzen, da gehen dann auch alle möglichen anderen, *.ogg zB.
-
Den tastenklick fand ich immer nervig, vielleicht wäre das eine Alternative?
https://freesound.org/people/BryanSaraiva/sounds/820351/
Dort finden sich auch andere Sounds die Creative commons sind
Gefällt mir. Vielleicht das hier noch als Ping ("Bell"):
https://freesound.org/people/datasoundsample/sounds/638638/
-
[...] oder Singen zum Beispiel.
Da bin ich raus...das wollt Ihr sicherlich nicht hören ;)
-
[...] oder Singen zum Beispiel.
Da bin ich raus...das wollt Ihr sicherlich nicht hören ;)
... und Pizzicato ist zu lang. Bleibt die Elektronik.
Übrigens laufen jetzt Signum 3 und 4 perfekt, bevorzugt im 256-Farben-Modus. Da gab es noch ein Problem mit der Maus; das habe ich zufällig gefunden, als ich den Tastenklick oder -klack einbauen wollte bzw. Vorbereitungen für selbiges.
-
Apropos Maus: ich habe mir deine Änderungen dafür angeschaut. Prinzipiell lässt du dir relative statt absolute Koordinaten von SDL schicken. An den Atari werden aber in jedem Fall immer relative Koordinaten geschickt. Ich verstehe nicht so ganz, was das für Signum ändert?
-
Apropos Maus: ich habe mir deine Änderungen dafür angeschaut. Prinzipiell lässt du dir relative statt absolute Koordinaten von SDL schicken. An den Atari werden aber in jedem Fall immer relative Koordinaten geschickt. Ich verstehe nicht so ganz, was das für Signum ändert?
Das ist auch vertrackt. Der Knackpunkt ist, daß ich normalerweise -- im Unterschied zu Hatari und Aranym -- immer versuche, die Mauszeiger von Gastgeber und Gast zur Deckung zu bringen. Das ist nämlich genau das, was mir bei den anderen Emulatoren fürchterlich auf den Zeiger geht: Ich rühre wie bescheuert mit der Maus, und der Hatari-Atari-Zeiger klebt wie eine Fliege am Fenster, links oder oben. Nun fummelt aber Signum anscheinend an der Mauszeigerposition des Atari herum, und das mag der Emulator nicht und zieht die Maus immer wieder zurück. Deshalb das Gehüpfe. Im relativen Modus ist, einfach gesagt, egal, wo der Host-Mauszeiger steht, der Atari kriegt also stumpf die Mausbewegungen. Dann funktioniert auch die Maus-Emulation im Atari, über Alt-(Umschalt-)Cursor. Im absoluten Modus müßte man dann den Mauszeiger des Hosts auch mit verschieben, sonst hüpft der Zeiger des Atari nämlich bei nächster Gelegenheit wieder zurück.
Übrigens gehen jetzt das Klick und das Pling. Es war eine schwierige Geburt, weil ich kein einfaches Beispiel gefunden habe und nicht kapiert hatte, daß es drei SDLs gibt, wovon zwei Mixer sind. Vielleicht kann mal jemand ausprobieren, ob das Programm auf dem Apple noch baut. Ich habe Schwierigkeiten mit cmake gehabt, weil der SDL-Mixer nicht so eingebunden wird wie SDL selbst (wobei der alte Mixer 1.2 wiederum so eingebunden wird, aber mit SDL2 kollidiert). Damit man keinen alten Kernel verwendet, ist jetzt auch eine Abfrage drin, denn für die Signaltöne braucht man eine neue Version.
PS: Die Signaltöne sind direkt in das Programm eingebunden, damit es keine Probleme beim Finden der Ton-Dateien zur Laufzeit gibt. Irgendwie hat Linux kein Konzept für Dateien, die ein bestimmtes Programm benötigt. Bei macOS ist das elegant gelöst.
PS/2: Die Glocke zeigt ja häufig einen Fehler an, ist also hilfreich, aber vielleicht sollte der Tastenklick standardmäßig erstmal ausgeschaltet sein...
-
Wer das Programm jetzt vor Jahresende noch installiert, kriegt kostenlos bunte Bildchen im Dateimanager (bei mir Nautilus) für alle Atari-Programmdateien. Zugreifen, ehe es zu spät ist!
Warum die Dateien "Other" sind, weiß ich nicht. Die Datei-Eigenschaften zeigen die richtige Bezeichnung. Es war auch wieder eine schwierige Geburt; selbst die offiziellen Beschreibungen des MIME-Konzepts sind dürftig, und Beispiele sind unvollständig und fehlerhaft.
(Wer sich wundert: Ich habe mein Ubuntu auf Englisch gestellt, weil ich mich sonst ständig über dumm-dämlich-häßlich-denglishe Übersetzungsfehler ärgere ("Wollen Sie die Upp-Dahtes dohnlohden?"). Life Hack: Auf English (UK) stellen, dann kriegt man ein zivilisiertes Datumformat und nicht das proprietäre US-Zeugs. Zusätzlich kann man noch Datum und Uhrzeit auf "deutsch" stellen, das ignorieren aber einige Programme.)
PS: Man kann jetzt Atari-Programme auf der Kommandozeile übergeben. Es sollte beides funktionieren, Atari-Pfad oder Host-Pfad.
PS/2: Das Logo wirkt vielleicht etwas zeitgeistig, das ist aber unbeabsichtigt; ich fand es einfach nur fröhlich in dieser düsteren Jahreszeit.
PS/3: Doppelklick auf ein Atari-Programm im Nautilus-Dateimanager startet eine neue Instanz des Emulators und darin sofort das entsprechende Atari-Programm.
PS/4: Wenn man eine ".st"-Datei oder andere "disk/volume images" als Parameter übergibt, auch z.B. im Dateimanager ("Öffnen mit..."), kann man sie als A: oder B: aktivieren, nach Rückfrage. Hatari installiert diesen Datentyp nicht ganz korrekt, man kann aber das Icon nachtragen.
-
Alle Dateien fürs rootfs liegen jetzt direkt im Emulator-Repository, und es gibt entsprechend neue und sehr viel kürzere Installations-Anweisungen. Im wesentlichen muß man nur noch ein Skript ausführen.
Leider konnte ich das Prozedere noch nicht vollständig testen, weil ich dazu praktisch einen "frischen" Rechner brauche. Das werde ich noch nachholen. Außerdem reagiert das Skript je nach Anwesenheit von Hatari unterschiedlich.
PS: Ich habe auch einen Hinweis auf Thorstens rootfs-"Snapshots" ins README geschrieben.
-
Großartig! Lief bisher schon toll und wird immer noch toller. Dank an alle Beteiligten und Cheerio, kommt gut ins Neue, woll!? :-*
-
Großartig! Lief bisher schon toll und wird immer noch toller. Dank an alle Beteiligten und Cheerio, kommt gut ins Neue, woll!? :-*
Danke und ein "dito" von mir!
Die Versionsnummer ist jetzt 0.9, d.h. ich denke, es läuft soweit. Trotzdem habe ich noch ein "uninstall"-Script geschrieben, damit man das Programm wieder los wird - auch zum Testen der Installationsprozedur.
-
Etwas OT:
Ich finde Hatari genial und auch das Konzept des EmuTOS ganz prima und habe damit schon etwas herumgespielt, insbesondere für Kompatibilitätstests. Andererseits fühle ich mich an düsterste Zeiten zurückversetzt, weil EmuTOS alle Dummheiten und Häßlichkeiten von GEM geerbt hat, ohne irgendeinen Fortschritt:
Das Fenster schnappt immer noch zusammen, wenn man nur das Größenänderungsfeld anklickt, und das gruselige, überflüssige Geflacker beim Fensterwechsel (wenn die sich teilweise überlappen) tut geradezu weh. Beides hatte ich schon beim KAOS repariert, weil es mir so auf den Senkel ging. Ich habe auch etwas mit Online-Emulatoren für klassisches Mac OS herumgespielt, und, alle Achtung, das klassische Mac OS ist absolut unerreicht in dieser Beziehung. Nun ja, Qualität hat ihren Preis, und Power without the Price war halt nicht Quality without the Price. Ich weiß übrigens nicht, ob NAES oder XAES oder MAES oder GENEVER das besser machen; das war alles quasi "nach meiner Zeit". Ich habe mich auch praktisch nie mit Mint beschäftigt, das lief auf meinem ST einfach laaaangsam.
-
fühle ich mich an düsterste Zeiten zurückversetzt, weil EmuTOS alle Dummheiten und Häßlichkeiten von GEM geerbt hat, ohne irgendeinen Fortschritt:
Das finde ich (und ich spreche hier in meiner Rolle als Projektleiter) - ehrlich gesagt - ein bisschen frech. :( Der Fortschritt von EmuTOS gegenüber Atari TOS ist erheblich. Vielleicht weniger im AES, wo der Hauptfokus eben auf der kompatiblen Nachbildung von Atari TOS liegt. Aber bei Open-Source-Software gilt schließlich: nicht meckern, selbst machen.
-
( Der Fortschritt von EmuTOS gegenüber Atari TOS ist erheblich. Vielleicht weniger im AES, wo der Hauptfokus eben auf der kompatiblen Nachbildung von Atari TOS liegt. Aber bei Open-Source-Software gilt schließlich: nicht meckern, selbst machen.
Richtig. Ich störe mich halt an Äußerlichkeiten, ich bin ein Augen-Mensch. Aber im Museum schaue ich ja auch nicht hinter die Bilder, ob die stabil befestigt sind. :)
-
WTF! Jetzt habe ich einen Riesenaufwand betrieben, um herauszufinden, warum das vermaleidete GFABASIC 3.6 mit einem weißen Bildschirm hängenbleibt und wie ich das verhindern kann, und jetzt finde ich heraus, daß jemand im Jahre 2022 (a) das gleiche Problem hatte und (b) die gleiche Lösung gefunden hat: https://www.atari-forum.com/viewtopic.php?p=432805
Die Diagnose "Someone else added that GFA Basic sends a command to query the joysticks" kann ich aber erstmal nicht bestätigen. Ich finde keinen XBIOS-Ikbdws()-Aufruf, und zwar weder in meinem disassembly noch im trace von Hatari. Deshalb bleibt diese Schleife für mich unverständlich.
Mit dem Patch läuft das Programm im "single mode" in ST-high und ST-mid. Von ST-low aus versucht es - leider vergeblich - auf ST-mid umzuschalten, natürlich mit Registerzugriff statt XBIOS, wäre ja auch zu einfach. Bei anderen Auflösungen stürzt GFABASIC ab und reißt das gesamte System mit.
-
Ich finde keinen XBIOS-Ikbdws()-Aufruf, und zwar weder in meinem disassembly noch im trace von Hatari.
GFA benutzt nicht ikbdws, sondert sendet ein einzelnes Byte mit Bconout(4):
[0001a7de] 7016 moveq.l #22,d0
[0001a7e0] 6100 851a bsr $00012CFC
...
[00012cfc] 3f00 move.w d0,-(a7)
[00012cfe] 5140 subq.w #8,d0
[00012d00] 13c0 0001 2d16 move.b d0,$00012D16
[00012d06] 4879 0003 0004 pea.l $00030004
[00012d0c] 4e4d trap #13
[00012d0e] 5c8f addq.l #6,a7
[00012d10] 4e75 rts
Das Kommando was da gesendet wird, dient zum Abfragen beider Joysticks.
-
GFA benutzt nicht ikbdws, sondert sendet ein einzelnes Byte mit Bconout(4):
Heißen Dank und Frohes Neues!
Ich hatte bei der Masse von beobachteten Bconout-Aufrufen schon so etwas vermutet, die Theorie dann aber verworfen.
Die Adressen scheinen sich etwas verschoben zu haben. Bei mir sieht es so aus:
lblA7C2:
move.w #$22,-(sp) *00A7C2=3f3c0022
trap #$e * xbios Kbdvbase *00A7C6=4e4e
addq.l #2,sp *00A7C8=548f
movea.l d0,a3 *00A7CA=2640
adda.w #$18,a3 *00A7CC=d6fc0018
move.l (a3),-(sp) *00A7D0=2f13
move.l #lblA7BA,(a3) *00A7D2=26bc0000a7ba
clr.l lbl2D12 *00A7D8=42b900002d12
moveq #$16,d0 *00A7DE=7016 <==== BCONOUT
bsr lbl2CFC *00A7E0=6100851a
lblA7E4:
tst.l lbl2D12 *00A7E4=4ab900002d12
beq.s lblA7E4 *00A7EA=67f8 <====== ENDLOSSCHLEIFE
Mein Disassembler kann den versteckten Bconout-Aufruf hier natürlich nicht finden.
-
( Der Fortschritt von EmuTOS gegenüber Atari TOS ist erheblich. Vielleicht weniger im AES, wo der Hauptfokus eben auf der kompatiblen Nachbildung von Atari TOS liegt. Aber bei Open-Source-Software gilt schließlich: nicht meckern, selbst machen.
Richtig. Ich störe mich halt an Äußerlichkeiten, ich bin ein Augen-Mensch. Aber im Museum schaue ich ja auch nicht hinter die Bilder, ob die stabil befestigt sind. :)
Ist zwar etwas OT, aber auch mit Blick auf MagiC wurden in EmuTOS einige AES-Erweiterungen eingebaut (Nicelines und Dialogtitel) ;)
-
Prima! Mußte erstmal Suchmaschine bemühen, was "Nicelines" und Dialogtitel sind. Ist zu lange her. Ich mußte direkt mal KAOS und EmuTOS vergleichen, in ST-high.
Und ich habe - nach Thorstens endgültiger Analyse - das vermaledeite GFA-Basic endlich zum Laufen gebracht -- ohne Pätsch! Dabei schwingt immer die Hoffnung mit, daß auch andere Programme davon profitieren. Meistens wird diese Hoffnung enttäuscht.
Technisch: Das Programm schickt per Bconout() zwei Befehle an den IKBD: Eine Joystick-Abfrage, und dann wird die Maus auf den relativen Modus umgeschaltet. Letzteres ist harmlos, aber bei ersterem wartet das Programm auf das Antwortpaket vom IKBD, dafür hängt es sich mit Kbdvecs in die Joystick-Behandlungs-Routine. Ich habe bei der Gelegenheit gleich alle Bcon***()-Aufrufe für IKBD und MIDI an den Emulator geleitet, der kann dann den Interrupt simulieren und die Datenpakete liefern. Ein ziemlicher Aufwand. Unklar ist mir, ob der Atari dann zwei Pakete à zwei Bytes liefert, denn er müßte ja beide Joysticks berücksichtigen. Das "Profibuch" ist hier lückenhaft.
-
[...]
Technisch: Das Programm schickt per Bconout() zwei Befehle an den IKBD: Eine Joystick-Abfrage, und dann wird die Maus auf den relativen Modus umgeschaltet. Letzteres ist harmlos, aber bei ersterem wartet das Programm auf das Antwortpaket vom IKBD, dafür hängt es sich mit Kbdvecs in die Joystick-Behandlungs-Routine. Ich habe bei der Gelegenheit gleich alle Bcon***()-Aufrufe für IKBD und MIDI an den Emulator geleitet, der kann dann den Interrupt simulieren und die Datenpakete liefern. Ein ziemlicher Aufwand. Unklar ist mir, ob der Atari dann zwei Pakete à zwei Bytes liefert, denn er müßte ja beide Joysticks berücksichtigen. Das "Profibuch" ist hier lückenhaft.
Ich werde langsam alt und verliere allmählich die Lust am Sammeln und Benutzen (von Atari-Zeugs) - damit mache ich mittlerweile zu wenig damit. Aber 2025 war für mich ein Atari-Jahr. Atari macht wieder Atari-Dinge und Merch, Der Atari800-Core des MiSTer wurde erwachsen (und weit darüber hinaus), MoL und was-weiß-ich-nicht-noch alles. Zusammengefasst: Atari-Porno pur. Überschwänglich tausend Dank an alle Beteiligten!
-
Unklar ist mir, ob der Atari dann zwei Pakete à zwei Bytes liefert, denn er müßte ja beide Joysticks berücksichtigen. Das "Profibuch" ist hier lückenhaft.
Nein, er schickt ein Paket, bestehend aus 3 Bytes. Das erste Byte ist $fd, die anderen beiden Bytes sind die Status-Daten für die Joysticks (bits 0-3 Directions, bit 7 fire-Knopf wenn ich mich recht erinnere). Für die Status-Daten sollte es momentan reichen, zwei $00-Byte zu schicken, solange nicht wirklich ein Joystick simuliert wird.
Zu beachten ist auch daß Joystick-0 des IKBD eigentlich ziemlich unbrauchbar ist. Wenn der aktiviert wird, ist die Maus ausgeschaltet, und umgekehrt. Das Abfrage-Kommando liefert aber trotzdem beide Bytes.
-
https://www.atari-wiki.com/index.php?title=Keyboard_Protocol#Joystick_Event_Reporting
Das Profibuch ist da offenbar nicht ausreichend. Danke!
-
Doch, das Paket ist da ja auch erklärt. "Joystick Event Reporting" ist allerdings was anderes, das bekäme man bei Senden von 0x14. GFA schickt aber 0x16 Joystick Interrogation (https://www.atari-wiki.com/index.php?title=Keyboard_Protocol#JOYSTICK_INTERROGATE)
-
@AndreasKromke Hallo!
Vielen Dank für die Wiederaufnahme der Entwicklung von MagiC. Ich habe vor mehr als 25 Jahren MagiCMac intensiv benutzt (u. a. hab' ich meine Diplomarbeit damit mit Papyrus auf einer Quadra840AV geschrieben).
Habe jetzt mal die aktuellste Version von MagicOnLinux von gitlab auf macOS Sequoia 15.7.3 auf einem MacBook Air M3 getestet. Funktionierte im großen und ganzen recht problemlos, allerdings sind mir ein paar Dinge aufgefallen:
- In der Anleitung zum compilieren auf macOS (MACOS.txt) fehlt der Hinweis das das sdl2_mixer Paket installiert werden muß. Ohne das scheitert das "cmake -G Xcode .." Kommando ("brew install sdl2" installiert nicht automatisch sdl2_mixer)
- das install_rootfs.sh bricht mit der Fehlermeldung "cp: illegal option -- -" ab, da das cp von macOS die option "--update=none" nicht kennt die im LOCALISE.SH script das von install_rootfs.sh aufgerufen wird das cp zweimal mit dieser Option aufgerufen wird
- in der default-Konfiguration die mit "./Release/magic-on-linux -w" erstellt wird sind die folgenden Zeilen enthalten die dazu führen das die Ausgabe von MagicOnLinux auf das doppelte skaliert wird was etwas komisch aussieht:
atari_screen_stretch_x = 2
atari_screen_stretch_y = 2Nachdem ich den Wert von "2" auf "1" geändert habe ist die Ausgabe wieder normal.
- wenn ich MagicOnLinux starte und dann auf dem Desktop auf das Laufwerk C: klicke und dann über das Menü "File - Information" auswähle und dann versuche die erschienene Dialogbox mittels Cancel zu verlassen crasht MagicOnLinux wie im angehängten Screenshot zu sehen.
Wäre klasse wenn es in Zukunft auch ein App-Bundle für macOS gäbe damit man das Programm wie andere Applikationen vom Desktop aus starten kann.
-
- wenn ich MagicOnLinux starte und dann auf dem Desktop auf das Laufwerk C: klicke und dann über das Menü "File - Information" auswähle und dann versuche die erschienene Dialogbox mittels Cancel zu verlassen crasht MagicOnLinux wie im angehängten Screenshot zu sehen.
"Bytes/Sektor: 1048576" im angezeigten Dialogfeld sieht auch etwas dubios aus. :)
Bei macOS gilt es zu beachten, dass man "f_frsize" als Maßeinheit für Dateisystemblöcke nehmen muss. Unter Linux sind "f_bsize" und "f_frsize" typischerweise gleich, daher fällt das nicht auf. Ich verweise darauf, wie Hatari es letztlich gelöst hat: https://framagit.org/hatari/hatari/-/blob/main/src/gemdos.c#L1694
Leider ist das Hatari-Listen-Archiv down, sodass ich zur diesbezüglichen Diskussion nur auf eine Nachricht auf emutos-devel verweisen kann: https://sourceforge.net/p/emutos/mailman/message/59193055/
-
"Bytes/Sektor: 1048576" im angezeigten Dialogfeld sieht auch etwas dubios aus. :)
Das sieht nicht nur dubios aus, sondern ist vermutlich auch der Grund für den Absturz. Das Text-Feld im Dialog dort ist 4 Zeichen lang, wenn der gelieferte Werte also >= 10000 ist, wird dort irgendwas anderes überschrieben. Sieht man auch am angehängten "ANDR": das ist der magische Wert, der intern von MagiC vor Speicherblöcke gesetzt wird.
Versuch mal bitte angehängte Version von MagxDesk, da sollte das abgefangen sein (gehört nach C:\GEMSYS\GEMDESK, aber aufpassen daß die Resource-Datei nicht beim ändern der Sprache wieder überschrieben wird).
PS.: solange MagicOnLinux unter macOS dort f_bsize liefert, kann es trotzdem sein daß die angezeigten Werte nicht stimmen; aber zumindest sollte es nicht mehr abstürzen).
-
Versuch mal bitte angehängte Version von MagxDesk, da sollte das abgefangen sein (gehört nach C:\GEMSYS\GEMDESK, aber aufpassen daß die Resource-Datei nicht beim ändern der Sprache wieder überschrieben wird).
@Thorsten Otto Danke! Mit dieser Version von MagxDesk tritt der Crash nicht mehr auf.
-
Grüß' euch,
ich bin eher der Freund von europäischen Linux-Distributionen wie openSuse (kommt ja aus Nürnberg),
und daher habe ich versucht, MagicOnLinux auf Leap 16.0 zu installieren.
Dazu habe ich in install-all.sh apt durch zypper ersetzt (gcc und cmake usw. sind standardmäßig auch nicht installiert (ich bin ja lieber Python-Freak ;D):
sudo zypper install cmake gcc gcc-c++ SDL2-devel SDL2_mixer-develDie Installation der Mime-Sachen hat mich bei den Ausgaben etwas "schockiert", hat aber anscheinend funktioniert. Und letztendlich läuft MagicOnLinux auch auf openSuse!
Ich habe MagicOnLinux über die Konsole gestartet, damit man auch alle Ausgaben auf stderr sieht, siehe Anhang...
Dabei ist mir folgendes aufgefallen:
- bei OpenSuse (KDE) gibt es kein gxmessage sondern nur ein xmessage, daher funktionieren die Ausgaben so auch nicht... muss ich mal mit einem symlink versuchen...
- und der shutdown funktioniert nicht, weil der Aufruf C:\GEMSYS\GEMDESK\shutdown.prg lautet... aber das Programm ist im GEMDESK-Ordner in Großbuchstaben (Fehlermeldungen siehe Anhang) oder ist da was anderes im Busch?
-
Und hier auch die aktuellen Warnings/Fehlermeldungen:
-
1. Die Vergrößerung des Atari-Fensters um den Faktor 2 ist für moderne Monitore gedacht. Bei 2,5k- oder 4k-Monitoren sieht man ansonsten den Atari-Bildschirm nur unter einer Lupe. Aber läßt sich ja leicht ändern.
2. Den Hinweis zum sdl2-mixer habe ich ergänzt. Das Paket kam erst später dazu.
3. Bitte versuche, den cp-Parameter "--update=none" zu ersetzen durch "--no-clobber". Wenn das auch nicht geht, dann bitte durch "-n". Dieser Parameter gilt als veraltet. Mein cp hat Version 9.4.
4. Bitte die soeben hochgeladene Version testen, ob der Überlauf in MAGXDESK auch damit behoben ist. Ich denke, eine Änderung der RSC-Datei sollte ausreichend sein. Ich habe es rudimentär getestet.
Und vielen Dank fürs Testen! Obwohl ich noch einen Vorkriegs-Mac stehen habe, bin ich doch leider weit weg von macOS, dafür habe ich derzeit keine Energie.
-
Vielen Dank fürs Testen! Die Log-Dateien sind mMn alle o.B..
Das virtuelle Laufwerk C: ist konfiguriert als 8+3 und "case insensitive", deshalb werden alle Zugriffe erstmal vom Atari-Zeichencode (wegen der anderen Umlaute etc.) in utf-8 und in Großbuchstaben (!) umgewandelt. Du könntest in "config.h" die Zeile "//#define _DEBUG_XFS" noch ent-kommentieren. Dann wirft das XFS massenweise Meldungen raus, die weiterhelfen könnten.
Du könntest mal MCMD starten (Strg-B) und schauen, ob SHUTDOWN.PRG zugreifbar ist.
Oder ob es eine Folge des fehlenden gxmessage ist? Das solltest Du Dir dringend (!) nachinstallieren. Ich habe auch erst mit xmessage experimentiert, weil das vorinstalliert war. Das ist erstens winzigst, also der Text ist etwa drei Millimeter hoch (WTF), und außerdem ist es ziemlich ohnmächtig. Oder machtlos.
Vielleicht würde die ganze Installiererei auch mit etwas cmake-Magie distributionsunabhängig funktionieren, statt ein Shell-Script zu schreiben. Andererseits ist ein Script transparenter, man weiß also immer, was man tut .. oder tun will.
Hier zwei Schirmschüsse von xmessage und gxmessage zum Vergleich - beide unter einer starken Lupe.
-
bei OpenSuse (KDE) gibt es kein gxmessage sondern nur ein xmessage,
Ja, is mir auch schon aufgestossen ;) gxmessage gibt es auf https://trmusson.dreamhosters.com/programs.html#gxmessage, aber leider scheint es kein paket für openSUSE zu geben, auch nicht für TumbleWeed. Oder angehängte Version probieren, sollte sich recht einfach mit
gcc -O2 `pkg-config --cflags --libs gtk+-2.0` -o gxmessage gxmessage.c
übersetzen lassen. gtk+3.0 sollte auch funktionieren. gtk4 allerdings nicht.
-
Ja, is mir auch schon aufgestossen ;) gxmessage gibt es auf https://trmusson.dreamhosters.com/programs.html#gxmessage, aber leider scheint es kein paket für openSUSE zu geben, auch nicht für TumbleWeed.
Nur fürs Archiv: Auch Fedora Desktop hat kein gxmessage.
-
Ich habe jetzt was auf software.opensuse.org für Tumbleweed gefunden und auf mein Leap 16.0 installiert:
zypper addrepo https://download.opensuse.org/repositories/home:jsegitz/openSUSE_Tumbleweed/home:jsegitz.repo
zypper refresh
zypper install gxmessage
damit hat es jetzt funktioniert: beim Beenden per Shutdown kommt jetzt eine Message, auf die ich aber auch gerne verzichten kann... denn MagiConLinuX funktioniert auch ohne gxmessage...
-
WTF! Nach dem erfolgreichen Hinwürgen von GFA-Basic startet jetzt auch Omikron-Basic. Beim ersteren hatte das die angenehme Nebenwirkung, daß ich noch drei (!) Fehler bei selten genutzten Funktionen im XFS gefunden habe. Die Lösung war ein Mock-Joystick. Für Omikron braucht es einen Fake-Shifter-Read-Pointer. Das Sch...programm liest die Register, die vom Shifter ständig geändert werden, und wo kein Shifter, da keine Änderung, und wo keine Änderung, da Endlosschleife. Was sollte der Quatsch damals?
-
Leider gibt es wohl keine Alternative zu gxmessage, die mindestens so gut ist und auf allen Linux-Versionen sofort greifbar. Ich habe damals lange recherchiert und nachgelesen, was es in Richtung xmessage Brauchbares gibt. Andererseits habe ich mich auch schon daran gewöhnt, ein PPA zu installieren, also eine alternative Paketquelle. Dann gibt es auch automatisch Aktualisierungen. Selberbauen ist natürlich etwas mühsam. Auf dem Mac war das alles einfacher, aber ich mußte damals das SDL ändern und selber bauen, weil sonst die Dialoge keine Tastatureingaben gekriegt haben.
-
1. Die Vergrößerung des Atari-Fensters um den Faktor 2 ist für moderne Monitore gedacht. Bei 2,5k- oder 4k-Monitoren sieht man ansonsten den Atari-Bildschirm nur unter einer Lupe. Aber läßt sich ja leicht ändern.
2. Den Hinweis zum sdl2-mixer habe ich ergänzt. Das Paket kam erst später dazu.
3. Bitte versuche, den cp-Parameter "--update=none" zu ersetzen durch "--no-clobber". Wenn das auch nicht geht, dann bitte durch "-n". Dieser Parameter gilt als veraltet. Mein cp hat Version 9.4.
4. Bitte die soeben hochgeladene Version testen, ob der Überlauf in MAGXDESK auch damit behoben ist. Ich denke, eine Änderung der RSC-Datei sollte ausreichend sein. Ich habe es rudimentär getestet.
Und vielen Dank fürs Testen! Obwohl ich noch einen Vorkriegs-Mac stehen habe, bin ich doch leider weit weg von macOS, dafür habe ich derzeit keine Energie.
Vielen Dank für die Rückmeldung.
Zu "3.": bei macOS kennt cp anscheinend grundsätzlich keine langen Optionen (wie z.B. "--update=none"). Ich habe deshalb jetzt das LOCALISE.SH wie folgt geändert:
# Localise MagiC root fs
# Note that this script can be run from anywhere
# TODO: should run recursively
VERBOSE="-v"
#VERBOSE=""
if [ "$#" -eq 1 ]; then
# go to directory where the script resides
cd "$(dirname "$0")"
# convert language code to uppercase
CODE=`echo $1 | tr a-z A-Z`
# check if kernel file already matches
cmp --quiet $CODE/MAGICLIN.OS ../MAGICLIN.OS
STATUS=$?
if [ $STATUS -eq 2 ]; then
echo "LOCALISE.SH: Valid country codes are: "; ls -d ??
exit 1
fi
if [ $STATUS -eq 1 ]; then
# overwrite all programs and kernel
cp $VERBOSE -pf $CODE/MAGICLIN.OS ../
cp $VERBOSE -pf $CODE/GEMSYS/GEMDESK/*.RSC ../GEMSYS/GEMDESK/
cp $VERBOSE -pf $CODE/GEMSYS/GEMDESK/*.PRG ../GEMSYS/GEMDESK/
cp $VERBOSE -pf $CODE/GEMSYS/GEMDESK/*.TXT ../GEMSYS/GEMDESK/
# do not overwrite application database, if exists
cp $VERBOSE -pn $CODE/GEMSYS/GEMDESK/APPLICAT.DAT ../GEMSYS/GEMDESK/ 2>/dev/null
cp $VERBOSE -pn $CODE/GEMSYS/GEMDESK/APPLICAT.INF ../GEMSYS/GEMDESK/
fi
else
echo "usage: LOCALISE.SH DE|EN|FR"
#echo $#
exit 1
fi
Also "--verbose" durch "-v" ersetzt und "--update=none" durch "n". Damit funktioniert das Script jetzt bei mir auf macOS.
Zu "4.": mit der aktuellen Version von MagicOnLinux von Linux tritt der Crash nicht mehr auf. Danke für's fixen!
Btw. bei mir sieht die Ausgabe von cmake etwas anders aus als die die in der MACOS.txt zur Verifizierung angegeben ist:
-- The C compiler identification is AppleClang 17.0.0.17000603
-- The CXX compiler identification is AppleClang 17.0.0.17000603
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /opt/homebrew/bin/pkg-config (found version "2.5.1")
-- Checking for module 'sdl2'
-- Found sdl2, version 2.32.10
-- Checking for module 'sdl2_mixer'
-- Found sdl2_mixer, version 2.8.1
-- Configuring done (5.0s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/<user>/Source/magiclinux/build
Wie du siehst wird da auch sdl2_mixer erwähnt.
-
Prima. Der cp-Befehl könnte entweder veraltet sein, oder er stammt aus einer anderen Quelle, weil macOS ja auch ein BSD-Unix ist und kein Linux.
-
Leider gibt es wohl keine Alternative zu gxmessage, die mindestens so gut ist und auf allen Linux-Versionen sofort greifbar.
Es gibt schon diverse Alternativen (zenity, dialog, yad, whiptail etc.). Ob deren Verfügbarkeit besser ist, weiss ich aber nicht (auf openSUSE gibt es die alle). Evtl. könnte man das auch konfigurierbar machen, da es nur eine zentrale Stelle gibt wo es aufgerufen wird, sollte das machbar sein.
Ich hatte mich auch schon daran versucht, dafür SDL zu verwenden. Müsste prinzipiell möglich sein, da man in SDL2 mehrere Fenster verwalten kann. Allerdings wären dafür einige "Krücken" notwendig (Events von solchen Fenster sollten ja nicht an die Emulation weitergereicht werden). Und das Handling habe ich noch nicht sauber hinbekommen, da Emulation und Graphic in verschiedenen Threads laufen, kann man an der Stelle nicht einfach SDL-Funktionen aufrufen.
-
Leider gibt es wohl keine Alternative zu gxmessage, die mindestens so gut ist und auf allen Linux-Versionen sofort greifbar.
Es gibt schon diverse Alternativen (zenity, dialog, yad, whiptail etc.). Ob deren Verfügbarkeit besser ist, weiss ich aber nicht (auf openSUSE gibt es die alle). Evtl. könnte man das auch konfigurierbar machen, da es nur eine zentrale Stelle gibt wo es aufgerufen wird, sollte das machbar sein.
Was ist denn mit AppleScript bzw. osascript? Das ist auf jedem Mac vorinstalliert.
-
Ich habe alles mögliche, wenn auch nicht alles Mögliche, zu gmessage-Alternativen gelesen, und bisher hat mich nichts wirklich überzeugt. Es ist schon bescheuert, daß es nicht so etwas Banales wie eine "Alert Box" gibt. Vermutlich ist Apple Script die eleganteste und hübscheste Option, aber gibt es leider nicht für Linux. Alle Aufrufe sind übrigens in gui.cpp, also wenn jemand experimentieren möchte...
OT: Die Versionsnummern sind noch etwas chaotisch. Die des Emulators ändere ich nur nach Lust und Laune. Der Kernel hat zwei Versionsnummern: Die Version 6.21 vom Dezember ist quasi die AES-Version, die werde ich nicht jedesmal (ein heute verbotenes Wort ...) ändern. Die andere kriegt Ihr über die Kontrollfelder, die sollte immer stimmen.
PS: Die erstere Version gibt's auch im Kontrollfeld "MagiC-Konfig".
-
Ich habe alles mögliche, wenn auch nicht alles Mögliche, zu gmessage-Alternativen gelesen, und bisher hat mich nichts wirklich überzeugt. Es ist schon bescheuert, daß es nicht so etwas Banales wie eine "Alert Box" gibt. Vermutlich ist Apple Script die eleganteste und hübscheste Option, aber gibt es leider nicht für Linux. Alle Aufrufe sind übrigens in gui.cpp, also wenn jemand experimentieren möchte...
Bin jetzt nicht so der Programmierer aber was von meiner Ausbildung als FiSi hängen geblieben ist sind Macros. Was wäre denn mit __APPLE_ und __linux__? Also sowas wie:
if __APPLE
osascript("Dolle Nachricht");
elif __linux__
gxmessage("Dolla Nachricht");
else
printf("Wat? Windows?");
endif
-
4. Bitte die soeben hochgeladene Version testen, ob der Überlauf in MAGXDESK auch damit behoben ist. Ich denke, eine Änderung der RSC-Datei sollte ausreichend sein. Ich habe es rudimentär getestet.
... damit die Werte des HostXFS-Dfree allerdings richtig sind, solltest Du m.E. auch die richtige Blockgröße ("f_frsize") nutzen.
-
f __APPLE
osascript("Dolle Nachricht");
elif __linux__
gxmessage("Dolla Nachricht");
else
printf("Wat? Windows?");
endif
Sowas ähnlich wird schon gemacht. Problem ist halt daß __linux__ nicht unbedingt heisst daß gxmessage verfügbar ist.
-
f __APPLE
osascript("Dolle Nachricht");
elif __linux__
gxmessage("Dolla Nachricht");
else
printf("Wat? Windows?");
endif
Sowas ähnlich wird schon gemacht. Problem ist halt daß __linux__ nicht unbedingt heisst daß gxmessage verfügbar ist.
Wie gesagt, ich bin kein Programmierer aber kann man nicht prüfen ob ein Tool vorhanden ist? Ich Stelle mir das ungefähr so vor:
ret = exec("gxmessage");
Wenn ret alles andere als 0 ist, dann ist es nicht vorhanden. So mach ich das in meinen bash scripts auf der Arbeit. Das gibt es mit Sicherheit auch in C.
Vielleicht wäre GTK ne Lösung, ist für eine Dialogbox erstmal ziemlicher Overkill aber für eine spätere GUI könnte das hilfreich sein.
-
Wenn ret alles andere als 0 ist, dann ist es nicht vorhanden.
Naja, nicht ganz. Wenn es vorhanden ist, liefert das Werte ab 101, je nachdem mit welchem Button der Dialog beendet wurde. Aber man könnte das prüfen, ja. Fragt sich nur welche Alternative man dann nimmt.
Hab mir mal ein paar Sachen angeschaut, aber entweder bin ich zu blöd die Man-Page zu lesen, oder die Programme sind einfach zu doof. Bei Zenity hab ich es jedenfalls nicht hinbekommen, die Button-Texte so zu ändern wie MagicOnLinux das haben will. Yad ist auch nicht viel besser. Ausserdem muss ich Andreas zustimmen, die Dialoge sehen grauenvoll aus (Buttons sind die meiste Zeit doppelt so gross wie der Text).
Vielleicht wäre GTK ne Lösung
gxmessage ist ja mit GTK gebaut.
-
Griaß eich,
wenn ich in der bash prüfen will, ob ein Programm/Script überhaupt ausführbar ist, verwende ich meist
if [[ -x "$file" ]]und wenn ich das Programm überhaupt suche, weil ich nicht weiß, wo es liegt, verwende ich z.B.
whereis gxmessagelg, fichti
-
ich habe heute auch noch wegen gxmessage herumgesucht und probiert, aber auch nix brauchbareres gefunden...
was mir aber bei gxmessage aufgefallen ist:
- wenn ich jetzt per shutdown beenden will, bleibt das Fenster "stecken"...schaut aus wie Absturz, ist es aber nicht!
- erst wenn man das Fenster zur Seite schiebt, sieht man ein Mini-Fenster von gxmessage,
das ich erst auch mal vergrößern muss, um den ganzen Text lesen zu können... - und wenn man dann dort auf OK klickt, beendet sich dann MagicOnLinux
das ist also auch nicht das Gelbe vom Ei... ohne gxmessage brauche ich nicht erst das Fenster "suchen" und OK klicken...
den Text kann man zuerst auch nicht zur Gänze lesen, da muss man erst dieses gxmessage-Fenster vergrößern...
-
@AndreasKromke: vom M-Laufwerk bin ich total begeistert!!!
Ich brauche nix herumkopieren, sondern kann z.B. auf meiner NAS direkt auf ein Backup von meinem Hades060 (der leider nicht mehr startet) zurückgreifen und ein paar Programme testen.
- Calamus SL99 läuft, kann aber größere Dokumente wegen fehlendem Speicherplatz nicht öffnen...
ein Klacks, sofort über die config von 8MB auf 32MB eingestellt... alles paletti! - Scooter-PCB will auch nur maximal 256 Farben, und auch das geht über die Config und alles läuft wieder rund!
-
Das Aussehen der gxmessage-Dialoge scheint vom Linux abhängig zu sein. Ich habe lange mit Leerzeichen herumprobiert, bis es bei mir ordentlich aussah. Ist also quasi ein Hack für Ubuntu.
-
Das Aussehen der gxmessage-Dialoge scheint vom Linux abhängig zu sein. Ich habe lange mit Leerzeichen herumprobiert, bis es bei mir ordentlich aussah. Ist also quasi ein Hack für Ubuntu.
Bei mir sieht es ganz normal aus. Ich benutze LMDE 7 mit dem Mate Desktop.
-
Hängt vermutlich davon ab, welches Widget-Theme GTK benutzt. Bei mir sieht es auch ok aus, und ich benutze oxygen-gtk. @fichten: könntest du mal nachschauen was bei dir eingestellt ist? Und welche GTK version dein gxmessage benutzt (GTK2 oder 3)?
-
Guten Morgen,
gxmessage baut laut spec-File: BuildRequires: intltool pkg-config gtk3-devel
und das Oxygen-Theme gibt's laut zypper nur für gtk2
standardmäßig ist als Theme gtk3-branding-openSUSE installiert, daran wird es wohl liegen...
Das soll aber keinesfalls ein showstopper für mich sein, da ich diese Meldung beim Shutdown nicht wirklich brauche. Und sonst ist mir bis jetzt keine andere Message aufgefallen... Wenn ich nach einer Fehlermeldung suche, dann starte ich MagiC einfach über die Konsole...
lg, markus
-
if __APPLE
osascript("Dolle Nachricht");
elif __linux__
gxmessage("Dolla Nachricht");
else
printf("Wat? Windows?");
endif
So ähnlich sieht es tatsächlich in "gui.cpp" aus.
-
- Scooter-PCB will auch nur maximal 256 Farben, und auch das geht über die Config und alles läuft wieder rund!
Du könntest Dir sogar ein shell script schreiben, à la
magic-on-linux -g 256 <path>/SCOOTER.PRG
-
Ich denke, ich habe alle wesentlichen Änderungen für macOS jetzt eingepflegt. Vielen Dank für die ausführliche Fehlersuche!
-
und das Oxygen-Theme gibt's laut zypper nur für gtk2
Stimmt. gtk-3 benutzt Breeze bei mir. Dialoge sehen aber trotzdem ok aus. Einstellung müsste in
~/.config/gtk-3.0/settings.ini stehen.
da ich diese Meldung beim Shutdown nicht wirklich brauche.
Ich beende es einfach indem ich das Fenster schliesse. Dann kommt die Meldung erst gar nicht.
Und sonst ist mir bis jetzt keine andere Message aufgefallen...
Gibt auch nur wenige Stellen an denen das passieren könnte. Eine ist gleich beim Start, wenn der Kernel nicht gefunden wird, oder falsche Version hat. Sollte normalerweise nicht auftreten, sobald es einmal läuft.
Die einzige wichtige Stelle ist wohl momentan wenn ein ST-Disk-Image gemountet werden soll. Dann würde eine Frage kommen, welches Floppy-Laufwerk benutzt werden soll, und ob read-only oder nicht.
-
[Hier stand Unsinn, ich hatte wohl die falsche Quelle konsultiert]
Etwas OT:
Ich habe ein Testprogramm namens ADR.PRG, das auf dem Atari einen Adreßfehler provoziert, damit man die drei Bömbchen bewundern kann. Das Programm hatte ich damals extra so geschrieben, daß es nicht einen Datenzugriff auf eine ungerade Adresse macht, denn das kann der 68020, sondern auf eine ungerade Adresse springt. Also müßte der Emulator hier einen Adreßfehler liefern. Daß er das nicht macht, ist ein Fehler.
-
Tatsächlich kann aber der 68020 wohl nicht nur auf ungerade Adressen zugreifen, sondern sogar Code von ungeraden Adressen ausführen.
Das 68020UM sieht das anders:
-
Tatsächlich kann aber der 68020 wohl nicht nur auf ungerade Adressen zugreifen, sondern sogar Code von ungeraden Adressen ausführen.
Nein, kann er nicht. Darum versucht das Test-Programm ja auch, auf eine ungerade Addresse zu springen. Das führt auch auf 68020+ immer noch zu einem Address-Fehler (wobei ich mir gerade nicht sicher bin, welche Addresse dann als Exception-Address im frame auftaucht, aber ein Address-Frame ist sowieso sehr viel anders als alle anderen)
Preis-Frage ist natürlich auch, ob man das im Emulator abfangen muss. Für korrekte Emulation wäre das aber nötig.
-
Richtig. Ich hatte Unsinn geschrieben.
-
OT: Die Versionsnummern sind noch etwas chaotisch. Die des Emulators ändere ich nur nach Lust und Laune. Der Kernel hat zwei Versionsnummern: Die Version 6.21 vom Dezember ist quasi die AES-Version, die werde ich nicht jedesmal (ein heute verbotenes Wort ...) ändern. Die andere kriegt Ihr über die Kontrollfelder, die sollte immer stimmen.
Man könnte die andere natürlich auch im About-Dialog anzeigen. Ist nur die Frage ob das nicht zu verwirrend ist, wenn die unterschiedlich sind? (wäre im moment bei der Version die ich baue, auch der Fall)
-
Schade, MagicOnLinux läuft leider nicht auf meinem 3.-Liebsten Betriebssystem, HaikuOS. GCC schmeißt beim HostXFS ettliche Fehler :(
-
Welche Linux Versionen bieten sich am besten an?
-
Welche Linux Versionen bieten sich am besten an?
Aus dem Bauch heraus, alles was Debian als Unterbau hat. @goetz @ 3rz hat zwar bestätigt dass es auch mit rpm Distros geht aber da kenne ich mich zu wenig mit aus
-
Ubuntu/Debian sollte auf jeden Fall gehen. openSUSE Leap/Tumbleweed wurde auch schon von ragnar und mir getestet (allerdings funktionieren dann momentan die neuen install-* Scripte noch nicht, bzw. musst du die apt-Kommandos auskommentieren und die notwendigen Pakete vorher selber installieren). Für andere dürfte das gleiche zutreffen.
-
Aus dem Bauch heraus, alles was Debian als Unterbau hat. @goetz @ 3rz hat zwar bestätigt dass es auch mit rpm Distros geht aber da kenne ich mich zu wenig mit aus
äh, wus? Ich schrieb, dass Fedora ohne gxmessage daherkommt. Ich bekam MoL unter Fedora noch nicht gebaut (aber auch noch nicht allzuviel Zeit investiert). Also keine positive Bestätigung von mir (leider).
-
Ich bekam MoL unter Fedora noch nicht gebaut (aber auch noch nicht allzuviel Zeit investiert)
Ich jetzt schon ;) funktioniert im Prinzip, bis auf die schon erwähnten kleineren Probleme (kein gxmessage z.B.). Beim Start bekomme ich aus irgendeinem Grund noch eine Fehler-Meldung daß winframe.rsc nicht gefunden wurde. Die Datei ist aber da, hab noch kA. woran das liegt. Ausserdem kommen auf der console noch ein paar merkwürdige Fehlerdungen die ich noch nicht einordnen kann:
libEGL warning: failed to get driver name for fd -1
libEGL warning: MESA-LOADER: failed to retrieve device information
libEGL warning: failed to get driver name for fd -1
MESA: error: ZINK: failed to choose pdev
libEGL warning: egl: failed to create dri2 screen
Könnte aber daran liegen daß ich es unter VirtualBox laufen habe, und dort kein 3D aktiviert ist.
Übersetzen hat aber ohne Anstand funktioniert (sofern man vorher alle notwendigen Pakete installiert).
Die neuen installl-* scripts bedürfen aber noch ein paar Anpassungen (yum statt apt etc.)
Edit: die Fehlermeldungen auf der Konsole kommen wohl daher, daß Fedora den Wayland-Server benutzt. Allerdings lässt er sich scheinbar nicht mehr so einfach über /etc/gdm/custom.conf deaktivieren.
-
Beim Start bekomme ich aus irgendeinem Grund noch eine Fehler-Meldung daß winframe.rsc nicht gefunden wurde.
Das lag nicht an Fedora. Es wird irgendwie durch die MAGX.INF verursacht, die ich vorinstalliere. Die kommt von https://github.com/th-otto/MagicMac/blob/master/apps/instmagc/magx_lin.inf. Sobald ich den Emulator gestartet habe, und "Arbeit sicher", ist der Fehler verschwunden. Irgendeine Idee was die Ursache sein könnte?
Was mir aber noch aufgefallen ist: die Alert-Box kommt gleich beim Start, noch bevor MagXDesk gestartet ist, und lässt sich nicht über die Maus bedienen. Das scheint auch von Wayland verursacht zu werden, auf meinem System (mit "richtigem" X-Server) ist das nicht so.
BTW, die Linux-Archive auf https://tho-otto.de/snapshots/magicmac/ habe ich nun umsortiert, sodaß sie dem Layout von Andreas entsprechen (alles Sprach-Abhängige ist im LANG/ Ordner). Das heisst aber auch, daß man den Emulator einmal mit --lang=DE aufrufen muss, nachdem man das Archiv installiert hat.
Ich überlege gerade, ob man die Programme nicht vlt. besser anpasst, daß sie die Resource-Dateien gleich aus dem LANG-Ordner laden, dann würde diese Umkopiererei entfallen, und man hätte den gleichen Effekt auch auf Atari, ohne Emulator.
-
Ich jetzt schon ;) funktioniert im Prinzip, bis auf die schon erwähnten kleineren Probleme (kein gxmessage z.B.).
Soweit kam ich nicht …
Übersetzen hat aber ohne Anstand funktioniert (sofern man vorher alle notwendigen Pakete installiert).
Hmm … Dann fehlte mir wohl außer gxmessage noch was, was ich nicht fand. Mea culpa.
Edit: die Fehlermeldungen auf der Konsole kommen wohl daher, daß Fedora den Wayland-Server benutzt. Allerdings lässt er sich scheinbar nicht mehr so einfach über /etc/gdm/custom.conf deaktivieren.
Aaah. Ja, der Grund Fedora zu nutzen ist u.a. die gute Wayland-Integration. Meine Grafik wird von X11 nicht beschleunigt unterstützt, mit Wayland ist das dagegen kein Problem. Ich hatte vorher Mint auf der Maschine, das war kaum auszuhalten unschwuppdich.
-
Mit etwas Handarbeit läuft MoL jetzt auch als MagicOnMacOS (aarm64) auf MacOS 15.7.3. Danke, @AndreasKromke! Sehr schön, das wieder zu haben, und so schnell.
@AndreasKromke, würdest du Patches annehmen, wenn ich einmal queerbeet versuche, den Schreibweisenwildwuchs (MAGXDESK↔︎MagiCDesk; MagicOnLinux↔︎MagiC …) einzukürzen? Wie soll’s denn heißen? Magic, weil du es so in MagicOnLinux genannt hast?
-
Kannst du bei dir den normalen X-Server aktivieren? Ich hatte irgendwo gelesen, daß man dafür gnome-session-xsession installieren muss (und natürlich den Xorg Server), aber das Paket gibt es scheinbar gar nicht mehr (hab die aktuell version genommen, Fedora 43 Workstation)
-
Und noch eine Kleinigkeit in MagxDesk geändert: im About -Dialog wird jetzt statt des AES-Datums das von MagicOnLinux angezeigt:
Edit: ja ich weiss, Datum ist falschrum ;) ist schon berichttigt, war nur zu faul einen neuen Screenshot zu machen.
-
Kannst du bei dir den normalen X-Server aktivieren?
Würd ich gern vermeiden, weil ich mir grad mein Mint zersägt hatte, beim Versuch entweder unter Mint/Wayland die Tastaturbelegung richtig zu bekommen, oder die Mint/X11 Variante beschleunigt. :) Brauch erstmal Platz für einen Snapshot oder einen Klon. Sorry.
-
Ich habe als Laufwerk D einen lokalen Pfad angegeben:
atari_drv_D = 4 /Users/goetz/Emulation/ST/C
Klicke ich dann unter MacOS 15.7.3 in MagiCDesk auf "D:" und drücke TAB, meldet zweimal MagiCDesk "Pfad nicht gefunden -34", zeigt dann aber doch den Dialog an:
Der Pfad enthält ein mittelmäßig gefülltes "Atari"-Laufwerk, wäre also prinzipiell ermittelbar. Dass MagiCDesk nichts an Inhaltsinfos anzeigt, liegt am HostFS?
-
Anscheinend stört man sich an der inkonsistenten Benamsung von Programmen und Dateien - zu Recht. Als erste Maßnahme heißt die Konfigurationsdatei jetzt wie das Programm, also "magic-on-linux.conf".
Eigentlich wollte ich aber die tausend Probleme lösen, auf die ich bei einer Probeinstallation auf einem anderen Rechner gestoßen bin. Ich kapiere immer noch nicht, wann man "index.theme" braucht und wann nicht und wie man das automatisch aktualisieren soll. Auf dem einen Rechner war es jedenfalls nötig, auf dem anderen nicht. Und außerdem mag das bekloppte "xdg-icon-resource" keine Vektorbilder. Das ist so bescheuert, daß es schon beschäuert ist. Also entweder von Hand reinkopieren oder in .png wandeln. Alles viel zu kompliziert. Ich werde jedenfalls die neuen Skripte selber nochmal testen müssen.
Was bisher noch niemandem aufgefallen ist: Beim ersten Start, wenn die conf-Datei geschrieben wurde, fand er seinen Kernel nicht. Da hilft nur testen, testen, testen.
-
Klicke ich dann unter MacOS 15.7.3 in MagiCDesk auf "D:" und drücke TAB, meldet zweimal MagiCDesk "Pfad nicht gefunden -34", zeigt dann aber doch den Dialog an:
Da könnten versteckte kranke Dateien liegen, an denen er sich stört. Mglw. zeigt die Debug-Version mehr an, wenn Du die Debug-Meldungen einschaltest. Vielleicht ist das XFS auch noch zu pingelig und sollte z.B. böse Dateien einfach überspringen bei Dreaddir().
-
Da könnten versteckte kranke Dateien liegen, an denen er sich stört.
Vermutlich mal wieder diese ominösen .DS_Store Dateien, die der Finder immer und überall anlegt. Die passen halt nicht ins 8.3 Schema. Vlt. sollte man die (zumindest auf macOS) im XFS ausfiltern. Auf jeden Fall aber auf DOS-Verzeichnissen wie C: zB.
-
Meiner ist etwa 20mal so schnell wie Hatari und etwa so schnell wie Aranym ohne JIT. Aranym-jit ist unerreicht, etwa 20- bis 40mal so schnell wie meiner.
Wäre die Unicorn-Engine (https://www.unicorn-engine.org/) evtl. eine Alternative für MagicOnLinux? Da wäre auch JIT dabei, sollte also ähnlich schnell wie Aranym sein...
-
Da könnte man auch gleich QEMU nehmen. Wäre aber totaler Overkill, MagicOnLinux will ja nicht zig CPUs emulieren, sondern nur m68k.
Und QEMU ist (auch mit JIT) immer noch um Grössenordnungen langsamer als Aranym.
-
Etwas überflüssiges Wissen:
- KAOS ist ein Wortspiel aus "Kromke Andreas Operating System" und der Verbrecherorganisation aus der US-amerikanischen Serie "Get Smart" (siehe https://getsmart.fandom.com/wiki/KAOS)
- MagiX war ein Akronym von "Multi Application Graphical Interface eXtension".
- Wegen Namensgleichheit mit dem Programm MAGIX mußten wir das ändern in Mag!X ..
- .. und später dann in MagiC.
Deshalb haben einige Programme noch ein "MAGX" im Dateinamen.
Im Fenstertitel sollte eigentlich "MagiConLinux" stehen, das sieht aber aus wie "Magi-Con-Linux". Der Titel "magic-on-linux" ist häßlich, und dann bliebe noch "MagiCOnLinux", was auch saise aussieht.
-
Schade, MagicOnLinux läuft leider nicht auf meinem 3.-Liebsten Betriebssystem, HaikuOS. GCC schmeißt beim HostXFS ettliche Fehler :(
Ein paar der Sachen lassen sich relativ leicht beheben (gleiches Problem wie bei macOS).
Was aber fehlt ist eine Funktion die zu einem Filehandle den Pfad ermittelt. Für linux/macOS wird dazu fcntl(F_GETPATH) verwendet. Das ist aber wenig portable, und würde wohl auch bei anderen Ports (Windows zb.) zu Schwierigkeiten führen. Für Haiku habe ich noch nichts entsprechendes gefunden.
Wenn du Lust hast, kannst du dich ja mal an https://github.com/th-otto/MagicOnLinux/tree/my versuchen. Ist soweit geändert daß es unter Haiku kompiliert, funktioniert aber noch nicht wegen den erwähnten Problemen.
Als Pakete werden (mindestens) cmake libsdl2_devel sdl2_mixer_devel benötigt.
gxmessage gibt es dort natürlich auch nicht. Die Version in src/gui/gxmessage lässt sich aber mit GTK3 bauen. Evtl kann man aber auch was Haiku-Spezifisches nehmen, ähnlich wie bei macOS.
-
MagiX war ein Akronym von "Multi Application Graphical Interface eXtension".
Danke, das war mir neu.
Ich war anno 199…2? auf einer Atari-Messe und einer der Behnes führte Mag!X vor, v.a. den Taskmanager. War noch kooperativ, damals.
Leider hatte ich als Schüler kein Geld :-/ Es dauerte noch ca. ein Jahr, bis ich MagiC bekam. Nach einer seeehr kurzen Periode mit MultiTOS (gäääähn, auf einem 16 MHz-Rechner), war das die Offenbarung für MultiTeX, Papyrus, Texel, Pure C, CAT, CoNnect, X-Act.
Im Fenstertitel sollte eigentlich "MagiConLinux" stehen, das sieht aber aus wie "Magi-Con-Linux". Der Titel "magic-on-linux" ist häßlich, und dann bliebe noch "MagiCOnLinux", was auch saise aussieht.
Haha, Magi-Con-Linux würde ja erlauben, die Mac- oder Haiku-Version dann Magi-Sin-Linux zu nennen. Aber Spaß beiseite: Welchen Namen/Schreibweise hätten’s gern, damit wir das mal glattziehen können?
Ich glaube Helli wird wegen MagiX nicht mehr meckern …
-
KAOS ist ein Wortspiel aus "Kromke Andreas Operating System"
Das hatte ich mir gedacht...
und der Verbrecherorganisation aus der US-amerikanischen Serie "Get Smart" (siehe https://getsmart.fandom.com/wiki/KAOS)
... und das nicht. Obwohl ich Get Smart natürlich immer gerne gesehen habe.
Im Fenstertitel sollte eigentlich "MagiConLinux" stehen, das sieht aber aus wie "Magi-Con-Linux". Der Titel "magic-on-linux" ist häßlich, und dann bliebe noch "MagiCOnLinux", was auch saise aussieht.
Warum überhaupt magic-on-linux? Es hiess ja auch nur MagiCMac und MagiCPC. Warum nicht einfach MagiCLinux?
Oh, ich habe es gerade recherchiert - es gibt schon eine Linux Distro die so heisst.
Da "MagiC-on-Linux" ja auch bereits auf Macs läuft und möglicherweise bald auch Haiku, wäre etwas generisches sinnvoller. Da du die Sourcen unter die GNU GPLv3 gestellt hast vielleicht "GnuMagiC"?
-
kein Kommentar
-
Schade, MagicOnLinux läuft leider nicht auf meinem 3.-Liebsten Betriebssystem, HaikuOS. GCC schmeißt beim HostXFS ettliche Fehler :(
Wenn du Lust hast, kannst du dich ja mal an https://github.com/th-otto/MagicOnLinux/tree/my versuchen. Ist soweit geändert daß es unter Haiku kompiliert, funktioniert aber noch nicht wegen den erwähnten Problemen.
Bauen tuts fein, keine Warnung oder Error. Allerdings kommt dann im Betrieb ein schwarzer Bildschirm. Das was auf der Konsole ausgespuckt wird ist im Anhang
gxmessage gibt es dort natürlich auch nicht. Die Version in src/gui/gxmessage lässt sich aber mit GTK3 bauen. Evtl kann man aber auch was Haiku-Spezifisches nehmen, ähnlich wie bei macOS.
gxmessage habe ich noch nicht probiert, es läuft ja auch ohne.
-
Allerdings kommt dann im Betrieb ein schwarzer Bildschirm.
Ja, wie gesagt, kompiliert, aber funktioniert noch nicht. Es wird mindestens noch ein Ersatz für fcntl(F_GETPATH) benötigt (oder es muss so umgestrickt werden, daß man das nicht braucht, evtl. müsste dazu der Pfadname in der HostFD Struktur gespeichert werden). Ohne das funktioniert Fsfirst()/Fsnext() nicht, und damit wird auch der Bildschirmtreiber nicht gefunden, deswegen schwarzer Bildschirm.
Kenne mich aber eigentlich mit Haiku nicht besonders aus, hatte vor Jahren mal was damit gemacht, aber musste mir jetzt auch wieder einiges zusammen suchen.
War aber spannend zu sehen, daß es tatsächlich noch möglich ist, moderne Betriebssystem zu bauen, die in wenigen Sekunden booten.
-
Da könnte man auch gleich QEMU nehmen. Wäre aber totaler Overkill, MagicOnLinux will ja nicht zig CPUs emulieren, sondern nur m68k.
Nein, der Gag an Unicorn ist ja, dass das als Library kommt, die auch schon bei vielen Distros einfach vorcompiliert dabei ist. D.h. es wäre einfach ein bequemer Ersatz für den CPU-Kern, ohne dass man sich mit den QEMU-Sourcen auseinandersetzen muss.
Und QEMU ist (auch mit JIT) immer noch um Grössenordnungen langsamer als Aranym.
Sollte trotzdem noch deutlich schneller sein als ohne JIT.
-
Beim Start bekomme ich aus irgendeinem Grund noch eine Fehler-Meldung daß winframe.rsc nicht gefunden wurde.
Hat sich auch geklärt. Ich hatte natürlich meine lokale Kopie von WINFRAME.SLB in das Verzeichnis kopiert, und das hatte das SLB-Flag (bit 3 im Header) nicht gesetzt, wodurch kein Speicher für die Resource-Datei frei war :(
Müsste man evtl. auch mal in Slbopen fixen, daß dieses Bit automatisch angenommen wird. Oder die libs fixen, daß sie selber einen Mshrink() machen, so wie andere Programme auch.
-
Klicke ich dann unter MacOS 15.7.3 in MagiCDesk auf "D:" und drücke TAB, meldet zweimal MagiCDesk "Pfad nicht gefunden -34", zeigt dann aber doch den Dialog an:
Da könnten versteckte kranke Dateien liegen, an denen er sich stört. Mglw. zeigt die Debug-Version mehr an, wenn Du die Debug-Meldungen einschaltest. Vielleicht ist das XFS auch noch zu pingelig und sollte z.B. böse Dateien einfach überspringen bei Dreaddir().
Ja:
(16:00:50) DBG-WRN hostpath2HostFD() : fstatat("BUERO/PAPYRUS.X/VORLAGEN/PRA_SENTATIONSGRAFIK/") -> No such file or directory
mMn sollte sowas nicht als Warndialog an den Nutzer gemeldet werden, denn ohne Angabe was und wo kann er damit nichts anfangen.
-
fstatat("BUERO/PAPYRUS.X/VORLAGEN/PRA_SENTATIONSGRAFIK/") -> No such file or directory
Ob das etwas mit der "decomposed utf-8"-Apple-Krankheit zu tun hat? Versüch's mäl öhne Ümläute.
-
fstatat("BUERO/PAPYRUS.X/VORLAGEN/PRA_SENTATIONSGRAFIK/") -> No such file or directory
Ob das etwas mit der "decomposed utf-8"-Apple-Krankheit zu tun hat? Versüch's mäl öhne Ümläute.
Ohne Umlaut gibt’s keinen Fehler.
-
Ohne Umlaut gibt’s keinen Fehler.
Wenn Du Dir die Mühe machen möchtest, könntest Du Dich hier einlesen: [https://stackoverflow.com/questions/6153345/different-utf8-encoding-in-filenames-os-x]. Und schau mal, ob hier das Problem liegt.
Ich weiß schon, warum ich mich auf Linux/Ubuntu beschränkt habe. Dieser Unix-Wildwuchs ist lästig, das wäre trotz meiner Abneigung in Windows besser, da läuft es dann gleich überall.
PS: Das gleiche Problem hatte ich bei Android, wo ich nämlich Antonín Dvořák zweimal hatte, und beide sahen völlig gleich aus. Ich habe dann die Komponistendatenbank normalisiert, um Dubletten zu vermeiden. Unter Android bzw. Java gibt es dafür irgendwelche gruseligen Funktionen.
-
Wenn Du Dir die Mühe machen möchtest, könntest Du Dich hier einlesen: [https://stackoverflow.com/questions/6153345/different-utf8-encoding-in-filenames-os-x]. Und schau mal, ob hier das Problem liegt.
Ich kann bestätigen, dass mac OS decomposed UTF-8 nutzt. Ändern kann ich das bei mac OS nicht – ich könnte nur als Würgumher regelmäßig ein Script über meinen Pfad laufen lassen, der alle Umlaute ä -> a etc. verbiegt.
Ich weiß schon, warum ich mich auf Linux/Ubuntu beschränkt habe. Dieser Unix-Wildwuchs ist lästig, das wäre trotz meiner Abneigung in Windows besser, da läuft es dann gleich überall.
Äh, sicher? Windows (2k und neuer) nutzt UTF-16 (https://stackoverflow.com/questions/2050973/what-encoding-are-filenames-in-ntfs-stored-as), nicht UTF-8. Und selbst das mußt du im Code umständlich ankündigen, zumindest bis Windows 8 konnte ein schlichtes fopen kein Unicode.
-
Windows unterstützt UTF-16 schon mindestens seit win32s. Und man kann die Funktionen auch direkt aufrufen (_wfopen etc.). D.h. man kann auch einfach kleine Wrapper schreiben, die utf-8 in UTF-16 wandeln, und die entsprechenden Funktionen dann umbiegen.
Für Windows gibt es allerdings momentan noch ein anderes Problem: die ganzen fopenat(), statat() etc. Funktionen sind dort nicht verfügbar. Die müsste man erst nachbilden.