Posts by flowerking

    Beim Sharp MZ-80A ist das auch die einzige Möglichkeit etwas Grafik zu haben. Dort ist das bereits in Basic integriert. Allerdings kann ich jetzt nicht sagen, in welcher Version von Basic das integriert ist, da beim MZ-80 Basic erst mal von Kassette geladen werden muss.

    Den Monitor gibt es öfters mal. Hat sämtliche Retroanschlüsse

    Der hier hat leider nur Abholung


    https://www.ebay.de/itm/Dell-2…518822:g:nw8AAOSwrIxeiEFG

    Ich hatte mir mal einen Dell (gebraucht) gekauft, weil er eben auch S-Video- und Composite-Video-Eingänge hat. Aber auf keinem der beiden Eingänge wird ein Bild vom C64 angezeigt. Auch mit Lumafix wird kein Bild angezeigt. Das Videosignal vom C64 ist einfach zu schlecht. (EIn Acorn Electron funktioniert an diesem Monitor)

    Also ein LCD mit S-Video würde ich zuerst mit dem C64 testen, bevor ich dafür Geld ausgebe.

    Laut Heise kann man den Analogue Pocket ab 3. August 2020 vorbestellen und geliefert werden soll im Mai 2021.

    Sieht schon interessant aus. Preis ist (imho) grenzwertig, vor allem wenn man Dock und Moduladapter dazu rechnet.

    Vor vielen Jahren hatte Heise schon mal eine Handheldspielekonsole vorgestellt, die ich auch prompt bestellt und auch gleich bezahlt hatte. Das war die OpenPandora, die ich dann auch nach ungefähr drei Jahren bekommen habe... :emojiSmiley-12:

    Es ist ja nur der Sourcecode so ausführlich. Das ausführbare Programm kann ja deutlich kürzer sein.


    Wie es bei Cobol ist, weiss ich nicht. Aber bei Fortran ist es wohl so, dass nach 50 Jahren und mehr seit es die Sprache gibt, die Compiler inzwischen sehr effizient sind. Ich könnte mir vorstellen, dass es bei Cobol ähnlich ist.

    Ich kann mich erinnern, das Ende der 90er schon mal Cobol-Programmierer gesucht wurden. Damals, um die vorhandene Software Y2k-fest zu machen. Ein Bekannter hat das damals gemacht, das wurde wohl auch gut bezahlt. Einiges an Software wurde damals auf Java umgestellt, aber so wie es aussieht scheint immer noch einiges unter Cobol zu laufen.

    Um die Programmierung in Cobol einfach zu halten, wurde wohl versucht natürliche Sprache nachzuahmen. Aus if (a > b)... wird dann so etwas wie if a is greater than b then... Deshalb gilt Cobol als "geschwätzig". Es gab dann auch den Witz, dass (in Anlehnung an C++) eine objektorientierte Version von Cobol "Cobol giving Cobol increased by one" heissen müsste.

    Ich verstehe den Sinn des Replacements für den VC20 nicht. Wenn man keine „alten“ Chips (6502, 65C02) verwenden möchte, wird doch sicherlich der W65C02 mit Adapterplatine funktionieren. Das dürfte weitaus günstiger sein, als die aufgezeigten Möglichkeiten.

    Wer Spaß am Experimentieren hat, hätte einen einfachen Computer, der 65816-Code ausführen kann. Das Modul ist zwar teuerer, wie ein reiner 65C02, aber für ein 65816 trotzdem noch relativ preiswert. Allerdings könnte in der Grundversion der Speicher schnell knapp werden und wahrscheinlich muss man seine Programme auf einem anderen Rechner erstellen.

    Da hätte ich doch direkt mal ein paar Fragen:

    - Wenn ich dieses Modul, statt des standardmäßigen 65C02, in einen Apple IIc einbaue, läuft der Rechner trotzdem nur mit den ca. 1MHz, mit denen der IIc normal läuft?

    - Ist der 65816 voll kompatibel zum 65C02? D.h. , sämtliche Software, die ich habe, läuft immer noch?

    ...

    Nun ist es aber so, dass diese Retro-Rechner nun mal kommen werden – den Sinn zu hinterfragen, kommt zu spät. Es geht eher darum, ihnen einen Sinn zu GEBEN.

    Nur weil etwas da ist, muss es ja nicht unbedingt einen Sinn haben. Manchmal ist es halt einfach da. Und zwanghaft einen Sinn "suchen", ist ja nun wirklich sinnlos. ;)


    Die ganzen Retro-Rechner sind da, weil "es geht". Heute sind die PCs leistungsfähig genug, dass jeder, der genug Interesse und Ausdauer aufbringt, seinen eigenen Computer entwickeln kann. CAD-Programme und Platinenlayoutprogramme sind oft kostenlos erhältlich und sind inzwischen auch von Laien bedienbar. Es gibt Simulatoren, es gibt Entwicklungsumgebungen für FPGAs, etc. und alles läuft zu Hause auf dem PC ohne dass man viel Geld investieren muss. Selbst Gehäuse kann man komplett zu Hause entwerfen und mit einem 3D-Drucker sogar Wirklichkeit werden lassen. Ob man mit FPGA eine eigene CPU entwickelt oder "nur" auf einem Raspi etwas programmiert, die Mögichkeiten sind riesig.

    Ich finde das toll. Ob das sinnvoll ist oder ob das jemand anderes gebrauchen kann - egal! Hauptsache man hat Spaß daran und kann noch etwas dabei lernen.

    Um das auch hier abzuschliessen:

    Zusammen konnten wir rausfinden, warum der Emu64 bei mir nicht richtig gestartet ist und den Fehler beheben. Es lag an einem Soundbuffer, der die falsche Größe hatte. Emu64 läuft jetzt auch unter FreeBSD ziemlich gut. Auch USB-Joystickadapter funktionieren problemlos, so dass auch unter FreeBSD ab und zu eine Runde gezockt werden kann. :thumbsup:

    Ein Fehlerbericht habe ich gerade abgeschickt.


    Ich könnte eine Version mit mehr Logging hier bei mir ausführen. Vielleicht liefert das Anhaltspunkte. Oder es wäre vielleicht möglich, das Programm auf meinem Rechner zu debuggen?

    Ein "pkg autoremove" habe ich gemacht, da gab es tatsächlich einige Abhängigkeiten, die nicht mehr gebraucht wurden. Ein "pkg upgrade -f" werde ich eher nicht machen. Einen Treiber für X11 habe ich als Port kompiliert, weil da ein Parameter geändert werden musste. Das hat insgesamt ungefähr einen halben Tag gedauert. Das möchte ich mir nicht noch einmal antun. Ich habe mir ein SDL2-Spiel heraus gegriffen (Chromium-Bsu - habe ich vor Jahren schon mal unter Linux gespielt) Das hat (natürlich) funktioniert.

    Was mit noch aufgefallen ist: Auch wenn ich Emu64 über den Menüpunkt "Beenden" beende, bleibt ein Prozeß, manchmal auch zwei Prozesse zurück, die ich dann von Hand beenden muss.

    Einen Bugreport werde ich dann erstellen, auch wenn ich da nicht so überzeugt bin. Viel reinschreiben, ausser dass es nicht funktioniert, kann ich ja nicht. Für die Anmeldung habe ich schon eine E-Mailadresse hingeschickt.

    Zwischenstand:

    Ich habe einen anderen Windowmanager ausprobiert. Leider habe ich da nur twm (sonst benutze ich Openbox): Kein C64-Fenster.

    Ich habe das latest-Paket von emu64 installiert. Da wurde aber wirklich nur das emu64-Paket ausgetauscht. Beim Kompilieren des Ports wurde ja noch mehr Abhängigkeiten erstellt. Leider auch kein C64-Fenster.

    Das Löschen der Konfiguration bringt auch nichts.

    In emu64.log (im Konfigverzeichnis) wird auch kein Fehler angezeigt.


    Ein paar Fragen hätte ich noch:

    Die ROM-Files (Kernal, Basic, charset) sind dabei oder muss ich die irgendwo bereitstellen? Gibt es ein kleines Testprogramm, um SDL2 zu testen? Ich habe mal "SDL_jewels" installiert, was auch funktioniert, aber das benutzt eine libSDL-1.2. Also eher kein SDL2. Ein SDL-Logfile gibt es wahrscheinlich nicht? Rein gefühlsmäßig hätte ich SDL2 in Verdacht. Entweder kann meine Harware das nicht, oder es ist irgendwas nicht oder falsch konfiguriert.