General Insanity (Genesis + PVR)

DcSteve · Post by **DcSteve** » Mon Jun 21, 2004 3:58 pm

can anyone compile a bin of this please.. i would love to test it out and give reports

doragasu · Post by **doragasu** » Mon Jun 21, 2004 4:12 pm

Until there's a menu system, it's not really useful to have a bin because you'd be able to test it only with one predefined game.

Warmtoe · Post by **Warmtoe** » Mon Jun 21, 2004 4:24 pm

Yeah - OK - it works in Chankast - I'm using the 'run as a bin' version and putting my 1 rom into a romdisk... Right, now to fiddle.

First off, in xrender_draw_tile - I you only call pvr_dr_target once, not for each time you submit a vertex - and you don't then have to set all the values for each vertex because they carry across from one to the next. - it's hard to tell, but I think that makes a small improvement.

Post by **Quzar** » Mon Jun 21, 2004 7:03 pm

doragasu wrote:Until there's a menu system, it's not really useful to have a bin because you'd be able to test it only with one predefined game.

it could be compiled with the rom name set to 'rom.zip' looking at the CD.

BlackAura · Post by **BlackAura** » Mon Jun 21, 2004 8:51 pm

Storminator16 wrote:For those who don't know, this emu is what you've all been dying to see: fast speed (frame skip to 2?) homebrewn Genesis/Megadrive emu!

Actually... Frameskip = 0, but it's not quite full speed. Some frames take around 18ms to draw, which means the PVR needs to wait until the next frame to do anything (total 33ms instead of 16.6ms)

When do you plan to add a GUI and such? I have a bit more time lately, so I wouldn't mind trying to add something to this project.

When I've got some of the glitches ironed out. Feel free to help out if you want.

Btw, is tthere a way to exit the emu?

Power button. You can probably add it a bit of code to detect A+B+X+Y+Start and have that exit, but I don't actually know how to exit...

Status bar at the bottom of the screen missing

The missing status bars are almost certainly because I'm not emulating the windowing modes yet. I can emulate them, but they need to replace layer A, and I'm not totally sure how to get that happening yet. Now I at least have a couple of games to test with to give it a go.

Valis 3

I'll need to check that one out. I have no idea what could be wrong with that one.

Street Fighter 2 Turbo

As far as I know, SF2T doesn't work on Genesis Plus at all. I think the cartridge has some extra memory mapping hardware in it, which GP doesn't emulate.

Phantom wrote:Keep up the good work!

Will do!

DcSteve wrote:can anyone compile a bin of this please.. i would love to test it out and give reports

That'd really require a menu, which I don't have right now. If I can get one working, we'll see what we can do.

ice88 wrote:First off, in xrender_draw_tile - I you only call pvr_dr_target once, not for each time you submit a vertex - and you don't then have to set all the values for each vertex because they carry across from one to the next. - it's hard to tell, but I think that makes a small improvement.

I'll check that out. Thanks. I thought the SH-4 used two separate store queues, which would mean that the stuff would carry over from vertex 1 to vertex 3, and from vertex 2 to vertex 4. I know they definitely carry over when you're not using DR, but I've not done a lot with DR, so I'm not quite sure.

Time to experiment then.

Warmtoe · Post by **Warmtoe** » Tue Jun 22, 2004 1:33 am

Should the sound streaming be working? I have quite a late kos-svn version and snd_stream functions have all changed to take a sound stream handle - I converted them all over, but it's still not working.

Does sound work?

Warmtoe · Post by **Warmtoe** » Tue Jun 22, 2004 1:41 am

OK - like, wow - I just tried this on a real DC (had been using chankast) and I am getting a solid 58-60 fps - although I have no sound!!!!

BlackAura · Post by **BlackAura** » Tue Jun 22, 2004 6:25 am

Sound uses a version of the streaming API that Stef.D modified. It was intended to be used in KOS 1.2.0, so it might not work in the SVN versions. It does work with KOS 1.2.0 though, even though it has a few problems.

Aside from which, you need to re-enable the Z80 to make sound work properly, and that slows the emulator down. A lot. Change the Z80 clock speed (in main.c) to 228.

Adding Stef's C68K will help that a lot when enabling sound, but we still need a faster Z80 emulator before we can get this thing up to full speed with sound. At the moment, with the hardware accelerated VDP, no sound, using Musashi, it's almost full speed (like 55-60FPS all the time), and with C68k it's undoubtedly full speed all the time.

speud · Post by **speud** » Tue Jun 22, 2004 10:25 am

just tested it and its really awesome, sonic is almost perfect.
i compiled it with kos-1.2.0 and i have no sound neither, i got a few warnings here and there about implicit declaration of vdp_int_ack_callback just in case its connected.
also i was wondering, does the low resolution really improve speed? if not i think it might look better in 640x480 with some filtering.
i could try and make a quick games browser if that helps, dont expect anything beautiful though.
nothing original, but keep up the good work

doragasu · Post by **doragasu** » Tue Jun 22, 2004 10:35 am

Is this the beginning of another great team (like the one who made NeoCD SDL/DC)? It could be awesome! (it's already awesome anyway).

BlackAura · Post by **BlackAura** » Tue Jun 22, 2004 11:00 am

Speud - If you want to write a games browser, go ahead. I've been working on a new GUI for Genesis Plus anyway (which will be very cool if I ever get it finished), but that's a long way off.

The low resolution might not make much difference to speed, but it does make a lot of difference to the complexity of the code. We don't have to screw around with the sprite / tile coordinates to scale them up to 640x480, and I don't think filtering will make any difference at all to the video quality. Personally, I think it looks just fine as-is (except the bits that don't work), but feel free to experiment.

Currently, rendering the scene is taking around 0-2ms, which leaves us at least 14ms to waste. The time to submit the display list for one frame is more like 4-6ms, which leaves us only 10ms for everything else, including both CPUs and sound emulation. That 10ms is just about enough for the 68K using Musashi.

To get sound, you need to re-enable the Z80 (change the last line of dc_options in main.c to 228), and re-enable the sound emulation (uncomment the audio_init line in the dc_init function of main.c) It worked last time I checked it.

speud · Post by **speud** » Tue Jun 22, 2004 11:17 am

BlackAura wrote:Speud - If you want to write a games browser, go ahead. I've been working on a new GUI for Genesis Plus anyway (which will be very cool if I ever get it finished), but that's a long way off.

ok, i think ill do a temporary menu, this way youll be able to release a bin for more people to test it if you want.

BlackAura wrote:The low resolution might not make much difference to speed, but it does make a lot of difference to the complexity of the code. We don't have to screw around with the sprite / tile coordinates to scale them up to 640x480, and I don't think filtering will make any difference at all to the video quality. Personally, I think it looks just fine as-is (except the bits that don't work), but feel free to experiment.

yes i knew it would probably be harder to change the resolution since its not drawing one texture that contains the whole screen but several textures for each tiles, though after i multiplied the vertex coordinates by 2 in xrender_draw_tile() it looks like it does the trick, and it definitely looks better in 640x480 imo, but maybe thats just me.

BlackAura wrote:To get sound, you need to re-enable the Z80 (change the last line of dc_options in main.c to 228), and re-enable the sound emulation (uncomment the audio_init line in the dc_init function of main.c) It worked last time I checked it.

yes my bad, i didnt read your previous post carefully, sorry. sound works now, its a bit weird (playing twice) and makes things slow down but thats very promising.

Ian Micheal · Post by **Ian Micheal** » Tue Jun 22, 2004 11:26 am

Limt the sound to to the same fps it runs about 30 to 40 and it stays in time.does not start again etc. Very cheap but works.

/* Calculate the sound buffer size */
snd.buffer_size = (rate / 27); //27 change the number to match
snd.sample_rate = rate;

By changing this you can make the sound stay normal and not do what it's doing. On the SDL version with sound on i get 27 to 30 fps. Also init the sound when you frameskip it makes it synic pretty much perfect.

This speed is with old games it varys a lot. make the sound 8 bit fm lower sample rate the speed goes up again still sounds good.

qatmix · Post by **qatmix** » Tue Jun 22, 2004 11:47 am

Personally I hate it when emus smooth out the screens from their original resolution and apply filters. Unless its a full on filter such as the hq3x (Hiend3d.com) which really makes a difference I think bi-linear looks terrible on hand drawn sprites (I hate what it does on the neocd emu ive been trying). maybe thats because im an artist. However I wouldnt dream of sacrificing speed to display in an higher resolution etc.

Anyway, exciting stuff on this thread.

doragasu · Post by **doragasu** » Tue Jun 22, 2004 11:53 am

BlackAura, how do you profile the code to know how much time takes everything? Maybe reading from timers?

speud · Post by **speud** » Tue Jun 22, 2004 12:10 pm

Personally I hate it when emus smooth out the screens from their original resolution and apply filters. Unless its a full on filter such as the hq3x (Hiend3d.com) which really makes a difference I think bi-linear looks terrible on hand drawn sprites (I hate what it does on the neocd emu ive been trying). maybe thats because im an artist.

well, if youre an artist you shouldnt like when pixels are zoomed without applying a filter thus causing bad aliasing. and when the screen mode is set to 320x240 it use a sort of scanline effect that i find quite ugly, but again its only my opinion.

However I wouldnt dream of sacrificing speed to display in an higher resolution etc.

try replacing this part:

Code: Select all

	/* Send the upper-left vertex */
	vert = pvr_dr_target(dr_state);
	vert->flags = PVR_CMD_VERTEX;
	vert->x = x;
	vert->y = y;
	vert->z = zbase;
	vert->u = tc_left;
	vert->v = tc_top;
	vert->argb = vertex_colour;
	vert->oargb = 0;
	pvr_dr_commit(vert);

	/* Send the upper-right vertex */
	vert = pvr_dr_target(dr_state);
	vert->flags = PVR_CMD_VERTEX;
	vert->x = x+8;
	vert->y = y;
	vert->z = zbase;
	vert->u = tc_right;
	vert->v = tc_top;
	vert->argb = vertex_colour;
	vert->oargb = 0;
	pvr_dr_commit(vert);

	/* Send the lower-left vertex */
	vert = pvr_dr_target(dr_state);
	vert->flags = PVR_CMD_VERTEX;
	vert->x = x;
	vert->y = y+8;
	vert->z = zbase;
	vert->u = tc_left;
	vert->v = tc_bum;
	vert->argb = vertex_colour;
	vert->oargb = 0;
	pvr_dr_commit(vert);

	/* Send the lower-right vertex */
	vert = pvr_dr_target(dr_state);
	vert->flags = PVR_CMD_VERTEX_EOL;
	vert->x = x+8;
	vert->y = y+8;
	vert->z = zbase;
	vert->u = tc_right;
	vert->v = tc_bum;
	vert->argb = vertex_colour;
	vert->oargb = 0;
	pvr_dr_commit(vert);

with this one:

Code: Select all

	/* Send the upper-left vertex */
	vert = pvr_dr_target(dr_state);
	vert->flags = PVR_CMD_VERTEX;
	vert->x = x*2;
	vert->y = y*2;
	vert->z = zbase;
	vert->u = tc_left;
	vert->v = tc_top;
	vert->argb = vertex_colour;
	vert->oargb = 0;
	pvr_dr_commit(vert);

	/* Send the upper-right vertex */
	vert = pvr_dr_target(dr_state);
	vert->flags = PVR_CMD_VERTEX;
	vert->x = (x+8)*2;
	vert->y = y*2;
	vert->z = zbase;
	vert->u = tc_right;
	vert->v = tc_top;
	vert->argb = vertex_colour;
	vert->oargb = 0;
	pvr_dr_commit(vert);

	/* Send the lower-left vertex */
	vert = pvr_dr_target(dr_state);
	vert->flags = PVR_CMD_VERTEX;
	vert->x = x*2;
	vert->y = (y+8)*2;
	vert->z = zbase;
	vert->u = tc_left;
	vert->v = tc_bum;
	vert->argb = vertex_colour;
	vert->oargb = 0;
	pvr_dr_commit(vert);

	/* Send the lower-right vertex */
	vert = pvr_dr_target(dr_state);
	vert->flags = PVR_CMD_VERTEX_EOL;
	vert->x = (x+8)*2;
	vert->y = (y+8)*2;
	vert->z = zbase;
	vert->u = tc_right;
	vert->v = tc_bum;
	vert->argb = vertex_colour;
	vert->oargb = 0;
	pvr_dr_commit(vert);

in the xrender_draw_tile() function in xrender.c, and this line:

Code: Select all

	vid_set_mode(DM_320x240, PM_RGB565);

witht his one:

Code: Select all

	vid_set_mode(DM_640x480, PM_RGB565);

in the dc_init() function in main.c.
youll see the result by yourself, no slowdown at all, at least that i can notice.

Storminator16 · Post by **Storminator16** » Tue Jun 22, 2004 12:59 pm

I agree with qatmix, I hate filtering and such for these classic games. I moreso love the scanline effect, but I treid out your idea, Speud. The emu doesn't seem to drop off in speed at all, and some of the sprites seem cleaner. I dunno, I need to test both sizes over an extended period, but I have to leave at the moment. I'll try to test more as soon as I get home.

Damn, it's still hard to believe I'm playing Sonic2 on my DC.

Alexvrb · Post by **Alexvrb** » Tue Jun 22, 2004 1:23 pm

Great, all the coders that are looking at it are too busy playing games now, LOL!

Anyway, if what Speud suggested works without problems, it would be worth looking into. I think tri/bilinear filtering should be optional though, if it is ever implemented. Some people like it, but others want it to be as close to the original as possible.

elefas · Post by **elefas** » Tue Jun 22, 2004 2:53 pm

Hey B.A. does this beast compile under Dev-Cpp? I was trying to compile it yesterday night but it spitted out a hell out of errors and warnings. Most of them had to do with xvdp.c vs vdp.c and xrender.c vs render.c stating multiple function definitions. Anyway I guess it needs pure KOS.
Just keep up the good work!

Post by **Christuserloeser** » Tue Jun 22, 2004 5:59 pm

BlackAura wrote:
Storminator16 wrote:Street Fighter 2 Turbo
As far as I know, SF2T doesn't work on Genesis Plus at all. I think the cartridge has some extra memory mapping hardware in it, which GP doesn't emulate.

You are mixing it up with Super Street Fighter 2 I guess. I've made a check with the PC DOS version:

Test version: gp-051303-dos

Super Street Fighter 2 (U) (40Meg) - doesn't work (red screen)*
Street Fighter 2 Special Champion Edition (E/U) (24Meg) - runs perfectly
Street Fighter 2 Plus (J) (24Meg) - crashes at 1st demo play*, the game itself is perfectly playable
Street Fighter 2 Turbo (h1) (16Meg) - runs perfectly

...and just to be sure:
Bare Knuckle 3 (J) (24Meg) - runs perfectly

*see error logs below

---

Street Fighter 2 Plus (J) (24Meg)
Ingame error log: Illegal Instruction 04

GP Error log:

Code: Select all

PC:00000206	SP:FFFFFF00
PC:00000206	SP:FFFFFF00


PC:00025FEC	SP:FFFFFEEA	SR:2004
D0:800000A8	A0:FFFFDF00
D1:00000034	A1:00008F32
D2:00480018	A2:0000E2AC
D3:01280008	A3:FFFFF080
D4:00000000	A4:FFFFDE10
D5:00000878	A5:FFFFE000
D6:00000002	A6:FFFFF200
D7:00000000	A7:FFFFFEEA

PC:03B2	SP:02D6
AF:1A54	AF:1D4A
BC:0000	BC:0000
DE:06FF	DE:2200
HL:0039	HL:4000
IX:4002	IY:4000

---

Super Street Fighter 2 (U) (40Meg)

GP Error log:

Code: Select all

PC:00003AAA	SP:FFFFFC00
PC:00003AAA	SP:FFFFFC00


PC:00003C3A	SP:FFFFFC00	SR:2708
D0:85C18D66	A0:00380000
D1:FFFFFFFF	A1:00000224
D2:00000001	A2:00000000
D3:00000000	A3:00000000
D4:00000000	A4:00000000
D5:00000000	A5:00000000
D6:00000000	A6:00000000
D7:0000FFFF	A7:FFFFFC00

PC:0000	SP:0000
AF:0040	AF:0000
BC:0000	BC:0000
DE:0000	DE:0000
HL:0000	HL:0000
IX:FFFF	IY:FFFF

Maybe if Stef would...!?

Chris