Beiträge von 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. Ich packe künfige Programm dann in den Thread 'Junior ][ Computer Software', damit hier die Übersicht gewahrt bleibt.


    Dietrich

    Zum Thema BASIC Programm via Teraterm mit Copy-Paste übertragen habe ich jetzt mal ein paar Versuche gemacht. Das Problem ist die Garbage Collection Routine, die recht lange dauern kann. Bei sehr langen Programmen, in meinem Fall STARTREK.BAS, musste ich den transmit delay auf 400 ms/line hochsetzen, um eine fehlerfreie Eingabe zu erreichen. Das ist natürlich eine Geduldsprobe, aber besser als Eintippen ist es allemal.


    Dietrich

    FORTH hat gerade in der alten 8-Bit Welt den Charme, dass man damit nativ auf praktisch jedem System entwickeln kann. Der erzeugte Code ist recht kompakt und die Performance ist auch auf den alten Systemen sehr gut. Die Programme lassen sich auch standalone, d.h. ohne die Entwicklungsumgebung ausführen. Und man kann unmittelbar auf die Hardware zugreifen.

    Die Programme sind sehr strukturiert und lassen sich sehr gut debuggen.

    Ich schreibe gerne experimentelle Treiber mit Forth, und setze das Ergebnis anschließend in Assembler um.

    Der große Nachteil ist die umgekehrte polnische Notation, an die man sich erst gewöhnen muß. Und das fällt am Anfang richtig schwer….


    Dietrich

    Zitat
    Ich verzichte deshalb auch auf eine Sortierung der Einträge, da ich dann ja das vollständige Verzeichnis zuerst in den Speicher lesen muss, bevor ich sortieren kann. Das dauert eben, selbst wenn ich dann einen der schnelleren Sortieralgorithmen wie Quicksort nutze, eine gewisse Gedenksekunde, bis es mit dem Auflisten losgeht.

    Das ist alles nicht so schlimm. Die meiste Zeit braucht das Einlesen der Directory-Blocks, um diese nach den spezifizierten Filenamen zu durchsuchen. Das muß man immer machen. Bei der Gelegenheit kann man die Filenamen auch erstmal in eine Liste schreiben. Diese Liste hat ja maximal einige 100 Einträge. Da reicht auch Bubblesort und das braucht wenig Code. Sortiert werden nur die Pointer auf die Einträge. Sobald das fertig ist, kann man das sortierte Directory ausgeben. Der Zeitverlust ist nur die Sortierroutine. Ich finde insbesondere bei vielen Files ein sortiertes Directory ein Muß. Man findet sonst nix.


    Allerdings, und da hat 2ee natürlich recht, dauert es etwas bis der erste Filename ausgegeben werden kann. Ihr könnt das einfach mal mit CPM-65 testen. Auf der Systemdiskette sind ja jede Menge Files.



    Dietrich

    Zitat
    Wie schnell ist denn das "Disketteninterface" (also die SD-Karten-Datenschnittstelle von oben) jetzt so geworden ? Wenige KB/s oder doch so schnell, daß "on the fly" RAM Austausch damit möglich wird ?

    Die aktuelle ROM-Version schafft 25 kB/s im Blocktransfer, also SD-to-RAM. Mit dem von Jörg erwähnten etwas schnelleren Code sind es 28 kB/s. Möglich, aber noch nicht erprobt sind 41 kB/s. Bitbangroutinen schaffen die 25 kB/s nur beim Lesen, Schreiben ist mit 7-8 kB/s deutlich langsamer. Aber auch damit lässt sich gut arbeiten.

    25 kB/s ist die Datenrate einer MFM-Diskette ohne Spurwechselzeit, etwa ein GOTEK. Ich finde das recht beachtlich.


    Dietrich

    Funktioniert prima auch mit langen Directorynamen - da muß man natürlich die Kurzform eingeben.

    Schön wäre noch, wenn im Prompt der Directoryname erscheinen würde, damit man auch in den Tiefen des Dateibaumes noch weis, wo man ist.


    Hast du schon Ideen, wie die Schnittstelle zu den Anwendungsprogrammen aussehen soll?


    Dietrich

    Wenn man viel mit Images arbeitet, ist ein Floppy-Emulator oder ein DISK-II Emulator mit SD-Karte eine große Erleichterung. Ich persönlich verwende den FloppyEmu von BMOW mit sehr gutem Erfolg.


    Dietrich

    CIFE ist ein tolles Projekt für alle, die mit CP/M-Maschinen unterwegs sind. Für mich ist derzeit die alte C-Version 9.4 unter WIN10 immer noch das Arbeitspferd für mehrere, teils recht exotische Systeme - fast täglich im Einsatz. Ich brauche halt auch die Funktionalität, Files aus den Images zu extrahieren.


    Die neue Lazarusversion V0.8 ist in der Bedienoberfläche nochmal stark verbessert und ich freue mich schon auf V0.9, weil ich dann CIFE-alt pensionieren kann.


    Von mir geht also ein riesengroßes Dankeschön an Uwe ( HobbyProgrammer) für das beste CPM-Image File Tool zumindest unter Windows. Danach habe ich viele Jahre gesucht. :thumbup: :thumbup: :thumbup:


    Dietrich

    Noch'n paar Utilities


    Manchmal ist es nützlich, sich den Inhalt eines Textfiles anzusehen, zum Beispiel weil man sicherstellen möchte, die richtige Version vor sich zu haben. Da s kann man mit TYPE filename.ext [/p] machen. Dabei kann man optional den Schalter /P angeben - dann wird die Ausgabe alle 15 Zeilen angehalten und nach Tastendruck fortgesetzt. CTRL-C beendet das Programm vorzeitig.



    TYPE ist ein originäres CP/M-Kommando, aber in manchen Situationen einfach zu unflexibel. Besser geht das mit BROWSE filename.ext .

    Da kann man mit CTRL-R oder CTRL E eine Seite zurückspringen und mit SPACE oder TAB wieder eine Seite weiter, bis man alles gesehen hat, was man sehen wollte.



    NUN haben wir aber genug Durcheinander auf unserer Übungsdiskette angerichtet und möchte wieder ein jungfräuliches Image haben.

    Das macht FDISK d: für uns. Es kopiert die Systemspuren des aktuellen Laufwerks in die Systemspuren von d: und überschreibt das gesamte Directory in d: mit $E5. Das ist der CP/M-Standard für einen frisch formatierten Sektor. Aber aufgepasst - das machen wir nur mit einem Image, was wir tatsächlich leeren wollen.


    Die anschließende Kontrolle mit D zeigt, dass in der Tat alle Files gelöscht sind. Sicherheitskopien sind wichtig!


    Das wars für heute. Nächste Woche wenden wir uns den Programmiersprachen unter CPM-65 zu.


    Dietrich

    NorbertJ Danke für die schnelle Info. Ich habe ein EEPROM-Image gezogen und verglichen - in der Tat 48 Byte fremder Code.

    Ich gestehe, ich habe im ROM etwas gepatched - da ist wohl was schiefgegangen.


    Neu gebrannt - und schon gehts wieder :fpa: ::heilig::


    Dietrich

    Fehler im Monitor?

    Ich habe mit dem L Commando im Monitor ein kleines Programm angesehen und festgestellt, dass $4C nicht korrekt disassembliert wird. Könnt ihr bitte mal checken, ob das bei euch auch so ist?


    Dietrich

    CPM-65 V1.0 released


    Liebe JC-][-Fans,

    die Entwicklung von CPM-65 für den JC-][ ist nun so weit gediehen, dass ich mich traue ein V1.0-Release zu veröffentlichen.

    Ein dicker Bug war noch in der V0.9, aber das war hoffentlich der letzte. Alle Quellen liegen wie gehabt unter

    GitHub - Dietrich-L/CPM-65_for_JUNIOR_COMPUTER_II at V1.0
    CPM-65 Port for Junior Computer II. Contribute to Dietrich-L/CPM-65_for_JUNIOR_COMPUTER_II development by creating an account on GitHub.
    github.com



    Also bitte die neue Version aufspielen und weiter Spass haben


    Gruß


    Dietrich

    Housekeeping

    Die wesentliche Aufgabe von CPM-65 ist die Verwaltung von Files auf dem Speichermedium. Dazu liefert CPM-65 eine Reihe von Funktionen mit. Jede Funktion ist für sich in ein Hilfsprogramm gepackt, das mit den passenden Parametern aufgerufen werden muß, um seine Aufgabe zu erfüllen.

    Bevor wir mit diesen Programmen beginnen, brauchen wir als erstes eine Übungsdiskette. Dazu kopieren wir in Windows oder LINUX das Disk Image BLANK.IMG, benenen die Kopie in WORKDISC.IMG um und kopieren das Image auf unsere SD-Karte.

    Nun booten wir das Image CPM-65, wie gewohnt und installieren mit SD-UTIL WORKDISK.IMG in Laufwerk B:. Wer möchte, kann diese Kombination mit P permanent machen - das muß aber nicht sein. WORKDISK bleibt in B: bis wir entweder ein anderes Image mounten oder neu booten.

    Bisher ist WORKDISK.IMG ja noch leer. Mit D B: können wir uns davon überzeugen

    Die Fehlermeldung 'File not found' sagt uns, dass das Image in der Tat leer ist. Das können wir ändern, indem wir mit COPY *.COM B: mal eben einen SChwung ausführbaren Programme von A: nach B: kopieren. Copy fragt dabei bei jedem File, ob dieses kopiert werden soll - wir lassen die FORTH*-Files weg. Zum einen brauchen wir sie nicht, zum anderen steckt im BIOS noch ein Fehler, der das Kopieren abbricht, wenn zu viele Files kopiert werden.

    Mit B: wechseln wir das Laufwerk und sehen mit D nach, ob alles da ist - es sollten 52 kBytes an Files sein. Vorsicht: D lässt uns in der aktuellen Version immer nach A: zurückfallen. Auch das wird noch geändert.

    Nun fällt uns ein, dass wir die CPM-65-Files nicht brauchen - also weg damit mit ERASE b*.* . Aus Sicherheitsgründen fragt ERASE bei jedem File nach, ob wir es tatsächlich löschen wollen. Ach ja, BROWSE.COM möchten wir im Moment behalten.

    Und ja, die meisten Programme haben eine Hilfefunktion eingebaut. Wenn man also nur ERASE eingibt, wir der Kommandozeilenaufruf angezeigt und ERASE tut nichts. Und der guten Ordnung halber löschen wir auch CCP.COM.


    In der Programmsammlung auf B: ist ein Programm namens CPUTYPE.COM. Das gibt aus, ob wir eine 6502 oder eine 65C02 im JC-][ haben. Der Name des Programms sagt uns aber nicht zu - CPUTEST.COM wäre doch viel besser. Nichts leichter als das: RENAME CPUTYPE.COM CPUTEST.COM bewerkstelligt das.


    Erfahrenen CP/M-lern wird nicht entgangen sein, dass die Reihenfolge der Argumente anders herum ist als in CPM-80: erst kommt das File, das zu bearbeiten ist (Source file), dann kommt der neue Filename (Target file). Das ist die Logik von MS-DOS und die gefiel mir immer schon besser.


    Und damit haben wir die zentralen Programme zum Aufräumen im Dateiensalat kennengelernt.


    Viel Spass beim Probieren


    Dietrich

    Es waren doch noch einige Fehler im System:

    BIOS V0.9 - Speicherzellen $FC/$FD müssen im BIOS gepuffert werden, da sie auch von einigen ROM-Routinen benutzt und dabei zerstört werden

    BASIC 1.6 - Das IRQ-Handling des JC-][ verträgt sich nicht mit CPM-65. Daher muß der IRQ dauerhaft abgeschaltet werden. Anm. Ich bin da mit Jörg im Gespräch. Eine Lösung ist angedacht, aber noch nicht umgesetzt.

    SYSINFO - Die ROM-Version wird nun mit Haupt und Nebenversion ebenfalls ausgegeben.


    CPM-65 Release V0.91 liegt auf https://github.com/Dietrich-L/…NIOR_COMPUTER_II/releases und hier im Anhang


    Alle, die die Beispiele in den nächsten Posts nachvollziehen möchten, sind gebeten, die neuen IMG-Files zu benutzen. Bitte überzeugt euch mit SYSINFO, dass ihr auf BIOS V0.9 seid - danke



    Dietrich

    Die 2 Byte Startadresse am Beginn eines ausführbaren Programms haben einen gewissen Charme.

    In CPM-65 gibt es diese nicht. Da wird jedes Programm an den Beginn des User RAM (= TPA) geladen und dort gestartet. Meistens ist das ok. Wenn ein Programm allerdings an einer anderen Stelle laufen soll, wie zum Beispiel der Debugger, der im obersten Speicherbereich läuft, muss sich das Programm dann noch selbst an den Zielort verlagern und die TPA ist dann zerstört. Bei nachladbaren Treibern oä. wäre das ein erhebliches Problem. Das kann man sich mit dem Header und der passenden OS_LOAD Routine sparen.


    Dietrich

    4 GB Karte mit 16 Files und 12 DIRs zugemüllt geht bei mir auch mit allen Optionen für DIR. CLS, ECHO und Pause gehen auch.



    Bei der Gelegenheit ist mir nochmal aufgefallen, dass BOOT.SYS im 1. Directory-Sektor stehen muß, sonst wird die Datei vom Bootloader nicht gefunden. Das ließe sich leicht ändern, zumindest für den 1. Block


    Weiter so Jörg


    Dietrich

    Zitat

    Ich war jetzt natürlich gespannt, ob sich durch diesen einfachen Patch meine kleine Schaar an nicht lesbaren SD-Karten auch zum Arbeiten bewegen lässt.


    Kurz: Leider nein.

    Schade. Meine SDs gehen jetzt alle. Ich habe allerdings auch nur ein kleines Sortiment - 4 GB und 8 GB von 3 Herstellern. Das Problem dürfte darin liegen, dass die SPI-Schnittstelle im Mode 3 betrieben wird. Das liegt hardwaremäßig so fest und läßt sich so ohne weiteres nicht ändern. SD -Karten erwarten aber Mode 0. Die meisten SDs tolerieren Mode 3, leider nicht alle.

    Bei Problemen also mehrere SDs verschiedener Hersteller probieren 😇


    Dietrich

    Tja, das war Ende 84 der erste Büro-PC meiner Frau. Dazu war CP/M mit Wordstar erste Wahl. Und als Drucker gabs eine Brother CE- 60 mit Eigenbau-Centronics Interface. Die konnte Matrizen bedrucken und das war seinerzeit entscheidend für eine Junglehrerin 😍

    Dietrich

    Hallo zusammen.

    Nach einer deutlich längeren Pause, als geplant - es dauert ja immer länger als gedacht - gehts nun endlich weiter. In der Zwischenzeit war ich nicht untätig, sondern habe nun endlich meinen eigenen JC-][ aufgebaut und am Laufen, so dass ich alles auf der Original-Hardware testen kann.


    Und schon gibt es die erste Fehlerkorrektur:

    In BASIC.COM ist noch ein Fehler, der verhindert, dass Programme geladen werden können. Eintippen geht, SAVE auch, aber laden halt noch nicht. Die Fehlersuche läuft noch. Und in DEBUG ist noch ein Bug, der bei den Trace-Befehlen zum Absturz führt. Da ist der Fehler klar und Abhilfe in Arbeit.


    Aber nun zu der spannenden Frage, wie man die im Paket enthaltenen Images in das Filesystem von CPM-65 mountet. Dazu CPM-65 booten und am Prompt SD-UTIL aufrufen. Das sollte dann etwa so aussehen:



    Als erstes wollen wir mal die Befehlsübersicht sehen und geben ein '?' ein


    Nun das ist erstmal ziemlich viel. Das Tool kann ja auch eine Menhge nützliche Dinge mit der SD anstellen. Unter anderem kann man jeden Sektor ansehen und editieren. Da sollte man aber schon genau wissen, was man tut. Sonst ist schnell mal das CPM-65 zerschossen.


    Im nächsten Schritt wollen wir nur mal sehen, welche Images so da sind und geben 'I' ein. Groß- oder Kleinschrift ist übrigends egal.


    Das sieht ja fast aus, wie der BOOT-Screen und das sollte es auch. Wir haben ja immer noch die gleiche SD im Leser - hoffe ich. Zusätzlich zeigt diese Ansicht auch, wo genau die Images auf der SD liegen. Das brauchen wir im Moment aber nicht.


    Nun wollen wir die zusätzlichen Images mounten. Auf A: liegt ja immer das BOOT-Image und das lassen wir im Moment auch so. Auf B: kommt BASIC.IMG, auf C: FORTH.IMG und auf D: BLANK.IMG. Das geben wir nun in einem Rutsch ein, getrennt durch ein ';'



    Und weil wir diese Auswahl künftig immer nach dem Booten aktiv haben wollen, pushen wir sie mit deinem 'P' in den BIOS-Bereich des CPM-65. Dort ist unsere Konfiguration vor allen Programmen geschützt und wird mit dem BIOS geladen. Sie kann natürlich mit SD-UTIL jederzeit geändert werden.


    Das wars erstmal für heute. Wir verlassen SD-UTIL mit 'X' und schauen uns nun die Directories der neu gemounteten Laufwerke erstmal an.


    Bis zum nächsten Mal - Urlaubsbedingt erst Ende des Monats


    Dietrich

    Jetzt ist mir doch etwas aufgefallen: ab und zu verliere ich die Historie der aufgerufenen Images. Bisher konnte ich kein Muster erkennen. Aber es passiert recht häufig, manchmal auch nach nur 3 Aufrufen.


    Dietrich