Robotron Disketten

#303871
Lesenswert?

Hi.

Ich habe ein ziemlich wirres low-level Problem.
Und zwar steht neben mir ein Robotron K8915 mit defekter Bildröhre und
einem Haufen Disketten (5,25"). Nun würde ich diese gerne auslesen.
Aus diesem Zweck hab ich eins der originalen Laufwerke an einen 386
rangeknüppelt und versucht, dieses anzusprechen. Leider ohne Erfolg.
Auch mit low-level (Port-Access)-Routinen für den fdc, der das
Diskettenlaufwerk mit dem Robotron-Hauseigenen Format anspricht (16x256
Bytes, 80 Spuren) kam ich nicht weiter. Was kann man da noch tun ? Zur
Not hätte ich auch noch ein originales "West"-Laufwerk hier, dass mit
dem 386 und DOS-Disketten perfekt funktioniert. Kann es mit diesem evtl.
auch funktionieren ?

Im Internet fand ich einen SCP-Treiber, mit dem dieses Unterfangen
theoretisch möglich sein sollte - nur meldet der mir leider, dass mein
DOS zu neu ist (falls jemand eine DOS 3.xx besitzt wäre mir auch
geholfen ;).

Vielen Dank an jeden, der mir hierbei weiterhelfen kann !

Meine E-Mail Addresse ist (da nach einloggen nicht mehr angezeigt) :
christophwwagner(at)lycos(dot)de
Gast #303872
Lesenswert?

Suche mal nach Supercopy oder 22disk.

Evtl helfen die.

Es gab aber ein CPM Format auf den Robotron Rechnern mit 128
Bytes/Sektor für die Bootspuren. (ich glaube 26*128)
Das kann der  Floppycontroller des PC's nicht, nur die DDR
Version des 8272 kann das zusätzlich zu den restlichen Formaten.
Du brauchst die Spuren aber eigentlich nicht zu lesen,
(es sei denn Du willst den Kram booten) weil die "Datendisk" erst
dahinter anfängt. Du erwischst mich jetzt realtiv kalt, so genau habe
ich den Kram nicht mehr im Kopf.

Alternative: Ich besorge Dir eine B31G1 aus einer SW Kofferglotze,
war damals Alles ein Aufwasch...


Gruß,

Holm
#303874
Lesenswert?

Vielen Dank für die Antwort.

@Holm : was ist denn eine B31G1 ?


Wie war so eine Diskette eigentlich aufgebaut ? Ab welchem Track sollte
man es denn problemlos versuchen können ?

In einem Dokument vom SCDRV stand, dass Robotron-Disketten in einem
"Hauseigenen Format" beschrieben wurden (lt. Angabe 16 Sektoren a 256
Byte) ... Kann man davon eigentlich ausgehen ?

Und könnte man mit dem READ TRACK low-level Befehl eines FDCs nicht
eigentlich auch eine komplette Spur auslesen und so die Daten selbst
runterkaspern ?
(falls jemand zur Verwendung dieses Befehls einige Tips oder sogar ein
Programm hat, wäre das sehr schön).


@Hubert : Na und ? Was macht "Auf" oder "Ab"-wasch für einen
Unterschied ??? Ich kenns auch als "Aufwasch" ... aber egal :
--> Dein Post ist reine Haarspalterei ! <---
Gast #303878
Lesenswert?

@Hubert: na und? Gehe Du am Fenster am Putzen!

@Christoph: eine B31G1 ist eine Bildröhre :-)
Es gab viele unterschiedliche Diskettenformate unter CPM und auch auf
Robotron Rechnern. 16*256 Byte pro Spur war durchaus üblich,
aber eben die Bootsektoren (2 Spuren) eben auch mit 26*128Byte
formatiert. Außerdem gab es noch 5*1024. usw.
Die 16*128 lagen wohl an dem verwendeten Urlader im Eprom oder
aber am kleinsten gemeinsamen Nenner der Floppycontroller, die waren
ja
im 1520 System noch richtig "zu Fuß" aufgebaut, mit Roms und
Schiebregistern etc,  Es gab ja auch 8" Floppies, u.U.
hardsektoriert...
Oh Gott, das waren Zeiten..

Auf der K2526 ZRE gabs die komische aber clevere Mimik mit einer
 2. CPU als DMA Controller...
Sieh mal zu, ob Du aber der 2. Spur 16*256 lesen kannst, der Sektor
Interleave ist dabei erst mal Wurscht, Performance brauchst Du wohl
nicht. Weißt Du, was da für ein OS gelaufen ist?  (SCP, CPA, CPK,
ZDOS?, SIOS, UDOS)

Ob das mit dem Read Track funktioniert, weiß ich nicht, IMHO mußt
Du da vie über die zu erwartenden Daten wissen.. (GAP's,
Synchronfelder etc.)

Gruß,

Holm
Gast #303880
Lesenswert?

Hier brauch ma keiner auf ossis abkacken. Ne kaufhalle bleibt ne
kaufhalle. UND KEIN SUPERMARKT - schließlich sind wir hier nicht in
Amerika. Und wenn mir ein Studierter Lehrer erzählen will (wessi) dass
es Spannungsabfall heisst und nicht Spannungfall dann kann er gerne
seinen abfall messen. Ich tu' meinen abfall in den Mülleimer.

@christoph: hast du es mal mit rawritewin/ rawrite für DOS versucht,
bzw lad dir mal HAL91 das ist ne dikettenlinux-distri und versuch es
mit dd. da hast du wenigstens schonmal die daten als image.

Hast du mittlerweile ein DOS gefunden?
#303888
Lesenswert?

Vielen Dank für alle Antworten !!!

Nach einer weiteren Nacht intensiver Fehlersuche hab ich
herausgefunden, dass 1. das 12V Netzteil zerledert wurde und 2. durch
äußere Einflüsse Kriechströme auf den Platinen (Bildröhre und
Peripheriecontroller, jedoch nicht der CPU) entstanden sind. Diese
Gereinigt und ein altes PC-AT-Netzteil als 12V Ersatz angeschlossen und
der Robotron läuft wieder (Juhuuu !)
(es gehtauch nicht mehr die Lampe aus, wenn ich ihn einschalte ;)

Er meldet sich mit : "55K  SCPX 8915  BIOS-Version 5.1"

--> SCP System.

Mittlerweile verfolge ich zu den Disketten die Strategie, über den
ReadTrack Befehl eines FDCs die Tracks einzulesen, zu analysieren und
später mit gezielter Software ranzugehen (hab auch schon nen
Floppy-Devicetreiber für den Zweck zusammengebastelt). Sektorlesen
funktioniert, nur das mit dem Track lesen will noch nich so ganz ... da
werd ich noch etwas probieren müssen.

Ich werd jetz fleißig eure Tipps probieren und mich melden, wenn sich
was tut ...

Tausend Dank nochmals !
#303891
Lesenswert?

Tausend Dank, Guido !!!

Diese DEF-Datei enthält R780 (PC1715 SCP-Format), mit welchem diese
Disketten endlich lesbar sind.

Das der K8915 auch doppelseitig kann, wusste ich (steht schließlich
grad "nackig" neben mit ;) - er hat 2 vollwertige 250/500 KHz
Laufwerke integriert - mit jeweils 2 Leseköpfen.

Allerdings ist das kopieren der Dateien mit 22DISK noch problematisch.
Gibt man Wildcards an (und somit keinen Datei(!)-Namen, sondern nur ein
Verzeichnis), meldet es zurück, dass es die Datei nicht erstellen konnte
... Gibt es dafür einen Umweg, mit dem er alles auf einmal kopiert ? Und
gibt es eventuell eine Möglichkeit komplette Images für den MYZ80 zu
erstellen ?
#303892
Lesenswert?

HURRAAAAAHH !!!

Es funktioniert ! - mit SCPDRV

Ich hab DOS4.0 in einer verstaubten Schrankwand ausgegraben und war
erst enttäuscht, dass sich SCPDRV immernoch nicht einbinden lies.
Daraufhin fix den Rechner wieder auf Dos7.1 zurückgesetzt.

Dann hab ich mir die SCPDRV.SYS unter die Lupe genommen und
Disassembliert. Dabei auf der Position 0x0AD5 den Sprung zum Fehler bei
der Entscheidungsfindung ob die Version passt oder nicht in NOPs
verwandelt ... seitdem funktionierts !.

Für jeden gleichfalls betroffenen hier nochmals das SCPDRV-Packet :
gehackt.


Nochmals vielen Dank an alle !

Jeder, der auch mal vor dem Problem steht oder stand kann sich nun das
gepatchte SPCDRV-Paket herunterladen. Bei Rückfragen :
christophwwagner@lycos.de
Angehängte Dateien:

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren