2018-09-28 17:05:11 +00:00
|
|
|
### 6502bench SourceGen dis65 v1.0 ###
|
|
|
|
|
{
|
2020-03-19 00:45:06 +00:00
|
|
|
"_ContentVersion":3,
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"FileDataLength":62,
|
|
|
|
|
"FileDataCrc32":946946401,
|
2020-03-19 00:45:06 +00:00
|
|
|
"ProjectProps":{
|
|
|
|
|
"CpuName":"65816",
|
|
|
|
|
"IncludeUndocumentedInstr":false,
|
|
|
|
|
"TwoByteBrk":false,
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"EntryFlags":32702671,
|
2020-03-19 00:45:06 +00:00
|
|
|
"AutoLabelStyle":"Simple",
|
|
|
|
|
"AnalysisParams":{
|
|
|
|
|
"AnalyzeUncategorizedData":true,
|
|
|
|
|
"DefaultTextScanMode":"LowHighAscii",
|
|
|
|
|
"MinCharsForString":4,
|
|
|
|
|
"SeekNearbyTargets":true,
|
|
|
|
|
"SmartPlpHandling":true},
|
|
|
|
|
|
|
|
|
|
"PlatformSymbolFileIdentifiers":[],
|
|
|
|
|
"ExtensionScriptFileIdentifiers":[],
|
|
|
|
|
"ProjectSyms":{
|
2018-09-28 17:05:11 +00:00
|
|
|
}},
|
2020-03-19 00:45:06 +00:00
|
|
|
|
2018-09-28 17:05:11 +00:00
|
|
|
"AddressMap":[{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Offset":0,
|
|
|
|
|
"Addr":4096}],
|
|
|
|
|
"TypeHints":[{
|
|
|
|
|
"Low":0,
|
|
|
|
|
"High":0,
|
|
|
|
|
"Hint":"Code"}],
|
|
|
|
|
"StatusFlagOverrides":{
|
2018-09-28 17:05:11 +00:00
|
|
|
},
|
2020-03-19 00:45:06 +00:00
|
|
|
|
2018-09-28 17:05:11 +00:00
|
|
|
"Comments":{
|
|
|
|
|
},
|
2020-03-19 00:45:06 +00:00
|
|
|
|
2018-09-28 17:05:11 +00:00
|
|
|
"LongComments":{
|
|
|
|
|
"-2147483647":{
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"Text":"Project file was edited to force ASCII formatting for some operands.",
|
2020-03-19 00:45:06 +00:00
|
|
|
"BoxMode":false,
|
|
|
|
|
"MaxWidth":80,
|
|
|
|
|
"BackgroundColor":0}},
|
|
|
|
|
|
2018-09-28 17:05:11 +00:00
|
|
|
"Notes":{
|
|
|
|
|
},
|
2020-03-19 00:45:06 +00:00
|
|
|
|
2018-09-28 17:05:11 +00:00
|
|
|
"UserLabels":{
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
},
|
2020-03-19 00:45:06 +00:00
|
|
|
|
2018-09-28 17:05:11 +00:00
|
|
|
"OperandFormats":{
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"7":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Decimal",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"10":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Decimal",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"13":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Binary",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"19":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Decimal",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"22":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Decimal",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"25":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Binary",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"32":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":4,
|
|
|
|
|
"Format":"NumericLE",
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"SubFormat":"Decimal",
|
2020-03-19 00:45:06 +00:00
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"36":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":4,
|
|
|
|
|
"Format":"NumericLE",
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"SubFormat":"Decimal",
|
2020-03-19 00:45:06 +00:00
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"40":{
|
|
|
|
|
"Length":4,
|
2020-03-19 00:45:06 +00:00
|
|
|
"Format":"NumericLE",
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"SubFormat":"Binary",
|
2020-03-19 00:45:06 +00:00
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"44":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Ascii",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"47":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"HighAscii",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"50":{
|
2020-03-19 00:45:06 +00:00
|
|
|
"Length":3,
|
|
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Ascii",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"53":{
|
|
|
|
|
"Length":4,
|
2020-03-19 00:45:06 +00:00
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"Ascii",
|
|
|
|
|
"SymbolRef":null},
|
|
|
|
|
|
Split 2002x-operand-formats test
My original goal was to add a sign-extended decimal format, but that
turned out to be awkward. It works for data items and instructions
with immediate operands (e.g. "LDA #-1"), but is either wrong or
useless for address operands, since most assemblers treat integers
as 32-bit values. (LDA -1 is not LDA $FFFF, it's LDA $FFFFFFFF,
which is not useful unless your asm is doing an implicit mod.)
There's also a bit of variability in how assemblers treat negative
values, so I'm shelving the idea for now. I'm keeping the updated
tests, which are now split into 6502 / 65816 parts.
Also, updated the formatter to output all decimal values as unsigned.
Most assemblers were fine with negative values, but 64tass .dword
insists on positive. Rather than make the opcode conditional on the
value's range, we now just always output unsigned decimal, which
all current assemblers accept.
2020-06-09 00:47:26 +00:00
|
|
|
"57":{
|
|
|
|
|
"Length":4,
|
2020-03-19 00:45:06 +00:00
|
|
|
"Format":"NumericLE",
|
|
|
|
|
"SubFormat":"HighAscii",
|
|
|
|
|
"SymbolRef":null}},
|
|
|
|
|
|
|
|
|
|
"LvTables":{
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
"Visualizations":[],
|
|
|
|
|
"VisualizationAnimations":[],
|
|
|
|
|
"VisualizationSets":{
|
|
|
|
|
}}
|
