Beiträge von schufti

also Poti würde mich schon sehr wundern, eher Drehgeber.

Ja, diese Teile machen mit der Zeit Ärger, wenn die Schaltung und/oder Software nicht ordentlich designed wurde.

Etwas Kontaktspray wird wohl vorübergehend das Problem lösen können, längerfristig ist wohl eine Adaption der Schaltung die beste (einzige) Lösung. Selbst ein Ersatz - wenn mechanisch überhaupt möglich - ist bei mangelhaftem HW/SW Design wohl keine langfristige Abhilfe.

aber: die 5V für den Digitalteil kommen ja nicht vom 5V Regler am Board, der ist doch nur für den Video- (und Sound?) Teil, oder?
Schon mal geschaut ob das NT überhaupt 5V liefert? Und der Schalter auch ok ist?

p.s.: halte auch Ausschau nach MOS 74ern, die sind auch sehr übel ...

nein, in (Micro)python ist da nix. Alles gutes C/C++ (wenn auch tw in .ino verpackt).

Hi,

spricht eigentlich etwas dagegen so ein Chinamodul zu verwenden?

Platz genug ist under der orig. Platine allemal.

Zu beachten wäre ebenfalls, dass der orig. Elko mit 16V grenzwertig ist, zumindest im Leerlauf (also besser durch 25V Type ersetzen).

Das gilt auch für die Elkos im entsprechenden Bereich des C64, besonders wenn man den Schottky und Recom Umbau aus dem C64-Boardkompendium macht.

der vorsichtigste Umgang mit den ICs nützt aber nichts, wenn man sie dann verkehr rum in den Sockel zurück steckt ... siehe KickROM im zweiten Link des TOs

such mal nach microsoft basic, das war damals der Standard auf (fast) allen (Z80) Systemen.

sollte das nicht eigentlich auch mit SAMDisk funktionieren? Ich konnte damit zumindest auch Disks mit 128 und 256 Byte Sektoren lesen - dann sollte Schreiben doch auch machbar sein. Und mit irgendeinem der "raw-Tools" sollte auch eine Konvertierung des vorliegenden Images zu etwas mit SAMDisk Verdaubarem möglich sein?

bei "Farbe" ist nicht die Farbe der Ober(Lable)seite oder der Metallmatrize gemeint, sondern die Farbe des Farbstoffes der beim "Brennen" verändert wird. Da gibt es von Dunkelgrün, Dunkelblau über Gelb bis (fast) farblos viele Varianten. Und darin liegt der (Miß)Erfolg. Ist der Kontrast zwischen gebrannter/ungebrannter Farbschicht bei der Wellenlänge des Pickuplasers nicht ausreichend, hatten viele reine Audio CD-LW (aber durchaus auch Daten CD-LW) Probleme. Autoradios waren da oft ganz schlimm, wurde besser als diese dann auch MP3s von CD abspielen konnten; da wurden dann offenbar Pickups von Daten CD-LW verbaut.

naja, das heißt dann das Schreibsignal durchklingeln bzw. schauen ob der "Schreibschutz" nicht ev. irgendwo dazwischen funkt...

ev ist ja noch einer der Transistoren im Package defekt und liegt im "Schreibzweig".

dann löt mal einfach einen BC238 o.ä. huckepack drauf ...

Hi,

also aus Erfahrung würde ich nicht versuchen schwarz mit blau zu verbinden. Die übliche Beschaltung dieser Bauteile war wie aus der Skizze ersichtlich - also müsstest du sw mit sw und bl mit bl verbinden.

Das ließe sich verifizieren indem du bei einem blauen und schwarzen Verbindung zum Netz-kabel/-stecker messen können solltest; die anderen beiden sw/bl sollten dann einen geringen Widerstand zeigen, die Primärseite des Netztrafos.

Immer vorausgesetzt, dass der (Netz)schalter auf "Ein" steht und ev. Sicherung(en) ok sind.

nochmal: da springt nichts über - da es nichts gibt, was den Blitz leiten würde; kein Metall in den Zuleitungen.

Und selbst wenn, dann müsste/sollte (spätestens) an der Übergabestelle entsprechende Schutzmaßnahme (Erdung/Ableitung) getroffen werden.

Bleibt noch die "urban-legend" von Kugelblitzen - wenn sich so einer ins Installationsrohr zwängt, ja dann ....

ja, und was mich wesentlich mehr stören würde ist, dass nach M$ Wünschen neue MB (UEFI-BIOS) keine 32bit OS mehr starten dürfen.

da hat mir die Scannerei wohl schon etwas zugesetzt ... habe ich doch glatt 2 Seiten übersehen.

bitte, hier der Schaltplan frisch gescanned. Wenn es mich das nächste Mal in den Keller zieht, suche ich nach dem Heft 1/89 für den Grundplan.

Der Vollständigkeit halber auch noch die Ergänzung aus 9/90 sowie das Konkurrenzprojekt aus dem STcomputer Magazin.

sicher, dass er auch bis 1024 testen würde?

Zufällig (?) sind das genau 128k, möglicher weise ist da eine Bios Option, dass er das irgendwo als Cache fürs ROM verwendet o.ä.?

auf alle Fälle: warum W95? Wenn man schon bei 16/32bit bleiben möchte, dann doch zumindest W98se!

Im weiteren hat sich die Diskusiion hierhin verlegt ...

wie gesagt, im Post über dir sind zwei Images, hier die notwendigen diskdefs:

# jkzdisk
diskdef jkzdisk
  seclen 512
  tracks 1600
  sectrk 10
  blocksize 2048
  maxdir 128
  skew 2
  boottrk 2
  os 3
#  libdsk:format jkzdisk
end

# orcpm3
diskdef orcpm3
  seclen 512
  tracks 160
  sectrk 10
  blocksize 2048
  maxdir 128
  skew 2
  boottrk 2
  os 3
#  libdsk:format orcpm3
end

sowie für experimentierfreudige die .libdskrc

[jkzdisk]
description = Janich&Klass 10x512 inv 96tpi DS DD
sides = outback
cylinders = 80
heads = 2
sectors = 10
secbase = 1
secsize = 512
datarate = DD
rwgap = 12
fmtgap = 23
fm = N
complement = Y
multitrack = N
skipdeleted = Y

[orcpm3]
description = Oettle&Reichler 10x512 inv 96tpi DS DD
sides = outout
cylinders = 80
heads = 2
sectors = 10
secbase = 1
secsize = 512
datarate = DD
rwgap = 12
fmtgap = 23
fm = N
complement = Y
multitrack = N
skipdeleted = Y

und zur Bestätigung, dass die lesbar sind auch die notwendigen Einträge für PAWs samconv

gruß,

schufti

P.S.: ich mache das nicht um jmd zu quälen oder zu nörgeln sondern um es für andere Suchende die an den cpmtools (und deren nicht existenter Doku) verzweifeln fest zu halten. Als nächstes werde ich versuchen eine aktuelle Version der Windowsvariante der cpmtools mit libdsk (+tools?) zu erstellen.

P.P.S.: es wäre vermutlich nicht einmal viel Aufwand die Trackabfolgemimik und Invertierung in den cpmtools unterzubringen, man müsste bloß eine "kompatible" Parametrierung in der diskdefs finden.

Peter z80.eu ja, aber 22disk weiß eben auch um die Problematik mit der Trackabfolge bescheid.

fritzeflink mit dieser diskdefs funktionieren eben DS Formate nur mit oben genannten Einschränkungen.

Wenn jemand ein neues Tool schreibt, so kann man natürlich nicht verlangen, dass er mehr als das für ihn notwendige implementiert. Fehlende Funktionalität kann ja bei Bedarf vom "Fragenden" selbst implementiert werden - Sourcen sind ja am github.

ABER: wenn man auf Bestehendem aufbaut, sollte man sich auch der Unzulänglichkeiten des verwendeten Unterbaues bewußt sein - nichts anderes wollte ich vermitteln. Denn in der "Planungsphase" ist die Berücksichtigung von libdisk (oder eigene Implementation) eventuell noch einfacher als später.

Sucht euch (oder macht aus den Beispielen im Anhang) ein Janich&Klass, Öttle&Reichler, Kontron PSI 80, Morrow Design CP/M 2.2E, Sharp MZ-800, Sage IV oder Spectravideo SV-328DS RAW Image und schaut wie weit ihr da mit cpmtools kommt.

Gruß, schufti

GM,

ich muss meine Aussage im raw-Image ist bloß keine zusätzliche "Verwaltungsinfo" (also Track- und Sektorheader) enthalten, was die Verwendung nicht erleichtert. korrigieren: das ist der einzige Grund, warum für einige Formate das raw Image funktioniert. Nur dadurch, dass die Verwaltungsinformation wegfällt, geht z.B. Track 0, Rückseite als Track 1 durch - es erscheint somit als "lineares". Dadurch funktioniert dann auch das Kayp4 Format, weil nicht mehr evident ist, dass der erste Sektor auf der Rückseite eigentlich die Nummer 10 trägt.

Aber wie gesagt: das ist eine glückliche Koinzidenz für Formate mit einheitlicher Sektorierung und V0,R0,V1,R1 Trackabfolge.

Alle Versuche bei Formaten mit etwas exotischer Trackverteilung auf V/R Seite sind zum Scheitern verurteilt.

Vermutlich auch bei solchen mit unterschiedlicher Sektorlänge auf den Systemspuren oder wo ein HW-Skew auf der Disk vorhanden war; ebenso welche mit invertierten Daten.

Hi, nach meiner Information sind "raw" Images nicht per se "lineare/logische" Images; im raw-Image ist bloß keine zusätzliche "Verwaltungsinfo" (also Track- und Sektorheader) enthalten, was die Verwendung nicht erleichtert.

Ich habe bei noch keinem "Imager" Befehle gesehen womit man die Reihenfolge des Einlesens steuern kann, sodass die Spuren/Sektoren in der für die CP/M Implementierung logischen Reihenfolge im Image landen. I.A. landen da die Spuren in der Reihenfolge 0V,0R,1V,1R,2V,2R,...39V,39R im Image. Für viele CP/M Implementationen wäre das vermutlich sogar passend (libdsk "alt", samconv "sides") aber wenn CP/M z.B. die Disk 0V,1V,...,39V,39R,38R,...,0R angesprochen hat ist 0V,0R,1V,1R eben nicht linear (=logische Reihenfolge); z.B.janich&klass (libdsk "outback", samconv "cylinders")

Oder das Kaypro4 Format, welches zwar auch 0V,0R,1V,1R hat aber die Sektoren auf der Rückseite mit 10...19 nummeriert (libdsk "extsurface", samconv "sides+skewtable").

Die Zuordnung logischer Track - physikalischer Track ist Hersteller spezifisch, muss bekannt sein und geschieht am besten in den Tools die Filesystem spezifische Zugriffe nachbilden.

Das Disk-Image ist am besten ein echtes "Image" so wie die Disk physikalisch existiert - so läßt sich einfach eine zur HW kompatible Schnittstelle nachbilden, die dann mit Images ebenso wie mit echter HW umgehen kann. Oder Formate mit invertierten Daten - wo berücksichtigt man das sonst?

Zugegeben, für reine CP/M Images wären "echte physikalische Images" nicht notwendig, da 99.xxx% kein Kopierschutz drauf ist und "logische" Images würden die Zugriffe wesentlich vereinfachen - man müsste die Hersteller spezifische Trackumsetzung nicht wissen, nur die reinen CP/M DPB Werte. Dann wäre es aber sinnvoll ein spezielles Imageformat (.cpm ???) dafür zu definieren - am besten mit den DPB Werten gleich mit drin, dann wären zukünftig alle Images problemlos und einfachst zu "lesen".

ABER: spätestens beim Zurückschreiben auf ein Medium ist der Vorteil verpufft! Und das ganze widerspricht dem Gedanken der Image Erstellung: einfach Abbild machen, übermitteln und ebenso einfach wieder aufs Medium.

Zeigt mir eine Methode ein Kaypro4 (.dsk/.img/.imd siehe Anhang) mit reinen cpmtools (ohne libdsk) zu bearbeiten und ich behaupte fortan das Gegenteil.

P.S.: sorry, dass das jetzt den Thread zum CIFE jetzt etwas bloated ... könnt das gerne in meinen cpmtool thread verschieben

ja, bei mir läuft es auch wieder - sollte überlegen davon ein Archiv anzulegen ...

naja, ich habe gerade mit Erstaunen festgestellt, dass die üblichen .dsk .td0 oder .imd von doppelseitigen Floppys die so im Netz zu finden sind mit den reinen cpmtools nicht zu bearbeiten sind - zumindest konnte ich mangels entsprechender Doku keine Einstellungen finden um die diversen Spielarten der Verteilung (inkl. Nummerierung) der Spuren (und ggfs Sektoren!) auf Vorder- und Rückseite zu konfigurieren; von Formaten mit invertierten Daten ganz abgesehen.

Das scheint alles Funktionalität der libdsk Erweiterung zu sein. Das SAMconv von PAW ist da sogar noch etwas flexibler.

Jedes Image erst in ein "lineares" zu wandeln scheint mir doch etwas zu ... untechnisch.

Natürlich könnte man die "Disk-I/O" Routinen der cpmtools entsprechend erweitern - aber libdsk hätte (auf Windows zusammen mit fdrawcmd) den Charm auch direkt auf ein echtes LW zugreifen zu können.

Hi Fritz,

danke für den Verweis auf die noch existenten "Don Maslin's Disk" Archive.

Mir ging es baer nicht generell um diese, es war nur die letzte Seite von http://www.retroarchive.org die ich noch im Cache hatte. Ich fände es nur sehr schade wenn so ein umfangreiches Archiv plötzlich (für immer?) verschwunden wäre.

LG

P.S.: das mit dem defekten Link sah ich leider zu spät, gewöhnlich korrigiere ich das noch in der Vorschau.

Hi again,

no - not good - the archive on classiccpm.org only does link to the original location, too. Try to download some file from this list:

http://cpmarchives.classiccmp.…in's%20Disk%20Images.html

Hi,

ok thanks!

So obviously the DNS on my side seems to have a problem, though I tried from private and office.

But it is good to know there is a mirror of the archive...

best rgeards,

schufti

Hi,

when I try to access http://www.retroarchive.org I get a timeout because the address can't even be resolved.

Does anyone have recent information on the whereabouts of this huge archive? Is the domain just expired an direct ip (which?) access would work?

Unfortunately a lot of search results link to this page.

rgds,

schufti

Hi,

entschuldigt die ketzerische Frage, aber sollte man nicht auf Grund der Unzulänglichkeiten der cpmtools gleich anfangs auch die libdsk einbeziehen?

Bei doppelseitigen Disks auf Images angewiesen zu sein welche die logische (anstatt der physikalischen) Trackreihenfolge bereithalten sehe ich als problematisch. Ich denke nicht, dass es viele Imager gibt die das anbieten - besonders wenn sie auch Kopierschutz berücksichtigen.

Oder habe ich da etwas grundlegendes bzgl. DS Disks in cpmtools (ohne libdsk) übersehen?

Die Kaypro2 Variante nutze ich (nach Erweiterung der diskdefs) mit SAMdisk Images erfolgreich so:

cpmls -f kpii kaypSS.dsk

cpmcp -t -f kpii kaypSS.dsk 0:*.* cpm

sowohl cpmtools als auch libdsk geben ja an .dsk zu unterstützen.

Nach langem Schmökern in der libdsk.pdf und endlosen Versuchen erkannte ich, dass die Definition für KAYPRO4 (kpiv) im o.g. Thread falsch ist. Jetzt mit korrektem .libdskrc Eintrag ist auch das erfolgreich.

Habe mir noch extra von Dave Dunfield's Seite auch KP4 .IMDs geholt, läuft ebenfalls.

Alfred: es wurde um 2k größer definiert (4 anstatt 2 1k AUs), somit wäre AL0/1 zu soetwas wie "reserved Blocks" umdefiniert?