Talk:Fixed cycle delay: Difference between revisions
(Re2: No requirements) |
(Formatting & more replies) |
||
Line 1: | Line 1: | ||
== No requirements missing from most examples? == | == No requirements missing from most examples? == | ||
Shouldn't there be a "no requirements" entry for ''every'' example? Isn't that the natural maximum byte size / endpoint for each of these? - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 20:14, 16 March 2016 (MDT) | Shouldn't there be a "no requirements" entry for ''every'' example? Isn't that the natural maximum byte size / endpoint for each of these? - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 20:14, 16 March 2016 (MDT) | ||
: It is not possible to do 3-cycle delay without any requirements. The best you can get is <code>JMP *+3</code> which requires relocations, but does not have any execution-time side-effects. | : It is not possible to do 3-cycle delay without any requirements. The best you can get is <code>JMP *+3</code> which requires relocations, but does not have any execution-time side-effects. Additionally, in the larger delays, "no requirements" would involve a long sequence of "NOP"s followed by a "JMP" if the cycle count is odd. To reduce the size of the page, I omitted these for larger delays. --[[User:Bisqwit|Bisqwit]] ([[User talk:Bisqwit|talk]]) 15:02, 17 March 2016 (MDT) | ||
== Page size problematic? Maybe the wiki sin't the best place for exhaustive permutations... == | == Page size problematic? Maybe the wiki sin't the best place for exhaustive permutations... == | ||
Line 8: | Line 7: | ||
I'm noticing the wiki has some serious problems trying to diff some of the history on this page. I noticed [http://wiki.nesdev.org/w/index.php?title=Fixed_cycle_delay&curid=1621&diff=12038&oldid=12037 this edit] with the comment "Further tweak code to prefer repeated sequences, because reducing the page size helps fend off MediaWiki crashing". Given the explosive nature of permutations here, maybe it would be better to just implement this as a javascript tool on a webpage, and link it from here? (Would also be nice because you could just dial in constraints, etc.) - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 21:02, 16 March 2016 (MDT) | I'm noticing the wiki has some serious problems trying to diff some of the history on this page. I noticed [http://wiki.nesdev.org/w/index.php?title=Fixed_cycle_delay&curid=1621&diff=12038&oldid=12037 this edit] with the comment "Further tweak code to prefer repeated sequences, because reducing the page size helps fend off MediaWiki crashing". Given the explosive nature of permutations here, maybe it would be better to just implement this as a javascript tool on a webpage, and link it from here? (Would also be nice because you could just dial in constraints, etc.) - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 21:02, 16 March 2016 (MDT) | ||
:I'd recommend splitting them by 2-19, 20-100, 100-200, etc. --[[User:Tepples|Tepples]] ([[User talk:Tepples|talk]]) 09:40, 17 March 2016 (MDT) | :I'd recommend splitting them by 2-19, 20-100, 100-200, etc. --[[User:Tepples|Tepples]] ([[User talk:Tepples|talk]]) 09:40, 17 March 2016 (MDT) | ||
:I agree with principle on a Javascript tool, but there is the problem that finding these delay options is rather CPU-time intensive. The running time for my generator program is O(n^2) for the number of cycles to delay. This bodes badly with a tool that would run in the browser. --[[User:Bisqwit|Bisqwit]] ([[User talk:Bisqwit|talk]]) 15:18, 17 March 2016 (MDT) | |||
== Formalizing random writes == | == Formalizing random writes == | ||
Line 14: | Line 14: | ||
A write to a random address in a 256-byte page is fine if all addresses in the page are decoded to nothing, to a read-only memory, to a read-only port without side effects, or to memory that will be overwritten later. Most NES mappers decode $4100-$41FF to nothing. In addition, many games use $0200-$02FF, $0300-$03FF, or $0700-$07FF to hold a [[PPU OAM|display list]] rebuilt from scratch every frame; if the delay occurs before the next rebuild of the display list, there is no conflict. --[[User:Tepples|Tepples]] ([[User talk:Tepples|talk]]) 09:43, 17 March 2016 (MDT) | A write to a random address in a 256-byte page is fine if all addresses in the page are decoded to nothing, to a read-only memory, to a read-only port without side effects, or to memory that will be overwritten later. Most NES mappers decode $4100-$41FF to nothing. In addition, many games use $0200-$02FF, $0300-$03FF, or $0700-$07FF to hold a [[PPU OAM|display list]] rebuilt from scratch every frame; if the delay occurs before the next rebuild of the display list, there is no conflict. --[[User:Tepples|Tepples]] ([[User talk:Tepples|talk]]) 09:43, 17 March 2016 (MDT) | ||
Correct. In fact, utilizing this aspect I tried to think of a way to use "INC abs,X" in a partial-instruction context, but given the constraints there are only a few addresses where one can write safely. Here's a sample: | |||
<pre>A9 FE LDX #$FE ; hides 'INC $FDD0,X | |||
D0 FD BNE *-1</pre> | |||
This would read from $FDD0, read from FDCE, and then write to FECE. Writing to $8000-$FFFF is unsafe in several mappers, so I tried a bit different approaches. | |||
<pre>A9 FE LDX #$3E ; hides 'ROL $3FE0,X' | |||
E0 3F CPX #$3F | |||
D0 FC BNE *-2</pre> | |||
This would read from $3FE0 (maps to $2000; write-only register, so reading is safe), read from $3F1E (maps to $2006; write-only register, so reading is safe), and write to $401E (unmapped, so access is safe). This would be completely safe. However, there is no guarantee that the code will not loop infinitely. I am yet to think of a way where RMW abs,X can be used. I was able to incorporate INC zp,X in a few situations where X is known to be zero, though. --[[User:Bisqwit|Bisqwit]] ([[User talk:Bisqwit|talk]]) 15:18, 17 March 2016 (MDT) |
Revision as of 21:18, 17 March 2016
No requirements missing from most examples?
Shouldn't there be a "no requirements" entry for every example? Isn't that the natural maximum byte size / endpoint for each of these? - Rainwarrior (talk) 20:14, 16 March 2016 (MDT)
- It is not possible to do 3-cycle delay without any requirements. The best you can get is
JMP *+3
which requires relocations, but does not have any execution-time side-effects. Additionally, in the larger delays, "no requirements" would involve a long sequence of "NOP"s followed by a "JMP" if the cycle count is odd. To reduce the size of the page, I omitted these for larger delays. --Bisqwit (talk) 15:02, 17 March 2016 (MDT)
Page size problematic? Maybe the wiki sin't the best place for exhaustive permutations...
I'm noticing the wiki has some serious problems trying to diff some of the history on this page. I noticed this edit with the comment "Further tweak code to prefer repeated sequences, because reducing the page size helps fend off MediaWiki crashing". Given the explosive nature of permutations here, maybe it would be better to just implement this as a javascript tool on a webpage, and link it from here? (Would also be nice because you could just dial in constraints, etc.) - Rainwarrior (talk) 21:02, 16 March 2016 (MDT)
- I'd recommend splitting them by 2-19, 20-100, 100-200, etc. --Tepples (talk) 09:40, 17 March 2016 (MDT)
- I agree with principle on a Javascript tool, but there is the problem that finding these delay options is rather CPU-time intensive. The running time for my generator program is O(n^2) for the number of cycles to delay. This bodes badly with a tool that would run in the browser. --Bisqwit (talk) 15:18, 17 March 2016 (MDT)
Formalizing random writes
"it is difficult to formalize the rules under which one could write to such random addresses."
A write to a random address in a 256-byte page is fine if all addresses in the page are decoded to nothing, to a read-only memory, to a read-only port without side effects, or to memory that will be overwritten later. Most NES mappers decode $4100-$41FF to nothing. In addition, many games use $0200-$02FF, $0300-$03FF, or $0700-$07FF to hold a display list rebuilt from scratch every frame; if the delay occurs before the next rebuild of the display list, there is no conflict. --Tepples (talk) 09:43, 17 March 2016 (MDT)
Correct. In fact, utilizing this aspect I tried to think of a way to use "INC abs,X" in a partial-instruction context, but given the constraints there are only a few addresses where one can write safely. Here's a sample:
A9 FE LDX #$FE ; hides 'INC $FDD0,X D0 FD BNE *-1
This would read from $FDD0, read from FDCE, and then write to FECE. Writing to $8000-$FFFF is unsafe in several mappers, so I tried a bit different approaches.
A9 FE LDX #$3E ; hides 'ROL $3FE0,X' E0 3F CPX #$3F D0 FC BNE *-2
This would read from $3FE0 (maps to $2000; write-only register, so reading is safe), read from $3F1E (maps to $2006; write-only register, so reading is safe), and write to $401E (unmapped, so access is safe). This would be completely safe. However, there is no guarantee that the code will not loop infinitely. I am yet to think of a way where RMW abs,X can be used. I was able to incorporate INC zp,X in a few situations where X is known to be zero, though. --Bisqwit (talk) 15:18, 17 March 2016 (MDT)