Scaling hardware?

Ask anything your want about Mega/SegaCD programming.

Moderator: Mask of Destiny

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Jun 20, 2012 6:07 am

TascoDLX wrote:
Eke wrote:That's what I was doing before but it appeared it broke Willy Beamish Logo: see how it only rewrites reg 22 (and reg 23) but expects LSB to be reloaded with reg21 as well. If I leave reg21 to the final value it reached after previous DMA, I got those graphic errors.
I see what it's doing. But if the size of the previous transfer is 0x2800 bytes, shouldn't the low byte of the source address be the same in the end? You must be clearing the low bit or messing up the increment because of the wordram transfer issue.
Off course you are right... it's because of the way i handle the fact games set source address one word above the wanted address when doing dma from word-ram. At the end, the source address became incremented by one word less that it should have been :?
I have some idea how to handle this properly but I have difficulties understanding what hardware is really doing: why setting source address one word above would fix VDP slow read-out ? Does it mean the first word read is not read properly and instead written to the next VRAM address ? What about the last word ?

@Charles: i think that the point is that your docs actually are considered as THE references on that subject, hence why they are always cited as reference when someone discover something unknown with genesis hardware. I don't think it was meant as criticism, the way you discovered all these things (with a stock game genie right ?) is still amazing to me and always will. I also consider them as an example of how a technical doc should be written, i mean, accumulating testing notes is one thing but putting everything together in an intelligible and structured way is another thing and a thougher exercise, which is probably why you didn't see much (if any) similar published work...

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

Post by TascoDLX » Wed Jun 20, 2012 8:27 am

Eke wrote:I have some idea how to handle this properly but I have difficulties understanding what hardware is really doing: why setting source address one word above would fix VDP slow read-out ? Does it mean the first word read is not read properly and instead written to the next VRAM address ? What about the last word ?
Here's the theory:

Since the data always arrives too late, the VDP will go ahead and write whatever's already in its buffer (EDIT: or on the data bus, rather) (i.e., the previous read value). So, the first write will be garbage, the second write will be the first read value, the third write will be the second read value, etc. The last read value won't be written.
Last edited by TascoDLX on Wed Jun 20, 2012 11:02 am, edited 1 time in total.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Jun 20, 2012 10:51 am

Thanks, though i don't get why VDP being too slow for fast RAM would cause this, seems like what you describe is the opposite, i.e VDP reading bus too fast and word-ram being slow to put data on bus.

Anyway, so basically, if doing 0x80 words from $200000 to vram with VDP address register being set to $0000, vram $0000 with hold open bus data and vram $0002 to $00FF will hold word-ram $200000-$2000FD, while word-ram $2000FE-$2000FF will not be written anywhere but source address registers will still point to word-ram $200100.

I was pretty much emulating this. Only problem was that i was doing it by not incrementing the source address after the first write and it resulted in the source address registers being one step less than the expected value at the end of DMA. It should be fixed now.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Tue Jul 17, 2012 5:18 pm

Eke wrote:
Completely off-topic but I got some hard time emulating Snatcher. It hangs when I press start during the intro (the first displayed text message with blue background) and only after a very long time (something like 7000 frames or so when it should be quite immediate) the scene with Konami heardquarters is displayed, then it hangs forever on a black screen.
Have you (Stef or TascoDeluxe or anyone who worked on CD emulation) ever faced this issue ? I have trouble figuring what is causing this long pause between scenes and the lockup: MAIN-CPU seems to be running an infinite loop and only wakeup on VINT to refresh the screen with always the same setup while SUB-CPU main loop is only interrupted by CDD interrupt and only send TOC READ commands...


From what I've read on various forums, it seems like this game is VERY sensitive to the TOC so i faked audio tracks and got the intro running further (it indeed doesn't go further than the blue screen text if you only load an ISO without audio tracks) but as soon as I press START to skip the intro, same problems arise.

I found similar issues later in this game. Does not seem to be related to TOC either (no audio track is playing). It happens in the abandonned factory: on some scene transitions, the navigation menu takes a very long time to reappear (~60s instead of 2s comparing with other emulators), for example when I retreat to the piece where little john is standing or when I finish looking at him (see screenshot below) but it happens in some other scenes as well (factory entry, first time Gibson's body is dicovered, etc)

ImageImage

Notaz, Stef, is this something you ever faced ? any idea what the game engine might be waiting for to display the navigation menu ? from logging the game, I do not see anything anormal, SUB-CPU triggers a DMA from CD to PRG-RAM, it processes until the end then it waits for something... not sure what, probably some internal timer (Timer interrupt is triggered periodically and seem to be used for PCM timings)

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

Post by Stef » Wed Jul 18, 2012 9:29 am

I remember that indeed the game could lag or even freeze later, it was indeed at this portion. See the related discussions about this problem :
http://lparchive.org/Snatcher-%28Screen ... pter8.html
http://www.epforums.org/showthread.php? ... er-Problem
http://www.coolrom.com/forums/showthread.php?t=2083
http://www.rpgcodex.net/forums/index.ph ... ale.36083/
http://www.epforums.org/showthread.php? ... er-Sega-CD

But as far i remember it turns out to be a bad dump of the game or maybe a corrupted cue description (if you use it) :

http://forums.junkerhq.net/viewtopic.ph ... 4&start=16
Eke wrote: I found similar issues later in this game. Does not seem to be related to TOC either (no audio track is playing). It happens in the abandonned factory: on some scene transitions, the navigation menu takes a very long time to reappear (~60s instead of 2s comparing with other emulators), for example when I retreat to the piece where little john is standing or when I finish looking at him (see screenshot below) but it happens in some other scenes as well (factory entry, first time Gibson's body is dicovered, etc)

ImageImage

Notaz, Stef, is this something you ever faced ? any idea what the game engine might be waiting for to display the navigation menu ? from logging the game, I do not see anything anormal, SUB-CPU triggers a DMA from CD to PRG-RAM, it processes until the end then it waits for something... not sure what, probably some internal timer (Timer interrupt is triggered periodically and seem to be used for PCM timings)

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Jul 18, 2012 11:02 am

Thanks for digging all these old threads, it's interesting to read.
Unfortunately i don't think it's the same issue, at least, that's not at the same spot.
I knew about the freezing issue during the travelling sequence and it's indeed due to missing audio track / invalid TOC infos returned to the game. I don't have any lock here as the TOC is somehow hard-coded for this specific game, the issues i am mentionning are actually after this sequence, when exploring the ruin area, and i verified there weren't any audio tracks supposed to be played when it happens, also the problems do not occur in Gens or Kega, even when using a simple iso file without any audio tracks. I fear this must be a tiny bug in my own implementation and that you probably never encountered it yourself.

There is indeed some kind of tempo before the navigation menu is supposed to happen but it's only a few seconds on other emus. The code flow is a hell to debug though, as there are dozen of internal counters apparently used to trigger specific code events and i cannot figure which one is supposed to happen or why it takes so long to happen. There does not seem to be any missed interrupts either, on both side...

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

Post by Stef » Thu Jul 19, 2012 8:37 am

Err sorry i though it was the same problem.
As you said unfortunately i did not experienced your "bug".. do you use the same "read timing" as Gens or you tried to use shorter ones ?
I agree it is very difficult to trace the problem when the compatibility is already very good and the problem is not evident. Is it the only remaining game which meet that type of problem ?


Eke wrote:Thanks for digging all these old threads, it's interesting to read.
Unfortunately i don't think it's the same issue, at least, that's not at the same spot.
I knew about the freezing issue during the travelling sequence and it's indeed due to missing audio track / invalid TOC infos returned to the game. I don't have any lock here as the TOC is somehow hard-coded for this specific game, the issues i am mentionning are actually after this sequence, when exploring the ruin area, and i verified there weren't any audio tracks supposed to be played when it happens, also the problems do not occur in Gens or Kega, even when using a simple iso file without any audio tracks. I fear this must be a tiny bug in my own implementation and that you probably never encountered it yourself.

There is indeed some kind of tempo before the navigation menu is supposed to happen but it's only a few seconds on other emus. The code flow is a hell to debug though, as there are dozen of internal counters apparently used to trigger specific code events and i cannot figure which one is supposed to happen or why it takes so long to happen. There does not seem to be any missed interrupts either, on both side...

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Jul 19, 2012 2:26 pm

I use the same dma timing as in gens yes (512 bytes per line) since i could not figure what exact timings are. Anyway, that is the first thing i tried to change but incrementing or decrementing it did not change anything.

I kinda figured that the problem is actually caused by some flag (address $1511E bit 7) being set in prg-ram before specific scene change (for example when entering a new room or look at a specific object triggering a cutscene). If i wait too much time in current room, this flag is eventually being set and when i trigger the scene change, there is a loop waiting among other things for this flag to be cleared, which never happen (there is some kind of timeout though which breaks the loop after a long period). If i trigger the scene changes without waiting (for example, moving quickly through rooms or look immediately to specific object as soon as entering the room), the loop exit normally and navigation menu appears quite immediately. I verified that clearing manually this flag (using an input key for example) during a lock will also makes the navigation menu appears immediately.

I have yet to found which event sets or clears this flag. I suspect it might be related to PCM address pointers as there are some reads to pcm address $10 and $11 done in periodic int3 callback and the game seems to be waiting for them to reach a specific offset. The thing is, sometime pcm channel 0 address remains fixed because it apparently reached an infinite loop. Maybe i should update pcm chip on each line (i am updating it at the end of each frame actually) or more accurately in regard to PCM address pointer reads and current sub-cpu cycles ?

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Sat Jul 21, 2012 8:37 pm

Well, it appears it was indeed a PCM emulation issue. The game was locked waiting for a specific address being returned from the PCM RAM address pointers in order to continue. The error was that I was still incrementing the address after reloading it with loop address when loop data is first read, which is apparently wrong.

Note that all emulators that I have looked at (MAME, Gens; Picodrive) handle it like I was initially doing. It works in the two latter because they are interpolating the address increment to match wanted samplerate and need to post-process the entire waveform in case they missed any loop data so in most cases address will be properly reloaded...

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

Post by Stef » Sat Jul 21, 2012 9:25 pm

I missed your previous message, the bug was indeed very difficult to find...
Glad you figured it :) That explain the lag we sometime experience in Gens or Picodrive with this game.

Post Reply