Beiträge von guidol

    Ich habe nach wie vor das Problem, daß das Schreiben von Dateien mit cpmtools (V2.20) auf

    Drive C (diskc.cpm.fs) das Filesystem beschädigt !
    Lesen von diskc.cpm.fs mit den cpmtools ist ok.

    Mit den cpmtools von kkaempf funktioniert jetzt auch Schreiben auf Drive C. :)

    https://github.com/kkaempf/cpmtools/tree/master

    Auf der Original morio-de-cmptools-Webpage ist noch die v2.23 genannt, aber geht man direkt in
    das Files-Verzeichnis findet man "schon" die v2.24 (vom 2023-08-14 19:46 mit 177K).


    Changelog:



    Mit der v2.24 und dem em68k-diskdefs-Eintrag klappt es auch mit der diskc.cpm.fs

    solange man nicht GCC-10 (10.2.1-6) nutzt.


    Bei mir klappte es (funktiontuechtiger Transfer trotz Warnings beim compile) mit

    - NanoPi A64 mit armbian Bookwork (debian 12) - GCC-12.2.0-14

    - Windows-cygwin 64Bit - GCC 11.4.0

    - LinkIt Smart OpenWrt 23.05 - GCC 12.3.0

    Probier mal das fractal zum Fliegen zu bekommen und dann, wenn das klappt, probier das mit dem tbasic erneut.


    ngc224  Peter z80.eu tofro ThoralfAsmussen

    Danke fuer "Mut machen" ;)


    Und ihr werdet kaum glauben was es fuer ein aergerlicher Fehler war:

    compiliere ich die cpmtool von kkaempf (2.21) oder original moria.de cpmtools (2.23) auf meinem NanoPi Neo2 mit dem (dort bei der OS-Version mit Kernel 6.4.12) Stanard GCC-10 bekomme ich eine Version, die nicht immer alle Daten sauber uebertraegt :(


    Auf meinem NanoPi A64 mit GCC-12 (bei OS mit Kernel 6.6.2) kommt trotz Warnings beim compile (wie auch beim CygWin 64Bit) eine Version raus, die die Fiiles sauber uebertraegt.


    Meine compile-Fehler am Anfang waren auch Uebertragungsfehler z.B. vom tbasic.c und aber auch die read-Fehler bei der S.O und der CLIB


    Im tbasic.c fand der Compiler nichts, weil er woh gleich bei dem Wirrwar ein EOF erkannte und so auch ueber main motzte (weil er kein main fand).


    Aus Frust/Mut hatte ich alle 8 Disketteninhalte der CP/M-68k v1.2 in mein User 8 kopiert und selbst da complierte mit Muehen gerade mal ein "Hello World!" (das hatte ich als .C ueber den Editor eingepasted).


    Ans FRACTAL war nicht zu denken :( denn da hatte ich versucht per cpmcp ins 8: zu kopieren, konnte es aber weder TYPEen noch editieren :(


    Ich hatte es ohne Fehlermeldunf auf 8: kopiert bekommen, aber beim rueckkopieren ins Linux-Filesystem waren nur Hyroglyphen/Steuerzeichen zu sehen.


    Nachdem ich erst versucht hatte in MinGW oder MSYS2 dioe cpmtools zu compilieren, gelang es unter Warnings in Cygwin 64Bit und da klappt der Transfer des FRACTAL.C rein und raus ohne Fehler.

    Aus Neugier gegen den NanoPi Neo2 probierte ich es mit dem neuren OS des NanoPi A64 (GCC-12) und auch da klappte der Transfer :)


    So macht ich mich gleich dran mit dem neu gefundenen Wordstar-like SKED CP/M-68K Editor
    (den haenge ich zur Sicherheit auch mal hier mit dran)
    das FRACTAL.C auf mein mehr geliebtes FRAROUND.C umzustellen und zu compileren.


    Der Editor nutzt war Wordstar-Keys, allerding muss man zwischen den Command-Buchstaben die Control-Taste loslassen gegenueber echten Wordstar (und er zeigt dies auch nur in der Ctrl-J Hilfe und man muss es erstmal verstehen :) )
    Zusaetzlich mag der SKED wohl nur einen 80x25 Bildschirm :(


    Da dies jetzt endlich erfolgreich war, ist fuer heute erstmal Schluss, weil laut Euch eh nicht alles fuers TinyBasic (tbasic) vorhanden ist.


    Dafuer hier Bilder meines Wirkens von heute :)




    Überprüfe erst mal mit einem einfachen C Programm, ob der C Compiler richtig installiert ist.

    Mir scheint bei mir irgendeine Datei o.ae. zu fehlen - selbst beim FRACTAL bekomme ich eine Exception und vorher wie bei tbasic "Undefined symbol(s)" :(


    PS: clinkf.sub habe ich bei den .0 auf 2: gesetzt

    Gehe ich recht in der Annahme, dass am Ende des Compilierungsprozesses - vor der Code-Generierung - auch ein 'AS68' Aufruf erfolgt (weil eine Assembler-Source mit der Endung .S ebenfalls erzeugt wird) ? Wenn ja, da gibt es auch eine Option -U für den Assembler, um alle Subroutine-Aufrufe, die nicht direkt aufgelöst werden können, als "global" gehandhabt werden.

    Gibt es Beispielprogramme, die ohne Fehler compiliert werden können ?

    :) Schau mal in meinen ersten "Codeblock" in Zeile 4, da ist der as68 Aufruf mit -u


    Einen anderen Test-Code habe ich noch nicht in C compiliert unter simcpm CP/M-68k :(

    Ich habe ein TinyBASIC als C-Source gefunden und dachte ich versuche mal es auf CP/M-68 zu compilieren.


    Dazu habe ich den CPM-68K-C-Programming-Guide vom Nuni 1983 als PDF genommen (Anhang B1), aber die Befehle wollten nicht wie die da drin stehen :(


    Durch versuchen und andere Webseiten kam ich dann auf folgende Sequence;

    Code
    cp68 tbasic.c tbasic.l
    c068 tbasic.l tbasic.ic tbasic.st -f
    c168 tbasic.ic tbasic.st tbasic.s
    as68 -u tbasic.s

    Leider bekomme ich als Ergbnis nur bis zu folgendem:


    Bei lo68 ohne -r (relocate) (auch wenn ich in TBASIC.C die PROG_SIZE von 10000 auf 2048 setze)


    Code
    C>lo68 -o tbasic.68k 2:s.o tbasic.o 2:clib
    : Undefined symbol(s)
    _main
    
    
    C>tbasic
    Insufficient memory or bad file header

    und bei lo68 mit -r relocate:



    Hat jemand eine Idee dazu? Ich bin leider kein C-Programmierer-Experte :(


    Ausserdem komisch fand ich, dass wenn ich s.o und clib auf C im User 0 habe = 0:

    dann bekomme ich fuer die Dateien einen read-error :(


    Code
    lo68 -o tbasic.68k 0:s.o tbasic.o 0:clib
    oder
    lo68 -o tbasic.68k s.o tbasic.o clib

    Im simcpu liegen die Dateien zum Glueck im User 2 deshalb geht:

    Code
    lo68 -o tbasic.68k 2:s.o tbasic.o 2:clib

    Danke fuer den Tipp ;)

    Das Problem/die Loesung (per Hex-Editor in Windows und dann per FTP wieder ins DOS) )war es, aber das Problem ist der MS-DOS EDIT, der kein EOF (1A) anfuegt am Ende.

    So hilft mir der CP/M uemacs leider nicht direkt :(



    [EDIT] Habe mal Googleund ChatGPT gefragt und eine relativ einfache Loesung bekommen:


    Code
    COPY /A HELLO.BAS + NUL HELLO.BAS

    (solange mannoch nicht mit einem Hex-Editor dran gebastelt hat)
    Damit wird da benoetigte EOF-Strg-Z angefuegt :)

    So, jetzt gehts.

    Toshi Nachdem ich das mit


    Code
    RELOC CB68.REL CB68.68k
    CB68 HELLO.BAS
      => 10 PRINT "Hello World!"
    LINK68 HELLO,CB68.L68
    HELLO
    
    Hello World!

    auf dieser Seite gefunden hatte, fand ich auch hier diesen Thread ;)



    Leider weigert sich die DOS-Version CB86 da obige Hello-World mit CB86 zu bearbeiten.

    Es kommen ganz viele in der Zeile vesetzte ">^1" und fuer jedes mal (95x) bekomme ich einen Error angerechnet (95 erros detected)


    Sieht irgendwie so aus, als kommt er mit der Sektorgroesse der 2GB CF-Platte nicht klar oder mag er kein MS-DOS 6.22?


    Und das HELLO.OBJ hat dann 0 Bytes, so dass LINK86 auch nicht arbeiten kann :(

    Neben DECtalk nutze ich auch eine andere Softwareunter Android gerne:

    Home24 mit dem Home24-Mediaplayer


    weil da kann man - im Gegensatz zu DECtalk das man seriell anspricht - die Text-to-Speech Ausgabe per

    UDP-Netzwerkprotokol ansprechen:


    Code
    REBOOT_IP=$(hostname -I | awk '{print $1}'| rev|cut -d'.' -f 1|rev)
    TEXT='Eih Pieh '$REBOOT_IP' hat den Start erfolgreich beendet.'
    TTS="tts='"$JULIA_TEXT"'"
    # UDP
    echo $TTS|nc -w 1 -u 192.168.6.135 50002


    Als Ausgabe nutzt man damit dann die Standard-TTS-Voice (also Google-Voice oder man kauft sich guenstig die deutsche Stimme "Julia" bei acapella ;) )

    Für CP/M-68k gibt es einen

    CP/M-80 Emulator (em80.68k von Dr. Neuhbaus)

    und einen

    CP/M-Z80 Emulator (cpmz80.68k von SoftDesign GmbH Muenchen).

    ngc224 Da der com.68k Z80-CP/M-Emulator keinen der beiden obigen zu entsprechen scheint
    (ich konnte im com.68k mit dem HEX-Editor kein Copyright finden) moechtest Du den evtl. mal gegentesten?


    Bis jetzt habe ich damit nur mal MBASIC.COM gestartet (com mbasic.com) ;)

    Ich haenge das Binary mal an :)


    Ich habe mal den Autor des 68k-CPU-Kerns (Karl Stenerrud) - den cpmsim-68k nutzt - angeschrieben, weil beim compilieren des cpmsim die Meldung von Masushi Version 4.60 kommt, aber uf github in der readme.txt nur was von Version 4.10 steht.

    Laut Karl sind auf github die neusten Sourcen - so sollte man eigentlich ausgehen, dass Version 4.10 am neuesten ist, aber er hat in github nicht immer die Sourcen "sauber getaggt" ;)

    Das erkennt man wenn man (z.B. mit Notepad++) durch die Dateien suchen laesst:


    Da nach seiner Aussage auf github das neueste an Sourcen ist (auch 2 Jahre alt, wie bei dem Gesamt-Github-Paket von cpmsim inkl. Mashushi-Sorcen) hatte ich mal diese neuesten Sourcen ins cpmsim-Verzeichnis gepackt und wollte mit Cygwin 32&64Bit compilieren.

    Das gab am Ende einige Fehlermeldungen inkl. Abbruch, so dass ich alle Dateien mal einzeln durchgegangen bin und bei der m68kconf.h einige Unterschiede fand - die erstmal nicht den Compile behindern wuerden, aber dann am Ende der Datei war der "Boesewicht".
    Diesen hat wohl dann das cpmsim-"Team" eingefuegt ;

    Fuegt man diesen Part an die m68kconf.h der github Version an, laesst sich cpmsim auch wieder sauber mit Cygwin 32&64Bit compilieren.


    So habe ich das Sourcen-Verzeichnis inkl. der 32&64Bit compilerten Version (un deren RunTime-DLLs) mal in ein aktuell .ZIP gepackt und hier angehaengt ;)


    Ich nenne dies nun mal Version 4.10_github, auchg wenn in der m68kmake.c folgende Zeile
    (entgegen der readme.txt) eher auf eine Version 4.60 als aktuelle Version hinweist:


    Code
    static const char g_version[] = "4.60";

    Dann fehlt ja im Disk-Image nur noch ein BASIC-Interpreter und ein Compiler.

    CBASIC-68K scheint es ja zu gehen, und zwar >hier<.

    Beim gefundenen EHBASIC Interpreter ( RE: Basic-Interpreter für CP/M-68k bzw. RE: Basic-Interpreter für CP/M-68k ) scheint es keine Disk-Befehle zu geben, um bspw. Dateien zu öffnen (LOAD und SAVE geht).

    Peter z80.eu klaly
    Fuer den Interpreter koennen wir wohl nur ein wenig FAKE-en ;)
    com.68k ist der CP/M-Z80 Emulator und
    mbas68k.com ist ein Text-gepatches MBASIC v5.30 :)



    PS: Die CB68 und EHBAS v3.5.2 und v3.5.3 mit auf das C-Image aber ich weiss nicht wie ich die starte :(
    PS: Hatte hier nicht schon jemand CP/M v1.3 im Emulator? Wie bekommt man das upgedated von v1.2?

    Oder ein Proxy, der Webseiten umschreibt:

    https://github.com/atauenis/webone/wiki

    Das braucht natürlich einen ausreichend ausgestatteten Rechner im Netz für den Proxy selbst.

    Das hat heute bei mir geklappt mit der arm64-Version auf meinem NanoPi Neo2 (H5-CPU = aarch64).
    Einfach die Anleitung Punkt 4&5 fuer Android nehmen (ausser dass man Termux und Ubuntu installiert) wenn man schon armbian drauf hat :)

    Code
    wget https://github.com/atauenis/webone/releases/download/v0.16.1/webone.0.16.1.linux-arm64.deb
    apt install ./webone.0.16.1.linux-arm64.deb
    sudo touch /etc/webone.conf.d/my.conf
    sudo nano /etc/webone.conf.d/my.conf
    sudo service webone restart

    und dann unter DOS folgendes setzen in der CONFIG.BAT fuer MTCP
    (also IP nehmen Eueres SBC):


    Code
    SET HTTP_PROXY=192.168.6.24:8080

    Wozu braucht man den das?
    Dos-Spiele laufen doch in der https://www.dosbox.com/ und die bringt doch eine Soundblaster-Emulation mit.

    Und unter nacktem Windows kann man doch Dos-Spiele eh nicht starten

    Ich nach diesem Thread erst heute wieder nach einer Loesung fuer Intel-AC97 unter DOS gesucht, nachdem mein DOS-Rechner per MTCP-FTPSRV im Netz ist.


    Da es ein Industrierechner (DSM-600) ist (also eher ein besserer ThinClient-PC) und da ist AC97 onboard - auch wenn man !eine! PCI-Steckkarte einsetzen koennte.


    Fuer MPXPlayer und MOD-Files langt es schon mal ;) MP3 kratzt ein wenig :(


    Aber der 600Mhz Celeron (onboard geloetet) schafft dies schon :) Besser als kein Sound auf dem echten DOS-Rechner. Klar DOS-Box auf dem grossen PC wuerde auch gehen....aber so ist es eine andere Art von Spass :)

    Das original DECtalk ist schon etwas gross, aber so ein DECtalk express ist klein und handlich ;)

    Ich habe 1.5 DECtalk express :) Bei dem 0.5 ist leider beim Versand das halbe Gehaeuse kaputt gegangen :(



    Zusaetzlich gab es mal relativ kurz (gut lieferbar und relativ guenstig) das EMIC2 Modul (davon habe ich mir damals eins geschnappt - haette ich gewusst wie die im Preis steigen haette ich mal mehr genommen).



    EMIC2_CF.jpg



    Zum testen kann man gut mit der Windows-Demo-Software v4.61 spielen :)

    (Es gab auch eine Version / .exe, die konnte exportieren als .wav - so konnte man dies in Batchfiles nutzen oder Systemsound generieren)



    Zusaetzlich habe ich auch mal einen TOBY CHURCHILL LightWriter SL35M mit DECtalk drin ergatter.

    Den kann man aber meines Wissens nicht so am Terminal wie ein echtes DECtalk oder EMIC2 ;(



    Als TTS mag ich auch meinen Dolphin Apollo 2 ;)



    PS: Hier noch eine Info, wenn man sich fuers DECtalk express ein RS232-Ersatzkabel bauen will.
    PS2: Mein DECtalk Software Link Tipp *psst* :)

    Die Tage hatte ich ja sdchon mal davon geschrieben  im Bastelthread:

    Ich habe mich mal beschaeftigt (nachdem ich es mal lange vor hatte) mit dem Netzwerk unter MS-DOS.

    Genutzt wird - wie wohl von den meisten - MTCP mit einem DOS-Packetreiber.

    Mangels echter Netzwerkkarte nun hier per seriellem SLIP-Protokol und COM1: mit 115.200 Baud.


    Der erste erfolgreiche Test lief in Verbindung mit einem "SLIP-Server" per slattach-Command auf einem SBC mit armbian erfolgreich.

    Auf diesem konnte ich alle IPs in meinem privaten Bereich 192.168.6.x haben (.40/.41 fuer SLIP Poin2Point und die .99 als Server)


    Mit diesem Gedanken ging ich dann auch den - fuer mich - naechsten Schritt an, den SLIP-Server durch was noch kleineres (passend zu DOS) zu ersetzen: einem SLIP-Router (a.k.a. Server) auf einem ESP8266-Mikrocontroller :)


    Nun habe ich fast 1.5 Tage damit verbracht zu versuchen die IPs auf dem ESP8266-SLIP-Router so zu nutzen, wie mit dem slattach auf Linux (armbian) und scheiterte, weil ich keine Verbindung nach aussen bekam (wie andere auch - sogar der Autor von MTCP).


    Heute Nacht drehten dann die Gedanken und ich machte mich nachts um 02:00 nochmal daran, die YT-Videos zum Thema nochmal "langsam" durch zu sehen).


    Bei erneutem flashen/konfigurieren des ESP8266 (NodeMCU ESP-12F / 8266EX) durchbrach ich dann gedanklich die Netzwerkkonfiguration und versuchte weniger zu aendern und liess die beiden SLIP-IP-Adressen in Ihren Default-Werten (192.168.240.1 und 192.168.240.2).

    D.h. die SLIP-Verbindung ist in einem anderen Netzwerksegment als meine normalen Geraete mit 192.168.6.x

    Der ESP8266 holt sich per WLAN dann seine (feste - per MAC im DSL-Router) IP-Adresse im 192.168.6.x-Segment.


    Das war der Knackpunkt der mich zum Erfolg als ich die SLIP-IPs in diesem YT-Video nochmal sah und "verdaute" :)


    (weitere YT-Videos: 1 - 2 - 3)


    Zu diesem Zeitpunkt nutze ich - weil es eine Info zu DNS-Problemen in Bezug auf MTCP bei der Nutzung des ESP8266-SLIP-Routers bzw. dessen "original" Firmware gab - eine alternative Version der Firmware ;)


    Zusaetzlich muss ich zugeben, dass das flashen des ESP8266 - bei den ganzen Versuchen - nicht immer erfolgreich war.

    Mit dem Standard-esptool habe ich das flashen nicht lauffaehig hinbekommen, so bin ich auf das - bei mir erfolgreich getestete- Tool NodeMCU-Flasher vom NoideMCU-Team umgestiegen.


    Allerdings dies allein reicht beim probieren auch nicht immer allein, da wohl noch Reste/Parameter von Altkonfigurationen (wie WLAN-Konfig) im Flash waren.


    Geholfen hat dann in der Arduino-IDE den BLINK-Sketch zu flashen inkl. loeschen des kompletten Flash (gab tes dort bei den Optionen unter "Tools").


    Danach sauber mit dem NodeMCU-Flasher die .BINs geflasht (wobei auch der NodeMCU-Flasher manchmal hakte und 2-3 Anlaeufe brauchte).


    Aber jetzt laeuft es und ich habe wieder einiges gelernt :)


    Nun kann ich mit meinem MS-DOS-PC (DELL FX160 mit Atom 230 CPU - ich weiss viel zu schnell) per MTCP/SLIP/Telnet-Client ueber den ESP8266-SLIP-Router auf meine RunCPM-ESP32-Telnet-Version zugreifen :)







    Wenn ich es richtig erinnere, verfällt der (Bootloader des?) ESP8266 kurzzeitig in eine exotische Baudrate, bevor die Firmware „greift“. sind die Zeichen immer noch wirr, wenn man sie mit dem Oszi /LA betrachtet?

    Klar - jetzt wo Di es schreibst... Im Kopf hatte ich den Bootloader (mit den komischen 74880 Baud)
    nur fuer den ESP32-C12 bzw -S2 - fuer den ESP8266 hatte ich den nicht auf dem Radar.


    Beim booten gibt der ESP8266 sauber mit 74880 Baud folgendes aus:
    (kann man sich in puTTY anzeigen lassen - TELIX unter DOS kennt keine 74880 Baud :( )


    aber dann kommt nichts mehr (aber die Transfer-LED (GPIO2) blinkt beim senden/empfangen) :(

    Da ich es schon lange Zeit auf der Liste hatte, habe ich gestern meinen DOS-Rechner (DELL FX160) per MTCP/EtherSlip und seriellem USB-Kabel mit Hilfe eines SBC unter armbian ans Internet gebracht.


    Nach einigem suchen von passenden Config/Befehlen klappt es gut - ich kann sogar per Telnet auf mein EESP32-Telnet-RunCPM ;)


    Nun wollte ich einen Schritt weiter und einen ESP8266 per slip-router ohne das SBC aufbauen, aber es hakt bei den letzen Schritten nach der Umkonfiguration (die angenommen wird).


    MTCP kann weohl nicht mit dem Slip-Router sprechen, obwohl meine Verrkabelung stimmt (getestet mit einem seriellen Sketch und 115.200 Baud in TELIX).


    Leider kann man wohl beim Slip-Protocol nicht in TELIX erkenn, aber es kommen immer die selben wirren Zeichen, wenn man den ESP8266 resetet (NodeMCU und WeMOS D1 (non-minii) getestet 8266EX-Chipsatz)



    Ich bae dazu mal eine Issue in Github aufgemacht.


    Evtl. hat jemand von Euch das schin mal ans laufen bekommen?
    (auf Youtube haben es einige geschafft - z.B. hier und hier).

    Zur Information:
    mit der aktuellen ESP32-Core BETA v3.0.0-alpha2 laesst sich RunCPM fuer TTGO VGA32/FabGL zur Zeit noch nicht kompilieren, da die Kompatibilitaet der FabGL-Library (v1.09) noch nicht gegeben ist
    (Fehlermeldung bei der Timer-Komponente).


    Mit dem letzten aktuellen ESP32-Core v2.0.14 klappt noch alles :)