31
Hardware (Classic 16-/32-Bit) / Re: HBS640 Zusatz FPU Karte/Erweiterung ...
« Letzter Beitrag von ragnar76 am Sa 18.04.2026, 23:57:49 »Neu neugierige Zwischenfrage. Warum ein SG-615P und nicht ein popeliges DIP14 Quarz?
Neueste Beiträge
32
Software (16-/32-Bit) / Re: Lehrerkalender für Calamus
« Letzter Beitrag von cyberish am Sa 18.04.2026, 23:51:43 »nada?
33
Hardware (Classic 16-/32-Bit) / Re: HBS640 Zusatz FPU Karte/Erweiterung ...
« Letzter Beitrag von Lukas Frank am Sa 18.04.2026, 20:38:35 »Eine mal aufgebaut um die beiden unklaren Signale zuzuordnen ...
Die Flucht von J1 und J3 stimmt nicht ganz und die Platine sitzt etwas schräg aber Elektrisch macht das nichts. Muss ich dann im fertigen Layout noch überarbeiten.
Die Flucht von J1 und J3 stimmt nicht ganz und die Platine sitzt etwas schräg aber Elektrisch macht das nichts. Muss ich dann im fertigen Layout noch überarbeiten.
34
Hardware (Classic 16-/32-Bit) / Re: TT/MSTE Keyboard Instandsetzung ...
« Letzter Beitrag von Lukas Frank am Sa 18.04.2026, 15:52:54 »Das Problem ist das abtragen/abkratzen vom Schutzlack der auf den Leiterbahnen ist. Dieser Lack geht oft zusammen mit der Leiterbahn darunter ab aber man braucht für das Leitsilber ein kurzes Stück Leiterbahn ohne den Lack obenauf. Und als zweites zerläuft der Silberlack und macht es oft schwierig und der Elektrische Widerstand ist sehr hoch, es geht zwar damit aber optimal ist das nicht.
35
Emulatoren / Re: AtariX => MagicOnLinux
« Letzter Beitrag von don_apple am Sa 18.04.2026, 13:47:27 »Soweit bin ich jetzt ...Wie in https://gitlab.com/AndreasK/magiclinux/-/blob/main/MACOS.txt?ref_type=heads beschrieben must du nach dem cmake das unter Punkt „4a“ angegebene xcodebuild Kommando ausführen damit die Programmdatei erzeugt wird.
Franks-MacMini:~ frank$ cd magiclinux
Franks-MacMini:magiclinux frank$ mkdir build
Franks-MacMini:magiclinux frank$ cd build
Franks-MacMini:build frank$ cmake -G Xcode ..
-- The C compiler identification is AppleClang 21.0.0.21000099
-- The CXX compiler identification is AppleClang 21.0.0.21000099
-- 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.9s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/frank/magiclinux/build
Franks-MacMini:build frank$
36
Hardware (Classic 16-/32-Bit) / Re: TT/MSTE Keyboard Instandsetzung ...
« Letzter Beitrag von thomas am Sa 18.04.2026, 12:24:22 »Ich habe noch ein paar grüne Folien hier, wenn jemand was haben möchte zum Basteln.
Sie werden aber nicht 100 % OK sein, müssen also ebenfalls repariert werden,
bevor sie verwendet werden können.
Sie werden aber nicht 100 % OK sein, müssen also ebenfalls repariert werden,
bevor sie verwendet werden können.
37
Hardware (Classic 16-/32-Bit) / Re: Atari Monitor SC1224 ist zu leise
« Letzter Beitrag von thomas am Sa 18.04.2026, 12:21:28 »Hallo!
Ich habe lange an diesem Problem probiert. Manche Monitore machen das, nicht alle. Bei dem Umschalter ist dieser genannte PIN (Audio IN) nicht belegt, dadurch funktioniert es. Irgendwie.
Ich glaube nicht, dass es mit dem Netzteil zusammenhängt. Man kann es sehr einfach lösen, indem man den Stecker vom Monitor vorsichtig öffnet und das Kabel abzieht. Ich meine, es wäre das gelbe.
Der technische Grund würde mich auch interessieren.
Was war denn an Deinem Netzteil defekt? Normalerweise gehe da nur diese goldenen RIFA Kondensatoren hoch, bzw platzen auf. Das Plastik von denen ist brüchig nach all diesen Jahren.
Viele Netzteile haben diese jedoch gar nicht, bzw andere statt dessen.
Ich habe lange an diesem Problem probiert. Manche Monitore machen das, nicht alle. Bei dem Umschalter ist dieser genannte PIN (Audio IN) nicht belegt, dadurch funktioniert es. Irgendwie.
Ich glaube nicht, dass es mit dem Netzteil zusammenhängt. Man kann es sehr einfach lösen, indem man den Stecker vom Monitor vorsichtig öffnet und das Kabel abzieht. Ich meine, es wäre das gelbe.
Der technische Grund würde mich auch interessieren.
Was war denn an Deinem Netzteil defekt? Normalerweise gehe da nur diese goldenen RIFA Kondensatoren hoch, bzw platzen auf. Das Plastik von denen ist brüchig nach all diesen Jahren.
Viele Netzteile haben diese jedoch gar nicht, bzw andere statt dessen.
38
Emulatoren / Re: AtariX => MagicOnLinux
« Letzter Beitrag von AndreasKromke am Sa 18.04.2026, 11:02:58 »Etwas Grundlagen:
Früher hat man ein Projekt ein "Makefile" geschrieben. Das ist eine Textdatei. Sie enthält eine Liste aller Quelltextdateien, die übersetzt werden müssen, und die Anweisungen, wie sie übersetzt werden müssen. Außerdem konnte man noch Abhängigkeiten angeben, damit bei Änderung von Datei A automatisch die Dateien X und Y neu übersetzt werden und der Linker das Programm neu bindet.
Die Datei hieß i.a. "Makefile", und man hat im selben Verzeichnis das Kommando "make" aufgerufen. Das kann man heute noch so machen und ist für kleinere Programme auch legitim.
Für größere Programme schreibt man heute das "Makefile" nicht mehr selbst, sondern benutzt einen Makefile-Generator. Davon gibt es mehrere, und cmake ist der weitestverbreitete. Ein Vorteil von cmake ist, daß man unterschiedliche Betriebssysteme und Compiler berücksichtigen kann. So erzeugt cmake je nach Umgebung ein angepaßtes "Makefile" mit entsprechenden Compiler-Einstellungen.
Die zentrale Steuerdatei für cmake ist i.a. "CMakeLists.txt". Hieraus macht cmake dann das Makefile. Damit man sein Projektverzeichnis nicht mit Kompilaten vollschreibt (man möchte Quelltexte trennen von den Dateien, die temporär erzeugt werden), verwendet man ein "build"-Verzeichnis. Nach Konvention heißt es "build", der Name ist aber egal. Fast alle modernen Programme werden so erzeugt:
Das cmake sollte in das "Makefile" einen Mechanismus einbauen, der erkennt, wenn das "Makefile" selbst neu erzeugt werden muß, also von der Theorie her braucht man cmake fürderhin nicht mehr zu starten, sondern immer nur make, es sei denn es geht etwas schief. Wenn man Quelltextdateien hinzufügt oder entfernt, könnte das nötig sein.
Abschließend: Man kann dem "cmake" auch Parameter mitgeben, um die Generierung des Makefile zu beeinflussen, z.B. wenn man einen "debug build" will. Warum man das nicht später beim make festlegt? Keine Ahnung, bin kein cmake-Spezialist ...
Früher hat man ein Projekt ein "Makefile" geschrieben. Das ist eine Textdatei. Sie enthält eine Liste aller Quelltextdateien, die übersetzt werden müssen, und die Anweisungen, wie sie übersetzt werden müssen. Außerdem konnte man noch Abhängigkeiten angeben, damit bei Änderung von Datei A automatisch die Dateien X und Y neu übersetzt werden und der Linker das Programm neu bindet.
Die Datei hieß i.a. "Makefile", und man hat im selben Verzeichnis das Kommando "make" aufgerufen. Das kann man heute noch so machen und ist für kleinere Programme auch legitim.
Für größere Programme schreibt man heute das "Makefile" nicht mehr selbst, sondern benutzt einen Makefile-Generator. Davon gibt es mehrere, und cmake ist der weitestverbreitete. Ein Vorteil von cmake ist, daß man unterschiedliche Betriebssysteme und Compiler berücksichtigen kann. So erzeugt cmake je nach Umgebung ein angepaßtes "Makefile" mit entsprechenden Compiler-Einstellungen.
Die zentrale Steuerdatei für cmake ist i.a. "CMakeLists.txt". Hieraus macht cmake dann das Makefile. Damit man sein Projektverzeichnis nicht mit Kompilaten vollschreibt (man möchte Quelltexte trennen von den Dateien, die temporär erzeugt werden), verwendet man ein "build"-Verzeichnis. Nach Konvention heißt es "build", der Name ist aber egal. Fast alle modernen Programme werden so erzeugt:
- Ein "build"-Verzeichnis wird erzeugt und betreten. Hier landet der ganze temporäre Müll, aber auch das fertige Programm.
- Man ruft "cmake .." auf, dabei ist ".." der Parameter, mit Leerzeidchen getrennt, der dem cmake sagt wo es die Datei CMakeLists.txt suchen soll.
- Das cmake rattert rum, macht dies, das, Ananas und erzeugt schließlich ein "Makefile".
- Wie oben beschrieben, kann man jetzt per "make" den Bau-Prozeß starten.
- Abschließend kann man den "build"-Ordner wieder verlassen.
Das cmake sollte in das "Makefile" einen Mechanismus einbauen, der erkennt, wenn das "Makefile" selbst neu erzeugt werden muß, also von der Theorie her braucht man cmake fürderhin nicht mehr zu starten, sondern immer nur make, es sei denn es geht etwas schief. Wenn man Quelltextdateien hinzufügt oder entfernt, könnte das nötig sein.
Abschließend: Man kann dem "cmake" auch Parameter mitgeben, um die Generierung des Makefile zu beeinflussen, z.B. wenn man einen "debug build" will. Warum man das nicht später beim make festlegt? Keine Ahnung, bin kein cmake-Spezialist ...
39
Emulatoren / Re: AtariX => MagicOnLinux
« Letzter Beitrag von Lukas Frank am Sa 18.04.2026, 10:45:34 »xcode ...
Schaffe es aber nicht das Programm zu erzeugen. Weiß auch nicht was und wie ich da was machen soll? Bin zu blöd.
Schaffe es aber nicht das Programm zu erzeugen. Weiß auch nicht was und wie ich da was machen soll? Bin zu blöd.
40
Biete / Re: Atari Netzteil PS32 für Laufwerke
« Letzter Beitrag von thomas am Sa 18.04.2026, 09:46:11 »vergeben