Forums

I notice in the documentation for the TMS9918, which I believe is what the SMS VDP is based on, on page 21 (section 2.4, 2-12, fig.2.4) they describe the ability for the VDP to mix in an additional layer behind the backdrop from the input of one of its pins.

Does anyone know if this feature is still part of the SMS VDP, and if there's any way to access it? I checked the expansion port but nothing on there seems to go to the VDP. Can the Z80 address it via I/O to the VDP?

Ultimately I'm trying to answer this: can I build an additional piece of hardware (even if it has to be soldered to the pins of the VDP) that would act as some kind of background generator without needing to use cycles of the VDP/Z80 or consume any system memory?

Or am I totally misunderstanding what that feature of the TMS9918 is all about?

For the TMS it was about overlaying an external video feed, I think there was a minor Japanese Laserdisc-MSX thing that used it. It’s conceptually similar to a Teletext overlay or a TV’s on-screen menus. The Sega VDP doesn’t have it at all, as far as I know. You could probably solder it into an SG-1000.

Ah, that's a shame. Was really hoping I could rope in something akin to the battle backgrounds of Earthbound "free of charge" (in a processing sense), even if it meant building some ridiculous piece of hardware with its own processor(s)/memory.

I suppose I could still do it, given that I'm writing an emulator, so I could just make my emulated VDP do that additional bit from the TMS chip, but I feel like that'd be cheating. Really want to keep things to stuff that could be done with the real hardware, even if that means some manual soldering/building custom expansion hardware and that the software would have to be aware of it with no expectation of "backwards compatibility" with commercial SMS software.

Well, you could build some 32X-like monstrosity that would genlock over the SMS output via a video pass-through... technically possible (although tough if you want to pass through RF!) but you'd need to use colour keying to apply a background effect.

There is a table on Wikipedia that describes which parts include the video in feature and which don't.

The TMS9918a chips, not used in any Sega consoles, supports composite video in and out.

The TMS9928a, used in the SG-1000 / SC-3000, has no video input, but gains support for component video output.

JoppyFurr wrote

The TMS9918a chips, not used in any Sega consoles, supports composite video in and out.

Huh, I was going off the passage in the VDP doc by Charles MacDonald which says:

Quote

The Video Display Processor (VDP) is a graphics chip derived from the Texas Instruments TMS9918, used by Sega in their video game consoles and arcade hardware.

But I suppose he meant that in the more general sense of 9918->9928 and versions of both being used as the basis for various Sega VDPs

Either way, I did figure it was a longshot that Sega would leave that in.

Did get me thinking, thanks to Maxim, about the possibility of a reverse 32X (using it to just render an additional background layer vs it using the console for that(ish)). Still have a long ways to go before I get to that stage of my project, but at least the dream of fancier-than-possible backgrounds in my SMS game haven't died.

The SMS VDP handles this more like the V9938/V9958 do: when bit 0 of register #0 is set the composite sync pin becomes an input instead of an output, and you can drive it with a composite sync signal from some other source. But that's just a sync signal, there's no way to input a video signal that is internally mixed with the VDP video. Normally nothing else drives this pin on the SMS so turning that bit on causes loss of sync and the TV freaks out.

When you input external sync the VDP is still limited to the same resolution it's designed for. It's more about ensuring the horizontal and vertical sync signals are synchronized such that the display is centered with respect to the other video source. Like if you had two SMS VDPs connected one could be the sync output, the other would be the sync input, and it would be guaranteed they'd perfectly overlap instead of being-off center.

As for how video is overlapped there's a VDP pin called YS# that indicates if the current pixel data being shown is transparent or opaque. An external analog multiplexer could use that signal to route the RGB output of two SMS VDPs to the video output in this case, overlapping one whole layer (bg+sprites) over the other wherever pixel 0 is shown. Here we're talking about a 2nd VDP, but that could be your own video hardware too.

I think the difficulty would be synchronizing your video hardware to the VDP. Something like a EL1883 sync splitter would let you recover H-Sync and V-Sync from the composite sync output but there's probably some propagation delays you'd have to compensate for to get your graphics layer aligned with the SMS.

Check out the V9938/V9958 datasheet/application manual if you want to get a feeling of how external video can be mixed with the VDP in general. It sort of applies to the SMS in a more broad sense.

Charles MacDonald, thank you sir. That sounds like exactly the kind of shannanigans I am looking to get up to. The H/Vsync skew might actually be useful in producing the kind of trippy visuals I'd want this to produce.

I'm going to try and summarize what you're suggesting to ensure I'm following: A separate piece of hardware could include its own video processor and sync its output to the SMS VDP using the signal from its comp sync pin. The two video signals can then be multiplexed such that a certain value (transparent) "falls through" to the second output to show the second video processors output. This signal then I assume would have to override the regular output of the master system.

How close to home am I?

Quote

How close to home am I?

You're exactly right, yep!

Maybe as an experiment generating some vertical white stripes on every other pixel column would be a good way to see if you can get that to overlay with the SMS video properly.

Then you could verify the alignment between the layers and look for timing issues before committing to a substantially more complex design. If that works, pretty much everything else should too.

Perfect, that'll make for an excellent starting point. Originally I was thinking of doing this through pure emulation and just sort of be happy knowing that'd it'd most likely probably run on real hardware

Changed my mind on that though. Originally the goal of the project was to extend my knowledge further down the software stack by implementing an emulator and building my own suite of dev tools, but in thinking about it more going a little lower into the hardware itself should be very enlightening. Also finally gives me a chance to complete my understanding of that stuff, did some slightly above non-trivial circuit design 10-15 years ago, but software was much more enticing to me at the time and I've only now come up for air. Luckily MIT has what so far has been a lovely course on the subject available online.

I guess the next step for me is to figure out if this can work via the expansion port, if it has to be a cartridge port dongle, or if it'll be some kind of true monstrosity and require soldering.

Oh, and one other thing I'm curious about (please don't hate me) would it be possible for this rig to include its own sound hardware. Ive always felt that (plsnobully) the SMS soundchip was its weakest element. If you could say, replace that with the nes' sound chip I think you'd have hands down the single greatest 8bit console.

bps wrote

I guess the next step for me is to figure out if this can work via the expansion port, if it has to be a cartridge port dongle, or if it'll be some kind of true monstrosity and require soldering.

Funnily enough, I had been looking into this sort of thing a few months ago, purely out of curiosity. Accepting VDP writes through the expansion port, also having a YM2413 onboard, and just barely fitting inside the address space allowed in the Mark III expansion port.

Nothing really stopping this. I'm pretty sure you just need a method of properly multiplexing the RGB video, and properly mixing the audio from both sources (or all three, if you include the YM2413).

bps wrote

Oh, and one other thing I'm curious about (please don't hate me) would it be possible for this rig to include its own sound hardware. Ive always felt that (plsnobully) the SMS soundchip was its weakest element. If you could say, replace that with the nes' sound chip I think you'd have hands down the single greatest 8bit console.

Definitely look into also having full proper YM2413 support, especially if you're plugging into the expansion slot.
Look into how the Mark III's expansion slot works, though - for full authenticity.

It looks like you're going to meet me into implementing this own concept. This's what I get for being lazy for half a year. :)

Glad to hear I wasn't out to lunch thinking this'd be doable. I hadn't thought of using the fm expansion as the audio enhancement, I was thinking it'd sound like the built in audio with an extra voice, but in checking out some comparisons it seems pretty capable, def. An improvement over the psg sound. Still not a huge fan of the genesis-y dull/scratchy sound effects, but compatibility with real sms software is a massive plus.

As for me stealing your thunder I wouldn't worry too much, the hardware side for me will certainly be slow going. Ive got two years carved out for the project, and I'm thinking a lot of the first six months to a year will be consumed with electrical engineering studies. Might be overestimating that a bit, I've got a fair amount of practical experience, but stuff like Maxwell's equations are rough on me.

Plus, why compete when we can cooperate?

I've setup a little blog on my site to act as a development log for my SMS project(s). You can find it at http://bypass.systems/sms (once the DNS propagation is complete anyways, if it isn't working for you can use the direct AWS S3 hosting URL: http://bypass.systems.s3-website.ca-central-1.amazonaws.com/sms).

So far I've got some progress on the robot arms, the dev tools, and my z80 can NOP.

The site itself is still very much a WIP, as is everything else. I've only tested it @ 4K and ultrawide resolutions, so things may fly apart at the seams on lower res displays. Eventually it'll all work all the way down to mobile.

Also, I know HTTP is no longer in vogue, but this is a static JavaScript SPA, there's no database, server or fancy backend involved, so there's really not much to secure.

Author	Message
bps Joined: 18 Nov 2020 Posts: 12	SMS VDP external video signal mixing Posted: Wed Nov 18, 2020 9:36 am
bps Joined: 18 Nov 2020 Posts: 12	I notice in the documentation for the TMS9918, which I believe is what the SMS VDP is based on, on page 21 (section 2.4, 2-12, fig.2.4) they describe the ability for the VDP to mix in an additional layer behind the backdrop from the input of one of its pins. Does anyone know if this feature is still part of the SMS VDP, and if there's any way to access it? I checked the expansion port but nothing on there seems to go to the VDP. Can the Z80 address it via I/O to the VDP? Ultimately I'm trying to answer this: can I build an additional piece of hardware (even if it has to be soldered to the pins of the VDP) that would act as some kind of background generator without needing to use cycles of the VDP/Z80 or consume any system memory? Or am I totally misunderstanding what that feature of the TMS9918 is all about?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Wed Nov 18, 2020 10:58 am
	For the TMS it was about overlaying an external video feed, I think there was a minor Japanese Laserdisc-MSX thing that used it. It’s conceptually similar to a Teletext overlay or a TV’s on-screen menus. The Sega VDP doesn’t have it at all, as far as I know. You could probably solder it into an SG-1000.

bps Joined: 18 Nov 2020 Posts: 12	Posted: Wed Nov 18, 2020 11:41 am
bps Joined: 18 Nov 2020 Posts: 12	Ah, that's a shame. Was really hoping I could rope in something akin to the battle backgrounds of Earthbound "free of charge" (in a processing sense), even if it meant building some ridiculous piece of hardware with its own processor(s)/memory. I suppose I could still do it, given that I'm writing an emulator, so I could just make my emulated VDP do that additional bit from the TMS chip, but I feel like that'd be cheating. Really want to keep things to stuff that could be done with the real hardware, even if that means some manual soldering/building custom expansion hardware and that the software would have to be aware of it with no expectation of "backwards compatibility" with commercial SMS software.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Wed Nov 18, 2020 4:23 pm
	Well, you could build some 32X-like monstrosity that would genlock over the SMS output via a video pass-through... technically possible (although tough if you want to pass through RF!) but you'd need to use colour keying to apply a background effect.

JoppyFurr Joined: 11 Mar 2018 Posts: 65 Location: New Zealand	Posted: Wed Nov 18, 2020 9:29 pm
	There is a table on Wikipedia that describes which parts include the video in feature and which don't. The TMS9918a chips, not used in any Sega consoles, supports composite video in and out. The TMS9928a, used in the SG-1000 / SC-3000, has no video input, but gains support for component video output.

bps Joined: 18 Nov 2020 Posts: 12	Posted: Thu Nov 19, 2020 4:07 am
bps Joined: 18 Nov 2020 Posts: 12	JoppyFurr wrote The TMS9918a chips, not used in any Sega consoles, supports composite video in and out. Huh, I was going off the passage in the VDP doc by Charles MacDonald which says: Quote The Video Display Processor (VDP) is a graphics chip derived from the Texas Instruments TMS9918, used by Sega in their video game consoles and arcade hardware. But I suppose he meant that in the more general sense of 9918->9928 and versions of both being used as the basis for various Sega VDPs Either way, I did figure it was a longshot that Sega would leave that in. Did get me thinking, thanks to Maxim, about the possibility of a reverse 32X (using it to just render an additional background layer vs it using the console for that(ish)). Still have a long ways to go before I get to that stage of my project, but at least the dream of fancier-than-possible backgrounds in my SMS game haven't died.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Thu Nov 19, 2020 5:36 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	The SMS VDP handles this more like the V9938/V9958 do: when bit 0 of register #0 is set the composite sync pin becomes an input instead of an output, and you can drive it with a composite sync signal from some other source. But that's just a sync signal, there's no way to input a video signal that is internally mixed with the VDP video. Normally nothing else drives this pin on the SMS so turning that bit on causes loss of sync and the TV freaks out. When you input external sync the VDP is still limited to the same resolution it's designed for. It's more about ensuring the horizontal and vertical sync signals are synchronized such that the display is centered with respect to the other video source. Like if you had two SMS VDPs connected one could be the sync output, the other would be the sync input, and it would be guaranteed they'd perfectly overlap instead of being-off center. As for how video is overlapped there's a VDP pin called YS# that indicates if the current pixel data being shown is transparent or opaque. An external analog multiplexer could use that signal to route the RGB output of two SMS VDPs to the video output in this case, overlapping one whole layer (bg+sprites) over the other wherever pixel 0 is shown. Here we're talking about a 2nd VDP, but that could be your own video hardware too. I think the difficulty would be synchronizing your video hardware to the VDP. Something like a EL1883 sync splitter would let you recover H-Sync and V-Sync from the composite sync output but there's probably some propagation delays you'd have to compensate for to get your graphics layer aligned with the SMS. Check out the V9938/V9958 datasheet/application manual if you want to get a feeling of how external video can be mixed with the VDP in general. It sort of applies to the SMS in a more broad sense.

bps Joined: 18 Nov 2020 Posts: 12	Posted: Thu Nov 19, 2020 6:15 am
bps Joined: 18 Nov 2020 Posts: 12	Charles MacDonald, thank you sir. That sounds like exactly the kind of shannanigans I am looking to get up to. The H/Vsync skew might actually be useful in producing the kind of trippy visuals I'd want this to produce. I'm going to try and summarize what you're suggesting to ensure I'm following: A separate piece of hardware could include its own video processor and sync its output to the SMS VDP using the signal from its comp sync pin. The two video signals can then be multiplexed such that a certain value (transparent) "falls through" to the second output to show the second video processors output. This signal then I assume would have to override the regular output of the master system. How close to home am I?

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Thu Nov 19, 2020 7:25 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote How close to home am I? You're exactly right, yep! Maybe as an experiment generating some vertical white stripes on every other pixel column would be a good way to see if you can get that to overlay with the SMS video properly. Then you could verify the alignment between the layers and look for timing issues before committing to a substantially more complex design. If that works, pretty much everything else should too.

bps Joined: 18 Nov 2020 Posts: 12	Posted: Fri Nov 20, 2020 5:02 am
bps Joined: 18 Nov 2020 Posts: 12	Perfect, that'll make for an excellent starting point. Originally I was thinking of doing this through pure emulation and just sort of be happy knowing that'd it'd most likely probably run on real hardware Changed my mind on that though. Originally the goal of the project was to extend my knowledge further down the software stack by implementing an emulator and building my own suite of dev tools, but in thinking about it more going a little lower into the hardware itself should be very enlightening. Also finally gives me a chance to complete my understanding of that stuff, did some slightly above non-trivial circuit design 10-15 years ago, but software was much more enticing to me at the time and I've only now come up for air. Luckily MIT has what so far has been a lovely course on the subject available online. I guess the next step for me is to figure out if this can work via the expansion port, if it has to be a cartridge port dongle, or if it'll be some kind of true monstrosity and require soldering. Oh, and one other thing I'm curious about (please don't hate me) would it be possible for this rig to include its own sound hardware. Ive always felt that (plsnobully) the SMS soundchip was its weakest element. If you could say, replace that with the nes' sound chip I think you'd have hands down the single greatest 8bit console.

Flygon Joined: 30 Jun 2016 Posts: 196 Location: Melbourne, Australia	Posted: Sat Nov 21, 2020 6:42 am
	bps wrote I guess the next step for me is to figure out if this can work via the expansion port, if it has to be a cartridge port dongle, or if it'll be some kind of true monstrosity and require soldering. Funnily enough, I had been looking into this sort of thing a few months ago, purely out of curiosity. Accepting VDP writes through the expansion port, also having a YM2413 onboard, and just barely fitting inside the address space allowed in the Mark III expansion port. Nothing really stopping this. I'm pretty sure you just need a method of properly multiplexing the RGB video, and properly mixing the audio from both sources (or all three, if you include the YM2413). bps wrote Oh, and one other thing I'm curious about (please don't hate me) would it be possible for this rig to include its own sound hardware. Ive always felt that (plsnobully) the SMS soundchip was its weakest element. If you could say, replace that with the nes' sound chip I think you'd have hands down the single greatest 8bit console. Definitely look into also having full proper YM2413 support, especially if you're plugging into the expansion slot. Look into how the Mark III's expansion slot works, though - for full authenticity. It looks like you're going to meet me into implementing this own concept. This's what I get for being lazy for half a year. :)

bps Joined: 18 Nov 2020 Posts: 12	Posted: Sat Nov 21, 2020 7:08 am
bps Joined: 18 Nov 2020 Posts: 12	Glad to hear I wasn't out to lunch thinking this'd be doable. I hadn't thought of using the fm expansion as the audio enhancement, I was thinking it'd sound like the built in audio with an extra voice, but in checking out some comparisons it seems pretty capable, def. An improvement over the psg sound. Still not a huge fan of the genesis-y dull/scratchy sound effects, but compatibility with real sms software is a massive plus. As for me stealing your thunder I wouldn't worry too much, the hardware side for me will certainly be slow going. Ive got two years carved out for the project, and I'm thinking a lot of the first six months to a year will be consumed with electrical engineering studies. Might be overestimating that a bit, I've got a fair amount of practical experience, but stuff like Maxwell's equations are rough on me. Plus, why compete when we can cooperate?

bps Joined: 18 Nov 2020 Posts: 12	Posted: Wed Dec 02, 2020 3:01 am
bps Joined: 18 Nov 2020 Posts: 12	I've setup a little blog on my site to act as a development log for my SMS project(s). You can find it at http://bypass.systems/sms (once the DNS propagation is complete anyways, if it isn't working for you can use the direct AWS S3 hosting URL: http://bypass.systems.s3-website.ca-central-1.amazonaws.com/sms). So far I've got some progress on the robot arms, the dev tools, and my z80 can NOP. The site itself is still very much a WIP, as is everything else. I've only tested it @ 4K and ultrawide resolutions, so things may fly apart at the seams on lower res displays. Eventually it'll all work all the way down to mobile. Also, I know HTTP is no longer in vogue, but this is a static JavaScript SPA, there's no database, server or fancy backend involved, so there's really not much to secure.

Forums

View topic - SMS VDP external video signal mixing