Re: VIC-registers

From: Stephen Judd (
Date: 1998-02-27 17:38:57

Hola Ruud,

If you're interested you might take a look at my 816 monitor at

> 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



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 :).


Archive generated by hypermail 2.1.1.