Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - SG 1000 II, SEGA MARK III and JAP SMS - Schematic

Reply to topic
Author Message
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
SG 1000 II, SEGA MARK III and JAP SMS - Schematic
Post Posted: Sun Jan 17, 2016 12:06 am
Last edited by Esrael on Sat Dec 31, 2016 2:52 pm; edited 5 times in total
Recently I bought a SEGA Mark III and didn't find any schematic for it.

I have opened my console and did a schematic from it.
The names for signals is based in the schematic of Tec Toy Power Base.

Notice: The schematic can not be 100% accuracy, since this was done following board traces.

Edit: 19/01/2016: NMI signal from VDP IC is only used for Pause Switch. Removed trace which goes to bus.

Edit: 04/03/2016: Added Japanese SMS Schematic, another schematic done following board traces.
Missing some pin names on SEGA I/O 315-5297.

Edit: 04/12/2016: Added SEGA MARK II / SG 1000 II Schematic, another schematic done following board traces.
Missing some pin names on SEGA 315-5066.
SEGA Mark III.png (255.97 KB)
SEGA MARK III - Schematic
SEGA Mark III.png
Master System - Jap FM.png (310.43 KB)
Japanese SMS - Schematic
Master System - Jap FM.png
esquema_sega_mark_ii[1].png (181.09 KB)
SEGA MARK II / SG 1000 II - Schematic
esquema_sega_mark_ii[1].png

  View user's profile Send private message Visit poster's website
  • Joined: 31 Oct 2007
  • Posts: 808
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Sun Jan 17, 2016 5:33 pm
This is great !
  View user's profile Send private message Visit poster's website
  • Joined: 09 Dec 2013
  • Posts: 101
  • Location: detroit
Reply with quote
Post Posted: Tue Feb 16, 2016 1:36 pm
very nice, thanks for sharing :)
  View user's profile Send private message
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
JAP SMS - Schematic
Post Posted: Fri Mar 04, 2016 3:45 am
Japanese SMS Schematic, added to main post.
Done in the same way as Sega Mark III, following board traces.
  View user's profile Send private message Visit poster's website
  • Joined: 07 Aug 2007
  • Posts: 187
  • Location: Yach, Germany
Reply with quote
Post Posted: Fri Mar 04, 2016 10:44 am
Why would Sega put !MREQ on B10 on one system, on B9 on the other? Are you sure that one got traced correctly?

Philipp
  View user's profile Send private message Visit poster's website
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
Post Posted: Fri Mar 04, 2016 11:38 am
PkK wrote
Why would Sega put !MREQ on B10 on one system, on B9 on the other? Are you sure that one got traced correctly?

Philipp


I had noticed these differences too and rechecked traces and this is true. Card Slot has some differences too in pin out between Mark III and Jap SMS eg: Pin B2 in Cartridge Slot on Mark III is !CSCN4 and Jap SMS is assigned to VCC,
Pin 13 on Card Slot in Mark III is assigned to !MREQ through a gate IC and assigned to !CE 2 like an export SMS.

Edit: Searching I have found others docs which can confirm these differences:
- SEGA MARK III -> http://cgfm2.emuviews.com/txt/m3tech.txt
- Japanese SMS -> http://www.smspower.org/forums/15109-3155297AndMoreJapaneseMSStuffPinout
  View user's profile Send private message Visit poster's website
  • Joined: 07 Aug 2007
  • Posts: 187
  • Location: Yach, Germany
Reply with quote
Post Posted: Fri Mar 04, 2016 10:28 pm
Cartridge pin B20 seems to be missing in your SMS schematic.

Philipp

P.S.: I used your schematics to make a cartridge pinout table at
http://www.smspower.org/Development/JapaneseSMSCartridge
  View user's profile Send private message Visit poster's website
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
Post Posted: Sat Mar 05, 2016 3:43 am
PkK wrote
Cartridge pin B20 seems to be missing in your SMS schematic.

Philipp

P.S.: I used your schematics to make a cartridge pinout table at
http://www.smspower.org/Development/JapaneseSMSCartridge



Thanks.
B20 has no connection. Updated schematic in Main Post.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Feb 2009
  • Posts: 104
  • Location: Toulouse, France
Reply with quote
Post Posted: Sat Mar 05, 2016 11:28 am
It's great work, I'm glad someone took the time to confirm (and even improve) the analysis I made using only board scans , pinout guessing game by following board traces is quite fun, right? ;-)

And yes,the reason of the differences between Mark III and MS cartridge connections is because MS has the ability to control the various chip selects from software while this is done by hardware on Mark III (but they should remain fully compatible from what I've looked in the other thread).
  View user's profile Send private message
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
Post Posted: Sat Mar 05, 2016 2:33 pm
Eke wrote
It's great work, I'm glad someone took the time to confirm (and even improve) the analysis I made using only board scans , pinout guessing game by following board traces is quite fun, right? ;-)

And yes,the reason of the differences between Mark III and MS cartridge connections is because MS has the ability to control the various chip selects from software while this is done by hardware on Mark III (but they should remain fully compatible from what I've looked in the other thread).


Thanks.
Yeah! that was fun.
Some traces required a multimeter to arrive his destination, because goes under some ICs.

I can't understand why I/O uses CSync Signal at pin 19 coming from VDP, I think this can be used for sync 3D, but external export / Mark III 3D adapter works without this signal.

Other question your analysis say pin 62 (N.C.) from I/O is !CONT 2. Is possible which this pin can be used for software reset like !CONT does in export SMS? (Grounding this pin can confirm this but at risk of damaging I/O).
  View user's profile Send private message Visit poster's website
  • Joined: 31 Oct 2007
  • Posts: 808
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Sat Mar 05, 2016 3:22 pm
Csync is for autofire I think, I see no other clock pins.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1138
Reply with quote
Post Posted: Sat Mar 05, 2016 10:56 pm
So M1 really isn't available on a JP SMS cartridge connector?
Somehow I was sure was. Maybe I'm not remembering correctly.
  View user's profile Send private message Visit poster's website
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
Post Posted: Sun Mar 06, 2016 12:22 am
Charles MacDonald wrote
So M1 really isn't available on a JP SMS cartridge connector?
Somehow I was sure was. Maybe I'm not remembering correctly.


Retested again with a multimeter and !MI is only connected between Z80 pin 27 and Expansion connector pin 37.
Rechecked B20 again and really no connection for this pin.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1138
Reply with quote
Post Posted: Sat May 07, 2016 3:27 am
Last edited by Charles MacDonald on Mon May 09, 2016 2:40 am; edited 3 times in total
I did some tests and can confirm that pin 62 of the 315-5297 is mapped to bit 4 of I/O port $C1/$DD. When the pin is pulled low (I used a 1K ohm resistor) bit 4 goes low, otherwise when not connected or pulled high bit 4 remains high.

Bit 5 of port $DD is always 1 and seems to never change.

I also checked port $F2. Bits 1,0 latch the last value written, bits 3,2 are always zero, and bits 7-5 are described below. Port $F2 isn't mirrored anywhere else.

EDIT: Well this got interesting. Bits 7-5 of port $F2 return the high bits of a counter that is clocked by the C-Sync input into the 315-5297. The counter is 12 bits wide and counts up on each C-Sync pulse. The bits return are as follows:

D7 : Counter bit 11
D6 : Counter bit 7
D5 : Counter bit 3
D4 : Always zero
D3 : Always zero
D2 : Always zero
D1 : Mute control bit 1
D0 : Mute control bit 0

The mute settings are:

0,0 : PSG only (power-on default)
0,1 : FM only
1,0 : Both PSG and FM disabled
1,1 : Both PSG and FM enabled

I'm not sure what the point of exposing the counter state like this is for, but it's there. As TmEE said the composite sync is used for the rapid fire feature and this counter is part of that.

I also verified the rapid fire button does not function as an input that is mapped to port $DD, such that you can't read the state of the button when pressed.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Apr 2007
  • Posts: 27
Reply with quote
Post Posted: Sat May 07, 2016 1:03 pm
Charles MacDonald wrote

Next I'll check what the rapid fire rate and LED blink rate is relative to the clock.


How the RAPID button works exactly? I've read that is possible to activate the function for a selected gamepad button, by "hold down the button then while it's held down press the rapid button". A figure of the JP SMS manual shows the Power LED blinking, but I couldn't get a good translation of the procedure. It blinks while the rapid fire function is active for a gamepad button? Or blinks only when the Rapid button is pressed?

Charles MacDonald wrote

I did some tests and can confirm that pin 62 of the 315-5297 is mapped to bit 5 of I/O port $C1/$DD. When the pin is pulled low (I used a 1K ohm resistor) bit 5 goes low, otherwise when not connected or pulled high bit 5 remains high.


Could be related with TH input? According to Enri's docs, bits 6 and 7 of I/O port $DD returns TH direction (input or output) of the controller ports on a JP SMS, instead the line state (low or high) like on a western SMS. A Light Phaser game could be released for JP SMS if it used bits 6/7 to detect that specific system and then use bits 4/5 (my hypothetical example) to read TH input.

Also, Enri's docs don't mention mirrors of I/O ports $3E/$3F. Could you confirm if they don't exist on the JP SMS?

--
Enik
  View user's profile Send private message
  • Joined: 28 Sep 1999
  • Posts: 1138
Reply with quote
Post Posted: Sat May 07, 2016 6:49 pm
Did some more tests:

When rapid fire mode is enabled the LED is turned off for 2048 clock pulses and on for 2048 clock pulses. By clock pulse I mean C-Sync.

The time that the LED is turned on or off is 131.461ms, and the total period is 262.924ms. The reason it isn't exactly 131.072ms or 262.144ms is due to the C-Sync signal having a period during the vertical sync pulse where there are no horizontal sync pulses.

The rapid fire counter is only reset by the reset signal and is not synchronized to vertical sync or anything like that. Turning rapid fire on or off doesn't reset the counter, consider that it's free running all the time.

How rapid fire mode works from a user perspective: Rapid fire mode is disabled when the reset signal is asserted (power-on). At this time the LED remains lit.

To enable it, press and hold the Rapid fire button, and then press button 1 or 2. The LED will start blinking, and now you can let go of the rapid fire button. At any point later on you can press and hold the rapid fire button and then press button 1 or 2 to disable rapid fire mode.

Rapid fire works for both buttons 1 and 2 but not any of the directions. The LED blinks as long as any controller's buttons have rapid fire applied. Here are some examples:

Reset -> Hold Rapid, Press 1 (LED starts blinking) -> Release Rapid
(Now button 1 has rapid fire)

Hold Rapid, Press 2 (LED continues to blink) -> Release Rapid
(Now buttons 1 and 2 have rapid fire)

Hold Rapid, Press button 1 then button 2 (LED stays lit) -> Release Rapid
(Now rapid fire is disabled)


All of this works for the 2nd controller port too, so at most you can toggle rapid fire on for all four buttons (1,2 on 1st port, 1,2 on 2nd port).

EDIT: More tests

When the TH pins are configured as inputs via port $3F, bits 7,6 of port $DD returns their corresponding pin state unmodified. There seem to be internal pull-up resistors so an unconnected pad reads as all inputs high.

When the TH pins are configured as outputs via port $3F, bits 7,6 of port $DD are always zero regardless of the TH pins being pulled high or low.

This seems to match what I saw in the Genesis, where if you select the JP region those bits are always zero no matter what.

The I/O control register is only mapped to $3F and the memory control register is only mapped to $3E. Writing to any address within $00-$3D does nothing.

I made a mistake earlier, pin 62 corresponds to bit 4 of port $DD, I said "bit 5" before. This input is not affected by any combination of the TH control bits in port $3F (direction or level). I corrected the earlier post.
  View user's profile Send private message Visit poster's website
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
Post Posted: Sun May 08, 2016 4:40 am
Esrael wrote

Other question your analysis say pin 62 (N.C.) from I/O is !CONT 2. Is possible which this pin can be used for software reset like !CONT does in export SMS? (Grounding this pin can confirm this but at risk of damaging I/O).


Charles MacDonald wrote

I did some tests and can confirm that pin 62 of the 315-5297 is mapped to bit 4 of I/O port $C1/$DD. When the pin is pulled low (I used a 1K ohm resistor) bit 4 goes low, otherwise when not connected or pulled high bit 4 remains high.


Bit 4 of port $DD on Export SMS is assigned to Soft Reset function. But I think SEGA leave this function unused since some Japanese games does not have a Software Reset routine or I am wrong?
  View user's profile Send private message Visit poster's website
  • Joined: 29 Apr 2007
  • Posts: 27
Reply with quote
Post Posted: Mon May 09, 2016 12:26 am
Thanks very much for your works, Charles and Esrael, very appreciated.

Charles MacDonald wrote

When rapid fire mode is enabled the LED is turned off for 2048 clock pulses and on for 2048 clock pulses. By clock pulse I mean C-Sync.

The time that the LED is turned on or off is 131.461ms, and the total period is 262.924ms. The reason it isn't exactly 131.072ms or 262.144ms is due to the C-Sync signal having a period during the vertical sync pulse where there are no horizontal sync pulses.

Forgive my ignorance on video signals, I'm trying to understand what clock drives the C-Sync signal. I've read that C-Sync is H-Sync ANDed with V-Sync. 2048 clock pulses divided by 131.072ms (the lesser time) gives me 15625Hz. NTSC horizontal frequency alone has a higher value (15734 kHz). What I'm missing?

When a controller's button has rapid fire, may I assume it goes low/high at the same time the LED is turned on/off?

Charles MacDonald wrote

When the TH pins are configured as inputs via port $3F, bits 7,6 of port $DD returns their corresponding pin state unmodified. There seem to be internal pull-up resistors so an unconnected pad reads as all inputs high.

So, games can read TH input the standard way, but there are reports about Light Phaser not working on the SMSJ. The gun also needs to signal the VDP to latch the HCount value, but as seen on the schematic the !HL (or NHL) line connects the 315-5297 with the VDP. What else could prevent the Light Phaser from working on the SMSJ?

Charles MacDonald wrote

I made a mistake earlier, pin 62 corresponds to bit 4 of port $DD, I said "bit 5" before. This input is not affected by any combination of the TH control bits in port $3F (direction or level). I corrected the earlier post.

You also wrote:
Charles MacDonald wrote

Bits 7-4 of port $F2 return the high bits of a counter that is clocked by the C-Sync input into the 315-5297. The counter is 12 bits wide and counts up on each C-Sync pulse. The bits return are as follows:

But listed bits 7-5 as returning the counter bits. Shall I assume as 7-5? Is this 12-bit counter internal only or is readable in some way?

I have another curiosity about the SMSJ: the embedded 3D adapter remains functional when a discrete 3D adapter is inserted into the card slot?
  View user's profile Send private message
  • Joined: 28 Sep 1999
  • Posts: 1138
Reply with quote
Post Posted: Mon May 09, 2016 3:30 am
Quote
Forgive my ignorance on video signals, I'm trying to understand what clock drives the C-Sync signal. I've read that C-Sync is H-Sync ANDed with V-Sync. 2048 clock pulses divided by 131.072ms (the lesser time) gives me 15625Hz. NTSC horizontal frequency alone has a higher value (15734 kHz). What I'm missing?


It's a little hard to check this accurately since there's no pixel clock I can use and trying to probe the 10.583 MHz clock prevents it from oscillating.

If I use the Z80 3.58 MHz clock as a reference, the period for the LED to flash is 941,184 cycles. At 280ns per Z80 clock, that's 262.933ms.

The frame rate is 5.36 MHz / 262 lines per frame / 342 pixels per line for 59.92 Hz, or 16.688ms.

The LED flash time (262.933ms) divided by the frame rate (16.688ms) is 15.755 frames. 4096 counts divided by 15.755 frames is 260 counts per frame.

Now the C-Sync signal is pulsed 258 times per 262-line frame, which is sort of close to 260, so I think they roughly agree. What do you think?

About testing the counter, I had disconnected the C-Sync input to the custom chip and instead connected the port $F2 bit 0 output to it, such that I could toggle that bit and manually clock the counter. That's how I determined it took 4096 pulses before the sequence repeated.

Quote
When a controller's button has rapid fire, may I assume it goes low/high at the same time the LED is turned on/off?


I haven't checked yet, though I suspect this will be easy to tell by comparing the rate at which TL/TR toggle relative to the accessible counter bits in port $F2.

Quote
So, games can read TH input the standard way, but there are reports about Light Phaser not working on the SMSJ. The gun also needs to signal the VDP to latch the HCount value, but as seen on the schematic the !HL (or NHL) line connects the 315-5297 with the VDP. What else could prevent the Light Phaser from working on the SMSJ?


Does that mean no light phaser games work on the SMSJ at all? Or just some don't? I hadn't heard about incompatibility issues before.

Quote
But listed bits 7-5 as returning the counter bits. Shall I assume as 7-5? Is this 12-bit counter internal only or is readable in some way?


Thanks for noticing that, it was a typo. I've edited the previous post to correct it. The counter is internal and some of the outputs go to port $F2, but not all of them.

Quote
I have another curiosity about the SMSJ: the embedded 3D adapter remains functional when a discrete 3D adapter is inserted into the card slot?


Hmm, that's a good question. I'd imagine both would work in parallel? But some testing is needed to be sure.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Apr 2007
  • Posts: 27
Reply with quote
Post Posted: Tue May 10, 2016 12:53 am
Charles MacDonald wrote

Now the C-Sync signal is pulsed 258 times per 262-line frame, which is sort of close to 260, so I think they roughly agree. What do you think?


Yes, they roughly agree.

Quote
Does that mean no light phaser games work on the SMSJ at all? Or just some don't? I hadn't heard about incompatibility issues before.


Some users stated it doesn't work in general. I did a quick search and found Missile Defense 3-D and Rescue Mission as examples. I also found a report of the problem on the Japanese Mega Drive as well.
There are some mentions about TH signal being inverted on the JP systems, what was always seemed like a mistake to me.

Quote
Hmm, that's a good question. I'd imagine both would work in parallel? But some testing is needed to be sure.


I've read that it would be a way for 2 persons watch a 3D game at same time, but I didn't found information about any test performed.
  View user's profile Send private message
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
Post Posted: Tue May 10, 2016 4:21 am
Last edited by Esrael on Tue May 10, 2016 3:37 pm; edited 2 times in total
enik wrote

Some users stated it doesn't work in general. I did a quick search and found Missile Defense 3-D and Rescue Mission as examples. I also found a report of the problem on the Japanese Mega Drive as well.
There are some mentions about TH signal being inverted on the JP systems, what was always seemed like a mistake to me.

I have a Tec Toy Mega Drive with Region Switch and My Light Phaser worked when running in Jap Mode with Hang On/Safari Hunt and Gangster Town. To confirm which my Mega Drive are running in Jap Mode I have used "Mônica na Terra dos Monstros" which show Sega Mark III Logo.

I don't have an adapter to test Light Phaser Games on my Japanese SMS, but based on my tests when trying to add Light Phaser (with success) support for Game Gear in both Ports A and B, using a Scope and pointing Light Phaser to TV screen I can see !HL / NHL pulse going to VDP without this pulse Light Phaser only Hit screen at fixed X Pos.

The idea is using a Light Phaser Game on JAP SMS and test if !HL signal is send to VDP.


Edit: The Game tested on Mega Drive was Safari Hunt from Hang-On/Safari Hunt cartridge not Hang-On.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1138
Reply with quote
Post Posted: Tue May 10, 2016 4:36 am
OK, I'll definitely test if the I/O chip is asserting !HL in response to TH from the light gun. And I'll verify if the outputs are inverted or not too

It's pretty interesting that there would be this difference between the two systems. I wonder what's going on.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Apr 2007
  • Posts: 27
Reply with quote
Post Posted: Tue May 10, 2016 10:05 am
Charles MacDonald wrote
OK, I'll definitely test if the I/O chip is asserting !HL in response to TH from the light gun. And I'll verify if the outputs are inverted or not too

Could you also measure the TL/TR toggle rate of the rapid function and run Flubba's SMS VDP tests on the SMSJ? There's a test about "HC change on TH 0->1" that latches the counter via software, but I'm interested to known about any test that fail on the console.
  View user's profile Send private message
  • Joined: 28 Sep 1999
  • Posts: 1138
Reply with quote
Post Posted: Sat May 21, 2016 10:30 pm
Got my 3D glasses + adapter today:

SMSJ built-in port: Bit 0 of $FFFB only controls the glasses. Other locations do not affect it.

SMS adapter port: Bit 0 of $FFF8,9,A,B control the glasses. The adapter has a jumper with two positions "M4" and "M3".

Default is "M4", which connects input C of the 74HC259 to card pin 3 (MREQ) which is appropriate for the US SMS and SMSJ. If you select "M3" then it is connected to the card pin 13 (MREQ 2) which is appropriate for the Mark III.

SMSJ + adapter: It works the same as above, so the US adapter is 100% compatible with the SMSJ and does not interfere with the built-in glasses. In this case writing to $FFFB affects both pairs of glasses simultaneously, and $FFF8,9,A affect only the glasses plugged into the 3D adapter.

When the reset signal is asserted both shutters are off (transparent). Afterward if you don't write to $FFFB to initialize anything the default state has the left shutter on and the right shutter off.

I did some experiments changing the shutter state on line $40 and back on line $80. As expected this makes one eye only see those lines and the rest of the screen is black, and the other eye can only see lines $00-$3F/$80-$BF and lines $40-$7F are blank.

The exact border where the glasses turn on and off is poorly defined so don't get sharp transitions. It takes around 10 scanlines for the display to transition from fully visible to fully obscured by the shutter. So you can't make changes to the 3D effect within a frame.

Likewise pulsing the shutter state for an interval less than a few scanlines shows that the shutter fills in from the interior towards the exterior in rather unusual blobby shapes. So it's not instantaneous, nor does it fill in cleanly from top to bottom or left to right.

Enik: Flubba's test works, all cases are OK including the TH test you mentioned. To make his ROM work on a SMSJ I just had to remove the lines relating to port $3E.

I wrote a test program which set the TH pins to inputs, polled the TH bit to check for the lightgun beam detection, and wrote the H counter to the display as well as making a sprite track the X position. It works just fine on a US SMS and the SMSJ. So if there's some kind of incompatibility I'm not sure what it is yet.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Apr 2007
  • Posts: 27
Reply with quote
Post Posted: Sun May 22, 2016 2:07 am
I'm impressed with your experiments, wasn't expecting full analysis of the 3d glasses + adapter.

Charles MacDonald wrote
When the reset signal is asserted both shutters are off (transparent). Afterward if you don't write to $FFFB to initialize anything the default state has the left shutter on and the right shutter off.


Both shutters are off on reset, despite being set as left=on/right=off by default (set to 0 according to SMS Power Wiki), so the first effective change occurs when the state is changed to 1 (left=off/right=on)?

Quote
The exact border where the glasses turn on and off is poorly defined so don't get sharp transitions. It takes around 10 scanlines for the display to transition from fully visible to fully obscured by the shutter. So you can't make changes to the 3D effect within a frame.


Most of the times games change the shutter state after VINT occurs, at end of the frame. However, as I commented in MAME sources, "there are occurrences when Sega Scope's state changes after VBLANK, or at active screen. Most cases are solid-color frames of scene transitions, but one exception is the first frame of Zaxxon 3-D's title screen".

Quote
Enik: Flubba's test works, all cases are OK including the TH test you mentioned. To make his ROM work on a SMSJ I just had to remove the lines relating to port $3E.


Thanks! I guess you are using the expansion slot, that is disabled by those lines.

Quote
I wrote a test program which set the TH pins to inputs, polled the TH bit to check for the lightgun beam detection, and wrote the H counter to the display as well as making a sprite track the X position. It works just fine on a US SMS and the SMSJ. So if there's some kind of incompatibility I'm not sure what it is yet.


Well, I think your tests covered the required functionality. Any SMSJ / MDJ user here to confirm the reported Light Phaser compatibility problems?
  View user's profile Send private message
  • Joined: 30 Jan 2007
  • Posts: 262
  • Location: San Jose, CA
Reply with quote
Post Posted: Sun May 22, 2016 4:05 am
enik wrote
Any SMSJ / MDJ user here to confirm the reported Light Phaser compatibility problems?

I never got the Light Phaser to work on my Japanese SMS. Haven't tried on my Japanese Mega Drive and unfortunately I don't have a Light Phaser any more so I can't test that.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Apr 2014
  • Posts: 107
  • Location: NYC
Reply with quote
Post Posted: Sun May 22, 2016 5:55 pm
My main SMS is a Japanese MK-2000 and all the light gun games I've tried work perfect. I was used an Everdrive though...I don't have any original light gun MKIII games. Was there a specific problem people were having?
  View user's profile Send private message Visit poster's website
  • Joined: 30 Jan 2007
  • Posts: 262
  • Location: San Jose, CA
Reply with quote
Post Posted: Sun May 22, 2016 11:19 pm
RetroRGB wrote
I don't have any original light gun MKIII games.

That's because they don't exist.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Apr 2007
  • Posts: 27
Reply with quote
Post Posted: Sun May 22, 2016 11:45 pm
Last edited by enik on Sun May 22, 2016 11:47 pm; edited 1 time in total
ApolloBoy wrote

I never got the Light Phaser to work on my Japanese SMS. Haven't tried on my Japanese Mega Drive and unfortunately I don't have a Light Phaser any more so I can't test that.

Did you test that Light Phaser with other SMS/MD version to confirm it was working?
  View user's profile Send private message
  • Joined: 23 Apr 2014
  • Posts: 107
  • Location: NYC
Reply with quote
Post Posted: Sun May 22, 2016 11:46 pm
ApolloBoy wrote
RetroRGB wrote
I don't have any original light gun MKIII games.

That's because they don't exist.


Okay...but what about your light gun issue?
  View user's profile Send private message Visit poster's website
  • Joined: 30 Jan 2007
  • Posts: 262
  • Location: San Jose, CA
Reply with quote
Post Posted: Mon May 23, 2016 2:23 am
RetroRGB wrote
ApolloBoy wrote
RetroRGB wrote
I don't have any original light gun MKIII games.

That's because they don't exist.


Okay...but what about your light gun issue?

It didn't work period, at least from what I remember. This was with both real SMS carts and the Everdrive.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Apr 2014
  • Posts: 107
  • Location: NYC
Reply with quote
Post Posted: Mon May 23, 2016 12:36 pm
I had issues with certain roms, but for the most part, both my SMS light guns always worked with my MK-2000 (as well as all my US consoles).

The game (rom) that's given me the most trouble was Assault City. The original cart always worked perfect, but some roms wouldn't register hits on the screen at all. There's actually two versions of that game, but it's VERY obvious to tell which supported the light gun, so I wasn't just using the wrong version. I eventually found a working rom though, in SmokeMonster's romset.

It sounds like you probably just had a bad gun. It happens.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jul 2015
  • Posts: 124
  • Location: Berlin
Reply with quote
Post Posted: Mon May 23, 2016 1:02 pm
Maybe you two were using different SMS->MKIII adapters that route some signals differently?
  View user's profile Send private message
  • Joined: 06 Feb 2009
  • Posts: 104
  • Location: Toulouse, France
Reply with quote
Post Posted: Mon May 30, 2016 4:43 pm
Charles MacDonald wrote

I did some tests and can confirm that pin 62 of the 315-5297 is mapped to bit 4 of I/O port $C1/$DD. When the pin is pulled low (I used a 1K ohm resistor) bit 4 goes low, otherwise when not connected or pulled high bit 4 remains high.

Bit 5 of port $DD is always 1 and seems to never change.

I also checked port $F2. Bits 1,0 latch the last value written, bits 3,2 are always zero, and bits 7-5 are described below. Port $F2 isn't mirrored anywhere else.


Charles MacDonald wrote
The I/O control register is only mapped to $3F and the memory control register is only mapped to $3E. Writing to any address within $00-$3D does nothing.


Thanks for doing all these tests, this is quite interesting.

For completeness, did you verify if ports $DC/$DD are mirrored elsewhere and if port $3E can disable those ports like on export Master System model?
  View user's profile Send private message
  • Joined: 28 Sep 1999
  • Posts: 1138
Reply with quote
Post Posted: Tue May 31, 2016 2:59 am
Last edited by Charles MacDonald on Sun Jun 12, 2016 7:13 am; edited 2 times in total
Quote
For completeness, did you verify if ports $DC/$DD are mirrored elsewhere and if port $3E can disable those ports like on export Master System model?


Checked again, the only mirrors for the joypad ports are $C0/$C1 and $DC/DD.

You can also disable those ports by clearing bit 2 of port $3E. This does not affect port $F2 so you can still read the FM status and the rapid fire counter.

Ports $3E and $3F don't seem to be mirrored anywhere else as far as I can tell.

For the rapid fire I saved the button state once per frame in a list, and printed the list to the screen after 256 consecutive frames. In general this showed that the button state toggled every frame (30 Hz). I also kept a count of how many frames the button was low for and how many it was high for, and got 128 low and 128 high after 256 frames.

Now sometimes the button state was low or twice for two consecutive frames. However within 256 frames it would always happen enough times to even the result out, so if you got a button state of 1,1 somewhere, you'd get 0,0 later. I think this is due to the slightly irregular timing of composite sync clocking the rapid fire counter.

Looking at the data printed this happens every 64 frames, I'm not sure if we really need this kind of detail however. :D
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1138
Reply with quote
Post Posted: Sun Jun 12, 2016 5:46 am
Quote
Both shutters are off on reset, despite being set as left=on/right=off by default (set to 0 according to SMS Power Wiki), so the first effective change occurs when the state is changed to 1 (left=off/right=on)?


Good question, I tested it again and can confirm:

After reset : Left shutter opaque, right shutter transparent (same as $FFFB=0)
Write $FFFB=0 : Left shutter opaque, right shutter transparent.
Write $FFFB=1 Left shutter transparent, right shutter opaque.

So the first effective change is when you write $FFFB=1 as you said.

I realized I could disconnect the !HL input on the VDP and use it to probe other signals to determine the H counter value when they are active. I used an inverter to capture the timing for the opposite edge too. Reading port $7F:

!CBT - Goes low at $F7, high at $FE (7 counts, 14 pixels, 28 cycles of the 10.7368 MHz clock)
!PCP - Goes low at $F9, high at $00 (7 counts, 14 pixels, 28 cycles)
!CSYNC - Goes low at $E9, high at $F6 (14 counts, 28 pixels, 56 cycles (horizontal sync pulse only))
!NMI - Goes low at $F6 at one frame, and high at $F6 of the next

The pulse widths match my earlier results (in m3tech.txt) and disagree with my much older H counter tests (in msvdp.txt), so likely the old ones were a misinterpretation of the test results at the time. I'll look into it further.

Also it seems the !HL input latches the H counter at the negative edge, so it functions as a negative-edge triggered register and not a transparent latch like I had thought in my Mark III tests. I'll check again but as the VDP is the same between them I think this description is accurate.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Apr 2007
  • Posts: 27
Reply with quote
Post Posted: Tue Jun 28, 2016 12:33 am
Charles MacDonald wrote
Now sometimes the button state was low or twice for two consecutive frames. However within 256 frames it would always happen enough times to even the result out, so if you got a button state of 1,1 somewhere, you'd get 0,0 later. I think this is due to the slightly irregular timing of composite sync clocking the rapid fire counter.

Looking at the data printed this happens every 64 frames, I'm not sure if we really need this kind of detail however. :D


Charles MacDonald wrote
The LED flash time (262.933ms) divided by the frame rate (16.688ms) is 15.755 frames. 4096 counts divided by 15.755 frames is 260 counts per frame.


The button state probably changes each 256 pulses. Considering 260 pulses per frame, there's a difference of 4 pulses. After each 64 frames, the accumulated difference will cause two state changes in a same frame, seems to be the duplicated values got on your tests.

Charles MacDonald wrote
Now the C-Sync signal is pulsed 258 times per 262-line frame, which is sort of close to 260, so I think they roughly agree. What do you think?


Considering 258 pulses per frame, the repetitive values would occur each 128 frames. Is there a chance for the count be in fact 260 instead 258?
  View user's profile Send private message
  • Joined: 07 Aug 2007
  • Posts: 187
  • Location: Yach, Germany
Reply with quote
GND case?
Post Posted: Fri Dec 02, 2016 8:33 am
What's inside the GND case near the SCART output?

Philipp
  View user's profile Send private message Visit poster's website
  • Joined: 21 Oct 2014
  • Posts: 38
  • Location: Guarulhos-SP-Brasil
Reply with quote
Post Posted: Sun Dec 04, 2016 6:55 pm
SEGA Mark II / SG 1000 II Schematic, added to main post.
Done in the same way as Sega Mark III, following board traces.

Revised schematics -> http://esraelneto.com.br/esquemas.php
  View user's profile Send private message Visit poster's website
  • Joined: 30 Jan 2007
  • Posts: 262
  • Location: San Jose, CA
Reply with quote
Post Posted: Thu Sep 14, 2017 12:24 am
ApolloBoy wrote
RetroRGB wrote
ApolloBoy wrote
RetroRGB wrote
I don't have any original light gun MKIII games.

That's because they don't exist.


Okay...but what about your light gun issue?

It didn't work period, at least from what I remember. This was with both real SMS carts and the Everdrive.

I'm gonna have to eat crow now, because I got a Light Phaser again today and sure enough, it works just fine with my Japanese SMS.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Apr 2014
  • Posts: 107
  • Location: NYC
Reply with quote
Post Posted: Fri Sep 15, 2017 4:15 pm
Those light guns are really temperamental. I think to get consistent performance, we probably need to "refurbish" ours; Clean the sensor, check all solder connections, etc. I still have the one that sometimes works perfectly and other times barely works at all (on the same monitor, etc).
  View user's profile Send private message Visit poster's website
  • Joined: 30 Jan 2007
  • Posts: 262
  • Location: San Jose, CA
Reply with quote
Post Posted: Sun Sep 17, 2017 11:35 pm
It might be the photodiode, I've done everything from cleaning it to replacing the two capacitors inside and nothing seems to help adjust the sensitivity. I really have to crank up the contrast on my monitor just to even get it to register shots, and even then it doesn't work well.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!