Hardware > Emulatoren
AtariX => MagicOnLinux
don_apple:
--- Zitat von: Thorsten Otto am Mo 19.01.2026, 18:44:34 ---Versuchs mal damit:
--- Code: ---diff --git a/src/MagiC.cpp b/src/MagiC.cpp
index bf77758..ba0684d 100644
--- a/src/MagiC.cpp
+++ b/src/MagiC.cpp
@@ -139,7 +139,7 @@ void getActAtariPrg(const char **pName, uint32_t *pact_pd)
static inline void OS_CreateCriticalRegion(pthread_mutex_t *criticalRegion)
{
//DebugInfo2("(%p)", criticalRegion);
- *criticalRegion = PTHREAD_MUTEX_INITIALIZER;
+ pthread_mutex_init(criticalRegion, nullptr);
}
@@ -213,9 +213,9 @@ CMagiC::CMagiC()
m_EventId = 0;
m_InterruptEventsId = 0;
- m_KbCriticalRegionId = PTHREAD_MUTEX_INITIALIZER;
- // m_AECriticalRegionId = PTHREAD_MUTEX_INITIALIZER; // remnant from MagicMac(X) and AtariX
- m_ScrCriticalRegionId = PTHREAD_MUTEX_INITIALIZER;
+ pthread_mutex_init(&m_KbCriticalRegionId, NULL);
+ // pthread_mutex_init(&m_AECriticalRegionId, NULL); // remnant from MagicMac(X) and AtariX
+ pthread_mutex_init(&m_ScrCriticalRegionId, NULL);
//m_iNoOfAtariFiles = 0; // remnant from MagicMac(X) and AtariX
m_pKbWrite = m_pKbRead = m_cKeyboardOrMouseData;
@@ -236,9 +236,9 @@ CMagiC::CMagiC()
m_bEmulatorIsRunning = false;
// inter-thread synchronisation
- m_EventMutex = PTHREAD_MUTEX_INITIALIZER;
- m_ConditionMutex = PTHREAD_MUTEX_INITIALIZER;
- m_Cond = PTHREAD_COND_INITIALIZER;
+ pthread_mutex_init(&m_EventMutex, NULL);
+ pthread_mutex_init(&m_ConditionMutex, NULL);
+ pthread_cond_init(&m_Cond, NULL);
atomic_init(&gbAtariVideoBufChanged, false);
}
--- Ende Code ---
BTW: bin mir nicht ganz sicher ob pthread_mutex_destroy() auf linux überhaupt was macht, aber ein entsprechender Aufruf fehlt auf jeden Fall. In Windows erzeugt pthread_mutex_init() auf jeden Fall ein HANDLE.
--- Ende Zitat ---
Vielen Dank!
Mit diesen Änderungen compiliert es jetzt auch auf macOS Ventura (13.7.8 ) ohne Fehler.
AndreasKromke:
--- Zitat von: goetz @ 3rz am So 18.01.2026, 09:57:31 ---Gibt‘s etwas, was ich in der Konfiguration tun kann, damit der Task-Manager von MagiC lesbar wird? Ich nutze derzeit 256 Farben, NVDI 5.03 und das ganze auf macOS 15.7.3/aarm64.
--- Ende Zitat ---
In den Modi 16M Farben und 32k Farben ist mit NVDI der TOS-Cursor bunt und leicht deplaziert. Das merkt man, wenn man VT52.PRG deaktiviert und dann z.B. die Shell mit Strg-M startet. Man muß dann die Fehlermeldung bestätigen und etwas warten, bis es losgeht.
Das ist alles sehr seltsam. Letztlich funktionieren mit NVDI nur die Modi 2/4ip/16ip reibungslos.
Thorsten Otto:
Kann es nicht einfach sein daß NVDI die falschen offscreen-driver läd?
AndreasKromke:
Ich glaube nicht, daß er die falschen Treiber lädt. Er müßte z.B. erst MFM256.SYS laden, dann NVDI und dann NFM256.SYS. Bei den behobenen Fehlern hat sich das NVDI beim MVDI Informationen geholt, und zwar aus den MFM...-Treibern. Die eigentlichen Zeichenfunktionen sind vermutlich im NVDI.PRG oder NFM*.SYS. Seltsam ist auch, daß es zwei kleine MVDI-Treiber gibt, 4IP und 16IP, und fünf große. Die großen haben VT52-Code, die kleinen nicht. Seltsam. Hat vielleicht historische Gründe.
AndreasKromke:
(hat sich erledigt, habe die Anleitung zu SID gesucht, bin gerade auf der Suche nach dem bunten VT52-Cursor, der ist grün/rosa)
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln