VDG weirdness

[prime]

Hi all,

Now that I have the Acorn Atom Colour board working correctly I thought I'd try and adapt it to work on the Dragon and CoCo, as they all use the 6847.

I have adapted the circuit so that only the video output section is used as the RAM is handled on the Dragon motherboard.

However I'm getting a strange problem in pmode 4, namely that it only displays the left hand half of the screen for some reason

I wrote this little program to verify this :

10 pmode 4,1;screen 1,0:pcls
20 for a=0 to 15
30 poke &h600+a,&haa
30 next a
40 for a=0 to 191
50 poke &h600+(a*32),&haa
60 poke &h600+(a*32)+15,&h55
70 next a
999 goto 999

This draws a line of dots all the way across the screen and down both edges, and doesn't have any line breaks, so the SAM at least is feeding it 32 bytes / line, but the VDG is only displaying the first 16.

Has anyone seen this sort of behavior before ?

If I take my board out and just use the normal video out I get the expected results, that the lines are only on the left half of the screen. All the other modes seem to work fine.

Couple of things I did notice, in pmode 4 DA0 seems to be doing long cycles (8 vid clocks), where it should do short cycles. Also the voltage levels of GM0, 1, 2 seem to only be 4.4V, I've tried swapping the PIA but this remains the same. My board wires these direct from the socket to the 6847 by a very short track so I can't account for this.

Cheers.

Phill.

[sixxie]

The behaviour kinda seems like GM1 and GM2 aren't getting through - GM0 must be (at least floating) high or you'd see a colour graphics mode.

But you tested... 4.4V seems like enough to register as high to me, so if it's not that, nothing else is coming to mind. Odd problem! You could maybe try pulling them high yourself just to be sure?

[prime]

The behaviour kinda seems like GM1 and GM2 aren't getting through - GM0 must be (at least floating) high or you'd see a colour graphics mode.

Indeed, and Pmode 3 is working correctly.

But you tested... 4.4V seems like enough to register as high to me, so if it's not that, nothing else is coming to mind. Odd problem! You could maybe try pulling them high yourself just to be sure?

What I do want to do is check the connections between the 6847 and the PIA, I checked my board for shorts, but of course there could also be problems on the Dragon motherboard.

For reference the VDG lines that go to the CPLD are :

A/G
CSS
GM0
HS (indirectly via dragon motherboard, to account for the extra lines it adds).
FS

Also Y, PA, PB and CHB via some analog circuitry & comparators.

The board doesn't have this problem in the Atom

Cheers.

Phill.

[simon]

post the code you are using to set the mode.....

the coco can do some wierd stuff with mode mismatch.....

are you using something like this:

lda #$f0
sta $ff22 (vdg)
sta $ffc3 (sam)
sta £ffc5 (sam)


if you hit $ffc1 it will display strangely (DMA mode if c1/c3/c5 are set)

/Simon

[prime]

Well I was just using pmode 4:screen 1,0 as in the basic program provided......

But I sussed the problem was a dodgy socket pin on GM1, though not sure why it wasn't affecting pmode 3.....

But it's working now, I posted some pictures on facebook : https://www.facebook.com/media/set/?set ... 56a79ff2be

Cheers.

Phill.

[tjewell]

Hi Phill - so what exactly are we looking at here? Apart from the crispest output I've ever seen from a Dragon! Is this something that plugs into the 6847 slot for those lucky peeps that have socketed chips?

[prime]

Hi Phill - so what exactly are we looking at here? Apart from the crispest output I've ever seen from a Dragon! Is this something that plugs into the 6847 slot for those lucky peeps that have socketed chips?

Yes it plugs into the 6847 socket, and produces TTL RGB. Basically I designed a Colour board for the Acorn Atom (which also has a 6847 video chip, but normally only outputs mono video), I got a bunch made before the design was complete, and so had some spare boards so tried one in the Dragon, minus some of the chips needed for the Atom, as the other function of the board on the Atom was video RAM and a noise killer that latched the video data during CPU accesses, but of course on the Dragon & CoCo the SAM does that.

Unfortunately I think it's pretty much going to be tied to being in the 6847 socket as I had to disconnect the Y signal from the rest of the machine as otherwise the circuitry in the rest of the video circuit induces noise onto that signal that degrades the video quality somewhat. I'll do some more experiments and I don't think it's production quality yet.... For a start I need to re-spin the board to not have the Atom specific components on which should shrink it, but also because the PLCC CPLD is no longer available, so I need to re-jig with a the surface mount equivalent.

Cheers,

Phill.

[tjewell]

So is this like Ed Snider's project, where he's replacing the 6847 with an FGPA emulation of one? Or does your board still use the 6847, but improve the output of it?

Cheers, Tony

[Bosco]

Wow, those screen shots look very crisp!

Picture quality is the one thing I dislike about firing up my Dragon.

[prime]

So is this like Ed Snider's project, where he's replacing the 6847 with an FGPA emulation of one? Or does your board still use the 6847, but improve the output of it?

Nope still use the 6847, just process it's output.

Cheers.

Phill.