Beiträge von guidol

    Erstmal sollte man rausfinden, welches Gigabyte Board ser Serie 6- Quad Du drin hast:

    -- GIGABYTE -- Ultra Durable 2 / Dynamic Energy Saver Motherboards

    und da nach einem BIOS Update suchen/durchfuehren.


    Der BAD_BLOCK Error ist laut MS meist ein Problem b

    bei Platte/Ram.


    D.h. Ram-Stick und Platten erstmal einzeln testen.

    Wenn die alle OK sind, kann es auch das DVD Laufwerk sein, dass nicht mehr sauber liesst.


    Zu den Platte/Ram Problemen sollte man sich auch die Kodensatoren von Mainboard/Netzteil ansehen.

    Ich nutze das Usenet auch nur via Google Groups, aber eigentlich eher nur weil mir ein gescheiter kostenloser Server und aktueller Newsgroup-Client fehlt.


    Damals mochte ich es sehr via FidoNet unter DOS Usenet-Groups zu lesen, bis fuer fast alle das Usenet nur noch zum tauschen von Bildern/Musik und Binarys war.


    Manchmal findet man in der comp.os.cpm einige Infos, die man sonst so nicht mitbekommt.

    Release v5.0 vom 15. Oktober 2023:



    Ich habe heute rausgefunden, dass die DECtalk "Demo-Eingabe-Windows", die man auch ueber die SAY.EXE amsprechen (oder spricht man die dectalk.dll an?) kann- nun neu compiliert frei verfuegbar sind.


    Frueher in einer kommerziellen Version musste man ein "TSR" GW32DEC.EXE vor dem Aufruf von SAY gestartet haben, dass faellt nun wohl weg :)


    Die SAY.EXE fuer Windows kann

    - Dateien vorlesen: SAY HELLO.TXT

    - Text vorlesen: SAY "Hello, how are you?"

    - .WAV erzeugen: SAY "Hello, how are you" -w HELLO.WAV


    Andere Optionen kann per Hilfe ueber SAY -HELP bekommen:


    Das Projekt Modern builds for the 90s/00s DECtalk text-to-speech application.
    ist auf guthub unter https://github.com/dectalk/dectalk


    Nimmt man die Dateien des Windows-Release (zusammen mit dem angehaengten SAY.EXE) hat man die o.g. Funktionen :)

    In dem Release gibt es MacOS und Ubuntu Files, aber da gibt es wohl dann kein SAY (oder man muss versuchen es selbst zu compilieren - unter /dectalk/src/samples gibts auf github auch ein Source-Verzeichnis fuer say.c

    Vor einiger Zeit hatte ich eine Kopie von DOS-Plus. Aus irgendeinem Grund war es im Emulator (mit und ohne Pirx) instabil und wurde daher nicht getestet.

    Welche Version von DR DOS Plus hattest Du getestet? Auch die "letzte" V2.1?

    Mit dem PCE aus Deinem Archiv "CPM86 fuer Newbies" habe ich es nicht gebootet bekommen,

    aber mit meinem GOTEK-USB-Floppy am eeePC701 startete es sofort :)


    Evtl. magst Du oder andere es mal testen? Oder Du machst uns netterweise (wenn es klappt) eine Konfiguration fuer den PCE, dann koenntest Du damit auch Deinen PIRX-Commander testen ;)


    [EDIT]
    Unter DR DOS Plus laeuft auch ein Z80-CP/M-Emu (den hatte ich bei Erstellung des .ZIP noch nicht)

    MBASIC und FRAROUND (das hatte ich abgebroche, damit man die Startmeldung des Z80-Emu sieht) laufen.




    Ist das ein Problem vom MINGW, oder tut es unter Linux auch nicht?

    Da ich es bis jetzt nur unter MinGW und Cygwin compiliert hatte, habe ich SAGE-simh eben nochmal unter armbian/Linux compiliert - aber da ist leider auch der Schreibzugriff (bis auf Files loeschen) nicht funktional. :(

    Wobei sich simh gefuehlz bei dem Befehl die Zeit laesst bis der Prompt wieder kommt.

    Also kann es sein dass simh da "irgendwas" tut.


    Den Autor "Holger Veit, March 2011" des imh Port der Sage II/IV koennte ich leider nicht finden/zuordenen im Internet um da mal anzufragen ob das der letzte Stand war. Da das von 2011 ist, ist leider davon auszugehen.


    Kenn den von Ecu schon jemand?

    Gibt es wohl schon ueber 10 Jahre und ist mir noch bis jetzt entgangen.


    Hat ein "maechtiges" .TXT README von 259KB und hat viele Optionen.


    Spannend fand ich

    - CP/M Plus 3.1 (aus eine v2.2 geboren

    - rcpmfs via LibDisk (Drive A: - D: koennen Verzeichnisse auf dem Host-Computer (OSX, Linuc, Windows) sein

    (das ist auch notwendig, da ich einen Tag sinnlos damit verbracht habe eine speziell gepatchte cpmtools v2.10j zu testen)

    - beetalker (SPO256-Chip) via emulierten PAR-Port (muss noch mal sehen wie man den anspricht)

    - nutzt OpenGL oder SDL (auch fuer Full-Screen und Windowed-Mode)

    -kann sich auf COM-Ports verbinden (Kommunikation in die Aussenwelt)

    - amber, green, color und monochrom Display-Mode

    - CPU-Frequenz einstellbar - wobei ich bei ueber 10Mhz eine zu schnelle Tatstur habe (da soll es eine VSYNC-Option was tun)


    Unter https://microbee-mspp.org.au/ gibt es File-Bereiche pub/tech und retro und ein eigenes Forum dazu.






    Die Meldung von CONFIG des MINCE hatte ich am Anfang auch.

    Nach dem uncompress konnte ich aber - wie Du - auch nicht auf die Disk schreiben, denn CONFG sagte dass nach 0 Pages schreiben des Swap B: voll ist :( obwohl STAT B: sagte dass 234K frei seien.


    Aber auch wenn ich ein .IMD in .RAW wandle mit cpmtools per diskdef "sage2" was drauf schreibe und per BIN2IMD wieder ein .IMD erstelle sieht das Directory ungesund aus und ich kann nicht drauf schreiben (selbst wenn ich vorher durch loeschen von Dateien Platz im Directory geschaffen habe:



    Ich habe es mit diesen Befehlen und mit IMD v1.18/v1.19 versucht in vDOS und auf einem echtem DOS-PC:


    Der Mince startet bei mir schon, aber die Terminal Emulation paßt nicht.

    mit SETENV TERM ist da nichts zu machen? Ich weiss zwar nicht welche VALUEs moeglich sind,

    aber in der Emulation setzt die SAGE Ii beim Boot

    SETENV TERM TVI950


    Evtl. geht ja

    SETENV TERM ANSI

    oder

    SETENV TERM VT100

    Gefunden (dachte erst die 68k.sim sei der 68k-Emulator-Code, ist aber die "Batch"-Datei fuer simh :) )


    Also am Ende der Datei 68k.simzwischen FD0 und BOOT einfach die Zeile fuer FD1 einfuegen ;)

    Dazu habe ich einfach vorher die CPM68K12.IMD nach DRIVE_B-IMD kopiert.


    Code
    att fd0 cpm68k12.imd
    att fd1 drive_b.imd
    boot cpu

    Ich habe heute mal (wegen dem 68K.CP/M) in simh v4.01 den Sage II Emulator compiliert (mit MinGW64 POSUX GCC 13.2.0 in MSVCRT/MSURT).
    Binary inkl. ROM/Startdisk im Anhang :) zum mitspielen fuer Windows 64Bit.


    Nun ist Drive A. am Anfang gleich voll (0 Byte free), deshalb wuerde ich gerne auf Drive B: eine leere Diskette einlegen, aber ich weiss nicht wie der att(ach) Befehl beim Sage II Emulator heisst (habe sowas nur mal beim pdp11 simh Emulator gemacht) und finde keine Anleitung dazu :(


    Weiss dies jemand hier der SAGE-Experten? ;)



    PS: Leider schmeisst der MinCE-Editor auf A: nur eine Exception :(


    Dazu muss bei mir erstmal das De-Interlace/Interlace klappen des Floppy-Image :(
    Nach dem De-Interlace ist 0: fast leerund gibt einige leere Eintraege (dann bootet CP/M nicht mehr davon) und B: nutzt A: - man kann kein 2tes Image laden :(

    Wo ist der Rest von 0: ? :(

    1ST1 ich hab noch mehr getestet (schau mal hier) - leider erfolglos

    d.h. eine .ST deinterlaced und gleich wieder interlaced (ohne File-Operationen dazwischen


    Es kommt eine Datei mit anderem (nicht nutzberen) Inhalt raus, die beim booten am St noch den CP/M-Bootloader v0.4 zeigt dann aber 2 ST-Bomben schmeisst.


    Tut man die wieder interlace-te Datei nochmal deinterlacen ist nur noch Quark drin :(

    Mir kommt es vor, als habe das interlace Python-Script nen Hau - ebenso Python 3.9.2/3.11 unter Windows - weil das deinterlace dagegen sauber auf armbian mit dem Python 3.9.2 klappt (dehalb hatte ich mit dieser Version 3.9.2 auch mal nach der 3.11 getestet :(

    *sniff* bis jetzt laeuft die AMIGA-Version echt besser...

    Kannst ja mal benchmarken, ob der ST oder der Amiga in CP/M schneller ist.

    • Dazu muss bei mir erstmal das De-Interlace/Interlace klappen des Floppy-Image :(
      Nach dem De-Interlace ist 0: fast leerund gibt einige leere Eintraege (dann bootet CP/M nicht mehr davon) und B: nutzt A: - man kann kein 2tes Image laden :(



    Wo ist der Rest von 0: ? :(

    guidol : Moment mal, ist die verschollene CP/M-68k Version des STs aufgetaucht? Das Datum oben mag das suggerieren. Oder ist das eine moderne Re-Implementation.

    Toshi  1ST1


    So aehnlich ;)

    Auf es gibt den alcyon compiler (Vorlaeufer vom Digital Research C Compiler):

    Code
    This directory contains the sources of the C compiler and
    utilities that i used to compile TOS. They are functional identical
    to the ones in the developer kit, but with numerous bugs fixed


    Dazu kommt der ATARI-ST-CP/M-68-Port der wie die AMIGA Version auf dem cpmsim aufsetzen.

    Alcyon .ZIPs findet man auch in diesem Thread.
    ATARI ST Sourcen auch hier.


    Natuerlich muss man fuer die Floppy BIOS/BDOS/CCP/Bootsektor je nach AMIGA oder ST machen.

    Beim AMIGA darf man direkt mit den cpmtools dran (amiga diskdef-Eintrag) aber beim ST CP/M-68K
    muss man erstmal mit Phyton3 das .ST image deinterlacen, dann mit cpmtool und st68k-720 diskdef bearbeiten und dann wieder mit Phyton3 interlacen :(



    Python 3.11 fuer Windows 64


    Wichtige Threads dazu (einmal spanisch und einmal englisch) sind:

    CP/M68K para Atari ST:

    [Conseguido] CP/M68K para Atari ST - RetroWiki & Cacharreo [RW]


    CP/M 68K:

    https://atari-forum.com/viewtopic.php?t=27055


    Den spanischen kann man sich im Google-Chrome uebersetzt (englisch) ansehen ;)


    Ich habe heute mal mit MSYS2 MinGW64 (also 64Bit, den da gibt es auch die ncurses lib)
    die cpmtools v2.24 fuer Windows compiliert
    (hat bis auf den FS-Editor fsed.cpm.exe geklappt (den fsed.cpm hab ich noch nicht genutzt)


    Laut cpmtools-Autor (Michael Moria) sind die getopt-Errors am Anfang "nicht schlimm", denn die hat er auch beim Compile auf seinem Arch-System mit GCC 13.2.0
    Nur beim ihm klappt wohl der Compile des fsed.cpm
    (unter armbian mit GCC-12.x klappt der auch bei mir)


    In den diskdefs bei den cpmtools v2.24 habe ich am Ende auch die defs fuer amiga, st68k-720
    und em68k drin ;)

    Ok - ein wenig versteckt - aber hatte ich Anfang Mai auch gefunden und "gemeldet" ;)
    Bin immer noch nicht dazu gekommen, dies auf dem MiST zu testen - WinUAE soll gehen.

    Heute (Nacht und gestern Abend( habe ich es auf meinem MiST ausprobiert und es klappt soweit ganz gut
    (auch wenn er beim Wechsel zwischen A: und B; Probleme hat und ich vom cpmsim-68K-Speed verwoehnt bin)


    Ist nett, dass er ohne Workbench auskommt und "Bare-Metall" auf dem Kickstart (besser v2.04 als v1.3) bootet.


    Zum FRACTAL/FRAROUND.C compilieren musste ich allerdings die cpm-boot.adf etwas mit anderen DR-C-Compiler-Komponenten/-Files bestueckt, da die vorhandenen mir eine arg seltsame Ausgabe bescherten.

    So als haette man durch eine Fehlberechnung das Bild an die Seite verschoben.


    Auch fehlte auf A: die AS68SYMB.DAT - ohne die wollte AS68.68K nicht arbeiten ;)


    Weil es nur eine CPMFS-ADF-Floppy fuer A: und B: gibt (aber per cpmtools nutzbar), ist es auf A: etwas eng.

    Nach dem compilieren von FRACTAL/FRAROUND wollte ich das PIPen nach B:, aber das wollte er nicht :(
    (BDOS-Error - na gut dann reset - gut dass die cpmtolls ein fsck.cpmfs haben)


    Da muss wohl noch am Filesystem-Handling gearbeitet werden (leider ist das Gihub-Repository schon fast ein Jahr im Dornroeschenschlaf :( )


    Aber FRACTAL und FRAROUN laufen als .68K Binary flot genug auf dem MiST :)


    Auf B: (cpm-extras.adf) habe ich mal COM.68K, MBASIC 5.29 (Z80) und EHBASIC v3.53 drauf gepackt.

    Die angepassten .ADFs haenge ich auch hier mal als .ZIP dran (wie im ATARI-COM-Forum MiST-Bereich)


    Ein Kickstart-ROM v2.04 (bevorzugt fuer A500/A600 da 68000-CPU) muss man schon selbst mitbringen.

    Gut dass ich damals das AMIGA-Emulationspacket gekauft habe mit ROMs & Key :)


    Ich hoffe, Ihr habt auch so viel Spass, wie ich dran habe (bei mir ist es jetzt schon wieder 03:44 nachts).
    Mal schauen ob ich einschlagen kann :)








    LOAD und dann ctrl-c

    Danke ;)

    Funktioniert bei Dir ein EHB353.68K?

    Bei mir startet (sauber) nur ein EHB353.REL


    Mache ich daraus ein .68K mit

    RELOC EHB353.REL EHB353.68K

    dann loescht es nu den Screen beim Start und haengt.


    Oder klappt da "nur" die automatische RELOC-Adresse nicht?


    Ist es eigentlich empfohlen ein .68K Binary draus zu machen (gibt ja auch die DR C-Compiler-Befehle als .REL)


    Ich hatte es so verstanden, dass die .68K mehr ans bestimmte CP/M 68K Systeme angepasst sind.

    2 kurze "dumme Fragen" (OK- wer nicht fragt bleibtbt dumm) ;)


    1.) Gibt es eine Moeglichkeit auf Dateien aus anderen User Areas zuzugreifen?
    - beim compilieren gibt man ja auch z.B. 2:s.o an oder 8:clib

    Denn ein TYPE 0:CLS.SEQ bringt einen Fehler :(

    [EDIT] Laut dem YT-Video koennte ich dafuer bei CLS folgendes machen, ist aber doch umstaendlich?

    Code
    PIP CLS.SEQ=C:CLS.SEQ[G0]
    TYPE CLS.SEQ

    2.) Wie verlasse ich EHBASIC 3.53?
    - QUIT, BYE, SYSTEM, STOP scheint es ja nicht zu sein -beim IoTBASIC/TinyBasic gabs noch CALL 0

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