Posts by guidol

    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 :

    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)


    iz-cpm wurde die Tage auf v1.3.1 upgedated und ist ein CP/M-Emulator der das Host-Filesystem nutzt:

    GitHub - ivanizag/iz-cpm: Portable CP/M emulation to run CP/M 2.2 binaries for Z80
    Portable CP/M emulation to run CP/M 2.2 binaries for Z80 - GitHub - ivanizag/iz-cpm: Portable CP/M emulation to run CP/M 2.2 binaries for Z80
    github.com


    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 ;)

    Quote


    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!

    Maccy.jpg


    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:

    Quote

    Kernel 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?

    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:

    Damn Small Linux 2024


    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):

    Quote

    -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. :D

    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:


    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! :)

    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

    Code
    U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:46:11 -0700)

    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 ;)


    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....

    Quote

    Printing

    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.

    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: