Re:Dirty tricks 6502 programmers use
by stjo on Monday August 19, 2019 @01:54AM
(#20735233)
I would say no. 34 bytes is 256^32=7588550360256754183279148073529370729071901715047420004889892225542594864082845696 combinations, and even if you could easily narrow it down to only valid programs you would still need to simulate it, which is way slower than computing a hash.
[ Parent
| on HN ]
Only a fraction of those would be reasonable programs, and you can test almost all of them immediately by computing a MD5 hash.
Re:Dirty tricks 6502 programmers use
by userbinator on Monday August 19, 2019 @07:58AM
(#20736964)
34 bytes is equivalent to bruteforcing a 272-bit key. It's already physically impossible to do that for a 256-bit key even if you ignore everything other than incrementing the key counter itself:
But as I said, you’re not brute forcing the entire key space because you likely have an idea of at least some of the bits.
Or, you could evaluate whether said program draws the crossed lines in an emulator. Might not take that much longer than calculating the hash...
That makes this kind of an interesting "Genetic Programming" challenge... The solution space is "only" 29 bytes long...
I don't think that would be this quick either.
Since the code might/will mess up zeropage and/or other dataareas in use by the C64 basic, you would have to wipe it to a known state for each test, which almost means "boot up the KERNAL and let it run complete INIT".
Not that even this have to take a long while on a 3GHz computer running full speed, but doing it 2^272 times ...
> you would have to wipe it to a known state for each test, which almost means "boot up the KERNAL and let it run complete INIT"
FWIW, if I were actually doing this I’d run it in a emulator and “save” the initial state to restore for the every test.