Re: Quick question about AUXMOVE

[Steve Nickolas <usotsuki@buric.co>]

Somewhere along the line I'm screwing up a memory move... either I'm 
putting the wrong data into auxmem (a quick analysis with EDM shows that 
it's probably correct) or I'm getting the wrong data from auxmem (strange, 
as I don't *think* I've messed up my calculations anywhere in 
fakerwts...).

Here's what I've got now...

http://1.buric.co/lr.derp.zip

lrrl128a.a65 is the source for LR.ALOAD. (LR.MLOAD is an earlier version 
that required handholding - which is why the padding is wacky.)

lrrl128_data3.a65 and lrrl128_data4.a65 generate the LR.DATA3 and LR.DATA4 
files, respectively, which contain the actual packed game code.

lrlvl1.bin and lrlvl2.bin, when concatenated, are the level data, packed 
down to 224 bytes per level instead of 256.

The code is supposed to store lrlvl1.bin and lrlvl2.bin consecutively in 
auxmem starting at 0800, then when B7B5 is hit, to recall the levels into 
main memory, using a lookup table stored from B800-B9FF and a function 
stored at BA00.

That the wrong data is being retrieved can be seen in two ways:

1. The emulation layer passes the engine something weird as "level 1" 
which it chokes on:

   DISKETTE IN DRIVE IS NOT A
   LODE RUNNER DATA DISK.

   HIT ANY KEY TO CONTINUE

2. It shows a bizarre set of high scores as seen in 
http://1.buric.co/lr.derp.png ...

This seems to work better than my last attempt, though...

-uso.