6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 11:58 am

All times are UTC




Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Mon Mar 25, 2019 6:43 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
BitWise wrote:
The .dpage directive tells the assembler where the application will set the direct page at execution time so it can determine if a direct page address can be used. By default the assembler assumes the direct page will be at $0000 as it is on the 6502 and 65C02.

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?


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 25, 2019 6:56 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
Here's a pathological example
Code:
                                             .dpage  $0000
00:F177  A5EA              :                 lda     $00ea
                                             .dpage  $0080
00:F179  A56A              :                 lda     $00ea
                                             .dpage  $2000
00:F17B  ADEA00            :                 lda     $00ea

_________________
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


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 25, 2019 8:42 pm 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
backspace119 wrote:
EDIT: I see that ca65 supports straight assembly too....not sure why I didn't find this listed on the page about assemblers, or maybe I over looked it. I sorted them by searching for 65816 or 65c816 to only get the ones that were capable of assembling for this cpu. At any rate, I'm still having a lot of fun with making this, but maybe it's more something that's only useful as a learning experience to me.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 25, 2019 9:10 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
BitWise wrote:
Here's a pathological example
Code:
                                             .dpage  $0000
00:F177  A5EA              :                 lda     $00ea
                                             .dpage  $0080
00:F179  A56A              :                 lda     $00ea
                                             .dpage  $2000
00:F17B  ADEA00            :                 lda     $00ea

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 26, 2019 10:35 am 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
BitWise wrote:
backspace119 wrote:
I'm actually checking for direct addressing mode, I was following the syntax found here


On the '816 the direct page is can start at any address in bank 0 so you can have code like this ...
Code:
                             ; These routines expect the caller to have set $DF00 as the direct page address
                             ; so that direct-page instructions are used to access hardware registers.
                             
         00000020          = SPI_SCK         .equ    1<<5
         00000040          = SPI_MOSI        .equ    1<<6
         00000080          = SPI_MISO        .equ    1<<7
                             
                                             .dpage  $df00
                             
                                             .longa  ?
                                             .longi  ?
                             SpiInit:
00:F177  08                :                 php
                                             short_a
                           +                 .longa  off
00:F178  E220              +                 sep     #$20            ; Make A register 8-bit
00:F17A  A920              :                 lda     #SPI_SCK        ; Set SCK as lo output
00:F17C  0424              :                 tsb     PDD4
00:F17E  1420              :                 trb     PD4
00:F180  A940              :                 lda     #SPI_MOSI       ; Set MOSI as an output
00:F182  0424              :                 tsb     PDD4
00:F184  A980              :                 lda     #SPI_MISO       ; Set MISO as an input
00:F186  1424              :                 trb     PDD4
00:F188  28                :                 plp
00:F189  60                :                 rts

.. where the hardware registers PDD4 (at $DF24) and PD4 (at $DF20) can be accessed with direct page instructions as they are here.


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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 26, 2019 2:06 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
backspace119 wrote:
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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 26, 2019 3:00 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
whartung wrote:
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


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 26, 2019 4:42 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
BitWise wrote:
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.

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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 28, 2019 4:41 am 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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).


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 28, 2019 8:21 pm 
Offline

Joined: Fri Jan 25, 2019 5:40 am
Posts: 346
Location: Knoxville, TN
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?


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 28, 2019 9:18 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1485
Location: Scotland
backspace119 wrote:
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/


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 28, 2019 11:02 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
drogon wrote:
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.

Can you tell use what benefits this might have if you're working alone (as opposed to being part of a team), and PCs these days are able to assemble large (ie, large for a 65xx project) projects with lots of INCLude files all at once in a few seconds?  Because otherwise it is my impression that having a separate linker is an outdated concept.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 28, 2019 11:55 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 29, 2019 12:41 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
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?


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 29, 2019 7:45 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1485
Location: Scotland
GARTHWILSON wrote:
drogon wrote:
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.

Can you tell use what benefits this might have if you're working alone (as opposed to being part of a team), and PCs these days are able to assemble large (ie, large for a 65xx project) projects with lots of INCLude files all at once in a few seconds? Because otherwise it is my impression that having a separate linker is an outdated concept.


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/


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: