Page 5 of 6

Posted: Wed Feb 13, 2013 1:35 am
by Nemesis
Hah, I never knew the tif format supported multiple images in the one container, no wonder I was getting confused. Thanks guys.

Posted: Wed Feb 13, 2013 11:04 am
by omp
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.

Posted: Wed Feb 13, 2013 12:39 pm
by notaz
Good job, thanks omp!

Posted: Thu Feb 14, 2013 11:27 am
by foobat
Cool! Thanks omp, you're the best.

Does that just leave Kaneda's?

Posted: Thu Feb 14, 2013 12:55 pm
by KanedaFr

Posted: Thu Feb 14, 2013 3:56 pm
by TmEE co.(TM)
This is great stuff !

The maintenance manual even lists part of YM2612 datasheet !

Posted: Fri Feb 15, 2013 6:10 pm
by foobat
sweet, thanks man. totally worth the auction price

Posted: Thu Feb 21, 2013 12:16 pm
by MintyTheCat
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.

Posted: Thu Feb 28, 2013 7:31 pm
by Oerg866
Nemesis you rock dude.

Thanks for this!

Posted: Thu Feb 28, 2013 11:28 pm
by Charles MacDonald
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!

Posted: Sat Mar 02, 2013 6:24 pm
by Nemesis
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.

Posted: Sat Mar 02, 2013 7:00 pm
by Chilly Willy
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.

Posted: Wed Mar 06, 2013 4:14 am
by Charles MacDonald
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.

Posted: Wed Mar 06, 2013 11:03 am
by TmEE co.(TM)
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 ^^

Posted: Thu Mar 07, 2013 1:20 am
by Nemesis
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.