I see.

So, if .dpage is set to $DF00, and I have "LFA $DF01" (assembled normally as absolute addressing AD 01 DF), the assembler will convert that to a "LDA $01", assembled as direct page addressing A5 01?

Rather than assuming that anything under 1 byte is an offset to DPAGE?

Here's a pathological example

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

The thing that probably tripped you up is that the C compiler doesn't support 65816, but the assembler & linker do.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

That's very interesting. I don't think I would ever have view Direct Page like that.

Sorry for the very late reply, got deep into working on this thing.

Presently, my assembler makes no assumptions about where the direct page is. You configure where you want DP to be at startup, and the assembler will lay out any vars you declare as DP vars there. The one issue here is the DP cannot be relocated at runtime (other than initially setting it to where the assembler is told it will be at) yet, as I do not have a system for changing that up.

I realise that this creates another conundrum now, the one you've been pointing me to, that LDA $00 could be either DP or not, but it must be assembled correctly.

The way that I set up compiling is not optimal at this point, it was much better than my original design, but I realize now it will be better to determine addressing mode before passing information to compiling code. Because of this, I'll probably rewrite that system so it takes in addressing modes along with the data, and then spits out an opcode plus the data appended.

Until then, it may be dangerous to relocate the DP on my system. Fortunately, this isn't an incredibly hard fix, it will just be tedious.

I'm going to push my code soon and put some release information here, I've added lots of features (.BYTES directive, CONST vars (that get values written into EEPROM at a location determined by the assembler from parameters setting where CONST vars should be stored) bug fixes to some compilation stuff, and the ability to connect over serial to an arduino EEPROM programmer like the one I built (and I may extend functionality to others out there like it, and eventually let it talk directly to the computer over a serial connection)).

I think that I didn't quite realize what dangers you were pointing me to until I wrote this message. At the very least, I can protect against it by requiring some form of denotation when accessing the DP, to ensure that the correct opcode is used.

My assembler simply assumes if the destination address is <= $FF, it's a direct page access. What you more likely need is a way to tell the assembler that you want ABSolute addressing instead of DP. Similarly, you might want something that forces LONG addressing instead of ABS.

But the WDC book I think has notes on how the assembler they use handles these issues.

Bitwise's technique of using a directive, and then use "absolute" addresses that are adjusted to DP if appropriate, is pretty foreign to me.

The $00ea in my example is just a hex number expressed with four digits it does not signify the address mode. Normally 65xx assemblers generate the shortest instruction that matches the operands so you get direct page addresses when possible and absolute otherwise.

The WDC standard is to use <, ! and > to force direct page, absolute and long addressing respectively when you need to control the generated instruction (e.g. lda !$ea generates an absolute lda).

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Oh, I understand that. What's foreign to me is using the assembler to create the offsets, rather than specifying the offsets yourself.

I'm no assembler guru, but what little I've done and I've seen, I've not seen that idiom before.

The 6502 is kind of rife with examples of looking at an instruction at not being able to, in isolation, know what it will assemble to. Leveraging the offset mechanic with the dpage pseudo-op just adds more to it.

Doesn't make it wrong, just different.

Simply said, if that were available to me, I don't think I would use that mechanism.

I just pushed a new release, v 0.0.4, added quite a few nice things to it, and I really think it's beginning to mature a bit. I've used it to successfully compile the display driver I've been working on, along with some other programs. My next goal with it is to fix the issue with DP detection, and to flesh out the newly added .include directive (it currently does not detect macros or vars in the file it includes, so there could be clashing).

There's a bug with .includes in the current release, and bugs with .ML as well, and a couple other issues, I have them fixed locally, and I'll push once I have a few other things done. Is there anything specific that I should be focused on adding? I know that assemblers exist and people aren't likely to switch, but are there features that any of you find very necessary to any assemblers you use?

Separate assembly and linkage. I use this all the time with my system. So a project might have many files, assembled individually controlled via a Makefile, then a final linking stage which resolves all the symbols, fixes the relocation data and creates a binary.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That's a valid point Garth. The linker and the librarian, among other things, were techniques to improve development times. The librarian is tied as much to the limitations of file systems as much as anything, since many did not do well with hundreds of files. And object files skipped the "expensive" assembly step.

Today, those are all free. Well, almost free. Kind of free.

As an example, simply go and fetch the distribution for cc65, and build it on a handy Linux box.

Part of the build process is creating libraries for a sundry of platforms (Apple, C64, etc.). On my Mac, with it's creaky 3.4Ghz Intel Core I7 and SSDs, take almost 2m 30s to build all of the libraries, using ca65.

OH NO! 2m 30s!! you cry. Yea, not a lot. 1500 files.

I tell you what 2m 30s is. It's not 2m. Or 1m 30s.

Back in the day, I'd kick off a build and pick up a book. Nowadays, I'm just not quite that patient any more.

My project at the office is 2000+ files, 800K of source code, which generates 9M of object code, and, inevitably, creates a 2GB artifact of assets and library code (that is also copied after it's created).

It does that (from "clean") in 2m 50s.

I find this is too long, and go through efforts to speed it up to shrink my turnaround cycle.

So, while you're absolutely right. Just using includes can be quite fast, but maybe using the linker is faster.

MY interest in the linker is secondary, more so interested in the object format to hopefully use that for an actual Loader.

Writing an assembler is one thing. Writing a linker is another. I honestly imagine writing a basic linker is easier than writing an assembler, but I have not done one yet. You first need an assembler to create the object files for your linker.

I am currently fixated on the cc65 toolset, I haven't had time to make it work for me. But it seems to have everything I might want.

This is lieu of fixing my assembler. Adding in macros and '816 support is just more of an effort than I'm interested in. The scoping and object files of the cc65 suite seem to suit me, as long term I am keen on relocating code and having a working loader for my system.

So it does seem to be fore when much of the code you're working with is not your own, whether it's from team mates or a supplier that provides loads of header files. The biggest projects I've worked on had 10,000 lines, but it's more common to have 1,000 lines plus my structure-macro INCLude files. When I said "a few seconds," I really did mean a few, like under five seconds on a modern PC.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It lets me build up librarys of routines to be re-used, if needed. I also find it easier to manage projects that way - so currently my OS is 12 .s files with corresponding .h files. I know that speed really isn't the issue on a modern PC though even when I type 'make' it only assembles what needs to be built which takes under a second. Sure - I could just have one file full of include statements, but I'd rather work with separate assembly units.

As for it being an outdated concept - news to me, but it's the way I've worked since I was introduced to separate compilation on everything but the smallest of projects.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/