It is currently Fri Oct 20, 2017 10:11 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sun Jun 18, 2017 10:31 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5728
Location: Canada
HihiDanni wrote:
rainwarrior wrote:
It's a "one-pass" assemble, but it does fill in forward references (unlike C, which requires forward declarations to even compile).

Yet another bullet point on the list of reasons why C is not a good language. When even assemblers do a better job at this...

The 6502 assembler has the advantage of being able to assume that it's a 16-bit value. In C it could be literally anything and it's impossible to make an assumption like that. The assembler isn't doing a better job with the single pass, it's merely doing a possible job. (Possible only because it has no such thing as type safety... or types at all.)

Anyways, to bring it back to the question of how to organize files... at least in ca65, in general keep your RAM / ZP reservations at the top of the source file. If your file becomes large enough it's useful to split things up by function. You can put the music code and music data in their own file, for example. This separation can help keep things more manageable-- the music source file now doesn't have to worry about anything that's in the other files, it only has its own concerns.

It's fine to stick everything in one file until later when the program grows large enough, or even keep just a single file assembly through the whole project. Both approaches are currently practical for an NES game.


Top
 Profile  
 
PostPosted: Sun Jun 18, 2017 12:35 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
I've generally concluded that old 65xx assemblers don't really need linkers, therefore no multiple modules. asm6 and bass are extremely fast on their own, both to the point where the multi module advantage of "reassemble some, not all" isn't worth much. If anything, it's just an annoyance to manage all the tons of files with exports and all that.

I haven't had to work on slow hardware in a while, though, so I'm probably lacking sympathy.


Top
 Profile  
 
PostPosted: Sun Jun 18, 2017 12:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
Using explicit import and export protects you from typoing a variable name as another module's private variable name.

And I work on an Atom laptop from 2010, though I may soon replace it with a Celeron (Intel's new name for Atom) laptop from 2017 if I can find a good 11.6" that takes more than 2 GB of RAM and has Linux drivers.

EDIT (45 minutes later): And doesn't beg the user to wipe the hard drive if an application other than a web browser is installed.


Top
 Profile  
 
PostPosted: Sun Jun 18, 2017 1:29 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
tepples wrote:
Using explicit import and export protects you from typoing a variable name as another module's private variable name.

Yeah, but as I said, that advantage doesn't mean much when you have little reason to have multiple modules in the first place.

Quote:
And I work on an Atom laptop from 2010, though I may soon replace it with a Celeron (Intel's new name for Atom) laptop from 2017 if I can find a good 11.6" that takes more than 2 GB of RAM and has Linux drivers.

I bought a Lenovo Ideapad with the intention of installing Linux on it. Guess what, the BIOS locks you into windows and the drivers are proprietary. So there's one place to avoid looking.


Top
 Profile  
 
PostPosted: Sun Jun 18, 2017 1:34 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5728
Location: Canada
I don't find assembly or linking speeds are an issue at all, even at this point where I have a few megabytes worth of code, it finishes fast enough (~1 second) that I haven't even bothered to consider using makefiles/etc. to only rebuild what's changed.

I just like the structure of having code with different concerns isolated in different files. If well organized, it helps me find where things are, and also avoids namespace pollution issues like the one tepples just mentioned (especially important with macros that can have less obvious effects if accidentally used outside their intended area). I'm also just used to that structure from years of C++ development where it's a necessity.

The only case where I've seen NES assembly take a significant amount of time was when Movax12 made a high level disassembly of Super Mario Bros using a set of complicated macros that added "high level" features to ca65. I can't remember exactly how long it took but it was probably well over a minute. (Edit: tried it just now, takes 2 full minutes for me, and apparently it even has a modified ca65.exe that is supposedly faster than regular with this macro set.)


Top
 Profile  
 
PostPosted: Sun Jun 18, 2017 1:46 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
rainwarrior wrote:
I just like the structure of having code with different concerns isolated in different files. If well organized, it helps me find where things are, and also avoids namespace pollution issues like the one tepples just mentioned (especially important with macros that can have less obvious effects if accidentally used outside their intended area). I'm also just used to that structure from years of C++ development where it's a necessity.

Bass lets you give as many source files as you want to the command line allowing for a feel of multiple files, and has namespaces in the form of scopes. I think it handles your issues pretty well, but of course I'm not asking you to switch your megabytes of code to a different assembler.


Top
 Profile  
 
PostPosted: Mon Jun 19, 2017 9:58 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2962
Location: Tampere, Finland
rainwarrior wrote:
and apparently it even has a modified ca65.exe that is supposedly faster than regular with this macro set.)

IIRC, it's not modified, just recompiled with Visual C++ with optimizations. It may have been that the regular ca65—at the time—was compiled without optimizations (with gcc, not that it matters).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Jun 19, 2017 10:07 am 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
cc65's optimization level just recently went from -O to -O3, so the modified binaries probably are just compiler-optimized.


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 3:57 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 248
I remember when I was making SNES stuff on my P133, having gone from a BASIC hack Assembler on the C64. The speed blew me away. The SNES assembler would tell me how long it would take to assemble the code. It was typically 0.00165... seconds. C64 games take about 10seconds on a 4mhz 286 with PDS, one of my ex leads told the time he walked to IT and demanded a new PC with a faster processor ( 386 SX 33 ) as 30 seconds to assemble was just unacceptable. These days I figure the assembler spends more time doing the printf "I'm done here is your file" than it actually does parsing the code. So I can't see that anybody would have be having issues with assembling speed, even if you are on an atom... hell even if you are on a Raspberry Pi 0.

I would also think that making a master.asm file that is basically
Code:
*=$00
.dsection zp

*=$8000
; init NES here
; fire up title screen

;NMI here

.include "file1.asm"
.include "file2.asm"
.include "file3.asm"
would assembler faster than doing a module and link. As the assembler will be able to pull most of the things it needs into cache in one shot and pass through it. Allowing it to hit the HDD once to get the files and then being all in RAM from then on. Were as if you Assemble, it will pull in the files it wants. Spit out a file, load the linker, load in more files and the files you just made, do more work to figure out were stuff is, make final file. To me this has a far larger dependence on File I/O and would be slower overall.


Top
 Profile  
 
PostPosted: Mon Jul 31, 2017 3:01 am 
Offline
User avatar

Joined: Fri Jul 21, 2017 4:38 am
Posts: 31
Quote:
It's fine to stick everything in one file until later when the program grows large enough, or even keep just a single file assembly through the whole project. Both approaches are currently practical for an NES game.


This pleases me. I was worried I might hit issues later but I'll leave everything in one file for now (might even leave it like that for the whole project - haha).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 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