Hardware > Emulatoren

AtariX => MagicOnLinux

<< < (39/40) > >>

AndreasKromke:

--- Zitat von: RealLarry am Gestern um 11:22:37 ---Gute Idee! Vorhin beides ausprobiert, aber immer noch die selbe Fehlermeldung.

--- Ende Zitat ---
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.

RealLarry:
Top, danke! Das krisch' hin. Ich geb dann die Tage laut...

ragnar76:
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).

Thorsten Otto:

--- Zitat von: ragnar76 am Gestern um 15:09:05 ---in C:\AUTO\ACCS kopiert (warum die da liegen und nicht auf c:\ weiss ich auch nicht)

--- Ende Zitat ---

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

--- Code: ---#_ACC C:\AUTO\ACCS\

--- Ende Code ---

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 ;)

AndreasKromke:
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".

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete