Hello, Guest the thread was called603 times and contains 27 replays

last post from faddie at the

String zu Hex int konvertieren

  • Moin,


    ich grüble gerade, wie ich einen Input String so konvertieren kann, dass ich damit rechnen kann.


    Der Spieler gibt einen max. 10 stelligen Wert ein und das "Spiel" macht dann irgendwas damit, z.B. $FF dazu addieren oder so.


    Meine Input-Routine speichert jedes Zeichen in einem Byte und ist Null-terminiert, das muss ich jetzt irgendwie konvertieren.

    $30 pro Byte abziehen, verstehe ich ja noch, weil PetSCII, aber dann wird es dunkel. Bisher beschränkten sich meine Eingaben auf Text und 0-9, das war überschaubar :)


    Gibt es da irgendeine effiziente Lösung, einen String in hex32 zu konvertieren?


    Danke und Gruß!

  • klingt erst mal nicht wesentlich schwieriger als die Umrechnung aus einem Dezimal-String


    Außenrum hast Du eine Schleife, die alle Zeichen durchläuft, bis sie auf den Null-String trifft.

    In der Schleife wird das Zwischenergebnis mit 16 multipliziert statt mit 10,

    dann wird das nächste Zeichen geholt.


    Innendrin hast Du eine Routine, die ein Zeichen in einen Wert umrechnet.

    Erstmal 48 abziehen, falls >=10 nochmal 7 abziehen, dann ein AND15, falls jemand Großbuchstaben eingegeben hat.

    Falls Du es ordentlich machen willst, dann ergänzt Du noch mehr Tests auf falsch eingegebene Zeichen und siehst eine Rückgabe für Fehler vor.

  • Danke erstmal für die Antwort. Ich versteh's aber irgendwie nicht ;(


    Jemand gibt also 255 ein und dann muss da intern $FF rauskommen

    Nach deinem Algorithmus wäre das dann: 5*16 + 5*16 + 2*16 ? Obwohl, von Addition hattest du ja nichts geschrieben. Dann käme auch $C0 und nicht $FF raus.


    Könntest du mir da nochmal auf's Pferd helfen?

  • Ich hab Dich so verstanden, dass der Spieler z.B. C000 eingibt und Du dann intern ganz normal mit der Zahl rechnen willst.

    Jetzt verstehe ich es so, dass Du eine normale dezimale Eingabe in eine normale Zahl umrechnen willst.


    Ist aber fast wie oben:

    -Du reservierst ein paar Bytes für das Ergebnis und initialisierst mit Null.

    -In der Schleife multiplizierst Du dieses Ergebnis mit 10

    -Dann nimmst Du eine Ziffer, ziehst 48 ab und addierst das auf das Ergebnis drauf.

    -Das machst Du bis zum Null-Byte.


    Die genaue Reihenfolge musst Du noch ausbaldowern ;)

    Wichtiger Punkt: Du multiplizierst in der Schleife das Zwischenergebnis, nicht die geholte Ziffer!

  • Und ich verstehe das wieder anders: Du hast eine dezimale Eingabe als String und willst eine Hexzahl als String bekommen?


    Vielleicht solltest du an einem Beispiel mal ganz klar machen, was genau du machen willst.


    Edit: Und wie lang kann die Eingabe sein? Sowas wie 255 oder 3289 oder auch sowas wie 823984239402380948902389048902389048092374376467546546523674525462?

  • Ich glaube, Hoogoo hat es richtig gedeutet: was ich vorhabe, ist eine Überweisung im Spiel.


    Spieler A gibt einen bis zu 10 stelligen Betrag ein.

    Dann prüft das Spiel, ob Spieler A überhaupt so viel Geld hat darauf wird der Betrag Spieler B gutschrieben und Spieler A abgezogen.


    Input-Routine ist fertig und prüft auf Ziffern und Zeichenlänge.


    cmp_h32, add_h32 und sub_h32 sind auch alle am Start. Nur die Konvertierung des Strings in h32 muss noch ausbaldowert werden ;)

  • detlef Ich wollte gerade eben dieselbe Seite posten (2min zu spät) und ungefähr dasselbe dazu sagen. ^^


    Das andersherumme dazu hat er auch .. http://www.6502.org/source/strings/32bit-to-ascii.html

    Ganz schön viele Zyklen gehen da drauf. So was wäre optimal für eine Mini-Competition. Das geht bestimmt schneller; da bin ich immer Optimist. :)


    p.s. Das BASIC-ROM kann das zumindest für 16bit-Zahlen, für Zeilennummern einlesen.

  • Ah, ok. Da hat mich deine "hex"-Bezeichnung verwirrt. Verstehe ich auch nicht so wirklich...wieso hex? Du willst doch letztendlich einen String in eine 32bit-Zahl umwandeln, oder? Was macht das hex da? Das ist doch nur eine Darstellungsweise der Zahl. Du könntest die auch dezimal, binär, oktal oder sonstwie darstellen...die Bytes bleiben dieselben. Oder habe ich da was nicht kapiert (kann gut sein...)?

  • Ah, ok. Da hat mich deine "hex"-Bezeichnung verwirrt. Verstehe ich auch nicht so wirklich...wieso hex? Du willst doch letztendlich einen String in eine 32bit-Zahl umwandeln, oder? Was macht das hex da? Das ist doch nur eine Darstellungsweise der Zahl. Du könntest die auch dezimal, binär, oktal oder sonstwie darstellen...die Bytes bleiben dieselben. Oder habe ich da was nicht kapiert (kann gut sein...)?

    Binärdaten werden ja oft Hexadezimal dargestellt (in Assembler). Ich denke daher die Verwirrung. Mit Hex hat das in diesem wohl wirklich nichts zu tun.

  • p.s. Das BASIC-ROM kann das zumindest für 16bit-Zahlen, für Zeilennummern einlesen.

    Das kann das auch für 32bit-Zahlen. Man müsste den String dazu erst in Gleitkomma wandeln und dann den FAC-Inhalt mit $BC9B in eine (vorzeichenbehaftete) 4 Byte-Zahl. Das wird sicher nicht sehr effizient sein, aber dafür kurz. Und Geschwindigkeit dürfte für diese Anwendung ja eher keine Rolle spielen.

  • Ich war leider die letzten Tage unterwegs und musste das Thema etwas ruhen lassen, aber ich wollte den Algorithmus zumindest mal auf dem Papier ausprobieren.

    Und ja, das mit Hex ist wirklich irreführend, ich wusste, unerfahren wie ich bin, nicht genau, wie ich "Zahl für Rechnen in dat 6510" ausdrücken sollte :D


    Also:


    Eingabe ist 2,5,5

    Im Speicher steht dann 50 53 53 0


    Algorithmus


    1. Loop

    0 Byte? Weiter

    2 * 0 = 0

    50 - 48 = 2

    2 + 0 = 2



    2. Loop

    0 Byte? Weiter

    2 * 10 = 20

    53-48 = 5

    5 + 20 = 25


    3. Loop

    0 Byte? Weiter

    25 * 10 = 250

    53-48 = 5

    5 * 250 = 255


    4. Loop

    0 Byte? Ende!



    Ungefähr so?

  • Kann man machen; könnte man aber auch lassen. Du müsstest die andere Zahl, wo du das dazu addieren willst, auch noch umwandeln. Dann mit 32bit-Addition addieren und dann das ganze wieder zurück konvertieren. Da fragt sich, ob sich das mit der ganzen Konvertierung überhaupt lohnt.


    Man könnte stattdessen für 10-stellige Dezimalzahlen (nur die Ziffern wandeln mit -48/+48) auch eine direkte Addition und Subtraktion, wie man es in der Schule gelernt hatte, programmieren und spart sich damit den Aufwand der Konvertierung. Die Dezimalfunktion des Prozessors kann dabei behilflich sein. Die Subtraktion dient gleichzeitig für Größenvergleiche, obwohl man das bei Bedarf erheblich beschleunigen könnte. Auch die Multiplikation und Division könnte man so machen. Vielleicht hat das auch längst irgendjemand getan in einem Wirtschaftsspiel.



  • 5 + 20 = 25

    Eingabe ist 2,5,5

    Im Speicher steht dann 50 53 53 0

    ...

    Würde ich in diesem Fall genau so machen. Für die Multiplikation musst du halt noch mal einen Schleife vorsehen. Da max. mit 9 multipliziert wird, ist eine Schleife akzeptabel. Ausserdem geht es um die Konvertierung einer Eingabe, das ist sowieso nicht zeitkritisch. Die Additionen sind dann 16-, 24- oder 32-bittig. Je nachdem, wie groß die Zahlen werden können.

  • Kann man machen; könnte man aber auch lassen. Du müsstest die andere Zahl, wo du das dazu addieren willst, auch noch umwandeln. Dann mit 32bit-Addition addieren und dann das ganze wieder zurück konvertieren. Da fragt sich, ob sich das mit der ganzen Konvertierung überhaupt lohnt.


    Man könnte stattdessen für 10-stellige Dezimalzahlen (nur die Ziffern wandeln mit -48/+48) auch eine direkte Addition und Subtraktion, wie man es in der Schule gelernt hatte, programmieren und spart sich damit den Aufwand der Konvertierung. Die Dezimalfunktion des Prozessors kann dabei behilflich sein. Die Subtraktion dient gleichzeitig für Größenvergleiche, obwohl man das bei Bedarf erheblich beschleunigen könnte. Auch die Multiplikation und Division könnte man so machen. Vielleicht hat das auch längst irgendjemand getan in einem Wirtschaftsspiel.

    Soll ja nicht unüblich gewesen sein, je Dezimal-Ziffer 1 Byte zu verwenden, besonders bei Scores.
    Aber RICHTIG rechnen, mehrstellige Zahlen hinzuaddieren oder gar multiplizieren? Klingt irgendwie nicht spaßig.