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 - Mega Drive VDP quirks in SMS mode

Reply to topic
Author Message
  • Joined: 11 Jun 2024
  • Posts: 8
Reply with quote
Mega Drive VDP quirks in SMS mode
Post Posted: Tue Jun 11, 2024 12:37 pm
These last days I've been busy reading the code from nukeykt's Verilog recreation based on the VDP decap trying to figure out how the Mega Drive VDP works and started to notice some oddities regarding SMS mode (especially when trying to use mode 5).

Just to make it clear, I haven't been able to verify this myself (I don't have the suitable hardware at hand), so it may be better if somebody here checks this on actual hardware to make sure.

In case some users here aren't aware with all these terms as they're largely Mega Drive specific:

  • SMS mode: console is in Master System compatibility mode
  • MD mode: console is in Mega Drive mode
  • Mode 4: VDP is in the Master System graphics mode
  • Mode 5: VDP is in the Mega Drive graphics mode


VDP commands in mode 5

Under mode 4, VDP commands are 16-bit. Under MD mode this means writing one word to the control port, while under SMS mode this means writing two bytes to it.

However mode 5 has longer commands (24-bit precisely), except for register writes which remain the same. Under MD mode you do this by writing two words in a row. However, mode 5 commands also work in SMS mode, by writing three bytes in a row. This means that you can access all 64KB of VRAM as well as VSRAM, or even read CRAM if you really want.

The odd part is that they seem to have made it explicit. You'd expect it to be two bytes (e.g. not support the longer commands) or four bytes (naively implement two words), but nope, the checks seem to be explicitly designed to reset it as soon as the extra byte is written (regardless of CPU).

VDP status port in mode 5

The status port on the Mega Drive VDP has 10 bits. Normally only the bottom 8 bits are accessible in SMS mode (no big deal since the two missing bits are not present on a Master System VDP anyway)… except under the following contrived conditions:

  • The VDP must be in mode 5
  • You must read one of the VDP status port mirrors with address bit 1 clear (e.g. $BD instead of $BF)

When this happens, bits 1-0 of the status port are replaced with bits 9-8, allowing access to all 10 bits. I don't think this is mentioned anywhere (who'd think to try one of the mirrors in a mode that may not have even worked?).

Other stuff...

Again, I'm getting this info by reading verilog code and I haven't been able to verify this myself yet so I may have misunderstood something.

I haven't gotten to the data port yet, so I have no idea how memory accesses work. I imagine that VRAM works as usual but no idea about CRAM or VSRAM (I wouldn't be surprised if it works like CRAM on the Game Gear, however). I also have no idea if DMA transfer works at all.

Whatever the case it does seem like Sega tried hard to ensure mode 5 works in SMS mode, or at least with a Z80. As for why they'd do that? My guess is that they still weren't sure if they'd use a 68000 (from an interview, I can't link since the user account is too recent lol):
Quote
“Yes, the designs for the graphics parts had already begun, and we had an issue regarding the cost, as it was quite a late stage when he had decided on the main CPU would be the 68000 (Motorola 68000 processor),” Ishikawa reminisces. “The reason we used two CPUs was because we believed that the load would be too heavy, had we used one to handle both sound and visuals. Due to that reason, we used the Z-80 as a sub-CPU to handle the sound, which reduced the load on the main CPU while maintaining compatibility.
  View user's profile Send private message Visit poster's website
  • Joined: 30 Jun 2016
  • Posts: 198
  • Location: Australia
Reply with quote
Post Posted: Tue Jun 11, 2024 10:11 pm
The link to the interview Sik was talking about by the way.

This is absolutely incredible stuff. I'm really glad you looked into this.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14789
  • Location: London
Reply with quote
Post Posted: Tue Jun 11, 2024 11:26 pm
I guess this is the original text: https://web.archive.org/web/20130818192544/https://www.famitsu.com/news/201308/1... but it seems there’s very little 8-bit in there. Maybe we need to interview him about the SG-1000 III and Master System :) It does seem to make it clear that the VDP was made by Yamaha and not under his direct control.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Jan 2023
  • Posts: 1
  • Location: United States
Reply with quote
Post Posted: Wed Jun 12, 2024 4:54 am
I'm tempted to think they might have done something to make games "dual compatible" (eg: running a game in SMS Mode 4 when on the SMS, Mode 5 when on a Megadrive) and perhaps it didn't pan out?

The only other guess I can wager is for developer familiarity; it likely would have been cheaper for several companies to merely make "dressed up" SMS games and let them use the same old Z80 dev setups and devkits they've been using.

The reason why I don't think it's because of any CPU shenanigans is because the quote reads more like they were simply unsure which architecture to use as the main CPU (I don't see any implications that there wasn't ever going to be a more capable main CPU) and simply settled on making the 68000 the main CPU architecture of choice. In other words, to me it implies that there was always going to be two CPUs, and they weren't sure what the main CPU should be.

Anyways, I find it fascinating that Mode 5 even works in SMS mode at all. I'm doubly impressed that Sega went out of their way to deliberately ensure it worked too, even going the extra mile in places. Combine this with the supposed Z80 overclock (if it even works in SMS mode) and you have a sort of "Super SMS" that isn't quite as powerful as the resulting Megadrive but is much more capable than a stock SMS. It's a bit like the MSX2+ models; the MSX-Engine ASIC can be overclocked (which also alters the PSG clock) and said models also received a visual enhancement as well (V9958 VDP over the V9938). Actually, given that similarity, perhaps we should call the Megadrive equivalent the SMS2+, lol.

Although, is the decap just the YM7101 ASIC? I'm sure the later Megadrive ones (like FC1004) have this as well, but it'd be nice to confirm it's there as well (or really, hardware confirm any of this; I could definitely do some testing in that regard as I have actual consoles).
  View user's profile Send private message
  • Joined: 11 Jun 2024
  • Posts: 8
Reply with quote
Post Posted: Tue Jun 18, 2024 2:39 am
I've been writing some of this stuff here:

https://github.com/sikthehedgehog/vdpnotes/blob/main/tidbits.md#mode-5-in-sms-mo...

Also some details about mode 4 for fun, though again it's just as incomplete:

https://github.com/sikthehedgehog/vdpnotes/blob/main/tidbits.md#mode-4-implement...

I know that the FIFO keeps track of partial writes by having a "bit -1" for the head index (used for byte writes). Writes go directly to the FIFO instead of an intermediate latch, each FIFO slot keeps track of whether one or both bytes are valid.

Still not sure how reads work but I did find a check that explicitly selects a byte when reading in 128KB mode (i.e. 8-bit CPU bus and 16-bit VRAM bus). So not only did they also accomodate reads from VRAM, but they even bothered to make it work with the memory configuration the Mega Drive doesn't use.

The whole mechanism isn't examined yet but it seems clear that VDP is expecting two byte accesses for reads and writes with a Z80 (for what would be a word access with the 68000).

I still have no idea if DMA transfers work, but if they do, it looks like the source address should be measured in bytes in SMS mode (unlike in MD mode which uses words), since it puts the address as-is on the address bus. I suppose length too (source address and length are incremented by the same signal), but I haven't checked how DMA interacts with an 8-bit data bus yet. Also note that the upper byte of the source address would be still needed since it includes the DMA type bits.

forple wrote
Although, is the decap just the YM7101 ASIC? I'm sure the later Megadrive ones (like FC1004) have this as well, but it'd be nice to confirm it's there as well (or really, hardware confirm any of this; I could definitely do some testing in that regard as I have actual consoles).
There's a decap of a later revision and off the top of my head the only thing that changed was the identification markings, the circuit proper is the same (down to the layout). In fact it looks like the VDP was pretty much intact until the very last revision (model 3 VA2), and even then only because it needs to interface SDRAM there (though they seem to have also fixed the VSRAM bug).
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1200
Reply with quote
Post Posted: Thu Jun 20, 2024 10:31 pm
This is really amazing work, thanks for sharing your findings. It's cool to see how things actually work under the hood at long last.

In vdp_notes.txt there's some talk about muxing the pixel data or DRAM refresh address onto the color bus (w.r.t register $8B bit 7).

In the Sega C2 hardware they seem to be using this feature as a convenient way to map 68000 address lines A8-A1 onto the color bus when accessing external color RAM. This saves them from having to externally multiplex the color bus and address bus.

But do we know what the timing looks like for the color bus in this mode? The C2 hardware seems to assume the column portion of the address is being output all the time, but I would imagine it would output the row (upper address lines) for a few cycles before switching to the column.

It's also unclear what would trigger that sequence; C2 maps the color RAM to $8C0000 and not $FF0000 where the work RAM is, so I guess the MSB of the address is not a factor. Maybe it just uses AS# to kick off the sequence of RAS and then CAS on the color bus?
  View user's profile Send private message Visit poster's website
  • Joined: 11 Jun 2024
  • Posts: 8
Reply with quote
Post Posted: Sun Jun 23, 2024 11:29 am
You're thinking on the wrong bit.

Bit 7 makes it output the current color and palette index over those pins. That is not a memory access. The RAMDAC takes those as inputs (alongside a bunch of other signals) to determine what color to output to screen (VDP can also output whether it's a sprite pixel, that's how scroll and sprites have separate palettes on a System C). So bit 7 is used to tell the VDP to let go of the bus so the 68000 can access it. Addressing is done separately by the System C custom hardware.

Bit 6 is the one that controls DRAM over that bus: when set the VDP takes control over the work RAM including its refresh. System C doesn't use that as far as I'm aware? Nor does Mega Drive, and you should avoid setting it there because it'll clash with the internal refresh mechanism and lead to a crash (oops). And no, I don't know what the DRAM timings are, but also explains what you're confused about I guess.

I haven't really looked much at that part of the VDP because right now I'm trying to nail down the basics first.


Back to the original topic: well, this is more cursed than it should be. In theory, byte writes work both in MD and SMS modes, so I wrote a test program in MD mode to try that theory… but it just does word writes. But I trace the circuit on both sides of the FIFO and it looks like it should work: /UDS and /LDS are stored straight to the FIFO, and then when flushing the entry those values go more or less straight to the /WE1 and /WE0 pins (there's some extra stuff involving DMA and stretching the pulse for a few cycles, but that isn't relevant here). There's even logic to account for 8-bit VRAM and flush word writes as two byte writes to VRAM. I still have no clue what's going on here.

I should probably try SMS mode but the problem is that no emulator supports mode 5 in SMS mode so I can't see what I'm doing and I don't have anything on hand to test it on real hardware either. You'd think that BlastEm would emulate it (since it emulates a VDP with MD quirks), but nope. Trying to see how to sort this out meanwhile.

One thing that does seem true, though: byte writes to the FIFO take up the whole entry (well, that's wasteful), at least in MD mode. Not sure what does that mean for CRAM and VSRAM in SMS mode, I'll need to look into that again.
  View user's profile Send private message Visit poster's website
  • Joined: 11 Jun 2024
  • Posts: 8
Reply with quote
Post Posted: Wed Jun 26, 2024 8:59 am
Turns out that the reason why byte writes don't work in MD mode is because of a hardware bug, oops: VDP doesn't latch the /UDS and /LDS signals in time, so the 68000 opcode prefetch happens before it does (which is a word access) and it stores that in the FIFO, turning the byte write into a word write. Thanks nukeykt for figuring out what was going on. Surprisingly, it seems that the byte writes are reversed between 64KB and 128KB VRAM? (8-bit and 16-bit VRAM bus) Sega really didn't test this much, did they?

This should not affect SMS mode thankfully (which relies on bit 0 of the current address instead). Remember to set autoincrement to 1 though (instead like 2 as is common in MD mode), since byte writes still take a whole FIFO slot.

CRAM and VSRAM seem to take byte writes just fine too, so that's another thing that shouldn't be a problem in SMS mode.

DMA transfer on the other hand seems hardwired to word accesses so that would make it unusable in SMS mode? I haven't looked that much into it yet so it's possible I missed something (and most of what I ran into turned out to be DMA copy, since it's muxed against the FIFO), but it doesn't look promising so far.
  View user's profile Send private message Visit poster's website
  • Joined: 17 Sep 2013
  • Posts: 130
  • Location: Gravataí, RS, Brazil
Reply with quote
Post Posted: Sat Jun 29, 2024 6:05 pm
I did some tests on this topic a while back, the most notable things I notice where:

DMA: DMA works in sms mode, but I only manage to use VRam<->VRam

Mode 4 Vertical Scroll: By swiching to Mode 5 midscreen and than back to Mode 4 at least one line later, the Mode 4 screen from that point on, will take its value from the VSRam, most likely from the last vertical scroll position fetched for Plane A.

Extended Mode 4 Screen: By Switching to Mode 5 midscreen and back to Mode 4 after line 192, the vertical borders of the screen get filled with Mode 4 data. It works almost exaclty as a natural extension, exceprt that the vertical scroll information comes from VSRam, instead of the VSCroll register. Also, the behavior of the 224-255 scroll position is slight different.

There's also some other diferences, like, changing the VDP to mode 5 during certain part of VBlank and than back, can make the Mode 4 Screen be shifted 16 lines Upwards.

The rom attached have all this. Including using Mode5 128k to DMA a Mode 4 sprite table from $4000 to $3f00
DemoStatusBar.zip (558.02 KB)
Example

  View user's profile Send private message
  • Joined: 11 Jun 2024
  • Posts: 8
Reply with quote
Post Posted: Mon Jul 01, 2024 8:44 pm
Yeah DMA transfer is what I think is likely broken. DMA copy and DMA fill should be safe since they don't involve the CPU bus. I haven't paid much attention to how DMA works though, I just ran into bits of it because it ends up in the FIFO (which is what I was looking at last time).

The vertical scroll stuff is likely a side effect of how it picks the value to use, it may be latching the value from VSRAM when it was in mode 5 and not refetching anything since it isn't supposed to in mode 4. I need to look at that later.

The 16 lines shift is likely what happens if you change the mode where the V counter wraparound is supposed to happen: there are different values for the wraparound points for mode 4 and 5 to accomodate the fact that V counter = 0 needs to match the first display line (and they have different heights, so this is needed to ensure it stays centered). If you're unlucky it can also go the other way and it miss the wraparound completely, giving you 512 scanlines per frame (which of course won't sync to anything).
  View user's profile Send private message Visit poster's website
  • Joined: 17 Sep 2013
  • Posts: 130
  • Location: Gravataí, RS, Brazil
Reply with quote
Post Posted: Tue Jul 02, 2024 2:23 am
Did you find a way to access the debug register from SMS mode?

I always assumed that the avaliability of Mode 5 in SMS mode was just a side effect of the fact that the genesis have just one VDP and they didn't bother to lock Mode 5 away. But that trick of accessing bits 9-8 of the status register made clear that this was a deliberate decision. So might be a way to access the debug register too.
  View user's profile Send private message
  • Joined: 11 Jun 2024
  • Posts: 8
Reply with quote
Post Posted: Tue Jul 02, 2024 8:53 pm
There isn't any way as far as I can tell. I could take a look at it again later but I'm pretty sure it only looks for a 68000 address.

Even in MD mode it barely works, it was clearly designed with custom equipment in mind (probably used at the factory for checking that the chip isn't defective). Latching values is unreliable, some stuff is only really usable when there isn't a CPU constantly on the bus (and possibly a frozen clock too), and sometimes some pins have unorthodox uses as well. Many of the registers are about reading internal VDP state. The fact that there was anything worth exploiting at all is impressive.

I know that there's at least one flag that affects SMS mode where it changes the bits reported by the HV port with the missing ones. I forgot for sure if it didn't also apply to MD mode or not (I think not but I need to look again to confirm).


I suspect that DMA transfer not working in SMS mode probably means that DMA was added after they decided to use the 68000 as the main CPU (and DMA does have its fair share of bugs). I didn't look exactly into how DMA transfer interacts with the bus though so maybe we're just overlooking something.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!