[saxman]

What I have here is a version of Sonic 2 that doesn't use the vertical interrupt at all. It instead relies entirely on the horizontal interrupt to do both page and line code.

Here's the source code and ROM:
http://uploading.com...4f1c1/s2hint.7z

I have an issue with the horizontal interrupt timing though. I have battled with this for a while now, and I cannot for the life of me figure out what is going on. I've read every VDP document known to man, many times over. I've debugged the heck out of my ROM.

In Regen, set a breakpoint for a write to address FFF520. Go to Aquatic Ruin 1. When the debug window pops up, you can use this guide to see what's going on:

D0 = current VH pos
D2 = previous line interrupt VH pos
D4 = previous page interrupt VH pos
D5 = interrupt count
D6 = Hint_counter_reserve value
D7 = interrupt type (0 = first page, 2 = page, 3 = line)

The interrupt count (D5) will tally up how many times an interrupt has occurred when the Hint flag (Hint_enable) is on. Take a look at when D5 is equal to 0x5E:

D0 = DF17 (this interrupt has occurred on line DF)
D2 = DF79 (previous line interrupt occurred on line DF)
D4 = DF76 (previous page interrupt occurred on line DF)
D5 = 005E (interrupt number 5E)
D6 = 8ADF (reserve DF)
D7 = 0002 (do a page interrupt)

Now take a look at when D5 is equal to 0x5F:

D0 = E6A6 (this interrupt has occurred on line E6)
D2 = DF79 (previous line interrupt occurred on line DF)
D4 = DF77 (previous page interrupt occurred on line DF)
D5 = 005F (interrupt number 5E)
D6 = 8ADF (reserve DF)
D7 = 0002 (do a page interrupt)

The problem here is the 5F interrupt is occuring when the VH pos (D0) is E6xx. It should never be anything higher than DFxx. Everything is working up until this frame. But when you look at the Hint_counter_reserve (D6), it still says 8ADF.

Naturally, I begin to think that somewhere else in my code register 10 is getting changed. However, I can't figure out where. I can't figure out how. Unfortunately, Regen can't trace writes to the VDP registers which would probably be the key to this whole thing. All I can figure out so far is having an interrupt at E6xx is wrong!

Here's what the problem looks like in the game:


If the H-int timing gets thrown off as demonstrated earlier, then the game will do what it's doing in the video.



I've been trying to fix this for a month now. Is anyone out there willing to take on the challenge and see if they can get the H-int timing working properly? I know it's a challenge, but I'm hoping some of you will like the challenge and what to take a crack at getting the H-int to handle everything as intended.

This post has been edited by saxman: 15 November 2012 - 02:39 PM

[MarkeyJester]

Pardon my ignorance, but isn't the a VDP register bit that needs to be cleared and set to start and pause the HV-counter, I'm pretty certain that I've read in a document somewhere that the HV-counter needs to be set to pause before you can read from the counter effectively, whether this is true or not though is something I have yet to see, I just thought I'd mentioned it as it's relevant.

Edit: another thing to note (which is the reason for your water line being all over the place) is that when you've set it to write the underwater palette data to CRAM, you changed the H-blank scanline register so that the next occurance will be at the bottom of the screen, which makes sense, the problem here is that it will not take effect until H-blank has occured once again, I.e. if the occurred scanline is at say 0x20, and you change it to 0x50, it will NOT occur next time at 0x70, the 0x50 does not take place yet, so it runs through another 0x20 reaching it to 0x40, THEN 0x50 will be taken into account, and the next occurrance will be at 0xB0, when setting the H-blank register, there's always a delay before it gets taken into account.

This post has been edited by MarkeyJester: 15 November 2012 - 04:55 PM

[saxman]

MarkeyJester, on 15 November 2012 - 03:24 PM, said:

Pardon my ignorance, but isn't the a VDP register bit that needs to be cleared and set to start and pause the HV-counter, I'm pretty certain that I've read in a document somewhere that the HV-counter needs to be set to pause before you can read from the counter effectively, whether this is true or not though is something I have yet to see, I just thought I'd mentioned it as it's relevant.

Edit: another thing to note (which is the reason for your water line being all over the place) is that when you've set it to write the underwater palette data to CRAM, you changed the H-blank scanline register so that the next occurance will be at the bottom of the screen, which makes sense, the problem here is that it will not take effect until H-blank has occured once again, I.e. if the occurred scanline is at say 0x20, and you change it to 0x50, it will NOT occur next time at 0x70, the 0x50 does not take place yet, so it runs through another 0x20 reaching it to 0x40, THEN 0x50 will be taken into account, and the next occurrance will be at 0xB0, when setting the H-blank register, there's always a delay before it gets taken into account.

I'm not aware of documentation saying you have to pause the HV counter. I know they mention it when using the level 2 interrupts, but to my knowledge it isn't required for reading the counter. Of course, maybe you're right and I've overlooked this.

When the DoPageInt section runs, it runs the RunPageInt code (the old V_Int, now called PageInt), and then follows this with the SetPageInt where it subtracts the Hint_counter_reserve line from DF, effectively setting up the next page interrupt that will follow the upcoming line interrupt.

When the DoLineInt section runs, RunLineInt code runs (the old H_Int, now called LineInt), and it is followed by SetLineInt where it simply sets register 10 to the Hint_counter_reserve line, setting up the next line interrupt that will follow the upcoming page interrupt.

I think you may be following my code wrong. You're right that there's a delay, because the internal counter will refresh immediately when the interrupt occurs, so what I want that value to be must be set between the current interrupt and the previous interrupt. But I've followed my code through the debugger, and I'm fairly certain it's doing this correctly. Or, maybe I'm just misunderstanding you?

This post has been edited by saxman: 15 November 2012 - 05:29 PM

[MarkeyJester]

Maybe, either that or I'm misunderstanding the problem entirely, sorry if I am.

I gave a go at altering a few things, and this is as far as I could get with the limited time that I have:

http://mrjester.hapisan.com/s2.rar

The graphical issue with the water no longer occurs, but there is major lag when the water reaches near the top of the screen (because of its reoccuring on every scanline I'm sure).

One question though, why are you trying to make a Sonic 2 game that doesn't rely on V-blank? Is it simply a proof of concept or is there an inside reason I'm unaware of?

[saxman]

MarkeyJester, on 15 November 2012 - 05:38 PM, said:

Maybe, either that or I'm misunderstanding the problem entirely, sorry if I am.

I gave a go at altering a few things, and this is as far as I could get with the limited time that I have:

http://mrjester.hapisan.com/s2.rar

The graphical issue with the water no longer occurs, but there is major lag when the water reaches near the top of the screen (because of its reoccuring on every scanline I'm sure).

One question though, why are you trying to make a Sonic 2 game that doesn't rely on V-blank? Is it simply a proof of concept or is there an inside reason I'm unaware of?

It looks correct. However the obvious side-effect is the lag. The lag may be due to the page interrupt occuring at the wrong place. There's a loop inside the RunPageInt section that forces it to wait until the VH counter has reached E008. This resolves issues with the sound lagging, and is also point at which a V-int would occur according to documentation. The main reason though is to keep the sound from lagging. But when the page interrupt doesn't occur at the bottom of the screen, the game is forced to wait until line E0 is reached. I wonder if when you take that section out if it'll throw out interrupts everywhere or not. Either way, I am curious as to what you changed.

I've been working on a project since February, and one of the requirements is for the game to never use the V-blank. Because I haven't announced the project publically, and because the reasons are very specific in nature, I can't really say more than that. But doing away with the V-int and having the H-int handle it instead is a must.

This post has been edited by saxman: 15 November 2012 - 06:03 PM