TMSS help.

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

TMSS help.

Post by Count SymphoniC » Tue Sep 30, 2014 9:01 pm

Another user of this board "Jazzmarazz" has tested the YMDJ demo on real hardware. This is what Jazzmarrazz said:

"To be more descriptive, the TMSS shows up on screen and while it is on screen, I may reset the console how ever many times I care to. Resetting the console makes the TMSS flash. If I do not reset the console, the TMSS will flash once after a few seconds and simply hang on the TMSS. If I allow for it to do that, I cannot reset the console at all. I have to disconnect power altogether.

It seems like the console simply hangs after the TMSS."

Is it that my rom doesn't satisfy the TMSS?

Code: Select all

move.b 0x00A10001, d0      ; Move Megadrive hardware version to d0
andi.b #0x0F, d0           ; The version is stored in last four bits, so mask it with 0F
beq @Skip                  ; If version is equal to 0, skip TMSS signature
move.l #'SEGA', 0x00A14000 ; Move the string "SEGA" to 0xA14000
@Skip:

BigEvilCorp's startup code.
I've checked other things, like the Domestic and Overseas name... which I think are supposed to be 48 bytes each but mine were not, I also checked the VDP registers, the first register was set to an unused bit, so I changed it to #0x14. Autincrement was set to #0x00.

What's causing this to crash on real hardware? It's a Sega Genesis 3.

Jazzmarazz
Very interested
Posts: 60
Joined: Wed Mar 12, 2014 11:11 pm
Location: Michigan
Contact:

Post by Jazzmarazz » Tue Sep 30, 2014 11:36 pm

Played around a bit. Fixed checksum and fixed region support with uCON64, edited "genesis" to "mega drive". Nothing worked.
I believe your header is correct, or at least fine as is.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Wed Oct 01, 2014 12:01 am

https://www.mediafire.com/?1llpv7l1py8zq2k

Here's the WIP v 005. Note Entry screen is only partially implemented so nothing works properly in there. I edited the startup code a bit so maybe now it will work, but maybe not. If you do get it to work, dpad navigates, c+dpad edits values, and a+dpad moves to next/previous screen, provided you set a value for that screen to go to.

Jazzmarazz
Very interested
Posts: 60
Joined: Wed Mar 12, 2014 11:11 pm
Location: Michigan
Contact:

Post by Jazzmarazz » Wed Oct 01, 2014 12:18 am

No dice. Booting your ROM does the same as I described before.
I will admit though, in an emulator it is looking damn fine!

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Wed Oct 01, 2014 12:46 am

Jazzmarazz, I sent you a PM @ chipmusic but I don't know if you got it... Here's the code after the TMSS. It's 68k yes, but it's interacting with the z80, perhaps you'll see something I don't. The declared #Z80DATA address label points to the data at the bottom of this post.

Code: Select all

; ************************************
; Init Z80
; ************************************
    move.w #0x0100, 0x00A11100    ; Request access to the Z80 bus, by writing 0x0100 into the BUSREQ port
    
        move.w #0x0100, 0x00A11200    ; Hold the Z80 in a reset state, by writing 0x0100 into the RESET port

    @Wait:
    btst #0x0, 0x00A11100      ; Test bit 0 of A11100 to see if the 68k has access to the Z80 bus yet
    bne @Wait                  ; If we don't yet have control, branch back up to Wait

    move.l #Z80Data, a0        ; Load address of data into a0
    move.l #0x00A00000, a1     ; Copy Z80 RAM address to a1
    move.l #0x29, d0           ; 42 bytes of init data
    @CopyZ80:
    move.b (a0)+, (a1)+        ; Copy data, and increment the source/dest addresses
    dbra d0, @CopyZ80

    move.w #0x0000, 0x00A11200    ; Release reset state
    move.w #0x0000, 0x00A11100    ; Release control of bus

Z80Data:
   dc.w 0xaf01, 0xd91f
   dc.w 0x1127, 0x0021
   dc.w 0x2600, 0xf977
   dc.w 0xedb0, 0xdde1
   dc.w 0xfde1, 0xed47
   dc.w 0xed4f, 0xd1e1
   dc.w 0xf108, 0xd9c1
   dc.w 0xd1e1, 0xf1f9
   dc.w 0xf3ed, 0x5636
   dc.w 0xe9e9, 0x8104
   dc.w 0x8f01

After that, it's PSG init and VDP init.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Wed Oct 01, 2014 1:15 am

I came across something interesting. I don't know how useful Fusion can be, but you can load the TMSS bios into it. Well I started up the YMDJ v005 rom in Fusion with the bios enabled and it showed the TMSS, and although it does load the tracker, the TMSS font is visibly replaced with my font before the tracker is loaded. Could this have something to do with the crash? It would almost make sense to me.

Jazzmarazz
Very interested
Posts: 60
Joined: Wed Mar 12, 2014 11:11 pm
Location: Michigan
Contact:

Post by Jazzmarazz » Wed Oct 01, 2014 1:35 am

I just got that too! I have been using Fusion all along, but without a BIOS file.The time in which it takes to change into your font may be the same amount of time when I mentioned " the TMSS will flash" and freeze with the TMSS showing.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Wed Oct 01, 2014 1:42 am

If it's not poor emulation, and if the same thing is happening on real hardware then that would basically mean that my palette and font is loaded into VRAM before TMSS is complete. Which makes debugging very interesting.

Jazzmarazz
Very interested
Posts: 60
Joined: Wed Mar 12, 2014 11:11 pm
Location: Michigan
Contact:

Post by Jazzmarazz » Wed Oct 01, 2014 1:44 am

Count SymphoniC wrote:If it's not poor emulation, and if the same thing is happening on real hardware then that would basically mean that my palette and font is loaded into VRAM before TMSS is complete. Which makes debugging very interesting.
Real hardware does not change to your font, but the TMSS does flash like on the emulator.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Wed Oct 01, 2014 1:48 am

Yes, I'm saying that what if that attempt to load the font and palette too early is what causes the crash? Or maybe some register wasn't set up properly or something. I'm starting to think the problem is after the TMSS check and before the palette is loaded in my code.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Wed Oct 01, 2014 2:12 am

TMSS needs 1 thing :

You need to have "SEGA" or " SEGA" at $000100 in the ROM. When it finds that it will show the TMSS message and jumps to the entry point of the ROM which is stored in $000004.

Rest is up to you, if there's a crash it will happen regardless of TMSS.

Possible food for thought : http://www.tmeeco.eu/BitShit/PONG!RAM.ASM
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Wed Oct 01, 2014 2:29 am

The TMSS is thusly satisfied then. Meaning I'm going to have a real trick debugging this crash. I'm taking a look at that source in that link you posted and am impressed, it seems to me that the rom header can be nearly trashed and still work fine as long as SEGA is there. Really impressive is Pong with no ram too.

Regardless, it hangs while still showing the TMSS meaning the problem code is early on.

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Wed Oct 01, 2014 4:17 am

Take a look at your VDP regs initialization. It's probably not a good thing that you're enabling DMA for no reason. Regardless of that, you can crash some systems by writing the DMA regs and NOT triggering DMA.

If you really want to init the DMA regs (and you probably shouldn't touch them unless you are definitely doing DMA), VDP reg 23 should be written as $80. See Eke's post about this issue.

You're also inadvertently writing to undefined VDP reg 24 (careful with those dbra loops). This might be tolerable, but no point in risking it. You're also enabling external interrupts (L2 INT) via VDP reg 11, which might be harmless but there's really no point.

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Wed Oct 01, 2014 5:08 am

Thanks for the useful information friend. I corrected the issues you mentioned, and now after reading some of those posts have a feeling there will be more even once this gets running on real hardware.

Well... here goes nothing.
https://www.mediafire.com/?l8dsi6pyiosyeqh

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Wed Oct 01, 2014 7:44 am

You should check this topic, i also experienced issues when dealing about TMSS on various system :
viewtopic.php?t=1849&highlight=tmss

Post Reply