Service manuals of various Sega machines !

For hardware talk only (please avoid ROM dumper stuff)
Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Wed Feb 13, 2013 1:35 am

Hah, I never knew the tif format supported multiple images in the one container, no wonder I was getting confused. Thanks guys.

omp
Interested
Posts: 14
Joined: Wed Jan 16, 2013 12:07 am

Post by omp » Wed Feb 13, 2013 11:04 am

Mega CD 2 Service Manual, Mega CD 2 Supplement and (what I call as it has no title) Mega CD2 Additional Information added.

These are quite nice manual's, lots of good useful information.

This finishes up all the manual's I have.

notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Wed Feb 13, 2013 12:39 pm

Good job, thanks omp!

foobat
Very interested
Posts: 92
Joined: Fri Sep 14, 2012 1:06 pm

Post by foobat » Thu Feb 14, 2013 11:27 am

Cool! Thanks omp, you're the best.

Does that just leave Kaneda's?

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Post by KanedaFr » Thu Feb 14, 2013 12:55 pm


TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Thu Feb 14, 2013 3:56 pm

This is great stuff !

The maintenance manual even lists part of YM2612 datasheet !
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

foobat
Very interested
Posts: 92
Joined: Fri Sep 14, 2012 1:06 pm

Post by foobat » Fri Feb 15, 2013 6:10 pm

sweet, thanks man. totally worth the auction price

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Thu Feb 21, 2013 12:16 pm

TmEE co.(TM) wrote:This is great stuff !

The maintenance manual even lists part of YM2612 datasheet !
My Japanese isn't up to much :) Anyone have any Ideas about its Translation for the YM2612?

Cheers.

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Thu Feb 28, 2013 7:31 pm

Nemesis you rock dude.

Thanks for this!

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Thu Feb 28, 2013 11:28 pm

Nice to have the official VDP pin assignments at long last. Interesting that the digital video bus has a secondary function as generating DRAM addresses for work RAM. I guess that could have been a cost-saving option. Also explains why you get a screen filled with garbage on System C2 when you turn off the digital video output. :D

Really great stuff, thanks KanedaFr!

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Sat Mar 02, 2013 6:24 pm

Oerg866 wrote:Nemesis you rock dude.

Thanks for this!
Don't thank me, I had nothing to do with it. I was flat broke at the time and couldn't even chip in any cash for the purchase. A big thanks though from me to everyone who was involved in this.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Mar 02, 2013 7:00 pm

I had some spare cash, so I tossed it in for the 16-bit and 32X manuals, but thanks should go to omp who handled all the purchases and scanning.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Wed Mar 06, 2013 4:14 am

Just trying to fill in some odds and ends here going by the VDP pin description now that we have it. I would appreciate some commentary if something sounds wrong.

SEL0 says if the 68K or Z80 controls the VDP; in the Genesis this is tied to M3 on the cartridge connector.

SEL1 says if the 68K clock pin is an input or an output. It is an output on the Genesis and an input on System 18 and System C2. Both of these systems have faster 68Ks (10 and ~8 MHz respectively).

I guess for a proper overclock on the Genesis you'd want to change this pin so the CPU can run faster, the VDP can run at the normal speed, and the synchronous logic in the VDP for the CPU interface is running at the faster speed. Has somebody already tried doing that in the past?

CSYNC can be an input or an output, it's an output on the Genesis. I have the feeling VDP register 0 bit 0 controls the direction since that's how it works on the TMS9918 and SMS.

HSYNC can be an input or an output, it's an output on the Genesis. When I tested this pin it was always high when set as an input, so there may be an internal pull-up resistor.

VSYNC can output the vertical sync signal or the pixel clock (half of EDCLK). It's an output on the Genesis.

EDCK can input twice the pixel clock or output it. It's an input on the Genesis and driven by the bus arbiter chip which alternates between two frequencies in H40 mode. (Why? More sprite drawing time?) I haven't checked how it's used on System 18/C2 yet.

SPA/B can output the sprite/background indicator bit or input it, presumably for managing layer priority in a multiple VDP setup. It's an output on System C2.

So then we can fill in register $0C a bit:

D6 : VSYNC pin signal type (1= pixel clock, 0= vertical sync)
D5 : HSYNC pin direction (1= input, 0= output)
D4 : SPA/B pin direction (1= output, 1=input)

My reasoning for D4 is as follows: On System C2 if this bit is '1', the sprites are displayed normally. If it is '0', the sprites use the background palette. This would indicate SPA/B is fixed low instead of operating normally.

Since the pin assignments say it can be an input or an output, it seems reasonable that D4=0 makes it an input and for whatever reason on System C2 (internal or external pull-down) this pin is low when configured as an input.

So which bits define if EDCK is an input or output?

I know for bits 7,0 we have these settings

00 = H32 mode
01 = H40 mode but display is a little funky
10 = No sync
11 = H40 mode

On System C2 setting bit 7 locks up the machine, and bit 0 just gives bad sync. Normally it has to be left set for 320-pixel display. Hard to tell if the VDP is at fault as a programmable logic chip does a lot of video timing and blanking functions in parallel with the VDP, so it may be the cause of those results rather than the VDP.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Wed Mar 06, 2013 11:03 am

Charles MacDonald wrote:SEL1 says if the 68K clock pin is an input or an output. It is an output on the Genesis and an input on System 18 and System C2. Both of these systems have faster 68Ks (10 and ~8 MHz respectively).
It has been done and it works really well, only downside you need DivBy7 for the YM. MD2 still won't go past 10MHz with it, but luckily MD2 does not need a DivBy7 for the YM ^^
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Thu Mar 07, 2013 1:20 am

EDCK can input twice the pixel clock or output it. It's an input on the Genesis and driven by the bus arbiter chip which alternates between two frequencies in H40 mode. (Why? More sprite drawing time?) I haven't checked how it's used on System 18/C2 yet.
EDCLK alternates between frequencies in order to keep the sync rate within specifications for a PAL/NTSC video signal. In a H32 display, we have 684 dot clock ticks per line, with an internal MCLK/5 divider, which gives us 3420 MCLK cycles per line. When running in H40 mode without EDCLK enabled, you get 840 dot clock ticks per line, with an internal MCLK/4 clock divider. This gives us 3360 MCLK cycles per line, which is too fast for PAL/NTSC displays. The varying clock rate provided by the EDCLK signal generator inserts slower clock cycles during the horizontal blanking regions, where stretched pixels don't matter, because it's all black anyway. There are 60 extra pixel clock cycles added, which increases the MCLK count per line from 3360 to 3420, exactly the same as in H32 mode, and exactly what's needed to generate a video signal at the correct rate in PAL/NTSC mode. If the output display could handle the faster sync rate, this wouldn't be required.

Post Reply