Posts by BlondMammuth

    He Leute, ich habs leider nicht geschafft, ich hoffe ihr habts es schön! :-)

    He super danke! :-)

    Ich kanns noch nicht sagen. Vielleicht schaf ich es!

    Ich selbst habe seit 2 Jahren in meiner DOS-Kiste einfache SD to IDE Adapter mit 8GB-Karten laufen. Die guten 1,6GB-Platten sind auch so langsam gestorben... Da habe ich eben 4x 2GB-Laufwerke draus gemacht und die Sache läuft zügig und rund. Hängt jedoch vom BIOS und vom DOS ab, wie groß das alles maximal sein kann. Die 'Emulation' funktioniert durch den Controller aber bei mir recht zuverlässig. Ist ne kleine Platine in etwa 2,5 Zoll-Größe. Das Ganze habe ich in einen SSD-Rahmen gefriemelt und in einen 3,5 Zoll Slot gebaut. Passt! Das würde ich empfehlen.

    Vielen Dank! Kannst du mir für die Adapter einen Hersteller nennen?

    Vielen vielen Dank erst einmal an Alle, ich krieg langsam ein klarers Bild. Meine Platte ist etwa eine 250MB-Platte gewesen, da ginge also praktisch alles. Die Breite muss ich mir anschauen - was war den typisch? Ich hab das problemlos in handelsübliche Wechselrahmen hängen können.

    SD an IDE gefällt mir als Lösung am Besten, und egal was ich da kaufe, es wird viel zu groß für die Zwecke. :LOL

    Hallo Alle, hier eine PC-Frage:

    ich habe noch alle meine PCs, beginnend bei einem 386. Bei den meisten funktionieren die HDs sogar noch, nur die vom 386 ist mir eingegangen. Daher die Frage: Hat jemand von euch Erfahrung damit, dermassen alte IDE Festplatten (so ca. Baujahr 1992) durch eine moderne Lösung zu ersetzen? Falls ja, welche würdet ihr da empfehlen? Und Achtung - weil mir die Verwechslung auch immer wieder beim Suchen unterkommt: Ich will nichtauf meine alte Platte zugreifen (die is hin), ich will mit meinem alten PC auf ein modernes Medium (wahrscheinlich USB-Stick oder micro-SD oder sowas) zugreifen (wobei, wenns was anderes ist, bin ich auch nicht böse).

    Und wo wir schon dabei sind: Bei meinem alten 386 gabs noch keine Selbsterkennung, da musste ich Zylinder, Spuren und Sektoren noch jeweils händisch eintragen. Wie geht sich das mit neuen Medien denn in dem Fall aus?

    Danke und LG!

    Aber ich hoffe, dass irgendwann auf europäischer Ebene Linux als Standard-OS (und FOSS für Software insgesamt) für Verwaltungen etc. vorgegeben wird. Das wäre dann DIE Chance, Desktop-Marktanteile zu generieren. Aber das hoffe ich schon recht lange. ;)

    Diese Hoffnung teile ich von Herzen, auch wenn ich eher skeptisch bin, ob es je so kommt.

    Ich verfolge das mit den Mac OS Versionen nicht, weil mich Apfel am Arsch lecken kann, seitdem sie auf PC-geräten (ja, ein Imac ist nichts anderes als ein PC) diese Philosophe des Schmeißweg fahren

    Ja, das ist unglaublich unsympathisch. Ich finde, hier könnte die EU wirklich wieder einmal ein wohltuendes Werk tun und schlichtweg diese Praxis (wenn geht rückwirkend) verbieten.

    Mein Ziel ist es, das irgendwie in VSCode zu integrieren. Aber ob ich das je schaffe, steht in den Sternen. :whistling:

    Vielleicht passiert da irgendwas von wegen Unicode? Denn die anderen sind lesbar wie zuvor.

    Der Bytestream wird als wohl als UTF-16 interpretiert (UTF8 wäre ja für Codes <128 ziemlich ASCII-konform). Du musst dem Editor wohl sagen, dass er das "nur" als Plain-ASCII (oder wenn er das kann als PETSCII) oder halt eine andere 8-Bit-Zeichencodierung. Gegebenenfalls muss man halt auch diverse Zeichen hin-her-konvertieren (um von/zu PETSCII zu kommen).

    Jetzt kommen wir der Sache schon näher. Die zwei Bytes sind die Lade-Addresse? Ich verwende plain files, ohne prg-Zusatz, aber wenn ich dich richtig verstehe, sind das trotzdem prg files. Ich gehe einmal davon aus, dass die gar nicht benötigt werden? OK, man soll mit solchen Annahmen immer sehr vorsichtig sein, aber Durex-Forth wird wohl selbst am besten wissen, wo es die hin lädt.

    Wenn ich ein C-Programm schreibe, das mir auf dem PC die beiden Bytes rausnimmt, sie sich merkt, und dann wieder hinzufügt, und wenn ich es schaffe, das an der richtigen Stelle in den VSCode reinzuklemptnern, wäre das schon sehr bequem. Nur weiß ich halt auch nicht so gut, wie man das dort macht. Aber ich kann ja einmal suchen gehen. Vielleicht kann man dort ja Filter und Pipes verwenden. Schaumamal. :D

    Durex-Forth hat aus meiner Sicht einen entscheidenden Nachteil, nämlich die Inkompatibilität seines File-Formats. Es ist tatsächlich nicht möglich, z.B. aus dem VICE heraus Files auf einer virtuellen 1541 in eimem Directory des File-Systems zu speichern, und die dann einfach mit einem PC-basierten Editor zu bearbeiten. Genau das wäre aber eine enorme Erleichterung, da der vi-clone "v" zwar grundsätzlich funktioniert, aber nicht perfekt. Er neigt dazu, irgendwann den Text nicht mehr korrekt darzustellen. Editierung und Text sind dann "out of sync". Während man meint, eine Zeile zu editieren, zerstört man sich in Wirklichkeit eine andere. Hier wäre die Verfügbarkeit ausgereichter Text-Editoren wirklich angenehm.

    Ahso? Wie speichert DurexForth denn das ab? Witzig, ich hab mir bei meinem 816er-Forth auch damit geliebäugelt, einen minimalistischen VI-Clone zu machen. Die Idee scheint verbreitet zu sein. Aber hat sich noch nicht verwirklicht. Naja, da kann ich mir das mal bei DurexForth mal ansehen ...

    Ich verwendet hier "plain" PRG-Dateien (sogar die ersten beiden Bytes, wo normalerweise die Ladeadresse steht, werden als "Inhalt" gesehen), die ich unter Linux als normale Textdateien editiere und dann mit etwas umwandeln (Newline, Tab, Kleinschreibung) als PRG-Dateien erstelle, was dann in ein Image kommt.

    Mit früheren Durex-Forth-Versionen ist das noch gegangen. In 5-0-0 ist da nur Bytesalat zu sehen. Oder warte, ich schau zur Sicherheit noch einmal nach!

    OK, jetzt bin ich ganz verwirrt. Eines meiner Files zeigt sich so:

    ꀁ‱മ䕒啑剉⁅佃偍呁㈍⸠刍充䥕䕒匠剔䍕ൔ″മ䕒啑剉⁅剁䅒൙‴മ䕒啑剉⁅呚䉁㔍⸠刍充䥕䕒䜠塆഍䕒啑剉⁅䱔䌭䕒呁൅ㄍ‰‮∮䄠剒奁䕔呓•䕋⁙剄偏䄍剒奁䕔呓഍䕈൘ㄍ‱‮∮䠠剉卅䕔呓•䕋⁙剄偏㨍䠠剉卅䕔呓഍†䥈䕒൓†〱䌠剌佃ൌ‍㈠〰〠䐠൏††⁉啄⁐䱐呏‍䰠住൐‍䬠奅‍䰠剏卅㬍഍㈱⸠䠍剉卅䕔呓഍㌱⸠഍佃䕄㸠㠾‍䴠䉓䰠䅄堬‍䰠䉓匠䅔堬‍〠䰠䅄⌬‍䴠䉓匠䅔堬‍删協ബ久ⵄ佃䕄഍㐱⸠഍›䕗䝉呈⠠堠夠䠠䝉䉈呙孅⩘嵙⤠‍⠠堠夠⤠‍⨠⠠堠夠⤠‍㸠㠾⠠删䠽䝉孈⩘嵙㸾‸ഩ഻ㄍ‵മ㨍㌠䷄偁⠠堠夠娠ⴠ‭员夠⁔ഩ†⁛䕈⁘൝†啄⁐刾⠠堠夠娠删›ⴭ娠⤠‍⼠⠠ⴠ‭⁘⽙⁚㩒娠⤠‍尠䐠偕⸠•⽙⁚•മ†〸⬠⠠堠夠⁔㩒娠⤠‍尠䐠偕⸠•呙∠⸠‍匠䅗⁐
ⴭ夠⁔⁘㩒娠⤠‍删‾
ⴭ夠⁔⁘⁚ഩ† 
ⴭ夠⁔⽘⥚‍尠䐠偕⸠•⽘⁚•മ†〸⬠⠠ⴠ‭呙堠⥔‍尠䐠偕⸠•员∠⸠‍匠䅗⁐
员夠⁔ഩ഻㨍䜠呅促剏卄⠠☠䱔䤠ⴠ‭⁘⁙⁚ഩ‍嬠⸠•㘱ㄮ•൝†啄⁐⁘⁀
否孌嵉吠孌嵉堮⤠‍嬠⸠•㘱㈮•൝†坓偁⠠吠孌嵉堮☠䱔䥛⁝ഩ†⁛∮ㄠ⸶∴崠‍䐠偕夠䀠⠠吠孌嵉堮☠䱔䥛⁝䱔䥛⹝⁙ഩ†⁛∮ㄠ⸶∵崠‍匠䅗⁐
䱔䥛⹝⁘䱔䥛⹝⁙否孌嵉⤠‍嬠⸠•㘱㘮•൝†⁘⁀
䱔䥛⹝⁘䱔䥛⹝⁙䱔䥛⹝⁚ഩ഻ㄍ‷‮∮吠䵉䱅义큅佌≔䬠奅䐠佒൐㨍吠䵉䱅义큅佌ൔ†⁛䕈⁘൝†䥈䕒൓†〱䌠剌佃ൌ†〲〠䐠൏††⁜⁉മ††⁉䥔䕍䥌䕎堠尠䀠䐠偕唠മ††⁉䥔䕍䥌䕎夠尠䀠䐠偕唠മ††⁉䥔䕍䥌䕎娠尠䀠䐠偕唠മ††剃‍†㌠䷄偁尠⸠•员•啄⁐⹕‍††⁜坓偁⸠•呙•啄⁐⹕‍††⁜坓偁‍†倠佌ൔ††剃‍†尠䬠奅䐠佒൐†佌偏‍䬠奅䐠佒൐†佌䕒൓഻ㄍ‸മ名䵉䱅义큅佌ൔ佌䕒S

    Vielleicht passiert da irgendwas von wegen Unicode? Denn die anderen sind lesbar wie zuvor.

    Jetzt habe ich wirklich ein Gerücht gestreut, tut mir leid!

    Update: Wenn du eine Lösung für das Ding mit den ersten zwei Bytes hättest, köntnest du sie mir dann verraten? Danke!

    So - Erfahrungen mit Durex-Forth bis jetzt:

    Abgesehen von der hier schon diskutierten kleinen Unkompatibilität bin ich an sich sehr glücklich über diese Implementierung, die wirklich viel kann. Über FORTH selbst brauche ich nicht viel sagen, das ist für kleine Berechnungsprogramme sehr gut, für Anwendungen mit komplexeren Datenstrukturen sehr gewöhnungsbedürftig und auch schwierig. Aber da bin ich vielleicht noch zu sehr Anfänger, das soll jetzt kein Werturteil sein.

    Durex-Forth hat aus meiner Sicht einen entscheidenden Nachteil, nämlich die Inkompatibilität seines File-Formats. Es ist tatsächlich nicht möglich, z.B. aus dem VICE heraus Files auf einer virtuellen 1541 in eimem Directory des File-Systems zu speichern, und die dann einfach mit einem PC-basierten Editor zu bearbeiten. Genau das wäre aber eine enorme Erleichterung, da der vi-clone "v" zwar grundsätzlich funktioniert, aber nicht perfekt. Er neigt dazu, irgendwann den Text nicht mehr korrekt darzustellen. Editierung und Text sind dann "out of sync". Während man meint, eine Zeile zu editieren, zerstört man sich in Wirklichkeit eine andere. Hier wäre die Verfügbarkeit ausgereichter Text-Editoren wirklich angenehm.

    Ich mache es derzeit aus leidvoller Erfahrung so, dass ich parallel immer auch in PC-Files mit editiere, und dann notfalls deren Inhalte über die "paste"-Funktion des Vice in ein File einfügen kann, wenn ich ein kapuittes File rekonstruieren muss.

    Ich denke, sobald der "v" ausgereift ist, ist das kein Problem mehr, und wer weiß, vielleicht kommt ja von den Autoren irgendwann auch Hilfe bezüglich der externen Editierbarkeit.

    Mein Fazit: Immer noch empfehlenswert, wenn auch mit leichten Mängeln.

    Also totales Schwein gehabt und unverdient gewonnen. :thumbsup:

    Bloß eines verstehe ich nicht: Es war ja schon einmal runtime. Wieso die Exkursion in dieser Version?

    Github-Change zeigt die jüngste Korrektur.

    Was heißt hier "runtime"? Gemeint ist, dass es irgendwann einmal schon nicht nur zu Compile-time funktioniert haben soll (zur Interpreting-time), oder? Scheint schon 2019 zurück liegen, wo die Reduktion auf Compile-time gemacht wurde: Github: base.fs

    Wohl deswegen, weil S" keine transienten Puffer verwendet hat (nur rutimentär implementiert war), also mehrere Angaben nicht möglich waren. D.h. es hat nicht so funktioniert, wie es laut Standard vorgesehen ist. Der String wird immer am Beginn des freien Dictionary-Speichers angelegt und mehrfach angegebene Strings überschreiben sich ...

    Oh ja, danke, das ergibt Sinn! Das heißt, bis jetzt war es eine kaputte Krücke, die Beschränkung auf Compile-Time ist sowas wie ein Baustellen-Zaun, um die Reparatur zu ermöglichen, und sobald das repariert ist (was es mittlerweile wohl schon ist), funktioniert dann auch die Runtime.

    Das Witzige daran ist ja, dass es ansonsten für die Runtime noch .( .. ) gibt, das aber den String sofort ausgibt. Warum der speicher-Mechanismus in dem Fall zur Runtime geht und sonst gar nicht, ist mir ein Rätsel.

    Weil es direkt konsumiert wird, womit es einfach in den Textpuffer geladen werden kann, ohne dass es die Erwartung gibt, dass der String ne Weile überlebt (und zum Beispiel erstmal zwei Strings eingelesen werden, mit denen dann gearbeitet werden soll, aber leider nur noch einer übrig ist).


    Man kann sich ja ein runtime s" selbst basteln, wenn man unbedingt will, und dann weiß man wenigstens, wie die Strings abgelegt werden (und kann das Verhalten nach Bedarf anpassen)

    OK, danke, wieder was gelernt.

    Gut, ich versuch das einmal, vielleicht gelingt es mir. Ich bin eher ein Anfänger in FORTH (merkt man eh :D), aber das ist sicher eine gute Übung wie schon das cat heute, von dem ich viel gelernt habe.

    Bloß eines verstehe ich nicht: Es war ja schon einmal runtime. Wieso die Exkursion in dieser Version?

    Aber so generell wundert mich trotzdem, dass die String-Definition mit dieser Version auf einmal compile-time-only geworden ist. Ist das überhaupt Standard-Konform? :org: .. OK, das ist eher eine Frage für

    Da geht es weniger um Compile-Time, sondern, wo der Parameter angegeben wird. Üblicherweise müsste ein Parameter in Postfix-Notation angegeben werden. Nur wenn man einen Dateinamen *nach* dem Kommando haben möchte, muss man sich eigentlich einem Parser-Konstrukt beanspruchen. Das ist aber im eigentlichen Sinne nicht der "Forth-Spirit", sondern spiegelt die Erwartungshaltung aus anderen Umgebungen wider.
    Es müsste eigentlich ." Datei" CAT. Das Problem damit ist, dass man hier nur einen String angeben kann, da der immer am gleichen Ort liegt. Damit mehrfache Parameter möglich sind, gibt es laut Standard S" Datei1" S" Datei2" KOMMANDO, wo die Strings jeweils in entsprechende (ev. zirkulär) verwaltete Puffer gelagert werden. Und S" ist explizit für den interaktiven Gebrauch gedacht. Zumindest laut Forth-2012-Standard. Käme mir komisch vor, wenn das ausgerechnet bei DurexForth nicht so sein sollte.

    Ja eben, mir auch. Übrigens danke für die Aufklärung, wieder was gelernt. Und jetzt zum Zitat:


    s" ( — caddr u )

    Define a string. Compile-time only! Example: s" foo".

    in diesem File: durexforth-v5.0.0-operators-manual.pdf auf Seite 23 oben "Strings".

    Das Witzige daran ist ja, dass es ansonsten für die Runtime noch .( .. ) gibt, das aber den String sofort ausgibt. Warum der speicher-Mechanismus in dem Fall zur Runtime geht und sonst gar nicht, ist mir ein Rätsel.

    Nachtrag: Ich sehe grade, dass die spezialform parse-name sogar noch besser ist, weil auf einer UNIX-Plattform man ja i.a. auch keine Anführungszeichen benutzt. Vermutlich wirds für 1541-Files dann blöd, wenn die Spaces enthalten, aber darüber denke ich noch nach. Vielleicht ein Wort schreiben, das vom ersten Zeichen her den String anders benutzt, aber das ist einmal SF, vorerst freue ich mich über ein simples cat für die einfachen Fälle. :thumbsup:

    Wieso eigentlich? Gerade bei Unix muss auch doppelte oder einfache Anführungszeichen verwenden, um die besondere Bedeutung von Metazeichen und Trennzeichen zu unterdrücken. Das hängt auch da vom jeweiligen Anwendungfall ab.
    Unter Forth ist es üblich Strings explizit in doppelte Anführungszeichen zu führen. Metazeichen in dem Sinne gibt es nicht, nur etwaige Trennzeichen (Steuerzeichen und Leerzeichen etwa bei WORD).
    PARSE-NAME ist ja eigentlich nur für die typischen Wortnamen gedacht, verhält sich aber neutraler als das klassische WORD (abgesehen auch vom anderen Rückgabeformat).

    Du hast völlig recht, aber so ist es erst einmal viel einfacher geworden. :D

    Nachtrag: Wollte ich es UNIX nachmachen, müsste ich als Erstes die Pipe nachbilden, und das wäre einerseits absolut geil - aber andererseits wäre ich damit erst einmal ganz fürchterlich überfordert. :baby2: :lol27:(.. und der C64 vermutlich auch.)

    OK, hier das Ergebnis:



    Es funktioniert soweit (und viel schneller als ich dachte), ich bin aber nicht sicher, ob nicht eventuell ein Character am Schluss doppelt ausgegeben wird wenn st<>0 ist, weil st ja erst danach gecheckt wird. Und ob das "guter Code" oder "Stil" ist, wage ich auch nicht zu sagen. Falls jemand daran herummäkeln möchte, bitte gern, ich kann daraus ja nur lernen! :spassbremse: :LOL

    Ah, super, danke, das ist ja einmal ein Tip! :thumbsup:

    Muss ich noch verstehen lernen, aber das werde ich. :thnks:

    Und sicherstellen, dass zu dem Zeitpunkt mit "decimal" die Zahlenbasis 10 ist. ;)

    Auch dafür danke, aber das wird hoffentlich mit der Definition eines Wortes gegessen sein? Hoffe ich jetzt einmal. :zustimm:


    Aber so generell wundert mich trotzdem, dass die String-Definition mit dieser Version auf einmal compile-time-only geworden ist. Ist das überhaupt Standard-Konform? :org: .. OK, das ist eher eine Frage für :rtfm: :lol27:


    Nachtrag: Ich sehe grade, dass die spezialform parse-name sogar noch besser ist, weil auf einer UNIX-Plattform man ja i.a. auch keine Anführungszeichen benutzt. Vermutlich wirds für 1541-Files dann blöd, wenn die Spaces enthalten, aber darüber denke ich noch nach. Vielleicht ein Wort schreiben, das vom ersten Zeichen her den String anders benutzt, aber das ist einmal SF, vorerst freue ich mich über ein simples cat für die einfachen Fälle. :thumbsup: