Forth-Diskussion und Infos
-
-
Das könnte ein Ansatz zur Berechnung von Apfelmännchen sein. Kann es aber leider im Moment nicht testen.
ESP32forth kennt davon schon einige words/commands nicht
-
Das könnte ein Ansatz zur Berechnung von Apfelmännchen sein. Kann es aber leider im Moment nicht testen.
ESP32forth kennt davon schon einige words/commands nicht
Das tolle / spezielle an FORTH ist ja, dass man, etwa mit dieser Liste, sämtliche Worte in sein System einbauen kann.
-
Also 8 Buzzwords in 3 Sätzen - das ist bißchen happig, um da direkt die Informaion rauszulesen.
Sorry kommt mir garnicht so vor...
Den Eindruck hatte ich ja auch
Ist nicht schlimm, muß man halt mal was googeln ... Der USBTiny scheint aber schon scharf auf Kante genäht zu sein, klingt so als ob das gerade eben so funktionieren würde mit den USB Signalen. Also gleiche Kategorie wie die fabGL Sachen - wo man ja auch nicht denken würde, daß sowas überhaupt geht.
Pixel-Grafik wird es kaum geben, da sind die Systeme zu unterschiedlich.
Es gibt zwar einige Forth-Standard-Versionen (Befehlsumfang) aber trotzdem schwankt die Vrefuegbarkeit der Befehle (in Forth werden die Words genannt)
Ja. Es scheint aber v.a. irgendwie niemand wirklich mal dafür benutzt zu haben. Streng genommen sollte ja eine komplett Grafikbibliothek transportabel machbar sein, sobald man eine Anweisung für das Setzen eines Punktes hat. Alles obendrüber ist ja dann schon reines Forth und damit verschiebbar. Noch interessanter ist wahrscheinlich dann noch Hardware gezeichnetes Triangle als Basis. Dann bräucht man nur noch die Screenmax Werte und schon geht eine ganze Menge obendrüber, was dann auch - egal ob nun Punkt oder Dreieck Basis - portabel sein sollte.
Was ich irgendwie noch nicht kapiert habe, ist, wie das mit den SCREENs gemeint ist. Manchmal gibt es das, manchmal scheint es zu fehlen. Irgendwie sind das wohl mal einfach Seiten gewesen, die genau einen Diskblock groß waren (oder ein kleines Vielfaches davon) und die man dann zum evtl. nur angenehmeren Eingeben benutzt hat; mit Grafik hat es aber nix zu tun.
-
Es ist irgenwie auch ein wenig eigenartig, daß es so gut wie keine Homcomputer gab, die das als Basissprache benutzen - hätte sich ja eigentlich/evtl. angeboten.
Ja, der einzige Rechner mit FORTH als Basissprache, der mir bekannt ist, ist der Jupiter Ace.
Wäre das so gewesen, dann hätte sich die Geschichte sicher etwas anders entwickelt und etwa Bill Gates wäre nicht so groß geworden.
Es gab noch den Micronique Hector HRX:
-
Es ist irgenwie auch ein wenig eigenartig, daß es so gut wie keine Homcomputer gab, die das als Basissprache benutzen - hätte sich ja eigentlich/evtl. angeboten.
Ja, der einzige Rechner mit FORTH als Basissprache, der mir bekannt ist, ist der Jupiter Ace.
Wäre das so gewesen, dann hätte sich die Geschichte sicher etwas anders entwickelt und etwa Bill Gates wäre nicht so groß geworden.
Es gab noch den Micronique Hector HRX:
Gerade gesehen: Es gab sogar noch einen weiteren Rechner mit FORTH im ROM, den Hector MX aus dem Jahr 1985.
-
Wer sich nun einmal näher mit FORTH beschäftigen möchte, dem empfehle ich die Installation einer entsprechenden Umgebung und dann die Seite RosettaCode. Hier gibt es eine Vielzahl von Programmierbeispielen, die meist mit Gforth umgesetzt wurden.
Unter Zuhilfenahme etwa dieser Liste kann man sich in aller Ruhe die Quelltexte ansehen und sich mit den words vertraut machen.
-
Es ist irgenwie auch ein wenig eigenartig, daß es so gut wie keine Homcomputer gab, die das als Basissprache benutzen - hätte sich ja eigentlich/evtl. angeboten.
Ja, der einzige Rechner mit FORTH als Basissprache, der mir bekannt ist, ist der Jupiter Ace.
Wäre das so gewesen, dann hätte sich die Geschichte sicher etwas anders entwickelt und etwa Bill Gates wäre nicht so groß geworden.
Es gab noch den Micronique Hector HRX:
Gerade gesehen: Es gab sogar noch einen weiteren Rechner mit FORTH im ROM, den Hector MX aus dem Jahr 1985.
Der Unterschied zwischen Hector HRX und MX liegt wohl im größerem ROM des MX, in dem neben Forth noch Basic und Assembler stecken.
-
weitere interessante Forth Seite
https://opensourcelibs.com/libs/forth
außerdem ganz interessant ist das Universum mit und um "CamelFORTH"
basierend auf dem Original von J Rodriguez
http://www.bradrodriguez.com/papers/
http://www.camelforth.com/news.php
das mal in GPL v3 umgewandelt worden ist
https://web.archive.org/web/20…camelforth.com/index.html
gibt es allerlei Umsetzungen für z.B. Z80 generell und Abkömmlinge
http://www.hytherion.com/beattidp/comput/z80forth.htm
oder den Z88
https://worldofspectrum.org/z8…camelforth/rom-camel.html
oder den TRS-80 Model 4
http://www.hytherion.com/beattidp/comput/camel4.htm
Außerdem findet sich darüber was für einen (evtl. interessanten) Chip namens Rabbit2000 (ein Z80 on-speed)
http://www.staton.us/electronics/Rabbit/Rabbit_Forth.html
-
Weil ich diese neueste Version 4.44 aus 2020 derzeit nur einmal im Internet gefunden habe (ein Google-Drive),
hier die v4.44 von DX-Forth fuer CP/M-80 und MS-DOS
PS: Leider schluckt entweder puTTY oder RunCPM beim Start von DX-Forth den ersten Buchstaben der Zeile am Anfang (gibt sich nach ein paar Enter/Return)
-
Weil ich diese neueste Version 4.44 aus 2020 derzeit nur einmal im Internet gefunden habe (ein Google-Drive),
hier die v4.44 von DX-Forth fuer CP/M-80 und MS-DOS
Anscheinend handelt es sich dabei um ein FORTH gemäß dem94er-Standard.
-
Habe nun auf dem RPi Pico (mit angeschlossenem SPI-SDCard-Reader) Mecrisp-Stellaris Forth installiert
(musste fuer den SDCard-Support mit den Tachyon Extensions "gepatcht" werden).
War schon etwas Muehe notwendig, die Info zu finden
Aber es hat geklappt
-
Bei einigen Forth-Systemen die seriell angeschlossen/angesprochen werden wie Microcontroller
(Arduino, RPi Pico)kann man das Problem der Treppen-artigen (Stair-Stepping) Darstellung haben wie unter
https://mecrisp-stellaris-folk…air-stepping.html#e4thcom
zu sehen.Fuer Linux gibt es da das Kommunikationsprogramm (auch genannt auf obiger Seite) e4thcom
Bei Windows hatte ich eine Probleme bei der passenden Mischung/Konfigurations-Moeglichkeiten
fuer CR/LF bei Ein- und Ausgabe
(bei Tera Term sollte man dann NICHT CR+LF bei Transmit nehmen
bei puTTY/kiTTY sollte man die Haken setzen)Nun fand ich beim suchen/browsen im Netz einen Klone von e4thcom fuer Windows mit dem Namen escom
(das Windows Commandline-Binary dazu ist da im windows-Verzeichnis des github)
Das Programm hat in der Windows(10)-Commandline nur das Problem, dass das Commandline-Fenster keine
ANSI-Codes mehr versteht wie es damals unter DOS mit ANSI.SYS war
Da fiel mir mein "alter Freund" ANSICON ein, den ich schon mal bei RunCPM 5.1 genutzt hatte fuer die Windows-Version.
ANSICON (v1.89) ist ein ANSI-wrapper/-parser fuer Windows-Commandline-Programme.
D.h. man muss das zu nutzende Programm mit dem ANSICON davor aufrufen wie z.B. hier fuer escom:
ansicon escom -d COM41 -b 38400 -t mecrisp-stIch hoffe, die Information hilft/nutzt hier eine Forth-Nutzer
-
-
D.h. man muss das zu nutzende Programm mit dem ANSICON davor aufrufen wie z.B. hier fuer escom:
ansicon escom -d COM41 -b 38400 -t mecrisp-stIch hoffe, die Information hilft/nutzt hier eine Forth-Nutzer
Da die escom-Version nur bis 115.200 Baud ging (im Gegensatz zur e4thcom-Version, die auch 921.600 Baus kann) habe ich mit dem TDM-GCC-32 die escom-Version neu kompiliert, damt sie auch bis zu 921.600 Baud versteht.
Dazu musste ich die neuen Baudraten in der /TDM-GCC-32/include/winbase.h hinzufuegen als Definition,
hat der Compiler aber dann "geschluckt"
Wer also mehr als 38.400/115.200 nutzen mag, kann dies nun tun
-
..,. da braucht man aber schon sehr, sehr flinke Finger beim Tippen, um an diese Grenzen zu stoßen ...
-
..,. da braucht man aber schon sehr, sehr flinke Finger beim Tippen, um an diese Grenzen zu stoßen ...
das ist auch eher fuer den File-Upload brauchbar, wenn man in mecrisp-stellaris eine .FTH Datei pasten und icht so lange warten will
OK - auch mit 38.400 Baud war es nicht so langsam - die meiste Zeit sind die Delays zwischen den Zeichen (1ms) und den Zeilen (15ms) um nicht den Inputbuffer zu ueberlasten -
Kleine Weihnachts-Rechenaufgabe:
(Annahme von 8 bit, 1 start und 1 stop bit = 10 bits pro Zeichen)
921600 baud / 10 = 92160 Zeichen pro Sekunde, also 1/92160 Sekunden pro Zeichen = 0.01085 ms, dann 1 ms delay.
Macht also 1.01085 ms pro Zeichen = effektiv 989.26 Zeichen pro Sekunde
Bei 9600 baud ohne delay:
9600 baud / 10 = 960 Zeichen pro Sekunde
Hoffentlich habe ich mich nicht verrechnet
Ich glaube, alles über 57600 oder so merkt man dann kaum noch. wegen des overheads.
-
Ich glaube, alles über 57600 oder so merkt man dann kaum noch. wegen des overheads.
kann schon passen - beim Upload eines knapp 90KB .FTH komme ich durch die delays bei 38.400 und bei 921.600 auch immer auf ca. 35 Sekunden.
Allerdings ohne delays klappt der Transfer bei 921.600 - bei mir - nicht sauber bis zum Ende
[EDIT] BTW: Ed Smallenburg hat auf meinen Hinweis hin seine Version von 0.1.2 auf 0.1.3 angehoben, die nun auch 921.600 Baud unterstuetzt - siehe https://github.com/Edzelf/escom
-
Die große Frage ist ja nun aber: was machst Du mit dem Forth nun. Eigentlich nett wäre ja so ein Benchmark, der exakt das gleiche Apfelmännchen zeichnet wie das, was hier immer mal für BASIC auftaucht. Da könnte man schön vergleichen.
Genau das gleiche habe ich nicht, aber mal eins, dass unter Mecrisp-Stellaris Fort auf dem RPI Pico laeuft
Baut sich in unter 3 Sekunden auf
Zu finden ist der Code hier
-
Als Uebung/Training/Neugier habe ich mit dem TDM-GCC(32/64) auf WIn10 und MinGW64 auf Ubuntu mit Wine-Hilfe
PForth V28-LE compiliert - und nicht mit MS-Visual-Studio (ist mir viel zu gross als Compiler).pForth - Portable Forth in 'C'
Leider ging es wegen Fehlern beim kompilieren nicht mit einem Rechner/Betriebssystem.
So musste ich zwischen den Schritten jeweils Teile der Kompilierung zwischen den Systemen umkopieren, da komischerweise immer nur ein System einen Schritt sauber machte.Nachdem es fuer die 32Bit Version gestern etwas laenger dauerte, ging die 64Bit Version heute schneller von der Hand.
Leider ist es bei den Makefiles nicht vorgesehen PForth einfach nur unter Windows mit dem TDM-GCC zu kompilieren
Hier fuer Euch die 32Bit/64Bit Version fertig kompiliert
-
-
Alternativ ist auch dies fuer naechstes Jahr nutzbar
-
Ein sehr kurzes Mandelbrot-Programm - laeuft aber leider nicht auf jedem Forth
Code
Alles anzeigenHere you can see the power of Forth in action. \ A Mandelbrot set recursion in just 6 lines of Forth ! fvariable ci fvariable c fvariable zi fvariable z CR : >2? z f@ fdup f* zi f@ fdup f* f+ 4.0e f> ; : nextr z f@ fdup f* zi f@ fdup f* f- c f@ f+ ; : nexti z f@ zi f@ f* 2.0e f* ci f@ f+ ; : pixel c f! ci f! 0e z f! 0e zi f! 150 50 do nextr nexti zi f! z f! >2? if i unloop exit then loop bl ; : left-to-right -1.5e 80 0 do fover fover pixel emit 0.026e f+ loop fdrop ; : mandelbrot ( --) -1e 40 0 do left-to-right cr 0.05e f+ loop fdrop ; mandelbrot \ execute mandelbrot
-
... ja, das ist einer der Schwachpunkte von FORTH - Fließkomma-Operationen waren leider nicht in den ersten Versionen enthalten und werden dann immer unterschiedlich nachgerüstet. Für Portabilität müsste man eine Fließkomma-Bibliothek mit dazupacken.
-
Ein sehr kurzes Mandelbrot-Programm - laeuft aber leider nicht auf jedem Forth
Unter Gforth läuft es.
Edit: Ah, ich sehe grad, dass du es auch in Gforth laufen hast.