Mixing two different graphic modes

Hardware Hacking, Programming and Game Solutions/Cheats
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

After a bit more experimentation I've discovered the effect on the frame sync irq of clr $ff02 is noticeably different to the effect of lda $ff02, but I do think I now understand what is happening. This moment of clarity won't last so I'm writing it down before it fades :)

I'm going to pretend the irq is asserted during the cycle indicated by the timing test program. In reality it could be asserted some time before depending on the details of the PIA edge detect circuit and the 6809 sync & priority network, but it doesn't really matter as far as the following is concerned.

In the case of the instruction lda $ff02, this instruction clears the frame sync irq by reading from the PIA. The read occurs on the last (5th) cycle of the instruction and the irq is cleared from the point of view of the 6809 by the time of the following (6th) cycle.

The clear operation has priority and prevents an irq being asserted during the cycle following lda $ff02. This is why we don't get an irq on phase 6 of the test. The irq returns on phase 7 because it is now being asserted after the clear operation.

For the instruction clr $ff02, this also clears the frame sync irq by reading from the PIA. It's a read-modify-write type of instruction and the read occurs on the 5th cycle. This suppresses an irq on the 6th cycle, and allows an irq on the 7th cycle, just like lda $ff02.

*However*

The instruction clr $ff02 is 7 cycles long and the 6809 irq input is level sensitive. This means an irq occurring during the first 6 cycles is cleared before the instruction is complete and the 6809 doesn't get to see it. i.e. an irq occurring during the first 6 cycles of clr $ff02 will not get serviced.

I've attached the latest test program. The large number of tests is making it unwieldy, so would probably benefit from a menu if it is to grow any more.
Attachments
tmgtest_v1_2.zip
(17.72 KiB) Downloaded 266 times
Stew
sixxie
Posts: 1346
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Mixing two different graphic modes

Post by sixxie »

Very interesting stuff.

A first attempt at tweaking XRoar as snap-2014-46673 in here.

Not happy with it, as I had to tweak the video timings - need to remeasure a bunch of stuff and see if they were values I'd applied a fudge factor to before...

Edit: ok happier now (snap-2014-46678) - implemented the 1µs delay in the PIA setting IRQ line, undone VDG timing hack.
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

@sixxie
Clean sheet now. That's pretty impressive :-)

Also pleasing to see that the split screen examples from earlier in this thread now show a similar level of flicker compared to real hardware. Can't be many emulators for any system that have this level of accuracy...
Stew
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post by pser1 »

@sorchard

I have been testing the programs I had that split the screen in two parts, the upper in PMODE3 and the lower in PMODE4
I see no difference with older XRoar versions. From the moment we added SYNC and had included the keyboard routine, all worked OK

Where we did have lots of flickering was when we try to mix two PMODE3 modes (one with each color palette)
We did it using two complementary images that when added together gave some 16 colors in the real Dragon but a headache in XRoar.
With the very last XRoar snapshot I keep getting quite a lot of flicker ... so the timing question is not related to this problem, right?

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 »

@pser1

For example, if I run your first PMODE34 program in old and new xroar versions side by side, there is a definite difference in stability in the position of the split line. (Especially if you run a BASIC loop like 10 GOTO 10)

But you're right, once we figured out that the scan keyboard routine was causing the problems, we were able to avoid the issue.

And yes, sadly, this doesn't help with the colour mixing. The flickering here is caused by the Dragon refresh rate being different to the PC refresh rate.
Stew
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post by pser1 »

@sorchard
you're right, I remember that you had comented this latter difference problem
So, no hope for the mixing of colors.
In the real hardware it is acceptable when it applies to big screen areas, but when applied to a few pixels, it creates an awful moving / vibration sensation
that, to me, invalidates the idea of doing this color mix, what a pity!
Maybe some day we could take the video signal right from the generator and this way it could show a more still image.
Hope someone will attempt to begin such a hardware project.

thanks a lot, Stew

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 »

pser1 wrote:Hope someone will attempt to begin such a hardware project.
I haven't been a member for very long so I've missed out on quite a lot but I remember reading somewhere that prime had an rgb board for the Acorn that he was hoping to try on the Dragon.

I made my own rgb board years ago for a digital monitor but it had a couple of issues and needed constant adjustment. Yet another thing to add to my list of things to look at when I get time...
Stew
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

While puzzling over some code that works on a D64 but not on D32s I found a surprising difference: The D32 generates more hsync irqs per frame. I'm working on adding some tests to the timing test program to illustrate but the numbers look something like this:

D32 (MKII ISS6):
120 hsync irqs from falling edge of FS to top of screen
63 hsync irqs from rising edge of FS to top of screen

D64:
70 hsync irqs from falling edge of FS to top of screen
38 hsync irqs from rising edge of FS to top of screen

It looks like the D32 generates an irq for every scanline whereas the D64 only generates irqs for the hsyncs from the 6847.

I'm now wondering if there are differences in the memory refresh as it is driven by hsync.

xroar seems to use the D64 timing for both machines. I'll try some different D32s when I get some more time.
Stew
sixxie
Posts: 1346
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Mixing two different graphic modes

Post by sixxie »

I think this has come up before - jmk noticed it while working on the machine detection for "Glove". Can't find it in search though.

I'm sure none of the D32 schematics I looked at reveal a reason for it: looking now, I see that there is a bit of a mystery about where the "NHS" signal originates. The LS74 in the D64 schematics (IC14, I think) isn't shown, but neither is any other source for the signal (and "HS", sourced from the VDG, must surely cease being generated, as VClk is inhibited in the same way).

The smudges on sheet appear to show NHS as an output from the SAM, but I'm pretty sure that pin is an output (the equivalent smudge on the D64 version of the sheet looks more like an outgoing arrow).

Can you spot it? I do have a couple of D32 boards (only) somewhere - one of them even worked the last time I powered it on - maybe I can figure out what's going on if nobody beats me to it :)
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:Can you spot it?
Yes, but as you point out the Dragon Data schematics are hard to follow and I had to have a quick poke around with a multimeter to get the answers.

On an ISS3 D64, these are in the same net:

IC14 pin 9 (/HS from 6847 sync'd to E)
IC39 pin 9 (SAM /HS)
IC5 pin 40 (PIA CA1)

This means 262 irqs per frame and 262 refresh 'windows'.


On a MKII ISS6 D32, these are in the same 'NHS' net:

IC14 pin 6 (/HS from 6847 XOR'd with the additional line pulses)
(The D32 ISS2 schematics show this same signal coming from IC14 pin 3)
IC15 pin 9 (SAM /HS)
IC26 pin 40 (PIA CA1)

This probably means 312 irqs per frame and 312 refresh windows. Hard to tell just by looking at the circuit. I'm not even sure if the additional pulses have the same timing as the 6847 HS pulses. (i.e does the first faked pulse arrive early or late)
Stew
Post Reply