Forums

I've been doing some messing around with a Pro Action Replay
and a Genesis, and figured out the following, which may
apply to the SMS (no reason why it shouldn't :)

Bit 0 of register 0 disables the display. Interrupts are
still generated, oddly enough. This verifies the same information
in "Jon's" SMS docs.

Bit 6 of register 1 blanks the display like usual, but it
appears that either the vertical interrupt is not generated,
or bit 7 of the status register isn't set (can't tell). I'm
thinking this may be put to use in GG games that enable
the blanking bit early on, while outside of the display
range but before line 192. (Mega Man for instance)

Could anyone tell me what registers 0 and 1 need to be set to
for enabling the SMS display mode, and what settings are
needed to enable any of the TMS9928 display modes?

I figure the SMS one comes from a combination of the existing
mode bits, but for some reason I keep on noticing bit 7 of
register 1 is set too.. maybe it acts as a fourth mode
select bit? I don't know of any SMS or GG games that have it
cleared.

And one last thing, contrary to most of the SMS docs out there,
there is no seperate address for color RAM. Knowing that you
cannot read from color RAM, there is never a time when you
have to maintain unique addresses for both of them. The only
time you can change from VRAM to color RAM or vice-versa is
when you write twice to the control port, and by doing that
you set up the address anyways... handling it like this does
not break any games, at least in my emu.

My Homepage

[First part is quite interesting. I'll answer after actually reading it and making some check]

Quote

> And one last thing, contrary to most of the SMS docs out there,
> there is no seperate address for color RAM. Knowing that you
> cannot read from color RAM, there is never a time when you
> have to maintain unique addresses for both of them. The only
> time you can change from VRAM to color RAM or vice-versa is
> when you write twice to the control port, and by doing that
> you set up the address anyways... handling it like this does
> not break any games, at least in my emu.

Sure but does any game made you think such thing?
I thought about it some time ago but in both case no game was broken/fixed at my knowledge.
I'll keep handling with the same address in Meka 0.50 - should be the best way to reperate broken games if there is any.

Quote

> Sure but does any game made you think such thing?
> I thought about it some time ago but in both case no game was broken/fixed at my knowledge.
> I'll keep handling with the same address in Meka 0.50 - should be the best way to reperate broken games if there is any.

There weren't any games that led me to this conclusion.

I don't think it would fix or break anything, let me explain:

Let's say you write data to the control port to set up for
a VRAM read or write. The only way you can do a color RAM write
afterwards is to write to the control port again, meaning you'll have
to set the address too. And likewise, to go back to doing
VRAM access, you'd have to write to the control port and
thereby set up the address again.

So there's never a time when you need to store a unique
address for color RAM and VRAM, because you cannot access
one or the other without being forced to set the address
in the first place.

My Homepage

I understood what you first meant.
I was wondering if any game (badly programmed) would take advantage of this feature, like setting a palette address for writing then reading from VRAM.
I tried the change with all non working games with Meka and nothing was running better. But anyway, I guess I'll be able to reduce the savegame file size by one byte ;)

Quote

> I don't think it would fix or break anything, let me explain:
> Let's say you write data to the control port to set up for
> a VRAM read or write. The only way you can do a color RAM write
> afterwards is to write to the control port again, meaning you'll have
> to set the address too. And likewise, to go back to doing
> VRAM access, you'd have to write to the control port and
> thereby set up the address again.
> So there's never a time when you need to store a unique
> address for color RAM and VRAM, because you cannot access
> one or the other without being forced to set the address
> in the first place.

Quote

> And one last thing, contrary to most of the SMS docs out there,
> there is no seperate address for color RAM. Knowing that you
> cannot read from color RAM, there is never a time when you
> have to maintain unique addresses for both of them.

You can't read from Color RAM? I thought you could? If you can't
read from Color RAM, what happens when you try?

--Nyef

Quote

> You can't read from Color RAM? I thought you could? If you can't
> read from Color RAM, what happens when you try?

It's unknown.

Quote

> I was wondering if any game (badly programmed) would take advantage of this feature, like setting a palette address for writing then reading from VRAM.

Err.. you mean setting up for a color RAM write then reading
from the data port, correct?

It would be interesting to see what happens on a real machine.
I don't know if the SMS Pro Action Replay can patch ROM addresses,
but if so, you could change a game that reads from VRAM
so it would send a color RAM write command, then observe what
kind of data it reads back.

I'm sure Flavio is capable of testing this, but I can *never*
get in touch with him. :

My Homepage

Quote

> You can't read from Color RAM? I thought you could? If you can't
> read from Color RAM, what happens when you try?

To my knowledge, the only game that reads the data port after
sending a color RAM write command is NBA Jam (GG), but I
don't have that game (can't find it anywhere). From what
I've been told, it doesn't do anything important with the
data, perhaps it just discards it.

I suppose it's incorrect to say that you can't read the color
RAM, just that there are no games to say otherwise.

My Homepage

Author	Message
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	VDP stuff Posted: Fri Mar 10, 2000 8:36 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	I've been doing some messing around with a Pro Action Replay and a Genesis, and figured out the following, which may apply to the SMS (no reason why it shouldn't :) Bit 0 of register 0 disables the display. Interrupts are still generated, oddly enough. This verifies the same information in "Jon's" SMS docs. Bit 6 of register 1 blanks the display like usual, but it appears that either the vertical interrupt is not generated, or bit 7 of the status register isn't set (can't tell). I'm thinking this may be put to use in GG games that enable the blanking bit early on, while outside of the display range but before line 192. (Mega Man for instance) Could anyone tell me what registers 0 and 1 need to be set to for enabling the SMS display mode, and what settings are needed to enable any of the TMS9928 display modes? I figure the SMS one comes from a combination of the existing mode bits, but for some reason I keep on noticing bit 7 of register 1 is set too.. maybe it acts as a fourth mode select bit? I don't know of any SMS or GG games that have it cleared. And one last thing, contrary to most of the SMS docs out there, there is no seperate address for color RAM. Knowing that you cannot read from color RAM, there is never a time when you have to maintain unique addresses for both of them. The only time you can change from VRAM to color RAM or vice-versa is when you write twice to the control port, and by doing that you set up the address anyways... handling it like this does not break any games, at least in my emu. My Homepage

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Palette Address Posted: Sat Mar 11, 2000 6:05 am
	[First part is quite interesting. I'll answer after actually reading it and making some check] Quote > And one last thing, contrary to most of the SMS docs out there, > there is no seperate address for color RAM. Knowing that you > cannot read from color RAM, there is never a time when you > have to maintain unique addresses for both of them. The only > time you can change from VRAM to color RAM or vice-versa is > when you write twice to the control port, and by doing that > you set up the address anyways... handling it like this does > not break any games, at least in my emu. Sure but does any game made you think such thing? I thought about it some time ago but in both case no game was broken/fixed at my knowledge. I'll keep handling with the same address in Meka 0.50 - should be the best way to reperate broken games if there is any.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Re: Palette Address Posted: Sat Mar 11, 2000 6:40 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote > Sure but does any game made you think such thing? > I thought about it some time ago but in both case no game was broken/fixed at my knowledge. > I'll keep handling with the same address in Meka 0.50 - should be the best way to reperate broken games if there is any. There weren't any games that led me to this conclusion. I don't think it would fix or break anything, let me explain: Let's say you write data to the control port to set up for a VRAM read or write. The only way you can do a color RAM write afterwards is to write to the control port again, meaning you'll have to set the address too. And likewise, to go back to doing VRAM access, you'd have to write to the control port and thereby set up the address again. So there's never a time when you need to store a unique address for color RAM and VRAM, because you cannot access one or the other without being forced to set the address in the first place. My Homepage

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: Palette Address Posted: Sat Mar 11, 2000 7:44 am
	I understood what you first meant. I was wondering if any game (badly programmed) would take advantage of this feature, like setting a palette address for writing then reading from VRAM. I tried the change with all non working games with Meka and nothing was running better. But anyway, I guess I'll be able to reduce the savegame file size by one byte ;) Quote > I don't think it would fix or break anything, let me explain: > Let's say you write data to the control port to set up for > a VRAM read or write. The only way you can do a color RAM write > afterwards is to write to the control port again, meaning you'll have > to set the address too. And likewise, to go back to doing > VRAM access, you'd have to write to the control port and > thereby set up the address again. > So there's never a time when you need to store a unique > address for color RAM and VRAM, because you cannot access > one or the other without being forced to set the address > in the first place.

Nyef Guest	Posted: Sat Mar 11, 2000 3:43 pm
Nyef Guest	Quote > And one last thing, contrary to most of the SMS docs out there, > there is no seperate address for color RAM. Knowing that you > cannot read from color RAM, there is never a time when you > have to maintain unique addresses for both of them. You can't read from Color RAM? I thought you could? If you can't read from Color RAM, what happens when you try? --Nyef

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Sat Mar 11, 2000 4:16 pm
	Quote > You can't read from Color RAM? I thought you could? If you can't > read from Color RAM, what happens when you try? It's unknown.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Re: Palette Address Posted: Sat Mar 11, 2000 4:29 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote > I was wondering if any game (badly programmed) would take advantage of this feature, like setting a palette address for writing then reading from VRAM. Err.. you mean setting up for a color RAM write then reading from the data port, correct? It would be interesting to see what happens on a real machine. I don't know if the SMS Pro Action Replay can patch ROM addresses, but if so, you could change a game that reads from VRAM so it would send a color RAM write command, then observe what kind of data it reads back. I'm sure Flavio is capable of testing this, but I can never get in touch with him. : My Homepage

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Sat Mar 11, 2000 4:41 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote > You can't read from Color RAM? I thought you could? If you can't > read from Color RAM, what happens when you try? To my knowledge, the only game that reads the data port after sending a color RAM write command is NBA Jam (GG), but I don't have that game (can't find it anywhere). From what I've been told, it doesn't do anything important with the data, perhaps it just discards it. I suppose it's incorrect to say that you can't read the color RAM, just that there are no games to say otherwise. My Homepage

Forums

View topic - VDP stuff