Beiträge von Mathias

    Zitat

    MFM-Festplatten als RLL waren teilweise unzuverlässig, u.a. Seagate hat die selbe HDD nochmal als R-Version für RLL rausgebracht. Das Aufzeichnungsverfahren MFM ist halt zuverlässiger weil Fehler keine Folgefehler auslösen.

    Das war mir bekannt, das ist etwa der gleiche Effekt, wie wen man eine 720KB Diskette mit 1.44MB formatiere.

    Zitat


    Es gab auch einige XT-Computer mit HDD-Unterstützung wie z.B. der PC-20-III mit Onboard 8 Bit-IDE-Interface woran nur 8 Bit IDE-Laufwerke laufen. Für den gab es später sogar ein richtiges BIOS.

    Solch eine 8Bit IDE Platte hatte ich auch mal in den Fingern, es war eine Drive-Card von WD. Der Pfostenstecker war der gleiche wie bei den 16Biter.

    Die Bios-Adresse war ein wenig anders, als bei den Standard-Controllern, sie lief parallel mit anderen Controllern.

    Zitat


    Inkompatibilitäten gibt es auch bei SCSI. NCR formatierte Platten liefen nicht zwingend an einem Adaptec und umgekehrt, da das Mapping der Controller teilweise unterschiedlich war.

    Diese Erfahrung hatte ich nie gemacht. Bei mir liefen sogar HDs an Sound-Karten. Nur booten konnten sie logischewrweis nicht, weil das BIOS fehlte.

    Zitat
    Zitat

    Genau so ist es: die MFM/RLL Festplatten sind nur "Motor und Köpfe", der Controller macht die Logik. Wobei es von WD z.B. AT Controller gibt, die zu WD XT-Controller abwärtskompatibel gejumpert werden können.

    Ab IDE wurden die Platten intelligent, dafür war die Controller stroh dumm, ausgenommen SCSI.


    Ich hatte auch bessere MFM-Controller in den Fingern, die hatte mehr Puffer-Speicher als die günstigen. Dimit konnte man Platten mit interlafing 1 formatieren. Normale weise ging nur 2-3.

    XT meisten 3, bei AT 2.

    Ich habe mich zurück erinnert, als ich mit alten PCs bastelte.

    Da ist mir aufgefallen, wen man eine MFM-Platte an einem XT-Controller formatierte, funktioniert dies nach an einem AT-Controller. Umgekehrt auch nicht.

    Was wurde an diesem beiden Controllern unterschiedlich formatiert, so das diese Inkompatibilität entstand ?

    Was funktioniert hat, wen man ein funktionierendes Kontroller und Plattengespann von einem XT in einem AT zügelte.


    Was mi bekannt ist, der XT brauchte ein Zusatz-BIOS auf dem Controller. Beim AT war die HDD-Unterstützung im BIOS des Mainboard mit verbaut.

    Ich konnte es nicht lassen und habe es mal versucht zu coden.


    Im Anhang mal das erste Ergebnis.

    Die bin läuft erstmal nur unter Linux.


    Nachtrag:

    Die Source inklusive OpenGL-Packages sind hier erhältlich:

    Das komplette OpenGL-Zeugs;

    GitHub - sechshelme/Lazarus-OpenGL-3.3-Tutorial
    Contribute to sechshelme/Lazarus-OpenGL-3.3-Tutorial development by creating an account on GitHub.
    github.com

    Nur das Beispiel:

    Lazarus-OpenGL-3.3-Tutorial/Beispiele/Maschendraht at master · sechshelme/Lazarus-OpenGL-3.3-Tutorial
    Contribute to sechshelme/Lazarus-OpenGL-3.3-Tutorial development by creating an account on GitHub.
    github.com

    Zitat

    Wenn Du ein Linux da hast und mehr an der Optik interessiert bist, dann schau mal bei

    . https://datagubbe.se/fvwm/

    vorbei. Das config File ganz unten auf der Seite ist sehr nett ! Und den FVWM2 sollte man in den meisten Linux Ausgaben immer noch finden - der wird dann plötzlich zu was richtig schickem und halbwegs benutzbaren.

    FVWM kann man auf aktuellen Ubuntu immer noch sehr einfach installieren.

    Code
    sudo apt install fvwm
    #oder
    sudo apt install fvwm2
    Zitat

    Unter Linux wäre ich dann eher bei SDL, oder was da heutzutage an 2D-Grafikpaketen üblich ist. 2D mit OpenGL hat mir zumindest früher nicht wirklich Spaß gemacht, aber u.U. sind die aktuellen Versionen auch besser geworden.

    Ich ging vom 2. obersten Bild aus, welches noch beleuchtet ist. Pro Ebene ist nur ein Rechteck mit einer Textur Alphablending Textur von nöten.

    Und dann noch die passende Beleuchtung. Ich würde trotzdem 3D nehmen. Die 3 Ebenen in verschiedenen Z Abständen.


    Ich habe gerade das Bild nochmals genauer betrachtet. Das Bild ist 3D, ausser es wurde bump mapping verwendet.


    Was bei OpenGL noch dazu kommt, das Bild einmal rendern und dann nur noch Koordinaten verschieben.

    Ich denke, die 63kB beziehen sich auf die Angabe der UMBs im MEM-Output.


    (Aber das kennen nur Leute, die damals unbedingt Wing Commander spielen wollten... :sunny: )

    Wen ich mich zurück erinnern mag, gab es von Caldera, oder wie dies hiess, einen alternativen EMM386.

    Mit diesem kriegte man mehr Basisspeicher frei, als mit der HIMEM..SYS und EMM386.EXE.


    Oder unter Linux gab es dosemu, der hatte auch fast 640KB, inklusive Maustreiber.

    Da habe ich etwas übersehen, weiter unten im Forum gibt es nochmals eine Software Ecke. :saint:


    Software

    Zitat

    Du googelst scheinbar die Fehlermeldung nicht sondern fragst in einem Forum. Falsch.

    Erster Treffer bei Google: https://stackoverflow.com/ques…t-find-entry-symbol-start

    Anscheinend ist nasm ein wenig heikel, die meisten Beispiele die ich gefunden habe, haben alle main, anstelle von _start.


    Ich habe gerade noch ein paar Examples gefunden,

    Sample 64-bit nasm programs


    Solche Register wie rcx, rdx, waren mir bekant. R8 und R9 sind mir neu, nur bei den AVRs kannte ich r* .

    Ich bin gerade an einem HelloWorld in Assembler zu schreiben.

    Die ASM-Source:

    Compilier-Kommando:

    Code
    nasm -felf64 hello.asm
    ld hello.o -o hello -lc -I /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    # ld hello.o -lc -o hello 
    ./hello

    Funktionieren tut es, aber bei Linker wird folgende Warnung ausgespuckt:

    Code
    ld: warning: cannot find entry symbol _start; defaulting to 0000000000401030

    Was mache ich falsch ?


    Noch was, lasse ich die "-I " Anweisung weg, kommt die gleiche Warnung, nur kann die erzeugte bin nicht ausgeführt werden, kommt nur folgender Fehler:

    Code
    $ ./a.out 
    bash: ./a.out: Datei oder Verzeichnis nicht gefunden

    Waran liegt dies ?

    Zitat

    Wobei die Zeiten auch vorbei sind... Die alten MCUs auf den Arduinos sind mittlerweile vor ueber 15 Jahren erschienen,

    Dies stimmt auch wieder, aber irgendwie sind sie trotzdem spannend, auch gibt es viel Doku darüber.

    Nur Schon bei einem STM32 steht man überall an.

    Zitat

    Außer es kommt von Microsoft und wird einem als fertig verkauft, dann ist das ok (Windows 10 hat bis heute Bugs, die mich täglich nerven).

    Microschrottmüll kommt keiner mehr auf meine Computer, ausser in einer Vbox für Versuche. Die wissen bis heute nicht, wie man Anchors in Dialoge einbauen, ich musste mich letzte Woche in der Bude an so Mikro-Dialoge ärgern Da hat man einen riessen Schirm und muss trotzdem scrollen :cursing: .


    Zitat


    X11 ist aus einer Zeit, zu der es haufenweise Fachbücher gab. Da wirst du wohl mal antiquarisch schauen müssen, ein für dich passendes zu finden.

    Habe unterdessen welche gefunden, eines sogar in deutsch, was mir hier empfohlen wurde.

    Aber wie zB. ein Clipboard unter Linux arbeitet, habe ich bis jetzt nicht gefunden, da musste ich alles in INet zusammen suchen.

    Besonders über die INCR-Übertragung findet man nichts. Da habe ich das Programm "xsel" auseinander genommen. Ein Vorteil von Linux, man bekommt von fast allem die Sourcen.


    Zitat


    Das ist bei mir anders. Ich programmiere auch gerne in der Freizeit. Der entscheidende Unterschied ist, dass ich hobbymäßig programmieren kann, was und wie ich will. Ohne Termindruck und auch gerne mal völlig chaotisch.

    Die ist bei mir auch so, ich mache es fast nur als Hobby.

    Da kann man das machen was interessant ist und auch die Lieblings-Sprache, bei mir FPC/Lazarus verwenden.


    Zitat


    Ein typisches Programm für einen Arduino UNO ist bei mir ein paar Kilobyte groß.

    Arduinos und AVRs habe auch ihren besonderen Reiz, da kann man optimieren, wir dazumal auf den Oldie-PCs.

    Diese Dinger programmiere ich auch in Pascal, Arduino hat viel zu viel Overhead.

    Ich bin momentan mit X11 am probieren, da versuche ich auch mit möglichst einfachen Beispielen zu zeigen, wie die einzelnen Sachen gehen.

    Und die wichtigsten Sachen versuche ich zu kommentieren.

    Ich arbeite momentan noch daran, und es wird immer mehr.


    Was ein leidiges Problem ist. man findet auf zig Webseiten immer die gleichen Datenblätter, aber Beispiele wie man die Befehle einsetzt, findet man kaum.

    Per Zufall findet man wieder mal was, was man schon lange gesucht hat.

    Und dann gibt es nur ein, sofort den Link sichern, ansonsten findet man es nie mehr.


    GitHub - sechshelme/Lazarus-X11-Examples
    Contribute to sechshelme/Lazarus-X11-Examples development by creating an account on GitHub.
    github.com

    Zitat

    Liegt vielleicht daran, dass ich auch viel im Forum64 unterwegs bin und dort wird viel in Basic und Assembler programmiert. Aber da geht es ja auch um wenige Gerätetypen.

    Meinst du, die Veteranen sind alle in eigene Foren, so wie bei die eines für den C64 ?

    Und dieses Forum hier ist zu allgemein ?

    Ich verfolge das Forum zwischendurch.

    Was mir dabei auffällt, es kommen fast keine Posts, was die Programmierung angeht.

    Ich hätte da eher das Gegenteil erwartet, das es ein Reiz sein kann Software für eure Museum-Computer zu entwickeln.


    Ist somit Notalgie programmieren keine gefragte Sache ?


    So wie ich es mitbekommen habe, kann man auf einer Modernen-IDE auf dem PC einwickeln und dann per Crosscompiliere Code für die alten Computer compilieren.

    Xwpe von Fred Kruse stammt aus dem Jahr 1993 und ist heute noch in einigen Linux-Distributionen vorhanden ...

    Konnte ich unter Manjaro aus dem AUR installieren, bringt aber nur die Fehlermeldung Xwpe: unable to open font "8x13", exiting ...

    Wieso kommt da ein Font-Fehler ?

    Eine Konsolen-Anwendung braucht doch keine Fonts.

    Bei mir sieht es so aus, wen ich "xwpe" in der Konsole starte.


    Nachtrag: Ich habe gerade die Sourcen davon kompiliert, jetzt sieht es aus wie bei dir.

    Ich dachte, der sei bei Turbo-Pascal voll in Ordnung.

    Bei FPC bin ich anderer Meinung, dort ist die erzeugte EXE einiges grösser als die von TP.

    Leider ist dies ein Manko von Pascal, auch unter Linux erzeigt gcc kleiner bins als fpc.


    Für AVRs, dort erzeugt FPC auch sehr kleinen Code.

    Ich habe damals unter DOS den Editor "ETP" genutzt... IIRC hiess der Hersteller "KRS" oder so.


    Die Suche mit gleichzeitigem Folding war damals ein echtes Highlight.


    Den habe ich genutzt mit Watcom C/C++... damals der beste Compiler. Kein Vergleich mit Blödland Borland C.

    Borland Pascal war super, aber der C war Müll.

    Wie heute mit Delphi und C Builder.

    Auf dem Atari ST haben viele Programmiersprachen ihre eigenen Editoren, ST-Basic, GFA-Basic, Omikron-Basic usw. Komplette IDEs gab es z.B. mit ST-Pascal-Plus, Turbo-C/Pascal, usw. Und eigentlich immer nehmen konnte man den Tempus-Editor (verwandt mit Tempus-Word) und XEdit, in die man z.B. die Compiler/Linker usw. von ST-Pascal-Plus und den Turbo-Sachen einbinden konnte, oder auch die diversen Assembler/Debugger wie Turbo-Assembler, Boogaboo, usw.

    War/ist das unter DOS/Windows nicht auch heute noch der Fall. VS für C/C++ Programmierer. Delphi für Pascaler.

    Und was unterdessen noch erwachsen geworden ist, das Gespann FPC/Lazarus. Dies lässt praktisch keine Wünsche mehr übrig. Und der Cross-Support ist auch hervorragend. Es gibt praktisch keine Plattform, welche da nicht unterstützt wird. Auch für Nostalgiker interessant. Auf dem PC entwickeln und die fertigen Programme auf den Oldie nehmen.

    Ich vermute schwer, der war sicher dazumal bei den SuSE-Distros dabei, nur wusste ich dies nicht.

    Überall lass man nur von Emacs und VI.

    Deine Fehler scheint von hir zu kommen, Zeile 480:

    nedit/util/misc.c at master · adrian-bl/nedit
    My copy of nedit. Contribute to adrian-bl/nedit development by creating an account on GitHub.
    github.com


    Was verwendest du für ein Linux ?

    Ich habe den Connamon-Desktop von Mint.


    Hast du mal folgendes probiert:

    Code
    apt install libmotif-dev 

    Ich habe kürzlich selbst Motif Programme geschrieben.

    Auf Debian 10 ist er noch im Angebot, hat aber Probleme.


    Genau, sowas hätte man dazumal gebraucht, ein Editor welche in Motif geschrieben ist, der kommt locker an den Komfort von dem dazu-maligen Win31 an.


    Was meinst du mit Probleme ?

    Bei mir scheint es zu laufen, passt einfach nicht so ganz zum GTK-Design von meinem Desktop.