C= IEEE488 Interface Replik?

Es gibt 19 Antworten in diesem Thema, welches 2.908 mal aufgerufen wurde. Der letzte Beitrag (16. April 2021 um 21:02) ist von x1541.

  • Moin moin!

    Heute kam (m)ein zweites Exemplar des relativ seltenenen IEEE488 Interface von Commodore bei mir an!

    (Welches mir RETRONER freundlicherweise verkauft hat)

    Bitte melde dich an, um diesen Anhang zu sehen.

    Nachdem hier nun zwei lagen, kam sogleich die Frage von toms01 ob er eine Replik bauen soll!?

    Bitte melde dich an, um diesen Anhang zu sehen. - Bitte melde dich an, um diesen Anhang zu sehen.

    Da mein erstes Exemplar eine kleine Macke am Gehäuse hat, würde ich es opfern.

    Deshalb die Frage: Besteht Interesse?

  • Deshalb die Frage: Besteht Interesse?

    Klar, warum nicht!
    Allerdings wäre dazu, wie bei den CMD Replika's von toms01, ein Gehäuse auch cool. :smile:

    10 GOTO Lesezeichen im Profil
    20 READ Lesezeichen im Profil
    30 PRINT Lesezeichen aus Profil
    40 POKE 198,0: WAIT 198,1

  • würde ich es opfern.

    ich glaube hier muss nichts geopfert werden - die Bauteile müssen nur "kurz umziehen", danach gehts wieder an die Originalschauplätze.

    ?SYNTAX ERROR
    READY.
    Bitte melde dich an, um dieses Bild zu sehen.

    Letzte Projekte:

    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

  • ein Gehäuse

    das wäre dann aber nur ein Blechgehäuse (wohl ähnlich RAMlink) oder irgendwas aus Plexiglas.

    ?SYNTAX ERROR
    READY.
    Bitte melde dich an, um dieses Bild zu sehen.

    Letzte Projekte:

    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

  • Das IEEE Interface von Commodore hat zwar ein nettes Gehäuse, aber das Interface selber ist wenig kompatibel. Es blendet ein eigenes EPROM im Speicherbereich ein. Da aber recht viele Programme sich darauf verlassen, den RAM-Speicher nach Gutdünken über die PLA umzuschalten und zu benutzen, sind die Routinen sehr bald abgehängt. Sprich: Damit läuft nicht viel. das war auch schon vor 35 Jahren so.

    Deswegen haben wir in Studententagen für ale drei Varianten der IEEE Interfaces stets einen "internen" Kernal mit den notwendigen Anpassungen verwendet. Und alle drei Varianten (6522, 6526 und 8255, letzteres auch für den 128er) sind ja inzwischen hier veröffentlicht und nachgebaut worden.

  • Das IEEE Interface von Commodore hat zwar ein nettes Gehäuse, aber das Interface selber ist wenig kompatibel. Es blendet ein eigenes EPROM im Speicherbereich ein. Da aber recht viele Programme sich darauf verlassen, den RAM-Speicher nach Gutdünken über die PLA umzuschalten und zu benutzen, sind die Routinen sehr bald abgehängt. Sprich: Damit läuft nicht viel. das war auch schon vor 35 Jahren so.

    Deswegen haben wir in Studententagen für ale drei Varianten der IEEE Interfaces stets einen "internen" Kernal mit den notwendigen Anpassungen verwendet. Und alle drei Varianten (6522, 6526 und 8255, letzteres auch für den 128er) sind ja inzwischen hier veröffentlicht und nachgebaut worden.

    Ja... ich denke es geht auch mehr darum dieses IF zu haben.

  • ich habe immer nur das Interface von Asklia genutzt. Perfekt im Kernal integriert. Kann mich noch gut dran erinnern wie ich in jungen Jahren mit dem c't listing am Hexeditor sass, um das ROM zu patchen ... Da war EPROM Brennen noch was besonderes, und ich war privilegiert eine entsprechend ausgestattete Werkstatt in der Bekanntschaft zu haben.

    Hab zwar inzwischen auch ein Technofor Interface und das von Jann, sowie das von Commodore zum VC20, aber genutzt hab ich die nie für irgendwas...

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • ich habe immer nur das Interface von Asklia genutzt.

    Beschreibt Bitte melde dich an, um diesen Link zu sehen. das Cartridge? Das Cartridge ist mir neu, aber ich möchte es ausprobieren.

    Ich habe ein BusCard II Cartridge. Es ist ziemlich gut, und man kann IEC und IEEE-488 gleichzeitig benutzen. Leider ist es wirklich langsam, weil es nicht mit JiffyDOS zusammen funktioniert. Ich habe auch versucht, das Interpod zu benutzen. Das war schneller, weil ich JiffyDOS benutzen konnte. Ich fand jedoch, dass das Interpod nicht so zuverlässig ist. Ich suche eine Lösung, die zuverlässig und kompatibel mit JiffyDOS ist.

  • Hallo

    Ja. der Thread wäre der richtige. Ich habe dieses Interface mit einem Portbaustein 6522 zu C64 Zeiten mit einem Kollegen entwickelt. Im Kernal haben wirdie Routinen für den Kassettenport entfernt, um Platz zu gewinnen. Zusätzlich, weil es das damals gab, sind die kompatible Routinen für das parallele Speeddos enthalten.

    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.

    Und jede Lösung mit einem externen EPROM wird bei jedem zweiten Programm abgehängt: Damit laufen dann weder CP/M noch Wolfenstein :wink:

  • 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.

    CMD ist nicht ganz so mein Ding, um ehrlich zu sein

    Klang damals als du dich noch roby1111 genannt hast ganz anders. Ich warte noch auf deine Version FD. Angekündigt war sie ja.

    ?SYNTAX ERROR
    READY.
    Bitte melde dich an, um dieses Bild zu sehen.

    Letzte Projekte:

    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

  • Naja, ob das jetzt wirklich noch alles zum ersten Beitrag von androSID, zu seiner IEEE488 Interface Commodore Replik dazupasst?? Vielleicht sollte man das ganze andere "IEEE488 Brainstorming" hier rausnehmen... Ist ja dann keine "echte" Replik mehr. :wink:

    :zzt:

    10 GOTO Lesezeichen im Profil
    20 READ Lesezeichen im Profil
    30 PRINT Lesezeichen aus Profil
    40 POKE 198,0: WAIT 198,1

  • Ja. der Thread wäre der richtige. Ich habe dieses Interface mit einem Portbaustein 6522 zu C64 Zeiten mit einem Kollegen entwickelt. Im Kernal haben wirdie Routinen für den Kassettenport entfernt, um Platz zu gewinnen. Zusätzlich, weil es das damals gab, sind die kompatible Routinen für das parallele Speeddos enthalten.

    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.

    Und jede Lösung mit einem externen EPROM wird bei jedem zweiten Programm abgehängt: Damit laufen dann weder CP/M noch Wolfenstein :wink:

    Danke für die Infos. Euer Interface sieht schön aus. Im Fall von einem externen EPROM und CP/M könnte man die Bitte melde dich an, um diesen Link zu sehen. benutzen. :wink: Es wäre nur nötig, ein kleines (2K) PET-Terminalprogramm zu portieren. Lustigerweise würde die SoftBox immer noch nicht mit dem BusCard II funktionieren, weil man die Signale des IEEE-488-Datenbusses nicht Bitte melde dich an, um diesen Link zu sehen. kann. Die SoftBox würde auch nicht mit eurem Interface funktionieren, weil die 7516x Chips das gleiche Problem haben. Ich möchte das Protokoll der SoftBox ändern, um dieses Problem zu vermeiden.

  • Danke für die Infos. Euer Interface sieht schön aus. Im Fall von einem externen EPROM und CP/M könnte man die Bitte melde dich an, um diesen Link zu sehen. benutzen. :wink: Es wäre nur nötig, ein kleines (2K) PET-Terminalprogramm zu portieren. Lustigerweise würde die SoftBox immer noch nicht mit dem BusCard II funktionieren, weil man die Signale des IEEE-488-Datenbusses nicht Bitte melde dich an, um diesen Link zu sehen. kann. Die SoftBox würde auch nicht mit eurem Interface funktionieren, weil die 7516x Chips das gleiche Problem haben. Ich möchte das Protokoll der SoftBox ändern, um dieses Problem zu vermeiden.

    Nun, ein brauchbares CP/M (sogar mit einem 8 MHz Z80) für den C64 gibt es ja bereits; auch als Nachbau. Da wäre es doch ein zu grosser Aufwand, einen C64 (zudem mit 40 Zeichen) als Terminal für einen externen vollständigen Z80 Computer zu verwenden. Eine Z-Maker für einen 8032 würde mich allerdings interessieren :smile:

    Eigentlich habe das nur erwähnt, weil CP/M damals einer der Prüfsteine für jede Hardware-Erweiterung wie etwa einen IEEE Bus für den C64 war. Die "grossen" Laufwerke SFD1001/8250 haben wir damals in das BIOS eingebunden; die waren ebenso nutztbar wie die kleine 1541. Damals allerdings nur mit Speeddos; Jiffdos ist ja ungleich jünger.

    Und Wolfenstein ist auch ein spezielles (Test-) Programm: Es verwendet als eines der wenigen Programme REL Files auf der Floppy.

  • Deswegen haben wir in Studententagen für ale drei Varianten der IEEE Interfaces stets einen "internen" Kernal mit den notwendigen Anpassungen verwendet. Und alle drei Varianten (6522, 6526 und 8255, letzteres auch für den 128er) sind ja inzwischen hier veröffentlicht und nachgebaut worden.

    Da Versionen von eurem Kernal für verschiedene I/O-Chips schon existiert, fällt es mir ein, dass ihr Unterstützung für den 6525-TPI im IEEE-488-Cartridge von CBM hinzufügen könntet. Der 6525-TPI ist Bitte melde dich an, um diesen Link zu sehen.. Man könnte den ROM-Sockel im Cartridge leer lassen.

    Die Replik hätte dann zwei Optionen. Man könnte das Cartridge mit dem ursprünglichen ROM von CBM (rein / historisch) benutzen oder mit eurem Kernal im Rechner (kompatibler / nützlicher) benutzen.

  • Nun, da muss ich alle enttäuschen: Ich habe vor 35 Jahren die Hardware gemacht; ein Kollege die software. Leider war der etwas "speziell" wie alle guten Programmierer und hat den Source Code nie herausgerückt. Leider hat er schon lange keine Bindungen mehr zu den Homecomputern; und auch seine alten Disketten sind entsorgt. Es gibt nur noch die fertigen Eproms mit den passenden Kernals.

    Ich bezweifle aber auch, dass sich dieser Aufwand lohnen würde: Wer wirklich einen IEEE Bus mit Kernal-unterstützung haben möchte, nimmt einfach eined er drei Varianten. Oder den lustigen IEC-IEEE Adapter; auch wenn der auf der IEEE Seite keinerlei passende Bus-Treiber hat.

  • gibt es denn einen Schaltplan von der Commodore Cartridge?

    Zumindest von der 6526 Version ist ein kommentiertes Disassembly in der c't abgedruckt. Da hatte ich den hex Code doch draus abgetippt.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • 6526: Ja, aber da fehlen leider all die guten Bequemlichkeiten: Funktionstastenbelegung mit Floppykommandos (ähnlich wie bei den anderen Speedern), Speeddos (immerhin besser als nichts), Drucken am Userport.

    Immerhin: Für die Abänderung auf einen 6525 könnte man es gebrauchen. Den Schaltplan findet man oben im Link.

  • offenbar hat sich André Fachat schon um ein Kernal gekümmert, wie im Readme zum Schaltplan zu lesen ist:

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN