[Coco] IRQ question

Simon Jonassen simon at roust-it.dk
Thu Feb 2 15:29:45 EST 2017


I beg to differ...

you can definately OPTIMIZE it to make it run in realtime.... !

please drop me a message if you are at all interested in that prospect (z80 is NOT my forte - but I know 6809 omtimization like the back of my hand)

/Simon :-)



-----Oprindelig meddelelse-----
Fra: Coco [mailto:coco-bounces at maltedmedia.com] På vegne af Glen Hewlett
Sendt: 2. februar 2017 21:19
Til: CoCoList for Color Computer Enthusiasts
Emne: Re: [Coco] IRQ question

Hi Guys,

Thanks for chiming in on this, I’ve done more testing similar to what Salvador what suggesting.  Using MAME and putting in breakpoints and watching the beamy and frame numbers I’m actually able to see how many cycles my code is using.  Unfortunately I can see that my sprite routine moving five 16x16 16 colour sprites is using 35427 cycles which is 1.19 frames just for rendering.  The rest of the IRQ is taking another 31698 cycles which is another .94 frames and the code outside of the IRQ is taking 19267 which is .65 frames.  The total is 117717 cycles which is 3.83 frames which is why my IRQ is hitting properly as you guys suggested the code is just to big to be processed by the 6809 in high speed mode within the 1/60th of a second it needs to be for the IRQ to be triggered properly.  The code outside the IRQ takes 19267 cycles which is 0.65 frames.

The code is almost 4x slower then real Pac Man runs at.  I don’t think I can optimize it enough to be playable in real time.  My sprite code is already very optimized as for the backup and restore features.  There may be room for improvement on the sprite drawing but not a lot.  The rest of the entire code inside + outside of the IRQ without the sprites is still using 50,965 cycles which is 1.59 frames.  This code can and will be optimized as of right now it’s mostly a quick and dirty instruction translation.  But I don’t think I can get the rest of the code under 1 frame... This is disappointing since I don’t even have any sound sections working yet which when running will make it even slower.  This is a learning experience for me and I really wanted to have Pac Man ported from the z80 with sound...  :(

Just for completeness and since Simon asked here is the IRQ setup code:
      LDX     #IRQ_Interrupt
      STA     $FEF7
      STX     $FEF8   
      ANDCC   #$EF

Cheers,
Glen

> On Feb 2, 2017, at 1:25 PM, Simon Jonassen <simon at roust-it.dk> wrote:
> 
> I would like to see a little more of this IRQ setup code...
> 
> are you using the most direct method ? eg putting a JMP $nnnn in the $fexx area - or are you going via the double vector at $10c.... ????
> 
> you have 262 scanlines (and depending on mode you have say 50 lines of Vblank (normally 57 cycles per line - but 114 cycles in double speed))
> 
> /Simon :-)
> 
> 
> 
> 
> -----Oprindelig meddelelse-----
> Fra: Coco [mailto:coco-bounces at maltedmedia.com] På vegne af Salvador Garcia via Coco
> Sendt: 2. februar 2017 17:17
> Til: CoCoList for Color Computer Enthusiasts
> Cc: Salvador Garcia
> Emne: Re: [Coco] IRQ question
> 
> Although I have no experience with 6809 code, I have done a few ISRs for i86 computers and when I read the part about the ISR being "big" that also caught my attention.For debug only, reduce the ISR size by 50% (or more), removing or commenting out code that isn't critical to the game's functionality (if possible) and see if that improves behavior. Salvador
> 
>      From: Arthur Flexser <flexser at fiu.edu>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com> 
> Sent: Wednesday, February 1, 2017 10:20 PM
> Subject: Re: [Coco] IRQ question
> 
> You say your IRQ service routine is big.  Could it possibly be SO big that
> servicing takes more than a 60th of a second on the CoCo 3?  That would
> certainly cause some IRQ servicings to be skipped.  Or even if servicing
> took slightly under a 60th of a second, the next IRQ would hit almost
> immediately after return from the previous service, so little code could be
> executed in between, causing a substantial slowup.
> 
> You could count cycles in the service routine to closely estimate how long
> servicing should take in the CoCo 3 double-speed mode.
> 
> Art
> 
> On Wed, Feb 1, 2017 at 9:55 PM, Glen Hewlett <glen.hewlett at sympatico.ca>
> wrote:
> 
>> Hi All,
>> 
>> I need some help from a CoCo3 IRQ expert.
>> 
>> I thought I had this figured out but something is not right with my IRQ
>> setting for my Pac Man transcode project.  I’ve gotten to the first attract
>> mode and the animation is running about 1/4 the speed of the real machine.
>> I was getting worried it was a problem with the CPU not being fast enough
>> but it looks like the IRQ just isn’t kicking in at the correct time.  It
>> seems to update the IRQ on the CoCo 3 every 4 frames and not when the
>> VBLANK occurs at least according to MAME in debug mode.  What I need is it
>> to be triggered on every VBLANK or (VSYNC)
>> 
>> On Pac man hardware the IRQ kicks in approximately 60 times a second and
>> using MAME debugger option I can see it in action, every IRQ it does is one
>> frame.  On the CoCo 3 under MAME debugger running my code it seems to kick
>> in around every 4th frame and definitely not when the beamy is at 241 like
>> pac man shows under MAME debug mode.  I know MAME might not be perfect but
>> there is definitely something wrong with my IRQ settings.  I’ve setup the
>> following code for my IRQ thinking it should trigger on the VBORD, is this
>> the same as VBLANK?
>> 
>>       LDA    #%00110100              *
>>       STA    $FF01                  * HSYNC IRQ Disabled, IRQ Polarity
>> Flag falling Edge, Data Direction Normal, Select Line LSB = 0, HSYNC Flag =
>> 0
>>       STA    $FF03                  * VSYNC IRQ Disabled, IRQ Polarity
>> Flag falling Edge, Data Direction Normal, Select Line MSB = 0, VSYNC Flag =
>> 0
>>       STA    $FF21                  * CONTROL OF CD FIRQ* TO CPU
>> DISABLED, IRQ Polarity Falling Edge of CD, CD Flag off
>>       STA    $FF23                  * CONTROL OF Cart FIRQ* TO CPU
>> DISABLED, IRQ Polarity Falling Edge of Cart, Cart Flag off
>> 
>>       LDA    #%01101100              *
>>       STA    $FF90                  * CoCo 3 Mode, MMU Enabled, GIME
>> IRQ Enabled, GIME FIRQ Disabled, Vector RAM at FEXX enabled, Standard SCS
>> Normal, ROM Map 16k Int, 16k Ext
>>       LDA    #%00000000              *
>>       STA    $FF91                  * Mem Type 64k chips, 63.695 usec
>> timer, MMU Task 0 - $FFA0-$FFA7
>> 
>>       LDA    #%10000000              *
>>       STA    $FF98                  * Graphics mode, Colour output, 60
>> hz, max vertical res
>> 
>>       LDA    #%00001000              * $08
>>       STA    $FF92                  * Enable only the Vertical Border
>> Sync (VBORD) Interrupt
>> 
>> The IRQ routine itself is big… Other then running normal code I’m only
>> doing the following in the IRQ routine itself:
>> IRQ starts…
>>       No special code here
>> 
>> At the end of the IRQ I have:
>>       LDA    $FF92                  * Reading this makes the IRQ
>> enabled again
>>       RTI
>> 
>> Does the above look OK for setting the IRQ to hit 60 times a second on the
>> VBLANK signal?  If so then maybe the CoCo 3 just isn’t fast enough to run
>> my Pac Man translated code.  :(
>> 
>> Thanks for looking,
>> Glen
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
> 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco


-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco



More information about the Coco mailing list