|
Post by thomas on Feb 4, 2016 14:11:33 GMT -5
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). Thomas DISASM.BIN (6.95 KB)
|
|
|
Post by Malban on Feb 4, 2016 15:48:56 GMT -5
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!
|
|
|
Post by vectrexmad on Feb 4, 2016 18:50:18 GMT -5
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.
|
|
|
Post by Malban on Feb 4, 2016 19:35:56 GMT -5
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
|
|
|
Post by thomas on Feb 6, 2016 13:02:20 GMT -5
##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..
|
|
|
Post by thomas on Feb 6, 2016 13:11:15 GMT -5
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
|
|
|
Post by thomas on Feb 6, 2016 13:11:39 GMT -5
hmm, tabs are all gone, sorry for that
|
|
|
Post by thomas on Feb 6, 2016 13:24:42 GMT -5
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..
|
|
|
Post by Malban on Feb 6, 2016 16:23:53 GMT -5
One last question for the moment, till I can wire up my own vectrex :-)!
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
|
|
|
Post by thomas on Feb 7, 2016 10:27:03 GMT -5
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..
|
|