SpritesMind.Net

Comm between Genny and SuperVDP seems nice now.
Now debugging A-PLANE.
Then, the full-screen scroll. It will wipe several instructions, so it's gonna be even faster !
Well ... on GENS ! :D

ob1 wrote:Comm between Genny and SuperVDP seems nice now.
Now debugging A-PLANE.
Then, the full-screen scroll. It will wipe several instructions, so it's gonna be even faster !
Well ... on GENS !

Faster on Gens result in faster on RH too, as soon it'll work

For now, I can't plan on coding with Kega, since it hasn't got a debugger.

I don't know if Snake still is around on this forum, but if you talk to him about this he might be able to help you out.

Just debug it like you would on real hardware... with logging. Just print to the screen at key places in the code.

Chilly Willy wrote:Just debug it like you would on real hardware... with logging. Just print to the screen at key places in the code.

I've never done it before (I LOVE KMod), but I guess that's what I'm left to do ;)

Edit : I guess that's what they call the hard way.

Enfin ... c'est là qu'on voit les hommes ! @copy; Nelson Monfort

There's another way to debug without a built in debugger - posting code for others to look over.

Anywho, you might double-check all your alignments - the SH2 is slightly more picky about alignments: the 68000 needs word alignment on words and longs, but the SH2 needs word alignment for words and long alignment for longs. If you have longs trailing a bunch of words, maybe you wind up on a word boundary instead of a long boundary. Emulators are notorious for ignoring those kinds of errors for better speed; so one emu may let longs on word boundaries slide while another doesn't. If you're more used to MD programming, you might also ignore such an issue since you're used to looking for only word boundaries, not long boundaries.

Oooooooooooooo Kkkkkkkkkkkkkkkkk !

It runs on Kega.
I just forgot to clear H INT.

So it was just a H Int problem, nice you fixed it
Strange that it worked on Gens though.... maybe an exception not handled by Gens 68K core...

ob1 wrote:I've never done it before (I LOVE KMod), but I guess that's what I'm left to do

if it runs at 30fps in KMod, it will run even faster!

@Stef : it's more a 32X problem I guess. On Gens, it seems that you don't need to clear the Clear register before returning from exception. On Kega, it's mandatory.
@Kan' : well, I had to fix it a little bit and I can't reach anything higher than 25fps (PAL 240) or 27fps (NTSC) on Kega, 28 and 30 on Gens.
Still not that bad, but room for improvement, innit ?

The real deal here is A-Plane (foreground and transparency). Writing each pixel byte per byte takes foooooooooooorever. 34 instr / 16 pixels, not higher than 47fps (NTSC) alone.
With the B-Plane (background, no transparency), I hit 21 instr / 16 pixels, 61 fps (NTSC).
Computing the scrolling isn't that expensive.
NB : 25 instr for a transparent tile line, 42 for a solid tile line => 33,5 instr avg, if 50% of the A-Plane are fully transparent

Oh, and about my fears when I started this project.
Contention doesn't seem to be a problem. Or the emulators don't pay attention to it.
Concurrency isn't a issue either.
I haven't tested cache influency extensively. I don't know if Kega uses it.

320 * 112 / 16 * 21 instr for B-Plane, then 320 * 112 / 16 * 34 for A-Plane = 47 040 + 76 160 = 123 200 instr / frame.
And with 27 fps, I reach 3.33 MIPS @ 23MHz. I don't know it it's that good, or even if these numbers have a meaning.
NB : 112 lines since each CPU draws only a half-screen for both planes.

Anyway, I guess it's time for showtime.
And even if there are some graphical glitches to fix,
even if the comm should allow noDMA,
even if there's just one scrolling mode (line H, 2-cell V),
here it is :
http://www.valpocl.com/SuperVDP/

The numbers you see in white are for Kega (no Kmod ;) , thank you Chilly) and are the Comm Port :
- comm from the Master
- number of frames drawn by the Master
- comm from the Slave
- number of frames drawn by the Slave
- comm from the 68k
- this page intentionnaly left blank ( :D )
- SuperVDP register
- vTimer

NB : no vSync on this version.

No source yet : I'll publish 'em when it's fixed.

Doesn't work on real hardware... unless the screen is SUPPOSED to be solid black.

EDIT: Ran it in Gens/GS to see what it's supposed to look like... pretty funky man.

www.valpocl.com/SuperVDP

fixed
2 planes
30 fps
~600kB of sprites

Shouldn't work on real HW though.

TODOs :
- fix sprites wrapping
- use some decent tiles ;D
- full screen scroll
- sending small (that is, less than 4 16-bit words) data from the 68k to the 32X

Well, you succeeded! It certainly doesn't work on real hardware.

You need to give these roms a ".bin" extension - Fusion only allows for (lower case) ".bin" roms to be shown/loaded. If you're worried people won't know it's for the 32X, put it in the name, not the extension.

It's certainly an odd demo... I'd have probably nicked a simple background and some sprites from somewhere instead of just using a font.

Chilly Willy wrote:It's certainly an odd demo... I'd have probably nicked a simple background and some sprites from somewhere instead of just using a font.

I've just uploaded some DBZ backgrounds.

'still some work to be done but ... hey ! It's aliiiiive !!!!

ob1 wrote:

Chilly Willy wrote:It's certainly an odd demo... I'd have probably nicked a simple background and some sprites from somewhere instead of just using a font.

I've just uploaded some DBZ backgrounds.

'still some work to be done but ... hey ! It's aliiiiive !!!!

Damn that looks good! Now THAT is a demo.

A couple minor booboos in the rendering (couple cell lines here and there), but overall nice and smooth. This really shows great potential.