Hier gibt es ein ziemlich minimalistisches Forth: https://github.com/fuzzballcat/milliForth
Wie ist das mit 8086 Code, ist der noch auf heutigen PC-Prozessoren lauffähig?
Ja
AMD64 Prozessoren können zwar 8086 Code ausführen, aber die AMD64 Versionen von Windows und Linux unterstützen es nicht. Die sinnvollste Möglichkeit ist es, einfach den ganzen Prozessor zu emulieren (DOSBox o.ä.).
Vorausgesetzt man will es auf einem echten OS laufen lassen, statt bare metal: "This is a FORTH so small it fits in a 512-byte boot sector."
Beitrag #7531121 wurde von einem Moderator gelöscht.
AMD64 Prozessoren können zwar 8086 Code ausführen, Das finde ich erstaunlich, weil der 8086 ja ein 16Bit Mikroprozessor ist
https://en.wikipedia.org/wiki/Intel_8086
und der AMD64 ein 64Bit Prozessor.
Die Befehle sind im 8086 in überschaubaren 8Bit codiert:
https://en.wikipedia.org/wiki/X86_instruction_listings
In naiver Herangehensweise habe ich auf meinem Intel-I5 mit Ubuntu versucht zu kompilieren
1 |
|
was das Binärfile tatsächlich erzeugt. Der Versuch der Ausführung schlägt dann aber fehl:
1 |
|
2 |
|
Vorausgesetzt man will es auf einem echten OS laufen lassen, statt bare metal: "This is a FORTH so small it fits in a 512-byte boot sector."
Hier war ich mir eben nicht sicher, ob der "putchar" Interrupt für Windows, Linux oder Bios gilt:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
( aus https://github.com/fuzzballcat/milliForth/blob/master/sector.asm )
weil der 8086 ja ein 16Bit Mikroprozessor ist und der AMD64 ein 64Bit Prozessor.
Jeder x86 kommt ab Reset im 16-Bit "Real Mode" zur Welt und führt die Befehle wie ein 8088 aus. Der Übergang in 32- oder 64-Bit Modi erfolgt später. Code im Bootsektor ist also 8088-Code. In einem laufenden Betriebssystem ist das anders.
was das Binärfile tatsächlich erzeugt. Der Versuch der Ausführung schlägt dann aber fehl:
Kein Wunder, Linux braucht das korrekte Format, typischerweise ELF. Aber auch im richtigen Format führt Linux keinen 8086 Code aus.
.1: int 0x10
Das ist ein BIOS-Interrupt, den kann man unter einem normalen OS überhaupt nicht aufrufen.
Man kann dieses Forth allerdings sicherlich auch auf AMD64 Assembly portieren, dabei die SYSCALL Instruktion statt INT 10h nutzen, und ein gewöhnliches ELF File produzieren. Das kann man dann ganz normal unter Linux starten. Mit den Headern wird es vermutlich etwas größer als 512 Bytes, aber in den MBR kann man so ein AMD64 ELF File ja sowieso nicht packen.
Es gibt z.Z. gute PC XT emulatoren z.B: Marty PC womit man es testen könnte.
Das ist ein BIOS-Interrupt, den kann man unter einem normalen OS überhaupt nicht aufrufen.
Dafür gibt es DOSBox. Darunter kann man das, auch unter Linux.
Es gibt auch eine Variante davon, die im Webbrowser läuft:
https://js-dos.com/v7/build/docs/
Warum man sich ausgerechnet die Write-Only-Sprache Forth in Kombination mit fossilem 16-Bit-x86-Code antut, ist natürlich eine andere Frage, aber manch einer mag vielleicht dieses Gefühl, wenn man sich Nadeln unter die Fingernägel schiebt ...
Dafür gibt es DOSBox. Darunter kann man das, auch unter Linux
Nicht ganz, das BIOS wird ja emuliert, die Ausgabe wird einfach in eine gewöhnliche GUI umgeleitet. Da passiert also kein echter BIOS Interrupt auf der Hardware.
aber manch einer mag vielleicht dieses Gefühl, wenn man sich Nadeln unter die Fingernägel schiebt ...
so was wie täglich Windows nutzen ?
Da passiert also kein echter BIOS Interrupt auf der Hardware.
Und? Was ist ein BIOS-Interrupt? Ein Softwareinterrupt. Und was ist das BIOS? Binärcode, der von der CPU ausgeführt wird.
Die Emulation von DOSBox stellt alle BIOS-Softwareschnittstellen zur Verfügung, d.h. sämtliche BIOS-Softwareinterrupts. Sonst könnten all' die DOS-Programme, die darauf laufen sollen, auch nicht funktionieren.
Du kannst auch ein DOS oder FreeDOS von USB Stick booten und dann das .bin ohne Emulator auf einem modernen Rechner laufen lassen.
Du kannst auch ein DOS oder FreeDOS von USB Stick booten und dann das .bin ohne Emulator auf einem modernen Rechner laufen lassen.
Sollte es nicht auch mit Qemu laufen? Im Makefile des projects steht folgende Zeile:
1 |
|
Als Ergebnis erhalte ich folgende Mitteilung und das Bild im Anhang.
1 |
|
2 |
|
3 |
|
Angehängte Dateien:
-
qemu_boot.png
(31 KB)
Das ist ein BIOS-Interrupt, den kann man unter einem normalen OS überhaupt nicht aufrufen.
Wäre vielleicht gut gewesen, mitzuerklären was hier mit "normalem OS" gemeint sein könnte. ;)
Sollte es nicht auch mit Qemu laufen?
Naja, sollte.. es kommt wohl auch drauf an, welche Bootdiskette man nutzt, bzw. welches DOS. Disketten können kaputt sein, gute Bootdisketten gibt es aber hoffentlich noch, z.B. hatte Bernd Leitenberger eine auf seiner Seite zum Herunterladen im Angebot, wenn ich mich nicht irre.
Die ein oder andere Anleitung lesen, wäre eventuell auch schon hilfreich: https://opensource.com/article/17/10/run-dos-applications-linux
Rbx (rcx) 10.11.2023 14:18
Disketten können kaputt sein, gute Bootdisketten gibt es aber hoffentlich noch,
Ein durchaus interessanter Gedanke, dass virtuelle Bootdisketten kaput sein könnten (der Screenshot im vorigen Post wurde nach dem Aufruf von Q-Emu aus der Kommandozeile auf meinen Ubuntu 22.04 PC gemacht).
Eventuell erkennt die Sinatur nicht die am Ende des Bootsectors sein sollte, 0x55 0xAA, weil es fehlt.
Sollte es nicht auch mit Qemu laufen?
Es läuft doch. Nur dass wegen des Minimalismus jegliche Meldungen fehlen und kein Prompt ausgegeben wird. Gedrückte Tasten werden auf dem Bildschirm angezeigt und nach Enter erfolgt irgendwie eine Reaktion. Allerdings konnte ich keine sinnvolle Ausgabe im Sinne einer Programmierung erreichen. Statt eines Sternchens wird z.B auf die Eingabe von 42 EMIT nur ein Sonderzeichen ausgegeben.
Herrje, das ist ja wirklich sehr minimalistisch. Wenn man sich das "hello world" ansieht, merkt man, dass dieses Forth noch nicht mal Zahlen kennt und man sich diese mühevoll zusammenbauen muss.
Außerdem ist man schon vor 35 Jahren von 512 auf 4K Sektorgrößen umgestiegen. Da würde dann auch was sinnvolles reinpassen.
Außerdem ist man schon vor 35 Jahren von 512 auf 4K Sektorgrößen umgestiegen.
Wo sollte das gewesen sein?
Mit dem Aufkommen von Unix.
Zumindest mit 4K Blockgrößen in der Verwaltung. Nicht so oft 4K Sektoren.
Mit dem Aufkommen von Unix.
Und dann haben Festplattenhersteller plötzlich andere /Sektorgrößen/ verwendet?
Nee. Echte 4K-Sektoren sind bei Festplatten noch relativ neu, die gibts effektiv erst seit etwa 2010.
Siehe https://en.wikipedia.org/wiki/Advanced_Format
Du meinst das Zusammenfassen von Sektoren als eine logische Verwaltungseinheit (was man unter DOS/Windows & Co. "Cluster" nennt).
Sehr, sehr viele Jahrzehnte früher, als noch MFM- bzw. RLL-Festplatten verwendet wurden, und ein separater Festplattencontroller à la WD1003 die Festplatte angesteuert hat, da war ein Umformatieren der Festplatten mit anderen Sektorgrößen möglich, da die Festplatte selbst "dumm" war und von einer Magnetoberfläche abgsehen nicht mehr zur Verfügung stellte. Solche Festplatten positionierten ihre Köpfe entweder mit Schrittmotoren oder aber Servoinformationen, die von den Nutzdaten getrennt auf eigenen Magnetoberfächen untergebracht waren (wie z.B. ST4096 bzw. ST4144R). FÜr die Sektorierung war der Festplattencontroller zuständig, genau so, wie das auch bei Diskettenlaufwerken üblich war.
Das aber verschwand mit der Verlagerung der Controller in die Festplattenelektronik und der Einführung variabler Sektoranzahlen pro Spur (zone bit recording). Damit fing man recht bald nach Einführung der ersten IDE-Festplatten an, nur die allerersten Modelle nutzten noch eine 1:1-Abbildung von Spur/Kopf/Sektornummern analog zum alten WD1003.
von Mario M. (thelonging) 12.11.2023 09:33
Christoph M. schrieb:
Sollte es nicht auch mit Qemu laufen?
Es läuft doch. Nur dass wegen des Minimalismus jegliche Meldungen fehlen und kein Prompt ausgegeben wird. Gedrückte Tasten werden auf dem Bildschirm angezeigt und nach Enter erfolgt irgendwie eine Reaktion. Allerdings konnte ich keine sinnvolle Ausgabe im Sinne einer Programmierung erreichen. Statt eines Sternchens wird z.B auf die Eingabe von 42 EMIT nur ein Sonderzeichen ausgegeben.
Tatsächlich, Du hast recht. Ich habe es nicht bemerkt, weil es keinerlei Meldung ausgibt. Im Anhang habe ich zum Spaß mal eine Meldung in den Assemblercode eingefügt. Das verlängert natürlich Forth-Code ..
Kompilieren und laufen lassen mit
1 |
|
2 |
|
Etwas ungünstig ist, dass qemu mit amerikanischer Tastaturbelegung läuft.
Um es real auszuprobieren, könnte ich einen alten PC mit Floppy reaktivieren.
Weis jemand, wie man das ganze auf den Bootsektor eines USB-Sticks bekommt?
Dann könnte man es auch auf einem aktuellen PC testen.
Weis jemand, wie man das ganze auf den Bootsektor eines USB-Sticks bekommt?
Ich würde dd nehmen.
Dann könnte man es auch auf einem aktuellen PC testen.
Vorausgesetzt, daß der noch den "legacy mode"/"CSM" kennt und im "BIOS"-Mode booten kann. Das ist bei neueren PCs selten geworden, die haben 64-Bit-UEFI-Firmware, und das war's dann. Auf so etwas gibt es dann keine 16- und auch keine 32-Bit-Betriebssysteme mehr.
Wenn man auf so etwas "bare metal"-Assemblerprogramme laufen lassen will, müssen die x64-Code enthalten und sich als UEFI-Bootloader verkaufen.
(Dateiname BOOTX64.EFI, Speiherort auf EFI-Partition im Verzeichnis \EFI\BOOT)
Für Ein- und Ausgabefunktionen kann man dann allerdings auf die Funktionen der UEFI-Firmware zugreifen, was was komplett anderes ist, als alte BIOS-Softwareinterrupts aufzurufen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.