Hello, Guest the thread was called6.6k times and contains 41 replays

last post from skern at the

IEEE-488 Cartridges für Commodore-Geräte C64 und VC 20 mit seriellem Bus (IEC), wie verbreitet, Unterschiede und Gemeinsames?

  • Hallo,
    ich habe mal im Forum gesucht und folgendes gefunden:
    IEEE-488 Modul von Data Becker
    IEEE-488 Module von Jann Datentechnik und Rex Datentechnik


    Rex IEC64 Modul und 4 Games Spielemodul von Chart Elektronik?


    Hellmut Landolt IEC Modul: IEEE-488?


    WAW-Elektronik IEEE-488 Interface


    IEEE-Interface von REX Datentechnik
    IEC 64 und SFD 1001


    Einzelne Module scheinen untereinander baugleich zu sein.



    Laut englischer Wikipedia soll es auch ein "VC 40" genanntes sehr einfach , luftig designtes Interface eines Drittanbieters gegeben haben.
    Desweiteren ein Commodore-eignes Cartridge für den VC 20, mit Namen VIC-1112 ebenfalls recht schlicht. (Original ist in meinen Augen besonders interessant .. leider nicht für C64, aber vielleicht anpassbar?)



    Nun frage ich mich, hat es Geräte gegeben die besonders universell verwendbar waren, wenig in den Rechner eingegriffen haben, besonders kompatibel waren, oder im Gegenteil besonders elaboriert, aber so "gut" dass sie einen Quasi-Standard gesetzt haben?



    Wie sind eure Erfahrungen? was hat sich damals "durchgesetzt" in diesem Bereich?


    vielen Dank und beste Grüße :)

  • Ich hab das hier:
    http://www.nightfallcrew.com/1…re-64-ieee-488-cartridge/


    Da ich nur dieses Modul habe, kann ich keinen Vergleich machen.

    Nun gut, ein Anfang ist gemacht! :thumbsup:


    Du könntest vielleicht deine Erfahrungen schildern:


    - hast du es, um bestimmte Commodore-Formate lesen zu können (z.b. 8050 mit 77 Spuren statt 35), oder mehr aus Geschwindigkeitsgründen ? oder gar um GPIB-Meßgeräte anschließen zu können?
    - fügt sich das Modul nahtlos in deine Arbeitsabläufe ein?
    - funktioniert es bestimmungsgemäss, ohne Aussetzer und Wackelkontakte?
    - ersetzt es das interne Kernel-ROM oder modifiziert es selbiges bei / durch umkopieren ins RAM oder ist es komplett eine BASIC-Erweiterung im Modulschacht (EXROM..) ?
    - ist der Geschwindigkeitszuwachs merklich bzw. ausreichend, so dass man kein Bedürfnis nach einem Speeder hat?

  • Ich hab das hier:
    nightfallcrew.com/19/08/2012/c…re-64-ieee-488-cartridge/

    Das müsste das Commodore-eigene Modul sein, dass im "SFD 1002"-Bundle enthalten war. Lt. 64'er (Ausgab-Nr. hab ich gerade nicht zur Hand) wurde die IEEE-Floppy SFD 1001 unter dem Namen SFD 1002 als Bundle mit diesem Modul für den Anschluss an den C64 verkauft. Wenn das stimmt, dann ist der Wikipedia-Text zur SFD 1002 falsch. Dort heisst es, die SFD-1002 habe einen CBM-Bus gehabt und wäre direkt an den C64 anschließbar gewesen: https://de.wikipedia.org/wiki/Commodore_SFD1002

  • Das müsste das Commodore-eigene Modul sein, dass im "SFD 1002"-Bundle enthalten war. Lt. 64'er (Ausgab-Nr. hab ich gerade nicht zur Hand) wurde die IEEE-Floppy SFD 1001 unter dem Namen SFD 1002 als Bundle mit diesem Modul für den Anschluss an den C64 verkauft.

    64'er Ausgabe 09/84, Seite 8.

  • Sehr interessant ist auch das Interpod IEEE-488 Interface, siehe:


    http://mikenaberezny.com/hardw…erpod-ieee-488-interface/


    Dies ist kein Modul für den Expansionport, sondern eine Converterbox von IEEE488 auf serielle IEC-Signale. Dadurch zwar langsamer, aber sehr kompatibel, da im C64 keine extra Software benötigt wird.

    Ein dicker Pluspunkt ist sicher das Konzept.


    Ein weiterer der Zusatznutzen mit der seriellen Schnittstelle (in Hardware, 6850 Chip) für einen entsprechenden Drucker.


    Mike Naberezny vermisst die "umgekehrte" Wandlerfunktionalität. (IEEE -> IEC) Für Betrieb eines PET mit Schnarchfloppys ;)


    Wermutstropfen sicher die Geschwindigkeit, aber wenn man hauptsächlich vom langsamen aufs schnelle Drive umkopiert und in Anbetracht der intendierten Nutzung, sind die Abstriche gerechtfertigt.


    Der Aufwand ist freilich hoch: an Komplexität wird ein kompletter VC 20 erreicht (nur RAM und ROM ist weniger drin.)

  • Desweiteren ein Commodore-eignes Cartridge für den VC 20, mit Namen VIC-1112 ebenfalls recht schlicht. (Original ist in meinen Augen besonders interessant .. leider nicht für C64, aber vielleicht anpassbar?)

    Das ist ein reines VC-20 Modul, womit man IEEE 488-Geräte betreiben kann. Ohne Modulbox oder Expansionsportverteiler relativ sinnlos, denn nur mit dem Modul und 5 KB Grundversionsspeicher kommt man nicht wirklich weit.

    Sehr interessant ist auch das Interpod IEEE-488 Interface, siehe:


    http://mikenaberezny.com/hardw…erpod-ieee-488-interface/


    Dies ist kein Modul für den Expansionport, sondern eine Converterbox von IEEE488 auf serielle IEC-Signale. Dadurch zwar langsamer, aber sehr kompatibel, da im C64 keine extra Software benötigt wird.

    Das Interpod funktioniert an jedem Rechner mit seriellem Bus. Hatte früher mal eines und es am Plus/4 angeschlossen - funktionierte einwandfrei.

  • Was war für dich der Grund, es mit dem Atmega 8515 zu realisieren, anstatt originalgetreu mit 6502 oder meinetwegen W65SC816 ? ;)

    Der ATMEGA ist ein Mikrocontroller. D.h. er enthält einen Mikroprozessor, Ein-Ausgangschips, RAM, (FLASH-) ROM, Oszillator... in einem Chip. Der 6502 ist nur ein Mikroprozessor, somit müssten die anderen Funktionen aufwändig mit zusätzlichen Chips gemacht werden. Es ist halt von der Hardware viel einfacher.
    (Der 8515 wird nicht mehr hergestellt; man muss jetzt einen 162 (mit angepasster Firmware) benutzen.)

  • Nun ja, theoretisch kann man auch mit einem (=1 Stück) 6510 und einem (=1 Stück) 6532 RRIOT-Chip ein komplettes Microcontroller-System aufbauen, mit RAM, ROM , Timer und jeder Menge Port-Pins ;-)


    Gut dass du nochmal schreibst! Was mich interessieren würde: ist dein IEEE-Interface beim Lesen und Schreiben von und zur Floppy (z.B 4040 oder 8050) merklich schneller als eine 1541? wenn ja wie schnell?

  • Im 6532 ist ein ROM, und der 6530 war maskenprogrammiert- was sich nur in größeren Stückzahlen lohnt und schwierig wird, wenn der Hersteller vor über zwanzig Jahren ohne Nachfolge untergegangen ist.

    Hast ja recht!
    Ich schrieb ja auch nur "theoretisch". "Praktisch" wäre es aber auch denkbar, für so ein Interface andere, primitivere Prozessoren ( Controller) einzusetzen, z.b. aus der 6502 / 6504-Familie. Oder ein winziger PIC, oder ein 8051 (mit Eprom) oder ein 8048-Derivat ...


    So ein Atmega o.ä. scheint mir "unterfordert" oder auch "an diese Aufgabe verschwendet" zu sein.

  • Der Einsatz eines Mikrocontrollers als IEEE488 <> Seriell-IEC ist nicht nur machbar sondern wurde auch schon gemacht. Leider findet man diese Nischenprodukte, die zusätzlich nur in sehr kleiner Stückzahl produziert wurden, heute kaum noch. Der Markt war nicht sehr groß,daher selten verkauft. Ich erinnere mich, dass zu Zeiten von Mailboxen und Modems / Akustikkopplern (und freiem Internet) der Trend zur SFD1001 ging, da sie mehr Speicherplatz hatte und schneller war. Am C64 wurden dafür genau diese Interfaces verwendet. Rex-Datentechnik verkaufte sowas und der Hagener Hersteller des "DELA" Eprommers hatte sowas auch mal im Programm. Ich habe sowas jedoch schon sehr sehr sehr lange nicht mehr in der Hand gehabt - genauso lange nicht, wie eine Z80 Karte mit einem CP/M 2.2 oder einer 40/80 Zeichenkarte.
    Der IEEE488 (HP-IB) Bus ist kein Hexenwerk und gut dokumentiert ist. Es sollte also mit einem ARM Cortex-M und ein paar bidirektionalen Bustreibern als Open-Collector Variante und etwas Software möglich sein, diese Aufgabe zuverlässig zu lösen. Mir fällt spontan dazu ein STM32F1 Nucleo Board ein, welches für unter 10 Euronen mit einem Jtag ,viel I/O und breiter Software-Untertützung aus dem GNU-Pool daher kommt.
    Die Bustreiber sind handelsüblich und können moderne varianten sein. Der IEEE488 Bus ist in der Messtechnik weiter verbreitet und dass schon sehr lange daher gibt es diese treiber auch heuter noch gut und günstig. Die Software ist zum Teil auch schon verfügbar - der serielle Bus wird ja bereits beim SD2IEC Projekt genutzt und dessen Firmware ist dank CMSIS-Support recht gut als Ausgangsbasis nutzbar.
    Einen diskreter Wandler der sich transparent einfügt, wäre sicherlich besser als jedes Einsteckmodul und angesichts der Aussichtslosigkeit der Beschaffung eines alten Originals sicherlich eine lösbare Aufgabe.
    Ich habe mir vor Jahren mal ein USB-IEEE488 Konverter gebaut und auch programmiert und kann sagen dass dies Ding mich fast 6 Monate beschäftige. Die Tücke steckte im USB-Bus - der IEEE488 war eigentlich recht entspannend zu programmieren.

  • Der Einsatz eines Mikrocontrollers als IEEE488 <> Seriell-IEC ist nicht nur machbar sondern wurde auch schon gemacht. Leider findet man diese Nischenprodukte, die zusätzlich nur in sehr kleiner Stückzahl produziert wurden, heute kaum noch. Der Markt war nicht sehr groß,daher selten verkauft. Ich erinnere mich, dass zu Zeiten von Mailboxen und Modems / Akustikkopplern (und freiem Internet) der Trend zur SFD1001 ging, da sie mehr Speicherplatz hatte und schneller war. Am C64 wurden dafür genau diese Interfaces verwendet. Rex-Datentechnik verkaufte sowas und der Hagener Hersteller des "DELA" Eprommers hatte sowas auch mal im Programm. Ich habe sowas jedoch schon sehr sehr sehr lange nicht mehr in der Hand gehabt - genauso lange nicht, wie eine Z80 Karte mit einem CP/M 2.2 oder einer 40/80 Zeichenkarte.
    Der IEEE488 (HP-IB) Bus ist kein Hexenwerk und gut dokumentiert ist. Es sollte also mit einem ARM Cortex-M und ein paar bidirektionalen Bustreibern als Open-Collector Variante und etwas Software möglich sein, diese Aufgabe zuverlässig zu lösen. Mir fällt spontan dazu ein STM32F1 Nucleo Board ein, welches für unter 10 Euronen mit einem Jtag ,viel I/O und breiter Software-Untertützung aus dem GNU-Pool daher kommt.
    Die Bustreiber sind handelsüblich und können moderne varianten sein. Der IEEE488 Bus ist in der Messtechnik weiter verbreitet und dass schon sehr lange daher gibt es diese treiber auch heuter noch gut und günstig. Die Software ist zum Teil auch schon verfügbar - der serielle Bus wird ja bereits beim SD2IEC Projekt genutzt und dessen Firmware ist dank CMSIS-Support recht gut als Ausgangsbasis nutzbar.
    Einen diskreter Wandler der sich transparent einfügt, wäre sicherlich besser als jedes Einsteckmodul und angesichts der Aussichtslosigkeit der Beschaffung eines alten Originals sicherlich eine lösbare Aufgabe.
    Ich habe mir vor Jahren mal ein USB-IEEE488 Konverter gebaut und auch programmiert und kann sagen dass dies Ding mich fast 6 Monate beschäftige. Die Tücke steckte im USB-Bus - der IEEE488 war eigentlich recht entspannend zu programmieren.

    Vielen Dank für deine kenntnisreichen Ausführungen!


    Wenn beim ARM Cortex (der hat eine 32 bittige Multipliziereinheit - wird das für IEEE gebraucht?) OpenCollector reicht dann wären es ja normale 74LS xxx - Bustransceiver mit Treibern im 7406-Stil -


    warum sieht man aber so viele IEEE-Lösungen die mit speziellen GPIB-Treibern daherkommen?

  • Weil man ohne die IEEE488-Treiber direkt am Mikrocontroller-Port oder TTL-ICs die Bus-Specs nicht einhalten kann. Das funktioniert zwar an kleinen Bussen problemlos (2-3 Geräte am Bus), wenn aber die maximale Leitungslänge und die maximalle Teilnehmerzahl am Bus ist, braucht man Treiberleistung. Außerdem ist der IEEE-Bus von den Reaktionszeiten eines Steuersignals her sehr zeitkritisch, daher wird meist der NEC Buscontroller eingesetzt, dann fallen Interrupt-Latenzzeiten etc. nicht ins Gewicht.

  • Die von dir zu recht erwähnten Specs sind ja modularisiert.
    Die Firmware der PET 2001 (3016.. 8032 .. 8096) Geräte ist ja daraufhin ausgelegt bzw. macht davon regen Gebrauch, nur ein "Subset" von Komponenten des GPIB-Bus zu realisieren.


    Z.b. können laut Specs in der Maximalversion IIRC bis zu 31 Geräte am Bus (exkl. Controller) angeschlossen sein.
    Die Primäradressen des PET sind aber auf 16 begrenzt, gemäss Basic 2.
    Davon wiederum sind die Adressen 0..3 für interne Zwecke umgewidmet, es verbleiben 12.
    Diese wiederum sind aber durch gewisse Systemgeräte die nicht beliebig umkonfiguriert werden können sondern zum Teil nur Schiebe-Schalter oder Mäuseklaviere haben, in Gruppen unterteilt.


    Zwischen Geräten dieser verschiedenen Gruppen können Primäradressen nicht beliebig umgewidmet oder verschoben werden. Dies schränkt die Zahl der verwendbaren Geräte weiter ein.


    So kann ein Drucker vielleicht von PA 4 auf 5 umgelegt werden, nicht aber auf 8..11 denn das sind üblicherweise Floppys. Genauso ein Plotter auf PA 6 (jedenfalls der 1520 am seriellen Pendant).


    Man könnte da von folgenden 4 Gruppen ausgehen:
    - Drucker: PA 4 und 5
    - Plotter: PA 6 und 7
    - Laufwerke: PA 8 , 9, 10 und 11
    - sonstige Geräte: PA 12 - 15


    Wenn man davon ausgeht, dass von jeder Gruppe nur 1 bis 2 Geräte anschließbar sind, dann sind in der Realität nur fünf bis maximal sechs Geräte insgesamt zu erwarten, die simultan an einem PET angeschlossen sind.


    Es würde also das Design vereinfachen, wenn man nicht die volle Treiberleistung installiert, wenn die von den Primäradressen her eh nicht ausgeschöpft werden kann.


    Es sei denn, jemand möchte eine komplette Roboterisierte Fertigungsstraße in der Industrie mit einem C64 steuern, wer weiß !? ;-)


    Im übrigen gibt es auch eine "schnelle" Version des GPIB mit Totem-Pole-Treibern, wo IMHO bei gewissen Geräten weniger , andere oder schwächere oder keine Terminierungswiderstände eingesetzt werden. Auch dies mindert u.U. den Bedarf an Treiberleistung bzw. Spezialtreibern.