WHDLoad MantisBT - WHDLoad |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0006621 | WHDLoad | [All Projects] General | public | 2024-10-24 22:21 | 2024-12-10 10:28 |
|
| Reporter | JOTD | |
|---|
| Assigned To | Wepl | |
|---|
| Priority | normal | Severity | block | Reproducibility | random |
|---|
| Status | resolved | Resolution | fixed | |
|---|
| Platform | | OS | | OS Version | |
|---|
| Product Version | 19.0 | |
|---|
| Target Version | 19.1 | Fixed in Version | 19.1 | |
|---|
| Machine | A1200 |
|---|
| CPU | 68060 |
|---|
| CPUSpeed | 50 |
|---|
| ChipSet | AGA |
|---|
| GFXCard | None |
|---|
| ChipMem | 2 MB |
|---|
| FastMem | 0 MB |
|---|
| Workbench | OS 3.0 |
|---|
| KickROM | 40 - Kick 3.1 |
|---|
| KickSoft | None |
|---|
| WHDLoad | 19.0 |
|---|
|
| Summary | 0006621: ReadJoyPort parasite outputs |
|---|
| Description | I think the underlying readjoypad routine implemented in whdload has issues.
I've adapted a lot of games to call this implementation and some games have parasite second button reads when using just first button.
>
I've adapted JST adding the resload_ReadJoyPort routine, but using the old
implementation, no timing cache or other complex stuff, and it works properly,
meaning the changes I have done are okay interface-wise.
The game I'm talking about is Jim Power, unreleased in v19 form but ready.
Test it with whdload v19 and "2nd button for jump" you'll notice that the
character jumps from time to time because you're just shooting.
Use latest JST on the same slave and it doesn't occur, not once.
Someone reported the same thing on the new Turrican 2 slave |
|---|
| Steps To Reproduce | run Jim Power slave or Turrican with joypad mode (2nd button jumps)
Firing sometimes triggers jumps or other extre buttons
|
|---|
| Tags | No tags attached. |
|---|
| Relationships | |
| Attached Files |  JimPower_v19_slave.zip (1,998) 2024-10-24 22:21
https://www.whdload.de/mantis/file_download.php?file_id=1841&type=bug |
|---|
|
Notes |
|
|
(0014170)
|
|
DJ Mike
|
2024-10-26 01:27
(Last edited: 2024-10-26 01:28) |
|
Observation from watching joypad reads in Turrican II (WinUAE only at this stage) - all held button bits are shifting up by 1 in some reads - not just spurious red button presses.
i.e. sometimes Red (bit 22) becomes Blue (bit 23), but likewise yellow (21) will become red, green (20) will become yellow, etc.
Blue will alternate between bit 23 and not triggering at all - if you hold down blue to jump in game your character will keep half jumping because the button appears held then not held. :-)
To me it looks like the first potinp test is happening slightly late sometimes, i.e. actual first button (Blue) isn't read in time, so all remaining buttons are treated as Blue onwards when it is supposed to be Red.
I notice that in ReadJoypad.s, the first potinp test is after 6x tst.b $bfe001 instructions (for waiting), but all subsequent potinp tests have 8x tst.b gap. This approach was not taken in resload_ReadJoyPort (all reads have 8x tst.b wait, including first).
|
|
|
|
(0014171)
|
|
DJ Mike
|
2024-10-26 10:41
(Last edited: 2024-10-26 10:43) |
|
Confirmed - shortening the first CIA 8x tst wait to 6x was enough to fix the problem in my testing. I also moved the bset/bclr ciapra calls for the trigger pulse to be adjacent.
All other RJP code left alone. I don't think the caching/TOD timing is an issue here.
|
|
|
|
(0014172)
|
|
Wepl
|
2024-10-26 12:32
(Last edited: 2024-10-26 12:33) |
|
Great investigation!
Yes, I tried to simplfy to code here. Didn't expect that timing is so sensitive at this place.
Can you provide PR/branch?
|
|
|
|
|
I will put together a branch.
One thing I'm not sure about - is the final pulse after all buttons have been read necessary? In original ReadJoyPad.s, additional pulses happen at the end of the loop just before dbf, meaning after the last button has been read there is one final pulse (but no potinp read). In WHDLoad RJP I see that there bclr has been moved to the top of the loop but not the bset.
I wonder if instead both bset/bclr could be at the top so we don't do unnecessary work. However that is a change in behaviour so I'm uncertain. Perhaps it is safest to do what ReadJoyPad was already doing. |
|
|
|
|
Doing some more precise testing on this, it seems the change that matters the most is the order of the initial pulse + potgo set. The following is the order in ReadJoyPad.s:
bset d3,ciaddra(a1) ;set bit to out at ciapra
bclr d3,ciapra(a1) ;clr bit to in at ciapra
move.w d5,potgo(a0)
WHDL version has ciapra + potgo the other way around (with some instructions in between):
bset #CIAB_GAMEPORT1,(ciaddra,a1) ;output mode (trigger pulse)
move #$6f00,(_custom+potgo) ;input mode (data)
moveq #RJPB_BLUE,d2 ;first button to read
moveq #7-1,d3 ;amount of bits/buttons to check
bclr #CIAB_GAMEPORT1,(ciapra,a1) ;trigger pulse low
This order matters! Changing potgo write to be immediately after bclr in the above instructions is enough to fix the problem - not even reducing the number of tst.b instructions makes a difference to my tests.
However I think because we know ReadJoyPad.s works, I will still reduce the initial tst.b instructions as well.
I have pushed a branch with proposed changes. |
|
|
|
(0014202)
|
|
Wepl
|
|
2024-11-13 22:42
|
|
|
|
|
|
|