Posts by Mac Bacon

    EDIT: mal wieder viel zu langsam... :D

    Gibt es irgendeine Syntax, mit der das doch möglich ist?

    Nein. Die entsprechende Adressierungsart existiert nicht, und wenn der Wert von X - wie im Beispiel - erst zur Laufzeit feststeht, können auch entsprechende Assembler-Direktiven oder -Makros nicht helfen.

    Ich könnte natürlich die erste Variante von oben nehmen und dann in der Routine auf das y das entsprechende Vielfache von 3 dazuaddieren, aber das will ich nicht. Die Routine steht und soll nicht geändert werden.

    Es muss ja nicht die Routine selbst geändert werden, die Umrechnung kann vor dem Aufruf der Routine gemacht werden:

    Code
    1. lda #<daten
    2. clc
    3. adc offset; addiere Vielfaches von 3
    4. sta $fb
    5. lda #>daten
    6. adc #0; ggfs. Highbyte anpassen (add carry)
    7. sta $fc


    Allerdings braucht man einen Offset von 3 eher selten. Wenn Du etwas weiter ausholst, kann man das Problem evtl. auch viel einfacher lösen.

    Theoretisch koennte man also auch einen Joystick bauen, der 2 Anschluss-Kabel hat, und dann seine 2 Feuerknoepfe auf die beiden Ports verteilt, und damit koennte man dann Commando usw ebenfalls zocken.

    Ich hab mal aus einem Stückchen Flachkabel und vier DE-9-Schneid/Klemm-Steckern einen Adapter gebastelt, der den zweiten Feuerbutton von Amiga- oder Sega-Pads auf den ersten Feuerbutton des jeweils anderen Ports umleitet.

    Paddles darf man daran dann natürlich nicht mehr anschließen, die CIA soll ja keine 5V abbekommen.

    Die haben beide das tupfengleiche Label, aber scheinbar tatsächlich unterschiedliche Kapazitäten. Ich weiß, das später nur noch die 4464er mit der höheren

    Kapazität verwendet wurden, aber der Fall ist mir unbekannt.


    Schon mal jemand ähnliche Erfahrungen gemacht?

    Das nicht, aber es erklärt ein altes Rätsel: Irgendwo im Netz hat mal jemand geschrieben, dass einige C128 und C128D bereits ab Werk mit 64 K VDC-RAM bestückt waren (obwohl das ja eigentlich erst mit dem DCR zum Normalfall wurde).

    Vielleicht waren das solche Chips - also Commodore hat 4416er gekauft und verbaut, aber ein entsprechendes VDC-RAM-Testtool erkennt sie korrekt als 4464er.

    Ich hab mich mit dem C16-Kernal bislang nicht auseinandergesetzt - ich hab das Ding erst seit ein paar Tagen - zieht der C16 einen

    vollständigen Speichertest analog zum C64 / $FD50 durch oder -weil er ja im Verhältnis gesehen recht schnell geht- klappert er nur

    die ersten paar Speicherstellen der hjeweiligen 256 Byte- Page ab?

    AFAIK testet der C16/+4-Kernal nur zwei Speicherstellen, nämlich um 32K und 64K zu erkennen, mit 16K als Fallback.

    Hierbei stellt dich die Frage, wie Floats im BASIC-Interpreter gespeichert werden und wo die Routinen zu z.B. Addition und Subtraktion zu finden sind.

    Kuckstu hier:

    https://sourceforge.net/p/acme…trunk/ACME_Lib/cbm/flpt.a

    https://sourceforge.net/p/acme…runk/ACME_Lib/cbm/mflpt.a

    https://sourceforge.net/p/acme…/ACME_Lib/cbm/c64/float.a


    Das geschilderte Problem würde ich allerdings eher mit einer vorberechneten Sinustabelle zu lösen versuchen, nicht mit echten Floats. Also man unterteilt den Vollkreis in 256 mögliche Richtungen für den Ball und holt für jede Richtung einfach Delta-X und Delta-Y aus der Tabelle, gerne auch als Fixedpoint...

    Wo bekomme ich denn ein Image her um eins der RAM Erweiterungsmodule einzubinden?

    Um eine REU und/oder GeoRAM zu aktivieren, brauchst Du kein Image. Bei echter Hardware ist der Erweiterungsspeicher nach dem Einschalten ja auch leer. Der Menüeintrag von Deinem Screenshot ist eine Funktion, die es an echter Hardware gar nicht gibt, nämlich, zur Laufzeit den Speicher der Erweiterung mit dem Inhalt einer Datei zu füllen.

    Ah, verdammt ... ich falle immer wieder mit dem ASCII-Code auf die Fresse ... die Bildschirmcodes der Buchstaben sind ja um $40 niedriger. :cursing:

    Ist ja nicht unbedingt falsch - da hier LOAD+LIST benutzt wurde, kann es durchaus auch der Zeichencode sein, da läge der Fehler dann eben bei $08xy. Aber zwei Bitfehler an der gleichen Adresse? Da ist ein einzelner Fehler im Screen deutlich wahrscheinlicher.


    Es können ja noch weitere Wetten abgegeben werden. :D

    Das $-Zeichen ($24) statt dem Leerzeichen ($20) auf Bild 2 und 3, zusammen mit dem "?OUT OF MEMORY ERROR" deutet auf ein defektes RAM-Bit 2 hin.

    Da im ersten Bild kein "$" zu sehen ist, wäre ich da vorsichtig. Es kann natürlich ein sporadisch auftretender Fehler sein, aber ebensogut könnte die Bildschirm-Speicherzelle in Ordnung sein und das "$" durch einen Fehler in einem ZP-Pointer entstanden sein.

    Ah, da ist noch eine ")" ($29) statt eines "I" ($49) in "EXIT" - da wären dann gleich Bit 5 und 6 im Eimer.

    Falls der Fehler im Bildschirmbereich liegt: Die Screencodes unterscheiden sich nur in Bit 5, bei ")" ist es gesetzt. Da dieses Bit auch im Screencode von Space gesetzt ist, fiele dieser Fehler bei gelöschtem Bildschirm nicht auf.

    Lass doch vielleicht zuerst Mac Bacons Speichertestprogramm laufen:

    Sollte das Laden/Starten nicht funktionieren, könnte man auch noch dies versuchen: for a = 1024 to 2023:poke a, 223:next

    Damit sollten genau die Fehler sichtbar sein, die man bei Spaces nicht sehen kann.

    Es gibt Befehle, die nach einem THEN sauber verarbeitet werden, andere nicht.

    Eine Möglichkeit wäre, Zeile 314 zu ändern von

    elsif (match = /^(?<code>then\s*(go(sub|to))|then|go(sub|to))\s*(?<labels>[\w\s,.]+)+/

    zu

    elsif (match = /^(?<code>go(sub|to))\s*(?<labels>[\w\s,.]+)+/


    Dann werden Labels nur noch hinter GOTO und GOSUB erwartet, nicht mehr hinter THEN. Sowas wie IF condition THEN target funktioniert dann natürlich nicht mehr, da muss man dann IF condition GOTO target oder IF condition THEN GOTO target schreiben. Ein richtiger Fix ist das also nicht, aber vielleicht hilft es ja.

    Es werden Leerstrings wie i$="" nicht korrekt erkannt / übersetzt.

    Änder mal Zeile 310 von

    if (match = /^["](?<string>[^"]+)["]/.match(@text))

    zu

    if (match = /^["](?<string>[^"]*)["]/.match(@text))


    Falls der Woltlappen jetzt was zerhaut: Es geht nur darum, das Pluszeichen durch ein Sternchen zu ersetzen. Das Pluszeichen sagt, dass zwischen Doublequotes mindestens ein Zeichen stehen muss (also keine Leerstrings erkannt werden), bei einem Sternchen sind auch "Null Zeichen" erlaubt.


    Ich hab das jetzt nicht groß getestet, das überlass ich Dir. ;)

    Betreiben würde ich sie am Cevi.

    Am C64 wird das REU-EPROM nicht in den Adressraum eingeblendet, da müsste man erst herumbasteln (GAME und/oder EXROM auf Ground legen). Nur: wenn dann die Software vom EPROM erst einmal gestartet ist, würde man die Einblendung wieder abschalten wollen, und damit das per Software geht, braucht man noch ein bisschen mehr Gebastel.

    EDIT: zu spät.

    Was hat dann Priorität - mein IRQ-Handler oder der CIA-IRQ? Springt dann der Prozessor kurzzeitig aus meiner Routine raus, um nach dem Abarbeiten des CIA-IRQs wieder neu einzuspringen? Oder wartet er auf mein RTI?

    Das hängt vom Zustand des entsprechenden Statusflags ab:

    Nach SEI ist der Interrupt gesperrt, nach CLI ist der Interrupt freigegeben.

    Ist der Interrupt freigegeben und liegt tatsächlich an, so macht die CPU drei Dinge:

    1. Rücksprungadresse und Statusregister werden auf den Stack geschrieben.

    2. Das Sperrflag wird gesetzt.

    3. Der Handler wird angesprungen.

    Beim Rücksprung durch RTI wird neben der Rücksprungadresse auch wieder das Statusregister vom Stack geholt und somit das Sperrflag wieder gelöscht.


    Wenn Du also in Deiner Handlerfunktion weitere (geschachtelte) Interrupts zulassen willst, musst Du nur CLI ausführen lassen und schon geht das. Allerdings muss man vorher die eigene Interruptquelle matürlich quittiert haben, sonst hängt die CPU in einer Endlosschleife.


    EDIT: Das alles gilt nur für den "normalen" Interrupt, aber natürlich nicht für NMI und Reset.

    irgendwo hab' ich mal gelesen, wie viele files auf der 1541 gleichzeitig offen sein dürfen.

    wenn ich mich richtig erinnere, so sind das

    - 1x par / 2x ser

    - 3x ser

    ich find das aber nicht mehr, wo ich das her hab.

    Ganz ehrlich? Probier es aus. Handbuchweisheiten sind im Zweifelsfall eh falsch.


    Ich meine mich zu erinnern an:

    Die 1541 hat fünf Puffer im RAM, davon ist einer immer durch die BAM belegt, bleiben vier.

    SEQ und USR brauchen jeweils nur einen Puffer, PRG braucht zwei, REL braucht drei. Das Laden von "$" braucht auch einen.


    Aber wie gesagt... probier es lieber aus, dann bist Du auf der sicheren Seite.

    Wahrscheinlich ist der VDC nicht korrekt initialisiert.


    Klingt ein bisschen wie das, was Mac Bacon da schreibt, scheint aber unabhängig vom Refresh zu sein und die grundsätzliche Initialisierung zu betreffen.

    Ich tippe auf "beides": Egal wie nicht-initialisiert der VDC ist, fällt mir außer einem falschen Refresh nicht viel ein, was die Nutzung des RAMs behindern könnte.

    Hier sind mal die aktuellen Quellen

    Danke. Da werden ja jetzt alle Register beschrieben, die auch der C128-Kernal setzt. Wenn Du Speicher sparen willst: Es müsste(tm) auch reichen, wenn Du Dich auf die Register 0, 1, 22, 25, 28 und 36 beschränkst, die anderen Register sollten(tm) keinen Einfluss aufs RAM-TIming haben.