Posts by runeb

    Ein PC speichert auf einer doppelseitigen DD 3,5" Diskette 720KB im MFM Format.

    Ein Amiga 880KB - also wohl zwei Blöcke mehr pro Spur (2*80 Spuren).

    Eine 1581 800KB. Die Blöcke ähneln vermutlich denen vom PC, weshalb alte PCs diese mit Omniflop und altem Laufwerk (nicht USB!) manchmal lesen können. Ein Amiga kann das mit geeigneter Einstellung eventuell auch verarbeiten. Ich weiss nicht ob man da das crossdos Device oder das für Amigaformatierte auf die entsprechenden Sektorzahlen stellen müsste oder was neues bräuchte. Der Amiga liest wie die 1581 die Spuren als ganzen Track in einen Puffer.


    Die SFD 1001 schreibt 2*77 Blöcke im GCR Format (GCR ist die gleiche Codierung wie bei der 1541). Auf DD-5-1/4" Disketten.


    HD Disketten haben eine schwerer magnetisierbare Oberfläche. So ähnlich wie mit normalen und Chromdioxid Kassetten bei Musik / Datasette.

    Bei den Kassetten konnte ich diese wunderbar in bester Qualität bespielen wenn sie neu waren, aber nicht überspielen weil ein ungeeigneter Kassettenrekorder zu wenig "Power" im Löschkopf verwendet.

    Das könnte mit Disketten ähnlich sein. Ich kann mir vorstellen das man sich viel ärger einhandelt wenn man HD Disketten im DD Laufwerk überschreibt oder bespielte bearbeitet. Wenn man eine junfäuliche HD Diskette einmal trackweise bespielt KÖNNTE es funktionieren.


    Übrigens beim Auslesen von doppelseitigen bespielten einseitigen Disketten mit Zoomfloppy habe ich oft angezeigt bekommen das alle Tracks auf der Rückseite schwach seien.

    Es wurde auch schon geschrieben das die 1541 stärker magnetisiere als die SFD 1001 und daher die 1541 Disketten hinterher in der SFD Probleme machen. Könnte aber auch am unsauberen Löschen aufgrund der anderen Trackanzahl und Lage liegen. Es heisst auch das die SFD eigentlich 100TPI schreibe statt wie üblich 96. (Tracks per Inch). Auf den Disketten steht im Idealfall ja DSDD 96TPI. (2seitig für 80 Spuren).

    I think it possible that the drive in 1571 mode might write only 40 (35) tracks double sided if these tracks are simply sent to the drive without thinking by the tool.


    Watch the progress and listen to the click when the track changes. Does it click every track or only every two tracks while writing with the 1571?

    Or count the total number of clicks.

    (Ich bin Deutsch aber weil einige englische Beiträge in dem Thread sind habe ich englisch geantwortet)

    Meiner Ansicht hat man am C64 mit alten unmodifizierten Spielen am meisten Spaß wenn man den 2. Feuerknopf separat herausführt und bei Bedarf mit Masse und Feuer von Port 1 verbindet.

    Denn viele Spiele mit Joystick in Port 2 und einer 2. Aktion lösen diese mit der Leertaste aus was fast immer auch mit Feuer von Port 1 geht.

    Ich habe das bei einem 2-Button Competition Pro und einem Quickshot gemacht. Nicht schön, aber (vielleicht nicht so) selten ;) . Da hängen zwei ca. 1m lange Kabel raus. Der 2. Feuerknopf ist mit keiner Leitung von Port 2 mehr verbunden. Eines hätte wohl auch gereicht, wäre aber gefählicher wenn man keine Ahnung hat und/oder es "fliegend" an einen Pin von Port 1 anklemmt und sich mal vertut.


    Hier gibt es eine Tabelle welche Systeme die Buchse wie belegen: (am 2. Mai 2019 von captain_tapp bereits gesendet)

    http://wiki.icomp.de/wiki/DB9-Joystick


    Hier steht sogar wie man es macht für C64GS modifizierte Spiele: (VCC 5V, GND 0V).


    "The classic C64GS two button joystick ("Cheetah Annihilator") uses the POTX line, which when the button is pressed is connected to VCC. For a third button, the same can be done with the POTY line. These two buttons can then be read from the paddle inputs: When the button is not pressed the POT line is floating, which equals a large resistance to VCC, and will read as $FF. When the button is pressed the POT line is connected to VCC, which equals no resistance to VCC, and will read as $00."

    Im Prinzip könnte man "fast belibig viele" Knöpfe unterstützen... Denn man kann die "normalen" fünf Eingangsleitungen auch auf Ausgang schalten und so eine Matrix abfragen.

    Rein theoretisch: alle 5 Leitungen auf Ausgang wählen aus: 32 Möglichkeiten * 2 wenn man beide POT-Leitungen als Eingang "mißbraucht". Ohne POT-Tricks kommt man schon auf 16*1.

    Ebenfalls denkbar wäre weitere Knöpfe durch unterschiedliche Widerstände zu Codieren, da die POT-Leitungen diese ja messen könnten.


    Vorsicht: - ich glaube wenn man eine auf Ausgang geschaltete Leitung mit dem entgegengesetzten Pegel belegt kann vielleicht der Chip kaputt gehen. Zumindest wenn kein Widerstand den Strom ausreichend begrenzt... (oder nimmt man da Dioden? Ich erinnere mich das früher oft bei Userportschaltungen oder neueren Rechnern an Perepherieanschlüssen von "Schutzdioden" die Rede war, z.B. um zu verhindern das beim Druckeranschluß bei laufendem Rechner der Port kaputt geht).


    Wie man in der verlinkten Tabelle sieht sind VCC (5V) bei MSX und Sega auf Pin 5 und bei Atari und Commodore auf Pin 7.

    Also könnte ein Amstrad oder MSX Gamepad GND und VCC verbinden (Fire 1 oder Fire2 dort). Und ein seltenes Commodore Gerät (oder Amstrad) mit Fire 3 MSX und Sega kaputt machen.


    Kürzlich habe ich ein angeblich für den Amiga und ST umgebautes Atari Gamepad gekauft. Die haben wie hier schon erwähnt die Leitung auf Masse gesetzt. Für den Amiga erst einmal korrekt, aber es scheint das einige Amiga Modelle noch einen Pullup-Wiederstand benötigen da sie es sonst nicht erkennen weil der Pegel nicht von selbst wieder hoch geht. Auch dort ist es eigentlich ein POT-Eingang.

    Umgekehrt müsste auch der C64 (wie der Amiga) 0V an den POT Eingängen erkennen können mit diesem Widerstand der bei "nicht gedrückt" für einen definierten Wert sorgt. Nun scheint es aber so zu sein das beim C64 wegen der Vorgabe vom GS 5V erwartet wird und das so am C64 auch ohne Widerstand funktioniert.


    Übrigens, der Individual Computers Arikel verlinkt u.a auf diesen Thread zurück:

    Wie funktionieren Joysticks mit 2 oder 3 unabhängigen Feuerknöpfen?


    Dort steht auch schon lange einiges was ich hier noch einmal hoffentlich richtig geschrieben habe.

    Moin


    Ich habe kürzlich ZoomFloppy über Ebay Kleinanzeigen gekauft und mit OpenCBM neueste Version experimentiert.


    1. 1541 mit Dolphindos


    Parallelkabel angeschlossen

    - Parallelkabel wird nicht automatisch erkannt, funktioniert aber mit den entsprechenden Optionen

    - RAM in der 1541 wird erwartungsgemäßt nicht genutzt, es wird kein kompletter Track in einen Rutsch gelesen

    - mit nibtools doppelte Geschwindigkeit, vermutlich liest das ohne Ranunterstützung die Tracks in einen Durchgang

    -> einfache Batchdatei geschrieben die (ganz simpel ohne Errorhandling)

    - mit d64copy Track35 liest. Dadurch gibt es statt einem Rattern nur einen Klick bei NibCopy ;)

    - Mit Nibread die Diskette in eine .nib Datei liest (%1.nib).

    - diese mit dem Konvertiertool in eine d64 Datei wandelt

    - die .nib Datei und das Logfile löscht

    Erfahrung:

    - konnte alle Diskettten lesen, eine hat einen 2. Versuch nach Neueinlegen gebraucht.

    - auf den Vorderseiten meist 3-4 weak tracks, auf den Rückseiten auf den meisten Disketten, sogar wenn frisch beschrieben


    2. 1581

    - wird von imgcopy nicht erkannt, es wird versucht 8250 Format zu benutzen, nichts geht so. Steht bei .99 auch dabei das da noch viel ungetestet ist.

    - mit -d 1581 (Drive Typ Festlegen) geht es. Es wird aber nicht der schnellste Transfermodus verwendet. Habe vergessen welcher der schnellste war, glaube es war burst.
    - Habe auch meinen alten Pentium Windows 98+XP Rechner reaktiviert und versucht damit 1581 Disketten mit OmniFlop zu lesen.

    - Einer der beiden Treiber muß installiert werden, das 1581 Format wurde nicht automatisch erkannt. Auswahl mühsam da Liste lang und keine Suche möglich.

    - Von meinen fünf Disketten ging eine nur zu 2/3. (Geos 128 Boot)

    - Nicht schneller als die echte mit ZoomFloppy


    Ich habe alles aus dem Gedächtnis aufgeschrieben. Falls es jemanden interessiert kann ich die Batchdatei und Versionsangaben der Tools nachliefern.

    Hat schon jemand probiert ob nibread einen %ERRORLEVEL% liefert? Wenn ja kann ich eine Warnung ausgeben wenn nicht alle Sektoren gelesen wurden.


    Als nächstes werde ich den leider nicht durch die Löcher passenden IEEE 488 Stecker mit Hilfe von Blumendraht auf die Platine löten und wenn es klappt über das Lesen von SFD 1001 Disketten berichten, habe 20 Stück die nach Stichprobe alle noch OK sind.

    (bisher mit REX Interface am C128 genutzt). Vielleicht hätte ich doch Pfostenleistenstecker, Buchse, Flachkabel und Presssstecker oder Buchse bestellen sollen... die gewinkelte Buchse zum Auflöten gabs bei Reichelt nicht. Schade das ZoomFloppy nicht einfach einen Platinenrand hat wie für das Parallelkabel zur 1541, denn dafür habe ich ein Anschlußkabel da ich die SFD Floppy damals mit einem C620 gekauft hatte.


    Weiteres zum Dateitransfer, im Moment OT: (wenn ich das angehe mache ich da eigene Threads auf wenn ich glaube es interessiert jemanden)

    Ich habe auch ein Ultimate 1541-II, habe das aber nicht weiter verfolgt damit auf die SD Karte zu kopieren. Liegt schon ein paar Jahre in der Schublade, wie auch Catweazle PC/Amiga und Cryoflux . Für letztere fehlen mir noch die Laufwerke bzw. die müsste ich irgendwo ausbauen.

    Die Modulemulation des Ultimate ging nach einen Firmwareupdate nicht mehr, vielleicht wurde das Modultiming von 2.6beta auf 3.x zurückgesetzt und war vorher richtig(er). Ich habe die Empfehlung für C128 Timings noch nicht ausprobiert ob es damit wieder geht. Könnte aber auch sein das das Modul mir übelgenommen hat das ich es in den durchgeführten Modulport vom REX IEEE 488 gesteckt habe. Firmwaredowngrade hat jedenfalls nicht geholfen, das Timing wird vielleicht nicht zurückgesetzt. Auch die REU Emulation geht nicht mehr, Dateien von Images laden geht noch. Echte REU (512K) geht.

    ... Die im Forum gefundene Timingeinstellung muß ich noch einmal ausprobieren. Wäre interessant ob man Images oder Dateien mit vernünftiger Geschwindigkeit von der SFD auf SD kopieren kann, also ob es Programme gibt die gleichzeitig die SF ohne Bechleunigung und die SD Karte oder D64/D81 mit Beschleunigung ansprechen. Habe was von Kernels gefunden die Professional/Prologic/Jiffy gleichzeitig mit REX/Jann können. Oder eingebautes Filecopy von der Ultimate?

    Aber eigentlich ist das alles nur noch Spielerei aus Spaß oder Interesse da es ja mit ZoomFloppy wohl am einfachsten geht. Gotek/HxC am Amiga habe ich bereits getestet, gehört hier aber überhaupt nicht her (-> Amiga/ADF, Bericht auf Wunsch).


    Anmerkung am Rande: Im Netz sind D82 (SFD / 8250) Images mit C64 Programmen im Moment sehr beliebt um hunderte Programme für den C64mini/C64maxi bereitzustellen da der die liest und da am meisten auf einmal darauf passt.


    Gruß, Rune.

    Ich verstehe die Speederdiskussion bei virtueller Hardware nicht ganz.


    Mit Ultimate64 oder Ultimate1541 kann man doch per DMA laden und nur ggf. nachzuladene Programme brauchen einen Speeder (PRG Datei im Ultimate1541-Menü auswählen und dort mit oder ohne Mount der .D64 laden). Da wäre dann Jiffy schon intessant. Oder EPYX Fastload was auch im Ultimate drin ist. Ich hatte damals das Fastloadmodul, das besondere war das es ohne Bildschirmabschaltung lädt und einigermaßen kompatibel war. Dolphindos oder Jiffy als Tauschromlader sind natürlich kompatibler. Lader mit flackerndem Bildschirmrand finde ich nervig (ausser bei Kassette).

    Ich selbt habe bisher mit Ultimate1541 noch nicht so viel rumgespielt, hatte damals aber diverse Module und DoplinDos 2.0+1541. Und auch eine SFD 1001 mit REX Modul und Jann Kernel. Und eine 1581. Bisher alles ohne Jiffy.


    OT: Mich persönlich interessiert im Moment die Möglichkeit 2 Systeme gleichzeitig zu haben, Dolphindos/Jiffy oder ein Filecopy oder .D82 Image Ersteller das sowohl 1541 mit Beschleunigung und andere ohne unterstützt damit der geänderte Kernel zum Tragen kommt, damit ich nicht all zu langsam von der SFD 1001 auf SD-Karte von Ultimate1541 oder auf 1581 kopieren kann.

    Wenn ein älteres System scheinbar grundlos Bluescreens wirft können auch oxidierte Kontakte z.B. der RAM Module die Ursache sein. RAM rausnehmen und wieder einsezten. Habe ich schon zweimal erlebt das Rechern manchmal gar nicht erst booten oder kurz danach abschmieren.


    Wenn eine Linux Bootcd rumliegt: Da ist oft ein Ramtest im Bootmenue. Könnte hilfreich sein das mal ein paar Minuten laufen zu lassen.

    Ich lese hier gerade was von PC IEEE Karten (Schmitti). Daher habe ich die Hoffnung das jemand weis ob die für uns nützlich sein können.


    Habe mir kürzlich bei eBay und Amazon welche angeguckt und da war immer nur von Messgeräten und zugehöriger Software die Rede, selten mal von einer C-Programmierung. Daher frage ich mich ob man mit diesen auch Dateien senden / empfangen kann und über das C-API was programmieren kann was erst das Verzeichnis anfordert und dann (ggf. nach Auswahl) die Dateien eines Commodore IEEE 488 Laufwerks. Oder OpenCBM so ändern das es die API nutzt.


    Die Teile sind allerdings sehr teuer aber eventuell besser verfügbar als die ZoomFlopppy Adapter, und eventuell auch mal gebraucht.

    Für die die die wie ich die Anleitung nicht griffbereit haben:


    Die Maus muß wohl in Port 1 - wenn man sie in Port 2 steckt springt der Mauszeiger wild durch die Gegend und man könnte denken das die Maus oder der Computer kaputt ist.


    Ich habe gerade den merkwürdigen Effekt das die Maus keinen linken Mausklick im 40 Zeichen Modus macht. Mit 80 Zeichen geht es merkwürdigerweise. Aber Geos128 mit 80 Zeichen macht sowieso mehr Spaß.

    Meine Erfahrugnen mit der Commodore REU 1750


    Commdore REU Unterstützung:

    Geos: Schnelleres Scrollen durch DMA-Verwendung und RAM-DISK.

    Test Drive (Autorennspiel): Cached alle bereits geladenen Level (keine Ahnung ob original eingebaut oder gepatcht)

    Burst Nibbler und diverse englische Kopierprograqmme (Maverick?): Kopieren einer Disk in einem Durchgang


    Quelle: Tests aus meiner Jugend C64 / 128 mit Commdore 1750 REU (512kb am C64 mit stärkerem Netzteil wie bei dier 1764 mitgeliefert).


    Mit Ultimate 1541 II noch nicht nachgetestet. Diese benutzt DMA auch wenn man ein Spiel aus dem Menü lädt und ist dann somit schneller als jeder Fastloader. Wahlweise wird nach dem laden auch noch das Diskimage gemountet.


    Ich habe damals auch mal versucht das COMAL Modul aus der Schule auszulesen und nachzubilden, das mit Banking funktioniert. Klappte, war aber irsinnig langsam weil das Modul jeweils 16K von 64 (oder so ähnlich) eingeblendet hat, die REU musste das natürlich ständig hin und her kopieren ;)

    COMAL war eine Programmiersprache u.a. mit Turtlegrafik wie LOGO. Die 1750 hat man ähnlich wie den Videochip des C128 genutzt in dem man Quell und Zieladressen in Register geschrieben hat, und dann durch Schreiben des Befehlsbytes die Operation ausgelöst hat. KEIN Memory-Map.


    Gruß, Rune.


    P.S.
    Hat schon jemand probiert wieviel Speicher GEOS maximal nutzen kann? (Kann ich natürlich auch selbst mal probieren... der C128 steht allerdings im Schrank und der Amiga 2000/68030 fast griffbereit unterm Drucker). Meine SFD-1001 mit REX-IEEE Modul ist leider wegen der Kondensatorkrankheit kaputt und wartet auf Reperatur... 1581 und 1541 mit DolphinDos laufen. Habe mal unter GEOS programmiert (Geoprogrammer).