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 - SMS VDP Die Shots on Twitter!

Reply to topic
Author Message
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
SMS VDP Die Shots on Twitter!
Post Posted: Sun Jan 09, 2022 8:05 pm
Last edited by bsittler on Mon Jan 10, 2022 6:09 pm; edited 1 time in total
Furrtek continues to do amazing work that will aid in proper understanding, emulation, simulation, and preservation of our treasured 8-bit consoles!

This time it is die shots of the "SMS 1" VDP 315-5124:

https://twitter.com/furrtek/status/1480263375183663104

I already exhausted my attachment quota here otherwise I would attempt to mirror the image: https://t.co/oC3bNeJOgx
  View user's profile Send private message
  • Joined: 30 Jun 2016
  • Posts: 195
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Mon Jan 10, 2022 5:04 am
What an absolute mad lad. I've been waiting for something like this for years.

I hope this can finally shed light on some final secrets on the Master System VDP!
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 741
  • Location: Adelaide, Australia
Reply with quote
SMS VDP Die Shots on Twitter!
Post Posted: Mon Jan 10, 2022 7:10 am
Very cool. Thanks Furrtek.

I've only had a brief look so far but Vcc pin 40 is in the top right hand corner of the die/photo. The pinout then goes around anticlockwise.

The PSG is in the lower left and corner of the die/photo.
  View user's profile Send private message
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Mon Jan 10, 2022 10:19 am
No problem, I've been meaning to make a full die picture while ago but time was lacking.
Out of curiosity I had a go at the PSG outputs and found out that the test pins T0 and T1 (12 and 13) seem to be used to test the channels individually.
From what I understand (can't test it myself), A14 and A15 select the channel, and T1 enables the analog output on T0.
Totally useless in normal use but thought I'd share it anyway ;)

CRAM, legacy color lookup table and video DACs are in the lower right.
315-5124_PSGtest.jpg (317.34 KB)
315-5124_PSGtest.jpg

  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 624
Reply with quote
Post Posted: Mon Jan 10, 2022 12:45 pm
furrtek wrote
No problem, I've been meaning to make a full die picture while ago but time was lacking.
Out of curiosity I had a go at the PSG outputs and found out that the test pins T0 and T1 (12 and 13) seem to be used to test the channels individually.
From what I understand (can't test it myself), A14 and A15 select the channel, and T1 enables the analog output on T0.
Totally useless in normal use but thought I'd share it anyway ;)

CRAM, legacy color lookup table and video DACs are in the lower right.

Thanks for sharing this! Are you going to do some further investigations/tracing?
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 741
  • Location: Adelaide, Australia
Reply with quote
SMS VDP Die Shots on Twitter!
Post Posted: Mon Jan 10, 2022 1:24 pm
Great find on the PSG test mode.

I can see CRAM, 12 high by 16 wide with a 6 line bus exiting out the right side towards the video DACs.

The huge block right above the PSG must be the Sprite Cache then? If it is, then the 8x16 zoom on the first 4 sprites only looks intentional doesn't it? I mean, it would be hard to miss a mistake like that.

To the right of the (what is possibly) the Sprite Cache is a big look up table next to the master ground and XTAL pads. I wonder if that's the core VDP state machine?
315-5124 CRAM.PNG (1.78 MB)
315-5124 CRAM.PNG

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3793
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jan 11, 2022 12:07 pm
asynchronous wrote
The huge block right above the PSG must be the Sprite Cache then? If it is, then the 8x16 zoom on the first 4 sprites only looks intentional doesn't it? I mean, it would be hard to miss a mistake like that.


It looks like it's 4 (or 8) shorter 'bands' above other 4 (or 8) slightly longer bands, if that makes sense. Could be the 'sprite draw' list.

About the bug itself, I think when they switched to 8 sprites per line max (from 4) they totally forgot about the zoom bit and duplicated only the 'cache' lines (and this is probably also the source of the zoomed sprites collision flag bug).
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Fri Jan 14, 2022 3:06 pm
Quote
The huge block right above the PSG must be the Sprite Cache then? If it is, then the 8x16 zoom on the first 4 sprites only looks intentional doesn't it? I mean, it would be hard to miss a mistake like that.


Looks like it is. Tracing back the 4-bit CRAM address bus leads to what could be the background shifter (the 2 rows between the PSG and the CRAM, only 16 bits ?), and the whole left edge of that big block.
All the rows are connected in parallel, which means that the priority logic probably drives tri-state buffers to select which sprite pixel is finally used.

I'm not 100% sure about the arrangement, but from what I understood from the TMS9918 patent, each sprite cache element should have an h-counter and a large enough shift register to store a full 4bpp line of 8 pixels.

That same color bus also goes to at least another block but I don't know what it could be used for.
Maybe the backdrop color ?

Quote
To the right of the (what is possibly) the Sprite Cache is a big look up table next to the master ground and XTAL pads. I wonder if that's the core VDP state machine?


Placing bets on that too. The top part is a ROM which data is used by another ROM for further decoding, and also fed back to its own address bus through a register. So the top part would be a current state -> next state lookup, and the bottom part would be current state -> control signals.

  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 741
  • Location: Adelaide, Australia
Reply with quote
SMS VDP Die Shots on Twitter!
Post Posted: Sun Jan 16, 2022 1:57 am
I’ve traced the CPU data bus and control lines (/IORQ, /RD, /WR, A0, A6, A7) and also the PAL/NTSC pin. The CPU data goes to the PSG and to what looks like the buffer and multiplexer for the command word register and status register in the top right; next to what looks like the VRAM address generation (or a chunk of it).

While doing that I traced all the lines going in and out of the PSG (D0-D7, /IORQ, /WR, A6, A7, CPU_CLK, /RESET, AUDIO.)

Oddly, the decoding logic for the /EXM1, /EXM2, /CSRAM, /KBSEL pins is slapped in the lower right hand corner of the PSG.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 741
  • Location: Adelaide, Australia
Reply with quote
SMS VDP Die Shots on Twitter!
Post Posted: Sat Jan 22, 2022 2:49 am
I think you’re correct regarding the Sprite H-counter.

The 16 lines directly above that sprite block are the 16-bit VRAM data bus. The shift register part of the block connect to each of the 16 data lines for loading the sprite tile pattern data and the H-counter part on the right connects to VRAM D0-D7 which would correspond to the X-coordinate of the sprite attribute x,n pair. So I reckon the X-coordinate is loaded into the H-counter and the H-counter counts down during active display and then starts shifting the sprite tile pattern out when the counter reaches zero. (This could be why the bit to move all sprites left 8 pixels is called the ‘Early Clock’ bit.)

The rectangle block right above the H-counter section appears to be part of the sprite processing. The bottom of the block connects to all 16 lines of the VRAM data bus and top of the block connects to part of the VRAM Address line formation and what could be some sort of line counter bus. So this block may perform part of the sprite Y-coordinate processing and fetching of the sprite x,n attributes.

The “BG Shifter” you pointed out, the one next to CRAM, I don’t think that’s the BG shifter for SMS mode 4. I think this may be for one of the Legacy modes? The lower half of the VRAM data bus (D0-D7) is connected to the top of this block. These lower 8 lines of the VRAM data bus can be multiplexed with the upper VRAM bus data (D8-D15).

The Background processing for SMS Mode 4 is on the right hand side of the die right above the section with the 2 ROM tables. There is a block for the 4 byte shift registers, a block for latching the Screenmap word, and then big block which appears to generate the VRAM address for the Screenmap access and the tile pattern access. The x-flip is done by loading the tile pattern bytes into the shift registers as D0-D7 and D8-D15 or D7-D0 and D15-D8 from the VRAM data bus. I'd upload an image but I've reached my SMSPower 25MB Upload Quote limit. :)
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14723
  • Location: London
Reply with quote
Post Posted: Thu Dec 14, 2023 5:00 pm
Note that the die image is here:

https://www.smspower.org/Development/315-5124Die
  View user's profile Send private message Visit poster's website
  • Joined: 26 Apr 2022
  • Posts: 29
  • Location: Brinstar, Zebes
Reply with quote
Post Posted: Fri Jan 05, 2024 5:10 pm
Y'all have probably seen this already, but just for completeness sake, nukeykt wrote an entire gate-level SMS emulator based on the available die shots :D
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 741
  • Location: Adelaide, Australia
Reply with quote
SMS VDP Die Shots on Twitter!
Post Posted: Sat Jan 06, 2024 2:04 am
Trirosmos wrote
Y'all have probably seen this already, but just for completeness sake, nukeykt wrote an entire gate-level SMS emulator based on the available die shots :D


Do you want to discuss this further? No disrespect to anybody's awesome work, but if you're trying to say the emulator is a gate accurate copy of the VDP die shot then I call BS. A lot of the blocks in the VDP die are so densely packed that it's hard to make out the transistors without etching off more layers and taking further die shots.
  View user's profile Send private message
  • Joined: 26 Apr 2022
  • Posts: 29
  • Location: Brinstar, Zebes
Reply with quote
Post Posted: Mon Feb 26, 2024 2:55 am
asynchronous wrote
Trirosmos wrote
Y'all have probably seen this already, but just for completeness sake, nukeykt wrote an entire gate-level SMS emulator based on the available die shots :D

No disrespect to anybody's awesome work, but if you're trying to say the emulator is a gate accurate copy of the VDP die shot then I call BS.


It is, effectively, exactly that :)

fwiw, as mentioned in the repo, the Twitter images were not the only ones used.

Also, I think you're severely underestimating nukeykt's abilities. Nuke has written gate-level emulators for the YM2608, OPL3, OPN2, OPLL and an entire Mega Drive, which is now the core used on MiSTer.

Also, Yamaha's manufacturing process was simple NMOS with only a single metal layer, so delayering is not strictly necessary.
As far as I understand, these chips all use a common set of more or less standard logic cells, which had previously been documented here.
The emu-russia team also built costumized tools that can take a library of images of standard cells and use a neural net to recognize them in a decap image.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 741
  • Location: Adelaide, Australia
Reply with quote
SMS VDP Die Shots on Twitter!
Post Posted: Fri Mar 22, 2024 9:57 am
Thanks for following up with links. There's a lot of good info. BRB.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!