SD2IEC und CP/M

Ich versuch gerade für den c64 ein Formatierprogramm zu schreiben, welches u.a. Speichererbefehle an die 1541 senden soll. Hab aber im Moment noch nicht die Hardware aufgebaut, um es praktisch zu testen. Hab auch starke Bedenken, ob es mit einer SD-Karten-Lösung laufen wird. In diesem Programm ruf ich 6510 Assembler-Code auf, um die Befehle an die Floppy zu schicken.

Zitat von spiceminer

Geht das überhaupt im CP/M.... also gibt es ein CP/M Programm, mit welchem man einen Kanal zur Floppy öffnen und Kommandos geben kann?

Ich glaube da mal irgendwas in der Richtung gesehen zu haben, mir reichten bislang aber Swaplisten aus.

Zitat

Nachtrag: ein .d71 file kann ich zwar mounten, aber cp/m bricht beim booten ab. Kann das SD2iec überhaupt .d71 images?

Klar kann es D71-Images - aber CP/M erkennt ein sd2iec nur als 1541 und ich vermute, dass CP/M intern irgendwo abbricht wenn man mit einer 1541 auf eine zweiseitig formatierte CP/M-Disk zugriffen will.

Und um der Frage vorzubeugen: Der Aufwand, um CP/M ein sd2iec als 1571 erkennen zu lassen steht in absolut keinem vernünftigen Verhältnis zum Nutzen: Damit es auf den AVR-Lösungen wirklich zuverlässig funktioniert wäre zusätzliche Hardware notwendig.

Zitat von daybyter

Ich versuch gerade für den c64 ein Formatierprogramm zu schreiben, welches u.a. Speichererbefehle an die 1541 senden soll.

Speicherbefehle im Sinne von M-R/M-W/M-E oder im Sinne von B-W/U2?

Zitat

Hab auch starke Bedenken, ob es mit einer SD-Karten-Lösung laufen wird. In diesem Programm ruf ich 6510 Assembler-Code auf, um die Befehle an die Floppy zu schicken.

Ob der C64 die Befehle ans Laufwerk per BASIC oder Assembler sendet ist dem Laufwerk relativ egal. Wenn du allerdings 6510-Assemblercode zum Laufwerk hochlädst und dort ausführen lassen willst geht das natürlich nur mit Laufwerken, die einen 6502/6510 haben bzw. eine komplette Nachbildung davon besitzen. sd2iec ist nur ein Massenspeicher und kein 1541-Emulator, darum wird das damit nicht gehen.

M-W usw.

http://pastebin.com/vAcvVkZq

Ich hab die BIOS-Sourcen jetzt mehrfach vor- und rückwärts gelesen, finde aber für die Boot-Verweigerung von .d71 keine Erklärung. Es läuft ungefähr so ab(*):

- BIOS-Modul CXDISK sendet ein BURST QUERY DISK FORMAT an das Laufwerk.
- Wenn dabei das Burst Acknowledge über SRQ reinkommt: Setze FAST-Flag für dieses Laufwerk.
- Scheitert das Query-Kommando (weil Laufwerk eine 1541 ist) ist es eine CBM-Disk: setzen.
- Liefert das Kommando GCR mit 256 Bytes pro Sektor (weil 1571) ist es eine CBM-Disk: setzen.
- Liefert das Kommando GCR:512 Bytes pro Sektor, muß es eine 1581 sein: 1581-Typ setzen.
- (MFM-Typen näher untersuchen- machen wir in fünf Jahren mal)
und zuzm guten Schluß:

Wenn CBM-Typ, dann Nacharbeit nötig: Bootsektor (1:0) lesen.
- Keine CBM-Kennung? C64-CPM-Typ setzen
- Letztes Byte $FF: C128-doppelseitig setzen
- sonst: C128-einseitig setzen.

Es laufen also Disk-Typ und Laufwerks-Typ völlig unabhängig, und das geht beim Sektor-Lesen und -schreiben genauso weiter: Track und Sektor werden aus dem Disk-Typ und dem angeforderten CP/M-Sektor generiert, die Entscheidung für (normalen) Sektrozugriff über U1/U2 oder (schnellen) BURST-Transfer läuft über das in Schritt 2 gesetzte FAST-Flag. Solange U1/U2 auf die Rückseite einer .d71 zugreifen können (oder sich dort keine Daten befinden) sollte CP/M kein Problem haben darauf zuzugreifen- wenn auch mit geringer Geschwindigkeit.

Im Prinzip klappt das sogar bei einem .d81-Image, nur braucht das a) zwingend die QUERY-DISK-Funktion und b) muß der erste Zugriff auf (1:0) auf Sektor (40:x) umgeleitet werden- ein ziemlich übler Hack mittels Laufwerks-Autostart-Datei. Könnte man mittels Hash über das Direchtory emulieren, ich fände es aber sinnvoller ein 'richtig großes' Containerformat samt BIOS-Unterstützung zu bauen.

(*) Der Boot-Code im ROM erkent nur die beiden C128-CP/M-Typen, macht es aber ansonsten genauso. Die 1581 bootet über den besagten umgeleiteten Bootsektor und einen angepaßten CP/M-Loader (alles auf der Directory-Track versteckt)

Tante EDIT ergänzte Boot-Verhalten und korrigierte User-Befehle zum Block-Lesen/-schreiben.

Das beste Goodie hatte ich eben übersehen:

Zitat von Unseen

Der Aufwand, um CP/M ein sd2iec als 1571 erkennen zu lassen steht in absolut keinem vernünftigen Verhältnis zum Nutzen:

Du hast recht, aber naders als Du denkst... der Aufwand um eine .d71 unter CP/M als solche nutzen zu können ist gleich null, und damit tatsächlich nihct in ein Verhältnis zum Nutzen zu setzen- Division durch Null, und so. Denn, wie gesagt: Es dreht sich um ein einzelnes Byte im Disk-Image. Alles andere ist (eigentlich...) längst vorhanden, wenn ich die SD2IEC-Sourcen auf die Schnelle richtig verstehe.

Der andere Punkt ist die immer noch fehlende Burst-Unterstützung. Der Nutzen wäre unter CP/M durchaus beträchtlich (zumal es da IIRC keine Fastloader für gibt) aber das Problem hat eigentlich nix mit CP/M zu tun.

mc71: CP/M fällt ohne Fast-Detection auf die kernal-Routinen des 8502-Mode zurück, hier hillft ein Jiffy-Dos ROM.

Zitat von mc71

Der andere Punkt ist die immer noch fehlende Burst-Unterstützung. Der Nutzen wäre unter CP/M durchaus beträchtlich (zumal es da IIRC keine Fastloader für gibt) aber das Problem hat eigentlich nix mit CP/M zu tun.

Da grüble ich auch drüber nach, allerdings auf dem c64. Wenn man da ne kleine Routine hätte, die z.B. mehr als 1 Bit auf einmal über den Bus bringt, sollte man das ggf noch einbauen.

Zitat von mc71

Du hast recht, aber naders als Du denkst... der Aufwand um eine .d71 unter CP/M als solche nutzen zu können ist gleich null, und damit tatsächlich nihct in ein Verhältnis zum Nutzen zu setzen- Division durch Null, und so. Denn, wie gesagt: Es dreht sich um ein einzelnes Byte im Disk-Image. Alles andere ist (eigentlich...) längst vorhanden, wenn ich die SD2IEC-Sourcen auf die Schnelle richtig verstehe.

Dann hat deine Analyse wohl etwas anderes ergeben als ich in Erinnerung habe - Bytes aus dem Disk-Image werden natürlich immer 1:1 durchgereicht und Zugriff auf Tracks >35 mit U1/U2 sollten auch problemlos funktionieren (bzw. hat noch niemand einen entsprechenden Bug gemeldet). In dem Fall ist mir gerade unklar, wieso CP/M mit D71-Images nicht funktioniert.

Zitat

Der andere Punkt ist die immer noch fehlende Burst-Unterstützung. Der Nutzen wäre unter CP/M durchaus beträchtlich (zumal es da IIRC keine Fastloader für gibt) aber das Problem hat eigentlich nix mit CP/M zu tun.

Genau die ist es aber, die auf AVR nicht ohne zusätzliche Hardware sauber hinzubekommen ist. Das Fast-Serial-Testbyte wird noch vor ATN geschickt, so lange der AVR aber gelegentlich auch mal Timer-Interrupts abarbeiten muss (weil Benutzer es im allgemeinen mögen, wenn das Fehler-LED-Blinken und die Diskwechsel-Tasten funktionieren) kann der AVR genau in dem Augenblick mit etwas anderem beschäftigt sein und würde dann mindestens ein Bit von dem Byte verpassen.

SD2IEC & CP/M