Hello, Guest the thread was called444 times and contains 19 replays

last post from mnaberez at the

Offtopic aus IEEE488 Replik Thread

  • Das Interface haben wir auch als Varianten mit 6526 (für den c64, publiziert in der ct) und 8255 (für den c64 & 128, publiziert in der 64er) entwickelt. Es gibt aber keine Variante von irgendeinem IEEE-Bus mit Routinen im Kernal, der die deutlich jüngeren Jiffy-DOS Routinen enthalten würde. Zumal da ein "Copyright-Inhaber" auch die Finger drauf hält.

    Daran soll es nicht scheitern.


    Ich wäre an einer IEEE-488 Hardware interessiert.

    Die Hardware kann ich nicht bauen, maximal zusammenbauen.

    Aber an der Kernal Änderung soll es nicht scheitern, DAS kann ich.



    Natürlich geht das immer nur mit Opfer.

    Wenn IEC (oder Jiffy) zugleich mit IEEE-488 gehen soll, dann braucht es Platz.

    Also fliegen entweder RS232 oder Tape raus.

  • Mir ist es egal ob 6522 oder 6526 oder ein GAL.

    Den Code kriegen wir schon gebacken.


    Zum testen habe ich alles da.

    C64, 1541, 8250, PET2SD ...



    Die Unterscheidung wird wohl die Geräte Nummer sein ...

    Die Frage ist mehr, WIE soll der Kernal wissen, welches Gerät an welchem Port ist.


    Natürlich könnte man auf beide Ports (IEC und IEEE-488) mal ATN setzen und das Gerät ansprechen.

    Da wo kein "Device not present" kommt ...

    Alles denkbar ...

  • Es gibt auch das IEC2IEEE Interface, das könnte hier eine gute Lösung sein:


    - gleichzeitig IEC und IEEE, weil es eine externe Bridge ist

    - keine Kernal Änderung nötig, weil es eine externe Bridge ist

    - schnell, weil es unterstützt das Jiffydos Protokoll

    - Expansionport bleibt frei.


    http://www.nlq.de/


    habe mir bisher aber keines gebaut, weil ich ja wie gesagt mit Asklias Interface sehr glücklich bin.

    Zuletzt repariert:
    21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
    19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
    27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!


  • Stimmt eigentlich.


    DAS ist die ultimative Lösung.

    Ein Jiffy to IEEE-488 bridge.


    :)


    www.zahnarzt-adler.de/nlq/ajni2blt.txt (zahnarzt-adler.de)

  • Hab das Commodore-Interface auch seit Ewigkeiten rumliegen, aber nur extrem selten genutzt. Interpod war besser, aber auch nicht perfekt, die Lösung von NLQ ist meines Erachtens nach ziemlich nahe dran am perfekt, aber hat eben einen Haken (für Fundis): basiert nicht auf 65xx Architektur...


    Da NLQ aber glücklicherweise auch hier im Forum aktiv ist, wäre mein Vorschlag daher, eine Implementierung auf Basis eines aktuell noch verfügbaren 65Cxx Prozessors zu machen als eigenständiges Kästchen wie das Interpod, aber eben mit Jiffy-Dos-Unterstützung und möglichst flexiblen "Routing", d.h. keine fixe Vergabe von Device-Nummern je Bus, sondern Pflegen einer Tabelle, wo welche Nr. zuletzt reagiert hat (da hot plugging bekanntlich eher ungesund ist im C=-Land, reicht es ja, diese Tabelle mehr oder minder statisch zu führen...)


    NLQ: wie schätzt Du die Chance ein, das auf z.b. 4MHz 65C02 mit z.b. je 32K SRAM und ROM und zwei 65C22 fürs I/O zu realisieren?


    Z.b. einfach auf ne modifizierte PCB der 1541-II oder ähnliche Plattformen (1581 oder CMD-FD Replik z.b.) aufsetzen, die günstig und in Masse verfügbar sind.


    Interesse?




    n.B.: Was das "will haben" anbelangt: da war sie wieder die Grundsatzfrage, ob etwas Seltenes nicht einfach dadurch an Reiz verliert, wenn es quasi unbegrenzt verfügbar wird?


    Ein Nachbau von z.b. 1581 oder CMD FD2K macht Sinn, weil sich diese in der Praxis auch noch nutzen lassen, meiner Meinung nach sollte die Community aber auch so selbstbewusst sein und sich von reinen Repliken lösen, die Welt stand ja nicht still in den letzten 30 Jahren!

    Denn "original" wird so ein Nachbau auch dann NIE werden, selbst wenn man das Gehäuse kopieren würde (was ziemlich teuer würde...), aber man nimmt sich selbst dadurch jegliche "künstlerische" Freiheit und wie Asklia schon korrekt anmerkte, gibt und gab es deutlich bessere Lösungen damals schon und heute erst recht!


    Ich weiß, das beisst sich jetzt etwas mit obiger Aussage, wobei ich selbst durchaus mit anderen Architekturen leben kann, wenngleich ich nicht auf ATMega "gepolt" bin, aber was ich verlöte, das ist mir relativ egal...


    Wenn ich aber selbst programmieren möchte, dann würde ich zu Plattformen greifen, die ich gut kenne und/oder schon häufiger verwendet habe.


    Allerdings hätte es auch seinen Reiz, quasi auf vorhandener Hardware das Ganze zu realisieren, z.b. eine 1581 oder eben CMD-FD PCB (egal ob neu, oder nachgefertigt als "Reparaturersatz") dazu zu verwenden, oder auch ne 1541-II ;-) als Low-Cost! Und eben nur das hinzu zu fügen, was man braucht, d.h. IEEE-488 Bus und Transceiver, dafür das mech. Laufwerk weg zu lassen. Mehr RAM und ROM sollten auch kein Problem sein... 2 oder 4 MHz dürften zusammen mit passendem 65C02/22 und neuem RAM/ROM auch auf der 1541-II funktionieren, die CMD FD hätte genau das eh schon als Standard mit drauf... Frontblende in 3D neu gemacht und ein nettes Typenschildchen und schon hat die C= Familie Zuwachs bekommen ...

  • Falls du aufgepasst hast, dann ist die FD sowie auch HD keine reine Replik mehr - sofern drehte sich die Welt schon weiter ;) Wobei man in diesem Fall sich wirklich fragen sollte ob sich die Arbeit lohnt - und im Hobbybereich wird niemand Spritzgussgehäuse herstellen lassen, die ans Original erinnert.


    Für die FD und HD jedenfalls ist die Gehäusefrage für mich längst geklärt - das neue Plexiglasgehäuse zeige ich nachher mal, setze ich gerade zusammen.


    Kann ja jeder selbst entscheiden, was er wo wie einsetzen will.

  • NLQ: wie schätzt Du die Chance ein, das auf z.b. 4MHz 65C02 mit z.b. je 32K SRAM und ROM und zwei 65C22 fürs I/O zu realisieren?

    1 MHz langt aiuch ganz leicht ...


    32K RAM, wow, Luxus!!

    das ist acht mal soviel wie eine 8250 hat und 16 mal soviel wie eine 1541 ...


    Da könnte man schon auf "Verdacht" lesen, die Bridge hätte dann schon alle Buffer von 4 angeschlossenen Geräten "auf Vorrat".

    Damit würde man den "Bridge Nachteil" wett machen, eine Bridge muss ja immer erst lesen und dann weiter geben ...



    Ein rein native Lösung wäre sehr einfach auf so einem Board.

    Eine Lösung mit großen extra Buffer wäre etwas komplizierter.

    Man muss dann aufpassen noch kompatibel zu bleiben.



    Aber angenommen man hat diese Bridge ...

    Was genau würde man damit machen?


    Ich weiß, das fragt man nicht.

    Man macht es weil man es kann. :D

  • toms01 : Nein, ich habe Dein CMD-HD Projekt NICHT verfolgt und vom FD-Projekt kenne ich nur flüchtig einen Stand, der -bis auf die Addon-PCB zur Anpassung von PC-LW- ziemlich nach 1:1 aussah. CMD ist nicht ganz so mein Ding, um ehrlich zu sein, von Jiffy-Dos mal abgesehen :thumbup:


    Aber angenommen man hat diese Bridge ...

    Was genau würde man damit machen?

    Nun, dazu mal meinen Use-Case, der aber -vermutlich- noch bei ein paar Anderen hier so oder so ähnlich gegeben sein dürfte:


    Ich habe neben einem SX64 und einem VC-20 (mit Vollausbau und VC1020) als Basisgerät noch zwei 1581 sowie eine 4040 (da die 1541er disks autark kopieren kann u.a.) sowie einen 8296D und noch zwei weitere SFD1001 hier stehen.


    Dazu mehrere ehemals hochpreisige Messgeräte (HP, Gould, Tektronix, LeCroy, Fluke) die jeweils ebenso einen GPIB=IEEE-488 Anschluss haben, also PARALLEL und die ich -auch damals schon- über CBM-Basic programmiert habe, um gewisse Testautomatisierungen zu realisieren.


    Dazu noch einen 1520, einen Seiko "Kassenbon"-Drucker und einen NL10 mit seriellem IEC-Bus, paralleler Centronics und sogar RS232 IF-Modul jeweils (nur eines immer verbaubar!) und natürlich jede Menge "modernere" Geräte mit Centronics-Schnittstelle und/oder RS232-seriellem Interface. z.B. HP4MV A3-Laser.


    Mittels dem originalen "historischen" Interpod konnte ich vom SX64 aus auch "damals" schon auf die IEC-parallelen Geräte zugreifen, ohne ein geändertes Kernal zu benötigen oder den Expansionslot (und wichtige I/O-Bereiche insb.) zu belegen, sowie über dessen serielle Schnittstelle immerhin serielle Drucker ansteuern (RS232 ist im Interpod rein für Ausgabegeräte ausgelegt, in HW liesse sich das schnell ändern, aber die Firmware dafür fehlt dann immer noch...)


    Was CBM-Geräte anbelangt, geht das relativ zuverlässig, aber GPIB Messgeräte zicken am Interpod teils gewaltig rum...


    Nachteil: saulangsam, eben serieller IEC-Bus im Werkszustand PLUS Umsetzverzögerung InterPod.


    Andersrum kann ich aber vom 8296D nur auf die IEC-parallelen Geräte zugreifen, nicht aber auf die IEC-seriellen, da das originale Interpod leider nur Master am seriellen IEC-Port unterstützt.


    Somit leider auch auf KEINE der Drucker, wobei ich mir natürlich ein Userport-Parallelkabel gebaut habe und somit in eigenen Programmen (aber mit einigem Aufwand) auf beliebigen Centronicsdruckern drucken kann, aber leider eben nicht auf dem VC1520 oder dem Seiko, die für kleine Messprotokolle besser geeignet sind und auch einfacher zu programmieren.


    Dank der "kleinen" Lösung von NLQ (Stand ca 2016?) konnte ich immerhin das altersschwache Interpod durch diese kleine und elegante Lösung ersetzen und es somit auch duplizieren, das historische hängt jetzt am VC-20 und wird nur noch selten genutzt....


    Soweit ich das richtig mitbekommen habe, hat NLQ die seinerzeit angekündigte Jiffy-Dos Unterstützung fertig (?) und das würde den Geschwindigkeitsnachteil beheben.


    Ob NLQs Lösung inzwischen auch Master am parallelen Bus erlaubt, habe ich noch nicht nachgeschaut, bin erst grad eben wieder auf dieses Thema aufmerksam geworden.


    Wenn es das noch nicht tut, wäre das einer der Punkte, die mir sehr am Herzen liegen würden!


    Die HW-Vorgaben 4 MHz 65C02 und 32k RAM und ROM stammen einfach daher, dass das eine Schnittmenge zw. "erprobt" (einige Turbo-Karten und z.b. das Final-Chess-Modul laufen mit 4 MHz) und heute verfügbaren Speicherchips ist, 32K SRAM ist heute (noch) ein günstiger und gut verfügbarer Chip, da auf was Kleineres zu gehen, lohnt schlichtweg nicht, ebenso erst recht bei den EEPROMs oder Flash-Roms. Ob man die dann komplett einblendet, das ist die andere Frage, aber ausser den paar Byte für die zwei 65C22 braucht man ja eigentlich kein I/O und die lassen sich a la 264 auch an fixen Stellen "übers" ROM einblenden.


    Wenn man eine 1541-II oder 1581 PCB als Basis nimmt, dann kann man ja erstmal mit deren RAM starten und erweitern, wenns nicht reichen sollte...


    Wobei ich stark Richtung 1541-II tendieren würde, da sich die sogar weitgehend rückbaubar dafür modifizieren lassen, man könnte eine neue Front in 3D drucken (es gibt inzw. ganze -und sogar relativ schicke- 1581-Gehäuse in 3D Druck, da sollte eine "gecleante" 1541-II Front auch gehen...), auch die Mods an der PCB halten sich in Grenzen und sind über kleine Adapter-Sockel machbar, wenn mans drauf anlegt, fände sich sicherlich auch genug Platz, um die "arbeitslose" Laufwerksmechanik auch noch im Gehäuse zu lagern, vielleicht sogar die originale Blende.


    Auf diese Weise zu neuem Leben verholfen würden vermutlich mehr 1541-II überleben!

    Von den ca. 20% ab Werk mit D50x Newtronics/Mitsumi-Mechanik bestückten und somit früher oder später -bislang irreparabel- Ausfallenden ganz zu schweigen.


    Natürlich kann dazu auch eine "klassische" 1541 (z.b. defekte D500er) als Basis dienen, dort kann man vorne ja sogar eine PC-Laufwerksblende einsetzen, aber die Teile sind mir persönlich zu groß und zu schwer, als dass ich da ne neue Funktion mit realisieren würde...


    Für die großen CBMs gäbe es natürlich auch die Möglicheit, die relativ kleine PCB dort noch intern mit einzubauen und dann gleich einen seriellen IEC am Gerät zu haben (und möglicherweise auch einen RS232 und Centronics als "Subgeräte" am virtuellen IEEE488 realisiert und somit problemlos und ohne Kernalpatch ansteuerbar)

  • Ob NLQs Lösung inzwischen auch Master am parallelen Bus erlaubt, habe ich noch nicht nachgeschaut, bin erst grad eben wieder auf dieses Thema aufmerksam geworden.

    Naja Master ...


    Der IEEE-488 Bus von Commodore ist nicht Multimaster fähig.

    Man kann zwar mehrere Master haben, darf aber nur einen benutzen.

    Sonst braucht man eine Hardware Lösung, gabs ja für Schulen etc.

    Weder die Master (8032 etc.) noch die Slaves (Floppy, Drucker ...) sind Multimaster fähig.


    Insofern macht eine "echte" Brdige ja gar keinen Sinn.


    Die Bridge ist einseitig orientiert:

    • entweder: IEEE-488 Master und IEC Slave
    • oder: IEC Master und IEEE-488 Slave


    Man kann das manuell schalten oder automatisch nach dem ersten Zugriff.



    Für die großen CBMs gäbe es natürlich auch die Möglicheit, die relativ kleine PCB dort noch intern mit einzubauen und dann gleich einen seriellen IEC am Gerät zu haben

    Oja, diese Idee ist sehr reizvoll.

    Eine Multiprotokoll 8250 Floppy wär schon was! :)


    Das geht auch verkehrt rum.

    Eine Multiprotokoll 1581 oder 1571 würde gut zu meinem 8296 passen!



    Wenn man eine 1541-II oder 1581 PCB als Basis nimmt, dann kann man ja erstmal mit deren RAM starten und erweitern, wenns nicht reichen sollte...

    Könnte man natürlich schon machen.


    Andererseits gibt es eine funktionierende Lösung auf Atmel AVR.

    Der Atmega kann von Haus aus mit 5V.

    Er ist robust, einfach, preisgünstig, kann direkt alles treiben, braucht wenig Strom, ist erhältich ...


    Eigentlich die beste Lösung.


    Entweder EINE Bridge ...

    ... oder wirklich in jedes Gerät einen Atmel, der das Gerät Multiprotokoll-fähig macht. :)

  • 1:1 aussah

    tja, so kann man sich irren.


    Könnte mir vorstellen, dass du bei weiterdrehenden Weltkugeln in einem Retro-Forum eher nicht so gut aufgehoben bist.

    Hmm, das ist jetzt eine hochphilosophische Sache:


    DU schreibst, Du hättest es NICHT 1:1 gemacht, aber gleichzeitig wirfst Du MIR vor, ich wäre in nem Retro-Forum nicht so gut aufgehoben, WEIL ich auch zeitgemäße Änderungen gut heisse...


    Was heisst das jetzt im Umkehrschluss für Dich selbst?


    Grübel grübel und studier....:whistling:

    (... um Thomas Spitzer von der EAV, den einzigen von mir verehrten Österreichern mal zu zitieren)


    Wobei ich -OT hier- speziell den C64 gar nicht so als Retro einstufe, der war ja IMMER da und nie wirklich weg, im Gegensatz zu anderen Plattformen, die heute gänzlich von der allgemeinen öffentlichen Wahrnehmung her verschwunden sind...


    WOT: Ist so ähnlich, wie ich mich auch lange sehr schwertat, den VW-Käfer oder Renault4 oder Citroen 2CV als Oldtimer wahrzunehmen und es mir heute mit VW-Golf I oder gar Golf II wieder so geht...

  • DU schreibst, Du hättest es NICHT 1:1 gemacht

    Doch :D Hab ich mal - was ich dann daraus mache bleibt ja mir überlassen. Die Nicht-Original-Blaupausen bestehen aber noch immer.


    Grübel grübel und studier....

    ersteres tue ich noch immer, das andere hab ich hinter mir - jedenfalls offiziell.

  • ... oder wirklich in jedes Gerät einen Atmel, der das Gerät Multiprotokoll-fähig macht. :)

    Da bin ich ganz bei Dir!


    Aber kann die Lösung von NLQ inzwischen die Konstellation Master Parallel Slave seriell

    a) überhaupt? und

    b) Jiffy-Dos beschleunigt?


    Denn ansonsten macht ne 1581 an nem großen CBM keinen Spass im Vergleich zur SFD1001 /8250[lp]


    Wobei es mir offen gesprochen aber sogar mehr um die Drucker- und Messgeräteunterstützung in beide Richtungen geht, um vielleicht entweder den SX64 auch dafür zu verwenden und den 8296 samt SFDs zu verkaufen, so lange die noch so hoch gehandelt werden oder eben aus dem R&S PUC, den ich kürzlich günstig erstehen konnte einen 8xxx-"Portable" zu bauen und damit dann die ganze Messtechnik ausschliesslich zu steuern und auch den SX64 -schweren Herzens nach 36 Jahren- aber aufgrund der aktuellen Tarife eben abzustoßen, nachdem meine Kids allesamt KEIN Interesse an jeglicher IT haben, die mehr wiegt oder komplizierter zu bedienen ist als ein iphone/pad...


    Der VC20 war mein allererster eigener Rechner und hat somit Bestandsschutz, den würde ich mir auch ohne Goldlack notfalls an die Wand hängen ;-)

  • Für die großen CBMs gäbe es natürlich auch die Möglicheit, die relativ kleine PCB dort noch intern mit einzubauen und dann gleich einen seriellen IEC am Gerät zu haben

    Oja, diese Idee ist sehr reizvoll.

    Eine Multiprotokoll 8250 Floppy wär schon was! :)

    Jetzt nicht ernsthaft, oder? X/

  • Aber kann die Lösung von NLQ inzwischen die Konstellation Master Parallel Slave seriell

    Ich hab es mir noch nicht genau angesehen was das NLQ Teil kann oder nicht kann.



    Was IEEE-488 Slave angeht, da habe ich vor Jahren schon mal experimentiert.


    Mein Problem war, soweit ich mich erinnere, das der 16MHz Atmega etwas zu langsam war, auf das ATN Signal zu reagieren.

    Zumindest im PIN Interrupt, denn C hatt da ziemlich Overhead, weil es alle Register auf den Stack schmeisst.


    Ich hab damals ins Schaltbild geguckt und gesehen, dass die Floppys ein <Exklusiv ODER> benutzen, damit NRFD low geht im selben Moment wie ATN low geht.

    Mit entsprechender Schaltung hat es dann auch am ATmega tadellos funktioniert.


    Lustig dabei ist, bei der 1541 ist es ja nicht ganz so zeitkritisch, der C64 erwartet erst nach einer Millisekunde eine Reaktion auf ATN.

    Aber die neueren 1541 mit der größeren PLA, die machen auch ein EX-OR und reagieren so schon von der Hardware her auf ATN.

  • Weils so lahm ist. Naja, vielleicht mit integriertem JiffyDOS. :D


    Ich habe neulich eine 1581 Disk über XoomFloppy im Standardmodus gelesen um ein Image zu erstellen. 30 Minuten! :/

    Naja gegen ein Dual Prozessor System wie die 8250 ist jede 1571 oder 1581 eine lahme Ente.

    Aber Jiffy DOS relativiert es wieder etwas.



    Natürlich ist eine Jiffy 1581 an einem PET nicht so schnell wie eine 8050.

    Aber zum laden von Programmen oder zum transferieren von ein paar Dateien wird es schon reichen.


    Den Gedanken ein 3,5" Floppy an meinem 8296 zu haben, den finde ich schon sehr reizvoll.


    Es würden ja auch REL Dateien gehen und prinzipiell auch Datenbank Programme und dergleichen.

  • Ich habe neulich eine 1581 Disk über XoomFloppy im Standardmodus gelesen um ein Image zu erstellen. 30 Minuten! :/

    Umgekehrt, eine 8050 Dual Drive an meinem C64, auch sehr reizvoll.


    Das läuft zwar nicht so schnell wie am PET, aber wenn es so schnell läuft wie eine Jiffy Floppy, dann reicht mir das vollauf.

  • Naja gegen ein Dual Prozessor System wie die 8250 ist jede 1571 oder 1581 eine lahme Ente.

    Aber Jiffy DOS relativiert es wieder etwas.

    Ihr dürft nicht vergessen, dass die 1581 (und 1571 im CP/M mode) durch einen dedizierten FDC unterstützt werden, der gleicht das vermutlich locker wieder aus,

    zudem sind die 3.5" LW von der Mechanik her deutlich flotter, d.h. beim Spurwechsel.


    Also ich würde da nicht auf die 8250 (insb. ohne LP) wetten wollen gegen eine 1581 mit Jiffy-Dos und optimierter IEEE-Bridge, aber vielleicht können wir das ja bald

    ausprobieren 8)

  • Naja gegen ein Dual Prozessor System wie die 8250 ist jede 1571 oder 1581 eine lahme Ente.

    Eine 8250 sieht auch sehr mächtig aus und funktioniert im Winter als eine Heizung.


    Aber es ist praktisch, eine 1571 und eine 8250 / SFD-1001 zusammen zu haben. Mit diesen zwei Laufwerken kann man jedes 5,25" CBM-Diskettenformat lesen.