IRQ issues

[pser1]

Hi,
I am using the two-voices player by Simon Jonassen. It is IRQ driven and
it works nicely on a Dragon 32, but performs really awfully on a Dragon64.

It seems to be related to the number of IRQs that each machine sends per frame.
Apparently Dragon 32, adds 50 lines to the std NTSC (262 lines), so that it
brings out the correct total of 312 lines equally time-spaced.
But the Dragon 64 doesn't add this 50 lines, instead it sets a delay for the needed
time to compensate for those not sent lines ...

As the program creates a sawtooth by adding a value to the previously accumulated
every two lines, it clearly fails due to these 50 lines not received.

Does anybody know if it were possible to modify the Dragon64, changing one chip or
something like this, so that it ends up performing the same than the D32 does?

Any hint on that subject would be highly appreciated
Thanks in advance
pere

[jmk]

This is a real problem when trying to use horizontal blank IRQs. PAL CoCos also output the correct number of lines, leaving the Dragon 64 as the odd one out.

The only real solution, I can think of, is to modify the sound routine so that it detects a Dragon 64 and uses 100% CPU time for those 50 lines, when it can't rely on the IRQs. This would be pretty awkward and maybe one for Simon to think about?

[sixxie]

In case that wasn't inconsistent enough, PAL CoCos also invert the HS interrupt!

[pser1]

Hi,
thanks for answering!
The player is IRQ driven so that the computer can (and *must*) do other things at the same time.
So, the player cannot get 100% of CPU at any time or the program will freeze to the user sight.
That's why I asked if there is anyway to modify the D64 video circuitry to make it behave like the D32
I just cannot figure out what part of the Dragon32 video circuits does generate these extra 50 HS ...
best regards
pere

[pser1]

Hi,
this is a related question ...
The NTSC signal (262 lines) has them distributed like that:

Code: Select all

- Vertical blanking  . .  13 lines
- Top border  . . . . . . 25 lines
- Active display  . . . .192 lines
- Bottom border  . . .    26 lines
- Vertical retrace  . .    6 lines
====================================               
                          262 lines

But we know that Dragon 32 *adds* 50 extra horizontal IRQs (50 lines)
Where do these go? Are all of them 'out of screen' ?
We use to say that using SYNC we can dispose of the time for the 70 out of screen
lines (70x57=3990 cycles) In fact this figure can be doubled issuing
the POKE&HFFD7,0 giving some 7980 cycles ... for a NTSC computer

Should I assume that in a PAL D32 I can dispose of 70+50 = 120 *not seen* lines?
This would imply 120x57=6840cycles but at 2x will be 13680cycles
Being this last a very high and interesting number if it were real ...

Could anyone explain me if this last 'number' is real?
thanks in advance
pere

[sixxie]

Hi,
thanks for answering!
I just cannot figure out what part of the Dragon32 video circuits does generate these extra 50 HS ...

Indeed: we've covered this before actually. The circuit diagrams appear to be missing something; it really is *not* obvious where the extra pulses come from on the Dragon 32 (PIA input is still labelled "NHS", but that appears not to actually be labelled anywhere else...).

Really one of us needs to trace some circuitry

[sixxie]

But we know that Dragon 32 *adds* 50 extra horizontal IRQs (50 lines)
Where do these go?

25 lines are inserted when vertical blanking starts, and another 25 appear 23 scanlines after the active area. On the '64, it delays the HS rising edge as seen by the PIA by 25 lines.

PAL CoCos do it slightly differently.

Are all of them 'out of screen' ?

I think you can generally see them on a television - black bands top & bottom.

We use to say that using SYNC we can dispose of the time for the 70 out of screen
lines (70x57=3990 cycles)

Should I assume that in a PAL D32 I can dispose of 70+50 = 120 *not seen* lines?

Yes if you have the IRQ triggering on FS falling edge; that happens just after the active area, so you do indeed then have 120 scanlines to do stuff in before the raster hits the top of the next active area.

[pser1]

Hi Ciaran,
thanks a lot!
That makes me understand a bit better why using more than those 7980 cycles (70x57x2)
didn't produce any glitch on the screen (at 2x) ... that's very good news for me!
Plenty of room to change things while the screen is not shown
kind regards
pere

[sorchard]

Really one of us needs to trace some circuitry

One of us really did

viewtopic.php?f=8&t=4940&start=40#p12570

tldr: someone messed up on the D64 layout and connected the PIA & SAM HS to the VDG hsync instead of the PAL hsync.

This also means that memory is not refreshed where the irqs are missing. I guess it doesn't matter that much or it would have been noticed before.

I think the easiest 'fix' for a D64 would be to cut/lift the PIA pin (IC5 pin 40) and connect it with a flying wire to the video hsync (looks like IC18 pin 3 on the schematic). That would only fix the irq, not the refresh. No guarantees as it's not something I've attempted.

[sixxie]

Really one of us needs to trace some circuitry

One of us really did

viewtopic.php?f=8&t=4940&start=40#p12570

Whoops. Obviously I have the D64 circuitry myself: I remembered the discussion, forgot you'd done the graft