Ich habe es hingekriegt aus der ASCII-Datei t.fnt.psftx, ein PNG aus dem Font zu erstellen.
Die Source habe ich diese genommen: https://www.zap.org.au/projects/conso…-39/t.fnt.psftx
Für OpenGL würde dies schon reichen.
Was ich festgestellt habe, die Zahlen und Buchstaben sind 8 Pixel breit, meistens sind diese nur 7, sodas immer eine Spalte zwischen den Zeichen Frei ist. Somit wird das VGA-Format 16x9 voll ausgenutzt.
Vielleicht ist er auf Linux Console Fonts Screenshots dabei?
Ich vermute es war die: t.fnt
Auf dem alten Rohren VGA sah sie sicher auch ein wenig anders aus.
https://adeverteuil.github.io/linux-console-fonts-screenshots//screenshots/t.fnt.png
Mal gucken, ob man die irgendwo downloaden kann.
Als ich mich an meine Anfänge von Linux erinnere, konnte man bei der Installation die Schrifart für die VGA-Konsole auswählen.
Die Schrift sah fast eine Hanschrift aus.
Hat einer eine Ahnung, was das für eine war ?
Was ich mich nur erinnern mag, den Font konnte man in einem solchen Dialog einstellen: https://de.wikipedia.org/wiki/Datei:Sla…_screenshot.png
Hallo ihr, ich bin nur an Z80 interessiert. Und Mathias: was soll da übrig bleiben? Ich habe noch nichts vom NDR und könnte also nur mit dem ganzen Paket etwas anfangen. Aber lieben Dank für das Angebot.
Grüße vom Karsten
Ihr verwechselt mich mit jemand anders.
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.
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.
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.
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;
Nur das Beispiel:
Wenn Du ein Linux da hast und mehr an der Optik interessiert bist, dann schau mal bei
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.
sudo apt install fvwm
#oder
sudo apt install fvwm2da sieht man, das es dazumal schon besseres gab als M$.
Yessss, gab essss
(aus der Sammlung / Museum von Darkscreen)
Was ist das für ein hübsches OS ?
Sieht aus wie motif auf Linux.
Da gab es mehrere Programme, die den Speicher effektiver verwaltet haben, als himem/emm386. Am bekanntesten dürfte QEMM386 von Quarterdeck gewesen sein.
Recht bekannt war auch 386max.
da sieht man, das es dazumal schon besseres gab als M$.
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...
)
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.
Sehe ich das falsch, oder hat die DosBox 63KB bei mir ?
Ich sehe auf Deinem Screenshot 632kB conventional memory. Wie kommst Du auf 63KB?
PAW
Eine Zeile weiter unten,
Sehe ich das falsch, oder hat die DosBox 63KB bei mir ?
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.
Da habe ich etwas übersehen, weiter unten im Forum gibt es nochmals eine Software Ecke. 
Auf einem heutigen Rechner würde ich die mit OpenGL lösen.
Wen ich mich richtig erinnere, hatten alte PCs wie der C64 nicht Hardware-Sprite ?
Hat dies einer von euch schon ausprobiert ?
Die Sourcen dazu hätte ich mal gefunden.
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,
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:
extern puts
extern exit
global main
section .data
message: db 27,"[93m", "Hello, World", 10, 10, 0
section .text
main:
mov rdi, message
call puts
push 0
call exitCompilier-Kommando:
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
./helloFunktionieren tut es, aber bei Linker wird folgende Warnung ausgespuckt:
ld: warning: cannot find entry symbol _start; defaulting to 0000000000401030Was 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:
$ ./a.out
bash: ./a.out: Datei oder Verzeichnis nicht gefundenWaran liegt dies ?
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.
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 
.
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.
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.
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.
Alles anzeigenAlles anzeigenIst somit Notalgie programmieren keine gefragte Sache ?
Ich kann natürlich nur für mich sprechen. Programme, die ich schreibe (egal, ob für Windows oder meinen alten Sharp PC-1360) werden immer nur so weit entwickelt, wie ich sie persönlich benötige. Falls ich dabei auf Probleme stoße, lassen sich diese entweder durch die Suche im Netz lösen, ich muss experimentell selber ermitteln, was die alte HW tut oder die Sachen sind zo komplex zu beschreiben.
Für mein "aktuelles" Projekt (das liegt aber seit über einem Jahr auf Eis) würde ich hier keine Diskussion aufmachen. Mir fehlen dazu auch keine Ideen, sondern eher die Zeit/Lust, mein knapp 30 Jahre altes Wissen aus dem Studium wieder hervor zu kramen und mir die Infos dazu im Netz zusammen zu suchen, um das zeitnah zu realisieren.
Ansonsten plane ich seit Jahren einige meiner alten Sharp-Programme zu veröffentlichen. Nur weiss ich, was das an (für mich persönlich eigentlich nicht benötigtem) Zusatzaufwand bedeutet. Ich weiss, was ich damals (oder teils auch heute) "verbrochen" habe, wie ich die Sachen ans Laufen bekomme und wie ich die Programme nutzen muss. Anleitungen dazu gibt es aber natürlich nicht.
Will ich das Zeugs so veröffentlichen, dass jemand anderes etwas davon haben könnte, muss ich die Doku dazu schreiben. ASM-Quelltexte müsste ich auch noch in ein allgemein nutzbares Format übersetzen. Mein privat geschriebener Assembler nutzt noch nicht einmal die offiziellen Sharp-Mnemonics.
Das ganze würde am Ende dann trotzdem nicht zu einem Posting hier unter "Entwicklung" führen. Die SW ist fertig und würde nur in der Hoffnung veröffentlicht, dass irgendwer anders daran auch Spaß hätte. Dazu gäbe es u.U. eine Info bei den Sharp-"Taschen- und Tischrechner" oder unter "Pocket Computer, Handhelds, PDAs".
Wenn mans nicht probiert, weiss man es nicht.
Ein bisschen Doku dauert nun auch keine Ewigkeit,
aber die evtl. Nutzer sind ewig dankbar dafuer.
Ich wuerds einfach mal machen.
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.
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.
Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.
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.
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.
Alles anzeigenWieso findest du die schlecht ?
Turbo Pascal hatte einer der besten Compiler.
Ich wüsste keiner der besser ist.
Nur welche die mehr verbreitet sind, zB. C/C++
Ich rede nicht vom Compiler oder dem Sprachumfang, sondern von dem daraus generierten x86-Code.
Der war einfach nicht sehr gut optimiert und langsam.
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.
Wieso findest du die schlecht ?
Turbo Pascal hatte einer der besten Compiler.
Ich wüsste keiner der besser ist.
Nur welche die mehr verbreitet sind, zB. C/C++
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ödlandBorland 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.
