|
|
Post by jfmateos on Dec 9, 2014 8:52:46 GMT -5
The BIOS moving and drawing routines use the 6522's shift register to control the BLANK line and the 6522's T1 interrupt to control the RAMP line.
I wonder whether we could move/draw without using the shift register nor the T1 timer.
Why?
Because I would like to know whether this way of moving/drawing is faster.
Has anybody tried this before?
|
|
|
|
Post by gauze on Dec 9, 2014 9:07:08 GMT -5
I don't know!
I've read a bit about the 6522 and vectrex drawing routines from an old document called "INTERNAL.TXT" (I think) I wonder if anyone has an updated version of this to clarify the 'steps' when drawing happens. From ASM instructions to mem mapped 'ports' to the 6522, to ??(deflection? etc) to picture on screen.
a full picture of what is going on with the hardware, digital and analog sides.
|
|
|
|
Post by christophertumber on Dec 9, 2014 10:54:17 GMT -5
I wonder whether we could move/draw without using the shift register nor the T1 timer. No idea, if you have ideas on how to do this, please proceed! The benefit to using the timer is that for long, straight vectors - especially non-drawn vectors used for initial positioning - you can multi-task. While the vector is being drawn you can do other things. However, this includes a lot of overhead every time you want to make a change in direction. If we could do something like:
<some setup>
ldx #shape_data
next_data:
ldd ,x++
beq done_shape
std hardware
bra next_data
jsr rest0ref
That would probably save a bunch of cycles, but presumably at the cost of a some largish data tables since you're updating your vectors every 16 cycles and I'm not sure how that's going to translate to length (ie; need to repeat several times for longer lines). Actually, this will affect resolution quite considerably! If you're moving the deflector at maximum speed, the height/width of the screen is 255 cycles (a vector (0,127) drawn at scale 255). Updating drawing every 16 cycles, that's an effective resolution of 16x16 which is really low rez. So in order to obtain a good resolution, you're going to need to draw at a much slower speed. Which negates any benefit. Unless there's some way to build some kind of buffer or stack the hardware would pull from automatically? Maybe a really quick interrupt? (probably not possible to do so fast) For long vectors - positioning vectors, or stationary frames (walls) around the perimeter you're probably better off using the old method since it's going to cost you a bunch of cycles that the old method allows you to recover through multi-tasking. Cliff notes: When the electron gun is moving at maximum/fast speed it's not possible to push bytes at it quickly enough. If you slow it down, you probably lose the proposed benefits and would be better off using the the current method. Still a really interesting concept that might have some killer applications if possible. |
|
|
|
Post by jfmateos on Dec 10, 2014 7:10:54 GMT -5
Thanks gauze and chris...
Could anybody explain the Callibrate subroutine?
;-----------------------------------------------------------------------;
; F2E6 Recalibrate ;
; ;
; Recalibrate the vector generators. ;
; ;
; ENTRY DP = $D0 ;
; ;
; D-reg, X-reg trashed ;
;-----------------------------------------------------------------------;
Recalibrate: LDX #Recal_Points ;$7F7F
BSR Moveto_ix_FF
JSR Reset0Int
BSR Moveto_ix ;$8080
BRA Reset0Ref
|
|
|
|
Post by christophertumber on Dec 10, 2014 8:32:34 GMT -5
BTW, in Fred Taft's original disassembly this is:
F2E6 8EF9F0 PF2E6: ldx #0xF9F0;
F2E9 8D1D bsr move_penFF;
F2EB BDF36B jsr $PF36B;
F2EE 8D20 bsr move_pen;
F2F0 2062 bra reset0ref;
I've never used it. Might be called on boot up?
|
|
|
|
Post by jfmateos on Dec 10, 2014 8:38:06 GMT -5
It is called in every wait_recal... and it seems to be the responsible of the vectrex buzzing
|
|
|
|
Post by jfmateos on Dec 13, 2014 13:21:41 GMT -5
Investigating this method I have found that it could be useful for drawing curved lines. The problem is that the emulators don't seem to manage this well... so the effect in a real vectrex is quite different. I am asking the community help to find out whether this effect is consistent among all vectrex consoles: Please could you test the bin attached and take a photo of your screen? As you can see, in my vectrex the curved line doesn´t cross the left-right sides of the rectangle.  pang5.bin (791 B) |
|
|
|
Post by christophertumber on Dec 13, 2014 21:43:44 GMT -5
MB Canada Model 3000-C1 Serial: 1021676  |
|
|
|
Post by christophertumber on Dec 13, 2014 21:44:58 GMT -5
MB Canada Model 3000-C1 Serial: 1012059  |
|
|
|
Post by christophertumber on Dec 13, 2014 21:46:06 GMT -5
GCE Model 3000 Serial: 110258 A  |
|
|
|
Post by christophertumber on Dec 13, 2014 21:52:51 GMT -5
MB Canada Model 3000-C1 Serial: 1011913  |
|
|
|
Post by christophertumber on Dec 13, 2014 21:56:57 GMT -5
MB Canada Model 3000-C1 Serial: 1015335  |
|
|
|
Post by christophertumber on Dec 13, 2014 22:01:25 GMT -5
GCE Model 3000 Serial: 141981 A  |
|
|
|
Post by christophertumber on Dec 13, 2014 22:09:26 GMT -5
Cliff notes: Drift is a sonofabitch!
|
|
|
|
Post by jfmateos on Dec 14, 2014 1:39:53 GMT -5
Thank you very much christopher, I will study this carefully.
Probably it is not just a matter of drift, but also the integrator could be different in this consoles.
|
|
