Beiträge von guidol

    [EDIT] OK - putty macht das Ctrl-\ im Moment nicht "direkt", aber Ctrl-\ ist ASCII 28
    so kann man ALT festhalten und auf dem Nummernblock 28 tippen und ALT loslassen.
    Also eine erste Zwischenloesung :)

    Da man mit Ctrl-\ auch den RC2014-Emulator beendet, habe ich nochmal nach einer Loesung gesucht und fand in dem putty-Clone/Fork kiTTY folgende Option in der kitty.ini dort die Section [Shortcuts]
    (leider gibt es wohl keine putty.ini?):

    Code
    list={CONTROL}{DOWN}
    {CONTROL}{DOWN}=\x1c

    D.h. die Tastenkombination Ctrl-CursorDown sendet ASCII 28 bzw. HEX 1C und beendet dann somit den Emulator und man steht wieder am Prompt ;)

    Schade, dass es nur die eine Folge ist. Die ganze Reihe wäre genial.

    Der Einsteller auf YT schrieb dass er evtl. noch einige einstellt:


    Zitat

    Heute Erfülle ich einen von euch des öfteren geäußerten Wunsch, die Sendereihe "Einführung in die Digitaltechnik" hochzuladen. Ich habe zwar bei weitem nicht alle Sendungen (zumindest bisher), aber doch ein paar. Diese hier macht den Anfang. Jean Pütz erklärt anschaulich, wie Datenübertragung Anno 1974 aussah. Lochkarten, Magnetbänder, grün-schwarze Röhrenbildschirme und mechanische Tastaturen garniert mit bunten Farben und der entsprechenden Mode, mehr braucht das Retro-Herz nicht!

    So :) Probleme geloest :)

    Das Ausgabeproblem lag an einem kurzem Wartebefehl (delay(1) also 1ms) in der Ausgabeschleife

    und das Eingabeproblem lag daran, dass beim fuellen des Eingabe-Ring-Buffers dieser nch ausgelesen wurde wenn er auf 0 stand (>=0) aber geklappt hat es dann besser wenn man vorher abgefragt ob ueberhaupt was im Eingabebuffer steht (Serial.Available() bzw. Serial.Available()) und dann erst diesen einliest (Serial.Read() / Terminal.Read())


    Auch das FabGL Terminal im VGA16Controller-Mode scheint (auch mal wieder aufgrund des graphischen Congif-Menues) wieder mal viel zu heftig zu sein.

    Der Emulator nutzt fuer CPU-Emulation und Serial-Ein-/-Ausgabe jeweils einen Task, der auf einen bestimmten CPU-Core der ESP32-CPU gepinnt ist.


    Ich denke der VGA16Controller nutzt auch so was in der Art, deshalb habe ich zur Zeit Probleme mit dem Init der SD-Karte.


    Diese sind weg, wenn man den VGATextController nutzt, was "leider" den Nachteil hat, dass man die Konfiguration (wie Tastaturlayout und Bildschirmfarben) im .ino Source-Code erledigen muss.


    Aber das macht man ja nur 1x :)


    Dafuer laeuft er jetzt - aus meiner Sicht - echt gut, dafuer dass es meine erste eigene Text-Emulator-Umsetzung auf FabGL ist. Damals beim RunCPM hatte mir ja schon Derek Cooper die Arbeit sozusagen vorbereitet mit der v4.4 :)


    Zusaetzlich hat der Autor des ESP32-Z80-Emulator gerade diesen auf V2.0 gehoben und auf diese Version habe ich noch einmal aufgesetzt bzw. daraus eine Jr-cutdown Version erstellt fuer den VGA32.


    Nebenbei habe ich diese auch fuer meinen WeMOS D1R32 (normaler ESP32) und den Deneyap mini (ESP32-S2) umgesetzt und auch da laeuft die Jr-Version gut :)


    Die neue Version liegt im Download Bereich meines Github


    Nach 2 Webseiten koennte es ein ATARI DiskImage sein - das koennte nach dem Alter und der Groesse ja auch hin kommen...oder soll es bewusst vom PC kommen?


    https://www.fileviewpro.com/en/file-extension-di/

    https://www.atarimax.com/jindroush.atari.org/afmtdi.html

    Zitat

    Steven J Tucker developed the DI file extension, also know as a Atari Disk Image file, for the APE software package.

    PCXFormer, SIO2PC, APE bzw. XL/ST link / XLDJ Disk Image file

    wenn ich die Ein-/Ausgabe ueber den seriellen USB-Port "route" im Source dann klappt die Ein-Ausgabe via einem externen puTTY-Terminal ohne Probleme :(

    So muss es am FabGL-Terminal liegen oder an meiner Nutzung dessen.... aber der Code ist ja eigentlich vom RunCPM kopiert und da laeuft es auch ohne Probleme....

    Da ich wegen der Idee der Umsetzung heute Nacht um 05:00 nicht mehr schlafen konnte, habe ich meine Kreativitaet freien Lauf gelassen und den vorhandenen Code aufgefuellt mit dem FabGL-Terminal aus "meiner" RunCPM-VGA32-Version.


    Das geht in der naechtlichen Kreativitaet meist gut von der Hand (besser als erwartet).

    Einzig einige Bibliotheken (FabGL und SD) hatten wegen doppelter Variabennamen im Bereich der SPI-Pindefinition so viele Fehler geschmissen, dass ich es fast aufgegeben habe ;)


    Aber nachdem alle falschen Fehlermeldungen weggedacht waren und es dann ganz trivial war (z.B. anstatt MOSI nimmt man SD_MOSI) klappt das compilieren ohne Fehlermeldung ;)


    Allerdings mag das Zusammenspiel im Bereich der Tastatur noch nicht ganz 100% klappen.

    D.h. man muss in bestimmten/seltenen Faellen die Taste Enter/Return 2x druecken.

    So z.B. beim Start um an den Prompt zu kommen oder nach dem DIR eingegeben wurde.

    Gibt man am Prompt nicht oder nur Leerzeichen ein, klappt es auch mit 1x druecken :(


    Das ist wohl ein Buffer-Problem der Ein-/Ausgabe, denn auch wenn das FRACTAL Basic Programm das Apfelmaennchen ausgeben will, bleibt die Bildschirmausgabe auch immer wieder mal stehen und geht nach einem Tastendruck weiter - auch wenn es an der Stelle nicht notwendig waere.


    Evtl. hat ja hier jemand eine gute Idee / helfende Hand und kann sich das mal im Source ansehen? ;)

    Auf der Startseite in Github (README.md) sind auch diese Probleme und ein paar Notizen zum Stand des Initial-Relese zu lesen :)


    Verstehe ich das richtig, daß das auf das RC2014 Format beschränkt ist, und nicht mit in einer diskdefs Datei beschriebenen Formaten funktioniert?

    Fuer diskdefs kann man den CPM Image File Explorer (z.Zt. v0.05) nehmen
    (wobei die (fuer mich) neue v0.0.5 - ich hatte vorher nur die v0.0.2 auch meine RC2014 diskdefs mit dem offset versteht - wobei dies hier mit rc2040imga Laufwerk A: eines RC2014 ohne 1K-Header/Offset ist))



    Zitat

    CP/M Image File Explorer dient zum einfachen Erzeugen und Bearbeiten von binären Disketten- und Festplatten-Images.

    Der CP/M Image File Explorer basiert auf dem Source-Code der CP/M-Tools von Michael Haardt in der Version 2.21.

    http://www.moria.de/~michael/cpmtools

    Entwickelt wird der CP/M Image File Explorer in C/C++ mit den wxWidgets Version 3.1.5 als GUI-Framework. Als Entwicklungsumgebung dient die CodeLite-IDE von Eran Ifrah.

    https://codelite.org

    cpmls: unknown unit specifier " "

    durch den selben build (2.20-2build1) auf einem ambian bullseye (debian) sagte er mir zu der diskdefs-datei dann auch, dass das Problem in Zeile 215 war.


    Es war ein " " (Space) beim Offset Zwischen der Value und dem "sec" fuer Sektoren.


    Unter armbian Hirsute (Ubuntu) sagte er die Zeilennummer nicht :(

    Nun klappt es auch wieder auf dem Hirsute-Rechner, nachdem er sich heute Morgen wieder weigerte.


    kkaempf Neuere MBASIC-Versionen habe ich auch ;)
    Ich habe folgende Versionen

    4.3

    4.51

    5.1

    5.21

    5.22

    und

    5.29


    Dein 5.2 hast Du nicht evtl. als uebersetzte Version (.COM)?


    Ansonsten gibt es wohl noch 5.26 alphatronic, das habe ich auch noch nicht aus dem .IMD/.RAW

    rausbekommen. Das in der diskdefs enthaltene alpha-def greift nicht :(


    PS: den Backspace/DEL-Key Patch fuer MBASIC kennst Du?

    Damit kann man einige neuere Versionen patchen, dass man auf der Eingabezeile rueckwaerts loeschen kann ;)

    Interessanterweise gehts bei der 5.21 und 5.29, aber nicht bei der 5.22

    Strange :(

    auf einmal weigerte sich der eine Rechner auch wenn nur ibm-3740 in der diskdefs definiert war mit

    cpmls: unknown unit specifier " "


    Obwohl es der gleiche Befehl war. Auch loeschen und neu installieren brachte den selben Fehler (obwohl es von anderen Rechnern ging)


    Erst als ich den Befehl

    cpmls -f ibm-3740 -i /toshiba/MB43IMD.RAW

    nutze (also das -i drin) loeste sich der Knoten und alles ging wieder.... versteh ich nicht :(


    Google kannt das Problem nicht.

    kkaempf JA SUPER :) Vielen Dank!
    Ich habe das gerade nochmal nachvollzogen auf meinem System.

    Meine beiden RAW Konvertierungen von samdisk und IMDU waren gleich und wurden von den cpmtools

    mit der Definition ibm-3740 sauber erkannt.

    Die ibm-3740 hat gegenueber meiner einfachen diskdef-Definition noch ein paar Optionen mehr drin, die es wohl ausmachen.


    Ich dachte ich haette meine diskdef auch nach 77 (fuer 77 tracks) durchsucht... hat wohl nicht geklappt.

    Allerdings musste ich bei meiner grossen diskdef auch alles ausser der ibm-3740 rausnehmen, da wohl irgendwo ein Fehler drin ist, denn mit allen Defs sagte er vorher bei der ibm-3740 immer

    cpmls: unknown unit specifier " " :(


    Man sollte echt nur Defs drin haben, die man nutzt :)


    Zum Beweis dass die Datei geht hier auch ein Bild vom MBASIC-Start ;)


    Genau kann man es nicht sagen.

    Von innen und von den Kartenanschluessen hinten sieht es aus wie ein PC-Clone des IBM XT

    Von vorne hat das Gehaeuse ein paar Design-Anleihen am IBM-AT-5170 (286) genommen.


    Aufgrund der Seagate-MFM/RLL-Platte tippe ich doch eher auf einen PC XT aus einer NoName-Schmiede ;)

    Kann mir jemand helfen MBASIC Rev. 4.3 aus dem Image zu extrahieren?

    Toshi hatte es ja damals auch schon "gesucht" (und ob es das aelteste ist):
    ältestes CP/M Microsoft Basic


    Ich habs versucht, bekomme es aber nicht hin :(


    Mit den cpmtools hab ich versucht aufs .raw zuzugreifen:


    diskdef imsai

    seclen 128

    tracks 77

    sectrk 26

    blocksize 512

    maxdir 256

    boottrk 0

    skew 0

    os 2.2

    end



    aber schon beim cpmls kommt zuviel "Muell" mit neben den Dateinamen.

    Richtig Dateinamen darin sind wohl:


    copran.asc

    cpindex.bas

    glmenu.asc

    loan.asc

    mbasic.com

    mortg.asc

    portval.bas

    portval5.bak

    portval5.bas

    startrk.asc

    timegain.bas


    mit samdisk hatte ich aus dem .imd ein .raw gemacht:

    C:\TEMP\SAMdisk3811>samdisk MBAS43.imd MBAS43.raw

    Wrote 77 cyls, 1 head, 26 sectors, 128 bytes/sector = 256256 bytes


    Oder hat jemand die 4.3er MBASIC.COM auch so?

    Ansonsten habe ich wohl "alle" ab der Rev. 4.51 ;)

    Nachdem es fuer den ESP32 (hier mal nicht der TTGO VGA32) RunCPM (ohne echtes BIOS) und eine Altair-Emulation gibt, fand ich gestern beim im Netz stoebern den ESP32-Z80-Emulator fuer TTGO T1/T2 von David Bottrill


    Wenn ich jetzt eins der Boards gehabt haette, wuerde ich den vollen Code versucht haben.
    Aber mangels solch eines Boards habe ich versucht den Emulator auf meinem WeMOS D1R32 (ESP32-Duino) zum laufen zu bringen.

    Deshalb habe ich einige Funktionen/Code-Bereiche eliminiert

    - der virtuelle GPIO Port A & B fiel raus, weil ich zu wenige freie GPIO auf meinem Board habe bzw. diese nicht die Aus-/Eingaberichtung laut Software

    unterstuetzen :(

    - der Telnet-Server fiel raus, weil er sich zwar mit meinem Router verband, ich aber keine Ausgabe auf dem Telnet-Port bekam

    - der SPIFFS-Unterstuetzung fiel raus, weil ich nur die SD-Karte nutzen will und es Code/Speicher spart


    Dann habe ich noch alle Hinweise und Codefragmente fuer TTGO T1/T2 (der T2 hat ein eingebautes Display) eliminiert.


    Angepasst habe ich die SPI-Pin-Daten, so dass diese zum WeMOS D1R32 passen.


    Der Emulator unterstuetzt fuer den Dateitransfer zum CP/M die SD-Karte mit einigen eigenen Befehlen:


    Code
    Additional CP/M utilities are provided:
    sdfiles.com - Lists files in the current SD card directory, defaults to /downloads
    sdpath.com - sets the SD card path, defaults to /downloads.
    sdcopy.com - copies a file on the SD card to CP/M disk

    Damit diese funktionieren konnte ich beim compilieren mit der ARDUINO IDE "nur" den ESP32-Core v1.0.6 nutzen.
    Mit einem ESP32-Core v2.x.x warf mir der Emulator beim Aufruf der Befehle immer Fehler oder restartete.


    Fuer die Laufwerke A: - P: kann man jeweils eine 8MB-Image datei nutzen.
    A: wird mitgeliefert und kann dann kopiert als Vorlage fuer die anderen Laufwerksbuchstaben genutzt werden.



    Verstehe ich das richtig, daß das auf das RC2014 Format beschränkt ist, und nicht mit in einer diskdefs Datei beschriebenen Formaten funktioniert?

    Soweit ich weiss - leider - JA. Und da auch nur fuer das RC2014 Grant Searles Format, nicht das RomWBW

    Das Programm/Project kommt von einem Nutzer aus der RC2014-Z80 Google-Group und somit ist es wohl darauf beschraenkt.


    Wenn sich einer "reinhaengen" will gibt es den Source - da gibt es sicherlich einiges als Unterbau zum uebernehmen, wenn man es fuer ein anderes Format nutzen/compilieren will.

    Der Framepuffer muss sich ausserdem im internen SRAM befinden.

    Für eine Auflösung von 800x480 Pixeln und je 6 Bit für Rot, Grün und Blau reicht das interne SRAM natürlich nicht aus.

    Ich weiss nicht ob es technisch ueberhaupt moeglich/nutzbar ist, aber einige ESP32 haben doch bis zu 8MB PSRAM

    Ich weiss nur nicht wie sich sich gegenueber dem normalen SRAM verhaelt.

    Der VGA32 von TTGO hat z.B. PSRAM mit drauf.

    Nachdem ich nun gestern ein diskdef-File fuer ein 128MB .cf/.dsk RC2014 erfolgreich erstellt habe um Zugriff sauber mit den cpmtools (unter Linux) zu erhalten, finde ich beim durchlesen alter Threads in der Google-Group RC2014-Z80 einen Thread zur Software

    CP/M Disk Manager

    vom Dezember 2021, in der die Verwaltung unter Windows graphisch wie in einem Datei Explorer moeglich ist *seufz*

    Aber OK - eine gute Moeglichkeit mehr und evtl. fuer einige Leute, die nicht firm mit Linux sind eine gute Alternative.


    Das Programm bietet einige gute Funktionen und ist aus meiner Sicht sofort gut bedienbar.


    Wenn als Administrator gestartet, dann kann man *ACHTUNG gefaehrlich bei falscher Auswahl* => direkter Laufwerkszugriff!

    auch direkt auf eine CF/SD-Karte zugreifen anstatt eines Disk-Image


    Zu finden ist der CP/M Disk Manager auf Github



    Ich glaube ich habe das/mein Problem geloest beim Zugriff mit cpmtools auf die .cf-Datei, die im Verleich zu einer .img Datei einen 1K-header hat.


    Bei diskdefs, die ich bis jetzt gefunden hatte wurde ab Laufwerk B: (fuer Dateien die 8MB Laufwerke A:-O: und 2MB fuer P: enthalten) immer ein offset pro Partition von 512 Tracks angegeben.


    Wenn man diese mit einer .cf Datei nutzt bekommt man zwar richtige Directory-Anzeigen aber beim kopieren/loeschen geht es dann "in die Hose".


    Um nun den 1K Header mit ins offset zu bekommen, kommt uns zu Hilfe dass ein Sector 512 Bytes hat - also 2 Sectoren der Groesse des Headers entsprechen :)


    Wenn wir das offset in der diskdef nicht mehr in Tracks (trk) sondern in Sectoren (sec) angeben, koennen wir "netterweise" einfach beim offset der Partiton im im Verhaltnis zum Start des Image einfach 2 Sectoren dazuzaehlen.


    Pro Partition gibts da einen Abstand von 16384 Sectoren (512 Tracks mal 32 Sectoren)

    Gehen wir also davon aus, dass Laufwerk A: einer 0 entspricht und somit Laufwerk P: 15

    ergibt gibt sich folgende Formel fuer die offset-Option in der diskdef


    offset = 2 (=2x512 bytes fuer den header) + ( Laufwerknummer/-wert * (512 Tracks mal 32 Sectoren))


    Das Ganze habe ich dann mal in eine diskdefs fuers RC2040 gepackt und auch erfolgreich getestet :)
    D.h. ich muss das .cf nicht mehr zum .img auseinander nehmen und kann direkt mit dem .cf arbeiten.

    Nach ein wenig lesen fand ich den Befehl um im RP2040-SDK den Pico von seinen Standard 125Mhz auf 250Mhz zu overclocken (wie man es auch in der ARDUINO IDE machen kann):

    Code
    set_sys_clock_khz(250000, true);

    Diesen Beghl habe ich an der richtigen Stelle in der RC2040.c (im Bereich nach dem "main") eingefuegt und RC2040 neu compiliert.... (.UF2 und .c im Anhang)

    Nun laeuft er doppelt so schnell ;)

    Zum leichteren Zugriff auf die Laufwerke A:-P: mit den cpmtools gibt es in dem Goolge-Groups-Archiv einen netten/hilfreichen Thread mit dem man durch die dort enthaltene defs-Datei direkten Zugriff auf die Laufwerke A:-P: hat, obwohl diese im .img/.cf Image-File liegen.

    Es braucht aber einen "kleinen Umweg" fuers saubere funktionieren der cpmtools, weil ein .cf (IDE Disk format file) im Gegensatz zu einem .img File einen 1Kb Header (vorne dran) hat (holds meta-data and the virtual identify block)


    D.h. bevor man die cpmtools nutzen kann fuer Laufwerk A: - P: muss man entweder den header wegschneiden -
    oder wie wir hier - nehmen uns das Standard 128MB .img (15x 8MB + 1x 2MB (P:) -Laufwerk fuer A: - P:) - kopieren unsere Software drauf und erstellen ein neues .cf mit dem 1Kb Header vorne dran.


    Die Befehle/Links habe ich mal (eher in Source-Schreibweise) mal zusammengestellt: