Mixing two different graphic modes

Hardware Hacking, Programming and Game Solutions/Cheats
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post by pser1 »

ok, I will try that, but from Basic, I have seen that if I don't press the expected key ("S"), then the screen flickers on every keypress.
That's why I supossed that from ml it might be avoided ...

cheers
pere
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

Just to add my own observations:

It's possible to get a stable split screen in xroar using both hsync and vsync interrupts if the interrupted code doesn't read locations $ff00 and $ff02, which clear the hsync and vsync flags. It's easy to verify this just by running a loop of instructions instead of returning to BASIC.

This is why the hsync version of the code doesn't work very well with BASIC. Reading the keyboard at $ff00 can cause hsyncs to be missed. I don't understand why this effects xroar more than real hardware*

Edit: *I have a hunch it may be due to how the irq is latched. Even if the irq flag is cleared in the PIA, the 6809 may still be able to respond to it if it has registered the state of the irq line before the flag was cleared.

The vsync only code must be flickering because BASIC reads $ff02 in a number of places, clearing the vsync flag and causing the mode change for the top half of the screen to be missed.

It is not necessary to read $ff02 to scan the keyboard so this is another route to a stable split screen. It may be possible to patch BASIC to substitute a clean keyboard scan routine that only writes to $ff02. This may even be the approach that the GraphText program uses.
Bosco wrote:Glad to hear your D64 has survived sorchard. Was it like unboxing a hibernating tortoise and wondering if it's still in the land of the living?
:lol: A lot like that. I didn't give the full story either. The smoke escaped from the D32 I tried first (I love the smell of burning tantalum caps in the, er, evening) and my ancient multisync monitor also went into sizzling smoke production mode. My instinct was to throw the monitor out of the window before things became more flamey but fortunately it decided that the smoke was enough to make a point. I've got quite a few more Dragons to go through yet. Think I'll be a bit more cautious...
Stew
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post by zephyr »

You could try reading the keyboard via a sub which avoids calling the keyboard routine when the flag is set. This method should (in theory) prevent the flickering under real hardware.

Code: Select all

INKEY  LDA $FF03
       BPL ROMKEY
       CLRA
       RTS
ROMKEY JMP $BBE5
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post by zephyr »

sorchard wrote:Just to add my own observations:

It's possible to get a stable split screen in xroar using both hsync and vsync interrupts if the interrupted code doesn't read locations $ff00 and $ff02, which clear the hsync and vsync flags. It's easy to verify this just by running a loop of instructions instead of returning to BASIC.

This is why the hsync version of the code doesn't work very well with BASIC. Reading the keyboard at $ff00 can cause hsyncs to be missed. I don't understand why this effects xroar more than real hardware*

Edit: *I have a hunch it may be due to how the irq is latched. Even if the irq flag is cleared in the PIA, the 6809 may still be able to respond to it if it has registered the state of the irq line before the flag was cleared.

The vsync only code must be flickering because BASIC reads $ff02 in a number of places, clearing the vsync flag and causing the mode change for the top half of the screen to be missed.
Writing to $FF02 (CLR $FF02) also causes the same problem under XROAR. I don't know it the same will happen on a real Dragon 32/64.
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post by zephyr »

It doesn't seem possible to stop the flickering completely, but I have managed to reduce it to an absolute minimum by adding a subroutine (INKEY) which uses a combination of flag detect and a countdown to prevent the keyboard routine from being called every time.
sorchard wrote: Edit:
Just noticed something subtle:
It programs the PIA to detect the rising edge of the frame sync pulse instead of the usual falling edge. This means less time is needed to be wasted in a delay loop to reach a given position on the screen.
I have also added the code which programs the PIA to detect the rising edge of the frame sync pulse. Try the attached updated demo (Encoder 09 source) code.
Attachments
ZIRQ3.zip
(1.1 KiB) Downloaded 257 times
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

zephyr wrote:Writing to $FF02 (CLR $FF02) also causes the same problem under XROAR
Yes, CLR $FF02 will cause flicker on both xroar and real hardware, the reason being it reads before it writes. (It's one of the read-modify-write instructions). To safely clear $ff02 it will be necessary to so something like CLRA STA $FF02.

I've looked at GraphText a bit more closely. It achieves the flicker free result by patching BASIC everywhere the keyboard will be read. It redirects the INKEY$ function, 016A "input char from DEVN", 017F "check break/pause" and 019A "get command". Then what it does is simply SYNC before calling the ROM scan keyboard routine. This ensures that the irq has been serviced and there is plenty of time to scan the keyboard any way you like without disturbing anything.

In summary, use SYNC before calling the rom scan keyboard routine.

I would add that it's a nice thought to try and detect the state of the vsync flag before scanning the keyboard but the subtle point is that you won't catch it because the irq handler will be called before you can take any action. The flickering is occurring because the vsync flag is both set and cleared during the same problem instruction.

I think xroar is different to the real hardware in the sense that the irq lines will be sychronised into the CPU clock domain via one or more registers. This has a delaying effect such that the CPU is responding to something that happened a couple of cycles ago. Perhaps xroar is instead responding to the current state of the line from the PIA?
Stew
sixxie
Posts: 1346
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Mixing two different graphic modes

Post by sixxie »

sorchard wrote: I think xroar is different to the real hardware in the sense that the irq lines will be sychronised into the CPU clock domain via one or more registers. This has a delaying effect such that the CPU is responding to something that happened a couple of cycles ago. Perhaps xroar is instead responding to the current state of the line from the PIA?
There does seem to be a timing error - those BASIC test cases being slightly off in the other thread imply something odd about the frame length... Yet I have logic traces from real hardware that show exactly what I expect! Ah well, it'll crop up.

The emulated CPU takes three cycles to latch an IRQ or FIRQ, as mentioned in the data sheet. Pretty hard to test that behaviour in real hardware, but again I had traces showing the edge and then when the IRQ vector was fetched, and it seemed to tally (multiple tests, as obv. it won't interrupt an instruction).
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

sixxie wrote:The emulated CPU takes three cycles to latch an IRQ or FIRQ
The Motorola and Hitachi datasheets say slightly different things about the interrupt timing but both have a timing diagram that shows an IRQ being recognised if it occurs during the cycle before the last cycle of the current instruction.

As you say, not an easy task to characterise this on real hardware. You've done a stellar job as it is.

It's explained in gory detail in US patent 4250546 but it's more than my tiny mind can cope with. I'd rather try and measure it!
Stew
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post by zephyr »

sorchard wrote: I've looked at GraphText a bit more closely. It achieves the flicker free result by patching BASIC everywhere the keyboard will be read. It redirects the INKEY$ function, 016A "input char from DEVN", 017F "check break/pause" and 019A "get command". Then what it does is simply SYNC before calling the ROM scan keyboard routine. This ensures that the irq has been serviced and there is plenty of time to scan the keyboard any way you like without disturbing anything.

In summary, use SYNC before calling the rom scan keyboard routine.
Thanks for the info. 8-) Attached code updated with SYNC instruction to give a flicker free split screen display.
Attachments
ZIRQ4.zip
(1003 Bytes) Downloaded 252 times
sixxie
Posts: 1346
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Mixing two different graphic modes

Post by sixxie »

sorchard wrote:The Motorola and Hitachi datasheets say slightly different things about the interrupt timing but both have a timing diagram that shows an IRQ being recognised if it occurs during the cycle before the last cycle of the current instruction.
Hmm, the note I was referring to is at the foot of the SYNC timing, but now I come to reread it, I feel I must have misunderstood before. Definitely need to knock up some test cases and get the logic16 out again. If only this had come up before the last day of my holiday ;)
It's explained in gory detail in US patent 4250546 but it's more than my tiny mind can cope with. I'd rather try and measure it!
Interesting document!
Post Reply