More 315-5313 unknown stuff (speculation)

Talk about anything else you want

Moderator: BigEvilCorporation

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

More 315-5313 unknown stuff (speculation)

Post by Jorge Nuno » Mon Sep 10, 2007 11:25 pm

This time it's about SPA/8, or more correctly SPA/B (YS can be a complement for this one), about 8 unused pins in the MD, and some bits in the VDP regs...

Intro:
As some of you know the 315-5313 was used in a bunch of SEGA arcade boards, besides the MD, all (or almost) of them more powerfull than the console.
The truth is these boards used the VDP and some auxiliary grafics chips and pals aiding them...


Main:
The System C2 was a surprise for me because it uses the VDP, but RGB isn't connected to anything! (WTF?) instead it uses 8 pins for pixel data (pin120-pin127(?) ), these ones get into a colourize chip (LOL) wasting the VDP crappy CRAM.


What's the point?
The point is that you can build a CRAM yourself with 12-bit (or more), and with this you can choose from a total of 4K colours (Like the GG)

Cool what else?
Now, you all know the MD pallete is:
----BBB-GGG-RRR-
but with 12bit it becomes:
----BBBBGGGGRRRR, the thing now is that the GameGear probably uses this pallete format (it was the easiest way, while maintaining backward compatibility with SMS), so this will probably means that GG games will work on MD with full colour!


Yeah, and'bout those bits and SPA/B?
SPA/B, probably means Sprite Plane A/B
I think it's to differentiate Sprite pixels from Plane pixels, but you need to activate it by using the bit 4 of register 0C (I think)


Why do I need it?
Well you now have 64 colours out of 4096, but with SPA/B you can use a different pallete for sprites, this gives 128 (without sh/hi and changing colours on the fly) colours on screen (-8 for 0 indexes)

Sumarizing you can have plane A/B using a CRAM and sprites using another one


So those pins, the pixel data, what do i do with them?
Well I don't know how to use them yet, but they just tell the index of the colour they use (just like the tiles).

Ok then I have those pixels, how do I "colourize" them?
You need to implement 2*64 banks of 12bit-CRAM, Shadow and highlight mode in a FPGA/ASIC/Whatever then output Digital RGB (if youre using 12bit CRAM then 6bit/colour is more than enough) DAC the colour signals and feed the RGB encoder of your MD.


Credit for this goes to Charles MacDonald for it's docs, you will find them at http://cgfm2.emuviews.com


Don't forget this is post all speculation, To prove the truthness (!) of this I need to test that register and SPA/B, look out for the GG pallete format, test those 8 "unused pins" and discover which pins they are...

IF anyone is doing it, I will probably do if it's true I just need to know how to capture CRAM DMA's so I can copy them to the new cram...

Don't forget that SPA/B is tied high with a resistor, so it is better to take it out before setting the bit to 1

8)

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) » Tue Sep 11, 2007 5:27 am

WOW !!!

One I idea that I've had is that maybe there's a bit in VDP that enables the first bit of color palettes... but now after reading this, there's some need for extra HW... if all of it is true
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

Fonzie
Genny lover
Posts: 323
Joined: Tue Aug 29, 2006 11:17 am
Contact:

Post by Fonzie » Tue Sep 11, 2007 10:01 am

Yeah, very great find :)

I was "sure" there were an input or output on the VDP so it could be hooked on another one for more planes :D Sega always think about many things :D

Even if it's not totally the case, knowing the ABSprites pixels let you already mix signal with another megadrive in a very simple way :D

:D Also, the megadrive ext port have two or three unknown wires going to the VDP :) Maybe you'll figure out them :)

PS : damn, that's not blabla, thats a topic you made for expert section ^^
instead it uses 8 pins for pixel data (pin120-pin127(?) ), these ones get into a colourize chip (LOL) wasting the VDP crappy CRAM.
Are you sure its not 4bit (well, a tile is 4bit so far)? What are the other 4bits used for? Input data?!!

Mask of Destiny
Very interested
Posts: 616
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Tue Sep 11, 2007 11:14 am

Fonzie wrote:
instead it uses 8 pins for pixel data (pin120-pin127(?) ), these ones get into a colourize chip (LOL) wasting the VDP crappy CRAM.
Are you sure its not 4bit (well, a tile is 4bit so far)? What are the other 4bits used for? Input data?!!
Well you need to know what pallete the current pixel uses for one.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Tue Sep 11, 2007 3:25 pm

Mask: that's right.

It says in a Charles doc (i think it's in c2tech.txt) that those 8pins are something like:

pin0~3: colour index
pin4~5: pallete number
pin6: Sprite or background pixel indicator (Seems to be the SPA/B pin this one)
pin7: Shadow/Highlight (there are 3 effects: Normal, Shadow, Highlight, but space for 2)


It was there that I read that the RGB output was not used...


Fonzie: to add more planes, you can use YS one, use it to activate the output of a VDP2, when VDP draws background colour.

Just make plane A/B "full of holes" so that the background colour is drawn, but instead youre putting the VDP2 into charge in those transparent pixels...



EDIT:

More stuff: (the systemC2 board)

http://www.system16.com/boards/puyopuyo2.jpg

VDP lower right corner with the crystal osc and the 2 VRAM chips, with some luck, a Hi-res pic appears and we could findout about those pins.



EDIT2:

Even more obscured stuff: :shock:

http://web.archive.org/web/200212200154 ... newreg.htm

After seeing this I think it would be great if we create a program that sets bits on the fly, using the controller pad we could write something into somewhere in the VDP to see the results, even if the MD locks at many spots, it's just a reset to get going...
:wink:

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Mon Oct 01, 2007 9:20 pm

Little update:

SEL1 (pin48) seems to be a VDP halt... (though the picture is drawn correctly)

It is grounded by default, lifted the pin off (risking the VDP integrity :shock: ), and left in the air, resulted in a very slow frame rate (propably H-L-H.. interference). When it's pulled high the picture freezes...

If you turn the MD on with sel1 high you won't see anything on the screen.

Or it could be an interrupt enable/interrupt mask bit...

Tested a minute ago with S&K.

Fonzie
Genny lover
Posts: 323
Joined: Tue Aug 29, 2006 11:17 am
Contact:

Post by Fonzie » Mon Oct 01, 2007 10:21 pm

Nice find.
Yeah, might be an interrupt mask or something that locks the the VDP access... Because of the raster drawing, a halt would turn off the screen :)

You tried to play with this pin during a game with complex sprites & raster effects like sonic, what's happen on the rasters?
And during a game that don't care of VINT (aren't some 3d games running in free style, skipping any timing checks?).

Btw, the hidden register is really exciting :)
We can imagine lot of things & hidden/canned concepts... Like the ability of the vdp to read tiles from external 64KB banked source (ROM) instead of VRAM, hence the corrupted tiles in some modes :P
The XOR mode (which merge all the planes) is also nice :)
I wonder if there are others undiscovered things, haha :)

Really nice! :D

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Tue Oct 02, 2007 4:40 am

Humm I could make use of sonic2, to test the water but my cart is currently under «a reworking process»; if you have Sonic compilation and S&K, you will probably guess what I'm doing :lol: ...

Eisshhhh lol ! completely forgot about sandopolis zone/special stages, I only tested the Mushroom hill.... (Blame me :( )

Tonight I will test more levels

LocalH
Very interested
Posts: 152
Joined: Tue Dec 19, 2006 5:04 pm

Post by LocalH » Tue Oct 02, 2007 7:48 am

Fonzie wrote::D Also, the megadrive ext port have two or three unknown wires going to the VDP :) Maybe you'll figure out them :)
You mean the expansion port? As far as I know the EXT port is a standard controller port with inverted gender. Just trying to clarify, that's all.

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) » Tue Oct 02, 2007 8:29 am

Fonz meant expansion port...

Really interesting things... too bad that I don't have MD1... I'd like to mess with this too !!! MD2 "chipset" has lots of pins present on chips it contains... but no-one knows which pins they are (if there's any what here's talked about).
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

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Wed Oct 03, 2007 9:42 pm

Tested again in S&K... (so much work, so little time...), it is like pressing the Esc key when running a rom in Gens. Picture freezes! No pixel movement, no "bottom dots"...
I didn't test water levels but i'm pretty sure that the water "disapears"...

Holding the pin (the wire that connects to it, that is) in the hand, sometimes result in corrupted tiles.
TmEE co.(TM) wrote:Fonz meant expansion port...

Really interesting things... too bad that I don't have MD1... I'd like to mess with this too !!! MD2 "chipset" has lots of pins present on chips it contains... but no-one knows which pins they are (if there's any what here's talked about).

I had a (very) quick look into the 60pin connector, didn't notice any special pin from CONN<->VDP excluding the address/data pins.


Yeah that 315-5660 sucks, badass 208pin with micro-sized legs, and worse, seems that there aren't pinouts of it in the net...


More: There is some suspicious activity in some(tested only a few) pins in this range: [120-127] of some MHz, somewhat digital, they are, like dirty signals (i think it's normal after seeing the $hity edclock that ges out of the VDP (seems like the pixel clock for the tv standards))... More on this matter in a few days...

SPA/B will be under testing too...
Last edited by Jorge Nuno on Wed Oct 03, 2007 9:51 pm, edited 1 time in total.

Fonzie
Genny lover
Posts: 323
Joined: Tue Aug 29, 2006 11:17 am
Contact:

Post by Fonzie » Wed Oct 03, 2007 9:51 pm

Haha, nice, 8bit of hidden goodies! Good luck with the testings :)

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Wed Oct 03, 2007 10:02 pm

Fonzie take a look at the picture of the C2 board, the server refuses but you can right click the link and save target as...

http://www.system16.com/boards/puyopuyo2.jpg

VDP in the lower right corner, side of pin1 is facing the VDP's RAM,
now looking at the pins left of pin1, they seem to be conected to that SEGA black chip...

More, that sega covered chip, has a central core (I presume that is the external CRAM), and 3 chips near the edges... I think they are the RGB DACs.

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 Oct 04, 2007 5:26 am

I've seen another arcade board, and it had same(looks like this) covered chip...
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

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Tue Oct 09, 2007 10:44 am

Ummm, pins 120-127, AND pins 18-25, all of them have digital signals present on them but they stop any activity if SEL1 is pulled high... I need to halt the CPU...
Even when the display is blanking these signals never stop... wierd, tough in vsync there is some minimal periodicity.


VDP pin 9 doesn't look like an output (always low with some noise), probably is a N.C.


Right now I'm going to test SPA/B:

It's always low with S&K, probably has to be configured in a VDP reg to show something...

Post Reply