32X VDP going crazy with my attempts to draw

[saxman]

It's no wonder it has problems... you aren't saving r0 or r2.

Close. It is saving the R0 register in 'main_irq'. However, I completely missed R2. Fixed. Thanks!

Static is only for LOCAL variables. This MUST be a global variable.
"volatile unsigned int variable_name;" and this must not be inside a function, but in the main body of the code. I.e., a global variable.

That makes so much more sense now. I'm exclusively a Java developer in my profession, and in Java, part of the way in which a variable becomes "global" (actually class scope, but it's close) is by marking it "public static". I'm actually pretty rusty with C and C++ as I haven't actively used in in many years now. So I was *really* confused about why you insisted it wasn't global. But having thought on it some, I'm now on the same page. Another easy fix.

And so with the two aforementioned fixed, it looks like the FPS counter is working now ...

32x_06.png (2.05 KiB) Viewed 17757 times

Although it's oddly only settling on values like 15.0, 20.0, 30.0, etc. Maybe that's just a problem with my math/logic. I'll have to review that again. But I'm certain it's correctly updating the vblankCount value (middle one in the screen shot), and that's what I care about most at this point in time.

Thanks for your patience and help. And now I'm back to making the greatest thing since sliced bread (if sliced bread was for the 32X).

[Chilly Willy]

That makes sense if you're rusty on C/C++. Static in C/C++ makes a local variable hold its value between calls to the function. So it's a like a global in that it always exists and holds its value, but it's still local to the function where it's defined.

My standard method of doing FPS is to increment a global each time the event occurs (a frame is drawn, for example). Then in the main timing code (maybe the vert blank int), I check if a second has gone by, and if so, copy the global to another variable that represents the displayed FPS, and then clear the event global count. That makes the FPS update once per second with the FPS for the previous second. It's really simple and fast.

[Vic]

Although it's oddly only settling on values like 15.0, 20.0, 30.0, etc.

If your frame lasts than 1 vbl, you program is going to run at 60fps on NTSC. At 2 vbls, you get 60/2 = 30fps. At 3 - 60/3 = 20FPS, at 4 - 60/4 = 15FPS. Unless you're averaging your tic values like Chilly has suggested, you're only going to get 60/X on your FPS meter.

[Vic]

One of the more recent discoveries that I've made is that aligning the mov instructions on longword boundary does make a measurable impact on performance. Especially in the tight drawing loops.

[saxman]

This board doesn't have much activity these days. I hope this post gets seen by someone...

I'm trying to understand how to draw 32X graphics in front of the Genesis VDP output. I currently have no tiles mapped to the Genesis VDP. So it's a blank screen with a green background. I write 0x0000 words to the 32X VDP (which is white), thinking that I'll see green poke through the 32X frame buffer. But instead, I just get the white. And I tweak the priority bit, thinking that I must have it set wrong, but it's not affecting it.

I've read through much of what the "VDP Registers" section says in the 32X Hardware Manual. There are parts that read like Greek to me, especially the "Priority" page (I have absolutely no idea what those pictures are trying to communicate, and the text isn't any better). I'm thinking I'm just misunderstanding how this is supposed to work and the answer I'm looking for is getting lost in translation.

Does anyone know what I might be doing wrong? Does it require tiles be placed on the Genesis display to get rid of the white? That sounds counter-intuitive, but I'm just about out of ideas.

[cero]

I don't do 32x, but I remember seeing somewhere that it considers zero transparent. Try some non-zero value. edit: Sorry, re-reading it you want the opposite.

[saxman]

I just thought of something: palette definitions have a priority bit. That's probably what's giving me trouble. I'll have to play with it later when I have some time.

I still think the hardware manual could be a little clearer. I might have picked this up sooner.