Wo bekomme ich die zugehörige Curl.exe her ?
Gibt es da ein Github Projekt ?
fuer mich sieht es so aus, als wuerdest Du hier fuendig werden...
Wo bekomme ich die zugehörige Curl.exe her ?
Gibt es da ein Github Projekt ?
fuer mich sieht es so aus, als wuerdest Du hier fuendig werden...
Hmm - und wo gibt's den Treiber oder Routinen dafür???
laut der Z80MBC-2 Software Seite:
S220718-R290823_IOS-Z80-MBC2.zip
The sketch for the IOS (with the needed libraries).
Unzip into a folder and open the .ino file (with Arduino IDE).
IOS must be uploaded into the Atmega32A flash.
Adds support for Fuzix OS
and the SPP Adapter board
(more info in the changelog inside the .ino file).
Seit Jahren hatte ich mein altes NAS - ein Zyxel NSA-320 - im original Karton fast ungenutzt rumstehen, weil es nur Samba SMB v1 kann
Da ich die Tage 2 Kirkwood Systeme (SheevaPlug und excito B3) auf debian 12 und auch jewels ein u-boot-Update gemacht habe, konnte ich mich mit den doch knappen Installangaben heute erfolgreich dran machen auch mein NSA-320 (auch eine 1.2GHz Singlecore-Kirkwood CPU) upzudaten.
u-boot gind vom original Zyxel u-boot v1.1.14 auf U-Boot 2017.07-tld-1
und das properitaere Zyxel System wird nicht mehr genutzt, sondern ueber USB debian 12 bookworm gebootet (damit ich irgendwann die Platte schlafen schicken kann)
Start-Install System war debian 12 mit einem v6.5.7 Kernel und fuer den gab es
dann noch ein Update auf v6.6.3
Und mit debian drauf muss da natuerlich auch RunCPM laufen
Linux nsa320 6.6.3-kirkwood-tld-1 #1
PREEMPT Tue Nov 28 23:25:58 PST 2023 armv5tel
================================================================
_____ _ _ _ ____ _ _________ ___
|__ / ___ _____| | | \ | / ___| / \ |___ /___ \ / _ \
/ / | | \ \/ / _ \ | | \| \___ \ / _ \ _____ |_ \ __) | | | |
/ /| |_| |> < __/ | | |\ |___) / ___ \_____|__) / __/| |_| |
/____\__, /_/\_\___|_| |_| \_|____/_/ \_\ |____/_____|\___/
|___/ debian 12 bookworm Marvell Kirkwood
================================================================
Last login: Sat Jan 13 18:51:53 2024 from 192.168.6.17
Linux version 6.6.3-kirkwood-tld-1 (root@tldDebian)
(gcc (Debian 12.2.0-14) 12.2.0,
GNU ld (GNU Binutils for Debian) 2.40)
Sat Jan 13 18:52:30 +03 2024 up 1 hour, 39 minutes
root@nsa320(192.168.6.32):~#
Alles anzeigen
auf Hackaday gibts eine "Grafikkarte" für PX-4 und PX-8 ..kennt die schon jemand?
könnte man die auch am HX-20 nutzen?
Fuer den HX-20 kenne ich bis jetzt nur Display-/Floppy-Emulatoren in Software.
Eine ist von Martin Hepperle hier im Thread
Die andere ist Flashx20 von "Norbert" - weitere Info/Bilder auch hier
Nach fast einem Jahr ist auch mal wieder mein PyBoard v1.1 mt nem Update dran.
Auch wenn es scheinbar garkeinen interessiert
den nach diesem Jahr scheint es immer noch das einzige PyBoard auf der Welt zu sein, auf dem anstatt Micropython RunCPM laeuft
upgedated wurde
- RunCPM von v6.0 auf v6.1
- STM32duino von v2.4.0 auf v2.7.1
- SdFat Library von v2.2.0 auf v2.2.2
Nachdem ich ein YT-Video gesehen hatte wie man FreeDOS 1.3 in qemu installiert dachte ich mir, dass waere auch fein fuer die 16Bit DOS-version von RunCPM
Ich habe heute mal in QEMU MS-DOS v6.22 und RunCPM 16Bit installiert und muss sagen, dass bei FreeDOS v1.3 die Bildschirmausgabe fuer RunCPM bis zu 4x schneller ist als unter MS-DOS v6.22
Bei der Berechung des FRACTAL Ausgabe kommen bei auf 2-3 Sekunden, aber z.B. bei der Ausgabe eines laengeren Directorys per DIR oder beim Start von Wordstar merkt man (also ich) den Unterschied deutlich.
Ausserdem mag qemu mit Acceletaor Option --accel whpx den MODE Befehl nicht mit dem CODEPAG SELECT
(bleibt daran beim booten haengen - wie FreeDOS beim CDROM Treiber, wenn man kein CDROM definiert)
(das glaube ich aber dann doch nicht... wird sich keiner die Mühe machen).
Bei der Installation habe ich einige CPU-Plattformen (wie auch AVR, Alpha, MIPS m68k, PPC, SPARC) abgewaehlt, aber von Z80 und NEC V20 war nicht zu sehen
Der qemu-Z80 scheint vor 15 Jahren eingeschlafen zu sein? Wobei mir der Name des Autor bekannt vorkommt:
https://github.com/davidgiven/qemu-z80
Ahh deshakb : https://github.com/davidgiven/cpmish
Kurze Frage.... gibt es eine zweite ser. Schnittstelle?
Der Pico hat zwar selbst noch 1-2 serielle Schnittstellen, aber leider sind die in RunCPM nicht ueber CP/M ansprechbar
Bis jetzt hatte ich mal seriell anstatt USB-seriell ausgegeben oder an 2 serielle den Text gleichzeitig um dass dann extern mit einem LCD abzufangen, dass an einem 2ten Microcontroller per serieller horschte.
Die CP/M-devices PUN: und LST: sind im Source auf Dateien gelegt - evtl. kann man mal ueberlegen z.B. PUN: als Ausgabe anstatt in eine Datei auf eine serielle Schnittstelle zu geben - wenn sich dafuer ein Programmierer findet....
ZitatPrinting
Printing to the PUN: and LST: devices is allowed and will generate files called "PUN.TXT" and "LST.TXT" under user area 0 of disk A:. These files can then be tranferred over to a host computer via XMODEM for real physical printing. These files are created when the first printing occurs, and will be kept open throughout RunCPM usage. They can be erased inside CP/M to trigger the start of a new printing. As of now RunCPM does not support printing to physical devices.
RunCPM v6.1 Update des RP2040 Core von v3.6.0 auf v3.6.3
fuer RPi Pico (270Mhz) und PicoW (260Mhz) als .UF2 Binary
Unter DJGPP gibt es auch strip: nach strip RCP61JG2.EXE hat die Datei "nur" noch 576512 Bytes ...
Info (auch fuer mich) von hier:
ZitatCompile your code with -s to strip debugging information.
Nachdem ich ein YT-Video gesehen hatte wie man FreeDOS 1.3 in qemu installiert dachte ich mir, dass waere auch fein fuer die 16Bit DOS-version von RunCPM
Und ich muss sagen bei mir laeuft es in qemu (unter Windows mit der Accelerator-Option --accel whpx) schneller als mit DOSBox-X oder VDOS
Mounten/bearbeiten kann man das HDD-Iage auch komfortabel mit IMDisk-Toolkit
Das von mir erstelle qemu-HDD-Image (22MB - wegen FreeDOS) liegt hier
Laufen hatte ich es unter qemu mit dem qemu-system-i386w-Emulator
Hier ein wenig (Selbst)-Dokumentation fuer die Nutzung unter Windows:
=====================================
= How to install FreeDOS using QEMU =
=====================================
https://www.youtube.com/watch?v=Se69XJWxwAc
Create HDD-Image:
======================
Console:
qemu-img create runcpm.img 100M
Formatting 'runcpm.img', fmt=raw size=104857600
Boot Installer FreeDOS
======================
Console:
qemu-system-i386.exe -hda runcpm.img -cdrom FD13LIVE.iso -m 16 -boot order=d -display sgtk
Console Start mit Window WITH CDROM (wppx may hang):
qemu-system-i386w.exe -hda runcpm.img -cdrom FD13LIVE.iso -m 16 -boot order=d -display gtk --accel whpx
Console Start mit Window WITHOUT CDROM (slow - but can install FreeDOs freom CDROM):
qemu-system-i386w.exe -hda runcpm.img -cdrom FD13LIVE.iso -m 16 -boot order=d -display gtk --accel whpx
Accelerator for Linux
-enable-kvm
Accelerator for Windows (seem to have problems when -cdrom is enabled?)
--accel whpx
For Windows with Menu (because -display sdl hasnt):
-display gtk
Boot HD:
======================
qemu-system-i386.exe -hda runcpm.img -m 16 -display gtk --accel whpx
Boot HD without hanging CD-Driver:
==================================
qemu-system-i386.exe -hda runcpm.img -cdrom FD13LIVE.iso -m 16 -boot order=c -display gtk
OR
After editing to exclude CDROM and CuteMouse-Driver in FDAUTO.BAT:
(Accelerator for Windows = ON)
==================================================================
qemu-system-i386w.exe -hda runcpm.img -m 8 -display gtk --accel whpx
Alles anzeigen
guidol Bitte mal in abstraction_posix.h folgende Änderungen vornehmen und mit dem HX DOS-Extender testen:
Ich habe mal eingetragen und compiliert, aber es aendert sich nichts.
Aber ich denke da hast Du Dich fuer mingw in die falsche Datei "vertieft".
Meines Wissens wird mingw(32) von der main.c als WIN32 erkannt:
Weil auch das INFO-Command gibt aus: "running on Windows) - wohl wegen dem HostOS
Ich nutze ja:
mingw32-make mingw clean
mingw32-make -f Makefile.mingw
Die gleich Stelle in der abstraction.vstudio konnte ich per "find" nicht finden
Interessant an der Stelle:
Unter echten Windows geht LUAINFO und unter DPMILD32 kommt nur eine leere Ausgabe.
Dass LUA drin ist sieht man beim Bootscreen an der LUA scripting Version
Durch die Arbeit an der 32Bit Version verstand ich jetzt einige Dateien der DJGPP-Version besser und habe durch ein paar Aenderungen an den Compile-Dateien eine nonLUA-Version compiliert bekommen, die ich besseren Gewissens empfehlen kann
Vor lauter "Freude" hatte ich uebersehen, dass diese neu compilierte .EXE auch nur wieder nur Files mit vollen 8.3 anzeigt.
Zu meinem Glueck hat JenGun mir zum Test evtl. schneller File-Funktionen eine neue abstract.h gebaut/bereitgestellt.
Die dann neu compilierte Version zeigt alle Dateien, wen leider nur genauso schnell wie vorher in DOS.
Anbei das gleiche Archive mit der neuen .EXE Version jetzt doch wieder mit LUA
Bitte mal die angehängte abstract.h für DJGPP testen: dort werden die Funktionen aus abstraction_posix.h verwendet ...
VIELEN DANK fuer diese abstract.h, denn ich hatte nicht getestet, dass meine heutige Version auch nur die Dateien mit den vollen 8.3 Dateinamen anzeigt.
Mit Deiner abstract.h werden jetzt alle Dateien angezeigt und sind nutzbar - nur leider aendert sich nichts (bei mir hier) an der File-Ggeschwindigkeit.
Anbei die .EXE - die mit Deinem abtract.h compiliert wurde - als .ZIP
[EDIT] Ich hatte noch beim INFO-Command gesehen, dass in Deiner abstract.h das HostOS aud 0x02 was zur Anzeige POSIX anstatt DOS fuehrt.
Dies habe ich nun in 0x03 fuer DOS geaendert.
Zusaetzlich klappt nun wieder LUA, also haben wir eine Version die alle Dateien mit Deiner abstract.h anzeigt und bei der es LUA gibt
Die .EXE ist nun auch ordentlich groesser geworden...
ob es dadurch unter DOS überhaupt einen spürbaren Geschwindigkeit-Unterschied zu den entsprechenden DJGPP-Funktionen gibt, müsste man gründlich testen ...
Ich sehe jedenfalls beim Start/Laden von MBASIC und Wordstar, dass diese bei der 32Bit Version per DPMILD32 fast instant geladen sind und es bei der DJGPP-Version doch eine merkbare Verzoegerung spuerbar ist
Nichtsdestotrotz habe ich mir DJGPP und desen RunCPM-Version nochmal angesehen und eine nonLUA-Version GL20240106 compiliert, die beim compilieren keine Fehlermeldungen geschmissen hat
Ich weiss schon garnicht mehr mit welchen Tricks ich LUA in der vorheringen GL20231231 drin hatte.
Mit einer 32Bit Version unter DOS koennte man auch dieses tricksen umgehen...wobei wer braucht wirklich LUA?
Nur aus Spass und damit auch die DOS-Version komplett ist:
RunCPM v6.1 fuer DOS jetzt mit LUA-v5.4.6-Support
Nachdem ich (bis jetzt) die 32Bit Version nicht mit dem DPMILD32 von HX DOS sauber zum laufen bekomme, habe ich mir den DJGPP nochmal vorgenommen.
Beim Compile der Version vom 31.12.2023 mit LUA hatte ich einige Meldungen, so dass ich diese Version mit LUA als experimentell betrachten will.
Durch die Arbeit an der 32Bit Version verstand ich jetzt einige Dateien der DJGPP-Version besser und habe durch ein paar Aenderungen an den Compile-Dateien eine nonLUA-Version compiliert bekommen, die ich besseren Gewissens empfehlen kann
Ist die Win32-Version von RunCPM mit dem HX DOS-Extender wirklich schneller oder "besser": Benchmark mit FRACTAL.BAS?
Ich glaube an der Rechnenleistung wie beim FRACTAL.BAS wird sich nichts tun.
Aber beim File-Zugriff sollte es beser werden.
Die alte abtract.h hat 2KB und die abstraction_vstuido.h hat 12KB
Interressant - was mir damals bei der DJGPP-Version auch aufgefallen ist als wir zu weige Dateien angezeigt bekommen haben - wenn man DOSLFN laedt, dann bekommt man bei DIR alle Dateien gelistet, die die 8.3er Konvention voll ausnutzen.
Also z.B. die MBAS529P.COM oder auch eine README12.TXT
Auch MBASIC zeigt mit FILES - wenn DOSLFN geladen ist - alle File an, wenn die volle 8.3 Zeichen haben.
Wenn DOSLFN geladen ist, kann Wordstar sogar dann speichern unter dem kurzen Namen (zeigt diesen aber nicht vorher beim Laden in der File-Auflistung).
Ein PIP README12.TXT=READ.ME geht und die README12.TXT erscheint in der Wordstar-Fileliste.
Anbei die alte abtract.h (letzte Version die ich fuer RunCPM v6.1 genutzt habe) und dabei auch zum Vergleich die abstraction_vstudio.h
ich habe auch schon versucht die Ausgabe wie bei der DJGPP Version mit fputc/putchar abzuaendern - wurde zwar compiliert brig aber nicht in der Ausgabe mehr (damals hatten wir es wegen der Interruptausgabe unter DOS und conio gemacht).
Ab Windows 7 ist der Windows Defender serienmässig dabei. Meiner Meinung nach völlig ausreichend
Wichtigster Schutz ist sowieso der eingeschaltete Verstand.
Ich habe bei Windows 10 auch "nur" den Defender am Start.
Wenn man auf den bei Download hoert (wenn er was verdaechtiges findet) und nicht zu viel auf russichen Seiten Download abholt ist man fast auf der sicheren Seite.
Laedt man sich doch mal ein .ZIP aus dem Osten, dann kann man dies auch nochmal manuell vom defender untersuchen lassen.
Als 2te "Firewall" meckert auch schon der Chrome beim Download gefaehliches an.
Bei richtig bosem speichert er es garnicht (evtl. in Zusammenarbeit mit dem Defender) ansonsten fragt er ob man dies wirlick behalten will.
So habe ich schon einige ausfiltern koennen udn mein System (auch Dank dem eingeschalteten Verstad) seit mehr als 6 Jahren Virenfrei
Heute ist eine frühe Hardware von Microsoft dazugekommen:
Zum lesen / Zur Information
https://en.wikipedia.org/wiki/MacEnhancer
Der HX DOS-Extender hat ebenfalls einen DPMI-Host: HDPMI32.EXE ... durch die Win32-API-Emulation sind auch ein paar .DLL-Dateien (z.B. DKRNL32.DLL) notwendig:
Ja das mit den .DLLs ist mir bewusst (aus der DPMI32LD-Doku):
ZitatAlles anzeigen5. Win32 API Emulation
During the load process some imported dlls will be "replaced"
by DPMI compatible versions. These are:
KERNEL32.DLL -> DKRNL32.DLL
ADVAPI32.DLL -> DADVAPI.DLL
USER32.DLL -> DUSER32.DLL
GDI32.DLL -> DGDI32.DLL
DDRAW.DLL -> DDDRAW.DLL
This feature allows dual-mode applications. Such apps run as normal Win32
apps in Win32 environments and will run as DPMI clients in non-Win32
environments.
Please note that some exports supplied by DKRNL32.DLL, such as
CreateProcess, LoadLibrary, FreeLibrary, GetProcAddress, GetModuleHandle
or GetModuleFileName are just thin wrappers around the loader's int 21h
API. This means that DKRNL32 can only work in conjunction with DPMILD32,
other PE loaders won't do the job.
Es waere ja auch ein Weg vom DJGPP wegzukommen, der so aussieht als wuerde er nicht mehr weiterentwickelt.
Die hier von mir mitgelieferte MSVCRT.DLL (335KB) ist die Version 7.0.2600.5512
Das ist die letzte (die ich gefunden habe) die als Abhaengigkeit
nur die KERNEL32.DLL hat (die HX DOS ersetzt).
Alle spaeteren haben Abhaengigkeiten mit langen Dateinamen
Ausserdem laeuft die 32Bit Version damit ohne Probleme unter WinXP (auch mit ConEmu).
Könntest du ein ZIP-Archiv (oder Git) mit den erforderlichen Dateien (HX, RunCPM, WS) erstellen, damit man das direkt testen kann?
Die RunCPM-Version für DOS (DJGPP) funktioniert doch mit NNANSI, oder habe ich etwas übersehen?
Natuerlich stelle ich gerne ein Archiv bereit
Im angehaengtem RCPM32.ZIP sind die Verzeichnisse
- HX (um das zu "installieren" sollte \HX\BIN im PATH von DOS sein)
- RUNCPM (hier liegt die 32Bit Version als RCPM32.EXE und NNANSI.COM)
Im Verzeichnis \H\BIN ist zusaetzlich die MSVCRT.DLL von WinXPSP3 enthalten, da die zum Start vom 32Bit RunCPM angefordert wird, da der mingw32 die MSVCRT-Version ist (im Gegensatz zum neueren UCRT).
Unter dem RUNCPM-Verzeichnis liegt A: (\A\0) und dort ist auch MBASIC und B: (\B\0) beinhaltet
Wordstar CPM v4.0
Zu DJGPP/NNANSI:
Ja - die DJGPP-Version arbeitet mit NNANSI - dies tut aber fuer die ANSI-Funktionen die 32Bit-Version.
Da ist also mit NNANSI kein Problem.
ABER
Die DJGPP-Version benutzt eine aeltere/rudimentaerere Version der abstract.h mit weniger ausgefeilten File-Operationen als die ABSTRACTION.POSIX oder die ABTRACTION.VISUAL_STUDIO
Bei der 32Bi Version fuer Windows wird die ABTRACTION.VISUAL_STUDIO zum kompilieren "angezogen".
Da es fuer die DJGPP-Version eh eines DPMI-Hostes (CWSDPMI z.B.) braucht, hat es eigentlich nur Nachteile und schoen waere dann gleich die mit besserem Compiler (mingw32) und besseren/schnelleren File-Funktionen auch unter DOS 16Bit nutzen zu koennen (und spart auch verschiedene Compile-Wege).
JenGun Peter z80.eu Martin Hepperle
In dem Thread zum RunCPM-compile unter DOS per DJGPP hattet ihr echt gute Ideen/Vorschlage, so dass wir damals die Version zum laufen brachten - nun koennte ich bei einer anderen Moeglichkeit auch Euer Wissen/Ideen brauchen:
Ich habe eine Moeglichkeit gefunden die 32Bit-CLI Windows-Version von RunCPM (compiled mit mingw32) auf 16Bit DOS zu starten.
Das geht ueber einen Loader (DPMILD32) von dem HX DOS Extender (aktuell v2.20)
So arbeitet dann die 32Bit Version von RunCPM auch mit dem unter DOS notwendigen NNANSI zusammen
Allerdings gibt es noch einen/einige Haken (waer ja sonst auch zu einfach/schoen) und zwar in den Datei-/File-Funktionen:
Was geht:
- laden von Programmen wie MBASIC oder Wordstar
- speichern und laden in MBASIC
- laden eines Dokuments in Wordstar
- PIP GLTEST.COM=FRAROUND.COM und starten der Kopue GLTEST.COM
Was get (leider) nicht:
- speichern in Wordstar (Disk-Full)
- DIR gibt nur "No File" aus (erkennt aber wenn man ein nicht vorhandes Laufwerk ansprechen will per BDOS-Error)
Info-Seite zur aelteren (non-Fork?) Version v2.17
dazu auch die passende Sourceforge-Seite
von dem hatte ich bis heute nichts gehoert/gelesen....
Interessant sind die verfuegbaren Disk-Images zum booten und die Ausgabe als extra Fenster im Serial-Terminal-Style
(leider nur schwarz auf weiss) - aber mit TTF-Font-Auswahl
Emulator v1.0.44 von Joe Moore unter: http://www.z80.info/zip/zemu.zip
zusaetzliche Disk-Images: http://www.z80.info/zip/diskimages.zip
Mehr Infos ueber ZEMU ist in folgender Seite enthalten: http://www.z80.info/z80emu.htm#EMU_CPU_W32
ZitatAlles anzeigen
This is the Z80 Emulator Version 1.0.44 for 32 bit Windows (12:18 PM 12/14/20)
The Z80 Emulator is a full featured emulator designed to run CPM, Intended for Hobbyists.
Features include
Z80, Z180, I8080 Instruction sets.
Disassembler for Zilog and/or Intel/TDL nmemonics
Instruction, I/O and Data Breakpoinits, Single Step, Trace, IO intercept, Debug Console.
Simple TTY, Timers, Interrupt ability
CRT emulator that can simulate many CRTS, including ANSI
Simulated Printer that produces RTF output.
Can access COM ports, Windows SPL for RAW printer files.
Disk Controller capable of accessing disk images availible for this and other emulators.
(runs CPM 1.3, CPM 1.4, CPM 2.2, CPM 3, MPM 2, Cromix, CDOS, ISIS 4.x native)
Also, supports a subset of the simulated features of Z80SIM.(runs uscd pascal, CPM 2, CPM 3 and MPM 2)
Simulates some real hardware
Simulates WD17xx FDC (can Write track(Format))
Cromemco 16/64FDC, Seven KZ64-II, TUART, PRI, 3102 (runs CDOS and CROMIX)
SD Sales VersaFloppy-II (runs SDOS)
Tarbel Single and Double Density FDC (runs CPM 1.3 and 1.4)
Intellec Series II DD FDC and MDS-800 SD FDC (runs original DRI CPM distros, 1.3, 1.4, 2.2, and ISIS)
IMSAI FIF FDC (runs IMDOS and CPM 1.31 for IMSAI)
Digital Systems FDC One (runs proto CPM 1975)
MIO, ACR, HSR, PIO, TUART, PRI
Can make network connections as client or server to allow multple users simultaneously. This feature augments the serial port feature, which due to the obsolecence of serial ports is fading. Instead of terminals, you can connect with TelNet.
Drag-n-Drop Windows to CPM file transfers.
Noch ein paar Infos dazu:
Das ist der gleiche Link wie bei mir
In den Kommentaren dieser Seite meinen die User, dass die aufgetauchte 0.11 eher eine 0.2 sein muesste, weil EDLIN schon in der Programm-Liste ist
Nur aus Spass und damit auch die DOS-Version komplett ist:
RunCPM v6.1 fuer DOS jetzt mit LUA-v5.4.6-Support