RE: AVG programming question...

Ooops. Jeff you must have copied some old code and pasted it into email.
The ISR below will NOT work in hardware without an sta INTACK.

-Anders

*** See modification below:

At 02:37 PM 4/15/99 -0600, Jeff wrote:
>Sorry about taking so long to respond. I've been at home this week helping
>take care of our new little that was born on saturday.
>
>When I first started writting space wars and tank.. (um forget about the
>second one, it's still secret) they worked great in MAME, but I had one heck
>of a time getting them to run on the real hardware. I now have them working
>almost 100% (just a few weird things still happening).
>
>I don't know how similar tempest hardware is to space duel & gravitar, but
>this is how I got it to work.
>
>The ISR routine is completely independent of the vector drawing hardware and
>is used only for timing (I set my drawflag every 4th entry into the ISR)
>You must have a HALT instruction at the end of your vector list (0x20) or
>the vector generator won't release the VRAM back to the processor. The halt
>instruction will also set the halt flag (on tempest it's 0x0C00 bit 6) which
>you should check before attempting to write anything to the VRAM.
>
>The following routine should work
>
>zoom
> bit 0x0C00
> bvc zoom ;wait for vector generator to halt
>Timing
> lsr drawflag
> bcc Timing ;wait for timing flag
> dec 0x2002
> lda 0x2002
> cmp #0x18
> beq Done
> sta VGGO
> jmp zoom
>Done
>
>plus you need something like this for your ISR
>ISR pha
> tya
> pha
> txa
> pha
       sta INTACK ; clear IRQ counter <- must do for hardware!!!
> dec icount
> lda icount
> and #03
> bne ISR1
> inc drawflag ;set every 4th interrupt
>ISR1 cli
> pla
> tax
> pla
> tay
> pla
> rti
>
>Also, I only use VGRESET once in the RESET routine and I use VGGO only in
>the main loop. That way the ISR won't fire it when you don't want it to go
>(and make all the VRAM unavailable)
>
>I have a complete API for programming the Vector Generator, it currently
>works for space duel and gravitar and I've almost got it done for tempest. I
>also have an API for reading controls. All you have to do is change a
>compile flag and your code will run on another machine (with a few
>limitations, I don't have anything for accessing the mathbox in tempest and
>I'm still working on a DVG version of the VG API)
>
>Let me know if you have any other questions and if you want, you can shoot
>some of your code over to me and I can take a look at it (or course I would
>keep that confidential)
>
>-jeff
>
>> -----Original Message-----
>> From: Clay Cowgill [SMTP:ClayC@diamondmm.com]
>> Sent: Thursday, April 15, 1999 11:45 AM
>> To: 'vectorlist@mcfeeley.cc.utexas.edu'
>> Subject: AVG programming question...
>>
>> Hi everyone,
>>
>> So this will probably be a limited audience for this message, but if any
>> of you know the answer feel free to pipe up. ;-)
>>
>> (I'm figuring Al, Jeff, and Anders will probably be the likely
>> candidates...)
>>
>> I'm doing my usual "write the menu system in MAME and then make it work
>> on real hardware" routine with the Tempest Multigame. I've got the
>> menu-system to a point I'm happy with, but alas the "real" Tempest
>> hardware doesn't take so kindly to it.
>>
>> I've got a display at least now (it was what I thought, Al-- need to
>> have the VG reset and VG go right at the end of the ISR...), but here's
>> my question for any of you that have programmed on the AVG:
>>
>> Does the AVG do anything "funny" with read-modify-write type
>> instructions accessing VRAM? I can't see any reason why it would, but
>> the symptom I'm having now is that it *looks* like the folliowing
>> doesn't work:
>>
>> VRAM is from h'2000 - h'2FFF in Tempest, so I've got something like this
>> in VRAM...
>>
>> Starting at 0x2000:
>>
>> 40 80 FF 71 06 6F 37 A9 ...
>>
>> which basically means:
>>
>> 40 80 center beam
>>
>> FF 71 zoom factor "really small"
>>
>> 06 6F color register 6 (had to do a 6F to make MAME happy, I don't think
>> the real hardware cares...)
>>
>> 37 A9 subroutine call to display the "TEMPEST" logo
>>
>> (Yes, I did that all by memory. Did I happen to mention that I can now
>> read and write Tempest Vector Memory display lists in hex? Probably
>> never come up in final Jeopardy though... :-)
>>
>> What I then do is basically:
>>
>> lda #0x01
>> sta frame_done
>> zoom: dec 0x2002 ; zoom in the logo - decreasing the value of
>> that 0xFF in the display list above
>> wait: lda frame_done
>> bne wait
>> lda 0x2002
>> cmp #0x18
>> bne zoom
>> ...
>>
>> frame_done is a flag that is cleared by the ISR that starts the Vector
>> Generator drawing. (So once a frame is drawn frame_done is 1.)
>>
>> What the above code does in MAME is decrement the zoom value of the
>> Tempest logo (making it get larger on the screen) once per frame update
>> until the zoom is equal to 0x18 after which it continues on to other
>> code.
>>
>> What it seems to do on the *real* hardware is hang. The ISR is still
>> running, but the logo never zooms in.
>>
>> I'm concerned that either the "dec 0x2002" isn't working (so the loop
>> never exits), or maybe that since my loop flag gets set in the ISR, but
>> possibly prior to the vector generator actually *finishing* drawing the
>> frame, maybe I'm getting a bus contention and "dec 0x2002" isn't able to
>> change the VRAM.
>>
>> I don't know if Tempest *has* a VG-busy bit I can read to tell when
>> things are done drawing...
>>
>> Any thoughts/theories/solutions welcome...
>>
>> -Clay
>

a n d e r s k n u d s e n

mailto:aknudsen.96@alum.mines.edu
Received on Thu Apr 15 15:58:29 1999