How to determine the addressing mode?
MarkLim
attempted to do the same for the "PRODOS EDITOR-ASSEMBLER // RELEASE
1.1 01-MAY-85"
Despite spending many hours at it, I could not fully understand the
source code generated for the module called EDASM.ASM. In particular,
the code (located @ $8537) for parsing the operand field of a 6502
instruction looks complicated. It makes use of values from 3 tables
located @ $DADF, $D7D7 and $D806
(LCBank2) to determine the addressing mode of a 65C02 instruction.
At $DADF, there is a pseudo opcode/directives/mnemonics table. A few
entries together with some comments are listed below:
LDADF EQU *
LtrA DCI 'ADC' ;6502 mnemonics
DB $03 ;flag byte
DB $FF ;Is this a flag byte?
DB $00 ;index to opcode table @ $D835
DCI 'ADD' ;SW16 pseudo opcode
DB $40
DB $02
DB $B7
DCI 'AND'
DB $03
DB $FF
DB $09
DCI 'ASC' ;DIRECTIVE
DB $80
DDB L8DD2-1 ;JMP addr of directive handler
My guess is the first byte following a mnemonics/pseudo opcode is a
flag byte. It's not clear what's the 2nd byte; it looks like another
flag byte. The 3rd byte is definitely an offset into the opcode table
at $D835. Could someone care to elaborate on the what the various bits
of both flag bytes represent?
The first 16 bytes of the two tables (or sub-tables) @ $D7D7 and $D806
are listed below;
LD7D7 HEX 300A005A800ACD8
HEX A9A0020F0619A9AC
: : : : : :
: : : : : :
LD806 HEX 0400B40019000EAA
HEX AAB40C00AE00AA14
: : : : : :
: : : : : :
Both tables are 47 bytes long. The code @ $8537 seems to be using the
values of sub-table @ $D7D7 for parsing the operand field and the
values @ $D806 for indexing and error codes.
Could someone care to elaborate on how the addressing mode is
obtained?
John B. Matthews
<e4c16e40-fc69-46e3...@a39g2000pre.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
> Encouraged by Willie Kusch's effort at disassembling BUGBYTER, I
> attempted to do the same for the "PRODOS EDITOR-ASSEMBLER // RELEASE
> 1.1 01-MAY-85"
Oddly, at file offset $f3f, the date is 30-APR-85 22:46, but the splash
screen says 01-MAY-85.
> Despite spending many hours at it, I could not fully understand the
> source code generated for the module called EDASM.ASM. In particular,
> the code (located @ $8537) for parsing the operand field of a 6502
> instruction looks complicated. It makes use of values from 3 tables
> located @ $DADF, $D7D7 and $D806 (LCBank2) to determine the
> addressing mode of a 65C02 instruction.
>
> At $DADF, there is a pseudo opcode/directives/mnemonics table. A few
> entries together with some comments are listed below:
[...]
> My guess is the first byte following a mnemonics/pseudo opcode is a
> flag byte. It's not clear what's the 2nd byte; it looks like another
> flag byte. The 3rd byte is definitely an offset into the opcode
> table at $D835. Could someone care to elaborate on the what the
> various bits of both flag bytes represent?
>
> The first 16 bytes of the two tables (or sub-tables) @ $D7D7 and
> $D806 are listed below;
>
> LD7D7 HEX 300A005A800ACD8
I think this should be A300A005A800ACD8.
LD7D7
07d7: a3 00 a0 05 a8 00 ac d8 a9 a0 02 0f 06 19 a9 ac
07e7: d9 a0 02 0d a0 06 02 11 13 04 15 8d 15 bb 15 00
07f7: a0 02 03 01 ac d8 a0 02 07 09 d9 a0 02 17 0b
LD806
0806: 04 00 b4 00 19 00 0e aa aa b4 0c 00 ae 00 aa 14
0816: aa b4 ae 00 b4 18 18 00 00 1b 00 1d 00 1f 00 00
0826: 24 23 00 00 b4 2a b4 29 00 00 ac b4 2e 00 00
LDADF
0adf: 41 44 c3 03 ff 00 ADC
0ae5: 41 44 c4 40 02 b7 ADD
0aeb: 41 4e c4 03 ff 09 AND
0af1: 41 53 c3 80 8d d1 ASC
0af7: 41 53 cc 02 1b 12 ASL
0afd: 42 c3 48 03 b8 BC
0b02: 42 43 c3 08 03 17 BCC
0b08: 42 43 d3 08 03 18 BCS
0b0e: 42 45 d1 08 03 19 BEQ
0b14: 42 47 c5 08 03 18 BGE
0b1a: 42 49 d4 00 1f 1a BIT
0b20: 42 cb 60 00 b9 BK
0b25: 42 4c d4 08 03 17 BLT
0b2b: 42 cd 48 03 ba BM
0b30: 42 4d b1 48 03 bb BM1
0b36: 42 4d c9 08 03 1f BMI
0b3c: 42 4e c3 48 03 bc BNC
0b42: 42 4e c5 08 03 20 BN
0b48: 42 4e 4d b1 48 03 bd BNM1
0b4f: 42 4e da 48 03 be BNZ
I see a mixture of 6502, 65C02 and Sweet-16 opcode mnemonics. ADC and
AND can have eight addressing modes, while the branches only have one;
but I don't see which is which. Neil Parker's 6502/65C02/65C816
Instruction Set may help:
<http://www.llx.com/~nparker/a2/opcodes.html>
> Both tables are 47 bytes long. The code @ $8537 seems to be using the
> values of sub-table @ $D7D7 for parsing the operand field and the
> values @ $D806 for indexing and error codes.
>
> Could someone care to elaborate on how the addressing mode is
> obtained?
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
John B. Matthews
"John B. Matthews" <nos...@nospam.invalid> wrote:
[...]
> Neil Parker's 6502/65C02/65C816 Instruction Set may help:
>
> <http://www.llx.com/~nparker/a2/opcodes.html>
For reference, here's formatted binary dump of the three tables, along
with some code:
<http://sites.google.com/site/trashgod/edasm>
MarkLim
> Neil Parker's 6502/65C02/65C816 Instruction Set may help:
I agree this instruction table is useful for deciphering the table
located @ $D835
The info you posted
http://home.roadrunner.com/~jbmatthews/a2/rel.html
is also useful. I use it for comparison against that recorded in the
assembler's manual.
Mark
On Nov 29, 9:33 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article <nospam-F7F061.16552828112...@news.aioe.org>,
John B. Matthews
<e179c89f-cac8-4efb...@j9g2000prh.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
> Hi John,
>
> > Neil Parker's 6502/65C02/65C816 Instruction Set may help:
>
> I agree this instruction table is useful for deciphering the table
> located @ $D835
I hadn't looked this before; any speculation? I see the bytes at $D835
are replicated at $D875 with bit 5 clear:
000835: 6d 65 69 75 7d 79 71 61 72 meiu}yqar
000875: 4d 45 49 55 5d 59 51 41 52 MEIU]YQAR
> The info you posted
>
> <http://home.roadrunner.com/~jbmatthews/a2/rel.html>
>
> is also useful. I use it for comparison against that recorded in the
> assembler's manual.
Excellent. Let me know if you find any discrepancies. I also updated
this site with some guesses about the flag bytes in the opcode table at
$D835:
<http://sites.google.com/site/trashgod/edasm>
I used DumpCodes & grep to search for common bit patterns, e.g.
$ java DumpCodes | grep "^.....1"
00000100 00100111 01011101 LDX
00000100 00000011 10100000 STX
MarkLim
> I hadn't looked this before; any speculation? I see the bytes at $D835
> are replicated at $D875 with bit 5 clear:
>
> 000835: 6d 65 69 75 7d 79 71 61 72 meiu}yqar
> 000875: 4d 45 49 55 5d 59 51 41 52 MEIU]YQAR
At location $D835: ADC opcodes - 9 addressing modes
This table is 213 bytes long.
> > The info you posted
>
> > <http://home.roadrunner.com/~jbmatthews/a2/rel.html>
>
> > is also useful. I use it for comparison against that recorded in the
> > assembler's manual.
>
> Excellent. Let me know if you find any discrepancies. I also updated
> this site with some guesses about the flag bytes in the opcode table at
> $D835:
>
> <http://sites.google.com/site/trashgod/edasm>
>
Your table $0ADF has given me another perspective on those flag bytes
viz. grouping bits 0 and 1 together. Thanks.
> The info you posted
> <http://home.roadrunner.com/~jbmatthews/a2/rel.html>
> is also useful. I use it for comparison against that recorded in the
> assembler's manual.
Since you already have a page detailing a lot of information on using
the EDASM package, may I venture to suggest you include pseudo codes/
directives for the Linker 1.0.
Mark
MarkLim
0-1 11 ADC, AND, CMP, EOR, LDA, ORA, SBC, STA.
0-1 10 ASL, DEC, INC, LSL, LSR, ROL, ROR.
0-1 00 BIT/CPX/CPY/LDY/STY/STZ/TSB/TRB
John B. Matthews
<4c8f4881-e540-4067...@y32g2000prd.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
> > Excellent. Let me know if you find any discrepancies. I also
> > updated this site with some guesses about the flag bytes in the
> > opcode table at $D835:
> >
> > <http://sites.google.com/site/trashgod/edasm>
> >
>
> Your table $0ADF has given me another perspective on those flag bytes
> viz. grouping bits 0 and 1 together. Thanks.
Excellent. The groupings seem to reflect Neil Parker's formulation.
> > The info you posted
>
> > <http://home.roadrunner.com/~jbmatthews/a2/rel.html>
>
> > is also useful. I use it for comparison against that recorded in
> > the assembler's manual.
>
> Since you already have a page detailing a lot of information on using
> the EDASM package, may I venture to suggest you include pseudo
> codes/ directives for the Linker 1.0.
I'm at a loss. What pseudo codes? REL? ZDEF/ZREF?
John B. Matthews
<cf9c1f7b-f2ba-49d6...@k13g2000prh.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
Aha! So maybe in group "11", the second byte's bit 2 is immediate mode,
as it's the only one clear for STA?
$ java DumpCodes | grep "^00000011"
00000011 11111111 00000000 ADC
00000011 11111111 00001001 AND
00000011 11111111 00101010 CMP
00000011 11111111 01000000 EOR
00000011 11111111 01010100 LDA
00000011 11111111 01101110 ORA
00000011 11111111 10001011 SBC
00000011 11111011 10010111 STA
$ java DumpCodes | grep "^00000010"
00000010 00011011 00010010 ASL
00000010 00011011 00111001 DEC
00000010 00011011 01001001 INC
00000010 00011011 00010010 LSL
00000010 00011011 01101000 LSR
00000010 00011011 01111111 ROL
00000010 00011011 10000100 ROR
$ java DumpCodes | grep "^00000000"
00000000 00011111 00011010 BIT
00000000 00000111 00110011 CPX
00000000 00000111 00110110 CPY
00000000 00011111 01100011 LDY
00000000 00001011 10100100 STY
00000000 00011011 10101000 STZ
00000000 00000011 10101111 TRB
00000000 00000011 10110001 TSB
MarkLim
>
> I'm at a loss. What pseudo codes? REL? ZDEF/ZREF?
>
Some of the directives accepted by the ProDOS Linker 1.0 :ORG, ALN,
OPT, REL/SYS/BIN
John B. Matthews
<2e354605-e1fa-4de6...@z3g2000prd.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
Sorry, I only have "ProDOS Assembler Tools," part number #A2W0013.
I've only used RBOOT and RLOAD. I had no idea there was a linker.
MarkLim
MarkLim
> Aha! So maybe in group "11", the second byte's bit 2 is immediate mode,
> as it's the only one clear for STA?
That's a good point. The two flag bytes (called Byte 0 and Byte 1
according to your table at google's site) are used in AND/BIT
operations before the addressing mode is finally determined. I can
confirm Byte 2 is an index (offset) into the opcode table @ $D835.
Let's look at this line from your DumpCodes
00000011 11111111 00101010 CMP
Byte 2 in hexdec is $2A.
$D835+$2A=$D85F
Location $D85F is the start of CMP opcodes (9 of them)
Coming back to the code @ $8537 which I mentioned in my 1st post.
IMHO, it is some sort of "micro-interpreter"; the tokens in table
$D7D7 may be commands to the the intrepreter.
LD7D7
07d7: a3 00 a0 05 a8 00 ac d8 a9 a0 02 0f 06 19 a9 ac
07e7: d9 a0 02 0d a0 06 02 11 13 04 15 8d 15 bb 15 00
07f7: a0 02 03 01 ac d8 a0 02 07 09 d9 a0 02 17 0b
If you look at the 47 bytes (posted in one of your replies), you will
notice that the tokens A3, A8, AC, BB, D8, A9, D9 are # ( , ; X ) Y
(msb on) respectively.
I think if one understands the meaning of the other tokens, its
possible to get the code @ $8537 to process operand fields with [, ],
s
Mark
MarkLim
> I think if one understands the meaning of the other tokens, its
> possible to get the code @ $8537 to process operand fields with [, ],
> s
I think I should re-phrase this line to read:
...its possible to"instruct" the code @ $8537 to parse operand fields
which includes [, ], s etc as part of their syntax.
MarkLim
I believe we are heading in the right direction. The 8 bits of the 2nd
flag byte (Byte1 on your table) may be interpreted as:
Bit Addressing Mode
7 (zp,X)
6 (zp),Y
5 abs,Y
4 abs,X
3 zp,X
2 #
1 zp
0 abs
Several checks were made to test this idea. Let's look at several
lines from your DumpCodes listing.
> 00000010 00011011 00111001 DEC
bits 4, 3, 1, 0 are set. So we have
DEC abs,X
DEC zp,X
DEC zp
DEC abs
Another one:
> 00000000 00000011 10101111 TRB
Bits 1, 0 are set.
TRB zp
TRB abs
One last one:
> 00000000 00001011 10100100 STY
Bits 3, 1, 0 are set. Therefore,
STY zp,X
STY zp
STY abs
Other checks made were for BIT, CPX, CPY. All these conform to the
suggested interpretation.
There are several "odd man out" cases viz the 65C02 mode (zp), JMP
(abs) and JMP (abs,X)
Regards. I hope Antoine is following the discussion.
Mark
Toinet
>
> Regards. I hope Antoine is following the discussion.
>
> Mark
I am following or trying to, a little bit desesperate to find some
spare time to work on the subject but I think you will succeed before
I can use the disk image.
antoine
John B. Matthews
<2b9d60f9-8127-49bd...@j24g2000yqa.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
> I believe we are heading in the right direction. The 8 bits of the 2nd
> flag byte (Byte1 on your table) may be interpreted as:
>
> Bit Addressing Mode
> 7 (zp,X)
> 6 (zp),Y
> 5 abs,Y
> 4 abs,X
> 3 zp,X
> 2 #
> 1 zp
> 0 abs
I've updated the page to reflect this new information:
<http://sites.google.com/site/trashgod/edasm>
> Several checks were made to test this idea. Let's look at several
> lines from your DumpCodes listing.
>
> > 00000010 00011011 00111001 DEC
>
> bits 4, 3, 1, 0 are set. So we have
>
> DEC abs,X
> DEC zp,X
> DEC zp
> DEC abs
>
> Another one:
> > 00000000 00000011 10101111 TRB
>
> Bits 1, 0 are set.
> TRB zp
> TRB abs
>
> One last one:
> > 00000000 00001011 10100100 STY
>
> Bits 3, 1, 0 are set. Therefore,
> STY zp,X
> STY zp
> STY abs
>
> Other checks made were for BIT, CPX, CPY. All these conform to the
> suggested interpretation.
Excellent. I modified the format of the opcode table to reflect your
interpretation of Byte 2 (the third byte after the opcode mnemonic) as
an index into the table at $D835.
> There are several "odd man out" cases viz the 65C02 mode (zp), JMP
> (abs) and JMP (abs,X)
>
> Regards. I hope Antoine is following the discussion.
--
MarkLim
> Excellent. I modified the format of the opcode table to reflect your
> interpretation of Byte 2 (the third byte after the opcode mnemonic) as
> an index into the table at $D835.
Thanks; the way you present the information may be help me or someone
out there take on a different perspective.
Mark
John B. Matthews
<669306cd-da1d-4618...@r24g2000prf.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
Please feel free to incorporate anything on the page into whatever
results you publish. I cleaned up the code a the bottom of the page in
case anyone wants to re-use it in similar work:
<http://sites.google.com/site/trashgod/edasm>
MarkLim
>
> Please feel free to incorporate anything on the page into whatever
> results you publish. I cleaned up the code a the bottom of the page in
> case anyone wants to re-use it in similar work:
>
> <http://sites.google.com/site/trashgod/edasm>
>
Thanks.
To continue, the area $D41E-$D7D6 is concentrated with messages
specific to EdAsm.Asm; these include warnings and error messages. A
table of pointers @ $D3D4 is used to access most of these messages.
There is another table @ $D90A. The first 9 bytes are:
$D90A: 04 03 02 04 04 04 05 06 05
These bytes corresponds to the opcodes:
$D835: 6d 65 69 75 7d 79 71 61 72 meiu}yqar
and are the instruction cycles of these opcodes.
Mark
John B. Matthews
<38828519-7a82-4ef9...@15g2000prz.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
> To continue, the area $D41E-$D7D6 is concentrated with messages
> specific to EdAsm.Asm; these include warnings and error messages. A
> table of pointers @ $D3D4 is used to access most of these messages.
>
> There is another table @ $D90A. The first 9 bytes are:
>
> $D90A: 04 03 02 04 04 04 05 06 05
>
> These bytes corresponds to the opcodes:
>
> $D835: 6d 65 69 75 7d 79 71 61 72 meiu}yqar
>
> and are the instruction cycles of these opcodes.
I've updated the page to reflect this new information
and added a few internal links. Let me know of any errata:
<http://sites.google.com/site/trashgod/edasm>
So far, I've focused on the data; how's the code coming?
What disassembler are you using? I presume you're targeting
EdAsm itself. I've previously used d65, which accepts a file
of labels:
<http://www.npsnet.com/danf/cbm/cross-development.html>
I see there's an alpha version of dxa, which evolved from d65:
<http://www.floodgap.com/retrotech/xa/#dxa>
Toinet
Is there a documentation somewhere? I found the "?" key, I have been
able to load a file but how do you assemble? I mean easily, I have
Toinet
...a Macbook which has a mousepad to the left and the right of the
real mousepad and it is more than annoying. The more days, the less I
like my Mac but that is off-topic....
...found the assemble command but I cannot use it (I don't understand
what to enter) - There are some source files that I would like to see
assembled one line after the other (just like with Merlin I am using)
but I don't know how to do that.
I am useless on that one :-(
antoine
John B. Matthews
<db8d551a-d32b-4e48...@t18g2000vbj.googlegroups.com>,
Toinet <antoine...@laposte.net> wrote:
<http://home.roadrunner.com/~jbmatthews/a2/rel.html#tbla1>
Use NEW to empty the edit buffer and ASM to assemble a file.
Has anyone seen this error:
ERR: PRODOS ERROR=$2F
ASSEMBLY ABORTED. PRESS RETURN
I'm getting it running the assembler in one emulator, but not it either
of two others.
Toinet
The only error I encountered was $43 while launching the SYS file from
my compact-flash card.
antoine "asm" vignau
John B. Matthews
<8ef963b8-067e-4617...@x15g2000vbr.googlegroups.com>,
Toinet <antoine...@laposte.net> wrote:
Welcome to EdAsm!
BTW, I found a reference to error $2F, Device off-line. Apparently, it's
not listed in the ProDOS 8 Technical Reference Manual:
<http://www.artofhacking.com/IET/PRGM/live/aoh_prodos.htm>
MarkLim
> Has anyone seen this error:
>
> ERR: PRODOS ERROR=$2F
> ASSEMBLY ABORTED. PRESS RETURN
>
From my experience, it seems EdAsm must be boot with ProDOS8 v1.1 for
it to work properly. EdAsm's command interpreter will swap ProDOS code
located in LCBank2 with a module of the Editor. When you type "ASM
filename", the CI will load the Assembler's modules and move code to
LCBank2. After assembly, the CI will re-load the Editor's modules etc.
John B. Matthews
<8a100dc3-1280-476f...@13g2000prl.googlegroups.com>,
MarkLim <mark...@yahoo.com.sg> wrote:
Interesting. EdAsm assembles correctly under ProDOS 2.0.3 on two of the
three emulators I tried. Reverting to 1.1.1 on the affected emulator
restores normal operation. Possibly that emulator's bank switching is
errant. I'll investigate further and report in c.e.a.
Thanks for suggesting this.
MarkLim
> So far, I've focused on the data; how's the code coming?
Comments have been added to the initial source generated by TFBD (aka
Phoenix) resulting in a doubling of the total file size. That's the
easy part. The difficult part are the nitty-gritty details of each
subroutine especially the flags.
Mark