SpritesMind.Net

Regarding the code of sonic 2 what is the interest to wait Hblank flag is set to 1 because when H-Int procedures start we are in hblank?
Perhaps there is a short delay between firstly H-Int trigger and then Hblank start (Hblank flag set to 1)?
In all case 68k neeeds ~ 44 cycles to start first instruction so theres is a big probability that we are already in hblank ...

Do you now what i mean?

I don't know, I think Hsync is more used to trigger some execution on a specific line, it might not be such precise and it's probably better to poll the flag to be sure we are in HBLANK period

for example, you could have the 68k executing a MUL instruction (which take LOT of cycles) when the H interrupt occurs, and the execution of Hint could be delayed way after the HBLANK period

Yes I see what you mean, I understand the utility now
I will continue my work this week end
Thank you eke for sharing all your precious knowledges

Another thing :

In genesis plus, when border color is modified during Hblank you make a remap of the current line.

But if Cram is modified between the moment the line is rendered and the moment the border color is changed the Cram change will be taken in account?

what do you use to disassemble the rom?

I use ReSource for the Amiga to do my 68K disassembly. Of course, I'm running the "Amiga" via e-uae in linux these days rather than an actual Amiga. ReSource is really great for 68K disassembly.

I just got through using it to disassemble the multi-loader code from the MD-Pro to figure out how it works (that and the ucon64 code).

TmEE co.(TM) wrote:There's quite a bit of flicker on real HW, but on last line of the separation bar. I don't recall flickering on 1st line... I need to pay more attention.

It's there. It's VERY, VERY difficult to see, though, because of the interlacing.

I bet this depends on when *exactly* display is disabled/enabled:
hblank flag could be read as set at the very end of the left border and the VDP could have have 8-pixels (1 cell) latency before effectively switching the display, which eventually happen during the start of active area...

does it seems possible ?

This week end i made tests with this timings.
All games seems to work correctly.

To resume :
- Line rendering at HBLANKSTART + 36 cycles 68k
- Correct c68k core. Now 68k return 44 cycles before executing first instruction. So the first instruction of interrupt process is executed at HBLANKSTART + 44 (After line rendering).
- During line, if display is switched ON/OFF I render the line again (takes effect immediately).
- During the display, if color border is modified, i remap color on the current line.

I just have a glitch on outrunners intro, when the SEGA logo is divided into two parts. The first line of the logo in the top is not drawed.
I must look at the reason why ...

This week end i made tests with this timings.
All games seems to work correctly.

To resume :
- Line rendering at HBLANKSTART + 36 cycles 68k
- Correct c68k core. Now 68k return 44 cycles before executing first instruction. So the first instruction of interrupt process is executed at HBLANKSTART + 44 (After line rendering).
- During line, if display is switched ON/OFF I render the line again (takes effect immediately).
- During the display, if color border is modified, i remap color on the current line.

I just have a glitch on outrunners intro, when the SEGA logo is divided into two parts. The first line of the logo in the top is not drawed.
I must look at the reason why ...

Eke wrote:maybe one of our two former genesis programmer here could tell us what timings they were told to use to do fast display modifications during HBLANK

Hey, nobody was told anything other than what was in the manuals. Which you've seen, right? It was basically just a case of 'try it and see, modify until it works'. Hell, I had to completely reverse engineer the multitap, because there was no documentation for that at all at the time

Do you think that was just a case of there being no documentation in English, or no documentation period? I'm just wondering if the Japanese programmers had better documentation and resources.

I did ask, because even in Japanese, it would have been useful. But apparently it hadn't been written up yet.

As to whether Japanese developers got better documentation, well, obviously they would get most of it first. But I usually got hold of (very bad) translations pretty quickly. I got quite good at reading this stuff As far as I know though, the final translated US documents were no worse than the original Japanese stuff.

I have another question about DMA Timings.
Is it necessary to emulate dma transfert line per line or making all the transfert at start of dma and set the status flag to 0 after necessary cycles is sufficient?

mickagame wrote:I have another question about DMA Timings.
Is it necessary to emulate dma transfert line per line or making all the transfert at start of dma and set the status flag to 0 after necessary cycles is sufficient?

For normal ROM to VRAM DMA, the CPU is locked while it happens anyway, so you could get away with doing it all in one go, as long as you also adjust the 68K cycles correctly. VRAM fill and VRAM copy don't lock the CPU. Then again, you can't write to the VDP while they are happening without breaking stuff - meaning it's pretty much guaranteed nobody will be doing that. So you could probably get away with doing it there, too.

If doing it line by line isn't a problem, though, I'd defintely do that, at least for VRAM fill and copy.

I'm trying to adjust my DMA Timings with sonic 2 but i have a problem because the display isn't switch off at constant line.
Sometimes it's disabled at line 107 or sometimes at lines 108.
So the blue bar isn't fix ...