Re: Vector rotation

On Tue, 15 May 2001 11:24:08 -0400 (EDT), Paul Kahler <phkahler@Oakland.edu>
wrote:

>
>> > x' = c*x + s*y
>> > y' = -s*x + c*y
>> >
>> > Funny, I've seen Cinematronics code to do this very operation using
>> > 8 multiply instructions for each product - it's about a page of code.
>>
>> If you mean 8 MUL instructions, then surely that isn't a surprise?
>>
>> Each MUL instruction on the Cine is just one shift+add step of Booth's
>> algorithm. You need 8 of them in a row to execute an 8-bit multiply.
>> But you must know that - you wrote one of the emulators. is there
>> something else about this code in the Cine that's funny? I'd be quite
>> interested in identifying this entire sequence as a block that can
>> be removed and replaced with a high-level emulation (in my automatic
>> translation of tailgunner to C), so if you have that page of code, maybe
>> you could email it to me :-)
>
>I think I first saw it in Star Castle or RipOff. I don't have the
>disassembly any more, and you'd need to learn the Paul/Kurt mnemonics
>to read it anyway :-) I suspect that block got reused a lot though.
>
>Other funny things?
>
>Try to emulate toggling the "bright" bit while a line is drawing :-)

That would be difficult!

But I do (somewhat) emulate the 9 intensity levels that are achievable by
changing the line length parameter when drawing points. When drawing a point,
the hardware will remain fixed at that point for the duration of the line length
register. And since the longer it stays in one place, the brighter it gets, by
varying the "vector length" of a point you can vary its intensity.

The weird thing is this seemed to be the universal way the programmers changed
star intensities. They never seemed to use the "bright" bit, which would have
worked just as well, especially since they only used it to create two levels of
star intensities.

The only exception was Tailgunner, where they used the different levels to have
stars fade as they receded. Pretty cool effect. Looked a lot like Sundance
which had 16 levels of intensities available.

Since only Tailgunner used the different levels (and I didn't know this at the
time), I cheated and only display two levels of stars based on the line length
register. Though it wouldn't be that hard to fully emulate this...

One thing I didn't emulated was the variable intensity pulsating star in the
middle of Space War. That was achieved by re-drawing the same vector multiple
times in one frame. I also draw the vector multiple times, but that doesn't
have much effect on a raster monitor. ;^)

>Treat the normalize instruction as a NOP. We do. It's used to extend
>vectors (dx,dy) so the beam tries to overshoot the endpoint. Then the
>hardware turns the beam off part way there, otherwise lines would
>be brighter at the end due to nonlinear beam speed. Using a NOP will
>cause the vectors to be unmodified the way you want them :-)
>
>I doubt this instruction is used for anything else, however
>Speed Freak doesn't quite run on our emulator.
>
>Technically ANY branch instruction can be used to select the
>secondary accumulator, but it's not used that way much if at all.

Except for the jump to new ROM bank instruction. This instruction will always
select the secondary accumulator. The Cinematronics in house programmer's
manual indicated one must always jump to a NOP when bank switching ROM. (There
is no mention as to why that is required.)

>Star Castle never uses the carry flag, so it's a nice game to
>start with. Flags were a big deal for me to get correct (fortunately
>I started with S.C.) If I had to do it again, I'd store the compared
>values rather than the flags.
>
>Then evaluate the flags only on a
>conditional branch - and then only the one you care about.

That's how I did it in my emulator. (The source is available on my homepage if
anyone is interested.)

You didn't mention that the minus flag, is delayed by one instruction, because
of how the latch used to read the external input is clocked. The minus flag
was hacked in by jumpering a line from the high bit of the temporary accumulator
to the external input, normally used to read the comparator output of the DAC on
the vectorbeam monitor, when a joystick is attached. -- in Rev K boards this was
labeled the JMI jumper. That was a bitch to emulate properly!

The code I've seen always places a NOP instruction before a test for the minus
flag (this is mentioned in Cinematronics in house programming manual, but,
again, no mention is made as to why it is needed).

This could be your problem with Speed Freak, though I'm not sure Speed Freak
even used the minus flag.

I also fully implement the Normalize instruction, so maybe that really is the
problem.

>Then again,
>we run OK on a P90, so speed isn't a big deal. The problem is that there
>are SO many instructions that affect the flags - I think anything that
>modifies/loads an accumulator.

Mine ran fine on a 66mhz 486 ;^) (Though admittedly the resolution sucked! But
there was no flicker! -- I used a dual buffered VGA mode, and only draw to the
buffer not being displayed.)

-Zonn
---------------------------------------------------------------------------
** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
** message body to vectorlist-request@synthcom.com. Please direct other
** questions, comments, or problems to neil@synthcom.com.
Received on Thu May 17 22:06:23 2001