
Posted Tue Feb 12, 2019 6:50 AM
Posted Tue Feb 12, 2019 7:11 AM
(a) unlikely
(b) unclear question. why would it be a problem to read two registers within 20ms?
© no plastic piece. closed circuit.
(d) you rom or emulator is broken.
Posted Tue Feb 12, 2019 7:24 AM
sage:
b - I guess this means it's possible. I've read through some dev manuals but there was no mention of this possibility or application. Do you happen to know any emulator or game making use of subframes?
d - I'm pretty sure both the ROM and the emulator is correct. Can you suggest a better emulator so I can test it out?
This U+D/L+R glitch usually have these effects on various platforms and games, but the results are so weird, I'm not sure does it really works the same way on a real console.
Edited by MESHUGGAHTAS, Tue Feb 12, 2019 7:25 AM.
Posted Tue Feb 12, 2019 7:29 AM
sage:
b - I guess this means it's possible. I've read through some dev manuals but there was no mention of this possibility or application. Do you happen to know any emulator or game making use of subframes?
d - I'm pretty sure both the ROM and the emulator is correct. Can you suggest a better emulator so I can test it out?
This U+D/L+R glitch usually have these effects on various platforms and games, but the results are so weird, I'm not sure does it really works the same way on a real console.
(b) the definition of frame, subframe etc... what do you mean?
endless:
lda $FCB0
bne dothis
lda $FCB1
and #$01
bne dothat
bra endless
the cost you ~40us ... vs 20 ms for a frame? whats the deal?
Posted Tue Feb 12, 2019 4:13 PM
Subframe input (where you read input multiple times during frame rendering/buffer swaps) is definitely possible and has been a problem for one of the projects I'm working on. I've had to add some buffering/debounce code to prevent that. Here's a little demo that shows how that can be implemented - https://github.com/i...ffered_joystick
My code goes something like this (not showing actual code just pseudo code to get the idea across)...
while(1) {
joy_read
process inputs
if (not tgi_busy) {
render frame
}
}
Posted Wed Feb 13, 2019 2:45 AM
Thanks for the answers!
sage: Frame as in video frame and subframes input as in multiple input during one frame.
So only the Xybots question remains.
Posted Wed Feb 13, 2019 10:37 AM
Just curious: if pressing up+down simultaneously produces some sort of advantageous result, isn't that a bit outside the realm of human possibility without modifying the console? Or maybe that's why you're trying to find out if there was ever a Lynx that could allow that input out-of-the-box. Or maybe you're looking to do TAS's.
Also, since the d-pad is one solid piece, is it possible to do up+down without also pressing left+right?
Posted Wed Feb 13, 2019 3:08 PM
You can't do opposing direction inputs on these D-pads. If you take the console apart and have a look the D-pad has a central pivot that prevents that from happening, so it's not physically possible to have up+down or left+right pressed at the same time. If you're quick enough and the game hasn't done anything about it, you can press up, down within the space of one frame, though I don't think that's humanly possible.
Posted Wed Feb 13, 2019 4:07 PM
2 - Sub frames input- Is it possible for a game to poll multiple inputs within a single frame ($FCB0, $FCB1)?
I really don't undertand the reason for such a question. Knowing it, could be possible to give an answer, that I think is not so trivial as it could seem IMHO.
while(1) {
joy_read
process inputs
if (not tgi_busy) {
render frame
}
}
Your code is not really trying to check more input events betwen two phisical frames, but betwen two framebuffer swap (If I correctly understood how the screen driver works)
The LCD driver updates the whole LCD at a frequeny (50, 60 or 75 Hz) based on the counter 2 (VBLANK), and it's updated line by line based on counter 0 (HBLANK).
So the original question could be: are the input registers phisically controlled by the buttons state (i.e. their value changes as soon as a button is pressed by simple transistor logic triggerd by the CPU frequency), or is there some hw/sw layer betwen the button input lines and the registers?
In the second case the updates need to be linked at some sort of timing, and since there are only the two previously mentioned timers that aren't general purpose, if the register updates was linked to the HBLANK, their values can change several times during a phisical LCD frame, but if the changes are triggered by the HBLANK, it isn't possible.
This is only speculation. If my reasonings are wrong, please correct me.
Posted Wed Feb 13, 2019 4:11 PM
Yes you're right it's between buffer swaps, but it equates to the same thing for the purpose of this question I think.
Posted Wed Feb 13, 2019 10:55 PM
A small Lynx trivia about buttons. The buttons are mapped to the cart data bus. This means that whenever the Lynx is not reading the cart it can read the buttons. The buttons are mapped into a byte that is read at FCB0
FCB0 JOYSTICK. Read Joystick and Switches(R) If Lefthand=1 If Lefthand=0 B7 = Joy Up (Down) B6 = Joy Down (Up) B5 = Joy Left (Right) B4 = Joy Right (Left) B3 = 0ption 1 0ption 1 B2 = 0ption 2 0ption 2 B1 = Inside Inside B0 = 0utside 0utside FCB1 = SWITCHES. Read Other Switches (R)B7 = 0 B6 = 0 B5 = 0 B4 = 0 B3 = 0 B2 = Cart1 I/0 Inactive B1 = Cart0 I/0 Inactive B0 = Pause (was Flablode)
The same data bus is also read as a cart. They are saving money by re-using the data pins in Suzy for multiple use.
FCB2,FCB3 RCART(R/W)Read or write 8 bits of data. FCB2 uses 'CART0/' as the strobe. FCB3 uses 'CART1/’ as the strobe.
So Suzy is responsible for flipping the buttons whenever the screen is flipped. It is also responsible of the cart read strobes vs joypad reads. So it is up to the programmer when to read the inputs through registers JOYSTICK and SWITCHES or the cart through RCART.
These reads can occur at any time. Even during an interrupt.
Edited by karri, Wed Feb 13, 2019 11:02 PM.
Posted Thu Feb 14, 2019 12:04 AM
Yes you're right it's between buffer swaps, but it equates to the same thing for the purpose of this question I think.
I suppose yes, the purpose of the question is not clear.
Coding games I never needed reading the inputs faster than the framerate, but it could be useful using the input line for some kind of real time probing (on systems where there is an IO port obviously).
An example was the lighgun for systems using a crt for video, where code needs keep reading the input line while the crt is drawing the screen.
Posted Thu Feb 14, 2019 12:58 AM
An example was the lighgun for systems using a crt for video, where code needs keep reading the input line while the crt is drawing the screen.
read the counter at the interrupt which occur when you pressed the button?
Posted Thu Feb 14, 2019 4:32 PM
Just curious: if pressing up+down simultaneously produces some sort of advantageous result, isn't that a bit outside the realm of human possibility without modifying the console? Or maybe that's why you're trying to find out if there was ever a Lynx that could allow that input out-of-the-box. Or maybe you're looking to do TAS's.
Also, since the d-pad is one solid piece, is it possible to do up+down without also pressing left+right?
Yes, I'm making TASes. In the OP I linked a photo of a Lynx with a different d-pad, does it also have a middle pivot, preventing physically pressing l+r/u+d?
Regarding impossible human input: It's known that most controllers gets worned out after playing with a lot of time. So while it's very unreliable, applying big force on the right spot let's you press down those l+r/u+d buttons for at least a few frames.
I really don't undertand the reason for such a question. Knowing it, could be possible to give an answer, that I think is not so trivial as it could seem IMHO.
I have no programming experience in assemblies (apart from very simple stuffs) and especially no on-hand experience with SMS.
I didn't knew there's a possibility that video game consoles poll multiple times rather than just every 30/50/60 frame, so this is still something new information for me and probably many other people.
Now does this means my lengthy tests with the number of polls mentioned and those other tiny facts are "real", valid?
So it is up to the programmer when to read the inputs through registers JOYSTICK and SWITCHES or the cart through RCART.
These reads can occur at any time. Even during an interrupt.
Can you recommend an emulator supporting this, as well as featuring a debugger?
And thank you all for the answers so far
Posted Thu Feb 14, 2019 4:54 PM
The Lynx you linked is a Lynx Model II, you can't press up+down or left+right on that d-pad, there's definitely a pivot in there.
What kind of videos are you making that use the Lynx?
Posted Fri Feb 15, 2019 6:45 AM
The Lynx you linked is a Lynx Model II, you can't press up+down or left+right on that d-pad, there's definitely a pivot in there.
What kind of videos are you making that use the Lynx?
Thanks for the answer!
My (edit:) Tool-Assisted Speedrun projects are on pause until I can make use of debugger tools (currently missing in BizHawk).
Lynx Scrapyard Dog -> new time saver found (pause unpause at score countdown) to published TAS but want to debug the movement glitch and also desyncs at lightning boss http://tasvideos.org...211150738858593
Lynx Electro Cop (has video encode in the link) -> needs route planning (and probably need to remove the fast level trick because it uses the level select code despite I go to level 1) http://tasvideos.org...175305288979821
Lynx Xybots ->
INSERT GAME without crashing http://tasvideos.org...812954781886441
INSERT GAME permanently and lag frames http://tasvideos.org...813160016997614
I don't know my other Lynx projects from the top of my head, probably 2-3 more. edit: Gordo 106 (better optimized movements mostly), Krazy Ace Minature Golf (need to investigate a random desync point that uses nearly same input but changes the ball despite same strength and angle)
Edited by MESHUGGAHTAS, Fri Feb 15, 2019 6:55 AM.
0 members, 1 guests, 0 anonymous users