"You must spread some Reputation around before giving it to Chilly Willy again."
Printable View
"You must spread some Reputation around before giving it to Chilly Willy again."
Chilly Willy:
What you say I think that maybe makes sense, I was looking at two games to see how the code of the mouse: Fun 'n games and Lord Monarch (jap). The latter seemed to me more interesting and shorter, also you can see that the value of "Y" is inverted, though I'm not sure if it works for both versions of mouse, here is the code:
The version2 that could work for Barone, was that just changing a "bne" for "beq" in the last "handshake" but I've noticed that the codes I've seen, is that it should be as I left, because when writing a #$0, it waits for a 0 in bit 4, and when a #$20 is written, it waits for a 1 in bit 4. That's how it is in the version2:Code:;--------------Lord Monarch mouse code-----------------
; a0 = 00a10005 ;a1 = ffff8550
L8c6:
move.b #$20,(a0)
move.b #$60,6(a0)
btst #4,(a0)
beq.b L946
move.w #$ff,d7
bsr L980 ;---L980----- get 4 bits ($0 wr phase)
bcs.b L946
bsr L96c ;---L96c----- get 4 bits ($20 wr phase)
bcs.b L946
moveq #0,d2
bsr L980 ;---L980----- get 4 bits ($0 wr phase)
bcs.b L966
andi.b #$0f,d0
move.b d0,d2 ; YO XO YS XS
bsr.b L96c ;---L96c----- get 4 bits ($20 wr phase)
bcs.b L966
lsl.b #4,d0
or.b d0,d2 ; S M R L YO XO YS XS
swap d2
bsr.b L94c ;---L94c----- get 1 byte
lsl.w #4,d2
bsr.b L94c ;---L94c----- get 1 byte
move.w d2,d3 ; X7 X6 X5 X4 X3 X2 X1 X0 Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
swap d2
move.w d2,d0
move.w d0,d1
move.w (a1),d2
move.w d0,(a1)+ ;buttons hold
and.w d2,d1
eor.w d0,d1
move.w d1,(a1)+ ;buttons press
moveq #0,d2
btst #2,d0 ;XO - (X overflow)
bne.b L92c
move.w d3,(A1)
move.b (a1),d2 ;X7-X0
btst #0,d0 ;XS - (X sign)
beq.b L92c
subi.w #$100,d2
L92c:
move.w d2,(A1)+
moveq #0,d2
btst #3,d0 ;YO - (Y overflow)
bne.b L942
move.b d3,d2 ;Y7-Y0
btst #1,d0 ;YS - (Y sign)
beq.b L942
subi.w #$100,d2
L942:
neg.w d2
move.w d2,(a1)+
L946:
move.b #$60,(a0)
rts
L94c:
bsr L980 ;---L980-----get 4 bits ($0 wr phase)
bcs.b L964
andi.b #$0f,d0
or.b d0,d2
bsr.b L96c ;---L96c-----get 4 bits ($20 wr phase)
bcs.b L964
lsl.w #4,d2
andi.b #$0f,d0
or.b d0,d2
rts
L964:
addq.w #4,a7
L966:
ori #1,CCR
rts
L96c:
move.b #$20,(a0)
L970:
move.b (a0),d0
btst #4,d0
dbne d7,L970
beq.b L994
move.b (a0),d0
rts
L980:
move.b #$0,(a0)
L984:
move.b (a0),d0
btst #4,d0
dbeq d7,L984
bne.b L994
move.b (a0),d0
rts
L994:
ori #1,CCR
rts
Anyway, I'll leave here a version with the addition of testing negative zero in X and Y. But I'll keep looking for the mouse code in other games to be sure.Code:get_mkyb:
move.w #0x2700,sr ;/* disable ints */
lea $A10005,a0 ;portb
move.b #0x60,(a0) ;/* first phase of mouse packet */
nop
nop
L0:
btst #4,(a0)
beq.b L0 ;/* wait on handshake */
move.b (a0),d0 ;/* not 0 means not mouse */
nop
nop
move.b #0x20,(a0) ;/* next phase */
nop
nop
L1:
btst #4,(a0)
beq.b L1 ;/* handshake */
L2:
move.b (a0),d0 ;/* not 11 means not mouse */
nop
nop
move.b #0,(a0) ;/* next phase */
nop
nop
L3:
btst #4,(a0)
bne.b L3 ;/* handshake */
L4:
move.b (a0),d0 ;/* specs say should be 15 */
nop
nop
move.b #0x20,(a0) ;/* next phase */
nop
nop
L5:
btst #4,(a0)
beq.b L5
L6:
move.b (a0),d0 ;/* specs say should be 15 */
nop
nop
move.b #0,(a0) ;/* next phase */
moveq #0,d0 ;/* clear reg to hold packet */
nop
L7:
btst #4,(a0)
bne.b L7 ;/* handshake */
L8:
move.b (a0),d0 ;/* YO XO YS XS */
move.b #0x20,(a0) ;/* next phase */
lsl.w #8,d0 ;/* save nibble */
L9:
btst #4,(a0)
beq.b L9 ;/* handshake */
L10:
move.b (a0),d0 ;/* S M R L */
move.b #0,(a0) ;/* next phase */
lsl.b #4,d0 ;/* YO XO YS XS S M R L 0 0 0 0 */
lsl.l #4,d0 ;/* YO XO YS XS S M R L 0 0 0 0 0 0 0 0 */
L11:
btst #4,(a0)
bne.b L11 ;/* handshake */
L12:
move.b (a0),d0 ;/* X7 X6 X5 X4 */
move.b #0x20,(a0) ;/* next phase */
lsl.b #4,d0 ;/* YO XO YS XS S M R L X7 X6 X5 X4 0 0 0 0 */
lsl.l #4,d0 ;/* YO XO YS XS S M R L X7 X6 X5 X4 0 0 0 0 0 0 0 0 */
L13:
btst #4,(a0)
beq.b L13 ;/* handshake */
L14:
move.b (a0),d0 ;/* X3 X2 X1 X0 */
move.b #0,(a0) ;/* next phase */
lsl.b #4,d0 ;/* YO XO YS XS S M R L X7 X6 X5 X4 X3 X2 X1 X0 0 0 0 0 */
lsl.l #4,d0 ;/* YO XO YS XS S M R L X7 X6 X5 X4 X3 X2 X1 X0 0 0 0 0 0 0 0 0 */
L15:
btst #4,(a0)
bne.b L15 ;/* handshake */
L16:
move.b (a0),d0 ;/* Y7 Y6 Y5 Y4 */
move.b #0x20,(a0) ;/* next phase */
lsl.b #4,d0 ;/* YO XO YS XS S M R L X7 X6 X5 X4 X3 X2 X1 X0 Y7 Y6 Y5 Y4 0 0 0 0 */
lsl.l #4,d0 ;/* YO XO YS XS S M R L X7 X6 X5 X4 X3 X2 X1 X0 Y7 Y6 Y5 Y4 0 0 0 0 0 0 0 0*/
L17:
btst #4,(a0)
beq.b L17 ;/* handshake */
L18:
move.b (a0),d0 ;/* Y3 Y2 Y1 Y0 */
move.b #0x60,(a0) ;/* first phase */
lsl.b #4,d0 ;/* YO XO YS XS S M R L X7 X6 X5 X4 X3 X2 X1 X0 Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 0 0 0 0 */
lsr.l #4,d0 ;/* YO XO YS XS S M R L X7 X6 X5 X4 X3 X2 X1 X0 Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 */
L19:
;btst #4,(a0)
;beq.b L19 ;/* wait on handshake */
move.w #0x2000,sr ;enable ints
rts
Download mouse_test8:
http://www.mediafire.com/download/56...ouse_test8.rar
Hi, guys! Thanks for your efforts.
I've just tested the lastest sample, mouse_test8, and it has the same problem with the up movement of the pointer (mouse moved to the forward direction).
gasega68k , maybe it could make things easier for you to comprehend what's going on if you expose more internal variables values of the code in this mouse test.
I can capture it from real hardware and upload the video. So you'd have some sort of "debugger".
Just a thought.
Hi, I've done other tests (5 more) to see if it finally works in both versions of mouse, plus I've added several variables on the screen as suggested Barone, to see the behavior when it fails so I can know what is happening. All variables are updated at a rate of 15fps to see the changes a little easier (at 60fps is almost impossible to see).
"XV" and "YV" shows the amount that will be added to the movement, for example if "XV" shows a value of 12, that amount is added to the X position of the mouse, in the case of "XV" displays a value between 1 and 50 when moved to the right (in the case of "YV" as it moves upwards) and a value between 255 and 200 when moving to the left (in the case of "YV" when moving down ), these values vary depending on the movement of the mouse when movements become faster, these values will be larger.
"XS" and "YS" are a sign, "XS" is 0 when it is moved to the right (for "YS" is when it moves up) and 1 when it moves to the left (for "YS" when down), "XO" and "YO" are overflow, I've never seen them to change, even when very fast mouse movements are made (at least in the emulator Fusion).
In the file I have done 4 tests with a slightly different code that I had before and I've also included a version with the code of the game Marble Madness, which Chilly Willy disassembled, I think at least this version should work (or some of the other four versions) for both versions of mouse, I hope.
And again, I'm asking you to do these tests :sorry:, I really appreciate your help on this, and it will be the last test, because if none works on both mouse, then I have to make two different codes and with an option to choose between one of the two.
Donwload:
http://www.mediafire.com/download/oe...st_9_10_mm.rar
9 = a-okay
9b = fail
10 = fail
10b = fail
marb = fail
This is on a CDX with the MegaMouse. All fails show all vars as 0.
I am very happy that people are touting these amazing works that community is doing.
Unofficial Sega Mega Drive Port Of Wolfenstein 3D Blows Away The Retail Super Nintendo Version
http://www.retrocollect.com/News/uno...o-version.html
I put together a short article for this on Diadu. Let me know what you guys think:
http://www.diadu.net/?p=205
If I got any technical info wrong or if I glossed over anything important let me know and I'll fix it.
Chilly Willy: The versions that fail work with the pad connected to port 1 ?, If so, this means that what is happening is that it is not detecting the mouse at the beginning, because when you start, it is saved in a variable to indicate that the mouse is present and then in the main routine first checks this variable to use the mouse in port 2, or the pad in port 1 (only one of the two will be used).
Anyway if the version 9 also works for Barone, then I'll use that.
TrekkiesUnite118:
Thanks for the article. :)
9 = OK
9b = OK
10 = Same issues of previous versions.
10b = Same issues of previous versions.
marb = OK
JP MD 1 VA6 with Sega Mouse.
Hi!
Sorry for the little delay.
Yeah, looks like version 9 works for both protocols!!! :rock:
I've recorded videos for each version and they'll be up tonight I think.
Thanks!
Here are the videos (.ts file format, I recommend VLC to watch them; raw and unedited, so the coloring is red-ish):
gasega68k's Mouse Test - Marble Madness driver:
https://drive.google.com/file/d/0B0c...ew?usp=sharing
gasega68k's Mouse Test - Custom Driver v9:
https://drive.google.com/file/d/0B0c...ew?usp=sharing
gasega68k's Mouse Test - Custom Driver v9b:
https://drive.google.com/file/d/0B0c...ew?usp=sharing
gasega68k's Mouse Test - Custom Driver v10:
https://drive.google.com/file/d/0B0c...ew?usp=sharing
gasega68k's Mouse Test - Custom Driver v10b:
https://drive.google.com/file/d/0B0c...ew?usp=sharing
I tried to provide all the movements which could reveal something of interest to you, gasega68k and Chilly Willy.
Great job Barone. Chilly Willy and gasega68k are the genius coders, but you Barone are always a big help in projects like this, Pyrons color hacks, etc. So as a Sega fan, thanks to all of you guys.
Special thanks to you gasega68k, this project keep getting better and better, way better than i ever tought Wofenstein 3D would ever be on the Genesis. Its amazing!
I'm very happy to read these kind words 'cause all that I want most to leave some positive contribution to this community. I love the Mega Drive since I was 6 and it still brings me a lot of fun and great things 22 years after that.
However, I have to say that I don't feel like I've given enough contribution yet and I'm sorry for not being as skilled and wise as other members here.
gasega68k has been an unbelievable gift to our community.
I'm here long enough to have read, several times, that the Mega Drive just couldn't deliver a port of Wolfenstein 3D as "good" as the SNES one. Seriously.
"It doesn't have enough RAM", "It can handle 64x64 sprites", "Its hardware is too old to handle something like that", etc.
And gasega68k just proved all that stuff wrong in a classy and definitive fashion. Like I said, the guy is a genius in my book.
Chilly Willy never gets the credit he deserves, though.
The guy has COUNTLESS contributions to the MD's homebrew scene and I think I've never seen he promoting himself or anything like that.
A piece of my heart dies every time someone compares Wolf32X to gasega68K's work in a dismissive way 'cause they're missing the point completely IMO.
Chilly has built a lot of foundations and prepared the path for future contributions with stuff like that; some people don't realize how tough and non-rewarding is to take that role.
Be assured that claiming anything in a different direction than Chilly's, like I did in the mouse discussion, is not an easy and much less "enjoyable" task for me 'cause it's like disagreeing with the foundations of everything I've been studying and trying to apply in the MD scene.
Stef and Kaneda can probably be put in the same group of Chilly (along with some very few other guys), but, sadly for us, those guys aren't so active here as Chilly (Stef has been a lot more lately; our damn luck).
I have the mouse in port 2 and a pad in port 1. I didn't think of trying it with them switched... mainly because my flash cart doesn't work with a mouse in port 1. :)
I'll need to do some rewrites to the flash menu to check the other way around. In the meantime, my mouse is always in port 2 since most games assume a pad in port 1. I wrote Wolf32X to use a pad in port 1 and the mouse in port 2, even though the code to read the mouse was written to work with either port.