Beiträge von RhinoDevel

    Hier ein BASIC-Einzeiler, den ich in der Zeitschrift The Transactor, Vol. 4

    gefunden habe (die Ausgabe mit entfaltbarem Jim Butterfield..!):


    Code
    1 c=32 : for n=1 to 41 : c=192-c : for a=0 to n : for b=32768+a to 34768 step n : poke b,c : next b,a,n


    Der Code ist für den 8032, bitte für die 40-Zeichen - CBMs (z.B. den 4032) 34768 in 33768 ändern.


    Das funktioniert natürlich auch auf VC20 und C64 mit den entsprechende

    Änderungen.


    Viel Spaß

    Gestern habe ich nocheinmal zum Thema Linux Port (und damit WLAN) recherchiert.


    Mit pigpio kann evtl. der Fastloade/-saver übertragen werden,

    indem man diesen mit gpioWaveAddNew() usw. als Wave Form sendet.

    Die scheinen nämlich DMA für das Setzen der GPIO-Pins zu verwenden,

    was eine ausreichende Genauigkeit zur Folge hat

    (keine Unterbrechungen durch das Timesharing/Scheduling des Betriebssystems, wie bei der Nutzung der CPU).


    Das werde ich mal ausprobieren.

    Und was ist mit PicoPi ? Da wäre BareMetal geradezu nötig, wahrscheinlich kann man das recht gut dahin portieren, zumindest wenn ARM mitgedacht hat, und es macht eine unglaublich günstige Lösung aus dem Ganzen.



    Ansonsten: Glückwunsch zum Artikel. Das ist ja bißchen wie ein kleiner Ritterschlag, wenn das da in dem Magazin auftaucht. Dürfte ja das bekannteste und größte dieser Art sein.

    Mit dem Raspberry Pi Pico habe ich mich noch nicht ernsthaft beschäftigt.

    Wäre aber zumindest in Richtung WLAN, etc. kein Fortschritt - im Gegensatz zu ESP8266/Arduino.

    Aber ja, günstig. Müsste mir mal welche organisieren zum Herumspielen..


    Danke für den Glückwunsch!

    Daher mag ich meine PETdisk Max und ihre WIFI-Funktionalität. Einfach am PC in den freigegebenen Ordner speichern, fertig. Der PET sieht es instant auf seinem Laufwerk. Rückzu genauso. Bindet man den Ordner PC-seitig in Vice ein, kann man direkt aus Vice auf dem PET speichern und vice versa. Schneller geht's nicht.

    Am liebsten würde ich CBM Tape Pi von Bare Metal zu Raspbian portieren.

    Dann hätte man damit auch sehr einfach das WLAN & Internet zur Verfügung (unter Anderem).


    Den Fastloader/-saver per Datassetten-Emulation aus Linux auf den Commodore zu bekommen gestaltet sich allerdings schwierig

    (wegen des Timings). Evtl. geht das per Kernel-Modul und DMA, aber das erscheint mir sehr aufwendig

    (hatte schonmal experimentiert in die Richtung).


    Ein anderer Weg zu WLAN & Internet & ... ist die Portierung auf Arduino.

    Sobald wieder Zeit, bastel ich da mit dem ESP8266 weiter dran.

    Der Pi will aber 1A , besser bißchen mehr. Das ist evtl. gar nicht da.


    Mich würde mal interessieren, was die Elektoniker zu der Art dert Verbindung sagen. Ist das OK, oder macht man sich damit ganz schnell den GPIO Port kaputt (oder den Stein hinter dem Datasettenport), etwa wenn man das abzieht und noch ein Gerät an ist.

    Nicht alle Pis wollen 1A. Beim Zero solltest Du z.B. mit 500mA auskommen.


    Dass man die Geräte nicht im laufenden Betrieb abziehen soll, steht in der README.

    Das ist ja nichts neues bezüglich der alten Computer/DIskettenlaufwerke, oder?


    Man kann die Schaltung ja auch mit Level Shiftern versehen.


    Mir ging es aber auch darum, zu schauen, wie weit man mit einfachen/diskreten Komponenten kommt (und dem Pi).

    Die Übertragungsrate ist ganz grob bei 2.5 Kilobyte pro Sekunde.

    Das Übertragungsprotokoll ist aber derzeit auch nicht auf Geschwindigkeit ausgerichtet,

    sondern darauf, dass es unabhängig von der Reaktionszeit der verbundenen Geräte ist

    (viel Handshaking..). Das könnte man also noch wesentlich beschleunigen, denke ich.


    Es sollte nichts passieren, wenn man die Geräte gleichzeitig ein-/ausschaltet.

    Ich bin die Kombinationen (Standard-GPIO-PIN-Einstellungen, Pull-ups / Pull-downs, CBM an/aus, etc.) durchgegangen

    und habe mich dazu entschieden, das so einzuschränken.


    Die neue Version von CBM Tape Pi v1.7.0 ist jetzt verfügbar.


    Wichtigste neue Funktionen:

    • Fast Mode per Befehlserweiterung (Wedge) für CBM/PETs, VC 20 und C64.
    • Unterstützung für den Raspberry Pi 3 (neben 1, 2 und Zero).

    Ein paar HIghlights:

    • Es wird nur der Datasetten-Port belegt (gleichzeitig Diskettenlaufwerk verwenden sollte z.B. gehen).
    • Durch die Verzeichnisse gehen und Dateien auswählen geht direkt über den Commodore.
    • Bei den CBM/PETs gibt es Support für BASIC v1, v2 und v4.
    • Bei den CBM/PETs kann man wählen, ob die Befehlserweiterung in den Kassettenpuffern oder am Ende des BASIC RAMs hinterlegt werden soll, beim C64 zwischen Ende des BASIC RAMs und direkt vor $D000.
    • Gibt dem alten, herumliegenden Raspberry Pi eine neue Aufgabe.
    • Open Source.
    • Minimaler Bastelaufwand (z.B. keine ICs - außer dem Raspberry Pi..).

    Für Raspi & BMC64 & altes Gehäuse braucht man dann aber noch ein Keyrah oder ähnliches, oder?

    Also auch nicht so einfach/günstig.

    Trotzdem wahrscheinlich billiger als THEC64 neu.

    Habe gerade einen sehr günstig gebraucht ergattert.

    Mir fehlt bloß die CBM/PET - Emulation. Muss wohl auch auf Raspi & BMC64 umsteigen/erweitern.. :)

    > Das bedeutet dann also auch, wenn man (beispielsweise ein Spiel) programmiert,

    > welches auf 60 Hz ausgelegt ist, kann man bei Computern mit CRTC im Spiel auf 60 Hz umstellen(?).


    Hört sich für mich alles so an, als ob man (beispielsweise in eigenen Spielen) den CBM nicht einfach auf 60 Hz umstellen sollte, oder? :/

    Die Anpassung der Bildwiederholrate an die Netzfrequenz ist definitiv kein "Unfug". Das haben alle Hersteller gemacht. Auch die TV-Normen passen sich dem an. Neben der EMV (Elektomagnetischen Verträglichkeit) spielt auch die Raumbeleuchtung eine große Rolle. Immerhin "flackert" das Bild (entsprechend der Nachleuchtkraft der Bildröhre) mit der Bildwiederholrate. Solange die Raumbeleuchtung nun mit der gleichen Frequenz "flackert", entsteht nur eine Schwebung, die man kaum wahrnimmt.

    Die PET ohne CRTC erzeugen die Videosigale (damit auch die Bildwiederholrate) fest auf 60 Hz.

    Beim CRTC kann dieser neben der Vorgabe des Editor-ROM (siehe auch hier oder hier) jederzeit umprogrammiert werden. Jedoch werden bei 60 Hz weniger Rastterzeilen pro Bild dargestelt. Damit kann es sein, daß die Bildgeometrie des Monitors angepaßt (eingestellt) werden muß.

    Das Editor-ROM unterscheidet sich neben den angepaßten Werte für den CRTC auch in der Interrupt-Routine. Diese ist immer für 60 Hz ausgelegt. Bei 50 Hz wird bei jeder fünften Auslösung die Routine doppelt ausgeführt. Die Jiffy springen dann um zwei.

    Danke für die Erklärung mit der kaum wahrnehmbaren Schwebung und für die Links!

    Die Frequenz wird bei der Initialisierung des CRTC festgelegt. Die Werte für die Initialisierung sind im Editor - Rom festgelegt. Es gibt Editor-Roms mit 50 und mit 60 Hz.

    Für Europa sind 50 Hz vorgesehen, für USA 60 Hz. Durch den Tausch des Editor-Roms bzw. Umprogrammierung des CRTC kann man die Frequenz ändern.

    Danke für die Info.


    Also kann man sagen:


    - Alle CBMs/PETs ohne CRTC: 60 Hz

    - CBMs/PETs mit CRTC: 50 Hz oder 60 Hz, software-abhängig


    Das bedeutet dann also auch, wenn man (beispielsweise ein Spiel) programmiert,

    welches auf 60 Hz ausgelegt ist, kann man bei Computern mit CRTC im Spiel auf 60 Hz umstellen(?).


    Klar, Jiffy Clock etc. haben dann evtl. ein Problem, aber kaputtmachen kann man damit nichts, oder?

    In "Programming the PET/CBM" von Raeto West steht, dass bei den 12" CBMs/PETs mit BASIC v4

    der Screen Retrace (Interrupt) mit einer Frequenz von 50 Hz "ausgelöst wird",

    im Gegensatz zu den anderen CBMs, die an dieser Stelle mit 60 Hz arbeiten.


    An der ISR sollte man das erkennen, da die Jiffy Clock wegen dieses Unterschieds anders "hochgezählt" werden muss.


    - Kann man so allgemein sagen, welche PET-Monitore mit 50 Hz und welche mit 60 Hz laufen?


    - Gibt es tatsächlich regional bedingte Unterschiede bezüglich dieser Frequenz, so wie z.B. beim C64 (zurückzuführen auf das Stromnetz)?


    Danke!

    Danke. Ach, ich hatte überlesen, dass auch Umlaute vorhanden sind.

    So wie hier (Nr. 6)?


    http://www.6502.org/users/sjgr…editrom/cbmkeyboards.html


    Mach doch sonst bitte mal ein Foto, würde mich interessieren!

    Was passiert, wenn man so ein POKE/SYS auf einem Computer mit 2K Character ROM ausführt?

    Werde ich sonst mal im Emulator testen..

    Bei POKE passiert gar nichts, weil der Video Controller Chip bei diesen Kisten fehlt.

    Das hieße ja, man kann davon ausgehen, dass alle CBMs mit CRTC ein 4K großes Character ROM haben. Bist Du Dir da sicher?

    Naja, wenn sie nur 2k haben, dann fehlt auch die Umschaltung per PRINT CHR... im Editor ROM ... :)

    Wäre jedenfalls sinnvoll. Damals wurde wahrscheinlich noch so ordentlich gearbeitet..

    Danke!


    Mir war nicht klar, wie ich den Wert für CHR_GRAFIC erhalte.


    Aber das würde dann ja so gehen:


    1. Eingeben:


    Code
    ?asc("

    2. Tastenkombination CTRL + rechte Hochstelltaste + B drücken


    3. Eingeben:


    Code
    ")

    4. Return drücken.


    Da kommt der PETSCII-Wert 130 heraus.


    Mit


    Code
    ?chr$(130)

    konnte ich schonmal "auf Englisch" umschalten.


    Ich teste das später mal in Assembler.