Vectrex Revisions again

[thomas]

Hi,

I wanted to check a particular Vectrex hardware difference for a while now
and finally decided to enhance a test cart of mine for this purpose:

this is a dissassembler running on the Vectrex that I quickly programmed to learn
all the 6809 mnemonics way back when (last October and that doubles as
one of my test carts for my main project: it uses fonts/storage/screensaver/quick switch
etc. capabilities of that extension. And it generates a lot of strings for my draw functions..

The font function is unique in that I encountered a timing difference that breaks it somewhat
on newer generation hardware. This is not a problem on my hardware, where a user can
specify this once via an option. But I'd like to understand this better, esp. since I plan to develop
games of my own and would prefer to use this functionality since i invested a lot of
time to get the fastest string routine possible.

Not that I would encourage anyone to use any bitmaps on a Vectrex anyways, I do not plan
to myself except for some text strings, but the functionality is a lot faster than a 'normal' one
so I'd prefer to keep it for a general release cart. to squeeze out a few more cycles..

Anyways, the way the functionality works is that there is a simple automism in place that
sets up a call function for the hardware detected - in the moment one of three in this binary:
first rev. hardware, non-buzz hardware and ParaJVE emulation.
Hardware differs just in one cycle but ParaJVE (0.7.0) emulation is way off so I added
a (bit slower..) version for emulation dev. and test purposes, too.

So..

What I'd like to know is whether this display output works on your Vectrex hw out of the box
(in the default Automatic mode) or if not, whether one of the other timings you can select
via Button 1 work for you.
if automatic does not work I also would like to know what type of exec rom you've got
(the test rev version no.) and especially the revision of the exec printstr in place.

And for this a Vectrex disassembler comes in handy: the rev. b1 code changes at F4F6
are checked to enable the 'new hw' functions in the moment (starting with an ASLB on new hw).

ThomasDISASM.BIN (6.95 KB)

[Malban]

Hiho!
Tell me, do all three versions work the same on your vectrex?

I just tried the bin with VIDE, I can get them all three to work playing around with internal timing parameters, but not all at the same time...

Regards

Malban

These cycle busting/optimizing homebrewers are an emulator programers nightmare!

[vectrexmad]

Hi Thomas, I ran it on my main Vectrex and after the initial title screen which I can read, the next pages I see contain what look like bit mapped text of the Vectrex ROM. However, it is so speckled, that I can't read anything. This true for the automatic mode and any of the other modes for button 1.

[Malban]

Me again -

I will probably get some time over the weekend to wire up my real vectrex and try your bin file.
In the meanwhile - I have not been able to get your text to work alongside my own text routines I did (look at the last VIDE entry) some years ago - I hope that is an indicator that your routines are still a bit flawed :-).
Otherwise I would get even more gray hair than I already have in trying to figure out what is wrong in the emulation code <AGAIN>.
(But I assume your code is working with your vertex - at least I got the impression... )

I would be very careful to optimize the last squeeze that is theoretically possible.
It might work on this or that emulator, it might even work on this or that vectrex, but "checking" the hardware revision in order for a program to work on a real vectrex would (IMHO) be to much optimization.

I looked through my old codes and packed together a "demo" of the moon lander text routines. While I don't have your sources to compare I did a little peek at your code and they are not unsimilar :-)

Perhaps we can compare notes and if yours work on real vertex (all - one - none?) than I would someday like to get them working in VIDE "without" your program checking if an emulator is running :-).

print.zip (ok, that was a very quick setup, much code in there that is not needed for printing... but you will see what I mean).

One very important command while optimizing (I learned from vectrex) is "NOP"!

Here a short extract: At least with my vectrex THREE "NOP"s were needed, otherwise there would be garbled output...



;**************************************************************************
; expects
; b = speed
; first char
; u pointer to string
; X pointer to inverted character display table
; Y speed set to zero
; ...
ONE_LINE_BACK macro t            
STB     VIA_port_a        ; negative x speed
LDB     #1
STB     VIA_port_b        ; enable RAMP, disable mux
       NOP                       ; delay needed for drawing</span>
       NOP
       NOP
       brn     LF4C7_2\?
LF4C7_2\?:
LDA     A,X               ; Get bitmap from chargen table
STA     <VIA_shift_reg    ; Save in shift register
LDA     ,-U               ; Get next character
BPL     LF4C7_2\?         ; Go back if not terminator
; A=$81
STA     <VIA_port_b       ; disable RAMP, disable mux
LDX     #\1
LDB     Vec_Text_Height   ; Get text height
endm

;**************************************************************************
MOVE_DOWN_BEFOR_FORTH macro
; now move down
STB     <VIA_port_a       ; store 'height' to dac (y)
DEC     <VIA_port_b       ; disable RAMP, enable mux
INC     <VIA_port_b       ; disable RAMP, disable mux
CLR     <VIA_port_a       ; zero dac
; now only y set, x to zero
LDB     #01
STB     <VIA_port_b       ; enable RAMP, disable mux
; here we move down
LDB     ,U+
LDA     ,U+
DEC     <VIA_port_b       ; enable RAMP, enable mux
 ; tricky, cutting y off while
     ; integrating, saves one switch of mux
 ; B is still $81
 ; (terminating value for string, reuse here for poke to VIA)
STB     <VIA_port_b       ; disable RAMP, disable mux
LDB     Vec_Text_Width
; now finnished moving down
endm
...

Cheers

Malban

[thomas]

##DOES MOST LIKELY NOT WORK ON EMULATION##
..should have stated that before more clearly..

So, to clarify: I own four Vectrex units myself that display two different timings: they definitely do not behave the same timing-wise, which is
what interests me: to display correctly I sometimes need to delay the retrace for a cycle (the 'one' option) and on some i do not.
This is what I meant by fixing Moonlander, too, I adjust the delay in its routines by one cycle just like I do with my own functionality based on
the systemwide setting. Otherwise I get the same incorrect output. In a way the routine is somewhat stable since the problem autocorrects
every other line. On my actual hardware this means just the one cycle, which makes it readable but slightly 'weird' if it fails. On emulation
this can be wildly off, more than 16 cycles, which makes it entirely corrupt and unreadable.

The binary supplied runs fine on all my hw units and only as an afterthought I added ParaJVE support since I do not use emulation for development.
It probably will not work on emulation in general, though, even with ParaJVE I can get it to fail easily by juggling around the timing even a tiny bit.

so, to vectrexmad:
as i said the text routine should autocorrect every other line, meaning the odd and even lines on your Vectrex are shifted only horizontally
but within even/odd it should be the same. Which is what I hope you mean by speckled. Once you know what to look for you maybe recognize what I mean.
If I am right. Question is: how much off are there ? One whole char is 18 cycles.

so no, the three versions do not work the same on my vectrex hw, 'one' and 'zero' display differently and the auto. selects one of the two
depending on the exec printstr version. Except if ParaJVE is detectect in Auto mode, then yet another version is used..

[thomas]

oh, in case you were wondering

nonv4e_setup_timing ldx #nonv4e_myPrint_Str_d
tsta
bne nonv4e_setup_timing0
if V4E_USE_PARAJVE_PRINTSTR
lda v4ecartflags ; now the v4e cart versions
bmi nonv4e_setup_timing_nov4e ; bit 7 set, we are on v4e
lda #$26
cmpa $F067 ; are we on ParaJVE ?
bne nonv4e_setup_timing_nov4e
ldx #paraJVE_myPrint_Str_d
bra nonv4e_TeensyPatch
nonv4e_setup_timing_nov4e
endif
lda #$58 ; automatic mode
cmpa $f4f6 ; look for aslb in rev.b1 changes
bne nonv4e_TeensyPatch ; use brn for 3 cycles total
ldx #nonv4e_2_myPrint_Str_d
bra nonv4e_TeensyPatch
nonv4e_setup_timing0
deca ; no cycle to add ?
beq nonv4e_TeensyPatch ; yes
ldx #nonv4e_2_myPrint_Str_d
nonv4e_TeensyPatch
stx print_calladr
rts

[thomas]

hmm, tabs are all gone, sorry for that

[thomas]

the code was for Malban, mostly, the ParaJVE timing version is enabled by detecting the patched rom at F067 (for faster reset), I think I had to add 3 nops
to keep the line running and one cycle in front of the shift..

[Malban]

One last question for the moment, till I can wire up my own vectrex :-)!

This is what I meant by fixing Moonlander, too,

Does that mean Moonlander also is not working correctly (String wise) on all machines?
(I have only one to tested it on...)

Oh...
And for emulation :-)
I too could offer an option to emulate "new" or "old" vectrexes with different timings...

Regards

Malban

[thomas]

Correct, Moonlander does not work on all machines, and yes both Moonlander's code and mine are similar to the exec string routine: there really
is no other way to implement variable-size strings w/o a similar looking code but I could name quite a lot of differences between the Moonlander code and
mine off the top of my head right now so no, they are not the same except for this inner 18 cycle loop.

I also do not hear the digitized sound of Moonlander on my development Vectrex (or rather, it is nearly but not entirely silent), but I do on two others just fine..