Visible graphics problems on SGDK-based game

[mikejmoffitt]

I followed the new wiki setup instructions, and things are good, mostly. This is a pre-TMSS system, but it does not seem to cause issues. Sonic 1 works fine. However, a WIP build of my game has a lot of problems. Palette writes seem corrupted, as do writes to VRAM (be it through DMA or FIFO writes to the background plane tables). The game is built using SGDK.

A build for testing is included here, which has the problems:
http://csh.rit.edu/~moffitt/bin/lyle_test.bin

These problems manifest themselves as visible graphical errors, but the game runs perfectly fine otherwise. No crashing, the Z80 is happy as well as the 68000. I even switched my system to PAL mode, and behavior was the same.

I haven't tried a debug session yet, but I will be doing that soon.

[prophet36]

These problems manifest themselves as visible graphical errors

Have you tried this game on a real MegaDrive previously (e.g using a flash-cart), or have you only ever tested it on emulator?

[mikejmoffitt]

I've been testing on my Everdrive, which has been fine. I haven't burned it to an EPROM cartridge yet but I don't expect it to be particularly different.

[prophet36]

I've been testing on my Everdrive, which has been fine. I haven't burned it to an EPROM cartridge yet but I don't expect it to be particularly different.

OK that definitely sounds like a UMDK bug/problem. Anything that works on an Everdrive should work on a UMDK.

Can you give more detail about precisely which MegaDrive model you have? Do you have other models you can test with?

If you take an instruction-trace of the game running, do you see anything unexpected (e.g DMA cycles mis-reading from ROM, etc)? Does your game do any Z80-orchestrated audio playback?

Also, as a sanity-check, can you grab a logic-analyzer trace and upload it somewhere so we can see if there are any obvious hardware problems. Just follow the instructions in this post, but obviously load your game rather than Sonic. And make sure the trace you grab does actually include instances of graphic corruption. You can increase the log-size from 4096 to something bigger if you don't have enough time to get the game to that point.

I don't have my MegaDrive setup right now; can someone else give mikejmoffitt's game a try? I'm just collecting data right now so I'm interested in anything and everything.

[MintyTheCat]

I don't have my MegaDrive setup right now; can someone else give mikejmoffitt's game a try? I'm just collecting data right now so I'm interested in anything and everything.

I cannot see any issues. This means either I am not seeing them or it is MJM's UMDK hardware at fault.
I did start a project for UMDK Test-ROMs but I have not finished it. It may well be that there is an issue here.

What exactly do you see when you use the game with UMDK?

Trace is here:

http://www.filedropper.com/tracemmjlyletestumdklog

Game wise: Mike, on the first screen if the player dies you are not rewriting Plane-B's data so the cityscape in the background disappears when the player restarts.

Some of the coloured block Sprites do not reappear too once the player dies.

Let me know if I can help further.

[prophet36]

I cannot see any issues...trace is here:

That's great, thanks for testing. My theory is that since mikejmoffitt is using a US machine, the core clock speed will be slightly faster, so the DMA cycles are slightly shorter, and the UMDK memory-controller isn't quite fast enough to have the data ready in time during DMA cycles.

To confirm this it would be good for someone with a US machine to test mikejmoffitt's game.

So far I've deliberately tried to keep the VHDL simple by putting everything in just one 48MHz clock-domain. If it turns out that this corruption is caused by the memory controller being slightly too slow on US machines, the only way to fix it that I can see would be to decouple the memory-controller into a separate, faster clock-domain (perhaps driven by a simple x2 clock-multiplier, giving 96MHz, although [perhaps counter-intuitively] the optimal speed may turn out to be slower, because everything is constrained by the SDRAM's timings).

If someone else wants to have a go at this, I put some tweaks into the memory-controller a couple of years ago, to run with 6 cycles @72MHz per read/write operation (rather than 4 cycles @48MHz). This work is on a separate branch "cyc6" in the mem-ctrl project.

[MintyTheCat]

To confirm this it would be good for someone with a US machine to test mikejmoffitt's game

I have a genuine US MD2 on the way but as I stated, we need a pool of testers to get a pool of test hardware so that we can be sure.

I will be adding a database to my site soon enough for this purpose.

[TestSubject06]

I have a genuine US MD2 on the way but as I stated, we need a pool of testers to get a pool of test hardware so that we can be sure.

I have a US MD1 TMSS model(pretty sure it's a va6), and if everything goes well I'll have my umdk up in a week or so.

[MintyTheCat]

I have a genuine US MD2 on the way but as I stated, we need a pool of testers to get a pool of test hardware so that we can be sure.

I have a US MD1 TMSS model(pretty sure it's a va6), and if everything goes well I'll have my umdk up in a week or so.

It has been on the cards for a while but we have had a chat today. We will have a single point of reference used for the results of testing.

So if the users of UMDK who wish to contribute could work out what hardware they have that can be used for UMDK testing then we will be asking them a bit later for their lists to add to the wiki page. The page will be part of the UMDK GitHub accordingly to Chris. I also put forward the idea to have a UMDK Google-Group so that users can submit their results when they run their work with UMDK.

Something simply like in the subject like "UMDK HW Compatability Result" will be fine.

[mikejmoffitt]

This is what my VA3 Genesis is doing.

https://www.youtube.com/watch?v=cQzWmJzCJcQ

On mswan's system (A VA6) it runs a lot better, but there is still a small amount of visible speckling and occasionally faulty tile writ

Game wise: Mike, on the first screen if the player dies you are not rewriting Plane-B's data so the cityscape in the background disappears when the player restarts.

Some of the coloured block Sprites do not reappear too once the player dies.

That's not a problem - the game does not expect to load from the same room into the same one agian, as it should not happen in a normal game. The game restarting is a quick hack I inserted so if the player dies the console does not need to be restarted. It's a bug, but a consequence of a hack - working as expected.

[MintyTheCat]

This is what my VA3 Genesis is doing.

https://www.youtube.com/watch?v=cQzWmJzCJcQ

On mswan's system (A VA6) it runs a lot better, but there is still a small amount of visible speckling and occasionally faulty tile writ

Game wise: Mike, on the first screen if the player dies you are not rewriting Plane-B's data so the cityscape in the background disappears when the player restarts.

Some of the coloured block Sprites do not reappear too once the player dies.

That's not a problem - the game does not expect to load from the same room into the same one agian, as it should not happen in a normal game. The game restarting is a quick hack I inserted so if the player dies the console does not need to be restarted. It's a bug, but a consequence of a hack - working as expected.

I am trying to work out if this is a UMDK issue or your game logic playing up.
We know that incorrect tiles appear when the player dies and that is game logic at fault that you have clarified as a working hack.
We still need to work out if and how UMDK is at fault or not, then we need to determine if it is UMDK's design at fault or if it is the hardware that you are using - we do know that the chinese manufacturer did not produce perfect work as I recall the issue Montserrat had for one.

I had hoped to circumvent these issues by using an automated manufacture process.

I see it as:

1. OS issue - subtle but could be an issue - a fair test would have everyone using the same OS version for testing.
2. MD Hardware version issue.
3. MD region issue.
4. UMDK design issue.
5. Game Logic issue that leads to some kind of issue that you see visibly on screen.

We'll draw up a tester pool and hardware list to help resolve some of these unknowns.

Cheers.

[Montserrat]

Yup, that's was the weird graphical issues i have withmine too, but not only in my code. It happens in some games, like streets of rage and megaturrican. I tought that was a md1 hardware problem, like a capacitor or something...but seems that is the umdk...

Also noticed that this do not happens in the nomad...or may be the screen is to tiny to notice...

[mikejmoffitt]

Okay, so I did some testing and found some commercial games with the exact same problem. Sonic 3 has Sonic's sprite tile data loaded into VRAM whenever his frame changes, and there are similar speckles of wrong data in place, indicating a DMA corruption. Interestingly the palette data is rewritten every frame, but there are no problems there.

Sonic 3D Blast has background tile corruptions, though they are static since they aren't being transferred repeatedly:

[mikejmoffitt]

mswan's UMDK kit works and produces the exact same problems that mine does with regards to minor corruptions in DMA transfers.

[Montserrat]

Also...did you notice some sound problems? like some random note out of nowhere? i get this from time to time.