Beiträge von Dietrich

    Zitat

    Ist es möglich eine Turbo-Pascal.dsk-File (z.B. 190 KB) über eine entsprechende wav-Umwandlung mit einem AUX-Kasettenadapter direkt von PC in eine RAM-Disk (Vortex SP512, neu mit BOS2.1-EPROM ausgestattet) zu laden und danach zu starten? Wie funktioniert das unter BASIC?

    Nach meiner Erfahrung ist die beste Möglichkeit, Daten und Disk-Images auf den CPC 464 zu übertragen, der Anschluß eines GOTEK mit Flashfloppy als Laufwerk B:


    Dietrich

    Es gibt nichts Gutes außer man tut es….

    Was hindert euch?

    Eurs Software muß nicht perfekt sein und die Doku auch nicht. Man merkt recht schnell, ob man mit seinem Projekt auf Interesse stößt und dann kann sich alles so weiterentwickeln, wie die User das brauchen.


    Nur Mut. Versucht es einfach.


    Dietrich

    Tja, das ganze Paket braucht 32kB. Da wir auf dem JC ][ eine TPA von 43 kB haben, bleiben ca. 11 kB für Programmcode und Daten. Das ist nicht üppig.

    Ich frage mich, ob sich das lohnt.


    Dietrich

    Guter Vorschlag


    Ich habe das eben gemacht



    Dietrich

    Seit Anfang Juli läuft im kleinen Kreis ein Projekt CPM-65 auf den Junior ][ zu portieren. Mittlerweile sind wir im Alpha-Teststadium angekommen, d.h. Code und Tools liegen in einem privaten GITHUB-Repo und wir versuchen derzeit CPM-65 zum Booten zu überreden. Derzeit sind wir zu Dritt. Mutige Tester sind willkommen. Sobald wir das Beta-Stadium erreichen, d.h. ein bootfähiges System vorliegt, das auch von normalen Usern installiert werden kann, were ich das Repo für alle öffentlich schalten - versprochen.


    Eine Beschreibung zu CPM-65 findet ihr hier : CPM-65 für 6502-Systeme


    Und das Originalsystem für meinen stark modifizierten Junior Computer liegt hier: https://github.com/Dietrich-L/CPM-65


    Nur noch etwas Geduld ...


    Dietrich

    Zitat

    Und mit dem CPM-65 von https://github.com/davidgiven/cpm65 hat es anscheinend auch so gar nichts zu tun

    Naja, seitens der Autoren sind beide Entwicklungen völlig unabhängig. Und da wir beide nicht kommerziell sind, ist das mit den Rechten unkritisch. Im Ergebnis haben wir 2 CP/M-ähnliche Betriebssystem, die natv auf dem 6502 laufen. Die dafür geschriebenen Programme lassen sich recht leicht portieren, da die Betriebssystemschnittstelle fast identisch ist.


    Mit Pascal schaun mer mal - das ist ein dickes Brett und es ist kein Zufall, dass Pascal und auch C auf 6502-Systemen nie richtig geflogen sind, mit Ausnahme von UCSD-Pascal auf dem Apple II.


    Dietrich

    Zitat

    Mir ist z.B. nicht klargeworden, ob das FORTH (!) und das BASIC da spezielle eigengeschriebene Sachen sind, oder ob das dann was ist, was "generisch" unter eben CP/M läuft und woanders hergenommen worden ist.

    CPM-65 ist ein CP/M-ähnliches Betriebssysten, das nativ auf 6502-CPUs läuft. CP/M-80 Programme müssen also auf 6502 umgeschrieben werden. Da 8080 und Z80 sehr andere CPUs sind, kann das ein erheblicher Aufwand sein.


    CPM-65 FORTH ist FIG-FORTH mit einer Anpassung an das Disk Operating System CPM-65.


    CPM-65 BASIC ist Microsoft BASIC in der CBM8032-Version mit einer Anpassung an das Disk Operating System CPM-65. EH-BASIC ist da natürlich klar besser.


    Dietrich

    Hallo Norbert,


    Die liegen mit dem Rest des Projektes in einem privaten Repo. Ich werde dich dazu freischalten. Bitte schicke mir dazu deinen GitHub-Namen oder deine email.


    Danke für deine Unterstützung


    Dietrich

    Kurzer Zwischenbericht von der CPM-65-Front:

    BIOS und BOOT-Loader sind fertig und laufen auf meinem Testsystem. BDOS und CCP mussten nur bezüglich der Speicheradressen angepasst werden, ebenso die Programme.

    CPM-65 bootet von einem Disk Image mit 1 MB Größe. 4 Images gleichzeitig sind als Drive A: - D: möglich. A: ist getested

    Im Moment muß ich noch das Problem lösen, wie man dem BOOT-Loader mitteilt, wo der erste Block des zu bootenden Image liegt. Ich kläre das mit Jörg.


    Ich benötige an dieser Stelle eure Unterstützung. Da ich nur einen stark modifizierten Original-Junior besitze und keinen JC-II, kann ich leider nicht auf der Original-Hardware testen. Da wären abenteuerlustige und frustrationsresistente Betatester hilfreich. Die gesamte Software liegt auf einem privaten GitHub-Repo. Wer mittesten möchte, möge sich bitte bei mir melden. Ich schalte euch dann frei, sobalt ein testfähiges Image vorliegt.


    Dietrich

    Prüfe auf jeden Fall nochmal dein Kabel --> https://www.cpcwiki.eu/index.php/DIY:Floppy_Drives

    Der GOTEK muss S1 gejumpert sein

    In der FF.CFG habe ich:

    Damit läufts an meinem CPC464 mit DDI


    PS. Natürlich brauchst du korrekte Images


    Dietrich

    Hallo zusammen,


    ich habe mein CP/M-80 analoges Betriebssystem CPM-65 auf den Apple II portiert. Für Abenteuerlustige, die mal etwas probieren wollen, finden sich bootfähige Diskettenimages hier: https://github.com/Dietrich-L/…Apple-II/tree/main/Images


    CPM-65 ist ein in Bedienung und Programmierschnittstelle an CP/M 2.2 angelehntes Betriebssystem, das nativ auf der 6502 läuft. Benötigt wird wenigstens 1 Diskettenlaufwerk und eine 80-Zeichen-Karte. 48k RAM reichen aus, das aktuelle System kann auch nicht mehr verwalten. An Software ist dabei ein Assembler, BASIC, FIG-FORTH und einige Utilities.


    Die Software incl. Dokumentation liegt unter https://github.com/Dietrich-L/CPM-65-for-Apple-II/tree/main


    Und ja, das ist nicht das einzige CPM-System auf der 6502 und dem Apple. Hinweisen möchte ich auf jeden Fall auch auf David Given's System ( https://github.com/davidgiven/cpm65 ), das auch eine ProDOS-Bootdisk zur Verfügung stellt.


    Über Feedback, Anregungen und natürlich auch Fehlerberichte freue ich mich immer.


    Dietrich

    Zitat
    Das dürfte schwierig werden, wenn man die Images unter Windows, Linux oder MacOS speichert. Die Chance ist zwar bei einem leeren Datenträger groß, dass die Cluster alle aufeinander folgen, aber falls sich z.B. ein defekter Block auf der Platte befindet, kann das schon wieder ganz anders aussehen.

    Ich hoffe, es ist nicht ganz so dramatisch. Moderne Datenträger haben nach aussen hin keine defekten Sektoren mehr, weil sie diese logisch ausblenden. Bei physischen Disketten ist das natürlich ein Thema, aber in meiner durchaus lückenhaften Erinnerung habe ich Disketten mit defekten Sektoren immer entsorgt…


    Dietrich

    Schreibe Einfach mal ein Paar ca. 1 MB große Textdateien *.txt auf eine FAT formatierte SD-Karte . Dann änderst du den Text, ohne die Textlänge zu ändern und schaust, ob sich die FAT dieser dateien ändert. Dazu brauchst du natürlich einen Disk editor oder du machst das mit einem disk image und schaust dir das Ergebnis mit einem Hex-Editor an.

    Wenn die Clustertabellen stabil bleiben, ist alles gut.


    Dietrich

    Zitat

    Das mit den CP/M65 Imagefile in #1481 habe ich wohl nur halb verstanden, aber da sollte man bedenken, daß man niemals wissen kann, was ein PC mit so einer hochgeordneten Reihenfolge macht

    ThoralfAsmussen Du könntest uns sehr helfen, indem du diese Frage mal mit einigen Experimenten klärst - Deal?


    Dietrich

    Das ist ja super. Wenn wir BOOT.SYS im Directory gefunden haben, haben wir die Nummer des 1. Clusters von Boot.sys. Das ist bei einer Clustergröße von 4k ausreichend für fast alles…


    Wer sich für die Structur von FAT32 interessiert - ich habe meine Weisheit von https://www.pjrc.com/tech/8051/ide/fat32.html


    Die Idee wäre dann folgende:

    Man könnte im FAT-System Disk Images ablegen und diese mit einem kleinen Programm außerhalb von CPM-65 selektieren - auch mehrere auf einmal als Drive A:, B:, C: usw. CPM/65 würde dann jedes Image als disc sehen und wir brauchen nur Code um in dem jeweiligen Image den gewünschten Sector zu lesen oder zu schreiben. Sollte einfach sein, da CPM-65 intern mit 24-Bit-Sectornummern arbeitet. Im ROM brauchen wir dann nur Code, der absolute Sectoren auf der SD lesen und schreiben kann und im RAM brauchen wir eine Tabelle des jeweils ersten Sectors jeder gemounteten Disc. Wenn wir dann noch dafür sorgen, dass alle Images in lückenlos aufeinander folgenden Sectoren liegen, haben wir gewonnen. Maximale Größe der Images wäre 8 MB - ist eigentlich zu groß. Um die Software einfach zu halten, würde ich eine einheitliche Größe vorschlagen, z.B. 1 MB. Das ist noch übersichtlich.


    Die Images kann man dann mit CIFE von HobbyProgrammer (Uwe Merker) füllen.



    Dietrich

    Im Prinzip funktioniert das. Dummerweise legt das Apple-ROM die Register in der Zeropage ab, was natürlich Probleme macht, wenn da andere Daten liegen...

    Gibt es da eine Lösung. Am liebsten hätte ich einen klassischen BRK-Einsprung mit allen Registern im Naturzustand.


    Dietrich

    Vielen Dank für den Hinweis. Im Moment benutzt ich AppleWin mit Apple IIe-Emulation. Da scheint der Vektor auf $3F0 zu liegen. Kann es sein, dass sich das von Modell zu Modell unterscheidet?


    Gruß


    Dietrich