It is currently Mon Dec 11, 2017 2:49 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Thu Jun 16, 2016 4:45 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5886
Location: Canada
tokumaru wrote:
As my programs get more complex, I sometimes worry that the assembler is going to bump into some sort of limit and will not be able to handle the huge amount of labels I'm using...

My current project has ~2MB of generated assembly files worth of this kind of stuff and they assemble "instantly" and painlessly. If there's a practical limit, it's very high, I think.

The only time I've seen assemble times become significant with ca65, though, was with Movax12's "high level" SMB disassembly. In this case, all the complicated macros he used really do consume a lot of assembly time. (As I recall, it was on the order of "minutes".)

Though, even if you did run into assembly complexity issues, this can be helped a lot by breaking up your code into separate units and assembling them separately, letting you do incremental builds on only the stuff that's changed since the last build (makefiles make this easy to accomplish). Doesn't help link time, but unless you're also exporting/importing all these generated labels for some reason (why would you need to?), I don't imagine the generated data will give you link time problems anyway.

In my project, I am not even using makefiles, just because a need has never come up. I have a huge pile of assembly code, but the whole build process only lasts about a second, so... I never bothered. I just let it build from scratch every time.


Top
 Profile  
 
PostPosted: Thu Jun 16, 2016 5:11 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 218
rainwarrior wrote:
My current project has ~2MB of generated assembly files worth of this kind of stuff and they assemble "instantly" and painlessly. If there's a practical limit, it's very high, I think.

I hit ld65's limits pretty hard on that 8MB bebop.nes rom I made. There's a ~255 file limit when linking and each file can't have more than ~255 segments. It was not a fun experience getting it to work.

Smaller roms shouldn't have a problem though.

Quote:
makefiles make this easy to accomplish

And they come with the sweet bonus of being able to compile your files in parallel.


Top
 Profile  
 
PostPosted: Thu Jun 16, 2016 5:27 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
rainwarrior wrote:
The only time I've seen assemble times become significant with ca65, though, was with Movax12's "high level" SMB disassembly. In this case, all the complicated macros he used really do consume a lot of assembly time. (As I recall, it was on the order of "minutes".)

(・□・ )

I hope nobody has ever have to touch ca65hl.h again.


Top
 Profile  
 
PostPosted: Thu Jun 16, 2016 7:28 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5886
Location: Canada
pubby wrote:
I hit ld65's limits pretty hard on that 8MB bebop.nes rom I made. There's a ~255 file limit when linking and each file can't have more than ~255 segments. It was not a fun experience getting it to work.

Heh, I didn't know it even had an input file limit, or segment limit. :P I've never been anywhere near either of those. Your case seems rather unique. What about performance, though? How long did it take to build?

A tip that could help in your specific case, or in general:

You don't have to link all your banks at once. This is especially true of 32k banking. You can do each bank separately and just concatenate the results. Even with 16k (or other) banking, you can create a dummy segment (that doesn't output to a file) to generate references for other banks that you need to do cross-bank linking with.

I started doing it that way when I found I couldn't get bank info from the debug symbols, so all the symbols in the listing would overlap with no way to disambiguate. Splitting them up was a necessity for generating debug symbols for FCEUX, but once I started doing it I found it convenient in other ways too.


Top
 Profile  
 
PostPosted: Thu Jun 16, 2016 8:13 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 218
rainwarrior wrote:
What about performance, though? How long did it take to build?

Assembling and linking probably took about 20 seconds total. It was still pretty fast.

The slow part was the converter program I made. It would take 5+ minutes to convert the movie file into rom data.

Quote:
You don't have to link all your banks at once. This is especially true of 32k banking. You can do each bank separately and just concatenate the results. Even with 16k (or other) banking, you can create a dummy segment (that doesn't output to a file) to generate references for other banks that you need to do cross-bank linking with.

I like the idea, but what does the dummy segment look like? Did you map out the cross-bank addresses by hand?


Top
 Profile  
 
PostPosted: Thu Jun 16, 2016 8:29 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5886
Location: Canada
pubby wrote:
I like the idea, but what does the dummy segment look like? Did you map out the cross-bank addresses by hand?

A dummy segment looks exactly like the regular version of that segment except it is placed in a MEMORY block with file = "" instead. No, you don't map them out by hand, that's the whole point of the dummy segment.


Top
 Profile  
 
PostPosted: Thu Jun 16, 2016 10:18 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
I have had similar kind of problems. In my case the issue was music, and I used the following postprocessor code:
Code:
        ; Adjust music looping addresses
        lda #$C0
        sta <3
        lda #high(song1)-$40
        sta <1
        lda #low(song1)
        sta <0
        sta <2
        ldx #$00
        stx $2000
muadj   lda [0,x]
        cmp #mushs
        bne muadj1
        lda <0
        sta <2
        inc <0
        lda <1
        eor <3
        sta [0,x]
        jmp muadj3
muadj1  inc <0
        cmp #musl
        bne muadj3
        lda <2
        sta [0,x]
        lda <0
        sta <2
        inc <2
muadj3  inc <0
        bne muadj
        inc <1
        lda <1
        cmp #(high(endsong)&$1F)|$40
        beq ppend
        cmp #$60
        bne muadj
        lda #$E0
        sta <3
        lda #$40
        sta <1
        jmp muadj
Obviously you cannot use this code as is; it is for a specific use case which is different from your own. But this probably will not work for you anyways since most assemblers cannot execute 6502 code; this is a specialized assembler which includes a 6502 interpreter for use as a postprocessor (and I may be the only person who uses it).

_________________
.


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 9:06 am 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
I have taken the approach of generating .db statements instead of including binary files before. I believe I did this when working on my raycasting demo, where I had tables of information for every possible wall distance, which looked something like this:

Code:
RaycastingWallHeightsDistance01:
  .db $05,$05,$05,$05,$05...
RaycastingWallHeightsDistance02:
  .db $05,$05,$04,$05,$05...
...
RaycastingWallHeightsDistanceFE:
  .db $00,$00,$00,$01,$01..
RaycastingWallHeightsDistanceFF:
  .db $00,$00,$00,$00,$01...


Then I needed pointers to these tables, so I just generated .db statements like this:

Code:
RaycastingWallHeightsDistancesL:
   .db <RaycastingWallHeightsDistance01
   .db <RaycastingWallHeightsDistance02
   ...
   .db <RaycastingWallHeightsDistanceFE
   .db <RaycastingWallHeightsDistanceFF

RaycastingWallHeightsDistancesH:
   .db >RaycastingWallHeightsDistance01
   .db >RaycastingWallHeightsDistance02
   ...
   .db >RaycastingWallHeightsDistanceFE
   .db >RaycastingWallHeightsDistanceFF


This approach is actually pretty handy.


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 7:22 pm 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
If CA65 can assemble code or data on top of an already incbin file, that there's an easy(ish) way to do this. Store all the absolute addresses as whatever (doesn't matter), and have your program output a non binary file to include with the binary file. In the supplemental file, you'll need a series of equates and org/data defines so the assembler will re-assemble data on top of the already included binary, based on the entry point of where the assembler is assigning an address for this binary. I do this kinda stuff in PCEAS a quite often. Either for hacking roms, or writing self modifying code that needs to reside in ram (all absolute addresses have to be redefined), or just binary distribution without source.

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 7:27 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5886
Location: Canada
tomaitheous wrote:
writing self modifying code that needs to reside in ram (all absolute addresses have to be redefined)

ca65 has a built-in feature for this purpose, i.e. a segment has a "load" address for where it will be placed, and a "run" address for where it will be executed.


Top
 Profile  
 
PostPosted: Mon Jun 20, 2016 5:50 pm 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
rainwarrior wrote:
tomaitheous wrote:
writing self modifying code that needs to reside in ram (all absolute addresses have to be redefined)

ca65 has a built-in feature for this purpose, i.e. a segment has a "load" address for where it will be placed, and a "run" address for where it will be executed.


Yeah.. I really need to switch over to ca65 and quit stalling on it.

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
PostPosted: Mon Jun 20, 2016 8:00 pm 
Offline
User avatar

Joined: Thu Jan 19, 2006 5:08 pm
Posts: 748
Location: Shelton, Washington.
tomaitheous wrote:
Yeah.. I really need to switch over to ca65 and quit stalling on it.


Converting all your PCE source code to CA65 can be a good thing, But can be painful...

You may need to convert your code that uses the .func pseudo-op to raw data/code, or a macro, or a define

_________________
AKA SmilyMZX/AtariHacker.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 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:  
Powered by phpBB® Forum Software © phpBB Group