6502 Assembler - Zweck einer Funktion

[Marco W. (watz)]

Hi!

Ich bin über ein Stück 6502 Maschinencode von einer Art Bytecode 
Interpreter gestolpert und erfasse den Sinn einer Funktion nicht. 
Vielleicht hat jemand von euch sowas schoneinmal gesehen?

Hier ist, was ich bis jetzt glaube verstanden zu haben:
- Die Funktion greift auf einen Stack von 16 Bit Werten zu. Die Lobytes 
liegen ab $A408, die Hibytes ab $A42C. X enthält den 0-basierten Index 
des letzten gültigen Stackeintrags.
- Das X Register ist beim Aufruf der Funktion = 1 und beim Verlassen = 
0. Sie bekommt also zwei 16 Bit Werte über den Stack rein und gibt einen 
16 Bit Wert über den Stack zurück.
- Sie rollt die Bits von stack[2] und stack[1] 16 mal nach rechts. Sieht 
mir wie das Rollen eines 32 Bit Wertes um 16 Bit nach rechts aus.
- Jedes mal, wenn Bit 0 von stack[1] (also quasi Bit0 des 32 Bit Wertes) 
gesetzt ist, wird der Wert an stack[2] (also quasi das Hiword des 32 Bit 
Wertes) um den Wert an stack[0] erhöht. (??)

A53B   A0 10      LDY #$10
A53D   A9 00      LDA #$00
A53F   9D 2D A4   STA $A42D,X        // stack[2] nullen (temp variable)
A542   9D 09 A4   STA $A409,X        // "
  A545   BD 08 A4   LDA $A408,X      // A = stack[1] lobyte
  A548   4A         LSR A            // A /= 2
  A549   90 13      BCC $A55E        // A % 2 == 0 ? goto A55E
    A54B   18         CLC
    A54C   BD 09 A4   LDA $A409,X    // stack[2] += stack[0]
    A54F   7D 07 A4   ADC $A407,X    // "
    A552   9D 09 A4   STA $A409,X    // "
    A555   BD 2D A4   LDA $A42D,X    // "
    A558   7D 2B A4   ADC $A42B,X    // "
    A55B   9D 2D A4   STA $A42D,X    // "
  A55E   7E 2D A4   ROR $A42D,X      // stack[2] nach rechts rotieren
  A561   7E 09 A4   ROR $A409,X      // "
  A564   7E 2C A4   ROR $A42C,X      // stack[1] nach rechts rotieren
  A567   7E 08 A4   ROR $A408,X      // "
  A56A   88         DEY              // Y--
  A56B   D0 D8      BNE $A545        // Y > 0 ? goto A545
A56D   BD 08 A4   LDA $A408,X        // pop stack[1], speichere in stack[0]
A570   9D 07 A4   STA $A407,X        // "
A573   BD 2C A4   LDA $A42C,X        // "
A576   9D 2B A4   STA $A42B,X        // "
A579   CA         DEX                // "
A57A   60         RTS

Gruß,
Marco

[Markus (Gast)]

Apple Byte Code VM:
https://en.wikipedia.org/wiki/SWEET16

[foobar (Gast)]

Sieht nach einer Multiplikation aus ...

[Marco W. (watz)]

foobar schrieb:
> Sieht nach einer Multiplikation aus ...

Darüber muss ich mal nachdenken...

Der Code ist übrigens aus der C64 Version von Sid Meiers Pirates! und 
ist eine der vielen Operationen dieses Bytecode Interpreters. Aber 
SWEET16 ist es nicht, denn die Opcodes passen nicht.

[Wolfgang (Gast)]

Marco W. schrieb:
> Hier ist, was ich bis jetzt glaube verstanden zu haben:

Das Verständnis würde steigen, wenn du den Code nicht willkürlich 
einrücken würdest

> A54C   BD 09 A4   LDA $A409,X    // stack[2] += stack[0]

Das ist eine ganz gewöhnliche absolut x-indizierte Adressierung. Damit 
da etwas sinnvolles passiert, muss das x-Register vor Einsprung in die 
Unterroutine vernünftig belegt werden.

Der Prozessorstack des 6502 liegt zwischen 0x0100 und 0x01FF, nicht bei 
0xA4..

[Apple Asi (Gast)]

Wolfgang schrieb:
> Der Prozessorstack des 6502 liegt zwischen 0x0100 und 0x01FF, nicht bei
> 0xA4..

Naja, das ist eben nicht der Stack des Prozessors sondern
(ich nenne es mal) eine Arbeits-Page des Programms in der
verschiedene Objekte im Index-Raum 0...255 bearbeitet werden
können.

[Marco W. (watz)]

foobar schrieb:
> Sieht nach einer Multiplikation aus ...

Der Kandidat hat 100 Punkte! Danke ;-)

Habs mit nem 6502 Simulator laufen lassen:

#include <cstdint>
#include <fstream>
#include "mos6502.h"

uint8_t ram[0x10000];

void BusWrite(uint16_t addr, uint8_t val)
{
    ram[addr] = val;
}

uint8_t BusRead(uint16_t addr)
{
    return ram[addr];
}

void ExecUnknownFunc(uint16_t arg1, uint16_t arg2)
{
    ram[0xA408] = arg1 & 0xff;
    ram[0xA42C] = (arg1 >> 8) & 0xFF;
    ram[0xA409] = arg2 & 0xFF;
    ram[0xA42D] = (arg2 >> 8) & 0xFF;

    mos6502 cpu(BusRead, BusWrite);
    cpu.Reset(0xA53B);
    cpu.X = 1;
    uint64_t cycleCount = 0;
    while(cpu.pc != 0xA57A)
    {
        cpu.Run(1, cycleCount);
    }

    uint16_t res = ram[0xA42c] << 8 | ram[0xA408];
    std::cout << "ExecUnknownFunc(" << arg1 << ", " << arg2 << ") = " << res << "\n";
}

int main()
{
    std::ifstream ramfile("ramimage.bin");
    if(ramfile.is_open())
    {
        ramfile.read((char*)ram, sizeof(ram));
        ramfile.close();
    }

    ExecUnknownFunc(0, 0);
    ExecUnknownFunc(1, 1);
    ExecUnknownFunc(11, 55);
    ExecUnknownFunc(20, 2200);
    ExecUnknownFunc(111, 8);

}

Vollständiger Code ist im Anhang. Ergebnis:

ExecUnknownFunc(0, 0) = 0
ExecUnknownFunc(1, 1) = 1
ExecUnknownFunc(11, 55) = 605
ExecUnknownFunc(20, 2200) = 44000
ExecUnknownFunc(111, 8) = 888

[Wegstaben V. (wegstabenverbuchsler)]

der Ursprungs-Beitrag ist übrigens ein schönes Beispiel dafür, wie 
kniffelig es ist, "reverse engineering" zu betreiben, und aus 
disassemblierten Code wieder sogar nur einzelne Codefragmente 
"einfacher" Funktionen in einer Hochsprache herzuleiten.

einen vernünftigen komplexen Algorithmus (z.B. Fourier Transformation, 
trigonometrische Funktionen, Bresenham, Sortieralgorithmen etc) aus 
"einer handvoll arithmetischer oder Zeiger-Operationen" heraus 
herzuleiten, ist dann die nächste Weihe-Stufe.