Hey All,

Err... I'm kinda puzzled... :? I'm working on this little project, and am using a few VDP commands (mostly copy's and fill's) to speed things up a little. The strange thing is that these commands seem to get aborted from time to time. I really don't know why... I am ofcourse cheching CE of Stat reg #2 but still, *something* keeps interrupting my VDP commands. I really don't understand it! I'm puzzled to say the least.

I am running on R800 in a DOS2 environment, but as far as I knew the Engine took care of any R800/VDP speed issues. Am I wrong to assume this? Well... Anyways, I'm having the occasional missed copy (in my text routine) and am getting interrupted MMV and MCM commands. Any clues as to how I'm fucking up this time?

Thanks...

how do you know they're interrupted? Maybe you just gave bad parameters?

Because it only occurs sometimes... Most of the time the commands will execute correctly. Once in a while tho, a command will seem to get aborted. This for example means that a fill that should be 100x40 pixels will be interrupted somewhere in the middle, leaving only part to the box to be drawn... It's quite the pain, really...

well, it's hard to say something about this one... :/

Perhaps you're pumping too much data in a too short time-interval? I'm not sure at all, but 2 NOPs spring to mind...

Posting a (partial) source would really help here.

if you are executing a FILL command without the need of send each byte... surelly is not true than you are sending the data too fast, overall if you got a middle execute command.

3 THINGS.... first before all, and after all insert DI and EI commands. Because you need disamble the interrupt when you are sending commands to the coprocessor VDP.

and the other thing.... on R800 make sure of got the correct timing when you send the coordinates.

the Theerd thing is : you need wait to read a RESET value on BUSSY bit , before do nothing. If you don't do that, surelly you are overriding the work of the COprocessor during its work.

And other thing... for speed up your game you can do some graphics on VRAM direct writing at same time when the coprocessor are working..

Quote:

and the other thing.... on R800 make sure of got the correct timing when you send the coordinates.

No, the S1990 Bus Controller takes care of this.

Quote:

the Theerd thing is : you need wait to read a RESET value on BUSSY bit , before do nothing. If you don't do that, surelly you are overriding the work of the COprocessor during its work.

He said he did that. What you call BUSSY bit is called 'CE' officially.

Well, I'm under the impression you're allowed to OTIR to the VDP (You can even OUTI, so OTIR shouldn't be a problem) which is just about all I do... I've already planted a PUSHIX/POPIX between selecting status reg #2 and the IN to see if that was the problem. I even put NOPs between consecutive OUTs which shouldn't even be required since the s1990 already puts in massive waits... I'm really clueless here... I've got every single VDP routine checking CE before doing anything, and still... I get interrupted VDP commands... By now I've got my DI/EI's moved so far out they pretty much include every single OUT command. I really don't know what to do.

Could perhaps reading the mouse somehow have something to do with this? I really don't know anymore. Sigh... I would post a source but then you all are gonna poke phun at my assembly 'skills' so I'll just avoid that... I'll just see what happens... Maybe I can find something once I get to optimizing the code. I am *clueless* tho... Never had this happen before.

Quote:

I've already planted a PUSHIX/POPIX between selecting status reg #2 and the IN to see if that was the problem.

That's not necessary. AFAIK it's a myth that was brought into the world by Stefan Boer's VDP course. I never do ANY kind of wait between writing R#15 and reading the status port, and I don't see why it would be necessary.

We're as much puzzled as you are, probably
Even though you're afraid to be laughed at, posting some source would really help.

I know no waits are really required, much less a PUSH/POP IX... I'm just getting so darn desparate I don't even know what to try next... I guess I could post the parts of the source that use the VDP, but I'm guessing the problem isn't there. These are from lib's I've been using for years and have always worked fine. At first I suspected some newly coded LMMC/HMMC routines but these turn out not to be the problem since the graphic data is loaded fine onto the alternate page. The problem is a frikkin' copy! Even fills go wrong, I mean, what the hell can you do wrong with a fill?!?!

I don't know anymore... I guess I'm doing one more night of bug-searching and if I can't find anything... well... I guess the only thing left would be to post some sources here and be the laughingstock of the forum

if you want you can send me to my email the source i will check and made the needed corrections.... PLEASE ONLY THE VDP routines and INTERRUPT handle if you got that

you can see my email on www.mnbios.com.ar frontpage