PPPPUURRRRUU PURU!
- Quzar
- Dream Coder
- Posts: 7497
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Wed Jul 31, 2002 12:14 am
- Location: Miami, FL
- Has thanked: 4 times
- Been thanked: 9 times
- Contact:
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...
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
- SinisterTengu
- DC Developer
- Posts: 382
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Arlington, WA
- Has thanked: 0
- Been thanked: 0
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 .
Anyways, a couple weeks ago I bought two official Sega rumble packs ($6.75 together including shipping on ebay ), 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?
Anyways, a couple weeks ago I bought two official Sega rumble packs ($6.75 together including shipping on ebay ), 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?
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..
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..
- SinisterTengu
- DC Developer
- Posts: 382
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Arlington, WA
- Has thanked: 0
- Been thanked: 0
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.
-
- Insane DCEmu
- Posts: 138
- Joined: Sun Apr 06, 2003 5:29 am
- Has thanked: 0
- Been thanked: 0
- Contact:
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.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.
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.
- SinisterTengu
- DC Developer
- Posts: 382
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Arlington, WA
- Has thanked: 0
- Been thanked: 0
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 .
-
- bleemcast! Creator
- Posts: 882
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Los Angeles, CA
- Has thanked: 0
- Been thanked: 0
- Contact:
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.
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.
- SinisterTengu
- DC Developer
- Posts: 382
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Arlington, WA
- Has thanked: 0
- Been thanked: 0
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.
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.
-
- bleemcast! Creator
- Posts: 882
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Los Angeles, CA
- Has thanked: 0
- Been thanked: 0
- Contact:
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.
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.
-
- bleemcast! Creator
- Posts: 882
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Los Angeles, CA
- Has thanked: 0
- Been thanked: 0
- Contact:
-
- DCEmu Uncool Newbie
- Posts: 1459
- Joined: Sat Dec 27, 2003 10:40 pm
- Has thanked: 0
- Been thanked: 0
- Contact:
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:
purupuru.c:
then at the begining of my code i do:
and in the main loop:
where freq, pow and len have been calculated before in the loop.
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();
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);
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.
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.
- nothingxs
- DCEmu Newbie
- Posts: 2
- Joined: Fri Mar 26, 2004 10:35 pm
- Location: miami, fl, usa
- Has thanked: 0
- Been thanked: 0
- Contact:
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).
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!
-
- Soul Sold for DCEmu
- Posts: 4865
- Joined: Fri Jul 11, 2003 9:56 pm
- Has thanked: 2 times
- Been thanked: 4 times
- GyroVorbis
- Elysian Shadows Developer
- Posts: 1873
- Joined: Mon Mar 22, 2004 4:55 pm
- Location: #%^&*!!!11one Super Sonic
- Has thanked: 79 times
- Been thanked: 61 times
- Contact: