Beiträge von haglebu

    Hallo mikemcbike,


    ich einfach nur mal kundtun, dass dein ROM Wizard sehr gut zu gebrauchen ist. Ich beschäftige mich gerade sehr viel mit meinen S-100 Computern und hier mit den 2708 bzw 2704 EPROMs.

    Hallo slabbi ,


    entweder bin ich komplett auf dem Holzweg oder dir ist bei den EPROMs 2704 und MM5204 ein Fehler in deiner Chipdatenbank passiert. Also 2708 und 2704 sind ja bis auf die Größe soweit identisch: 1024 oder 512 Byte. Soweit so gut. In deiner Datenbank wird als Alternative für den 2704 auch der MM5204 ausgegeben.


    Aber, wenn ich mir die Datenblätter anschaue, dann passt da was nicht.




    Meinst du "Borosilikatglas"? Das kenne ich von der 3D-Druckplatte und von Teegläsern/Teekannen... Die sind aber klar.

    Es geht ja darum, das Quarzglas kaum durchlässig für UV-C-Licht ist. Die verwendeten Spezialgläser waren teuer, deswegen gab es viele OTP-EPROMs. Angeblich kann man die mit Röntgenstrahlung löschen

    Ich habe nur den o.g. Hinweis, mehr nicht. Und das Glas ist richtig milchig.

    Bei meinen U555C (2708) EPROMs wird kein durchsichtiges Quarzglas, sondern ein sehr "milchiges" Glas verwendet. Im Forum "Mikrocontroller.net" wird ein kurzer Hinweis auf "Borsilikatglas" gegeben.


    Code
    > Das ist kein Keramikfenster ..., das ist Borsilikatglas. Das Zeug
    > wurde an der Sektion VST der Bergakademie Freiberg entwickelt um sich
    > von Importen unabhängig zu machen. Es gab da auch mal frühe Experimente
    > mit Eprom im schwarzen Plastikgehäuse und eine solchen aufgeklebten
    > Scheibe, hat nicht gehalten, wurde deshalb wohl nie in Serie produziert.
    > Habe leider Keinen mehr aus der Versuchsserie.

    Hat jemand hierzu weitere Informationen oder Unterlagen?


    Hier noch mal die besagten weiteren Informationen von Chuck zum EXM:

    Code
    As I noted, it's pretty unusual to find a block size of 2048 bytes with DSM < 256 and EXM 0, as it leaves half the allocation block fields in the extent unused. That's why I had to make a real disk and check it out. Whether or not it was intended in the original or was simply an error, is anyone's guess. FWIW, EXM is the extent search mask that CP/M BDOS uses to find the "next extent" in a file. It's a negative mask, so that EXM 0 says to look at all bits in the extent field, while EXM 1 says to ignore the low-order bit.
    
    Sometimes, this was done to ensure compatibility with an older CP/M 1.4 program that did its own random I/O and depends on assuming that any on-disk extent is 128 records (16KB). So, when you move to double-sided 8" media, each block number takes 16 bits and you still get the 128 record disk extents.

    Fazit: Es funktioniert :)

    So, mit diesen (minimal veränderten) Parametern funktioniert 22DISK wunderbar. Geändert ist nur EXM=0. Mit dem Ergebnis, das die doppelten Dateien nun auch verschwunden sind (RE: 8" Diskette mit SISYPHUS CP/M 2.2).

    Code
    BEGIN SIS1  Sisyphus - SSDD 8"
    DENSITY MFM,HIGH
    CYLINDERS 77 SIDES 1 SECTORS 48,128
    SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
     25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48
    BSH 4 BLM 15 EXM 0 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
    END

    Und genau diese beiden Datei sind problematisch:



    Die sind wahrscheinlich defekt; das hat Larry Kraemer auch bemerkt.

    Zu meiner Hardware ist noch zu berichten, dass ich unter DOS 6.22 einen AT286 mit der CompatiCard IV und das 8" Mitsubishi M2896-63 verwende. FLUXTEEN verwende ich unter Windows 10 mit dem 8" YD180-1601.


    Das Mitsubishi M2896-63 kann ohne Probleme auch hart-sektorierte Disketten lesen/schreiben.

    Wer sich auch noch sehr gut mit diesem Thema auskennt ist Larry Kraemer (ldkraemer). Hier sind seine Ergebnisse:


    examplemac.txt


    Mein persönliches Fazit:


    Der Weg über FLUXCOPY und die BIN (bzw. IMG) Datei fuktioniert gut. Danach können die Inhalte mit den CPMTOOLS oder SAMCONV extrahiert werden. Ich kann nur sagen, ich bin rundum zufrieden. Vielen Dank an PAW für FLUXCOPY; einfach nur genial :applaus:

    Chapeau!

    PS: PAW tut mir leid, dass ich dich wieder von einer eigentlich Arbeit abgehalten habe ;)

    Merkwürdigerweise tauchen im Inhaltverzeichnis 22DISK/CDIR einige Dateinamen doppelt auf. Ich kann nicht sagen, ob dies anfangs auch der Fall war. Und genau hier hat 22DISK jetzt Probleme wenn ich mit CTOD (herauskopieren) arbeite.

    doppelt sind:

    Code
    A0:STRUZ80.STR
    A0:STRUDEUT.WI

    So sollte es eigentlich aussehen: nur 26 Dateien

    Könntest Du bitte die erste Diskette (die mit EXAMPLES.MAC) nochmal komplett mit SIS1 einlesen und die Dateien hochladen, damit ich sie vergleichen kann

    22DISK: sis1.zip

    Code
    BEGIN SIS1  Sisyphus CP/M 2.2 - SSDD 8"
    DENSITY MFM ,HIGH 
    CYLINDERS 77 SIDES 1 SECTORS 48,128
    SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
     25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48
    BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
    END

    Nachtrag: Würde man auf den Skew beim Lesen nicht Rücksicht nehmen müssen, dann wäre der logische Interleave mit 1, 2, 3, 4, 5, ... zu definieren. Dies wurde aber schon ausprobiert, siehe: RE: 8" Diskette mit SISYPHUS CP/M 2.2

    Ich habe mir den nachfolgenden Track nochmals angeschaut und stimme PAW zu, dass der logische Interleave tatsächlich 1:1 mit 1, 2, 3, 4, 5, ... ist. Anders kann es nicht sein. Während der physikalische Interleave aber 2:1 mit 1, 25, 2, 26, 3, 27, ... ist.


    Somit macht auch die Aussage von Chuck Guzis Sinn: Es gibt den physikalischen (FLUXCOPY, ANADISK, IMD) und den logischen (22DISK) Interleave. Wieder was dazugelernt.

    Diese Reihenfolge entspricht bei mir SIS1 in der Definitionsdatei:


    Code
    BEGIN SIS1  Sisyphus CP/M 2.2 - SSDD 8"
    DENSITY MFM ,HIGH 
    CYLINDERS 77 SIDES 1 SECTORS 48,128
    SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
     25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48
    BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
    END

    Aber auch hier traten manchmal Ungereimtheiten auf. Vielleicht lag es aber auch an der Diskette bzw. Datei. Auf jeden Fall haben die Definitionen SIS2 (Interleave 3:1) und SIS3 (2:1) nahezu unbrauchbare Ergebnisse geliefert. Ich habe hierzu die Datei EXAMPLES.MAC mit allen drei Definitionen kopiert, d.h. ausgelesen.


    Auf jeden Fall funktioniert der Weg über FLUXCOPY und die BIN (bzw. IMG) Datei. Diese kann mit den CPMTOOLS ausgelesen werden; Kryoflux und HxC geht auch. SAMDISK habe ich noch nicht getestet.

    Ja, Chuck hat geantwortet, aber er gibt seine Informationen immer nur tröpfchenweise weiter. Das ist immer recht ermüdent.


    Er unterscheidet bei ANADISK (wie auch bei FLUXCOPY) zwischen dem physikalischen Interleave und dem logischen Interleave bei 22DISK. Mir ist der Unterschied aber nicht klar.


    Ich frage weiter und hoffe auf Antworten.

    Geht eigentlich um die Frage, ob 22DISK grundsätzlich in der Lage ist so ein Format zu handhaben?

    Ja, ich starte gerade eine diesbezügliche Anfrage im VCF. Dort ist auch Chuck Guzis Mitglied; 22DISK ist ja von ihm. Mal abwarten.


    Sisyphus CP/M 2.2 and 22DISK
    On a 8" single-sided floppy disk from Germany "Regionales Rechenzentrum Erlangen, RRZE) I discovered a CP/M called Sisyphus 2.2. The first two tracks are in FM…
    forum.vcfed.org

    Für Track 2 ist das ja richtig. Aber mach mal einen Screenshot von Track 3 oder danach (von einer Originaldiskette)!


    Dort müsste man einen Skew von 2 sehen.

    Hallo PAW, du hast Recht. Ich habe ANADISK mal in einem anderen Modus benutzt und hier werden genau deine Angabe bestätigt.


    Track 2 hat 3:1 aber Track 3 ff hat 2:1.


    Aber auch die SIS2 Definitionen für den Interleave scheinen nicht korrekt zu sein. Sowohl CTOD macht Probleme als auch die kopierten Dateien sind nicht in Ordnung. Die Versuche mit einem Interleave von 1:1 waren zwar auch nicht in Ordnung, aber besser als 3:1. Schade.

    Code
    BEGIN SIS2  Sisyphus CP/M 2.2 - SSDD 8"
    DENSITY MFM ,HIGH 
    CYLINDERS 77 SIDES 1 SECTORS 48,128
    SIDE1 0 1,17,33,2,18,34,3,19,35,4,20,36,5,21,37,6,22,38,7,23,39,8,24,40,
     9,25,41,10,26,42,11,27,43,12,28,44,13,29,45,14,30,46,15,31,47,16,32,48
    BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
    END

    Hier mal mehrere Textdateien 1 bis 10KB im Original und dann jeweils mit SIS1 und SIS2 (CPMDISKS.DEF) auf Diskette kopiert und wieder ausgelesen. SIS1 funktioniert flott und SIS2 mit einem Interleave von 3:1 entsprechend länger.


    Merkwürdigerweise werden jetzt sowohl bei SIS1 und SIS2 die Textdateien korrekt kopiert.


    sis.zip

    Hiermit scheint es (besser?) zu funktionieren. Ich habe die Werte für den Interleave aus IMD übernommen. Auch ANADISK ermittelt einen Interleave von 1:3, siehe Bild


    Code
    BEGIN SIS2  Sisyphus CP/M 2.2 - SSDD 8"
    DENSITY MFM ,HIGH 
    CYLINDERS 77 SIDES 1 SECTORS 48,128
    SIDE1 0 1,17,33,2,18,34,3,19,35,4,20,36,5,21,37,6,22,38,7,23,39,8,24,40,
     9,25,41,10,26,42,11,27,43,12,28,44,13,29,45,14,30,46,15,31,47,16,32,48
    BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
    END


    Ich verwende diese 22DISK Parameter:


    Code
    BEGIN SIS1  Sisyphus CP/M 2.2 - SSDD 8"
    DENSITY MFM ,HIGH 
    CYLINDERS 77 SIDES 1 SECTORS 48,128
    SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
     25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48
    BSH 4 BLM 15 EXM 1 DSM 224 DRM 127 AL0 0C0H AL1 0 OFS 2
    END

    Hallo PAW,


    ich habe mit deiner alten Exceldatei (für Testausgaben) mal eine 10KB Textdatei erstellt. Diese habe ich mit 22DISK auf eine Sisyphus Diskette kopiert. Die Testdatei beinhaltet 160 Textzeilen.


    Ergebnis:


    1) ctype /sis1 a:


    Code
    00001 --- Testtext ---
    ...
    00144 --- Testtext ---
    
    Und das war es; die Zeilen 145 bis 160 fehlen!

    1) ctod /sis1 a:test010.txt test010.sis


    Hier die beiden Dateien:


    TEST010.TXT


    TEST010-SIS.TXT