TMSS help.

Jazzmarazz · Post by **Jazzmarazz** » Wed Oct 01, 2014 9:55 pm

Count SymphoniC wrote: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

Still changes the font in an emulator and hangs on real hardware. Keep trying pal! I bet you're close.

Count SymphoniC · Post by **Count SymphoniC** » Wed Oct 01, 2014 9:58 pm

Jazzmarazz wrote: Still changes the font in an emulator and hangs on real hardware. Keep trying pal! I bet you're close.

There was something I read in another thread around here that caught my attention. This may be related to the problem. I'll work on it in another hour or two, after I get some of this code working to read my new and improved compact arrays haha.

Also, thanks for continually testing. I tried to get a Genesis of my own today but luck wouldn't have it.

Jazzmarazz · Post by **Jazzmarazz** » Wed Oct 01, 2014 10:15 pm

Count SymphoniC wrote:
Jazzmarazz wrote: Still changes the font in an emulator and hangs on real hardware. Keep trying pal! I bet you're close.
There was something I read in another thread around here that caught my attention. This may be related to the problem. I'll work on it in another hour or two, after I get some of this code working to read my new and improved compact arrays haha.

Also, thanks for continually testing. I tried to get a Genesis of my own today but luck wouldn't have it.

Genesis or not, you would also need to have a flash cart.

Gonna PM you over at CMo real quick...

Count SymphoniC · Post by **Count SymphoniC** » Thu Oct 02, 2014 12:49 am

Well it's probably been more than a couple of hours. I managed to get my array drawing routines working for reading my new arrays and displaying their data to screen, but I can't test their functionality 100% until I fix a crash I'm having. There's alot of variables involved that tie in to this so I have to rewrite more code until everything is back to consistent form. It'll take a while for sure.

One possibility for the crash on real Genesis I believe had something to do with the timing between writing to the control port and then to the data port, I'm not sure why that would cause a crash, but it apparently would cause tile drawing to fail sometimes. I'm not sure that's the issue, but I was going to investigate it anyways.

I know you did a checksum fix, but I haven't really put the checksum in the header, I don't know if that matters though. Another issue may be the starting and ending ROM address. If you open up the rom in a hex editor you'll see there is blank data at the end, although once more I'm not sure that would be a real issue, but it could be. These are all things I'd like to investigate. Maybe the TMSS needs time before we start writing to the VDP? That's something I'd like to try right now. So hang on a moment. Maybe I can get it to wait before drawing stuff to VRAM.

Count SymphoniC · Post by **Count SymphoniC** » Thu Oct 02, 2014 1:04 am

https://www.mediafire.com/?u1juo2h3j6rwfr5

In this test version, I put a loop counter that gives it an extra few seconds before beginning the main program. It still shows the font changes in the emulator, so I suspect this won't work. The next thing I'll try is fixing the ending rom address.

TascoDLX · Post by **TascoDLX** » Thu Oct 02, 2014 1:56 am

Count SymphoniC wrote: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

You slightly missed the point about the DMA regs. The last register must be set to $80 unless you are setting up a transfer. This is an issue regardless of whether DMA is enabled.

BUT, there's still no point initializing the DMA regs unless you're doing something with it. So, just change the loop count on your VDP regs loop from $17 to $12. You don't even need to worry about removing the extra 5 reg bytes.

Count SymphoniC · Post by **Count SymphoniC** » Thu Oct 02, 2014 2:12 am

I misunderstood then.

The first link is with the loop count set to 12 https://www.mediafire.com/?ffaa00nfrm05k4k

The second link is with register 17 set to 80 https://www.mediafire.com/?t7gx8ovfokdxdb3

All the dma regs were initially set to 00 anyways so maybe I'm still misunderstanding but wouldn't setting the loop count down to 12 mean they're still set to 00? I posted both test roms just in case...

Jazzmarazz · Post by **Jazzmarazz** » Thu Oct 02, 2014 2:53 am

Well, I have good and bad news.

The good: Both ROMs work
The bad: Both ROMs work

How can you tell which was the fix if they both work? :S

The font seems to look terrible on my screen, but the TMSS looked more or less clear. I don't know if its the HD resolution or the contrast between your color palettes.

Sadly I had to toss my CRT when I moved.

Count SymphoniC · Post by **Count SymphoniC** » Thu Oct 02, 2014 2:59 am

Thanks so much for testing. Maybe they're both the fix haha. I haven't a clue why the font looks like that... Is it really as pixellated as it looks?

Btw, I had a look at your disassemblies, and noticed you like to keep spare parts. I have an HP stereoscopic 3d monitor 1920x1080, that recently quit working due to a lightning strike (the neighbors claimed it hit our tree, although the strike was about that close, the tree looked fine to me

) You think that might be something you'd be interested in? Or is it good as trash?

Jazzmarazz · Post by **Jazzmarazz** » Thu Oct 02, 2014 3:11 am

Count SymphoniC wrote:Thanks so much for testing. Maybe they're both the fix haha. I haven't a clue why the font looks like that... Is it really as pixellated as it looks?

Btw, I had a look at your disassemblies, and noticed you like to keep spare parts. I have an HP stereoscopic 3d monitor 1920x1080, that recently quit working due to a lightning strike (the neighbors claimed it hit our tree, although the strike was about that close, the tree looked fine to me ) You think that might be something you'd be interested in? Or is it good as trash?

Yes, my TV displays it THAT pixelated. that is my 32" Tv and surprisingly, my 50" doesn't have composite video input! WTF?

I would pop open the monitor and check the power board. More often than not a few caps popped. I have repaired one that had a broken CCFL tube and in hind sight I would rather have tossed it out. I am still using it in front of me right now, but what a pain that was. Worst case, you can always sell it on ebay for parts/not working. THE LCD components may be perfectly fine.

TascoDLX · Post by **TascoDLX** » Thu Oct 02, 2014 3:28 am

Jazzmarazz wrote:Well, I have good and bad news.

The good: Both ROMs work
The bad: Both ROMs work

How can you tell which was the fix if they both work? :S

Well, they're sorta both the same fix. Writing the last VDP reg (#23) sets the DMA control state of the VDP. It's just that writing $80 doesn't change the state, so it's pretty much the same effect as not writing it at all.

My recommendation is to not write the DMA regs unless you're explicitly setting up for DMA.

Eke · Post by **Eke** » Sun Oct 05, 2014 2:11 pm

TascoDLX wrote:
Jazzmarazz wrote:Well, I have good and bad news.

The good: Both ROMs work
The bad: Both ROMs work

How can you tell which was the fix if they both work? :S
Well, they're sorta both the same fix. Writing the last VDP reg (#23) sets the DMA control state of the VDP. It's just that writing $80 doesn't change the state, so it's pretty much the same effect as not writing it at all.

My recommendation is to not write the DMA regs unless you're explicitly setting up for DMA.

I think the reason for this is that b7 and b6 in DMA source address register #23 actually indicate the source type:

bit7: 0 = external (68k bus interface), 1 = internal (VDP)
bit6: 0 = write FIFO (VRAM Fill), 1 = read Buffer (VRAM Copy) if source is internal to VDP

My theory is that when you set the DMA circuitry to use the external 68k bus as DMA source, some signals on 68k interface (!AS, !RW, ...) are changed from input to output before DMA is actually started (and 68k tooked out of the bus) and under some unknown conditions or VDP later access, this will screw up normal 68k processing.

This is also probably similar reason why tech bulletins advised to run the code that triggers DMA from RAM (RAM control signals being handled all the time by the VDP itself).