Interessant! Meines ist auch ein „V.34 Fax with V.32 bis“. Aber der Stomanschluss sieht so aus:
von der Buchse her sieht dies aus, als wuerde da ein S-Video Mini-DIN Stecker passen :
S-Video – Wikipedia
de.m.wikipedia.org
Interessant! Meines ist auch ein „V.34 Fax with V.32 bis“. Aber der Stomanschluss sieht so aus:
von der Buchse her sieht dies aus, als wuerde da ein S-Video Mini-DIN Stecker passen :
Schade dass man nicht auf das "aktuelle" Translator setzt. Das konnte nämlich auch unterschiedliche Sprachen.
Das Program ist ja noch neu und man muss ja nicht diesen Translator nutzen
(aus em Kopf gab es im AMIGA BASIC-Handbuch ein Listing fuer Deutsch zur Nutzung des Narrator)
Sicherlich gibt es auch einen Phonem-Converter der auch anstatt des Translator genutzt werden kann.
Ansonsten kannst Du ja mal probieren auf der Github-Seite eine "Issue" auf zu machen - evtl. ist der Autor fuer die Idee empfaenglich?
Die Stimme des AMIGA war fuer damals als Soft-TTS-Voice echt garnicht schlecht
Nur gab es (fuer mich) bis jetzt keine Chance sie ausserhalb einer AMIGA-Emulation zu nutzen
Gestern dachte ich - es waere schoen, wenn es dafuer auch einen Emulator geben wuerde
--und mich hat wohl schon jemand vor 2 Monaten gehoert"
Es gibt den "AmigaNarrator - Commodore Amiga narrator.device emulator" auf github
Damit der laeuft braucht man ein original "narrator.device" und "translator.library" aus einer Workbench.
Im errsten Link wird angegeben, dass die aus der Workbench v1.2 am besten waeren.
Nun wie bekommt man die aus dem .ADF?
Man installiere dazu den Total Commander und darin das ADF-Plugin (AMIGADX) von der PlugIn-Seite
Hat man die beiden Dateien steckt man die zu den anderen ausgepackten Dateien des Github .ZIP und
compiliert mit
./build.sh
Das ergibt dann eine narrator und eine translator Binary.
Die Einzelnutzung der Befehle ist auf der README.md der Gitbuh-Seite erklaert.
Es gibt auch eine ./say.sh die fuer einen nach
say.sh "Hello world."
alle noetigen Befehle ausfuehrt.
Da diese say.sh aber alle Befehle hintereinander "weg-pipt" scheint mein Orange Pi Zero (H3-CPU) zu sher hinterher zu haengen und die Ausgabe erfolgt unterbrochen (weil er es dann wohl direkt "streamen" muss )
Da ich zuvor die Befehle einzeln erfolgreich getestet hatte, habe ich wieder einzelne Befehle (hintereinander) daraus gemacht und so klappr es auch (inkl. etwas debug-Ausgabe) - saygl.sh :
#!/bin/bash
if [ "x$1" == "x" ]; then
echo "Usage: $0 <text>"
exit 1
fi
TEXT="$1"
echo ...translating $TEXT
./translator "$TEXT" 2>/dev/null >./readout.txt
echo ...creating .s8 soundfile
cat readout.txt | ./narrator - >./readout.s8 2>/dev/nul
echo ...playing empty.wav for sleeping amplifier of OrangePi Zero
aplay ./empty.wav
echo ..sleeping 1 second
sleep 1
echo ...playing .s8 file
aplay -f S8 -r 22200 ./readout.s8
echo ...removing .s8 file
rm ./readout.s8
echo ...DONE
Alles anzeigen
Leider dauert die Umsetzung in ein .S8 Audio-file auf dem Orange Pi Zero eine ganze Weile.
Ein Test-WAV-Audio File gibt es hier (nicht von mir)
PS: Unterstuezt Mingw auf Windows Sound - dann koennte ich es da mal testen oder auf einem schnelleren Linux)
Update der UF2-Binarys fuer Pico & PicoW
von RP2040-Core v3.6.3 auf 3.7.1
iz-cpm wurde die Tage auf v1.3.1 upgedated und ist ein CP/M-Emulator der das Host-Filesystem nutzt:
Gedanklick hatte ich beim ersten lesen des Namens an einen Verwandten der App gedacht - cpmish
https://cowlark.com/cpmish/
Entweder aus dem aktuellen Vezeichnis oder per Commandline kann man den Laufwerksbuchstaben auch Verzeichnisse zuweisen.
Alternativ kann man auch direkt eine .COM aufrufen.
Terminal-Emulation ist normal/default ADM-3A - kann aber mit der Commandline-Option "--terminal ansi" auf ANSI gesetzt werden.
PS: von dem Autor gibt es auch eine Z80-MBC2-Emulation:
https://github.com/ivanizag/z80-mbc2-emu
Fuer den Basilisk II und die Installtion finde ich dieses Video sehr nett:
[Labs] Emulate a Classic Macintosh Today! Basilisk II Tutorial!
von Macintosh Librarian
Zitat
Maccy and Ms. Fox give a tutorial on setting up the vintage Macintosh Emulator - Basilisk II. Want to run System 7 software or MacOS 8 on a modern PC or Mac? Basilisk II will help you do just that! Also, we discuss how to connect your Macintosh Emulator to the internet and even LAN connected Macs!
And the RaSCSI-Fileserver Video = Apple Fileserver auf dem Raspberry Pi
DOS von USB booten geht nur mit FreeDOS.
Und Wind kann man nicht von FreeDOS installieren.
Es gab letztens ein "virtual get-together" von FreeDOS und da gabs es unter anderem fuer naechste Pre-Relase die Info:
ZitatKernel updates from Jeremy. There are a few updates coming, including support for Win311.
Hoping to see a new version soon, even if it's a pre-release.
BTW: Ich bin immer wieder erstaunt ueber meinen DELL FX-160, der ohne DOS-Treiber ein USB-ZIP-Laufwerk einbindet. Oder zulaesst dass ein angeetsckter USB-Stick als D: unter MS-DOS 6.22 erkannt wird und partitioniert, formatiert und "ge-sys-ed" werden kann und z.B. mein ASUS eee 701G kann dann von dem MS-DOS booten oder wenn man eine SD-Karte (im Singleslot-Reader/Writer hat) anstatt dem USB-Sick kann man diese genauso bearbeiten und der ASUS bootet dann MS-DOS vom internen SDCard-Slot.
Ich habe ekien Ahnung wie diese Funktion(alitaet) heisst. Allerdings ist die mir sonst noch nicht untergekommen.
Bei dem Stick bzw. der SDCard muss man natuerlich die 2GB Partition-Groesse beachten.
Ist ein neuer Stick/SDCard das erste mal am FX160 dauert es ein wenig laenger bis das Device konfiguriert ist.
Kenn dies jemand?
adafruit hat einen Artikel, wie man ein HDMI Display und USB Tastatur an das Pico RunCPM bringt
HisashiKato1969 hat side nun als Kombination mit USB-OTG-Keyboard und PicoDVI erstellt
Es ist fest, halt eben schief!
Was kann denn der Hypercache Turbo?
hier ist eine Infoseite (wohl fuer den Nachfolger = Plus Version):
ist das "nur" ein Ram-Erweiterung im 68000er Sockel oder ist das mehr mit dem quadratischen TOSHIBA Chip?
Ich verstehe nur nicht, wie es heise immer wieder schafft weder den Seiten- noch den Download-Link mit anzugeben
Du hattest wenigstens den Download-Link gleich dazu
Hier noch der Link zur Seite:
Bin mal gespannt es es installiert weniger als debian pur mit xfce verbraucht...den es besteht ja aus antix/debian...
Nur dass es von debian neben der netiso keine minimal desktop-iso mit xfce gibt.
Die koennte auch noch auf eine CD passen
Normal nutze ich ja Cmder (bzw. Conemu in Cmder) um RunCPM oder ntzvcm in einem Windows-Console-Fenster (kein serielles Terminal)
laufen zu lassen und damit die ANSI bzw. VT100 Escape-Codes umsetzen zu lassen bei CP/M-Software.
Einigen Usern (auch hier) war die Software zu gross oder zu Feature-reich zum installieren
(kann ich auch verstehen, aber ich mag die Prompt-Autovervollstaendigung der Befehlshistorie von Cmder)
Nun auf der Suche, warum ntvcm unter Windows mit Cmder Probleme mit einem 24x80 (aber nicht 25x80) Fenster hat, fand ich im Netz
Console2 v2.00 beta148 in 32 & 64Bit
Das Projekt ist schon etwas aelter und wird wohl nicht mehr weiterentwickelt, dafuer ist es aber relativ klein und sozusagen eine portable Software - da keine Installation notwendig ist. Einfach Verzeichnis anlegen und Verknuepfung auf den Desktop
Zwar unterstuetzt Console2 nicht die Farbunterscheidung von nromal/bold Text (in Farbe) wie Cmder/Conemz oder puTTY/kiTTY aber es macht ANSI bzw. VT100 Software nutzbar auch wenn man keine ANSI-Microsoft-Console ansonsten unter Windows installiert hat oder nutzt.
So kann ich Euch diese Software mal zum testen ans Herz legen
In Windows sollte man dann das Fenster auf 80x25 setzen.
Wordstar 4.0 CPM laeuft in Linux bei der Bildchirmausgabe gut, aber das selbe mit einer Windows-Compilierung zerhaut mir die Bildschirmausgabe.
Allerdings arbietet (mit 80x25 Fenster) die DOS-Version dann sauber unter Windows 64Bit
Die Bildschirmausgabe von Wordstar 4.0 klappt bei ntvcm auch unter Windows,
wenn man die Command-Line-Option -c (nicht -C und auhc in in Verbindugn mit -C) mit angibt
UND die Fenstergroesse auch (wie bei DOS/ntvdm) auf 80x25 anstatt 80x24 setzt
(was ja angegeben ist in der ntvcm Online-Help bei der -c und -C Option):
Zitat-c never auto-detect ESC characters and change to to 80x24 mode
-C always switch to 80x24 mode (Windows only)
-d don't clear the display on app exit when in 80x24 mode
Ähm.
Wenn ich DOSBOX starte, dann schläft meine CPU fast weg.
Selbst wenn man zig mal DOSBOX gleichzeitig laufen lässt, bringt das meine CPU nicht ins schwitzen.
Auch nicht MaME oder sonst ein Emulator.
OK dann war es nicht DOSBOX(-X)
Ich hatte nur einige Emulatoren (evtl. war es der DOS-Player), die auch im Idle meine "alte" AMD Phenom II Quad 3GHt CPU immer so belasteten, dass die CPU von 28 auf 50 Grad raufging und die Leuftung einsetzte, was bei den Sachen die ich normal mache eigentlich nict vorkommt - ausser der Defender will beim compileren auf der Arduino-IDE alle kleinen Files mitscannen
Einige Emulatoren setzen evtl. das Tastatur-Polling zu hoch ein und verursachen unnoetig Last
Bei MAME hatte ich auch eine relativ hohe Last bei der Emulation des NABU, obwohl dessen Hardware nicht wirklich anspruchsvoll von den Chips ist (ebenso ein DEC-VT-Terminal unter MAME)
Besonders nett ist ntvdm in der Textconsole von Linux, da hatte ich immer Anzeigeprobleme mit der DOSBOX (ohne X/Desktop) - da laeuft dann echtes GW-BASIC, denn PCBASIC ist mir echt zu lahm.
Ueber den Discord-Server von RunCPM wurde ich heute aufmerksam auf das Github-Repository von davidly
Dort gibt es interessante (nicht org. MS) VMs fuer CP/M (Z80 oder 8080) und DOS (8086 und DOS 3.3 kompatibel) die unter Windows nicht so an der CPI zerren wie DOSBOX, vDOS, CP/M Player
Fuer DOS gibt es ntvdm und fuer CP/M ntvcm (nd sogar ntvao fuer Apple 1 und rvos fuer RISC-V .elf files)
Die DOS-Variante habe ich unter Windows 64Bit (wird auch nur fuer 64Bit bei Windows angeboten) und unter armbian kompiliert bekommen (bei Linux muss man erst die m.sh per chmod 755 m.sh ausfuehrbar machen - bei Windows nutzte ich die mg.bat fuer mingw)
In Windows sollte man dann das Fenster auf 80x25 setzen.
Die CP/M Variante habe ich in Windows 32 & 64Bit kompiliert (braucht zum includieren/comilieren einige dlj-Files ein Verzeichnis hoeher als die -BAT compile-batch-Datei - siehe -I ..\dlj in der .BAT)
Nutzbar ist das ganze dann aehnlich wie beim ZRUN fuer CP/M-Files
ntvcm WS.COM (fuer CP/M(
oder
ntvdmg WS.EXE (fuer DOS)
De Github-Archive bringen beides mal Worstar mit und bei DOS auch einige BASIC-Dialekte zum testen.
Wordstar 4.0 CPM laeuft in Linux bei der Bildchirmausgabe gut, aber das selbe mit einer Windows-Compilierung zerhaut mir die Bildschirmausgabe.
Allerdings arbietet (mit 80x25 Fenster) die DOS-Version dann sauber unter Windows 64Bit
Anbei mal ein paar Test-Compilate fuer Windows (DOS in 64Bit und CP/M in 32&64Bit)
Dazu kommt der ATARI-ST-CP/M-68-Port der wie die AMIGA Version auf dem cpmsim aufsetzen.
Fuer den ATARI-ST-Port gibt es die BootDisk v0.6, den vorher gab es einen Bug
im BIOS mit dem Drive-Select. So verwies B: immer auf A:
Mit dem neuen BIOS kann man dann auch auf eine in B: eingelegte Diskette zugreifen
und hat somit 2 Laufwerke zur Verfuegung
Jetzt muesste ich es wie der Autor nur noch sauber mit dem de-/reinterlace hibekommen
VORSICHT: Firmware-Brick moeglich durch falsche Flash-Reihenfolge
Da ich die Info bis jetzt nur im MiST-Bereich des ATARI-Forums und auf Mastodon gesehen habe:
Es gibt eine WARNUNG beim Firmware-Update dass wenn man <= Firmware 230705 hat,
dass man vor der - zur Zeit - neuesten firmware_240105.upg (also aus 2024)
ERST die Version firmware_231214-intermediate.upg flashen sollte um das bricken des MiST zu vermeiden:
ZitatAlles anzeigenhttps://github.com/mist-devel/…ries/tree/master/firmware
Important note
Firmware versions up and until 230705 has a bug which might prevent a successful upgrade. After the upgrade fails, the only way is to de-brick MiST is the SAM-BA or JTAG method. An intermediate firmware (firmware_231214-intermediate) was created, which fixes the bug, and has a higher chance for a successful upgrade from earlier versions.
So if you're upgrading from a version before 231214,
then upgrade first to 231214-intermediate, then go for the latest release.
D.h. erst mit der Dezember 2023 Version als firmware.upg updaten und dann nach Neustart erst mit der 2024er Version (auch dann umbenannt als firmware.upg) weiter upgraden.
Meine beiden MiST (je einmal alter und neuer Ram-Typ) haben es aus dem Minimig-AGA Core "ueberlebt" nach den Upgrades
Ich drueck Euerem MiST auch die Daumen fuer Upgrade der Firmware!
Danke, das funktioniert
Gerade auf ADM3A und F80 konfiguriert,
Anbei DS0N14.DSK - also Disk O: von CP/M 2.2 auf dem Z80-MBC2 - mit Wordstar v4.0
Konfiguriert fuer Dich auf ADM3A und Epson-FX80
Ich habe es normal auf ANSI, da ich meinen Z80-MBC2 mit puTTY auf dem PC nutze
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.