Forums

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

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!

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.

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)

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?

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 Core State Machine Possibly.PNG (2.35 MB)

315-5124 Sprite Cache Possibly.PNG (1.73 MB)

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).

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.

315-5124_sprite_row.jpg (365.18 KB)

315-5124_bg_shifter.jpg (233.91 KB)

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.

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. :)

Note that the die image is here:

https://www.smspower.org/Development/315-5124Die

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

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.

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.

Thanks for following up with links. There's a lot of good info. BRB.

Author	Message
bsittler Joined: 22 Apr 2018 Posts: 530	SMS VDP Die Shots on Twitter! 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
bsittler Joined: 22 Apr 2018 Posts: 530	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

Flygon Joined: 30 Jun 2016 Posts: 196 Location: Melbourne, Australia	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!

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	SMS VDP Die Shots on Twitter! 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.

furrtek Joined: 05 Mar 2006 Posts: 53 Location: France	Posted: Mon Jan 10, 2022 10:19 am
furrtek Joined: 05 Mar 2006 Posts: 53 Location: France	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)

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Mon Jan 10, 2022 12:45 pm
Calindro Joined: 14 Apr 2013 Posts: 624	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?

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	SMS VDP Die Shots on Twitter! 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 Core State Machine Possibly.PNG (2.35 MB) 315-5124 Sprite Cache Possibly.PNG (1.73 MB)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	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).

furrtek Joined: 05 Mar 2006 Posts: 53 Location: France	Posted: Fri Jan 14, 2022 3:06 pm
furrtek Joined: 05 Mar 2006 Posts: 53 Location: France	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. 315-5124_sprite_row.jpg (365.18 KB) 315-5124_bg_shifter.jpg (233.91 KB)

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	SMS VDP Die Shots on Twitter! 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.

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	SMS VDP Die Shots on Twitter! 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. :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Thu Dec 14, 2023 5:00 pm
	Note that the die image is here: https://www.smspower.org/Development/315-5124Die

Trirosmos Joined: 26 Apr 2022 Posts: 29 Location: Brinstar, Zebes	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

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	SMS VDP Die Shots on Twitter! 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.

Trirosmos Joined: 26 Apr 2022 Posts: 29 Location: Brinstar, Zebes	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.

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	SMS VDP Die Shots on Twitter! Posted: Fri Mar 22, 2024 9:57 am
	Thanks for following up with links. There's a lot of good info. BRB.

Forums

View topic - SMS VDP Die Shots on Twitter!