Beiträge von robert_99

Hast du eventuell Jumper Settings?

-robert

Ich fange Mal an zu zeichnen.

Hast Du die Rückseite auch fotografiert?

Danke, ich werde Mal vor dem Wochenende kurz schubsen 😀

Habe endlich etwas gefunden:

Thread über 8-bit SCSI Karten bei VCFED

speziell mit Verweisen auf ein Github Repo von Oleg Mishin:

Github Link

Eine zweite Version wäre jedoch wünschenswert.

Möglicherweise hat Toast_r seine NCL-501 Karte noch und kann ein Foto von unten machen.

In diesem Thread: KLICK aus diesem Forum gibt es einiges an Info.

--robert

Danke für den Hinweis. Derzeit bin ich an der Funktion interessiert. Das unterschiedliche Pinout kann man dann beim PCB berücksichtigen. Funktionskompatibel sollten sie ja sein.

Ich kann den Schaltplan aus einem Foto abzeichnen wenn ich ein gutes Foto von Vorder- und Rückseite hätte. Eventuell ist das überprüfen der einen oder anderen Leiterbahn notwendig.

Die BIOS Sourcen habe ich gefunden. Ich benötige jedoch den Schaltplan für die Implementierung dazu.

-robert

Neu kaufen kann man die nicht mehr. Möglicherweise NOS. Ich habe aber ein paar alte Scanner SCSI Karten gekauft mit diesen Chips um 5-15.-, daher mein Wunsch eine eigene Karte zu machen. Sind jedoch 16-bit Karten ohne BIOS, daher meine Frage nach BIOS.

Geschwindigkeit ist eher zweitrangig da diese Karten für einen IBM XT (oder kompatible) sind

-robert

5380 oder 53C80.

Den mit dem 53c400 hab ich ja

Hallo, ich wieder mal.

Habe meinen Rancho RT1000 8-Bit ISA SCSI Controller mit Blue SCSI zum laufen gebracht und den Floppy Controller Teil dazu gebaut.

Vorher:

Nachher:

Die GAL Gleichungen habe ich mir aus verschiedenen Quellen "ausgedacht".

Schaltplan habe ich gezeichnet (siehe pdf)

Nun würde ich gerne einen solchen SCSI Controller mit einem 5380 aufbauen und dafür benötige ich:

• Fotos von vorne und hinten in hoher Auflösung und scharf,
• das BIOS des Adapters und
• die Gleichungen vom GAL
• ev. Hilfe beim durchmessen der fehlenden Verbindungen.

Ich kann den Schaltplan zeichnen und ev. das Board routen.

Was den GAL betrifft (wenn einer auf der Platine vorhanden ist) wäre ein dump mit dem Retro chip Tester optimal, weil auslesen wahrscheinlich nicht funktionieren wird.

Bei einem einfachen Addressdekoder kann man sich wahrscheinlich die Gleichungen ausdenken.

Hat jemand etwas?

-robert

Hallo allerseits, ich habe ein python-script gebastelt welches mir Imagefiles von Floppy und Harddisk erstellt. Es kann ebenso die Files aus dem Image extrahieren.

Gibt es zwar schon in der einen oder anderen Art, ich habe jedoch nichts passendendes gefunden. Außerdem steckt einiges an Info drinnen wie die einzelnen Faktoren im BPB und im VBR (= Volume Bootrecord) zusammenhängen. Kann ganz nützlich sein.

Die Images sind startbar und haben folgende Eigenschaften:

• Floppy Image Erzeugung von 360k, 720k, 1200, 1440k und 2880k (FAT12)
• Harddisk Image Erzeugung von: 3MB-504MB (FAT12 und FAT16) mit einer partition
• Betriebssystem: MSDOS2,3,5,6, DRDOS3,5,6,7,8, FreeDOS, Win95, Win98
• Extrahieren aus Harddiskimage, Floppy Image und CD-Image
• Script läuft unter linux und verwendet 7-zip und mtools und zum testen QEMU.

Da es Python ist, kann es leicht erweitert werden. Die Bootsectoren sind im Script gespeichert, die daten müssen bereitgestellt werden.

Das script sucht in einem Unterverzeichnis dimp_files nach ordnern mit den jeweiligen Daten. Die Ordner müssen den selben Namen haben wie das Betriebssystem (MSDOS3 oder WIN95 z.Bsp.).

Das erstellen eines 504MB Images dauert etwa 2s inkl start von QEMU.

Beschränkungen:

• MSDOS2 kennt keine Festplatten und keine HD floppies,
• DRDOS3 hat einen anderen BPB (= Boot Parameter Block) und ich habe keine Infos für größere Floppies (>720k) und Festplatten.

Falls jemand Infos zum Aufbau des BPB unter DRDOS3 hat bitte melden.

*DAUMENDRÜCK*

Status Update:

Leider ist die Sachlage derzeit so dass Holger nach einer Ausstellung seinen Adapter nicht findet und Ralph momentan nicht an seinen Adapter rankommt.

Ich habe keine Idee wie lange es dauern kann bis die Daten zur Verfügung gestellt werden können. Ich habe derzeit Kapazität dieses Projekt zu starten, wie es in der Zukunft aussieht ist fraglich.

lg. robert

Ich würde das selber machen. Ich mache das mehr oder weniger dauernd. Ein Bild von der Platine wäre allerdings (oben und unten) hilfreich um Fehler im Schaltplan auszumerzen.

Immerhin ist ja Interesse von zwei Personen vorhanden, also hoffen wir mal....

-robert

Ich habe Kontakt mit Holger und Ralph_Ffm aufgenommen. Sobald einer von ihnen dazu kommt gibt es mehr. Ich kann dann hoffentlich auch den Schaltplan fertig stellen und korrigieren.

-robert

Hallo, um den Thread nicht sterben zu lassen wollte ich will einmal nachfragen wer sich denn dazu motivieren kann die EPROMs hochzuladen und ein Foto der Platine zu machen.

Ist ja auch im eigenen Interesse wenn die Daten verfügbar sind. 😉

Ich habe einmal mit dem Schaltplan begonnen. Leider ist die Qualität zu schlecht um einen Nachbau zu starten. Ich würde ein besseres Foto von der Platine benötigen (von oben UND unten!) und wie gesagt die Firmware.

Hier einmal das Bild der Platine mit den Referenzen:

und hier der Schaltplan:

EVA.pdf

Danke für die Vorschläge, die kenne ich jedoch alle schon. Auch mit der pc-lösung habe ich schon Erfahrungen sammeln können.

Auch moderne Varianten mit ATmega oder Raspberry Pi sind zu begrüßen. Ich bin an der alten Firmware interessiert, da diese auf einem 6803 läuft.

Kann Holger eventuell die beiden Eproms dumpen?

-robert

Hallo allerseits,

ich wollte meinem HX-20 und meinem PX-4 einmal eine Bildschirmausgabe spendiern.

Gibt es eigentlich einen Dump der Firmware von z. Bsp. dem EVA von KK Sytems?

Da hab ich einen Schaltplan gefunden und die ICs sind alle in meinem Bestand vorhanden.

Falls ja, kann ich einmal anfangen den Schaltplan nach zu zeichnen.

Falls nein, gibt es möglicherweise eine andere Lösung (mit firmware)?

lg. Robert

Hier mal die kicad exportierten gerber daten... IDE-Adapter-Gerbers.zip

Grüsse, Robert.

Ich habe jetzt folgenden Ansatz gewählt:

Für CP/M mit einem Software Versatz (nennen wir es einmal skew) habe ich ein script geschrieben dass mir den skew herausrechnet (ab einer Adresse) und ein neues File produziert in dem man dann das Template laufen lassen kann.

Das script heisst: UnSkew_Image.1sc und ist ab sofort im Repository zu bekommen.

Zwei weitere scripte welche Daten aus Imagedisk und Samdisk files extrahieren gibt es auch (Imagedisk_Export.1sc und Samdisk_Export.1sc).

Auf den extrahierten files kann man dann wieder das Template (RetroDrive.bt) laufen lassen.

Für alles andere kann man das Template direkt ausführen und die variante auswählen (wenn implementiert).

Das Template versteht sich als Gerüst rel. einfach weitere Filestrukturen zu implementieren.

Derzeit ist folgendes implementiert:

FLEX1 und FLEX2: fixe Rootdir Einträge mit Größe != Sector und verkettete Datenblöcke,

es65: fixe Rootdir Einträge, Datenblöcke sind in einer map zu finden,

CP/M: fixe Rootdir Einträge, Datenblöcke sind in einer tabelle im Eintrag zu finden,

FDOS: fixe Rootdir Einträge, Datenblöcke sind ab einem Startsektor einfach hintereinander,

CP68: fixe Rootdir Einträge, Datenblöcke sind ab einem Startsektor einfach hintereinander,

DOS68: verkettete Rootdir Einträge und verkettete Datenblöcke.

Das sollte eine rel. große Anzahl an Filesystemen bereits abdecken. Alles weitere ist nur Parameter ändern und Codeblöcke kopieren.

Ich bin sehr interessiert an "schrägen" Filesystemen. Falls jemand etwas kennt bitte posten.

Danke.

Ich habe jetzt einen anderen Ansatz gewählt. Ich habe ein Skript (ebenfalls für 010 editor) geschrieben das mir den Skew ab einer bestimmten Adresse herausrechnet und das file neu abspeichert. Jetzt passt es auch mit dem directory. Bei der Gelegenheit habe ich auch gleich Byte negieren implementiert.

Das mit Trackabhängigem Skew könnte ich mir ansehen wenn ich mehr Beispieldateien hätte.

Kannst Du mir etwas zur Verfügung stellen?

Mehr Beispielimages mit skew wären auch super, eventuell auch Images mit unterschiedlicher Füllreihenfolge.

Hier mein bisheriger Fortschritt:

lg. robert

Ok. Danke für diesen Hinweis. Das erklärt einiges. Dann sollte es logischerwieis auch im Bottsector sein?

Ich habe einmal den Skew in der Fileansicht implementiert. Am Beispiel READ.ME1 kann man die Anfänge der Sektoren sehen:

Das deckt sich jetzt mit der tatsächlichen Datei. Wie ich das im Directory mache ist mir noch nicht klar.

Lg. Robert

Ich habe die Disketten mit einem Single Board Computer in einem selbstgemachten Gehäuse bekommen. oettle & reichler hab ich auch rausgefunden, die Type ist mir neu.

Im IMD file ist das directory eindeutig sortiert:

kann es sein das SAMCONV die Datei verschachtelt?

Ich habe dieses image selbst direkt von floppy erstellt.

lg. Robert

Zitat von PAW

Das Betriebssystem UCSD verwendet auch einen Sektorversatz. Siehe Philips und Altos. Diese wurden in SAMCONV aber fix im Programm verdrahtet und sind hier nicht parametrisierbar. Der Versatz ist außerdem trackabhängig, d.h. ist auf jedem Track anders (bis sich die Reihenfolge wiederholt)

Zitat von PAW

Es gibt noch die Möglichkeit, dass die Daten INVERS sind, d.h. Nullen und Einsen auf Binärebene vertauscht. Siehe Spalte mit "Data Mode" im EXCEL = "INV"

Danke, das sind beides sehr gute Hinweise.

Bezüglich Directory: Ich habe mit IMD einige CP/M Disketten gerippt und da sind die Directory Einträge alle in Folge, die Datenblöcke jedoch nicht.

Beispiel: 003.zip

Hier die erste Datei mit Skew: read..me1.txt

Nachdem ich mich noch weiter in die Materie eingearbeitet habe kann ich noch etwas hinzufügen bzw. erfragen:

• Nachdem ich ein Template für einen HEX Editor schreibe ist es irrelevant wie die Daten auf der Diskette gespeichert werden. Einzig wie die Daten NACH dem lesen interpretiert werden ist relevant. Ob das jetzt skew oder interleave genannt wird ist mir nicht klar.

Es ist also der Unterschied zwischen der Reihenfolge der Datenblöcke im Disk Image und im Binary wichtig. Ich bin mir nicht sicher wie imageprogramme (Imagedisk, 22Disk, Anadisk,...) das handhaben, aber bei IMD gibt es eine Sektormap die angibt in welcher reihenfolge diese ausgelesen werden.

Bei den von mir erzeugten images sind die Blöcke verschachtelt (weil skew oder interleave = 3), die sektormap zeigt jedoch 1,2,3,4,5....

• Sektoren werden von einigen alten Systemen NICHT nach der Reihe gelesen, trotzdem sind diese in allen Images die ich mir angesehen habe der Reihe nach. Möglicherweise ist das ein Unterscheidungsmerkmal zwischen Interleave und Skew.

Den von mir angesprochenen Versatz gibt es NUR bei CP/M, ich habe ihn noch nirgendwo anders gesehen. Falls wer ein Beispiel hat wo das doch so ist bitte sagen.

• Directories und ev. auch der Bootsector haben KEINEN Versatz im Image. Wer gegenteiliges gesehen hat, bitte melden

• CP/M hat für meinen Anwendungsfall "nur" einige Schrauben an denen man drehen kann (C, H, S, Byte/Sec, Bootsektor, Directory Entries, Blocksize, Allocation Table 8 oder 16bit und eben Skew). Alles andere ist irrelevant für das lesen bzw extrahieren der Daten. Auch hier sind gegenteilige Beispiele willkommen.

Ich habe mir das Excel Sheet Samconv angesehen (funktioniert übrigens auch mit LibreOffice unter Linux) und hab auch ein eigenes Spreadsheet mit über 100 CP/M Formaten aus: (Chaos mit System - Disketten Formate unter CP/M (c‘t 1985, Heft 6)).

lg. Robert

Danke einmal für die Antworten. Da ist ja eine Menge an hilfreichem Material bzw. Informationen.

Auch die Erklärung mit Interleave vs. Skew ist hilfreich.

Mein skript funktioniert schonmal für "einfache" Images. Falls jemand mal ausprobieren möchte oder Images von schrägen Systemen hat dann immer her damit ich kann einmal reinschauen und versuchen es zu implementieren. Eine Beschreibung des Formates wäre allerdings wünschenswert (Link oder pdf Dokus sollten reichen).

lg.

robert

Danke für den Tip. Ist leider nicht das was ich brauche. Da ich gerade am implementieren des skew bin wäre das vorrangig. Normale images ohne skew gehen ja schon gut.

LG. Robert

Hallo allerseits,

ich bin gerade dabei ein Binary Template für 010 Editor zu programmieren.

Diese soll diverse "alte" Diskettenformate erkennen und interpretieren können.

Derzeit funktionieren: FLEX1, FLEX2 (SD und DD), FDOS, CP68, es65 und zum Großteil auch CP/M. Ich möchte die Darstellung jedoch verbessern und alle Sektoren die im Binary aufeinanderfolgen auch hintereinander darstellen.

Hier einmal ein Screenshot:

Hier die Software: 010 Editor

Ich finde diesen Editor (kann sowohl HEX als auch Text) sehr hilfreich und habe auch schon andere Binary Templates geschrieben.

Ich benötige speziell angefertigte Floppy Images in einem Format mit einem Skew > 1 mit den Records (128 Byte) gefüllt mit EINER 16 bit Zahl die pro Record um 1 inkrementiert wird. Der Sinn ist das ich somit aufeinanderfolgende Records (und auch Sektoren) leicht identifizieren kann.

Osborne SD hat z.B. skew = 2, es gehen aber auch andere unbekannte Formate.

Ich habe zu wenig Erfahrung mit den inneren Vorgängen in CP/M um Images verlässlich erstellen zu können.

Im Prinzip sollte eines mit skew = 2 und eines mit skew = 3 reichen. Es ist jedoch besser unterschiedliche zu haben weil bei einem Track oder Head change der skew nicht angewendet wird.

Ich hoffe jemand kann mir helfen oder auch Images mit Textdateien UND die extrahierten Files (zum Vergleich) zur Verfügung stellen.

Ich arbeite unter Linux und kenne cpmtools, es ist jedoch schwierig den Zusammenhang von Binärdateien zu prüfen.

Danke.

lg. robert