Beiträge von 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

    Vielleicht liegt es auch an dem Kurzschluss den du mit der Brücke auf dem LED Jumper hast.

    Hab zwar im Netz ein Foto gefunden wo das auch so ist, aber das sieht für mich nicht richtig aus.

    In der Tat - mit dem Jumper hast du den LED-Anschluß kurzgeschlossen. Das könnte den Vorwiderstand kurzgeschlossen haben und dann die Sicherungen. Und dann wäre der Kurzschluss jetzt immer noch da. Also bitte den Jumper ziehen und Vorwiderstand, Sicherungen und anliegende Spannungen nachmessen.


    Und wenn du dir da nicht sicher bist, suche dir bitte jemanden, der dir helfen kann. Es wäre schade um das Board...


    Dietrich

    Die Backblaze-Statistik ist recht gut und sorgfältig analysiert. Danach fallen die Festplatte im Sinne der üblichen Badewannenkurve vor allem mit steigender Leendauer öfter aus (1-2 % pro Jahr im Dauerbetrieb. Für eine Analyse der Zuverlässigkeit bei gleichem Alter aber unterschiedlichem Herstellungsdaten reicht die Datenlage nicht aus.


    Die Analyse von securedatarecovery ist sehr oberflächlich und ohne die konkreten Daten, die zugrunde liegen - also erstmal wertlos. Schade.


    Die meisten von uns, die ihre Platten nicht 24/7 betreiben, dürfen sich auf ein langes Leben moderner Platten freuen.


    Dietrich

    Ja, habe ich --> das macht das Ergebnis schlechter !?


    Mit dieser diskdef

    bekomme ich


    und DUMP.ASM sieht etwas verwurschtelt aus:

    Wenn ich die Sektortabelle aktiviere, sieht schon das Directory furchtbar aus...


    Bin ratlos


    Dietrich

    Das ist der ‚normale‘ China Clone. Funktioniert bei mir perfekt an einer DIY Schnittstelle am Junior Computer.

    Ich würde als erstes mal die Spannungsversorgung nachprüfen.


    Dietrich