Posts by PAW

    Für mich sehen die entstandenen Dateien ziemlich unterschiedlich aus. Aber Du kennst Dein Format sicherlich besser. Kannst ja mal sehen, ob Du was damit anfangen kannst.

    Es handelt sich um eine MS-DOS Diskette, zweiseitig, 80 Track, afaik 512 Byte pro Sektor, GCR kodiert.

    Georg habe Dir eine PN geschickt.


    Habe die Dateien kurz angesehen. Sehen nicht sehr eindeutig aus.


    Aufgrund der varablen Drehzahlen müssen für acht verschiedene Zonen die Standard-Fluxwechselintervalle ermittelt und für Vorder- und Rückseite getrennt angewendet werden. Noch dazu muss die Drehzahl des Laufwerkes bei der Fluxaufzeichung berücksichtigt werden. Weiters muss die GCR-Codierung entschlüsselt werden, sowie Track- und Sektoraufbau, als auch CRC und Write Precompensation, falls nötig.


    Wird wohl länger dauern, um die Daten Dumpen zu können.



    Grüße


    PAW

    Quote from Georg

    PAW: Der erste Versuch mit Fluxcopy hat nicht funktioniert, die Kopien waren nicht lesbar. Aber auch das möchte ich noch mal gegenprüfen - dann bekommst Du auch das Image.

    @Georg das war zu erwarten. Hat vermutlich eine andere Struktur als C64. Bitte schick mir einfach die Images und eventuell einen Tipp, was darauf gespeichert ist. Ich schaue es mir dann an.

    @Georg Danke!


    Habe inzwischen ein paar Informationen zu den Disketten gefunden.


    Die Disketten des Victor Vicki sollen mit dem Victor 9000 kompatibel sein.


    Sirius 1 / Victor 9000 Specification


    Single side floppy 5¼ (130mm) Max capacity: 620kb per side

    Double side floppy Max capacity 1.2M byte

    Single side floppy 80 tracks at 96 TPI (620544Kb)

    Double side floppy 160 tracks at 96 TPI (1216512Kb)

    Floppy's have 512 byte sectors: Using a GCR, 10-bit recording technique


    Damit sollte einem Einlesen nichts im Wege stehen.


    Soweit ich das verstanden habe, werden dazu normale DD Disketten verwendet und nicht HD wie bei PC-AT. Dennoch haben sie ein ähnlich hohes Speichervermögen!


    Grüße


    PAW

    Quote from funkenzupfer

    Wenn ich das bisher richtig gesehen/verstanden habe, nimmt das FluxCopy nur die Zeit zwischen den Flux-wechseln auf.

    Wenn jetzt die zeitliche Auflösung klein (also die Abtastung hoch) genug ist, könnte das doch funktionieren.

    Oder hab ich einen Denkfehler?

    Die Auflösung reicht in jedem Fall bis zu HD-Formaten (25MHz = 40nsec).



    Quote from x1541

    Wenn man das auf einem anderen Laufwerk kopieren will, muss dann aber nicht nur die Bitrate stimmen und die Codierung übernommen werden, was beim fluxen aber kein Problem ist. Man braucht auch die richtige Spurlage bzw. Spurdichte. Ob das jetzt 96tpi (Standard) oder auch 100tpi (wie bei Commodore) ist, kann ich nicht sagen.

    Die Bitrate sollte beim Fluxen tatsächlich kein Problem darstellen, wohl aber die Write Precompensation. Bei FM Formatierung gibt es kaum Probleme, aber bei anderen Kodierungen wie z.B. MFM, MMFM, etc.


    Spurdichte 100tpi wären dabei vermutlich ein unüberwindbares Problem, außer man verfügt über ein 100tpi Laufwerk mit Shugart Anschluss.


    Eine weitere Frage ist noch, ob das Indexloch für die Formatierung berücksichtigt wird oder ob es, wie beim C64, ignoriert wird. Wird das Indexloch ignoriert, dann ist eine genauere Analyse der Daten erforderlich, damit der richtige Startpunkt für das Schreiben per FLUXCOPY ermittelt werden kann. Wird an der falschen Stelle mit dem Schreiben begonnen/aufgehört, dann werden die Daten an dieser Stelle zerstört. Der Aufsetzpunkt muss also sich immer innerhalb eines Gaps befinden und nicht in den Daten.



    @Georg falls Du ein Image mit FLUXCOPY machst, bitte eine Kopie Zwecks Analyse an mich. Danke!


    Grüße


    PAW

    Hallo @as58


    weißt Du wo ich ein Kryoflux-Image (je eine Datei pro Track) einer APPLE II Diskette runterladen kann? Würde mir das Format gerne näher ansehen. Andere Images kann ich nicht lesen (ausgenommen Fluxcopy-Images).


    Gruß, PAW

    Zu Commodore kann ich nichts sagen. Wer ganz genau wissen will wie es beim Apple Disk II Laufwerk am originalen Controller funktioniert, finden eine aufs Bit genaue Beschreibung in Don Worth / Pieter Lechner "Beneath Apple DOS". Das findet man als PDF zum Download.

    In dem PDF-Dokument wird aber statt GCR eine FM-Codierung beschrieben. Scheint also nicht "bitgenau" zu sein.

    Quote from 1ST1

    Die 5,25er Laufwerke schalten darüber dann den Schreibstrom und die Umdrehungsgeschwindigkeit zwischen 300 und 36ß rpm um. Zu allem Überfluss melden wieder andere Laufwerke über Pin 2 den Diskchange... Das ist total vermurkst!

    Welche 5,25" Laufwerke schalten die Drehzahl mittels Pin 2 um?


    Ich dachte, das regelt der Controller, indem er die Schreibgeschwindigkeit anpasst.

    Quote from slabbi

    Ich habe als Brenner nur den TL866A und TL866 Pro II.

    den TL benutze ich aber zum EPROM brennen recht selten und wenn, dann kommt bei 25V ein Adapter zum Einsatz.

    Gibt es den 25V Adapter fertig zu kaufen oder ist es ein Eigenbau?

    Quote from klaly

    Also, der Prommer TL866II Plus ist ganz nett, aber für alte EPROMs wohl eher ungeeignet.

    Ich hatte auch einen TL866A bei Amazon bestellt, aber einen TL866 II plus erhalten. Wie schon erwähnt kann der TL 866 II nur 18 Volt, statt 21 Volt.


    Zum Glück habe ich noch einen uralten Eprommer für 2716, etc. mit 21 und 25 Volt. Der Z80-Teil ist selbst gebaut, verwendet aber eine Eprommer-Platine von Siemens, welche selbst die benötigten Spannungen aus 5 Volt generiert.


    Habe mich aber dennoch umgesehen und folgende Möglichkeit für den TL 866 gefunden:


    Adapter für höhere Programmierspannungen am Universalprogrammer TL866


    Dort gibt es eine Anleitung zum Bau eines Adapters für den TL866 bzw. TL866 II um auch höhere Programmierspannnungen verwenden zu können. Diese höhere Programmierspannung muss dem Adapter von extern zugeführt werden (z.B.: mittels Labornetzteil 21 V, 25 Volt, ...)



    Der Hersteller vom Eprommer TL866 warnt allerdings vor solchen Adaptern, da bei defekten EPROMs die erhöhte Programmierspannung auf den Eprommer zurückschlagen und diesen zerstören könnte. Dieses Risiko muß halt jeder für sich selbst abwägen.


    Ich persönlich würde dieses Risiko eingehen, falls ich nicht mehr auf mein altes Gerät zurückgreifen kann.


    Gruß, PAW

    Hi Jaume,

    Quote from jlopez

    A few days ago I started to desolder the P3's CPU board

    did I understood well, that you put off all components of the PCB to get an empty board? Then you want to draw a circuit diagram of the board?


    In the 1990s a colleague and I did a similar job, but we did not destroy the original Z80-interface-board. He checked the circuits on the board with an ohm-meter. So we got a big chart with all connections of the components. I disassembled the EPROM. So we could redesign a new board with similar functions.


    If you have really an empty board (hopefully it is only double sided and not a multi layer), you can scan it with a flat bed scanner on both sides. Then you can try to colorize the sides in different colours and make them semi transparent. Then you can overlay them to get a good overview.


    I think it will be a lot of work, but you will get a good documentation for your system.


    I wish you good luck!


    Kind regards

    PAW

    Habe mal schnell meinen HP45 ausgegraben. Stammt aus den 70ern (1973-1976), ist also rund 45 Jahre alt und funktioniert immer noch! Nur die Akkus habe ich entfernt und betreibe ihn mit einem Netzteil.


    Das Beispiel mit Sinus von 23,4° bewältigt er in rund einer Sekunde.



    Auch die Genauigkeit ist hervorragend. Ein Vergleich mit dem Windowsrechner zeigt völlige Übereinstimmung, auf die Anzahl angezeigter Kommastellen.



    Grüße, PAW

    Bei den Preisen muss man allerdings bedenken, dass z.B. einer der ersten HP Taschenrechner HP35 (mit LEDs) im Jahr 1972 ca. 1500,- Euro für unsere Schule gekostet hat. Habe dann 2 Jahre später selber einen um ca. 350,- Euro gekauft (und später wieder verkauft).


    War schon ein gutes Gerät, vor allem was die Qualität der Tasten betraf. Man musste nicht auf's Display schauen, ob die Zahlen tatsächlich eingegeben waren. Das spürte man an der taktilen Rückmeldung im Finger.

    Die Nutzung der polnischen Notation während meine Schulzeit fand ich dann schon sehr schwierig. Ich kam nie damit zu recht und habe den eigentlichen nutzen nie verstanden.

    Die UPN (umgekehrte polnische Notation) bei HP-Taschenrechnern ist schon super, wenn man sich damit angefreundet hat. Sie spart Tastendrücke und damit Zeit bei der Eingabe. Allerdings muss man mehr mitdenken und die Vorrangregeln zwischen Punkt- und Strichrechnung beachten.


    https://de.wikipedia.org/wiki/Umgekehrte_polnische_Notation


    Grüße, PAW

    Hallo,


    habe hier eine Zusatzinfo. Hilft vielleicht beim Zusammenstellen der Dateien.


    Ich habe obige Disk Images mit dem Tool SAMdisk auf Disketten geschrieben und anschließend mit dem Tool 22DISK wieder auf den PC eingelesen. Ich konnte z.B. die ZORK1 Dateien mit dem 22NICE CP/M-Emulator erfolgreich starten. Das hier verwendete Format DSK ist dem von SAMdisk verwendeten sehr ähnlich und SAMdisk hat damit keine Probleme.


    MIt Hilfe von overCLK konnte ich eine Definition für 22DISK erstellen:


    BEGIN P2DS  Alphatronic P2 GOTEK 16x256 DSDD 40 Track

    DENSITY MFM ,LOW

    CYLINDERS 40

    SIDES 2

    SECTORS 16,256

    SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16

    SIDE2 1 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16

    ORDER EAGLE

    BSH 4 BLM 15 EXM 0 DSM 155 DRM 127 AL0 0C0H AL1 0 OFS 2

    END


    Seltsam war allerdings, dass der Parameter EXM = 0 der Literatur zu CP/M widerspricht. Sollte bei einer Blocksize von 2048 eigentlich 1 sein (DSM < 256), funktioniert aber bei 22DISK nur mit 0 richtig. Bei EXM = 1 geht 22DISK beim Kopieren der Dateien in eine Endlosschleife. Habe keine Erklärung dafür.


    Grüße, PAW