SpritesMind.Net

Indeed you would think VDP code of 2 is likely a bug by programmers. Chaos Engine seems to write a lot using code 2 just before the character select screen, but then does complete CRAM/VRAM writes to setup the screen after that. Sort of like whatever is happening with code 2 is a mistake ...

Thanks for the information Nemesis. I implemented it as you have said and it seems to be functioning fine. I guess that explains why there is an EMPTY flag on the VDP, it means you can check it before you do a ctrl write and know whether the 68K will be locked.

I did a quick test and Outrunners ...

Ok, so here is how I am currently emulating VDP writes/reads upon some reflection and testing. It may interest some of you, I don't know if it's 100% correct but there are no issues in any game I have tried. RetroCopy's VDP is run at the cycle level, so if my timing is off even slightly there are ...

If you simply write the data then Bonkers is fine. It's only when you have the possibility of the 68K still running and the FIFO is being processed in real time will you hit this bug. As far as I'm aware only RetroCopy works in this manner.

I don't know about having two separate "user" cycles, the ...

Well someone on SMSPower mentioned the fact there shouldn't be THAT much difference on the reset lines, but it seemed enough on the SMS end to give you different enough R values on the Z80. When it comes to the MD I guess it's a question of where does the VDP start upon power on. Maybe its vcounter ...

On the intro, that would make sense. I just implemented a random line counter for startup (which I guess the real system is roughly doing) and I got a variety of different intros, nice! Why do you only do a random line start on soft reset in Gens-GX ?

Well I don't think they could be buffered like the SMS, since there is little information on this (ie double reading or waiting upto max cycles after a write) you wouldn't think it's buffered. They make sure to tell you that in the TMS manual.

However the other thing to consider is my memory timing ...

Yeah it's just interesting to see that Gynoug looks better with the "incorrect" emulation. Something that would be hard to notice unless you had played the game on the real system.

One of my users reported that the MD game Bonkers had graphics corruption in RetroCopy so I took a look at it. RetroCopy's main aim is to emulate like hardware so I often run into weird bugs and undocumented areas. In this case VRAM reads. Bonkers seems to write to VRAM depending upon certain reads ...

Not sure if you have seen this EKE, but this video on youtube shows the gynoug scrolling issue. Seems correct with your new findings compared to forcing the partial column to the 0 entry.

http://www.youtube.com/watch?v=8pNGK1lDdIk

A possible theory is that sprites (16 or 20) are parsed (Ypos/Size/Link from internal RAM then Xpos/Name/Attr from VRAM if sprite is "on the line") during HBLANK (or more exactly as soon as Vcounter is incremented), but one line before the line they are intended to be displayed (the VDP ...

Yes it was a bug. When I was updating the length registers after a DMA I was sending the cached write before that, so if one of them was a reg 19 write it would be overwritten with 0 after the DMA, thanks for your help Eke.

What should you do with DMAs that aren't set up correctly, ie VBUS DMAs ...

This is the state when the DMA is sent :-

addr = 0x4922
code = 1 (vram write)
reg0 = 0x14
reg1 = 0x34 (display off)

reg19 = 0
reg20 = 0
reg21 = 0xcf
reg22 = 0x87
reg23 = 0x7F

therefore :-
dma_address = 0xff0f9e
dma_length=0 (so 0x10000 words)

If the screen is blanked for 2-3 frames wouldn't this ...

Since I am using Musashi I needed to handle the case where this happens as it ruins the game display otherwise and Musashi runs on instruction granularity, not cycle.

Then why do you have "cycle accurate" claims all over your site?

I think you are mistaken as I have never claimed the Megadrive ...

What I am doing is using a cycle count for 68k and a main cycle count for VDP events (line/frame). The main cycle count is incremented by 3420 cycles per line and, as long 68k current cycle count is above the wanted main cycle count, no cycles are executed but other chips (incl. VDP) keeps running ...