It is currently Fri Oct 19, 2018 10:15 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Thu Aug 30, 2018 10:39 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20671
Location: NE Indiana, USA (NTSC)
Besides, all a glitch would do is increase intensity by one step for one frame, something the player is unlikely to notice.

Do the Nintendo 64 Rumble Pak and GameCube vibration feature even have an intensity setting?


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 10:59 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7664
Location: Seattle
No, both the Gamecube controller and Rumble Pak use a single bit to control the vibration motor.

Gamecube controller serial protocol consists of a query of three bytes: [0x40 X Y] where Y=even for rumble off and Y=odd for rumble on. (The controller then replies with a standard report). (Lots of other sources vary on what X and the upper bits of Y are. No-one seems to have tracked down what they do)
Rumble Pak protocol piggybacks on top of the protocol for the Transfer Pak: a single bit is mapped to the upper half of its address space, and writes [0x03 Ah Al <31 bytes of don't care> Z] with the ones bit on in the last byte turn the motor on, and vice versa. Oddly enough, the bit is readable too.

Apparently the Wiimote is also just on/off.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 3:40 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 812
Apparently Nintendo's rumble motors are really low current too, but I've only found one source on the net for GC rumble measurement, 30 mA. I want to confirm that and measure a few controllers (orig, third party, new Smash Edition ones) for potential N64 use. Extension cable ordered.


Top
 Profile  
 
PostPosted: Sat Sep 01, 2018 8:00 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3569
Location: Indianapolis
tepples wrote:
Besides, all a glitch would do is increase intensity by one step for one frame, something the player is unlikely to notice.

Yeah, that's a good point. It makes sense to write to it every frame, and the occasional variation really shouldn't be noticeable. DPCM glitch should be pretty much irrelevant in that case.

When I was talking to kevtris about controlling a rumble motor like this, he suggested using the latch/OUT0 line. It's a good idea too, because games normally only leave it active for like 6 CPU cycles to latch the controller. You could also accept CLK pulses while OUT0 is active for sending those parameters. Normal games would pretty much never do that either, because it would only read the A button repeatedly.

Anyways, I'm fine with any control method, just figured I'd put that out there.


Top
 Profile  
 
PostPosted: Sun Sep 02, 2018 12:35 am 
Offline
User avatar

Joined: Sat Aug 15, 2015 3:42 pm
Posts: 147
Location: France
I finally have some time to post here :)

Memblers wrote:
When I was talking to kevtris about controlling a rumble motor like this, he suggested using the latch/OUT0 line.

Yep, I think that's what I would do.

One idea could be to use RS-232 with the OUT0 line.
The routine below works for me with both NTSC and PAL NES (front loaders), but it may be time consuming ...
The receiver must be set to 115400 bauds (not 115200).
If only 4 bits are used, we can reduce the routine, and set the RS-232 receiver to 5N1 or maybe 4N1 ?

Let me know what you think.

Code:
; ZEROPAGE vars
temp:           .res 1
rumbleState:    .res 1
; ----bbaa
; aa : player 1 motor intensity (0 : stop / 1 : low / 2 : mid / 3 : high)
; bb : player 2 motor intensity (0 : stop / 1 : low / 2 : mid / 3 : high)
; ---- : unused bits ?

    lda rumbleState ; 2
    sta temp        ; 2
    lda #0          ; 2
    sta $4016       ; 4 ; start bit
    lda temp        ; 3
    nop             ; 2
    ;nop             ; 2 ; NTSC - works for me without this line on an NTSC and PAL NES front loader
   
    pha             ; 3
    and #$01        ; 2
    sta $4016       ; 4 - 16 ; bit 0
    pla             ; 4
    lsr             ; 2

    sta temp        ; 3
    and #$01        ; 2
    sta $4016       ; 4 - 15 ; bit 1
    lda temp        ; 3
    lsr             ; 2
    nop             ; 2
   
    pha             ; 3
    and #$01        ; 2
    sta $4016       ; 4 - 16 ; bit 2
    pla             ; 4
    lsr             ; 2
   
    sta temp        ; 3
    and #$01        ; 2
    sta $4016       ; 4 - 15 ; bit 3
    lda temp        ; 3
    lsr             ; 2
    nop             ; 2
   
    pha             ; 3
    and #$01        ; 2
    sta $4016       ; 4 - 16 ; bit 4
    pla             ; 4
    lsr             ; 2
   
    sta temp        ; 3
    and #$01        ; 2
    sta $4016       ; 4 - 15 ; bit 5
    lda temp        ; 3
    lsr             ; 2
    nop             ; 2
   
    pha             ; 3
    and #$01        ; 2
    sta $4016       ; 4 - 16 ; bit 6
    pla             ; 4
    lsr             ; 2
   
    sta temp        ; 3
    and #$01        ; 2
    sta $4016       ; 4 - 15 ; bit 7
    lda temp        ; 3
    lsr             ; 2
    nop             ; 2
   
    lda temp        ; 3
    lda #1          ; 2
    sta $4016       ; 4 - 16 ; stop bit

_________________
My first game : Twin Dragons available at Broke Studio.


Top
 Profile  
 
PostPosted: Sun Sep 02, 2018 8:16 am 
Offline

Joined: Fri Nov 18, 2016 7:29 am
Posts: 15
Memblers wrote:
When I was talking to kevtris about controlling a rumble motor like this, he suggested using the latch/OUT0 line.


So sending the control byte via the latch line instead of counting clock cycles? That would keep timing equal regardless of the information being sent. The rs232 isn't a bad idea either but won't work with my current prototype. I feel since the clock and latch lines are both present on the microcontroller that simply bit-banging the control bytes in would be sufficient. I can utilize the rs232 code for some of my other projects so thank you glutock for posting that!


Top
 Profile  
 
PostPosted: Sun Sep 02, 2018 9:19 am 
Offline
User avatar

Joined: Sat Aug 15, 2015 3:42 pm
Posts: 147
Location: France
One advantage of the rs232 solution is that dpcm glitch won't be a problem.

_________________
My first game : Twin Dragons available at Broke Studio.


Top
 Profile  
 
PostPosted: Sun Sep 02, 2018 10:27 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7664
Location: Seattle
As long as the bitrate you use is slow enough that losing 4 cycles when a DPCM fetch steals the CPU, that'll be fine.

Other self-clocking encodings may work well, too.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group