OSI Superboard II Basic String Funktionen

    Liebe Tüftler und Bastler


    Ich habe da ein etwas seltsames Problem mit meinem OSI Superboard II, Modell 600. Nach einem Kaltstart, CLEAR oder RUN verhalten sich sämtliche Stringfunktionen eigenartig.

    Eine Stringzuweisung z.B. A$="OSI" wird mit OK quittiert, ein anschliessendes PRINT A$ liefert nur wirre Zeichen. Auch alle Funktionen wie LEFT$(), MID$(), CHR$() usw ergeben ausnahmslos ungültige Resultate.

    Erstaunlich ist, dass nach einer Stringzuweisung vom mehr als 10 Zeichen (A$="0123456789") plötzlich alles normal funktioniert, allerdings nur bis zum nächsten CLEAR oder RUN. Diese Zuweisung ist jedoch innerhalb eines Programms nicht wirksam. Um ein Programm mit besagten Funktionen laufen zu lassen, muss die 10-Zeichen-Zuweisung im Direktmodus erfolgen, gefolgt von einem GOTO <Programm-Start-Zeile>.


    Ich habe auch gelesen (https://www.osiweb.org/software.html#BASIC_ROMS) dass ein Bug in den ROMs vorhanden ist, der aber nur die Garbage Collection betrifft, dürfte für genanntes Problem nicht relevant sein (oder doch?).


    Ich habe alle BASIC ROMs ausgelesen und mit Images aus dem Netz verglichen, ohne Fehler. Ebenso war der RAM-Test (8k) erfolgreich.

    Ich verwende den CEGMON Monitor.


    Hat jemand eine Idee, woran dies liegen könnte?


    Schon mal vielen Dank

    Tony

    Zitat von t.schlumpf

    Hat jemand eine Idee, woran dies liegen könnte?

    Eine Idee schon.


    Leider aber auch keinerlei Ahnung von diesem System.

    Insofern kann meine "idee" auch völliger Quatsch sein.



    Beim Commodore BASIC bekommt man genau dieses Ergebnis, wie von dir Beschrieben, wenn der Hi RAM defekt/nicht vorhanden ist.


    Commodore BASIC legt Variable ab im "unteren" RAM, gleich nach dem BASIC Code.

    Das gilt auch für String Variable.

    Aber nicht für die Strings selbst, die werden von "oben" nach unten angeordnet.


    Wenn also da oben kein RAM ist, dann wirkt sich das genau so aus.

    Beim Commodore ist das zb. so, wenn:

    • ein Modul ROM (Cartridge) eingeblendet wird, wo normal RAM ist
    • der HIMEM Pointer zu "hoch) gestellt ist, sodass der ins ROM zeigt


    Bei einem "speziellen" RAM defekt, der nur HIMEM betrifft, würde man auch dieselben Symptome sehen.

    Hallo Diddl


    Danke für den Tip mit dem RAM. Ich werde ein Assembler-Programm basteln, mit dem ich auch normalerweise von Basic belegte Seicherbereiche testen kann. Viellecht gibt das neue Erkenntnisse.


    Liebe Grüsse

    Tony

    Ich habe eine Lösung gefunden, obwohl das eigentliche Problem immer noch vorhanden ist:


    Bei der Abfrage der Memory-Size beim Basic-Kaltstart einen Wert ein wenig unterbalb des Maximums eingeben, dann läufts wie geschmiert.


    Bei 8k RAM (8192 Bytes) läufts bis 8179 (ergibt 7410 freie Bytes), bei 8180 nicht mehr. Am RAM kanns nicht liegen, der Test läuft erfolgreich. Es sieht doch eher nach einem Problem mit der Garbage-Collection aus. Nach längerer Laufzeit eines Programms mit viel Stringmanipulationen tritt der Fehler mit dieser Einstellung wieder auf.

    Mit 8100 habe ich den Fehler auch nach Stunden Laufzeit nicht mehr gesehen.


    Tony

    Das Problem ist nun definitiv gelöst.

    Zitat von Diddl

    Bei einem "speziellen" RAM defekt, der nur HIMEM betrifft, würde man auch dieselben Symptome sehen.

    Diddl, Du liegst richtig. In einem RAM-Sockel (an oberster Adresse, hier legt das Basic seine Strings ab) war eine Kontaktfeder so verbogen, dass er mit dem IC-Bein keinen Kontakt mehr hatte. Die IC-Beine etwas zusammengedrückt, alles läuft wie es sollte.


    Tony