How about the big picture as well?
I have just collected data of the errors in my large programs, which traces the chasing fault in axevsm1.dll, here:
Code:
[U]Program name | Picaxe | Length | Line | Address | What it does wrong at this line and address[/U]
KEYPAD MASTER 15X7 CAPS graphic.bas | 40X1 | 2079B | 545 low 0 | 401F | Command does no effect, continues to next line
| 548 pause 700 | 403A | Stayes on this line 'forever'
KEYPAD MASTER 15X7 CAPS GRAPHIC cfd1.bas | 40X1 | 2063B | 546 if typrel=1 then | 3FFD | [PC=2406]; [PC=241B]; Run then pause: [PC=2426] 'forever'
KEYPAD MASTER 15X7 CAPS GRAPHIC CFD2.bas | 40X1 | 2079B | 545 low 0 | 401F | Command does no effect, continues to next line
| 547 if typrel=1 then | 4030 | Command improperly executed by jumping to the line underneath rather than "else" when typrel =0
| 548 pause 50 | 403A | Terminates: Internal Exception: divide by zero in module 'AXEVSM1.DLL'. (No "let varl=varl/0" etc. in program)
KEYPAD MASTER 15X7 CAPS GRAPHIC CFD3.bas | 40X1 | 2063B | 546 if typrel=1 then | 3FFD | [PC=1C05]; [PC=6272], Invisible "high 0"; [PC=6280]; +$E every step - 50th time=[PC=653C] continues: polled in4, executed "keyled" ("keyled" command not in program), -to [PC=8C79] 'forever'
Graphic lcd for atahdd.bas | 40X1 | 3991B | 790 b0=b0-32 | 4002 | Instead of "b0=b0-32", it does "high 0" instead, Continues to next line
| 791 gosub audatab0 '###... | 4010 | Simulation terminates - Internal Exception: access violation in module AXEVSM1.DLL'.
GRAPHIC LCD FOR ATAHDD cfs1.bas | 40X1 | | 783 next b4 | 3FE7 | Rather than jump under "for b4=0 to 20" on line 778, 3F02, it goes [PC=43F1]; [PC=4403]; [PC=4414]; b0=33; [PC=4451]; [PC=4462]; terminates with "access violation in 'AXEVSM1.DLL'"
GRAPHIC LCD FOR ATAHDD CFS2.bas | 40X1 | | Completely skips this: 778 3FAE if hdb0=hexbin0 then
779 3FF8 w0=ch6line6
780 4010 else
781 4018 w0=ch6line7
782 ---- endif
| 784 b1=autowrite | 4045 | Command does no effect. Continues to next line
| 785 gosub comb1 | 4062 | Program continues to next line without completing this sub-procedure
| 786 for b4=0 to 20 | 407A | Completes sub-procedure "comb1", b4=21, continues to next line
| <Line simulation continues to be off-sync until back under "main".>
symbols & key:
In keypad master 15x7 caps graphic {cfd$}.bas:
symbol typrel=bit3
In graphic lcd for atahdd {cfs$].bas:
symbol hdb0=bit16
symbol hexbin0=1
symbol ch6line6=105
symbol ch6line7=126
symbol autowrite=%10110000
<sub 'audatab0' (including the one that is jumped to: 'dskip' starting on $331B) is between addresses $3189 and $339E>
<sub 'comb1' is between addresses $3611 and $36C9>
every ; means 'then after (another) click on the step button' unless otherwise stated.
on each [pc=####], the code window is blanked, and displays "no source code in pc address [pc=####]."
This concludes that the havoc caused by the chasing fault starts on the commands in the program bit addresses $4000 onwards.
For example, the havoc (incorrect line simulation) starts on b0=b0-32 in bit address $4002, onwards in the program
'Graphic lcd for atahdd.bas'.
This means at the moment, I cannot simulate an X1's program in vsm, that occupies program bit addresses beyond $4000,
without the posibility of getting erratic line simulation on bit address $4000 onwards. Similary, I cannot simulate an X1's
program in vsm that is longer than 2048 bytes, half of 4096.
Remember that it is not any of the command's fault. If any of the commands (including their end commands e.g. 'endif' if
it was 'if ...')
mentioned in the data are put in bit addresses before $4000 rather than in $4000 onwards, they execute correctly.
Does this help you better than posting one full program in posts #34 and #37, to fix this program-space-limiting chasing fault?