PPPPUURRRRUU PURU!

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
User avatar
Quzar
Dream Coder
Dream Coder
Posts: 7486
Joined: Wed Jul 31, 2002 12:14 am
Location: Miami, FL
Has liked: 0
Been liked: 3 times
Contact:

Post by Quzar » Tue Apr 20, 2004 2:58 am

There are three different controller boards.

v0 is the first and is 2 pin for Heatpipe dreamcasts 1998
v1 has 3 pins for the fan header and iirc is brown 1999
v2 is the same as v1 except for it is green and newer so it may have revised hardware. 2000

it has been reported that some rumble packs dont function properly at times with one DC and then they do with others, so it is possible that from v1 - v2 SEGA fixed something to keep unlicensed things from working or such...
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
User avatar
SinisterTengu
DC Developer
DC Developer
Posts: 382
Joined: Wed Oct 17, 2001 7:44 pm
Location: Arlington, WA
Has liked: 0
Been liked: 0
Contact:

Post by SinisterTengu » Fri May 28, 2004 4:42 pm

Ok, I know its been over a whole month, but I just haven't had much time to work on this lately. Plus I got a new computer (Athlon 64 3200+ ;)) and Comcast internet, so I've been playing a lot of games and downloading stuff instead of working on the purupuru stuff :P.

Anyways, a couple weeks ago I bought two official Sega rumble packs ($6.75 together including shipping on ebay :D ), and I just got around to trying them with my hex rumble demo today. I have some problems. First of all, the "Please attach a controller to port A!" message pops up when I press A or B quite often (but it still reacts fine). It never did that with my Performance one. Also, it seems considerably weaker than the Performance one, and a lot of rumbles that do something on the Performance one seem to make the official one only do a tiny tick.

So I am wondering, have those of you with an official pack had the same problems with this demo?
Image
Image
Viktor
DC Developer
DC Developer
Posts: 30
Joined: Sun Nov 04, 2001 4:47 am
Location: Stockholm, Sweden
Has liked: 0
Been liked: 0
Contact:

Post by Viktor » Sat May 29, 2004 3:27 pm

I only have the official so I dont know how different the rumble is but I have the same "problem" with "Please attach a controller to port A!" message, but it just shows for a cople of screens and then back to normal.

/Viktor
Kamjin
DC Developer
DC Developer
Posts: 216
Joined: Wed Dec 17, 2003 5:27 am
Has liked: 0
Been liked: 0

Post by Kamjin » Sun May 30, 2004 2:57 pm

I started looking at that problem also.. unforturnatley
free time is rare for me lately, and I lost a lot DC code, and notes
after my system died..
I've borrowed a sega unit, and I have my original unit..
My original doesn't behave at all like the newer sega rumble,
But I did start looking at it, and it almost seemed that it was
rumble was locking up the bus. at the time it seemed random.
I guess later on in the summer when things quiet down I'll
have a better chance to look at it..

but on the bright side.. with help from friends I've think
I've covered every joystick, lightgun, and rumble pack..
they all seem to work fine.. the only issue is the sega one..
User avatar
SinisterTengu
DC Developer
DC Developer
Posts: 382
Joined: Wed Oct 17, 2001 7:44 pm
Location: Arlington, WA
Has liked: 0
Been liked: 0
Contact:

Post by SinisterTengu » Sun May 30, 2004 6:05 pm

I'm rebuilding the DC tools on my new system..I was going to try changing the purupuru driver a little. It might be that genwait_wait part of the code, because I really had no idea how long to wait. KOS has different amounts of time to wait for different devices, so I just guessed with 200 and it worked with my Performance pack. Maybe that time needs to be adjusted a little to fix the errors with other packs. I'm going to try this as soon as I have the environment built again.
Image
Image
Vorrtexx
Insane DCEmu
Insane DCEmu
Posts: 138
Joined: Sun Apr 06, 2003 5:29 am
Has liked: 0
Been liked: 0
Contact:

Post by Vorrtexx » Sun May 30, 2004 6:46 pm

Kamjin wrote: But I did start looking at it, and it almost seemed that it was
rumble was locking up the bus. at the time it seemed random.
This was the same problem I experienced with the Lightgun. Originally I had the lightgun driver polling for light signals, and then I had changed it to a function where I would tell the DC I pulled the trigger and to send the command out on the maple bus then, having a callback to pick up the X/Y coordinates.

Have you tried it with 2 controllers attached to the Maple Bus? When one controller is only attached to the DC then it is the focus of all Maple Bus commands for the vblank, I think? so it could be a case of bus port taking commands too quickly or causing it to block somehow.
User avatar
SinisterTengu
DC Developer
DC Developer
Posts: 382
Joined: Wed Oct 17, 2001 7:44 pm
Location: Arlington, WA
Has liked: 0
Been liked: 0
Contact:

Post by SinisterTengu » Mon May 31, 2004 3:35 am

Ok, I got all my tools built (gcc-3.4.0, binutils-2.14, and newlib-1.12.0), and KOS compiled. My demo built fine, so I tried out the changes I said before. It seems that no matter what delay I set, I still get the problem. I tried taking out the wait all together like the controller driver, and I tried a wait of up to 900, and no matter what I still got the same results :( . I also tried it with a second controller plugged in like Vorrtexx said, but that didn't help. Also, no matter what setting I tried, my Performance one never had a problem, just the Sega ones :? .
Image
Image
Vorrtexx
Insane DCEmu
Insane DCEmu
Posts: 138
Joined: Sun Apr 06, 2003 5:29 am
Has liked: 0
Been liked: 0
Contact:

Post by Vorrtexx » Mon May 31, 2004 4:53 am

So the Official Sega Puru Puru Packs lock up the maple bus, or don't rumble, or both?
Rand Linden
bleemcast! Creator
bleemcast! Creator
Posts: 882
Joined: Wed Oct 17, 2001 7:44 pm
Location: Los Angeles, CA
Has liked: 0
Been liked: 0
Contact:

Post by Rand Linden » Mon May 31, 2004 6:12 am

The official ones are the only ones that handle the Maple protocol correctly.

All the other ones aren't guaranteed to give the right effects when using the correct parameters.

It was a real pain with b!DC to handle all sorts of cases -- the solution was to get a bunch of different packs from a variety of manufacturers and come up with something that was "middle-of-the-road" to ensure that everything worked on all devices.

Rand.
User avatar
SinisterTengu
DC Developer
DC Developer
Posts: 382
Joined: Wed Oct 17, 2001 7:44 pm
Location: Arlington, WA
Has liked: 0
Been liked: 0
Contact:

Post by SinisterTengu » Mon May 31, 2004 4:59 pm

The official packs work most of the time, but they sometimes lock up the maple bus real quick or something. My program checks if the controller is connected every frame, and if its not, it pops up with a message saying "Please attach a controller to port A!". Well, when you make an official pack rumble, it makes that message flash real quick a lot of the time, and sometimes the rumble doesn't go off, but the program still runs fine and I can still use the controller and stuff after the message goes away. My unofficial pack doesn't do this. So its still usable, but its causing some slight problems. If you aren't popping up a message giving an error like I am, then you should have no problems, except that a rumble has a chance of not triggering if its an official pack. I'm still messing around with things to see if I can fix this though.

Edit: ok, now this is weird. I rigged up my demo to make all puru's connected rumble, instead of just the one in slot A-2. Now, if I put my performance one in A-2 and the official one in B-2, they both rumble, and I don't get any errors. However, if I put the official one in A-2 and the unofficial in B-2, I do get the problem, and sometimes B-2 doesn't get the command to start or stop, but A-2 does. I tried swapping controllers and using different ports, but it still gave the same results.
Image
Image
Rand Linden
bleemcast! Creator
bleemcast! Creator
Posts: 882
Joined: Wed Oct 17, 2001 7:44 pm
Location: Los Angeles, CA
Has liked: 0
Been liked: 0
Contact:

Post by Rand Linden » Sun Jun 06, 2004 8:51 pm

The official ones shouldn't have any problems -- do you also have any non-Sega peripherals plugged into the DC at the same time? Or perhaps a VMU inserted?

If you're just testing with the Sega official puru-puru pack, errors should be rare indeed -- Yes, they do happen, but very rarely.

If you're getting weird errors that seem to occur more frequently when you add more devices later on in the maple chain, that's probably an issue with the data you're sending to the Maple controller, or the timing of the transmission.

There are also load limitations on the bus -- the more devices you have plugged in, especially non-official ones, the chances of an error happening start to increase dramatically.

Again, errors will happen on the bus, albeit rarely -- the solution is to basically reset the bus, wait a frame, then resync everything and all will be well.

Also, one other important tip: NEVER write to the memcards while the vibration is active -- the drain is usually too high, and in addition to getting read/write errors, there is a higher chance that the bus will reset and drop the devices entirely (again, the solution is to reset, etc.), but it's ugly.

My suspicion regarding what you're seeing with A2/B2 is that the non-standard one is either not responding properly to the commands, it's not buffering the lines, or it's drawing too much current when active. Basically, very similar stuff to what was observed with b!DC maple logic and testing.

Rand.
q_006
Mental DCEmu
Mental DCEmu
Posts: 415
Joined: Thu Oct 10, 2002 7:18 pm
Has liked: 0
Been liked: 0
Contact:

Post by q_006 » Sun Jun 06, 2004 9:01 pm

so the game should send a message to the pack/vmu/mem card that it's ready for transmission, reset the bus, then send the data. and this should be while the game is not running anything major.

absolute zero? cold? lukewarm? hot? a star's core?
Rand Linden
bleemcast! Creator
bleemcast! Creator
Posts: 882
Joined: Wed Oct 17, 2001 7:44 pm
Location: Los Angeles, CA
Has liked: 0
Been liked: 0
Contact:

Post by Rand Linden » Mon Jun 07, 2004 9:29 am

No -- when you notice a disconnect or error in the transmission, you need to verify that infact there has been a problem.

The cleanest way is to reset the bus, wait and resync.

A human can't plug/uplug the controllers faster than 2 frames' time, hence the solution.

Rand.
speud
DCEmu Uncool Newbie
DCEmu Uncool Newbie
Posts: 1459
Joined: Sat Dec 27, 2003 10:40 pm
Has liked: 0
Been liked: 0
Contact:

Post by speud » Fri Jul 16, 2004 11:56 am

i modified the plugin to implement rumble pack support in RADquake.
the result is quite good with my mad catz rumble pack, but when ian tested it with his performance rumble pack he said the analog stick was slow to respond :?
did you ever notice something similar? do you happen to know a way to fix it? here is my code.

purupuru.h:

Code: Select all

#include <kos.h>

#ifndef __DC_MAPLE_PURUPURU_H
#define __DC_MAPLE_PURUPURU_H
#endif

#ifndef MAPLE_FUNC_PURUPURU
#define MAPLE_FUNC_PURUPURU		0x00010000
#endif

int	purupuru_port;
int	purupuru_unit;
int	purupuru_enabled;
uint8	purupuru_freq;
uint8	purupuru_pow;

void	purupuru_rumble_callback(maple_frame_t * frame);
int	purupuru_rumble(maple_device_t * dev, uint8 freq, uint8 pow, uint8 len);

void 	purupuru_periodic(maple_driver_t *drv);
int 	purupuru_attach(maple_driver_t *drv, maple_device_t *dev);
void 	purupuru_detach(maple_driver_t *drv, maple_device_t *dev);
int	purupuru_init();
void	purupuru_shutdown();

purupuru.c:

Code: Select all

#include "purupuru.h"

void purupuru_rumble_callback(maple_frame_t * frame) {
	/* Unlock the frame for the next usage */
	maple_frame_unlock(frame);
}

int purupuru_rumble(maple_device_t * dev, uint8 freq, uint8 pow, uint8 len) {
	uint32 *send_buf;

//	assert( dev != NULL );
        
	/* Lock the frame */
	if (maple_frame_lock(&dev->frame) < 0)
		return MAPLE_EAGAIN;

	maple_frame_init(&dev->frame);
	send_buf = (uint32 *)dev->frame.recv_buf;
	send_buf[0] = MAPLE_FUNC_PURUPURU;
	send_buf[1] = (0x11 << 24) | (freq << 16) | (pow << 8) | (len << 0);
	dev->frame.cmd = MAPLE_COMMAND_SETCOND;
	dev->frame.dst_port = dev->port;
	dev->frame.dst_unit = dev->unit;
	dev->frame.length = 2;
	dev->frame.callback = purupuru_rumble_callback;
	dev->frame.send_buf = send_buf;
	maple_queue_frame(&dev->frame);

	return MAPLE_EOK;
}

void purupuru_periodic(maple_driver_t *drv) {

}

int purupuru_attach(maple_driver_t *drv, maple_device_t *dev) {
	dev->status_valid = 1;
	return 0;
}

void purupuru_detach(maple_driver_t *drv, maple_device_t *dev) {
	dev->status_valid = 0;
}

/* Device Driver Struct */
static maple_driver_t purupuru_drv = {
	functions:	MAPLE_FUNC_PURUPURU,
	name:		"PuruPuru (Vibration) Pack",
	periodic:	NULL,
	attach:		purupuru_attach,
	detach:		purupuru_detach
};

/* Add the mouse to the driver chain */
int purupuru_init() {
	return maple_driver_reg(&purupuru_drv);
}

void purupuru_shutdown() {
	maple_driver_unreg(&purupuru_drv);
}

then at the begining of my code i do:

Code: Select all

purupuru_init();
maple_hw_init();
and in the main loop:

Code: Select all

	maple_device_t *dev=maple_enum_dev(purupuru_port, purupuru_unit);
	uint32 func=maple_device_func(purupuru_port, purupuru_unit);

	if (!(func & MAPLE_FUNC_PURUPURU))
		return;

	if (purupuru_enabled)
		purupuru_rumble(dev, freq, pow, len);
	else
		purupuru_rumble(dev, 0, 0, 0x10);
where freq, pow and len have been calculated before in the loop.
http://blueswirl.fr.st - DC Online Tools and Downloads

thx to Wack0 for the avatar ;)
Kamjin
DC Developer
DC Developer
Posts: 216
Joined: Wed Dec 17, 2003 5:27 am
Has liked: 0
Been liked: 0

Post by Kamjin » Sat Jul 17, 2004 8:10 pm

I'm going to assume it's something to do with the method KOS uses to
queue up and xmit data to the maple bus. I went back to my stand alone maple
code, and I'm not having the lockup problem, also almost all the testing I've
done was with a performance rumble... you could always try what I did in the end.
run your own maple code to access the rumbles. set up your data and wait until
the DMA isn't busy.. and if I can recall you're not in a Vsync, then start the transfer. If the device doesn't respondind at all reset the bus, and try again.
You could use the code I originally posted as a framework.. there's a mistake
in the section to calc the DST var.. I don't remeber exactly what it was but that
i reversed something, and it won't calc the dst properly beyond the 2nd port.
speud
DCEmu Uncool Newbie
DCEmu Uncool Newbie
Posts: 1459
Joined: Sat Dec 27, 2003 10:40 pm
Has liked: 0
Been liked: 0
Contact:

Post by speud » Sat Jul 17, 2004 9:20 pm

ok ill try that. thanks.
http://blueswirl.fr.st - DC Online Tools and Downloads

thx to Wack0 for the avatar ;)
User avatar
nothingxs
DCEmu Newbie
DCEmu Newbie
Posts: 2
Joined: Fri Mar 26, 2004 10:35 pm
Location: miami, fl, usa
Has liked: 0
Been liked: 0
Contact:

Post by nothingxs » Mon Aug 02, 2004 2:06 am

i've a few questions:

does the utility loop the purupuru command endlessly? if so, good, because i've the performance, madkatz and sega purupuru devices and have been intending to conduct an experiment to see if it is possible to burn the motors out from too much use -- and if so, how long it would take for such a thing to happen on each brand.

someone let me know if such a thing can be tried. and if i can get a nero image that i can just burn to try it with (to this day, i am unable to make a self-booting dc disc after at least 20 tries -- ugh).
what!
Kamjin
DC Developer
DC Developer
Posts: 216
Joined: Wed Dec 17, 2003 5:27 am
Has liked: 0
Been liked: 0

Post by Kamjin » Mon Aug 02, 2004 7:11 am

kidding right? Odds are it'll cause a solder joint to come loose before the motor get's dammaged, or more perhaps burn the transistor that drives to motor..
Ian Micheal
Soul Sold for DCEmu
Soul Sold for DCEmu
Posts: 4864
Joined: Fri Jul 11, 2003 9:56 pm
Has liked: 0
Been liked: 3 times

Post by Ian Micheal » Mon Aug 02, 2004 7:16 am

I think he is making a toy for his gurl freind by the sound of it and she needs lots of loving.
:P :mrgreen: )()(
Dreamcast forever!!!
User avatar
GyroVorbis
Elysian Shadows Developer
Elysian Shadows Developer
Posts: 1808
Joined: Mon Mar 22, 2004 4:55 pm
Location: #%^&*!!!11one Super Sonic
Has liked: 0
Been liked: 0
Contact:

Post by GyroVorbis » Mon Aug 02, 2004 11:29 am

Ian Micheal wrote:I think he is making a toy for his gurl freind by the sound of it and she needs lots of loving.
:P :mrgreen: )()(
:rofl: :guffaw:
Elysian Shadows - "Next-Gen" 2D/3D RPG coming to Sega Dreamcast, Steam, OUYA, and Smartphones
Image
http://www.elysianshadows.com
Post Reply