Beiträge von guidol

    In abstraction_posix.h findet sich kein conio.h, sonst wäre es ja nicht "POSIX" ... putch ist bei DJGPP in conio.h, aber putchar ist natürlich in stdio.h ... welche "platform" wird denn mit make build für den DJGPP benutzt?

    den make starte ich "natuerlich" mit

    make dos build


    Versuche ich unter DJGPP
    make build

    fragt er platform


    Mit

    make posix build

    klagt er natuerlich ueber viele fehlende "Librarys".


    Und ersetzen der conio durch stdio hilft leider auch nichts an der Ausgabe :(

    Zitat

    The putch() and cputs() functions may be good choices for text output in a 16-bit real-mode OS. Both the DJGPP and Turbo C versions use BIOS interrupts but not DOS interrupts.

    Die abtract.h nutzt wie die abtraction_posix.h die conio.h - aber DJGPP verahelt sich wie Turbo C :(

    conio.h - Wikipedia


    Zitat

    The library functions declared by conio.h vary somewhat from compiler to compiler. As originally implemented in Lattice C, the various functions mapped directly to the first few DOS INT 21H functions. The library supplied with Borland's Turbo C did not use the DOS API but instead accessed video RAM directly for output and used BIOS interrupt calls.

    In abstraction_posix.h wird einfach putchar genommen, gibt es natürlich auch bei DJGPP ...

    putch gibt es auch bei DJGPP
    Ich habe putchar getestet, aber der ist laut Doku eher verwandt mit den File-Command fputc (nach std-out)


    Sebst wenn ich putch gegen putchar tauschen koennte und der wuerde DOS Interrupts machen ist immer noch puts, der auch BIOS-Interrupts macht....


    Ich denke ohne passende Inline-ASM commands ist DJGPP dazu nicht in der Lage es als DOS-Interrupt auszugeben :(

    clrscr ist als
    system ("CLS");

    definiert....


    Koennte man als Quick-Dirty Hack nicht das system (DOS-command) ECHO nehmen um Char/Zeichen oder String auszugeben.

    Ich wuesste nur nicht, wie ich die Variable des unit char oder string da rein bekomme


    Fuer den String geht es wohl unfefaehr so:

    char * command = "ls -l /non-existent";
    system( command );


    Also eine Variable fuer "ECHO " une eine fuer den String und diese dann vereint an system uebergeben


    Bei einem einzelnen Zeichen muesste man von ASCII auf String umwandeln.... und dies an "ECHO " anhaengen.


    Nur ob ECHO bei einzelnen Zeichen keinen CR oder LF macht?

    Der RunCPM-Source nutzt

    _putch (putch) und

    _puts (puts)


    aber nach

    OSD: Putting text on the screen

    nutz DJGPP dabei nur BIOS Interrupts :(

    Zitat

    The putch() and cputs() functions may be good choices for text output in a 16-bit real-mode OS. Both the DJGPP and Turbo C versions use BIOS interrupts but not DOS interrupts.


    Bei diesen Befehlen gibt es bei puts auch kein Ende-Stringzeichen wie /0 oder $ da der String ja durch "" begrenzt uebergeben wird.


    Leider kann ich selbst kein Assembler um eine Inline-Routine zu basteln....kann ich irgendwo die genannte Borland-Variante sehen?


    Und: putch hat als Eingabe eher einen ASCII-Wert, weil ch (fuer chard) ein uint8 ist und kein char :(

    Das sieht so aus, als ob die Bildschirmausgabe nicht via DOS-Interrupts geschieht, sondern via BIOS-Interrupts.

    Hmm - im Source gibt eine "Funktion" _puts fuer "put string" - die muesste ich mir mal ansehen.

    Fuer DOS-interrupt Ausgabe habe ich au folgender Seite:

    https://nullprogram.com/blog/2014/12/09/

    im Bereich "Hello World in DOS"

    was an Source gefunden, der evtl. passen koennte.

    Muss ich Morgen mal ansehen...

    Oder hast Du noch einen Source/Link Tipp?

    Tux  Martin Hepperle  Peter z80.eu

    Heute habe ich mir nochmal den DJGPP vorgenommen - diesmal unter Win7 auf einem Netbook ;)

    Damit habe ich es heute geschafft eine unter DOS (16Bit) lauffaehige Version zu erstellen, die diesmal das vollstaendige DIRectory anzeigt.

    (OK - die braucht CWSDPMI.EXE als Extender)


    Genutzt habe ich


    gcc1020b kennt wohl die Commandline-Option -mconsole nicht mehr.
    Alle ANSI-Ausgaben laufen ins leere trotz ANSI.SYS in der CONFIG.SYS


    Fuer den compile war also wichtig die Linker-Option -mconsole raus zu nehmen und auch die Option

    -Wno-pointer-sign im gcc compile reinzunehmen.


    Der gcc346 wohl noch die Option -mconsole - aber auch da erkennt die Console die ANSI-Ausgaben nicht (z.B bei Wordstar).


    PS: In Win7 habe ich in der Console "nur" eine englische Tastatur - aber im deutschen MS-DOS 6.22 klappt die deutsche Tastatur.....


    Anbei eine compilierte Test-version von RunCPM v4.4 und v5.7


    Empfohlen von https://www.delorie.com/djgpp/zip-picker.cgi auf
    FTP Site: http://www.delorie.com/pub/djgpp/current/


    heute Nacht kam mir eine "bloede" Idee in den Sinn ;)
    Warum nicht anstatt dem DJGPP den TDM-GCC fuer 16Bit nehmen?


    Im Kopf war es soo einfach. Einfach den Compile-Flag von -m32 (oder -m64) auf -m16 umstellen.


    Leider macht mir der Compiler/Source einen Strich durch die Rechnng, weil der Assembler wohl werte groesser 65535 speichern wollte und somit einen int16 ueberstieg(?)


    Leider wird die .s Datei nach dem erfolglosen Compile gleich geloescht, so kann ich nicht mal versuchen zu erkennen was da so hohe Werte reinschreiben will.

    Eigentlich dachte ich, im SOurce seien alle int Werte jeweils sauber definiert (uint8, uint16 und uint32)

    aber es wird wohl irgendwo ein int ohne Angabe genutzt (denk ich) der dann bei weniger als 32bit Umgebung nur 16bit ist und muesste vom Wert der reinpassen sollte 32bit sein :(


    Nun ja - war ein Versuch....


    Ausgabe beim compile:


    Als Info, da ich es bis jetzt nicht getestet hatte....


    Das schalten der GPIOs geht auf auf dem RunCPM Pico Port, wie auf dem RunCPM Arduino DUE Port


    D,h, ich konnte erfolgreich die gruene OnBoard-LED an Pin (GPIO) 25 mit den Beispiel-Programmen LED.BAS und LED.PAS aus dem ArduinoInterface-Ordner vom original RunCPM-github ein- und ausschalten.


    Ich gehe mal davon aus, dass dies dann auch erfolgreich fuer andere GPIO-Pins/Nummern klappen wird

    (habe leider gerade keine LEDs und passende Widerstaende zum testen)

    BTW: Aufpassen mus man beim uebertragen der Sources, da die bei mir als Linux-Zeilenende-Format vorlagen.

    Ich habe diese dann im NotePad++ auf Windows-Zeilenende (CR+LF) umgestellt.

    Dann konnte ich diese auch per Zwischenablage in die MBASIC/Turbo-Pascal-Editoren pasten.


    So ;) ich bin erstmal wieder zufrieden - durch 2 Loesungsansaetze:


    1) Ich habe keine Downloadprobleme mit der neuen Arduino IDE 2.0.0rc9.2
    Allerdings ist die in der Anwendung etwas anders - aber wenn man sich dran gewoehnt hat auch OK

    insbesondere die neuen Farb-Themes. Das helle gruene gibts nicht mehr, aber das dunkele finde ich eh besser lesbar und die neue(?) Schriftart ist fuer mich auch besser lesbar ;)


    Die 2.0.0rc9.2 erscheint im Gegensatz zur 1.8.x nicht in der Windows-Firewall mit der javaw.exe als Freigabe...


    2.) habe ich nach folgender Anleitung einen Squid-Proxy auf meinem armbian SBC aufgesetzt und den als manuellen Proxy in die Network-Settings der Arduino IDE 1.8.19 eingetragen.

    Der Download klappt da nun ohne Fehlermeldung (wenn auch genauso langsam wie in der 2.0.0rc9.2), auch wenn ich nicht weiss warum ueberhaupt eine kam.


    Anpassen musste ich fuer meinen Gebrauch die /etc/squid/squid.conf damit alle Clients aus meinem lokalen Netz zugreifen koennen (einen arduino User habe ich mit Passwort angelegt ueber htpasswd.



    In meiner Arduino IDE habe ich folgende 4 URLs (durch Kommas getrennt) in den Preferences im Feld
    Aditional Boards Manager URLs


    Code
    https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
    http://arduino.esp8266.com/stable/package_esp8266com_index.json
    https://github.com/earlephilhower/arduino-pico/releases/download/global/package_rp2040_index.json
    https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json


    Nun habe in in den letzten Tagen (oder 1-2 Wochen?) das Problem, dass je nach Tageszeit ich beim Aufruf des Boards Managers

    oder beim Start der Arduino IDE (weil diese automatisch nach Updates sucht) von einigen URLs eine Fehlermeldung im Messages-Fenster erhalte:

    Code
    Error downloading https://github.com/earlephilhower/arduino-pico/releases/download/global/package_rp2040_index.json
    Error downloading https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
    Error downloading https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json


    Dies hat vorher immer geklappt :(


    Im Chrome/Firefox Browser lassen sich die URLs aufrufen und es kommt auch das File zurueck.


    Windows Firewall (Apps ist berechtigt) und Pihole (github URLs sind in der Whitelist) habe ich gecheckt (sonst wuerde es auch nicht im Browser gehen in Bezug auf das Pihole)


    Auch mit deaktivierter Firewall/Pihole klappt es nicht.


    Das einzige was mir noch aufgefallen war, als mit aktualisiertem idex.json fuers RP2040 spaeter die Board-Unterstuetzung runterladen wollte, bekam ich eine lange Java-Fehermeldung die einen TimeOut anzeigte.


    So kann ich mir nur vorstellen, dass die Arduino IDE evtl. ein zu kurzes TimeOut hat und deshalb meint nicht an die Files zu bekommen....

    Im Browser geht es meist sofort, aber ab und zu braucht er auch mal 5-10 Sekunden :(


    Kann es an github liegen (routing im Internet?), da die URL arduino.esp8266.com bei der Fehlermeldung eigentlich nicht betroffen ist?


    Hat dazu jemand eine Idee/Hilde/Setting?


    Ich habe keine Einstellmoeglichkeit fuer ein TimeOut gefunden und in den Network-Settings der Arduino IDE ist auch No Proxy angehakt/eingestellt.




    wie angekuendigt im Thread Was hat Dich heute glücklich gemacht habe ich es nun nach 2 Jahren geschafft mein Pyboard v1.1 - via STM32Duino Arduino Core - mit RunCPM zu versehen ;)



    Source & Bilder & Infos findet Ihr in meinem github Repository RunCPM_Pyboard_v1_1


    FRACTAL (MBASIC) Speed-Test-Ergebnis


    Upload in der Arduino IDE erfolgt per DFU Mode


    Pyboard v1.1 im DFU Mode (3.3V verbunden mit BOOT/P1/DFU-Pin - dann Reset ausloesen)


    Die CPU

    Anscheinend ist mein USB-RS232 Adapter vorhin gestorben.

    Ich komme auf das Thema zurück sobald ich wieder eine Laufende RS232 habe.

    Du hattest nur einen? ;)
    Bei den Preisen nehm ich immer gleich nen 5er Pack (also die CH340 China USB-TTL - die laufen gut)

    CP2102 mag ich nicht so und die original FTDI sind mir zu teuer.


    Ansonsten kann man (wenn man hat) einen Arduino dafuer zweckentfremden :) der hat ja auch nen USB-TTL-RS232 drauf.

    Hallo Guidol,

    danke für Deine prompte Antwort. Ich probiere später Dein Binary aus und berichte dann.

    Bevor Du das Binarys ausprobierst.... ich hab wohl noch nicht viel Uebung mit der Nutzung/Angabe des seriellen Ports - im Gegensatz um USB.
    Ich wollte das Binary testen und musste feststellen, dass der Pico als USB-device nicht erkannt wird :(



    Also habe ich mir meinen alten Source vom 05.11.2021 angesehenund festgestellt, dass man bei setRX/setTX die GPIO-Nummern und nicht die Pin-Nummern angeben muss...deshalb wurde der Pico nicht als USB-Device erkannt :)


    Also aendert sich die Definition im Arduino .ino wie folgt:



    D.h. ich habe Dir ein neues Binary gemacht fuer GPIO0/GPIO1
    und habe es getestet mit einem ESP8266-Telnet-Modem :)


    Zum seriellen Port habe ich jetzt doch noch eine andere Info zu Serial. in Verbindung zu USB gefunden :(


    Serial. ist immer USB


    So gelten fuer den Earlephilhower Arduino-PicoCore laut einer Github-Issue also folgende Namen:
    (BTW: hatte vorher an Pin1/2 RX/TX vertauscht - OOPS)


    orion7 als Anhang mal ein Binary, dass Serial1. an Pin 1/2 nutzt mit 115.200 Baud
    (habe es aber noch nicht selbst getestet) ;)

    Jetzt habe ich noch eine Frage dazu: Und zwar möchte ich die UART benutzen.

    Nach dem Bild hast du die Pins 26,27 dazu verwendet. So wie ich das Pinning verstehe sind die UARTs aber auf den Pins 1/2 bzw. 6/7.

    Kannst Du mir einen Tipp geben wo mein Fehler liegt.

    ;) Bei Dir liegt kein Fehler vor - Du nutzt wohl nur ein anderes Pinout Bild :)


    Bevor ich RunCPM auf dem Pico umsetzte, nutzte ich auf einem meiner anderen Picos das Projekt Picomite.


    Da nach dem Pinout Bild des Picomite auf

    Pin 26 (GPIO20) COM2RX = Pin 7 (GPIO5) COM2RX

    und

    Pin 27 (GPIO21) COM2TX = Pin 6 (GPIO4) COM2TX

    die selben Signale moeglich sind, habe ich mit damals beim Picomite und RunCPM entschlossen die ganzen Kabel in einer Ecke "anzustecken" :)


    Im void setup des Arduino-Source koennte man am Anfang vor dem oeffnen des seriellen Ports die Pins definieren (entsprechendes auskommentieren und drauf achten, dass der Source normal Serial. (fuer USB) und nicht Serial2. (Pin 26/27) nutzt):




    Auf dem Standard Pinout Bild sieht man bei Pin 26/27 nur I2C SDA/SCL, aber auf dem Picomite Pinout Bild auch COM2TX/RX wie bei Pin 6/7


    Wenn es Dir wichtig ist, kann ich Dir auch mal ein Binary machen mit Pin 1/2 oder 6/7, aber wie Du auf der ersten Seite dieses Themen-Threads sehen kannst, habe ich auch eine TTL-serielle auch mal an COM1 Pin 21 (GPIO16) und 22 (GPIO17) genutzt - dass ist dann anstatt Serial2. dann Serial. in der Arduino-IDE.



    Leider evtl. nicht über C64 Niveau, aber wenn man als Einsteiger Kinder sieht, dann waere eine virtuelle Konsole prima zum Einstieg ;)


    Die nennt sich TIC-80 (Freeware):

    TIC-80 tiny computer
    fantasy computer for making, playing and sharing tiny games
    tic80.com


    images (18).jpeg

    images (1).png

    images (2).png


    oder Pico-8 (ca. $15) fuer eine kommerzielle Multiplattform Entwicklungsumgebung:

    PICO-8 Fantasy Console
    PICO-8 is a fantasy console for making, sharing and playing tiny games and other computer programs.
    www.lexaloffle.com