ZitatOhne DDI-1 disk controller geht mit CP/M ohnehin nichts am 464, m.E. (Gotek schon gar nicht)
Korrekt. Ohne Diskettenlaufwerk macht CP/M allerdings auch keinen Sinn…
Dietrich
ZitatOhne DDI-1 disk controller geht mit CP/M ohnehin nichts am 464, m.E. (Gotek schon gar nicht)
Korrekt. Ohne Diskettenlaufwerk macht CP/M allerdings auch keinen Sinn…
Dietrich
ZitatIst 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
Die Reise ist spannend und noch lange nicht zu Ende 🤩
Dietrich
Bei CPM-65 gibt es keine Kommandos. Man kann nur Programme aufrufen. DIR.COM ist nicht auf der Disk, also kommt die Fehlermeldung.
Die Option zum Diskettentausch ist für Konfigurationen mit nur einem Laufwerk. Mach bitte einen Issue auf - ich denke mir was aus.
Dietrich
Alles anzeigenWas Dir ja evtl. gefallen könnte - wenn jetzt WE ist und hier ja sowieso gerade soviel Drive drin ist - könnte das hier sein
https://github.com/nickgammon/G-Pascal
( "secureklon" https://github.com/cbmeeks/G-Pascal )
dann wären schonmal die Hochsprachen fast komplett.
Das scheint aber auch irgendwie erstmal den Code auf eigene Tokens zu übersetzen und dann damit weiterzumachen, so ähnlich wie evtl dieses P-Code funktioniert haben mag. Und man muß wohl am Anfang ein paar Sachen fix einstellen, passend zur Maschine. Scheint aber soweit komplett zu sein, daß es einen basalen Pascal Befehlssatz komplett abdeckt (Kommandos sind in src/gtoken.inc).
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
Äh ja, aber das liegt an meiner mangelnden Dokumentationen.
Ich habe den DIR Befehl von CP/M nicht implementiert. Stattdessen gibt es D, in der CP/M-Welt auch als SD bekannt. Das gibt ein sortiertes Directory aus.
Die anderen üblichen Commandos sind auch alle als Programm realisiert, also TYPE, ERASE, RENAME uam.
Viel Spaß
Dietrich
Guter Vorschlag
Ich habe das eben gemacht
Dietrich
Und hier noch ein kleiner Appetizer von meinem Testsystem...
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
.. und im Moment läuft gerade der Port auf den Junior Computer ][ 😜
Dietrich
ZitatUnd 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
ZitatMir 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
@Norbert - willkommen an Bord beim CPM-65 für den Junior ][ Projekt
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
ZitatDanach habe ich hoffentlich den Kopf frei, um mal den CPM-65 Port von Dietrich zu testen.
So, ein erstes image 'CPM-65.IMG' und die dazu passende 'BootCPM65_FAT16.bin' liegen auf https://github.com/Dietrich-L für mutige Tester bereit. Lasst bitte den Jörg nicht die ganze Arbeit alleine machen
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
CP/M 2.2 kann schon von B: booten, leider unterstützt das aber das Standard-ROM der CPCs nicht. Normalerweise geht das interne A: ja auch …
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:
interface = shugart
host = unspecified
pin02 = nc
pin34 = rdy
write-protect = no
side-select-glitch-filter = 5
track-change = instant
write-drain = eot
index-suppression = yes
head-settle-ms = 12
motor-delay = ignore
chgrst = step
Alles anzeigen
Damit läufts an meinem CPC464 mit DDI
PS. Natürlich brauchst du korrekte Images
Dietrich
Das ist absolut nicht trivial.
Lest mal hier: https://www.faulhaber.com/de/k…-zum-mikroschrittbetrieb/
Ich würde mich überzeugen, dass es tatsächlich ein Justageproblem ist und dann Justieren - zur Not mit einer bekannt guten Diskette.
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
ZitatDas 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
ZitatDas 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
FAT12 würde ich nicht mehr in Betracht ziehen. Das benutzt niemand mehr. Keep it simple 😉
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
An welches DOS denkst du?
Dietrich
Ja, die Kunst des Mappens beim Apple muss ich noch studieren 😇
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