Hola Ruud,
If you're interested you might take a look at my 816 monitor at
http://stratus.esam.nwu.edu/~judd/fridge/programs/jammon/
>
> I'm expanding my disassembler from 6502 to 65C02 (done) and 65816. But I have some
> questions about the 65816:
>
> The D-register is used as an extra offset for a direct addressing mode:
> assume D = $1000
> LDA $1234 results in LDA $2234 in reality
> LDA ($80),Y results in LDA ($1080),Y in reality
> LDA ($80,X) results in LDA ($1080,X) in reality
> Correct?
DP is the "direct page" register. It only affects direct-page instructions.
So LDA $1234 stays as LDA $1234. LDA $12 though is effectively LDA $1012
(although it is still a 2-byte instruction), and your other instructions
are correct.
DBR is an eight bit register, and forms the upper 8-bits of addresses
(non 24-bit addresses). So if DBR = $3D
LDA $1234 = LDA $3D1234
LDA ($80),Y = LDA (DP+$80)+$3D0000+.Y
LDA $123456 = LDA $123456
> Assume D = 0
> Y = 0
> DB = $89
> $80 = $12
> $81 = $34
> $82 = $56
> LDA ($80),Y results in LDA $893412
> LDA [$80],Y results in LDA $563412
> Correct?
Right. Note that you could have just used LDA ($80) and LDA [$80] :).
> If I correctly understand the manual, the Programbank (PB) can be compared with CS in
> Intels 80x86 and the Databank (DB) with DS. Correct?
PBR says what bank code is executing in. DBR says where data fetches and
stores occur. It's been many years since I've programmed an Intel, and
I wasn't any good at it anyways, so I can't compare :).
> Questions regarding an assembler:
>
> LDX loads a value in register X. In the Native mode the Index Select Bit determines of X
> (or Y) is 8 or 16 bits wide. The Memory Status Bit does the same for A (I think). How
> does an assembler know what to do? Telling it (all the time) to use 1 or two bytes in
> some way ????
Note that the only instructions that are affected are immediate mode.
LDX $1234 is the same instruction no matter what, but LDX #$1234 is a
problem since it uses the same opcode.
This is very annoying. My solution (since it's only a monitor) was to
assemble according to whatever the bits are currently set to (according
to the 'r' register command); I then put in a mechanism to change these
bits during assembly. I have heard of one SNES assembler which will
insert the appropriate REP #$30 instruction before assembly (i.e. something
like LDXL #$1234 will insert the appropriate REP or SEP instruction
before the LDX).
> Questions regarding an disassembler:
>
> How does the disassembler know if A/X/Y is 8/16 bit????
Again, I used the current setting of the bits. This was the best I
could think of; otherwise you somehow have to track the bit settings.
But if you started disassembling after the bits were set it would be
all screwed up, etc.
> Does anybody have sources PLUS the binaries for me to test my assembler in the future
> (only 65C02 and 65816 of course)? Until know I tested the assembler by generating
> sourcefiles with my disassembler using the kernels of the C64 and 1541 and comparing the
> result of the assembler with the original binary. But I don't have any sources for the
> other processors and my disassembler doesn't support the 65C02 yet.
> Thanks.
You can try disassembling jammon; both the source and binary are there
in the Fridge. There aren't a lot of 816 opcodes, but they are in
there. The other thing you can do is just manually construct some
binaries (cat >a.out :). I used both of these to test the disassembler.
> Maybe one other question I asked has not reached you: I haven't implemented macro's due
> to the fact I don't have any need for them (I'm sorry but examples you gave me didn't
> convince me) but partly due to the fact I haven't found a simple way to implement them.
Well, I can say that I use macros fairly often. I will give you two examples:
1) In Jammon I use them to make 816 opcodes easy. I think that
>>> rep,$30
>>> per,super
>>> plx
>>> bra,memadj
is quite a lot easier to read (and to type!) than something like
hex af010000 ;LDA $000001
sta ohone
ora #$02
hex 8f010000
2) In the 3d library I have to construct something like 16 routines
for drawing polygons. With macros they look like
LOOP1 DEC YLEFT
BEQ DYL1
UL1 >>> MUPDATE,LEFTXLO;LEFTXHI;LEFTREM;LDY;LDXINT;LDXREM
LCOLMP >>> LCOLUMN
DEC YRIGHT
BNE UR1
>>> DYLINER,ENDMP
RIGHTMP >>> LINERP,RIGHTMM
JMP RCOLMP
UR1 >>> PUPDATE,RIGHTXLO;RIGHTXHI;RIGHTREM;RDY;RDXINT;RDXREM
RCOLMP >>> RCOLUMN
>>> UPYRS,LOOP1
The point is that by splitting things up into macros (that I can
pass parameters to) I can construct a series of complicated routines
just by changing the parameters/macros. Also it makes debugging easy, since
I only have to change a single macro and not 16 massive routines. In fact,
the above routines would have been excruciatingly difficult without macros.
So, macros are really useful for certain things. Honest! :)
Note that these macros are just substitution macros, much like #define.
> The problem I have is storing them so the assembler can easily find them when needed. A
> way to do it is to store each of them as files and read them when needed. Storing them in
> memory could cause problems. An idea is welcome.
What's the problem with storing macro definitions in memory?
> I also invented something for my assembler: comment that is outputted to screen when the
> file is assembled. You can use it during conditioned assembling. In this way you can see
Sounds cool. In Merlin you can toggle screen output; I almost always leave
screen output off though :).
-Steve
Archive generated by hypermail 2.1.1.