Total MD TMSS reverse engineering

[TmEE co.(TM)]

http://www.hot.ee/tmeeco/DWNLOADS/TMSS.RAR

I have no idea how many times it is done before, but here goes my attempt.
Comment on most of the lines, everything is nice and neat.

I have a small unconfirmed theory about the SEGA write we're supposed to do on later MD models... read the code, then you know.

Enjoy

[HardWareMan]

I, too, has long been done, but in Russian. A full description of all acts and registers, etc.
You can get it here, in second post.

[Eke]

I'm not sure about your theory on the VDP version thingie, I would rather say the version bits reflect the version of the IO controller and if TMSS register ($A14000) exists or not, there is no clue this register would affect the VDP.

The reason why it checks for version before exit when no "SEGA" string is found in ROM header is probably to "reset" the TMSS register which was set upon initialization:

on init, setup TMSS register:

Code: Select all

;A1 = 00A11100          ;
 MOVE.B -$10FF(A1), D0  ;
 AND.B  #$0F, D0        ; 
 BEQ.B  SkipSequrity    ; 
 MOVE.L #"SEGA", $2F00(A1)
SkipSequrity:

on exit, reset the TMSS register:

"bad" exit

Code: Select all

;A2 = 00A14000         ;
;A6 = 00A10001         ; 
 MOVE.B (A6), D0        ; 
 AND.B  #$0F, D0        ; 
 BEQ.B  GoAndHalt       ;
 MOVE.L #0,(A2)         ;
GoAndHalt:
 RTS 

"good" exit (wondering why they used a different mask)

Code: Select all

;A2 = 00A14000         ;
;A6 = 00A10001         ; 
 MOVE.B (A6), D0        ;
 AND.B  #15, D0
 BEQ.B  SkipVDPblank
 MOVE.L #0, (A2)
SkipVDPblank:

looks quite logical to me

The reason why the BIOS itself always checks version bits before writing to the register is probably because TMSS register do not exist on earlier machines and write would lockup the system. I admit this is a rather dummy verification since the BIOS has only been implemented on machines that should support that but this is common in software verification.

[TmEE co.(TM)]

The models without TMSS should not have the A14000 register in it and should not have the TMSS either... Why would you check if there's TMSS reg if the code should not be on a non-TMSS machine anyway ?
... OR Sega was lazy and didn't take the code out when they wrote it on a non-TMSS machine... ?

The A14000 register enables VDP and that is 100% certain, if you don't do the write the VDP is not functional. The TMSS ROM is completely controlled by the A14101 register and that is 100% certain aswell. Damnit... I had a non-TMSS MD with the VDP of the TMSS MD (315-5313A)...

EDIT: Possibility exists that there's TMSS units with the old VDP, and in that case, the checks would be justified... I've never seen one yet.

[Eke]

well, it make sense in a way, since the only thing that the BIOS is doing is initializing VDP/PSG (and USP yes)... the first VDP status read could be done to reset some internal stuff as well

or maybe the TMSS register is something taht would prevent access to WRAM if not properly set (I doubt it since this is the first thing it does and code won't be running from RAM until later) ?

I'm also pretty sure the "unneeded" version check is part of a generic software control routine that was left over.

[TmEE co.(TM)]

Bypassing the TMSS, and having no VDP read won't change anything... I have the TMSS bypassed in my MD2 (can be reversed, only matter of setting a jumper) in order not to have any weirdnesses on systems without TMSS... TMSS does VDP init nicely enough for you so may have issues on no-TMSS machines when not doing proper VDP init... BTW, all emulators should have garbage in all the RAMs to simulate real MD startup.

or maybe the TMSS register is something taht would prevent access to WRAM if not properly set (I doubt it since this is the first thing it does and code won't be running from RAM until later) ?

Not having SEGA in the reg means blank screen... I actually have not checked if VDP is functional... neither if you HAVE to write SEGA, maybe anything will do... don't know, will test soon enough.

[HardWareMan]

Bypassing the TMSS, and having no VDP read won't change anything...

Maybe, that is becouse all licensed games has own properly hardware init? When I was working on my SegaOS, I had to do such thing, or program somewhere hangs (at that time I did not trace where exactly).

[TmEE co.(TM)]

My programs don't read the VDP before doing anything and nothing has happened so far...

[Eke]

I bet reading the VDP status clears some internal values, this might not be necessary but the BIOS do this by default, who knows ?

In your program, on a TMSS console, have you tried reading/writing into memory (any locations) before writing "SEGA" in the register ? Maybe TMSS is something that force DTACK signal and lockup the machine ? (pure speculation )... This sure is interesting to know how this internally works...

TMSS does VDP init nicely enough for you so may have issues on no-TMSS machines when not doing proper VDP init...

There is one rom dump, a beta version of Demolition Man I think, that will lock if the BIOS is not running first.

[TascoDLX]

US Patent 5155768 - Security system for software

It's pretty simple.

Maybe, that is becouse all licensed games has own properly hardware init? When I was working on my SegaOS, I had to do such thing, or program somewhere hangs (at that time I did not trace where exactly).

Every licensed game is/was required to execute Sega's IP code which includes the "SEGA" security register write. As for the unlicensed games, I suppose only the security register write is required (at the very least). When TMSS exits, it resets the security register so this requirement remains for the game software to fulfill.

The security register ($A14000) is just 4 bytes of memory. You could write "NUTS" in there and the only difference is that the comparison fails and the holding circuit doesn't output the right signal. The security system will only lock up the CPU when the CPU accesses the VDP area (NOTE: the patent states this as "video controller" access and states that the check is performed when a coresponding address (bus) signal is present).

I bet reading the VDP status clears some internal values, this might not be necessary but the BIOS do this by default, who knows ?

If I were to guess, I would say the purpose of the VDP status read is merely to test the circuit. If it fails, the CPU is halted. There shouldn't be any other reason why it would matter. The logic is very straightforward. There really is nothing that needs to be cleared or reset internally.

[Eke]

Another mystery solved I guess

so this means, once the VDP acceeded, the CPU is definitively locked (the patent is not clear about that)?

anyway, thanks (again) for the US patent.. have you found others ? (VDP, IO, Bus Arbitrer...)


EDIT: another one I found about TMSS mechanism, this one also describe the internal bus and ROM banking mechanism

http://www.google.com/patents?id=TuokAAAAEBAJ

[TmEE co.(TM)]

Seems the patent is totally correct. I tried other things than SEGA and any VDP access will lock the system... anything else in the A14000 will blank the display, VDP configuration is unaltered, and operation is resumed as if nothing has happened when you have correct value in A14000.

[Eke]

anything else in the A14000 will blank the display, VDP configuration is unaltered, and operation is resumed as if nothing has happened when you have correct value in A14000.

you mean that writing bad value in the TMSS register AFTER you properly initialized it and setup the display would suddenly blank the display ?
I wonder how could that be: the patent only mentions it will lock the CPU when comparison mismatch AND VDP address is decoded

and also, I wonder if it possible to "unlock" the system once it has been locked ? I guess the answer relies on what the TMSS hardware is doing to lock the system (HALT 68k pin) ?

I took some time adding TMSS register emulation, probably the most useless emulator feature but at least it is emulated now

[TmEE co.(TM)]

OOPS, my bad, it doesn't blank the display, a VDP reg write before the SEGA write did

[Nemesis]

I wonder exactly how TMSS halts the system on a VDP access, in hardware terms. If the VDP was removed from the bus, the system would lock up by itself if VDP access was attempted, since the M68000 wouldn't get a response. The VDP does its own address decoding though, so it wouldn't be as simple as masking a CE line. Perhaps like Eke said, it might be asserting the M68000 HALT line. In this case though, maybe it's possible to get one write through to the VDP before the M68000 is halted? Or maybe there's another line running to the VDP which modifies its memory base, or disables it entirely? It couldn't completely disable the chip though, since the VDP generates the LWR and UWR lines, in the Model 1 system anyway, which would block access to virtually everything if it wasn't generated, including ROM and RAM.