Erste Vectrex Gehversuche ...

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 !

sieht schon sehr vielversprechend aus! ->

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

Oops, alle Tabs weg

hier ein include File:
xcode

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.

Läuft auch auf den ParaJVE Emulator

Quote from RetroJeck

Die alten Williamsspiele
wie Robotron machen es ähnlich, einen kommentierten Source gibt's übrigens online.

Wo denn?

z.B. hier:

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

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

bzw.

Danke für die Links

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?

Ich habs gerade mal mit meinem VecMulti direkt am Vectrex getestet-GENIAL !!! Sieht echt super aus-die Scores sind gut platziert und gut erkennbar. Spielt sich flüssig und mir ist noch nichts zum bemängeln aufgefallen. Weiter so !!!

Wo kann ich vorbestellen?

Dumpfbackenfrage: Wie bekomme ich die .bin denn im ParaJVE zum laufen?

Java hast Du installiert??Ohne dem geht es nicht