Investgating PAL 7800 picture issues (was 7800 RGB Musings)

[juansolo]

Something new!

 

This is our single remaining PAL 7800. It's not the prettiest inside like all our machines that we experiment constantly on.

We're still doing the separate clock for the MARIA (stuck to it for the moment, it doesn't live there), we're also doing the chroma shift that we do on the NTSC machines, but using a different 4050 who's timings seem to be more in line with the PAL machine's offset. But now we're running that through a 74HCT32 which is dealing with the TIA and MARIA chroma's instead of the relay we were using previously, and is also buffering the unbuffered (on a PAL 7800) LUM0 line. Then that goes into our little FMS6400 S-Video/Composite board that we use for just about everything now.

Anyhow, can't see any bleed at all from the pic Cleggy sent me from the BVM. Sad thing of course is that we do so few PAL machines that it's probably not worth the effort of doing a PCB for it, but I might. It's always the ball-ache of having to re-acquaint myself with KiCad, something I use so infreqently I constantly forget, and knocking things out on veroboard is just easy and quick (if ugly). Anyhow, a bit more testing and we'll see where this goes next.

Edited July 28, 2023 by juansolo

[+karri]

28 minutes ago, juansolo said:

Something new!

 

This is our single remaining PAL 7800. It's not the prettiest inside like all our machines that we experiment constantly on.

We're still doing the separate clock for the MARIA (stuck to it for the moment), we're also doing the chroma shift that we do on the NTSC machines, but using a different 4050 who's timings seem to be more in line with the PAL machine's offset. But now we're running that through a 74HCT32 which is dealing with the TIA and MARIA chroma's instead of the relay we were using previously, and is also buffering the unbuffered (on a PAL 7800) LUM0 line. Then that goes into our little FMS6400 S-Video/Composite board that we use for just about everything now.

Anyhow, can't see any bleed at all from the pic Cleggy sent me from the BVM. Sad thing of course is that we do so few PAL machines that it's probably not worth the effort of doing a PCB for it, but I might. It's always the ball-ache of having to re-acquaint myself with KiCad, something I use so infreqently I constantly forget, and knocking things out on veroboard is just easy and quick (if ugly). Anyhow, a bit more testing and we'll see where this goes next.

I already found the xtal module for my PAL. The latest KiCad is even easier to use than the one before. It would be nice to have a pcb design.

[juansolo]

9 hours ago, karri said:

I already found the xtal module for my PAL. The latest KiCad is even easier to use than the one before. It would be nice to have a pcb design.

I've knocked a PCB layout together. But we've still got testing to do... Couple of issues to iron out.

[juansolo]

We need to do more work on this. We've done a second machine (for @Guitari who's machine we had in to deal with a different problem) and though the mod is incredibly simple in terms of parts and removes the need for relays and clock crystals to get a good picture, it's not straightforward to install/setup. Plus we're having some issues in getting both a good S-Video and Composite picture out of it. We can do one or the other, but not both, which is annoying and we'd like to address that. Anyhow thought I'd add the pics from his machine.

[+karri]

2 hours ago, juansolo said:

Plus we're having some issues in getting both a good S-Video and Composite picture out of it. We can do one or the other, but not both

S-Video is rare today compared to composite input. So I would be happy with composite only as lots of TV sets have it.

[Guitari]

17 minutes ago, karri said:

S-Video is rare today compared to composite input. So I would be happy with composite only as lots of TV sets have it.

Hi Karri, 

I don't mind the S-video. My TV has a variety of inputs. 

Also I'll be making good use of the RGB output via SCART from the GD7800. 🙂 

 

 

[juansolo]

Hmmmm, it's annoying. We've managed to make a simple mod that doesn't need external clocks or relays and can look really good (still got the Maria colour running, but nothing we can do about that). What it also does do is completely eliminate the chroma/luma timing mismatches that seem to effect all 7800's. But we're struggling to make it run on everything. Get it set up perfect on one set and it needs tweaking on another. It needs more work and sadly our 30+ year old oscilloscope bit the dust a couple of days ago (we're not having great luck with our tools lately. Our iron died the week before but that was at least under warranty).

Having Guitari's machine as well as our own PAL machine made life a lot easier as we can compare changes we make between the two, but that needs to go back now. We're sending it back with proto 2 on it to see if it works on his TV. If not it'll come back and either go back to it's old MK mod or a UAV with our mods to make it work better.

The PAL 7800 is so utterly frustrating it's untrue. There's a reason we abandoned it. We do want to try and make this mod work, but we're likely to do that on an NTSC machine. We're gonna need a new scope first though, so it might be a while.

 

EDIT: After tuning @Guitari's machine on my TV's, Cleggy takes it back to his and the horizontal interference makes a return... Add the external clock though and it's gone... I hope this works on your TV dude, because this is about as good as we've ever had from a PAL 7800.

Edited August 7, 2023 by juansolo

[juansolo]

It's final form (well with the shield off for the photo):

[Guitari]

I now have the machine back from Juansolo who has managed to fix the issues. Only one thing remains and that's the clipping of the left edge of the image on my Panasonic TV. So if @SainT would be kind enough to implement positioning on the next firmware update that would be immense. This is a condition of the TV as it happens to a certain extent also from my 32X, and so not a condition of the GD7800. 

[SainT]

3 hours ago, Guitari said:

I now have the machine back from Juansolo who has managed to fix the issues. Only one thing remains and that's the clipping of the left edge of the image on my Panasonic TV. So if @SainT would be kind enough to implement positioning on the next firmware update that would be immense. This is a condition of the TV as it happens to a certain extent also from my 32X, and so not a condition of the GD7800. 

Nice! I'm hoping this should be relatively easy as I'm super-super-mega low on FPGA space... 😆

It would definitely be a nice feature to have to help with compatibility with direct connection to LCD TV's.

[Guitari]

Fingers crossed 🤞!! 

[juansolo]

Testing re-commences...

I was skeptical, however initial results are quite promising.

Obviously a load more testing to do, so I'm not getting too excited yet.

[juansolo]

Well I'm not sure what to do/say about this. The new mod works. It's output can be absolutely staggering, essentially the best output we've had out of both PAL and NTSC 7800's. The mod is simplicity itself with very few parts. However fitting and setting the thing up isn't, which is a bit of an understatement. Parts need to be pulled, one resistor needs to be swapped (both machines), the PAL machine still needs the seperate clock and the NTSC machine needs the MARIA socketing so you can lift the chroma pin. So it's a bit of a 'mare.

 

The MARIA thing was surprising. We were seeing chroma bleed on the luma signal and it's happening on the 7800 side of things. Lift the pin and run direct from that and it goes away (there's a couple of traces about a couple of cm long that are less than a mm apart, we suspect it's happening there). Incidentally we have the same on the TIA, but we've no idea at all where that's happening and running direct from the TIA doesn't remove it from the signal. That's just baffling. For this mod, like our previous ones, we pull a load of surplus stuff that can cause interference. We're also lowering the sync level as this mod seems to need that. The two trimmers on the boards won't actually be on boards from this point forth, that was just to determine the chroma/luma levels. That took a lot of tweaking, but surprisingly they're the same across PAL and NTSC.

 

The rest of it just seems to come down to console variability. The PAL machine for example, has a picture on the 2600 side so good you'd be hard pushed to believe it wasn't RGB. The pic on the NTSC 7800 side is also pretty much staggering. It's not perfect, on a very revealing screen you can still see colour rolling on the PAL machine and really mild jailbars on the NTSC. But you're starting to get super analytical at that point (which we are, so that doesn't help...). The picture is super sharp, way sharper than via my modded (has chroma shift and switched chromas) UAV based NTSC 7800. We suspect that the UAV is doing some filtering somewhere that will go a long way to hiding some of the sins (jailbars and what have you) that a lot of old machines might produce.

 

The UAV should still be the way to go on NTSC machines. They're fit and forget, add @-^CrossBow^- adapter board and it's a borderline trivial install that doesn't remove any other functionality and the overall picture is still exceptionally good. It also has a good composite out, which our mod doesn't (we've no idea why, the FMS6400 is chewing on the same signal for both, but composite just isn't anywhere near as good). For PAL machines you're still kinda boned. The GD7800 is your best bet and just go RGB here.

 

Our mod... Dunno, we mainly did it because it was interesting, but I don't think it's anything that can really be let out into the wild. We may end up installing it for people who's machines pass through us, but it being S-Video only and requiring a lot of work to put in really limits it. So for what it's worth, here's some pics of the final installs in both machines.

 

Edited August 30, 2023 by juansolo

[+-^CrossBow^-]

@juansolo So essentially the minor color bleed that is still present on the NTSC is due to something interferring with the chroma output off the Maria? I mean, pulling that pin or isolating it if soldered to the board isn't that difficult, but then it means the RF is out of the picture at that point?

 

I might go ahead and try this on my lab unit that has a UAV in it already along with the chroma fix on one of my boards. So basically, lift the chroma and just run that straight to the UAV bypassing the need for the chroma fix? Or run that to the MC in on the chroma fix still?

 

 

[juansolo]

8 minutes ago, -^CrossBow^- said:

@juansolo So essentially the minor color bleed that is still present on the NTSC is due to something interferring with the chroma output off the Maria? I mean, pulling that pin or isolating it if soldered to the board isn't that difficult, but then it means the RF is out of the picture at that point?

Most of that is still the offset (though this mod seems to get that to it's absolute minimum, one thing it does have in it's favour). I've still got the UAV and chroma offset board on my 7800 which we use as a basline. For what it's worth we're seeing it on an oscilloscope and it shows as jailbars on our mod. You can't see it on a UAV because I suspect the filtering is so good (which is possibly why it has a softer image than our mod), so I don't think it's worth doing.

8 minutes ago, -^CrossBow^- said:

I might go ahead and try this on my lab unit that has a UAV in it already along with the chroma fix on one of my boards. So basically, lift the chroma and just run that straight to the UAV bypassing the need for the chroma fix? Or run that to the MC in on the chroma fix still?

It will break RF and as I say, other than through an oscilloscope, you'll not really see any difference in the picture through the UAV. I didn't bother doing it to mine and mine doesn't have RF. I didn't think it'd make any difference. Yeah, you still need the chroma fix board.

Edited August 30, 2023 by juansolo

[marauder666]

There was a tiny colorburst on the NTSC machine luma output, wouldn't have known until a Sony TV I have kept locking onto the S video luma signal as composite, and the colour amp in the TV tried to create the colour from it, badly.  Scoped the luma out and there was a tiny chroma signal, could see the colorburst after the sync pulse.

 

Took the chroma pin out and wired directly, and the colorburst was gone.   

 

2600 side is the same, but lifting chroma pin didnt fix the chroma in luma.

 

We scoped John's UAV machine, and couldn't see the colorburst on the luma out, maybe the UAV does some more filtering.

 

Edited August 30, 2023 by marauder666

[juansolo]

Lots of pics incoming. We've been testing the two systems on lots of TVs/Monitors. Usual caveats apply to the pics: CRT's are hard to photograph, if you see a dark line, that's likely it scanning and isn't in the image. Also the camera we used doesn't like certain reds for some reason. The right hand tank on PAL combat is very pink, but for some reason in the pics it's super washed out (also the sandy yellow surround). It's a weird old camera, I used to have a red car it made look orange... Also go full res or you won't really be getting an idea of what it's like. I've scaled all of the images to 1920xwhatever. Pics are BallBlazer (7800), Combat (2600). 2 per screen to get an idea. All pics are S-Video out from console, the rest of the chain will be noted in each batch.

 

PAL7800 - Koryuu (S in, component out) - Sony BVM (CRT)

NTSC7800 - Koryuu (S in, component out) - Sony BVM (CRT)

PAL7800 - direct - Samsung (LCD)

NTSC7800 - direct - Samsung (LCD)

PAL7800 - Koryuu (S in, component out) - GBS Control (component in, VGA out) - LaCie ElectronBlue19 (CRT)

No NTSC for this as it wouldn't play nice with this combination

PAL7800 - direct - Toshiba (LCD)

NTSC doesn't play nice with this set. It's notoriously finicky this one.

This TV loses sync with any 2600 for some reason which looks like this:

There's more to come as we test more sets. Where we have to use the Koryuu with the BVM as it has no S-Video board, we can go direct into a PVM so we'll do that. It's about as accurate as we can get as the Koryuu will auto-adjust levels and the PVM wont. Got another panel we can stick them through also.

Edited August 30, 2023 by juansolo

[juansolo]

Round 2. This has become more of a TV compatability test than anything else. Cleggy throught he'd try the NTSC machine into the Tosh through the Koryuu (so component input to the TV) and that had some interesting results in that now the NTSC machine worked. But also the 2600 side of things on both consoles is now stable. It must be doing some digital processing there then. Though the NTSC 2600 has an odd line on it on the right, possibly noise being interpreted as video?

 

NTSC7800 - Koryuu (S to component) - Toshiba (LCD)

PAL7800 - Koryuu (S to component) - Toshiba (LCD)

NTSC7800 - direct - Sony 15" (LCD)

Update on odd line. Shows up here too on the 15" Sony LCD, so not the Koryuu.

Just really noticable on the much larger Tosh. Looking back it's on all other images too.

PAL7800 - direct - Sony 15" (LCD)

Yes this panel has a stuck pixel...

Edited August 31, 2023 by juansolo

[juansolo]

Really this is the one that matters most. The BVM, though a far better monitor (it's convergence is perfect), isn't set up for S-Video so we have to add the Koryuu into the mix that corrupts results a bit. This 14" PVM is essentially this is as 'correct' as a picture as we can get ultimately (I've got a bigger PVM than this, but it's convergence isn't as good. Probably could do with a re-cap). There's a little bit of blooming happening with full white. The BVM just takes this in it's stride because it's a monster... We may have to dial this down a little.

 

PAL7800 - direct - Sony PVM 14" (CRT)

NTSC7800 - direct - Sony PVM 14" (CRT)

I have a famously intolerant Panasonic plasma to try it on when Cleggy comes over at the weekend (it's RGB is just broken and has been from new). It'll have to go through the Koryuu to work, but it'll be interesting. Finally there's my big PVM. It shouldn't be much different to the little one to be fair.

Edited August 31, 2023 by juansolo

[juansolo]

Well we've at least one AA members PAL machine heading our way for the mod that'll provide more testing. We're at the stage where the trimmers can likely become resistors now, but it's still a lot of de-soldering and faff... But while I'm doing it, I may as well document the install even though at this stage I really don't think this is a DIY job. PAL machines are notoriously horrible to mod also. With teeny, tiny solder pads that love to lift and terrible quality solder.

 

We've also continued testing it on different TVs and monitors, but I realised I was just filling the thread with Ballblazer and Combat and it's probably only really useful to us. The long and short of that was the PAL machine is more compatible than the NTSC one, which makes sense given we're in a PAL region. But also that the more modern a panel is, the more chance there is that it's not going to handle it. The Koryuu seems a good option there if your TV can take component video in. Again nothing is guarenteed, but then nothing is when you're hitting a modern TV with piss poor analogue signal handling with a 30 year old console that was never meant to output S-Video and has some challenging faults that have to be worked around.

 

Really we could do with testing it with things like the RetroTink, but we haven't got one of those. It works with an Extron IN1508 (bought for £20 on eBay) but that does bring with it lag and deinterlacing issues sadly. Could have been a super cheap solution otherwise and it works with NTSC where the Koryuu > GBS Control option didn't.

Edited September 1, 2023 by juansolo

[+Muddyfunster]

50 minutes ago, juansolo said:

The Koryuu seems a good option there if your TV can take component video in.

OSSC can take component too, so it works well for upscaling. 

[juansolo]

I was going to buy a RetroTink for testing (as I don't actually need one), then I saw what sort of money they actually cost even for the simple ones... Errp, nope, can't justify that sadly

[juansolo]

Minor venting incoming...

 

Both modded machines over at mine. Successful testing all round, even the one set of mine that wouldn't previously sync to the mod now does with no problems. All great. Plug my own machine back in and it shits itself spectacularly. Corrupt graphics and crashing in both sides. Not the BIOS (the only socketed thing on that board so a super easy test). Not the cart slot as it does it with the built in Asteroids. So current thinking is probably either RAM or processor... Will delve into it more on Weds. As it is, the mod is good, and I'm now 7800-less as my NTSC machine with the UAV is dead, and my PAL machine ended up being used for parts in a repair.

 

Bah! Time to start watching eBay again... /if there's anyone with a spare NTSC 7800 in the UK who want's to sell it for sensible money, PM me.

Edited September 3, 2023 by juansolo

[juansolo]

@-^CrossBow^- You ever had this? I know it's not the cart slot as it does this with the inbuilt Asteroids and it's not the BIOS because I've already tried another one. Massive graphical corruption and hanging. Consistent across both 7800 and 2600. This is Galaga:

I'm planning on socketing the RAM first as that seems most likely and I can steal some from my PAL donor to try. But beyond that will take some proper investigation.

[+-^CrossBow^-]

@juansolo Not anything quite that severe but the fact you stated it is happening with both 2600 and 7800 games leads me to either the CPU or the RIOT. 2600 games aren't using the extra VRAM far as I know and only use what is in the 2600 hardware chips in the console. 

 

I have seen something similar but again not this bad due to a faulty 7432 that feeds some of the signals to the RF section and is before where we tap them off the board for UAV.