Beiträge von Dietrich

    Zitat

    Was meinst Du mit "freigeben"?

    Mein Win10 weist mich bei fremden Programmen gerne darauf hin, dass die Quelle nicht sicher sei, z.B. weil das Zertifikat nicht aktuell ist und fragt, ob ich das Programm trotzdem starten möchte. Wenn ja, merkt sich das System das und fragt nie wieder.


    Dietrich

    Zitat

    Blöd gefragt: Was brächte eine 64-Bit-Version an Vorteilen ?

    Naja, auf meinem WIN64-System verursacht die 32_Bit-Version eine Fehlermeldung (diskdefs hat ein ungültiges Format), das Programm ist dann auf dem Schirm nicht korrekt formatiert und ob es funktioniert, habe ich noch nicht getested.

    Falls sich das irgendwie anpassen lässt, weis ich noch nicht. Ich bin da für Hinweise dankbar.


    Dietrich

    SD-EDIT V1.1

    Nachdem die Partitionsinfos in FAT-Dateisystemen doch recht komplex sind, habe ich im SD Editor noch einen Befehl implementiert, diese etwas übersichtlicher und schon in nutzbare Daten umgerechnet darzustellen.


    Der neue Befehl ist P[n]. n = Partitionsnummer 1..4. Nur P gibt eine Tabelle der 4 Partitionen im MBR aus.



    Damit hat man es etwas leichter, dem System unter die Haube zu schauen. Das ist besonders interessant bei der weiteren Software-Entwicklung, wenn es darum geht, etwas ins FAT-System hineinzuschreiben und man auf dem JC-][ kontrollieren möchte, ob das auch da landet, wo es hinsoll...


    Viel Spass

    Dietrich

    Fig-FORTH


    Neben BASIC gibt es unter CPM-65 eine weitere Programmiersprache: FORTH, hier in der Version Fig-FORTH mit CPM-65 BDOS-Schnittstelle. FORTH ist seit dem Siegeszug von C, C+ und Co bei den Programmierern eher in Vergessenheit geraten. Das ist verständlich, denn auf den modernen Systemen erlauben die verfügberen Ressourcen einen ganz anderen Komfort.


    Für 8-Bit-Maschinen mit maximal 64 kByte Hauptspeicher ist FORTH jedoch die für mich beste Compilersprache. Der Betriebssystemkern ist nur 7 kB groß, das System mit Full-Screen Editor hat 11 kB. Ein kompiliertes FORTH-Programm wie SYSINFO kommt mit 8 kB daher. Damit kann man auf dem JC-][ sehr komfortabel leben.


    FORTH-Applikationen sind kompakt, schnell und komfortabel zu entwickeln. Sie erlauben den direkten Zugriff auf alle Systemressourcen. Ich nutze Forth vor allem für die Entwicklung von Interfacetreibern und Systemprogrammen. Funktioniert das Interface, ist der Treiber sehr einfach in Assembler umzusetzen. Aber auch für die Programmierung von Spielen ist FORTH schnell und systemnah genug.


    Der Preis für all diese Vorzüge ist eine Sprachstruktur, die es dem System leicht macht und an die sich der Programmierer erst gewöhnen muß. Kernelement ist die umgekehrte polnische Notation (UPN). Da kommen zuerst ein oder mehrere Argumente und dann der Operator, der diese Argumente verarbeitet. Etwa so: 1 1 + . Dabei werden die Argumente in der Reihenfolge der Eingabe auf einen Stack gelegt, von dem sie der Operator in umgekehrter Reihenfolge abholt. Das Ergebnis der Operation wird dann wieder auf dem Stack abgelegt und kann vom nächsten Operator verarbeitet werden.


    Doch genug der Vorrede - es geht los. Damit ihr auch was davon habt, solltet ihr euch das neue FORTH.IMG auf die SD ziehen. Ich habe in den letzten Tagen den Fullscreen-Editor auf die VT100-kompatiblen ROM-Routinen des JC-][ angepasst und das Ergebnis heißt FORTH-VT.COM. Und das solltet ihr nun aufrufen.

    Fig-FORTH V1.6 meldet sich. Nun gebt ihr NEW ein - Groß- und Kleinschreibung spielt in FORTH keine Rolle - und sitzt vor einem leeren Screen im Editor. FORTH arbeitet mit SCREENs, die im Falle des JC-][ von 3 .. 19 reicht. Jeder Screen hat exakt 1 kB Größe und liegt in der aktuellen Implementierung im RAM oberhalb von $8000. Das hört sich nach nicht viel an, aber glaubt mir - es reicht dicke. Aus systemtechnischen Gründen ist #3 der erste Screen, 1 & 2 gibt es nicht.

    Nun schauen wir erstmal, was der Editor so kann und rufen mit der ESC-Taste die Hilfeseite auf.

    Traditionell liegen die Cursor-Befehle auf CTRL-EXDS, aber die Pfeiltasten funktionieren auch - jedenfalls unter TELETERM. Damit kann das Eingeben beginnen:

    Programmzeilen werden kontinuierlich eingegeben. Kommt man am Zeilenende in Spalte 64 an, sprint der Cursor in die nächste Zeile, wo man einfach weiterschreiben kann. Das sieht aber furchtbar aus und erschwert die Lesbarkeit.

    Mit ( beginnt ein Kommentar, mit ) endet er. Vor und nach einem Befehl muß ein Leerzeichen stehen, außer natürlich beim allerersten Zeichen auf einer Seite. In Zeile 3 definieren wir unseren ersten Befehl, den Zeilenvorschub nl, also die Ausgabe von $0D und $0A. Da wir im Moment im Dezimalsystem arbeiten müssen wir alle Argumente auch dezimal eingeben. Das könnte man auf Hexadezimale Zahlenbasis umstellen, aber jetzt nicht.


    Als nächstes kommt das eigentliche Programm - das berüchtigte Hallo Welt... Mit ;S wird das Programm beendet und wir verlassen den Editor mit CTRL-Q.

    Das System meldet sich nun mit ok zurück. Wir kompilieren das neue Programm mit 3 LOAD und warten auf die Fertigmeldung ok. Und geben wir HALLO ein und freuen uns, dass alles geklappt hat.


    Und weil wir das Programm so schön finden, speichern wir es mit SAVE HALLO.BLK auf die Disk. Von dort können wir es jederzeit mit OPEN HALLO.BLK wieder ins RAM holen.

    Aber woran kann ich den sehen, welche Befehlsworte unser FORTH versteht? Dazu geben wir VLIST (Vocabulary List) ein.

    ... und man sieht alle definierten Befehlsworte in der umgekehrten Reihenfolge, wie sie erzeugt wurde, also unsere Worte NL und HALLO zuerst. FORTH-Befehlsworte dürfen bis zu 31 Zeichen lang sein. Das ist komfortabel.


    Nun gefällt uns unser Programm aber noch nicht ganz. Wir öffnen den Editor wieder mit E, gehen in Zeile 5 und fügen beispielsweise ein zusätzliches NL vor dem Text ein. Dazu den Einfügemodus mit CTRL-V einschalten. Dann mit CTRL-Q den Editor verlassen und mit 3 LOAD kompilieren. Aber oh weh - es gibt Fehlermeldungen:

    Fehlermeldungen in der CPM-65 Fig-FORTH Implementierung sind einfache Codes - hier beschwert sich der Compiler, dass ein schon existierendes Befehlswort nochmal definiert wurde. Das macht hier nichts - ausgeführt wird immer die neueste Version.

    Trotzdem ist das unschön und dafür gibt es auch ein FORTH-Wort, nämlich FORGET. Damit streicht man das angesprochene Wort und alle jüngeren aus dem Vokabular. Da wir NL zweimal haben müssen wir das forget NL auch zweimal eingeben. Und dann können wir HALLO neu kompilieren - diesmal ohne Fehlermeldung.


    Soweit der Einstieg in FORTH. Hingewiesen sei noch auf die Befehle DIR (Ausgabe des Disk Directory) und KILL (Löschen des Programms). Und schaut euch gerne mal SYSINFO.BLK an. Wer nun Blut geleckt hat, dem empfehle ich folgende Literatur:


    Deutsch:

    Literaturliste des FORTH-eV https://wiki.forth-ev.de/doku.php/projects:litlist

    Meine Empfehlung: Die Programmiersprache Forth von Ronald Zech, Verlag: Franzis. Leider nur noch im Antiquariat.


    Englisch:

    Starting FORTH von Leo Brodie (der Klassiker überhaupt)

    Thinking FORTH von Leo Brodie

    frei bei https://www.forth.com/forth-books/


    weitere Literatur und Programme bei https://www.forth.org/

    dort besonders Forth Dimensions https://www.forth.org/fd/FDcover.html


    Viel Erfolg

    Dietrich

    Da wäre ich auch dabei mit mind. V9938, 82C765, 4164, die 64 pol. Fassung und sicher noch diverses andere. Ich denke, sobald Jörg die Stückliste fertig hat, sollten wir loslegen.


    Dietrich

    2ee Alles gut. CPM-65 hängt derzeit nicht (mehr) von der ROM-BIOS-Version ab. Ein neues ROM-BIOS könnte natürlich Verbesserungen ermöglichen, die dann zu Veränderungen im CPM-65-BIOS führen könnten. Das wird man sehen. Derzeit gibt es da nur ein relevantes Thema und das ist die Nutzung der Speicherstelle $00F1 durch die ROM-IRQ-Routine. Dies zwingt CPM-65 derzeit zum Abschalten des IRQ, was CPM-65 prinzipiell egal ist, aber auf lange Sicht nicht toleriert werden kann. Da hängt potentiell zu viel dran…


    Auf die MOS-65 Weiterentwicklung freue ich mich schon sehr. Ich hoffe, dass der Portierungsaufwand sich in Grenzen hält. Dann kann ich noch etliche Software liefern.


    Und die neue Grafik/Floppy-Karte eröffnet ja jede Menge neue Perspektiven… 👍🤩


    LG Dietrich

    Das macht man eigentlich nur bei sehr großen Elkos. Bei kleinen schadet es aber nicht.

    Prozedur: Mit einer Konstantstromquelle mit ca. 50 mA - 500 mA, je nach Größe, auf die max. Gleichspannung laden. Einmal reicht. Es sollte nun nur noch ein minimaler Leckstrom fließen.

    Damit wird die Elektrochemie wieder sortiert - Nachbildung der elektrischen Doppelschicht an Anode und Kathode.


    Dietrich

    Zitat

    Ausserdem enthalten die letzte MKBOOT.COM (im Verzeichnis SYSTEM), mit der u.a. Dietrich auch mal seine partitionierte SD-Karte testen kann.

    2ee Das Problem saß mal wieder vor dem Computer. Kaum hatte ich auf einer SD 3 primäre Partitionen angelegt - FAT16, FAT32 und FAT12 -, schon funktionierts. Ich verwende übrigends den 'Mini Tool Partition Wizard'. Der ist für Gelegenheitsbenutzer recht praktisch, weil simpel.


    Super Cool - MKBOOT legt auf allen 3 Partitionen den korrekten Bootsector an. Man kann dann beim Booten die Partition auswählen und das bedeutet, dass man auf jeder Partition ein anderes System laufen lassen kann. Beispielsweise Partition 1 CPM-65 und Partition 2 M/OS-65. Dann braucht man zum Wechseln nicht mal mehr eine neue SD einzustecken.


    Und bei der Gelegenheit habe ich gleich festgestellt, dass die BOOT.SYS von CPM-65 auch von FAT12 booten kann 8)


    Ich bin begeistert :applaus: :sunny:


    Dietrich

    Zitat

    Junior ][ Mainboard,

    es würde sinn machen ein CPU Board ohne Tastatur und Anzeige zu entwerfen.

    Weil als "Vollausbau Version" sind diese Sachen zwar schön aber überflüssig.

    Ich bin mir nicht sicher, ob das Sinn macht. Meine CPU-Karte habe ich ohne Tastatur und Anzeige aufgebaut, nur mit Reset und BREAK-Taste - die braucht man halt schon. Der Formfaktor ist auch nötig, damit man das Platinenpaket mit den anderen Karten gut montieren kann.


    Und eine alternative Platinenvariante macht langfristig Probleme, weil sie natürlich auch geupdated werden muss, wenn es doch noch mal eine Änderung gibt.


    Dietrich

    Programmieren unter CPM-65 - BASIC

    Ich hatte es ja schon vor Wochen versprochen, aber wie so oft kam etwas wichtiges dazwischen...


    Natürlich hat auch CPM-65 ein BASIC. Auf dem JC-][ hat man da mit EH-BASIC eine tolle Version im ROM, aber die kann man unter CPM-65 nicht benutzen, weil das ROM abgeschaltet ist - im RAM darüber liegt nämlich CPM-65. Also bescheiden wir uns mit dem historisch wertvollen Microsoft-Basic KB9 in der Version des CBM 8032. Das habe ich vor 40 Jahren in einem langen Winter höchstpersönlich per Hand aus einem Printout des Original reassembliert und später mit den notwendigen Erweiterungen zum Laden und Speichern von Programmen erweitert.


    Zu CBM-BASIC brauche ich wohl nicht viel sagen - Details im Handbuch. Die Timervariablen TI, TI$ sind statisch weil ich die Echtzeituhr des JC-][ noch nicht eingebunden habe. Ebenso wird die RND-Funktion immer gleich initialisiert, ist also nicht wirklich RND.


    Man startet mit BASIC [filename]. Trägt filename die Extension 'BAS' und ist ein CBM-BASIC-File, wird es geladen und gestartet. In diesem Fall versuchen wir es mal mit BASIC STARTREK:

    Auf dem BASIC-Image ist auch noch WUMPUS, beides aus dem bekannten Buch von David Ahl.


    Programme gibt man in BASIC ein, wie gewohnt. Gespeichert wird mit SAVE"filename". Die Extension 'BAS' erzeugt BASIC automatisch. Laden geht dann mit LOAD"filename" und mit RUN"filename" wird das Programm geladen und direkt ausgeführt.


    Wie bekommt man aber Programme ins BASIC, die als ASCII Textfile vorliegen? Nun dazu eignet sich die Copy-Paste-Funktion von TERATERM ganz hervorragend. Man muß nur in der Serial Port Config mind. 500ms Delay pro Zeile eintragen, damit die Garbage Collection keine Zeile verschluckt. Das dauert etwas, ist aber wesentlich entspannender als tippen ..


    Viel Freude mit Startrek auf dem JC-][


    Dietrich

    Und hier noch ein kleines Programm für Abenteuerlustige: SD-EDIT.COM


    Mit diesem Programm kann man der SD aufs Byte schauen und auch jedes Byte ändern. Bei letzterem bitte Vorsicht und Umsicht walten lassen und nur mit einer SD-Kopie arbeiten. Man kann damit die SD so zerschießen, dass nur noch eine Neu-Formatierung hilft....


    Zum Einlesen empfehle ich Das FAT-Format


    Das Programm also auf die SD kopieren und mit SD-EDIT starten. In der Statuszeile sehen wir immer die LBA des aktuellen Sektors. Dieser wird auch sofort in den internen Buffer eingelesen und steht zur Bearbeitung bereit. MIt '? lassen wir uns erstmal die Befehlsübersicht ausgeben


    Geben wir nun einfach 'D ein, wird der aktuelle Sektor ausgegeben. Hier ist es der MBR.


    An der Speicherstelle $1C6 liegt der absolute LBA der 1. Partition, hier $00002000. Den wollen wir mal ansehen


    Aha, der mit MKBOOT modifiziert Bootsector von M/OS-65. Nun wirds etwas kompliziert. In diesem Bootsector liegen nämlich alle nötigen Infos, in der Partition etwas zu finden, z.B. das Root-Directory. Leider ist der Aufbau dieser Daten in FAT16 und FAT 32 unterschiedlich. Details müsst ihr selbst nachlesen. In meinem Fall (FAT32) liegt das Directory in LBA $4000

    Und hier sieht man nun das Directory-Format in seiner ganzen grausigen Schönheit ...


    Viel Spass

    Dietrich

    Hallo 2ee,


    ich habe das heute vormittag versucht nachzustellen. Bei mir bootet auf dem ROM 1.1.0 CPM-65 V.0 mit der enthaltenen BOOT.SYS V1.5 nicht zuverlässig. Diverse Meldungen, dann Absturz. Manchmal geht es aber eben doch. Der Fehler ist bekannt und mit BOOT.SYS V1.6 behoben.


    Die aktuelle Version ist BOOT.SYS 1.9. 1.6 und 1.9 gehen mit ROM1.1.0 und natürlich auch mit den neueren ROM-Versionen. Das klappt mit FAT16 und FAT32 als primäre Partition. Leider ist es mir bisher nicht gelungen, auf SDs mit mehreren Partitionen den mit MKBOOT den Bootsektor zu modifizieren. MKBOOT stürzt bei der 2. Partition einfach ab und schreibt nichts.



    Im Laufe des Testens ist allerdings eine SD-Karte verhaltensauffällig geworden - mal geht sie, mal nicht. Dem gehe ich nach.


    Bitte schaue dir trotzdem mein BOOTSYS mal an - es könnten durchaus noch Fehler drin sein.


    Dietrich

    Update: CPM-65 V1.1 ist raus, wie immer im GitHub Repository CPM-65 für den JC ][.


    Zitat

    Changes:

    • BIOS uses now standard ROM entry points to become independent from ROM changes
    • BOOT.SYS and SD-UTIL were also adopted to use standard ROM entry points
    • Error corrections in D.COM and XMODEM.COM
    • New Fig-FORTH version with VT100 compatible full screen editor to be used with most populat terminal emulators


    Und hier noch das Paket für Eilige


    Wie immer alle Files auf die SD packen und nicht vergessen, die Images wieder mit SD-UTIL zu mounten.


    Viel Spass

    Dietrich

    Need for Speed

    Es war etwas arbeit, aber die optimierten SD-R/W-Routinen sind fertig. Ich erreiche im Block-Read 41 kB/s (Original 25 kB/s) und im Block-Write 22 kB/s. Damit bin ich sehr zufrieden.

    Das theoretische Limit läge bei 55 kB/s. Das ließe sich erreichen, wenn man die Routinen ins RAM kopieren würde und in der Initialisierungsphase die Adresse der I/O-Karte in den Code schreiben würde. Aus meiner Sicht rechtfertigt der Geschwindigkeitszuwachs den Aufwand nicht. Dass das Schreiben so viel länger dauert, liegt daran, dass man das SR 74LS165 per Bitbang laden muss und das braucht alleine 36 us/Byte.


    In der Praxis ist der Geschwindigkeitszuwachs gut messbar, aber natürlich nicht mehr so groß.

    Mein Benchmark ist das Assemblieren von BASIC.ASM (74 kB Code, 2 Passes Lesen des Codes, Assemblieren, Schreiben des COM-Files 10 kB und des LABEL-Files 36 kB):

    - Original 60,7 s

    - optimiert 54,6 s (-10%)


    Jetzt muss ich noch den neuen Code ein paar Tage auf Stabilität prüfen und dann muß Jörg entscheiden, wie es weitergeht.


    Dietrich

    Eine kleine Unstimmigkeit habe ich in M/OS-65 gefunden: Wenn man die SD im laufenden Betrieb zieht und wieder einsteckt, klappt der erneute Zugriff nicht ganz. Im Bespiel hier wird das Directory beim ersten Mal nicht vollständig ausgegeben. Gibt man DIR nochmal ein, ist wieder alles ok.


    Im Beispiel habe ich DIR eingegeben, dann die SD gezogen und wieder eingesteckt, dann wieder DIR und dann nochmal DIR.

    Alles kein Aufreger, eher was für die todo-Liste


    Dietrich

    So, nachdem Jörg nun auch das Laden größerer Programme erlaubt - unbedingt die allerneueste BOOT.SYS vom 3.6.24 benutzen - kommt hier gleich mal ein ordentlicher Brocken: Fig-FORTH.


    Wer FORTH nicht kennt: gerade für kleine Systeme ist FORTH als kompakte Compilersprache extrem hilfreich. Sehr hardwarenahe Programmierung und feinteilige Testbarkeit des Codes sind hier hervorzuheben. Und an die UPN (umgekehrte Polnische Notation) gewöhnt man sich. Literatur gibts im Netz. Wer Hardcopies bevorzugt, dem empfehle ich das Buch 'Die Programmiersprache FORTH' von Ronald Zech. Leider nur noch im Antiquariat zu bekommen...


    Mein FORTH ist Original Fig-FORTH mit folgenden Einschränkungen:

    - keine Massenspeicher-Schnittstelle (Jörg muss da noch weiterprogrammieren)

    - keine Druckerschnittstelle (war mir nicht wichtig und etwas Aufwand ist es ja doch)

    - kein Editor (kommt noch, muss auf VT-100 angepasst werden)


    Wegen der noch fehlenden Möglichkeiten, in FORTH etwas zu speichern ist das Arbeiten derzeit noch nicht so elegant, aber möglich.

    Und so gehts:

    - Inhalt der ZIP entpacken und auf dem PC in einen Ordner kopieren - bei mir FORTH\

    - FORTH.COM auf die M/OS-65 SD kopieren, booten und mit FORTH aufrufen


    - Nun zur Kontrolle VLIST eingeben. Es erscheint die Liste aller FORTH-Worte



    Programme kann man in FORTH aus SCREENS laden. SCREENS sind zwar im System schon angelegt, aber man kann sie derzeit weder mit Inhalt füllen noch auf die SD speichern.

    Alternativ kann man Programme auch direkt an der Konsole eingeben. Dazu präpariert man sich das Programm als ASCII File. 2 Beispiele - CS.TXT und PSTACK.TXT sind im Paket. Das File kann man nun ganz einfach per Copy-Paste in Teraterm übertragen. Dazu unbedingt im Serial Port Setup min. 700 ms/line einstellen, da FORTH jede Programzeile direkt compiliert und das kann bei längeren Zeilen etwas dauern. Danach steht das Programm compiliert im Speicher und kann mit seinem Befehlswort ausgeführt werden.


    Beispiel CS: das Programm überprüft die Compiler Security des Systems. Das ist notwendig nach jeder Neu-Assemblierung des FORTH-Kerns, weil Fig-FORTH mit JMP (ind) arbeitet und da darf keine Sprungadresse auf $xxFF fallen, sonst crasht das System.

    Also frisch ans Werk:


    Natürlich ist bei unserem Fig_FORTH alles ok.


    Als 2. Beispiel habe ich PSTACK beigefügt. Das Programm gibt den Inhalt des Stacks aus, ohne diesen zu verändern. Das ist bei der Programmentwicklung eine große Hilfe. Im Beispiel werden erstmal die Zahlen 1 bis 5 auf den Stack gelegt und dann wird dieser mit .S ausgegeben.


    Und nun viel Spass mit FORTH auf dem JC-][


    Dietrich

    Ich habe mal eben testhalber ein kleines Program auf M/OS-65 angepasst.


    Programm: CPUTYPE

    Erkennt, ob eine NMOS oder eine CMOS CPU verbaut ist.


    Das Programm wird einfach in ein Verzeichnis kopiert und mit 'CPUTYPE' aufgerufen. Source Code ist natürlich dabei.




    Natürlich ist das erstmal nur ein kleines Progrämmchen. Sobald ich mich etwas besser in M/OS-65 eingearbeitet habe, insbesondere in die Filesystem-Aufrufe, folgt mehr.


    Dietrich