Using a Master System Light Phaser in Mega Drive Menacer games

Wednesday, 18th March 2020

I'm a big fan of light gun games and have guns and games for most of the Sega systems – the Master System's Light Phaser, the Saturn's Virtua Gun and the Dreamcast's gun all get plenty of use.

One notable omission is the Sega Mega Drive and its Menacer light gun. This is a wireless gun with a range of bulky plastic accoutrements that represented Sega's efforts in the 16-bit generation; unfortunately only three games were released for it on the Mega Drive – a six-in-one collection of minigames that came bundled with the gun, a port of T2: The Arcade Game and the ferociously-expensive Body Count.

Ultimately the gun was a flop and they are not cheap to pick up second-hand (and are often missing most of the bits) so I haven't sought one out, however I did recently buy a cheap job lot of games which included a loose copy of T2: The Arcade Game.

I tried the game with the regular control pad and found it a disappointing experience (as most light games are when played with a pad!) so thought I'd see if I could get it to work with one of my Master System Light Phaser guns.

Of course, the game wouldn't detect that the gun was plugged in. Controllers on the Master System were generally very simple affairs, with one pin on the controller port per button (no multiplexing or serial data transfers here). On the regular control pad four data lines were used for the d-pad directions and two data lines (TL and TR) were used for the two buttons. These data lines were pulled high by the console and the control pad just contained switches that connected these data lines to ground when pressed for simple active-low logic.

The Light Phaser doesn't make use of the four d-pad data lines and only has one button so only uses one of those two data lines (TL) however it does make use of another pin on the controller (TH) for its light sensor. When this pin goes low the console latches the video chip's horizontal counter and the game software can read this and the free-running vertical counter to determine what point on the screen the console was outputting at the point the gun "saw" the light from the TV (and from this work out where the gun is aiming).

The Mega Drive is descended from the Master System's design and has very similar controller ports. The d-pad's four data lines are named DATA0 to DATA3, and by default the B and C buttons are mapped to the two TL and TR inputs like the two buttons on the Master System controller. However, the Mega Drive controller adds two extra buttons (A and Start). These two extra buttons share the TL and TR data lines and whether they are B and C or A and Start depends on the state of the TH line which is configured as an output from the console.

This use of the TH line to choose which buttons are mapped to which data lines is also used for controller identification. When TH is high the d-pad is mapped to the four data bits as normal. However, with a normal controller, when TH goes low data lines 2 and 3 (corresponding to left and right) go low also. This is normally impossible, as you can't physically press left and right simultaneously on a Master System controller, so a controller that ignores the state of the TH line won't be detected as a Mega Drive controller.

The device ID is encoded as a four-bit value according to the following logic:

ID bit	TH state	Data bits
3	High	3 OR 2
2	High	1 OR 0
1	Low	3 OR 2
0	Low	1 OR 0

For example, to read a regular controller's ID set TH to high and read the data lines. In this state the d-pad is mapped to the data lines. Bits 3 and 2 are mapped to to right and left. If neither is pressed both bits will be "1" as the inputs are active-low; 1 OR 1 is 1. If either left or right is pressed then one of the bits will be "0" but the other will be "1"; 0 OR 1 is also 1. The only way to get a zero is if both directions are pressed simultaneously which is not possible, so ID bit 3 will always be 1.

The same applies to ID bit 2, as this is uses data lines 1 and 0 which are mapped to the down and up buttons, so this will also always be a 1.

After setting TH low, we know that data lines 3 and 2 are forced to 0 so ID bit 1 is a 0.

Finally, ID bit 0 is based on data lines 1 and 0 which are still mapped to down and up and so will still be a 1. This all gives us a device ID of %1101, which is indeed the peripheral ID of a standard Mega Drive controller.

This is fine, but what does it mean for the Menacer? Well, that device has an ID of %0000. For this to happen we need to make sure that all four data lines are low whenever the console is reading the device ID. The easy way to do this is to take apart a Master System controller and to press all four d-pad buttons down simultaneously – doing so and starting the console with the T2 cartridge inserted makes the game think that a Menacer is plugged in!

Somewhat unusually the Menacer's four buttons are mapped to the four data lines (instead of TL/TR) and are active high which means that if I start the game and let go of one of the Master System controller's buttons then it thinks I've pressed one of the Menacer's buttons (for example, releasing the "down" button makes DATA1 go high and the game thinks I'm pulling the trigger). Of course, I can't aim in this mode as there's no light gun input but it's good to see something is working!

I assumed that if TH is normally used for device identification I would start experimenting with using that to determine when the adaptor should output all zeroes. Considering the buttons need to be inverted to active-high logic too I thought it best to use an AND gate on each button so that if TH is high (normal state) the button input would pass through to the data line, but if TH is low (detection state) the data line would be forced low. I wired this up with an AND gate and four push buttons and the game still detected a Menacer and pressing a button in-game would now fire the weapon. Seeing that this worked, I removed one of the four push buttons that was previously used for the trigger button and used the TL data line from the Light Phaser instead via an inverter:

In the diagram above the TL on the left comes from the Light Phaser and the connections on the right go to the Mega Drive.

I assumed that the Menacer would also use the console's TH input for the light sensor from the gun (similar to the Light Phaser) so tried wiring up the Light Phaser's TH output to the Mega Drive's TH input. Moving the gun around the screen moved the aiming cursor around. Unfortunately, the aim was pretty far off:

The game placed the aiming cursor a consistent distance left of where the gun really was aiming. I assumed this was due to the game expecting a delay between when the gun saw the light from the screen and it sending a pulse to the console – unlike a wired gun that can send the signal back to the console very quickly the wireless Menacer converts the detected light pulse into an IR pulse that then needs to be handled by the receiving unit plugged into the console. By the time the console sees this pulse it will have moved further along the current scanline (right), so the game software works backwards (left) to an earlier point on the scanline. As I'm using a wired gun that transmits the signal much more quickly this left offset causes the aim to be incorrect.

The solution to this is to introduce our own delay into the signal, which I did with a crude RC circuit:

As I'd previously used a NAND chip to invert the signal from the trigger button I used three more of its gates to implement the delay. The first gate buffers the signal as the gun's TH is a common emitter output, so either connected to ground or pulled high via a resistor. This buffered signal then charges or discharges a capacitor to ground via a resistor – this provides most of the delay, and in my testing a 220Ω resistor and 100nF capacitor provided better aim. The next two gates buffer the signal again before driving a transistor for a common emitter output – as the console is also driving the TH line as an output I didn't want to directly drive it from the adaptor circuit and so the transistor seemed safer and is how the Light Phaser works anyway.

This is a crude circuit and has its limitations (very short pulses could be dropped entirely rather than delayed, for example) but it does at least seem to greatly improve the aim:

The game is now fairly playable, though there is one notable flaw with the circuit: pressing any button at the main menu screen causes the game to assume the gun has been disconnected, disabling the Menacer options:

Clearly using the TH signal alone to disable the buttons is insufficient, we must need to also output 0 when TH is high for full compatibility with the peripheral ID reading and the gun must use some other technique to enable or disable the button data.

Fortunately, a copy of the Menacer patent can be downloaded from the Sega Retro website where it can be studied to see if it provides any more clues for how the Menacer works. It goes into some detail about how the gun communicates with the console, including this figure showing the gun:

The centre portion of the image shows that infra-red signals from the gun are transmitted to the receiver in the form of 10µs pulses. The top portion of the image shows that these pulses can be generated by the gun's light sensor, so whenever the gun sees light it will send a 10µs IR pulse to the receiver. The bottom portion of the image shows the pulse generator used to encode the button presses; the button state is interpreted as a binary number and a corresponding number of IR pulses are sent: if SW1 is pressed then 1 pulse is sent, if SW2 is pressed then 2 pulses are sent, if SW3 is pressed then 4 pulses are sent and if SW4 is pressed then 8 pulses are sent. If multiple buttons are pressed then their values are added, so if SW1 (1) and SW3 (4) were pressed then five pulses would be sent up to a maximum of 15 pulses for all four buttons being pressed.

These button press pulses are only sent back to the console receiver after the gun receives an IR pulse from the receiver.

The receiver uses a counter chip to convert the IR pulses from the gun into button press or detected light pulses for the console. The duration of reset pulses are important here. The patent describes a standard counter reset pulse as being 2-3µs long and a main reset signal pulse as being about 10µs long. Any short reset pulse will reset the counter chip and latch. A long reset pulse will stil reset them, but also trigger a pulse of IR via the transmitter section at the bottom of the diagram. This IR pulse will cause the gun to send its button data back to the receiver, where the pulses will be counted by the counter chip and drive the DATA0 to DATA3 pins. After a certain delay to ensure that all button states have been sent the game software can read the button state and reset the counter, ready to read pulses from the light sensor in the gun. Bear in mind that the button state will have to be read before the active display starts, as the gun always sends an IR pulse when it sees light and this will cause the button presses to be miscounted.

Rather than pass every single detected pulse of light from the gun to the console it looks like the counter is used to detect eight pulses, after which it triggers a latch. This appears to be due to the assumption that when the gun is an expected distance away from the TV it will trigger on around 20 scanlines, and so by waiting for eight it will place the detected position roughly in the middle of those 20 lines.

All in all, this is a simple enough system but what does it mean for our convertor circuit? Will we need to add extra pulse length detectors and counters to make sure we send through the right sort of data?

I captured the state of the controller port lines during gameplay and found the above logic traces. Each frame TL goes high briefly and is then low for the active part of the frame. Pin TR has very brief pulses, and these appear to be the reset pulses. If we zoom in, we can see these more clearly:

Here TR goes high for over 10µs and so must be the main reset pulse (used to read the button state) and the next pulse is around 3µs and so must be the regular counter reset pulse. The gap between these pulses is only 85µs, however – if the button IR pulses are 10µs long then this would not give us enough time to read them – even if there was no gap between them 15 pulses of 10µs would take 150µs. Either there is a delay of at least 85µs before the gun starts sending the button data or the timing is different in the real gun when compared to the patent information. There is a final 3µs reset pulse as TL falls and this pulse comes 1.435ms after the previous short reset pulse so that would provide plenty of time to receive the button press data before resetting the counter ready to detect light pulses.

The next bit of the puzzle is what happens during the main menu when the Menacer is being detected. The traces are shown above. Both TL and TR are fixed high during this process. If we assume TR alone is used to reset the counters then holding this high would fix the data lines at %0000, identifying the controller as a Menacer. The TH line is also being pulsed here, possibly as the code is still checking to see if it could be some other type of controller.

If we force the output of the data lines to be 0 when TR is high (acting as a reset) then maybe this would work more reliably (and correctly) than when TH is low. I'll need to perform some further experiments, and also see whether the lack of the eight scanline delay before triggering the TH line to indicate detected light causes any other problems. I like the idea of a simple device that only uses logic chips to adapt the gun but if we need a more sophisticated circuit to time reset pulses and offset the vertical position maybe it would be better to switch to a microcontroller circuit. If that was the case, maybe the adaptor could also be programmed to work with games that use the Konami Justifier, another Mega Drive light gun that is incompatible with the Menacer.

If you'd like to see the circuit in action, I've uploaded a quick video on YouTube to accompany this post.

Repairing damaged plastic pegs

Friday, 4th October 2019

It's not uncommon for parts of old electronic devices to have damaged plastic pegs, like the one in this photo:

If you still have the snapped off plastic peg you may be able to glue it back on, but this can leave a weakened part that doesn't hold up very well. In other cases you might have lost the part entirely. This happened to me recently with the purchase of a six-button Mega Drive control pad. I ordered it from CeX's website and so couldn't see what condition it would be in until it arrived in the post. Unfortunately, it arrived in a filthy condition with a d-pad that only worked if you pressed the buttons very firmly and a non-functioning Mode button. I took it apart and was able to get the d-pad working again by cleaning the contacts. Whilst I left the rest of the plastic parts soaking in the sink to try to remove as much of the encrusted grime as possible I turned my attention to the faulty Mode button.

At some point the button must have been pushed in too firmly, damaging the tactile switch on the main board - the metal casing was bent and the plastic switch body had separated from it with the metal diaphragm that closes the contacts falling out. I've seen the same thing happen to some Sega Saturn control pads and fortunately had some spares in my parts bin so was able to swap that out easily. However, the pressure had snapped one of the plastic pegs of the Mode button off and it was nowhere to be found, so I needed to construct a replacement.

Fortunately, I have some scrap plastic parts from cutting out holes in plastic enclosures. In my case I needed to make a new peg that was 1.8mm in diameter, and had some 2mm sheet to use for this purpose. If I didn't have this then I could have gone online to buy a small 2mm thick sheet of ABS, but I prefer to recycle where possible!

The first thing to do was to get a piece of plastic that was roughly the right size, so I cut a length with a cross-section of 2×2mm. To cut the plastic I scored it with a knife and then snapped it by gripping the short part with a pair of pliers and bending the longer part away from the score line.

As the plastic peg needs to rotate in its slot inside the control pad it needs a round cross-section rather than a square one. To shape the peg into a rough cylinder I mounted it in the chuck of a rotary tool, as pictured above.

The rotary tool was then switched on and the plastic part held against a file. The photo above shows the start of this process with the peg beginning to take form. You need to work somewhat slowly with plastic as it gets hot when filing, cutting or drilling and if you let the heat build up it can melt and bend or gum up your tools. In my case I only used the file for a short period at a time before giving the piece time to cool back down. If I had been able to use my variable-speed rotary tool I could have set it to a lower speed to reduce the heat however the collet chuck on that tool wouldn't have been able to grip the work piece.

It doesn't take very long to get a nice round profile on the peg, though, even when working slowly (it's only a small piece, after all!) I carried on working it until I measured the 1.8mm diameter I was aiming for.

The above photo shows a size comparison between the new peg and the intact one on the Mode button. I've left the piece long (with the rough ending as a "handle") to make it easier to work with until it's time to fix it in place rather than cutting it to length straight away.

How to attach the new peg to the damaged button is the next issue to deal with. The rough surface of the snapped area of the button would make gluing difficult, though it could be filed flat to provide an easier surface to work with. My preferred technique, however, is to fix the new plastic peg with a metal pin made from a paper clip. This involves drilling narrow holes in the old button and the new peg to fit the metal pin through.

A pin vice is an invaluable tool for fine drilling work like this. I started with a very small drill bit to make the initial hole, being very careful to ensure I was drilling straight and in a well-centred location. This is something that needs to be taken slowly, especially on the original part. Once I had a pilot hole in the right place I switched to a larger drill bit that would drill a hole that the paper clip could fit into.

Starting the hole in the plastic peg might be easier by spinning the piece in your rotary tool and then bringing the stationary drill bit up to the end of it. As before be very careful about melting the plastic as once the hole is drilled the plastic is even thinner and will melt more easily – the peg is much shorter in the above photo than it was in previous photos as I accidentally melted it when I tried to drill all the way through in the rotary tool. I had to cut off the melted and distorted part to start again, only starting the hole in the rotary tool this time and then drilling the rest of the way slowly by hand. It's a good thing there was plenty of excess material!

The above photo shows the short length of paper clip that has been cut to connect the two plastic parts. Using a piece of wire like this should provide a lot of strength to the join – my experiences of gluing plastic to plastic have been very mixed, depending on the glue and plastic involved.

The parts in this case are all glued together with superglue and it seems to hold together quite well. The replacement peg was first cut to length before being glued. I coated one end of the paper clip rod in glue before pushing it into the hole on the button, then added glue to the other end and slid the new peg on. The end of the peg had a slightly protruding piece of the paper clip rod, so it was filed flush once the glue had set.

The uneven break still left a small gap in the join between the new peg and the Mode button body, so I filled it with a small amount of two-part epoxy resin. I used a toothpick to transfer a small amount of the mixed epoxy resin into the gap. This is always a bit messy so I protected the main button surface with masking tape. I also tidied up any "blobbiness" or glue that had otherwise run to undesired areas with a sharp knife before the epoxy had fully cured.

The button now sits properly in place inside the control pad and swings freely as it should. I could of course have just returned the control pad for a refund considering its condition but in spite of its problems it was still a well-priced item and I'm not sure they would have bothered to repair it. At least I know this way it'll be appreciated in its second life!

Modifying a Master System cartridge for use with flash ROMs

Thursday, 22nd August 2019

I have a ToToTEK GG-PRO flash cartridge to run homebrew software on my Game Gear however I have never been able to get it to work on my current PC and it seems that it's hard to find a Master System equivalent these days. A contemporary alternative is the Master EverDrive and it is by all accounts an excellent piece of equipment however it is a very expensive product.

I had, however, heard that certain Master System cartridges could be modified to accommodate a flash memory chip in place of their stock mask ROM. I do say certain cartridges as it's the ones with separate mapper chips that need to be used. One such cartridge is After Burner, and as I was able to find an inexpensive loose copy on eBay I used that as the basis of my modifications.

The memory mapper is used to map ROM banks or save RAM on the cartridge into one of three 16KB slots in the Z80's address space. Most Master System cartridges only contain a single chip that combines the ROM data for the game as well as the memory mapper logic. As such, these cartridges can't be modified for use with a generic flash memory chip as you can't access that internal memory mapper. Some cartridges, however, make use of a separate mapper chip and so you can remove the plain mask ROM chip and replace it with a flash memory chip. SMS Power! has this list of mappers and examples of cartridges in which they can be found.

In the photo above you can see where I removed the mask ROM from the cartridge PCB and have left the mapper chip on the board. I didn't want to damage the old ROM chip (in case I wanted to play After Burner again) so I carefully unsoldered it rather than cutting it off the board. To do so I heated up each solder joint on the back of the board and used my spring-loaded solder sucker to remove the molten solder. After this I checked each pin by gently trying to move it in its hole; if it moved I knew it had been unsoldered and if it was stuck fast I knew I needed to try removing more solder. Once all pins were free the old ROM lifted cleanly out of the PCB.

One of convenient features of these cartridges is that the pinout of Sega's mask ROMs is virtually identical to the pinout of commonly-available flash memories like the 29F010 or 49F040. Only two pins need to be changed, as per the information on Charles MacDonald's website:

Pin	Mask ROM	Flash memory
1	Not connected	A18
31	A18	/WE (Write Enable)

As I wanted to ensure that the cartridge was compatible with both the original mask ROM and the replacement flash memory chip I thought it best to install a switch to let me select the type of memory that is installed. To break the connection between the solder pad on the PCB and the leg on the memory chip I used an IC socket with legs 1 and 31 bent out and not soldered through their corresponding holes. Wires are soldered to the bent out legs and go via the switch to the corresponding solder pads on the bottom of the PCB.

The position of A18 definitely needed to be swapped between pin 31 on the mask ROM and pin 1 on the flash memory if I wanted to be able to address all 512KB of a 4 megabit ROM. I had heard reports that the write enable pin on the flash memory can be left disconnected however the datasheets for the flash memory chips I checked did seem to indicate that it should be held high during read operations so I thought it best to hold it high when in "flash" mode. This means that the function of both pins needed to be changed by the switch, so I used a DPDT to make this happen. The two different states are illustrated below, showing the connections to the six pins on the bottom of the switch:

The heavy black lines show the position of the switch contacts when in the upper and lower positions. When in "MPR" mode you can see that pin 31 of the IC socket (A18) is connected to pin 31 of the PCB and pin 1 (NC) of the IC socket is not connected to anything. When in "FLASH" mode pin 31 of the IC socket (now /WE) is connected to Vcc and pin 1 of the IC socket (now A18) is connected to pin 31 of the PCB.

The photos above show how the pins of the IC socket were bent outwards with very fine wires soldered to them. These fine wires run through holes on the PCB under the IC socket to the underside. I did stick very small pieces of electrical insulating tape under the points where the solder joints for the wires attached to the bent pins made contact with the PCB for a bit of added security. With those legs bent out and the wires threaded through the PCB the socket could be soldered down.

Unfortunately, one problem with using an IC socket is that the extra height means that the PCB no longer fits inside the cartridge shell. I needed to cut a rectangular hole in the cartridge enclosure for the chip to protrude through. I started by drilling two large round holes at the far ends of the chip - this allows me to use a chip puller (or small screwdriver) to pull (or lever) the chip out of the socket without needing to dismantle the cartridge each time. Due to the position of an internal support post very near to the memory chip a larger rectangular slot could not be cut – and I think this looks pretty neat anyway! A smaller rectangular hole was cut in the top of the cartridge shell for the switch to protrude through along with mounting holes for its two screws.

Here the switch has been mounted inside the case with the wires from the IC socket soldered to the appropriate pins on the switch and other wires connected to the appropriate pads on the back of the back of the PCB.

Inserting the original mask ROM for After Burner and setting the switch to MPR mode lets me play After Burner; writing a ROM image to a flash memory chip and inserting that with the switch set to FLASH mode let me run that program instead. Putting the switch on the wrong mode would take me to the console's built-in game of Hang On as the BIOS is no longer able to read the cartridge as a valid Master System game (at least when using a 512KB memory that requires A18 to be connected to the right pin). All in all I'm now happy that I have a way to run programs on my Master System from flash memory and do some homebrew experiments of my own on real hardware.

The above photo shows the excellent homebrew Flight of Pigarus by Kagesan running on my Master System courtesy of the modified cartridge. I've tested it so far with an AM29F010B (128KB/1 megabit) and an AT49F040 (512KB/4 megabit) and have been using the Willem programmer (along with Remapped IO.DLL to get it to work with my PC's PCI parallel port) to program the chips.

Updating remapped IO.DLL: The venerable Willem programmer still works on 64-bit Windows 10!

Sunday, 18th August 2019

A few years ago I posted about a way to get the Willem chip programmer to work with modern PCI parallel ports via a DLL that remapped the legacy port addresses to the ones of your modern card (in my case my card is installed at 0xCCD8 instead of 0x378). Since its release I've had several people contact me asking for advice and support, including a few questions about 64-bit support.

Until recently I had been using a 32-bit OS and as such hadn't run into compatibility issues myself. I had replaced the DLL in the zip archive for the project with an allegedly 64-bit-compatible version of the inpout32.dll library that the is used to access the I/O ports but I was unable to test this myself, however it still worked in a 32-bit OS so hoped that it would also work on a 64-bit OS as claimed.

I am now running a 64-bit OS and found myself needing to program a chip with my Willem programmer but was unable to do so, receiving the dreaded Hardware Error: Check Power & connection message. Clearly this DLL was not working as it should under 64-bit Windows!

Fortunately, Phil Gibbons of highrez.co.uk has come to the rescue with a 64-bit compatible version of InpOut32 that works perfectly on my 64-bit Windows 10 machine as a drop-in replacement for the old library. I have updated the zip archive containing the software with the working library. For more details and a copy of the Willem programming software please see the Remapped IO.DLL project page.

A temporary solution for 3D games on the Master System without the 3D glasses adaptor

Monday, 29th July 2019

I bought my Sega Master System-compatible 3D glasses almost exactly ten years ago for use in my LCD Shutter Glasses Adaptor project.

More recently I've acquired a CRT television and an actual Sega Master System so I could in theory make use of the glasses as I had originally intended - with Sega Master System games.

I've been keeping an eye on eBay for the 3D Glasses Adaptor for the Master System. This is a device that plugs into the console's card slot and allows it to drive the glasses with the software controlling which LCD shutter is open and which is closed by writing to the card. Unfortunately, these cards are not too easy to find in the UK and when they do appear they usually came bundled with a broken pair of glasses (it seems very unusual for both arms to still be attached to the glasses, and I've seen a fair few pairs that are cracked down the middle too). I already own some compatible 3D glasses so didn't want to waste money on buying a broken set of original Master System ones!

I did eventually find someone selling a loose adaptor for a reasonable price so bought it and a few games. Zaxxon 3-D was the first to arrive and I was eager to test it out. Without the card adaptor I needed to find an alternative solution, so my thoughts turned to the LCD Shutter Glasses Adaptor I'd built a few years ago.

This is designed to sit between a PC and a VGA CRT monitor and drives the shutter glasses, alternating which LCD shutter is open and which is closed every vertical sync. It can also blank out alternate scanlines, simulating an interlaced signal from a progressive one by blanking odd scanlines on one frame and even scanlines on the next, but this is not useful in our case. The Master System is already alternating complete left and right eye views on its own, so we just need to catch its equivalent of a vsync pulse and feed that into the VGA port on the back of the shutter glasses adaptor.

Above is the device I built, attached to the existing 3D glasses adaptor. It has a single composite input which should be connected to the composite output from the console, either via a splitter (if the console is connected to the TV using composite video) or via some sort of SCART breakout box (I'm using the composite video output from my SCART switch box). It also has a power socket which is used to power the circuit inside which is also passed through to the LCD shutter glasses adaptor. The box has a DE-15 connector and 5.5x2.1mm barrel plug on the other side for connections:

I'd cut the barrel plug off a faulty power supply years ago, I'm glad I kept it as it made the project a much neater solution than it might have other been!

The circuit inside is very simple indeed. As the original adaptor has its own 5V regulator inside and is designed to be powered from a 9V power supply I had to maintain the same convention for this device, so I use a 7805 regulator to convert the incoming voltage to 5V. This powers a textbook example of an LM1881 sync separator circuit - I'm using the reference circuit from the chip's datasheet, connecting the composite video input to the chip's composite video input via a 0.1µF capacitor (without termination as it's assumed the signal is being terminated by the TV) and I use the LM1881's composite sync output and vertical sync output for the VGA connector's horizontal and vertical sync connections respectively.

The circuit can be seen above, stuffed in the bottom of the box - along with copious amounts of hot glue to keep the barrel plug in place! How well does it work? Well, the below animation shows two views of the circuit in action, viewed through first one shutter and then the other of the 3D glasses:

This isn't a perfect solution - the Master System expects to be able to explicitly specify which shutter is open whereas in our case we're simply be alternating every frame. This could mean that the eyes are swapped, however there is an eye swap switch on the shutter glasses adaptor to compensate. If the view looks wrong then the switch can be used to correct it, and once that's done as long as the software alternates the views every frame then it should be fine.

I'm certainly happy for now, as it lets me play my 3D games whilst waiting for the console's intended 3D glasses adaptor to arrive in the post.