Posts by mvcube

    Es kommt tatsächlich darauf an, was man machen möchte. Interaktive Programme in COBOL sehen halt aus wie typische Datenbank-Masken mit etlichen Feldern an festen Bildschirmpositionen. Um das auf einem C64 zu nutzen, benötigt man so etwas wie eine Terminalemulation. Das ist ziemlich sicher nicht Bestandteil der C64-COBOL-Umgebung.


    Sinnvoller kann da schon die sequentielle Dateiverarbeitung sein, also lese einen oder mehrere Datensätze aus einer Eingabedatei, tue wasauchimmer damit und gebe die Ergebnisse sequentiell als Datei oder Druckliste wieder aus. Weiter geht es dann mit dem nächsten Datenpaket bis alles verarbeitet ist. Das ist typische kommerzielle EDV. Die Daten könnte man mit einem BASIC-Programm als sequentielle DAtei erzeugt haben.

    Ich, Baujahr 1959 (oder soll ich sagen 59, passt irgendwie besser zum Y2K-Thema) habe einen nicht unerheblichen Teil meiner Karriere als Programmierer (passt irgendwie auch besser als 'Softwareentwickler') mit COBOL zugebracht. Die Plattform war damals TANDEM, später HP-NonStop. Eigentlich komme ich von BASIC, später FORTRAN (aus dem Mathestudium), ein wenig ALGOL und SIMULA (aus den Informatikvorlesungen, alles auf Lochkarten). Später habe ich mir dann Z80-Assembler und C beigebracht und in der Industrie damit Maschinensteuerungen entwickelt. Nun hatte der Job leider ein Verfallsdatum und ich sah mich gezwungen, als Selbständiger (damals noch mit einem 'st') in der Wirtschaft anzuheuern. Ich hatte gute Ideen, die Probleme des Kunden in C zu lösen, aber gegen 'Wir machen das in COBOL' kam ich nicht an. Also COBOL und Datenbanken lernen... Das PDF-Format war noch nicht erfunden oder zumindest noch nicht verbreitet, so war meine Literatur ein 1000seitiges Referenz-Handbuch in zwei Ordnern, das ausdrücklich nicht zum Erlernen der Sprache gedacht war. Aber was tut man nicht alles für Geld...


    Es gibt einen Grund, warum man so dicke Handbücher für COBOL braucht: Für alle Operationen, die in C oder Java durch irgendwelche Sonderzeichen beschrieben werden, existiert in COBOL ein 'Verb' also ein Befehl. Da kommen einige zusammen. Es sollte sich halt lesen wie eine Geschichte. Der Quelltext mit seinen DIVISIONs, SECTIONs und Kapiteln erinnert tatsächlich an Prosa. Das einzige Satzzeichen, an das ich mich erinnere, ist der Punkt. Aber dass Buchhalter und Manager je einen Blick in den Quellcode ihrer wichtigen Programme geworfen hätten, halte ich für unwahrscheinlich.


    COBOL85 kannte wenigstens schon IF THEN ELSE und COMPUTE. Allerdings sind lokale Variablen und Modularisierung Fremdworte. Viele COBOL-Programme sind große Monoliten. Ich selbst habe auch nur ein einziges COBOL-Programm geschrieben, danach nur noch Kopien davon gemacht. Der Grund ist, dass man eine feste Struktur einhalten muss, um ein gültiges COBOL-Programm zu erstellen. Da schreibt man sich die Finger wund, bevor man in der PROCEDURE DIVISION einen einzigen Befehl kodiert hat. Dazu kommt, dass bei den Kunden, in meinem Fall war das ein Einzelhandels-Filialunternehmen, eine gewisse Struktur der Prgramme vorgegeben ist. Kopieren ist da die einzige sinnvolle Möglichkeit, zu Ergebnissen zu kommen. Da Unterprogramme mit lokalen Datenbereichen genauso komplex zu erstellen sind, wie Hauptprogramme, haben sich die allermeisten Programmierer den Aufwand gespart, daher der Mangel an Modularisierung. Stattdessen werden üblicherweise sehr viele einzelne Programme gebaut, die dann ihren Teil der Datenverarbeitung übernehmen und untereinander über Dateien oder Datenbanken kommunizieren. Die HP-NonStop-Architektur unterstützt darüber hinaus eine Client/Server-Architektur, in der sich die Programme untereinander Messages schicken. Ich habe schon komplexe Anwedungen mit Tausenden einzelner Programme gesehen.


    Bei all dem Lamento, warum hat man sich das angetan? Hinter COBOL (und seinen Seelenverwandten wie der SAP-Prograammierumgebung ABAP) steckt eine bestimmte Denke, die ihren Ursprung in den festen Satzlängen der Lochkarte hat. Daten werden in Datensätzen organisiert, denen eine feste Struktur zugrunde liegt. Diese Struktur wird in den Programmen (und nicht in der Datenbank!) in Feldern fester Länge abgebildet. Aufgabe eines typischen COBOL-Batchprogrammes, also eines für die meist nächtliche Verarbeitung der Daten des Tages, ist, eine große Menge gleichartiger Datensätze einzulesen, zu bearbeiten, und in anderer Schüttung wieder auszuspucken. Das nächste Programm in der Kette übernimmt dann diese Daten und macht ihr Ding damit. Häufig sind noch SORT-Schrittte dazwischen eingestreut. So entsteht immer noch ein Großteil unserer Bankkontobewegungen. Bei interaktiven Programmen erfasst der Sachbearbeiter in einer oder mehreren Masken Daten, die dann wieder in eine feste Struktur gepackt werden und für die Verbeitung an einen Server (also ein COBOL-Programm mit einer Message-Schnittstelle) gesendet werden. Das bearbeitet und speichert dann den Datensatz und liefert in einer Antwortstruktur die Ergebnisse der Verarbeitung oder die angeforderten Daten zurück. Viele dieser Anwendungen sind Jahrzehnte im Einsatz. Und etliche COBOL-Enwickler alter Schule kennen auch nichts anderes.


    Bei einem meiner aktuellen SAP-Projekte ging es darum, eine alte COBOL-Anwendung zu analysieren, um sie in ABAP neu zu implementieren. Die Frage nach der Dokumentation der vorhandenen Anwendung wurde mit 'Frage mal den und den oder schaue in die Programme!' beantwortet. Um überhaupt eine Chance zu haben, habe ich mir dann in Java einen rudimentären COBOL-Parser gebaut, der die kompletten Quelltexte in eine verlinkte HTML-Dokumentation umgewandelt hat. Als ich das dann den bisherigen Entwicklern gezeigt habe, standen die Münder eine ganze Zeit lang offen. :O

    Danke an alle, die die Aktion ermöglicht haben! Mein C128toScart ist inzwischen aufgebaut und vollständig angeschlossen. Ich habe einen älteren 720p (HD Ready) TV von Panasonic angeschlossen und das Bild ist ziemlich gut. Ich nutze S-Video ohne Probleme. Einer der Vorteile älterer Geräte ist, dass sie über etliche Eingänge verfügen, die heute aus der Mode gekommen sind: 1 mal Component, 1 mal FBAS/S-Video umschaltbar, 2 mal Scart, davon einmal mit S-Video/FBAS alternativ, und 2 mal HDMI. Da kann man einiges gleichzeitig anschließen und bequem über die Fernbedienung auswählen. Ich könnte sogar den Antenneneingang für Geräte mit RF-Ausgang nutzen. Für den analogen Tuner wäre das die letzte mögliche Verwendung, denn analoges Fernsehen über Kabel oder Antenne ist ja längst Geschichte.


    Die Darstellung im 80-Zeichen-Modus ist ausgezeichnet. Der 40-Zeichen-Modus wirkt etwas pixelig, fast schachbrettartig bei manchen Farben, vermutlich weil der Bildschirm wesentlich schärfer und größer ist, als eine Röhre. Kein Flimmern, kein Wabern, nur einige "Jail Bars". Das gilt auch für einen direkt über S-Video angeschlossenen C16.


    Einer weiteren Sammelbestellung für die Schalterverlängerung würde ich mich anschließen.

    Entschuldigt die Einmischung aber als Mac-User muss ich mich auf Multi-User-OS-Seite schlagen. Das Problem wurde hier schon genannt: In modernen Betriebsystemen haben die Nutzer keine Schreibrechte im Applikationsverzeichnis. Daher ist es auch keine gute Idee, dort Konfigurationsinformationen abzulegen. Mac-OS verwaltet Anwendungen als sogenannte Bundles: Das sind Verzeichnisse, die aus Anwendersicht aussehen wie Dateien. Was darin abgelegt ist, ändert sich normalerweise nicht, es ist fester Bestandteil der Software. Daher kann ein Programm wie VICE dort auch keine Konfigurationsdateien ablegen. Daher gibt es globale und anwenderspezifische Konfigurationspfade. Die globalen Einstellungen gelten systemweit, die lokalen nur für den jeweiligen Anwender.


    Im Fall von VICE, das ein einzelner Anwender mit verschiedenen Konfigurationen starten will, ist vielleicht der Dokument-Ansatz die beste Lösung: Alle Einstellungen und Statusinformationen werden in einer Datei gespeichert, die mit der Anwendung VICE verknüpft wird, üblicherweise durch die Dateierweiterung. Diese Dateien kann dann jeder so verwalten, wie er es braucht. Also statt vice -config meine-konfiguration.ini lieber vice meine-konfiguration.vice. Die Dateien kann man dann auch gut auf die Anwendung werfen, eventuell sogar auf verschiedene Versionen derselben. In der Datei kann auch stehen, welches System (C64, VC20, PLUS4) emuliert wird. Die Anwendung würde sich dann den richtigen Emulator automatisch heraussuchen.


    P.S.: Zum Glück verteilen sich die Einstellungen nicht kreuz und quer in der Windows-Registry. Das wäre weitaus schlimmer.

    Inzwischen geht ein Board wieder. Offenbar war es nicht das RAM sondern einer der drei anderen Chips, eventuell eines der ROMs. Ob ich die defekte Platine je wieder ans Laufen bekomme, weiß ich noch nicht, vielleicht muss sie als Ersatzteilspender herhalten. Zumindest TED und CPU sind noch brauchbar.


    Derweil habe ich das (etwas ramponierte) zweite Gehäuse endgültig zur Emulationstastatur erklärt. Retropie auf meinem Raspi3 läuft auch schon. Ich arbeite noch an der perfekten Tastaturbelegung und denke über einen Einbau des Raspi in das Gehäuse nach. Ich mag die C16-Tastaturbelegung lieber als die von C64, weil sie vier Cursortasten hat.


    Die Bastelei macht auf jeden Fall großen Spaß.

    An meinem C64 habe ich auch schon im Modulator einen Kondensator abgezwickt. Ob es viel gebracht hat, kann ich nicht sagen. Mein kleiner Fernseher kann S-Video und das Signal ist Composite um Längen überlegen.


    Pech habe ich mit einem solchen Teil hier: S-Video to VGA Converter. Probiert habe ich ihn an einem VGA-Monitor und meinem C128D. Leider liefert er weder über Composite noch über S-Video ein Bild. Lediglich die Menüs und VGA-Pass-Through funktioniert. Ich muss den Konverter mal an einer anderen Signalquelle testen, vielleicht ist das Signal am C128 nicht ganz kompatibel. Hat da jemand Erfahrung mit? Ich hatte das Gehäuse auf, da ist genau ein IC drin (AV755B?, ich habe es leider nicht notiert.)

    Ich möchte mich hier mal kurz einschalten. Ich versuche gerade aus zwei defekten C16 einen funktionierenden zu machen. Das Gehäuse und die Tastatur des einen hat schon einen Keyrah-Adapter bekommen und soll noch mit einem RASPI 3 zu einem "virtuellen" C16 gemacht werden, aber aus den beiden Boards möchte ich auf jeden Fall ein funktionierendes machen. Bei einem ist der I/O-Chip vermutlich defekt. Den habe ich schon heraus operiert, will aber dasselbe nicht mit dem anderen Board machen, da ich befürchte, den Chip zu ruinieren. Jetzt der Grund, warum ich mich gerade hier einschalte: Bei dem Board mit dem heilen 6529B ist möglicherweise ein RAM defekt. Da kommt die Huckepackplatine von knusis gerade recht. Ich möchte so ein Ding gerne haben. Reicht das als offizielle Bestellung?

    Danke für dein Engagement. Ich habe inzwischen meinen C128 an einen alten Mitsubishi Multisync-Monitor angeschlossen, der neben RGB (CGA/EGA) auch Composite (PAL FBAS) unterstützt. Das Signal ist wirklich brauchbar. RGB ist gestochen scharf und der 40-Zeichen-Modus tut nicht weh. Aber der Monitor ist alt, schwer und ziemlich unhandlich. Ich freue mich daher schon auf deinen Konverter. Dann muss ich auch nicht mehr auf der Rückseite des Monitors nach dem Umschalter suchen.


    Problematisch wird es aber bei meinem C64 und beim C16: Deren Composite-Signal ist ziemlich schlecht. Um die beiden an einem modernen TV zu betreiben, benutze ich ein Scart-Kabel, das sowohl Composite als auch S-Video (Chroma/Luma) durchschleift. Letzteres ist deutlich besser als Composite. Allerdings ist es inzwischen sehr problematisch, Scart-Eingänge mit S-Video-Unterstützung zu finden. Auch der HD-Video-Converter mit Scart-Eingang (eBay 193385658105) ist auf Composite beschränkt.


    Ich besitze einen Grundig-TV (natürlich nur dem Namen nach ein Produkt der deutschen Traditionsmarke), bei dem sich der Scart-Eingang auf S-Video umstellen lässt. Der kommt dann auch auf meinen Computerbastelschreibtisch, obwohl er leider keinen VGA-Eingang besitzt, und wird mit der Box vom C128 versorgt werden. Für den Anschluss der anderen Commodores habe ich noch einen Scart-Umschalter in der Grabbelkiste.


    Meine anderen modernen TVs, auf denen Telefunken steht, genauso authentisch wie Grundig, erlauben leider keine Umschaltung auf S-Video. Es muss ja irgendwie möglich sein, aber die Schaltung wird wohl gerne eingespart, zumal Scart auch nur Composite und RGB wirklich fordert, S-Video ist optional. Daher war ich auf die Idee gekommen, ob man nicht innerhalb der Schaltung aus Chroma/Luma ein besseres Signal erzeugen kann als Composite und dieses auf den RGB-Kanälen ausgibt. Ich vermute, dass man dafür einen Custom-Chip braucht, der PAL (und eventuell NTSC) versteht. Ich fände das auf jeden Fall praktisch. Vielleicht wäre das ja eine Idee für Version 2.0.

    Die Idee mit dem Überspannungsschutz ist nicht schlecht, könnte gleichzeitig als Adapter dienen.


    Der leise Pfeifton nervt nur, Angst macht er mir nicht. Ich finde die neuen Netzteile aber sehr viel eleganter und die Schutzschaltung ist schon integriert.


    Gelöst hat sich an der Bodenplatte bestimmt nichts von selber, da hat sich jemand Zugang verschafft. Es klebt auch Isolierband an der Sicherung. Das Netzteil kommt in die Ersatzteilkiste.


    Für meinen C128 brauche ich kein neues Netzteil, höchstens einen leiseren Lüfter von Pabst. Ich habe einen Plastik-D. Die 3A an 5V des bestellten Netzteils liefern mir aber reichlich Reserve für alles mögliche. Ich sollte mir ein paar DIN-Stecker und Kupplungen für Experimente besorgen...

    Ich traue meinem Plus/4-Netzteil nicht. Die Bodenplatte wurde bereits geöffnet und die alten Klötze verbreiten ein unangenehmes Geräusch. Für meinen C64 habe ich mir daher bereits ein modernes Netzteil für ca. 45€ gekauft. Von dem war ich so überzeugt, dass ich für den Plus/4 auch eines haben wollte, natürlich mit eckigem Stecker.


    Jetzt das Problem: Das neue Netzteil ist für den C128. Der hat, wie ich inzwischen weiß, einen weiteren Pin in der Mitte, an dem die Wechselspannung anliegt. Dafür ist einer der äußeren Pins offenbar als Schutzerde beschaltet. Ich plane jetzt den Stecker passend zu modifizieren (mittleren Pin entfernen, äußeren anders beschalten). Hat jemand Erfahrung damit? Passt der Stecker dann überhaupt oder ist die Geometrie zu unterschiedlich?

    @tdettling, ich freue mich schon auf mein Exemplar des Adapters und bin jetzt bei der Recherche nach einem passenden Ausgabegerät auf ungeahnte Probleme gestoßen. Es scheint kaum noch TV-Geräte mit S-Video am Scart-Anschluss zu geben. Mein kleiner Grundig-TV tut es, hängt aber im Moment an meinem Brotkasten und gehört ansonsten eigentlich ins Gästezimmer. Da dessen Beine weit auseinander stehen, eignet er sich auch nur schlecht als Monitor auf dem Gehäuse des C128D.


    Ich frage mich daher, ob es nicht eine gute Idee wäre, in der nächsten Version des Adapters das S-Video-Signal zu dekodieren und als RGB zu übertragen. Die Umschaltung wäre dann intern und nicht mehr per Signal am Scart-Anschluss. Wenn es fertige Schaltungen für die Umsetzung auf HDMI gäbe, könnte man auch direkt auf diese Schnittstelle umstellen, aber das ist Zukunftsmusik.