Goplanes and the TMSS

[djcouchycouch]

Hi,

Goplanes shows the "Produced by or under licence blah blah" message on start up. Since obviously Goplanes is not licensed, what should I do with that message? What have other published homebrew games like Pier Solar have done?

Thanks!
DJCC

[TmEE co.(TM)]

The message remains. It could be bypassed with some changes in cartridge + code though.

[djcouchycouch]

Can it be easily bypassed? How would that work?

Has Sega ever said anything about homebrew productions?

[TmEE co.(TM)]

You can do anything you want as long as you dont use their trademarks.

As for cart you need to add your own adress decoder and on software side you got to disable TMSS ROM by doing a register write to avoid a bus conflict.

[djcouchycouch]

As for cart you need to add your own adress decoder and on software side you got to disable TMSS ROM by doing a register write to avoid a bus conflict.

So it should be straightfoward to add to the SGDK?

[Mask of Destiny]

Hi,

Goplanes shows the "Produced by or under licence blah blah" message on start up. Since obviously Goplanes is not licensed, what should I do with that message? What have other published homebrew games like Pier Solar have done?

Thanks!
DJCC

The court system has ruled that Sega can't abuse the trademark system to enforce the "Produced by or under license" text. I wouldn't worry about it unless it bothers you for aesthetic reasons.

[Chilly Willy]

As for cart you need to add your own adress decoder and on software side you got to disable TMSS ROM by doing a register write to avoid a bus conflict.

So it should be straightfoward to add to the SGDK?

No, it isn't. Didn't you read the part about requiring extra hardware on the cart as well as software?

As MoD said, don't worry about it. The initial screen from the TMSS bios is not legally enforceable.

[djcouchycouch]

No, it isn't. Didn't you read the part about requiring extra hardware on the cart as well as software?

Apparently not!

[doragasu]

I'm intrigued. What extra hardware would you need to add? Maybe not shorting the CART_IN signal and something else?

[Chilly Willy]

Correct me if I'm wrong, but it's my understanding that failing the TMSS causes DTACK not to be asserted on accesses to hardware, which means the 68000 hangs. So it would seem the solution would be to generate your own DTACK signal.

[HardWareMan]

I think it's not about how to run the program without unlocking the VDP as it well known, but how to make TMMS not show this banner. If you put the keyword SEGA at 100 - TMMS will show banner and go to the program, if you do not put - the banner will not be shown but the program will not run too because TMMS hangs/loops.
A possible solution to the problem is a hardware write to TMMS register for disable its ROM before M68K fetch the start vector, and it requires a detailed study of initialize cycles of M68K and hardware, because reset by itself activates the TMMS. Good challenge, but without the help of the additional hardware is seems to not solved. And this is its essence - do not allow illegal code to run.

[Charles MacDonald]

Correct me if I'm wrong, but it's my understanding that failing the TMSS causes DTACK not to be asserted on accesses to hardware, which means the 68000 hangs. So it would seem the solution would be to generate your own DTACK signal.

The trick is that when $A14000 != "SEGA", the bus controller chip never strobes /VDPM (chip select) for $C00000-$DFFFFF. When you touch that area the VDP won't respond with DTACK and the system locks up. You could fake the DTACK response; but the VDP still wouldn't react to any reads or writes.

But as long as an application never uses the VDP it will still run correctly. I guess you could connect a LCD display to a controller port as a crude work-around.

[Chilly Willy]

Correct me if I'm wrong, but it's my understanding that failing the TMSS causes DTACK not to be asserted on accesses to hardware, which means the 68000 hangs. So it would seem the solution would be to generate your own DTACK signal.

The trick is that when $A14000 != "SEGA", the bus controller chip never strobes /VDPM (chip select) for $C00000-$DFFFFF. When you touch that area the VDP won't respond with DTACK and the system locks up. You could fake the DTACK response; but the VDP still wouldn't react to any reads or writes.

But as long as an application never uses the VDP it will still run correctly. I guess you could connect a LCD display to a controller port as a crude work-around.

Ah - thanks for explaining that. That explains why the first thing the standard Genesis startup code does after setting the TMSS reg is read the VDP.

[TmEE co.(TM)]

Solution :

Make the cart forcibly put out data on 000000-3FFFFF accesses, it will cause a bus fight with TMSS so the first thing you do in your ROM is write the mädzik TMSS disable register and rest is smooth sailing.

Alternatively you can do all before but with !CartIn high, then you get a bus fight with MCD BIOS when present but my experiments show it in not a big deal (series resistors and stuff on MCD side), you could also have a register which puts !CartIn back low too, then you can deal with WCD side too if you wish and 32X side should have no complaints either.

Some pirate games got MCUs which force some bits on the databus to break out of TMSS right into cart space.