Erste Vectrex Gehversuche ...

  • Erste Vectrex Gehversuche ...

    So, ich habe mich mal 2 Tage dazu aufgerafft, ein bisschen Vectrex programmieren zu lernen. Ich lade einfach mal spaßeshalber den bisherigen Erguss hoch, der alles andere als ein fertiges Programm ist. Wer die Möglichkeit hat, das mit einem VecMulti oder ähnlichen Modul zu testen, kann es ja mal ausprobieren. Geht natürlich auch mit MESS, wenn man denn das Teil eingerichtet kriegt.
    Das ganze soll mal später ein Port von dem Arcade-Klassiker "Juno First" werden.
    ENJOY !
    juno_first.bin
  • Sieht sehr vielversprechend aus ! hab's grad kurz auf meiner Entwicklungsvectrex gestartet:
    Bildaufbau ist stabil, Geometrie gut bis sehr gut: ich sehe im Bild einige Probleme bei den Sprites, typisch
    für echte Hardware wenn man erst auf Emulator programmiert, aber nichts tragisches: da fehlen ein paar
    Zyklen beim ein/ausschalten des Strahl von vertex zu vertex, weswegen da je nach Lage mehr oder weniger
    lange Stücke der Linien fehlen. Ich würd bei den Gegnern den Strahl erstmal immer anlassen, dann sind diese
    Fehler bei diesen Einheiten weg, nur am Ende könnte dann noch was abgeschnitten werden.

    Ebenso ist die Geometrie des Spielerschiffes instabil - es ist verzerrt, wenn es weiter oben gezeichnet ist,
    wahrscheinlich gleiches Problem wie bei den Gegnern, die selbstgeschriebene Zeichenroutine wurde vermutlich
    wenn überhaupt nur auf einer Vectrex bisher getestet - die unterschiedlichen 6522 in verschiedenen
    Vectrexeinheiten resultieren dabei in unterschiedlicher Ausgabe, wenn man es nicht etwas managt,
    die unterscheiden sich in bis zu 3 Zyklen.

    Ich habe übrigens auch gerade angefangen, mich mit Juno First für die Vectrex zu beschäftigen, werde
    dann aber vielleicht ein anderes Spiel machen. Dann muss Deins aber wirklich gut werden !
  • RetroJeck schrieb:

    wenn überhaupt nur auf einer Vectrex bisher getestet - die unterschiedlichen 6522 in verschiedenen
    Ich habe das auf meiner GCE Vectrex getestet, die MB-Vectrex müßte ich rauskramen. Ich weiss nicht, ob ich das richtig verstanden habe, aber jetzt schalte ich den Strahl füher ein. Mündet allerdings in weisse Punkte an den Linienenden ...
    juno_first.bin

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von peiselulli ()

  • Das ging ja fix.. beim neuen Binary sind die Fehler weg :)

    Und genau: das 'keine weissen Enden' hinzukriegen ist das Problem - da der Output des shiftregisters bis
    zu 3 Zyklen variiert muss man es ans Ende dieses Zeitkorridors legen. Liegt nicht an der Version der Vectrex, ich kenne
    MB Varianten mit langsamem 6522 und schnellen, mein no-buzz MB hat nur einen Zyklus delay gegen meiner
    schnellsten GCE, eine weitere GCE hat jedoch ganze 3 Zyklen delay. Bei normalem Zeichnen geht dies noch halbwegs,
    aber ich habe auf den wirklich letzten Zyklus optimierte Bitmap/Textroutinen, für die dies die Hölle ist.

    Deswegen habe ich sie für langsamere rausgeworfen ausserhalb meines Entwicklungsbiotops hier..

    Im übrigen gibt es auch 6522, die unterschiedlich auf ein zu frühes Wiederprogrammieren (vor 18 Zyklen) reagieren,
    einige 'stallen' nicht sondern schalten auf immer 1. Es gibt aber einige Zyklen dazwischen, wo alle bisher aufgetauchten
    'stallen', diese sicheren Zyklen könnte man also zum optimieren verwenden. Das ist aber erstmal vielleicht zuviel Info.

    Ansonsten seh ich im disasm, das nur noch wenige Systemroutinen benutzt werden, das ist für Performance der
    absolut richtige Weg, hier ist als Ersatz auch noch ein schnelleres 'get_buttons', das nutzt zwei Variablen, eine zeigt
    nur die Veränderungen an:

    get_buttons
    LDD #$190E
    STB VIA_port_a
    STA VIA_port_b
    LDD #$0001
    STB VIA_port_b
    STA VIA_DDR_a
    LDA #$09
    STA VIA_port_b
    NOP
    LDA VIA_port_a
    STB VIA_port_b
    LDB #$FF
    STB VIA_DDR_a
    LDB get_buttons_state
    COMA
    STA get_buttons_state
    COMB
    ANDB get_buttons_state ; and with inverted previous state:
    STB cur_buttons ; only button changes reported this way
    RTS

    und hier eine get_joy_digital Variante, andere Genauigkeit kann man beim LDA #$40, STA VIA_port_a einstellen
    (gemeint ist, wie sehr man den Stick aus der Nullposition heraus bewegen muss, z.B. bei $60 braucht man
    es halt weniger)

    get_joystick_digital
    LDD #$0300
    STD VIA_port_b
    DEC VIA_port_b
    LDB #$20
    get_joystick_digital_y_delay
    DECB
    BNE get_joystick_digital_y_delay
    STA VIA_port_b
    LDA #$40
    STA VIA_port_a
    LDD #$0120
    BITB VIA_port_b
    BNE get_joystick_digital_y_end
    NEG VIA_port_a
    NEGA
    BITB VIA_port_b
    BEQ get_joystick_digital_y_end
    CLRA
    get_joystick_digital_y_end
    STA cur_joy_y
    ; RTS

    get_joystick_digital_x
    LDD #$0100
    STD VIA_port_b
    STB VIA_port_b
    LDB #$20
    get_joystick_digital_x_delay
    DECB
    BNE get_joystick_digital_x_delay
    STA VIA_port_b
    LDA #$40
    STA VIA_port_a
    LDD #$0120
    BITB VIA_port_b
    BNE get_joystick_digital_x_end
    NEG VIA_port_a
    NEGA
    BITB VIA_port_b
    BEQ get_joystick_digital_x_end
    ; LDB get_buttons_state ; if one wants to use buttons
    ; BITB #$02 ; as joystick left/right..
    ; BNE get_joystick_digital_x_end
    ; NEGA
    ; BITB #$04
    ; BNE get_joystick_digital_x_end
    CLRA
    get_joystick_digital_x_end
    STA cur_joy_x
    RTS

    Ein waitrecal oder sound_byte hab ich auch noch, wenn man die Systemroutinen nicht benutzt, kann man sich
    auch die $80 RAM am Anfang greifen ;)
  • Gern geschehen, das hatte ich mir auch schon gedacht, als ich gesehen habe, wie der Code aufgebaut ist - so hatte
    ich auch angefangen und dann nach und nach alles Systemartige ersetzt. Ansonsten programmiere ich selbst im übrigen
    mit DP=D0 global gesetzt - wenn man Systemroutinen nicht nutzt hat man DP ja unter eigener Kontrolle.
    Ausserdem mit praktisch kaum festen RAM Variablen, die habe ich je nachdem entweder oberhalb des Stack oder in ,U.
    Dadurch sind die Befehle und Zugriffe kompakter, insbesondere kann man mit einer linked list über U sehr schön
    objektorientiert programmieren - das ist bug resistenter und man glaubt es kaum: auch schneller. Die alten Williamsspiele
    wie Robotron machen es ähnlich, einen kommentierten Source gibt's übrigens online.

    Es gibt nichts schnelleres als ein pulu d,x,y um die Register zu laden. Danach liegen dann die restlichen Variablen
    bei ,u - und da die indirekten Offsets [-14,15] bereits im postop Byte drin sind spart man ein paar Zyklen und Bytes bei
    jedem Variablenzugriff.

    ist vielleicht was zuviel des guten aber das Spiel ist ja noch relativ am Anfang, da könnte man es noch reinnehmen,
    und das bringt letztlich auch einiges an Performance.
  • z.B. hier:

    ; Reverse engineering of Robotron 2084 Solid Blue Label by Scott Tunstall (Paisley, Scotland.)
    seanriddle.com/robomame.asm
    robotron2084guidebook.com/technical/sourcecode/

    hier sind auch noch etliche, andere Williamsarcadedaten zu finden:
    seanriddle.com/willy3.html#dats

    bzw.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von RetroJeck ()

  • Hab's grad auf meine Entwicklervectrex - eine mit sehr schnellem 6522 - getestet: sieht sehr gut hier aus.
    Zwei Kleinigkeiten fallen direkt auf: der Scorestring ist so weit oben, das er meist nur halb zu sehen ist,
    ebenso wandert die waagerechte Linie, an der die gepunkteten Linien enden, vertikal je nachdem, was
    dargestellt wird. ..oder das Ende der gepunkteten ist manchmal zu unterschiedlich - wahrscheinlich beides.
    Ich würde nicht versuchen, die exakt enden zu lassen - das machen die Kondensatoren auf verschiedenen
    Vectrexen schwer mit - sondern die Linie einfach marginal drüber zeichnen
    Schussgenauigkeit ist ok, Schüsse die seitwärts vorbeigehen könnten, treffen noch, aber
    ich schätze das sollte ich eh noch gar nicht wirklich testen, ebenso die Kontaktgenauigkeit.
    Das Gegnersprite gefällt mir - schön einfach und symmetrisch für eine vectrex, und mit ner rechteckigen bounding box für
    hit/kontakttests, davon kann man wirklich viele darstellen und berechnen pro Frame..

    super !
  • Schaut schon super aus in ParaJVE.
    Kanns leider grad nicht an meinem echten Vectrex testen.

    Respekt. Das wird einigen Leuten in der Vectrexszene sehr gut gefallen...
    Und für "erste Gehversuche" ist das unglaublich gut.

    @Retrojeck: Ist von dir Robot Arena?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von steril ()

  • Benutzer online 1

    1 Besucher

  • Tags