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

Zitat von Cyberdyne

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!

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?

Ist doch verblüffend, dass es von Commodore ein eigenes Modul gab, und trotzdem soviele Alternativen von Drittanbietern?

Waren die um sovieles besser oder billiger?

Zitat von wfking

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

Zitat von NLQ

Hier ist mein Selbstbau-Adapter IEC2IEEE:
http://www.nlq.de

Dein Adapter beherrscht zusätzlich Jiffydos-Übertragungsart (schneller), und
eines deiner Programme
-reads the backside of a 1541 disk in a 1571 without flipping the disk
klingt trickreich . - Was war für dich der Grund, es mit dem Atmega 8515 zu realisieren, anstatt originalgetreu mit 6502 oder meinetwegen W65SC816 ?

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?

Zitat von mc71

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.

Zitat von DD4DA

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?

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.