print im IOS

[digger]

Wenn ich die Funktion "ios.print" verwende, nachdem ich mit "ios.cursetx"/"ios.cursety" den Cursor plaziert habe, dann wird nach dem ausgegebenen String immer noch ein Zeichen gelöscht bzw. eine Leerzeichen ausgegeben.
Ich glaube da wird ein "unsichtbarer" Cursor gesetzt, obwohl ich diesen eigentlich mit "ios.curoff" abgeschaltet habe. Hab mir die "reg-ios.spin" angesehen, aber konnte da die Ursache nicht wirklich eingrenzen/beheben.

Jemand einen Tipp für mich?

[drohne235]

Versuch mal folgenden Testcode. Die Ausgabe scheint mir ok zu sein, da wird kein Zeichen zusätzlich ausgegeben.

Code: Alles auswählen

OBJ
        ios: "reg-ios"

CON

_CLKMODE     = XTAL1 + PLL16X
_XINFREQ     = 5_000_000

PUB main | key

  ios.start
  ios.curoff
  ios.printcls

  ios.print(string("string1"))
  ios.print(string("string2"))

  ios.cursetx(10)
  ios.cursety(10)
  ios.print(string("string1"))
  ios.print(string("string2"))

  ios.stop

[digger]

Danke ... verdammt ... nach genauem hinsehen, hab ich mich doch mit der Reihenfolge vertan.
Ich habe ios.curoff doch erst NACH der Ausgabe aufgerufen, dadurch gabs bei den Ausgaben hinten dran immer noch ein gelöschtes Zeichen.

[digger]

Da ich meine SNES Buchsen noch nicht hab, versuch ich mich erstmal an was anderem was ich ein bischen auf dem HIVE vermisse.

[PIC18F2550]

schon ferdig?

[digger]

nein, ich kämpfe noch mit der ramdisk, ich möchte von sdcard in ramdisk kopieren, um dann wieder zurück auf eine andere gemountete sdcard kopieren zu können.
ich habe noch immense wissenslücken die es zu füllen gilt. frau meckert schon ein bisschen.

[drohne235]

Das sieht super aus.

Bezüglich der Dateioperationen vielleicht noch eine Idee: Ich habe bislang noch kein richtiges Copy-Kommando im TriOS, die Not war einfach noch nicht groß genug. Letztlich kann man mit xload/xsave ja auch jetzt schon kopieren. Früher bei SpinOS hatte ich ein Kommando, welches mit dem externen RAM arbeitet. Aber irgendwie gefällt mir das nicht wirklich und ich hab mir folgende Frage gestellt: Warum sollen bei einem Kopiervorgang die Date quer durch den Hive und viermal (adm --> reg, reg --> xram, xram --> reg, reg --> adm) über den langsamen Metabus kopiert werden? Das ist Quatsch auf dem Hive mit seinen verteilten Ressourcen. Viel besser wäre eine Copy-Funktion direkt in Administra, so wie es dort ja auch schon eine Funktion zum löschen oder umbenennen gibt. Das wäre dann auch sehr schnell, da die Datenmengen im Administra-Chip bleiben. Ich dachte dabei an ein "ios.sd_cp(stradr1,stradr2)" und ein "ios.sd_cpstat:status". Mit der Statusfunktion kann man den aktuellen Fortschritt der Kopierfunktion abfragen und hat so auch bei Bedarf einen schönen Fortschrittsbalken. Sollte auch nicht so riesig kompliziert sein so eine Kopierfunktion.

Die Software muß aber dann unterscheiden können, ob es ein Kopiervorgang sdcard --> sdcard oder sdcard --> xram ist.