CBM II B500 alias B128

  • Hallo allseits,


    heute von einem Bekannten abgeholt: Ein "Bürofund", ein CBM II B500 (alias B128). Frühes Exemplar, denn der Sticker auf der Rückseite zeigt noch wirklich "B500", obgleich der Rechner unter diesem Namen nie auf den Markt gekommen ist und der Sticker bald auf "B128" geändert wurde. Auch die Seriennummer #316 zeigt, dass es sich um ein frühes Exemplar handelt.



    Die technischen Daten sollten allgemein bekannt sein. Falls nicht, die hier wichtigsten: MOS 6509 Prozessor mit 2 MHz (ein 6502-Derivat mit einfachem Bankswitching), 128 KByte RAM, 6545-Video-Chip, SID (!)-Soundchip, RS232-Schnittstelle, IEEE488-Schnittstelle.


    Dem ersten Augenschein nach wurde das Gerät wenig benutzt (kein Wunder, gibt ja kaum Software dafür) und nie geöffnet. Den Zustand würde ich dementsprechend als "ziemlich gut" beschreiben, was mich wagemutig zu einem Funktionstest hat schreiten lassen. Ergebnis: Power-LED geht an, aber der Monitor zeigt kein Bild. Das muss ich mir mal genauer anschauen.


    Da ich wusste, dass ich das Gerät bekomme und es dafür kaum Software gibt, habe ich mal wieder den Assembler angeworfen und angefangen, ein Spiel dafür zu programmieren. Man, bin ich eingerostet. Immerhin, das Spiel läuft auf dem C64 schon in den ersten Zügen, auf einfache Portierbarkeit und die Eigenheiten des CBM II (wenig RAM in Bank 15 frei, 6545-Eigenheiten, keine Grafik, nur PETSCII etc.) habe ich geachtet.


    Ein paar Fragen in die Runde: Worauf sollte man beim Überarbeiten des Geräts besonders achten? Ein petSD sollte an dem Gerät wohl funktionieren, oder?


    Ich halte Euch auf dem Laufenden. Zur RETROpulsiv im April in Augsburg bringe ich das gute Stück wohl auch mal mit.


    Viele Grüße
    CK

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


  • Danke für die schnelle Antwort. Habe das Gerät direkt ausgeschaltet und auch den Stecker abgezogen. Dachte mir schon, dass das etwas "wagemutig" ist...

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


    • Offizieller Beitrag

    Wenn Du den Netzfilter entfernt hast, kannst Du an die Fehlersuche gehen.
    Erster Schritt: Netzteil überprüfen.
    Es muß +5V, +12 und -12V, sowie ein 50Hz Rechtecksignal liefern.
    Ein fehldendes 50 Hz Signal kommt öfters mal vor, der Rechner startet dann nicht.
    Wenn die Versorgungsspannungen aus dem Ruder laufen können sie mit dem Trimmpoti nachreguliert werden.
    Leider nur alle zusammen. Am wichtigsten ist natürlich, daß die +5V stimmen.
    +12V wird nur für den SID und die RS-232 Schnittstelle, -12V nur für die RS-232 Schnittstelle gebraucht.
    Wenn das Netzteil OK ist, und der Rechner noch nicht laufen sollte, suchen wir weiter. :)

  • Nochmal danke für die schnelle Antwort. Während ich mich bei Softwarethemen als recht fit bezeichnen würde, habe ich leider bei Lötaufgaben zwei linke Hände. Auf der RETROpulsiv im April sollten aber fachkundige Löter dabei sein, die mir helfen können. Gibt's irgendwelche Teile, die ich vorab schon mal besorgen sollte? Wie sieht's bei dem Gerät üblicherweise beispielsweise mit ausgelaufenen Elkos aus?


    Danke und viele Grüße
    CK

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


    • Offizieller Beitrag

    Defekte Elkos auf dem Motherboard sind mir bisher nicht dabei begegnet,
    in den Netzteilen habe ich hin und wieder welche angetroffen.
    Ausgelaufene zum Glück bisher aber noch garnicht.
    Was auf dem Mainboard gerne mal kaputt geht wären 4164 DRAM und 6116 SRAM.
    Sonst ist mir da noch nichts durch häufigere Defekte aufgefallen.


    Viel Erfolg !

    • Offizieller Beitrag

    Hallo Christian,
    Du hattest ja auch Fragen zur Programmierung, die Du per Email konkretisiert hattest.
    Damit auch andere noch etwas davon haben, und hoffentlich auch noch mehr Beitragen,
    versuche ich mal hier ein paar Antworten zu geben.
    Da ich am Lötkolben allerdings besser bin, als im Programmieren, kann es nicht schaden,
    wenn der eine oder andere da nochmal drüberguckt.


    Für die Benutzbarkeit ist auf alle Fälle ein Uprgade auf die letzte Kernal- und Basic-Version sehr empfehlenswert.
    Die alten Versionen sind recht fehlerhaft, da gehen teilweise die einfachsten Sachen nicht richtig.
    Als Masken-ROMs gibt's m.W. nur die ganz alten Versionen, die neueren habe ich immer nur als EPROM mit Adapter gesehen.
    Gesockelt sind die auf dem Mainboard immer.


    Das RAM in Bank 15 ist dediziert nur dort vorhanden.
    Überhaupt sind mir garkeine sich irgendwo spiegelnden Speicherbereiche bekannt.


    Der CRTC hat nur Zugriff auf den vorgesehenen Bildschirmspeicher.
    Die Hardware ermöglicht keinen Zugriff auf andere Speicherbereiche.
    Es gibt also leider keine Möglichkeit, auf eine zweite Bildschirmseite umzuschalten.


    NMI wird normalerweise nicht verwendet, ist auch Hardwareseitig nur mit
    dem Anschluß für die CPU-Erweiterung (8088 CPU) verdrahtet.


    IRQ ist schon interessanter:
    Es gibt Hardwareseitig 5 IRQ-Quellen, die am 6525 #1 anliegen.
    Der IRQ für die CPU wird auch vom 6525 #1 erzeugt (Anschluß PC5).
    IRQ0 (PC0) wird mit 50 Hz vom Netzteil getriggert.
    IRQ1 (PC1) SRQ-Signal vom IEEE-488 Bus, normalerweise nicht verwendet
    IRQ2 (PC2) IRQ-Signal vom 6526, Verwendung ???
    IRQ3 (PC3) IRQ-Signal von CPU-Erweiterung (8088 CPU) normalerweise nicht benutzt
    IRQ4 (PC4) IRQ-Signal vom 6551ACIA (RS-232 Schnittstelle)


    Wie die IRQs abgefrühstückt werden, weiß ich leider nicht.
    Vermutlich wird der 6525 so programmiert, daß er bei IRQ0 - IRQ4 einen IRQ zur CPU auslöst,
    und die IRQ-Routine dann beim 6525 abfragt, welcher der 5 IRQs die Quelle war.

  • Die per E-Mail gestellte Frage, wie man ein in Assembler geschriebenes Programm überhaupt in den Speicher bekommt, habe ich mir auch schon einmal gestellt.


    Ich habe mir damals dazu die crt0.s des cc65 C-Compilers angesehen, da dieser Code genau diese Aufgabe erfüllt: das Laden eines größeren Programms. Wenn man sich den Quelltext ansieht, stellt man recht schnell fest, dass das mit einigem Aufwand verbunden ist. Die Dokumentation des Quelltextes ist zwar deutlich besser geworden, seit ich damals reingesehen habe, aber leider enthält er bis zum heutigen Tag einen binär-blob, damit es nicht zu einfach wird.


    Ich habe damals ob der Komplexität schnell Abstand davon genommen, irgend etwas in Assembler für die CBM-II-Reihe zu tun und würde es heute wieder tun. Wenn Du Dich da ran wagen möchtest: Respekt! Wenn es Dir gelingt: Chapeau! Und wenn Du dann vielleicht sogar noch das Verfahren für dummies dokumentieren würdest: Kudos!

  • Hallo allseits,


    abermals danke für Eure Antworten. Die Informationen sind sehr hilfreich!


    Zum Thema IRQ: Für mein Vorhaben wäre am ehesten der 50 Hz getaktete "Timer"-IRQ sinnvoll. Defakto brauche ich aber keinen IRQ. Das Spiel läuft in einer Hauptschleife und IRQs würde vermutlich sogar eher stören. Gut auch, dass praktisch nichts einen NMI auslösen kann. Dann kann auch der nicht stören.


    Dass ich mich vom Double Buffering verabschieden muss, ist schade. Um dann ein flackerfreies Bild darzustellen, das nicht vom Bildaufbau "zerrissen" wird, wäre es gut zu wissen, wo sich der Rasterstrahl jeweils in etwa befindet. Einen Register mit der aktuellen Rasterzeile wie beim VIC scheint es nicht zu geben, geschweige denn einen Raster-IRQ. Der CRTC zeigt aber in seinem Statusregister an, wann der Rasterstrahl in seiner "vertical blanking time" ist. Nicht ganz klar ist mir, ob damit der Strahlenrücklauf von rechts nach links (für die nächste Zeile) und von rechts unten nach rechts oben (für das nächste Bild) gemeint ist. Außerdem kann ich noch nicht beurteilen, wie lange der Rasterstrahlrücklauf dauert. Von Zeile zu Zeile wohl nur einige Taktzyklen. Von Bildschirmende zu Bildschirmbeginn aber ggf. auch nicht viel länger, da der CRTC ja keinen "Rand" zeichnet, wie dies der VIC tut, oder?


    Ansonsten würde ich versuchen, mir die Welt so einfach wie möglich zu machen. Kompliziert wird's beim CBM II ja vor allem dann, wenn man aus einer anderen Bank den Kernel nutzen möchte. Davon verabschiede ich mich. Den einzigen Nutzen, den der Kernel bringen würde, ist die Abfrage der Tastaturmatrix. Das macht er wiederum im IRQ und somit ist auch das nur bedingt tauglich. Ich frage die Tastaturmatrix einfach selbst ab. Das sollte kein Hexenwerk sein.


    Ansonsten würde ich soviel wie möglich in Bank 1 laufen lassen. Ob ich auf Bank 15 und somit den I/O-Bereich und den Bildschirmspeicher ausschließlich indirekt indiziert zugreife, bin ich mir noch nicht ganz sicher. Das wäre wohl am einfachsten, aber ggf. auch etwas langsam.


    Evtl. packe ich in die 2 K RAM in Bank 15 ein paar zeitkritische Routinen, die dann etwas schneller auf den Bildschirmspeicher zugreifen können. Damit das Bankswitching unkompliziert funktioniert würde ich den identischen Code an der identischen Adresse auch in Bank 1 ablegen. So kann ich die Execution Bank ändern, ohne dass die CPU plötzlich in der Leere landet. Natürlich muss ich zuvor indiziert indirekt alle nötigen Parameter in die jeweils andere Bank schreiben, damit diese dort verfügbar sind, wenn ich wechsle. Und dann gibt's noch das Problem mit dem Stack. Auch dessen Inhalt "verschwindet" ja beim Bankwechsel. Das heißt für mich: In den Routinen, die in Bank 15 arbeiten, einfach keinen Stack zu benutzen. Also kein PHA/PLA, kein JSR/RTS. Auf diese Weise baut sich der Stack in Bank 1 auf und wird durch Code in Bank 15 auch nicht berührt. Auch der Stackpointer bleibt unberührt und zeigt nach Rückkehr in Bank 1 wieder dorthin, wo er soll. Da dort auch der Steckinhalt wieder da ist, kann ich sogar per "RTS" dorthin zurückspringen, wo ich hergekommen bin.


    Und dann stellt sich noch die Frage: Wie kriegt man das alles zu Beginn geladen und initialisiert. Ich dachte da in meinem jugendlichen Leichtsinn an einen Basic-Leader, der den Objektcode jeweils per BANK XX:BLOAD "xxx" an die entsprechenden Adressen in den Banks lädt. Über eine möglichst kurze Initialisierungsroutine im 2K-Bereich in Bank 15 springe ich dann in den Code in Bank 1 ein und los geht's. Das müsste eigentlich funktionieren, oder?


    Hab ich noch irgendwas vergessen?


    Viele Grüße
    CK

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


    • Offizieller Beitrag

    Der CRTC zeigt aber in seinem Statusregister an, wann der Rasterstrahl in seiner "vertical blanking time" ist. Nicht ganz klar ist mir, ob damit der Strahlenrücklauf von rechts nach links (für die nächste Zeile) und von rechts unten nach rechts oben (für das nächste Bild) gemeint ist. Außerdem kann ich noch nicht beurteilen, wie lange der Rasterstrahlrücklauf dauert. Von Zeile zu Zeile wohl nur einige Taktzyklen. Von Bildschirmende zu Bildschirmbeginn aber ggf. auch nicht viel länger, da der CRTC ja keinen "Rand" zeichnet, wie dies der VIC tut, oder?

    Vertical blanking Time ist der Strahlrücklauf vom Bildende zum Bildanfang.
    Einen Rand links und rechts neben den angezeigten Zeichen gibt es.
    Während der Strahl durch den Rand (und zurück zum Zeilenanfang) läuft, wird das Video-Signal deaktiviert.

    Und dann stellt sich noch die Frage: Wie kriegt man das alles zu Beginn geladen und initialisiert. Ich dachte da in meinem jugendlichen Leichtsinn an einen Basic-Leader, der den Objektcode jeweils per BANK XX:BLOAD "xxx" an die entsprechenden Adressen in den Banks lädt. Über eine möglichst kurze Initialisierungsroutine im 2K-Bereich in Bank 15 springe ich dann in den Code in Bank 1 ein und los geht's. Das müsste eigentlich funktionieren, oder?

    Das wird gewöhnlich so gemacht: Die Bank wird bei BLOAD mit angegeben, also
    BLOAD "[dateiname]",D[laufwerk],U[gerätenummer],B[BANK],P[startadresse]
    Wenn man von Gerät 8, Laufwerk 0 an die in der .PRG-Datei hinterlegte Ladeadresse lädt, braucht man nur den Papameter P, der Rest ist dann über.
    Die Verwendung von BANK und dann BLOAD ohne Bank-Angabe ist unüblich. Keine Ahnung, ob das tatsächlich funktioniert.
    BANK braucht man nur zum Umschalten der Bank für PEEK, POKE ... und meinem Meinung nach auch SYS, im Handbuch steht allerdings, daß sich SYS immer auf Bank 15 bezieht.
    Das glaube ich aber nicht so recht, sollte man mal ausprobieren.
    Das CBM-II Benutzerhandbuch ist definitiv voller Fehler, vor allem auch inhaltlicher Natur.

    Hab ich noch irgendwas vergessen?

    Mit Sicherheit ... das merkst Du, wenn Du es brauchst. :D

  • Um dann ein flackerfreies Bild darzustellen, das nicht vom Bildaufbau "zerrissen" wird, wäre es gut zu wissen, wo sich der Rasterstrahl jeweils in etwa befindet.

    Vorab: ich habe keine Ahnung von Spiele-Programmierung. Aber ist dieser Aufwand wirklich notwendig? Wenn ja, kannst Du kurz umreissen, warum? Beim CBM-II haben die CPU und der CRTC ja immer abwechselnd Zugriff auf den Speicher, da wird es also keinen "Schnee" geben, wenn die CPU in die Speicherzelle schreibt, die der CRTC gerade darstellen möchte.

  • Es geht dabei nicht um den "Schnee", der bei Zugriffskonflikten von CPU und CRTC auf das RAM entsteht (und wie man ihn von alten IBM PCs kennt). Vielmehr geht es darum, dass das Bild bei bewegten Objekten zerrissen wird. Das geschieht immer dann, wenn der Rasterstrahl genau dann die Zeilen des Bildes aufbaut, wenn etwas bewegt werden soll. Wird ein Objekt beispielsweise von links nach rechts bewegt, kann es sein, dass die obere Hälfte noch am alten Ort, die untere Hälfte des Objektes schon am neuen Ort ist.


    Man möchte meinen, dass das nur alle heiligen Zeiten passiert. Tatsächlich passiert es aber andauernd, so dass die Objekte auf dem Bildschirm ständig "zerrupft" wirken.


    Erschwerend kommt hinzu, dass bei meinen Bildschirmaufbauroutinen jedes Mal der Bildschirm gelöscht und dann neu gezeichnet wird. Das geht (zumindest im Moment) schneller, als nur die Änderungen auf dem Bildschirm zu schreiben. Das wiederum macht sich aber durch flackern bemerkbar, weil man immer wieder auch den gerade geleerten Bildschirm sieht.


    Deshalb empfiehlt es sich, den Bildschirmaufbau dann vorzunehmen, wenn der Rasterstrahl entweder gerade gar nichts zeichnet oder zumindest nachläufig zum Rasterstrahl das Bild aufzubauen. Für Letzteres müsste man zumindest in etwa wissen, wann der Rasterstrahl ganz oben ist.

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


  • Deshalb empfiehlt es sich, den Bildschirmaufbau dann vorzunehmen, wenn der Rasterstrahl entweder gerade gar nichts zeichnet oder zumindest nachläufig zum Rasterstrahl das Bild aufzubauen. Für Letzteres müsste man zumindest in etwa wissen, wann der Rasterstrahl ganz oben ist.


    Du hast ja doch schon herausgefunden, dass man den Strahlrücklauf im Statusregister des CRTC abfragen kann, per Polling. Da Polling immer viel Zeit verschwendet, wäre ein IRQ schöner. Mein Vorschlag wäre jetzt, den Timer-IRQ einmalig auf den Strahlrücklauf zu synchronisieren, das sollte sogar zyklengenau funktionieren. Wenn Du nun das Beschreiben des Bildschirmspeichers in den IRQ legst, sollten die Verzerrungen vergessen sein.

    Zuletzt repariert:

    10.11. defektes µT RAM im Apple //e ersetzt

    10.11. defektes µT RAM im Atari 130XE ersetzt

    12.11. VC20 mit black screen: defekter Videotransistor ersetzt

  • Gute Idee, werde ich mal durchdenken. Allerdings ist das Thema IRQ dann kompliziert, wenn Code auch in Bank 15 ausgeführt werden soll. Ich muss mal überlegen, wie das dennoch klappen könnte oder ob ich eben auf Code in Bank 15 verzichte.


    Das Spiel "zuckt" übrigens schon in der CBM2-Version von VICE. Ich habe bislang nur einige wenige Routinen an den CBM II angepasst, aber im Prinzip tut's: Kleine Init-Routine, die identisch sowohl in Bank 15 als auch Bank 1 geladen wird, der eigentliche Code läuft in Bank 1, auf Bank 15 greife ich (bislang ausschließlich) indirekt indiziert zu. Den IRQ schalte ich (dauerhaft) ab und springe in über die Init-Routine ein. Tut.


    Wozu die Unterlagen, die ich im Netz gefunden habe, bislang nichts Vernünftiges hergeben ist das Abfragen der Tastaturmatrix. Beim C64 hängt die Tastatur an der CIA 1. Weiß jemand hier Rat?


    Danke und viele Grüße
    CK

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


  • stimmt, es gibt ja die Optionen 50/60Hz und noch den 700er mit höherer Auflösung. hat der dann auch 50/60Hz oder mehr?


    Gruß x1541

    Zuletzt repariert:

    10.11. defektes µT RAM im Apple //e ersetzt

    10.11. defektes µT RAM im Atari 130XE ersetzt

    12.11. VC20 mit black screen: defekter Videotransistor ersetzt

  • Toast_r: Danke! Das sollte die letzte noch offene Frage beantworten! Die PAL/NTSC-Unterscheidung würde allenfalls bei *sehr* timingkritischen Dingen nützen, wenn man wissen muss, ob die Netzfrequenz (und somit auch der Timer IRQ) mit 50 oder 60 Hz laufen. Für mein Vorhaben ist das aber wohl irrelevant.


    x1541: Das kann ich leider nicht gesichert beantworten. Der B720 nutzt einen Zeichensatz mit 9x14 Pixeln Auflösung. Das ergibt rechnerisch eine Auflösung von 720 x 350. Der CRTC ist da sehr frei programmierbar. Ob das aber auch zu einer höheren Bildwiederholfrequenz führt, weiß ich nicht.

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


    2 Mal editiert, zuletzt von CKTWO ()

    • Offizieller Beitrag

    700er mit höherer Auflösung. hat der dann auch 50/60Hz oder mehr?


    Wie hoch die Bildwiederholrate beim 700er ist weiß ich gerade nicht,
    wohl aber, daß es da keine 50/60Hz Varianten gibt.
    Die haben alle die gleiche Wiederholrate.


    Ich hab noch was zum Thema Banking gefunden, das vielleicht hilfreich sein kann.
    Ich habs mal eingescannt und hier angehängt.
    Leider ist die Vorlage mal wieder nur die Kopie einer Kopie, wie so soft bei den alten Sachen.
    Es müsste aber zumindest soweit alles lesabr sein, daß man damit was anfangen kann.


    CBM II Banking.pdf

  • Der B720 nutzt einen Zeichensatz mit 9x14 Pixeln Auflösung. Das ergibt rechnerisch eine Auflösung von 720 x 350. Der CRTC ist da sehr frei programmierbar. Ob das aber auch zu einer höheren Bildwiederholfrequenz führt, weiß ich nicht.


    Das hört sich sehr nach Hercules an, das hatte ja doch auch nur 60Hz. Das war nur flimmerfrei dank Bernsteinmonitor.

    Zuletzt repariert:

    10.11. defektes µT RAM im Apple //e ersetzt

    10.11. defektes µT RAM im Atari 130XE ersetzt

    12.11. VC20 mit black screen: defekter Videotransistor ersetzt

  • So, gute Nachrichten von der "Space Chase"-Front: Gestern Abend bin ich wieder einen großen Schritt weiter gekommen. Das Spiel läuft jetzt im gleichen Umfang wie auf dem C64 auch auf dem CBM II (zumindest in der VICE-Emulation). Auch die direkte Abfrage der Tastaturmatrix funktioniert und ich hatte auch eine Idee, wie das Double Buffering zumindest eher recht als schlecht funktioniert.


    An die Programmierung des CBM II gewöhne ich mich langsam. Im Gegenteil, wenn man auf den Kernel verzichtet ist es richtiggehend Luxus volle 64 KByte im direkten Zugriff zu haben und trotzdem ohne großes Heckmeck auf die I/O-Bereiche in Bank 15 zuzugreifen.


    Ich werde nun definitiv auf der RETROpulsiv am 16./17.04. in Augsburg eine frühe Alphaversion zeigen, die natürlich noch unvollständig und buggy sein wird. Aber zumindest werdet Ihr sehen, wohin die Reise geht... aber natürlich nur, wenn Ihr auch nach Augsburg kommt. Da ich ja Veranstalter der RETROpulsiv bin, hab ich natürlich großes Interesse und würde mich auch sehr freuen ein paar CBM II-Fans dorthin zu "locken". B-)


    Nach der RETROpulsiv werde ich auch die www.spacechase.de live schalten und dort zumindest mal ein paar frühe Screenshots posten.


    Wie schnell es danach weitergeht, hängt natürlich vor allem vom Faktor "Zeit" ab. Wir werden sehen.


    VG CK

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


  • Kleiner Teaser...

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


  • Neee, da müsst Ihr schon auf die RETROpulsiv kommen ;-). Da gibt's dann mehr zu sehen. B-)


    Sind mittlerweile 2100 Zeilen Assembler. Man muss auf dem CBM II ja nunmal wirklich ALLES selbst machen. Aber immerhin ist der Rechner mit 2 MHz und direktem Zugriff auf den Bildschirmspeicher (anders als beim VDC des C128...) schön schnell.


    In den späteren Nachmittags-/Abendstunden will ich dann auf der RETROpulsiv auch am Spiel weiterprogrammieren. Es fehlt immer noch viel.


    VG CK

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


  • Ich kann ja verstehen, daß Du möglichst viele Leute auf dem Treffen haben möchtest,
    aber 600 km entfernt, das ist mir nun wirklich zu weit weg ...


    Ich kann ja verstehen, daß Du möglichst viele Leute auf dem Treffen haben möchtest,
    aber 600 km entfernt, das ist mir nun wirklich zu weit weg ...


    Kann ich auch wiederum verstehen. Nach der RETROpulsiv schalte ich die www.spacechase.de frei. Da gibt's dann mehr zu sehen und ggf. auch schon ne Betaversion.

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


  • So. Der CBM 500 läuft. Die versprochenen Nackigbilder hänge ich an.


    Mit der petSD+ läuft er auf Anhieb nicht. Das hatte ich aber schon fast erwartet.

  • Korrektur. Die petSD+ läuft doch!

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0


  • Nein, der ist mittlerweile draußen und dabei wurde das Gerät gleich auf 240V umgelötet. Die Bilder entstanden direkt nach dem Öffnen, der Screenshot ca. ne Stunde später, nach dem Ausbau. Eingeschaltet wurde das gute Stück erst nach dem Ausbau.

    www.retropulsiv.de -- Es gibt zu wenig Retrocomputing im Süden!

    www.spacechase.de -- The CBM II game that was 35 years late!
    Pegasos II/G4,1 GHz,512 MB,32 GB SSD,MOS,AOS4.1 : Amiga 600/Vampire II,128 MB,4 GB CF,AOS3.5,NIC
    GBA1000/060,100 MHz,72 MB,4 GB CF,AOS3.9 : Amiga 4000/060,50 MHz,270 MB,40 GB SSD,AOS3.0