It is currently Wed Nov 22, 2017 8:07 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Thu May 28, 2015 1:48 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
nicklausw wrote:
nesasm
Eh. Not into it. Directives need to be indented, making me wonder why do they even start with a period (which I would think lets the assembler detect if it's a directive). No anonymous labels. Somewhat picky syntax. I'd say the pre-generated headers aren't worth having to live with the rest of the BS.
Directives in NESASM do not require the period; it is optional. I like the "picky" syntax of NESASM, and I have added support for anonymous labels (but this is one of the few of the features I have added that I do not use myself (I have added various other features too, but which I seem to be the only one to use them); I added anonymous labels for benefit of other people).

Another limit of NESASM though is that the ROM data is limited to 1MB. (My own version though allows larger ROM data but if you do so, the extra data must be external and you have to use a custom output routine.)

_________________
.


Top
 Profile  
 
PostPosted: Thu May 28, 2015 1:49 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Throwing in my two cents: charmap in ca65 is stupid and badly-implemented. Compare its ridiculousness to how x816 implemented it (see .ASCTABLE and .ASC).


Top
 Profile  
 
PostPosted: Thu May 28, 2015 1:53 pm 
Online
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 368
Location: ...
koitsu wrote:
Throwing in my two cents: charmap in ca65 is stupid and badly-implemented. Compare its ridiculousness to how x816 implemented it (see .ASCTABLE and .ASC).

That's exactly how WLA goes about it, something that I've always loved.


Top
 Profile  
 
PostPosted: Thu May 28, 2015 2:00 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
nicklausw wrote:
Thanks Movax, I was able to set that up accordingly. The multi-line thing didn't work though...

Line continuation in ca65 needs to enabled with the ".linecont +" control command. I guess I forgot to mention that in the original post. BTW you don't need the .concat in there if it's a single line.

nicklausw wrote:
I tried to set A-Z to their specific characters, and found that the only good way to do so is through a loop. Is this really the best way?

Code:
charmap1 .set $41
charmap2 .set $b
.repeat 26
.charmap charmap1,charmap2
charmap1 .set charmap1+1
charmap2 .set charmap2+1
.endrep
.charmap $20,$00 ; space

This simplifies down to:
Code:
.repeat 26, i
  .charmap $41+i, $b+i
.endrepeat
.charmap $20,$00 ; space

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


Last edited by thefox on Thu May 28, 2015 2:11 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu May 28, 2015 2:08 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
koitsu wrote:
Throwing in my two cents: charmap in ca65 is stupid and badly-implemented. Compare its ridiculousness to how x816 implemented it (see .ASCTABLE and .ASC).

I agree that it's suboptimal. However most of the shortcomings can be worked around with macros (you could implement quite easily a macro that allows you to map ranges). The biggest problem I feel is the lack of ability to push/pop/reset the character sets, which can be really problematic e.g. for macros/files that expect the character set to be set up in a certain way. This, too, can be somewhat worked around with macro trickery but it's not pleasant.

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


Top
 Profile  
 
PostPosted: Thu May 28, 2015 2:15 pm 
Online
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 368
Location: ...
Assembler-wise, I think I'll stick with asm6. ca65 and wla-dx are tied for a second, and nesasm takes the spot for last.

With nesasm, it's nice that someone made a better version on their own, but I'm not into the idea of having to say "make sure you use the version from THIS PERSON, not the STANDARD ONE!"


Top
 Profile  
 
PostPosted: Thu May 28, 2015 2:32 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5825
Location: Canada
nicklausw wrote:
With nesasm, it's nice that someone made a better version on their own, but I'm not into the idea of having to say "make sure you use the version from THIS PERSON, not the STANDARD ONE!"

That's a big problem with assemblers in general. There's no standard to conform to, just a bunch of conventions implementers optionally use.

As for whether .charmap is fussy to use, I don't really see the problem for a small table generating code that you only have to write once, and that you could easily shuffle off into a header file that you .include where needed. How often are you changing character sets that it really feels like an inconvenience?


Top
 Profile  
 
PostPosted: Thu May 28, 2015 4:39 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19240
Location: NE Indiana, USA (NTSC)
rainwarrior wrote:
(Won't cause a problem on emulators, or with powerpak, but if you built a cartidge for it you might see problems if you're using the PPU before it's warmed up.)

Not waiting will cause a problem on PowerPak when you press the Reset button on the Control Deck after the game starts. So if you test on PowerPak, don't forget to try a reset every once in a while to see if your program still works.


Top
 Profile  
 
PostPosted: Thu Jul 09, 2015 10:38 pm 
Offline

Joined: Sat Apr 12, 2014 12:11 pm
Posts: 120
Location: Gothenburg, Sweden
I don't want to be nitpicking.. but I have some suggestions.
From the asm6 source
Code:
-:  lda message, x
    cmp $ff ; <----- don't you mean #$ ?
    beq load_attr
    sta PPU_VRAM_IO
    inx
    jmp -
(..)
message:
.db "MY FIRST NES ROM"-$36,$ff


The program works as intended because memory from the end of your code is all zeroes and returns true from your
Code:
cmp $ff
It's a simple thing to mess up.

Personally I really love to
Code:
pad $fffa,$ea
so I know for certain things don't mess up anything.

Code:
.org $fffa
.dw 0, Reset, 0

Not fond of this.. :) I would atleast put some dummy labels there just in case.

_________________
I´ve got %01100011 problems but the BITs aint one.


Top
 Profile  
 
PostPosted: Fri Jul 10, 2015 1:11 pm 
Online
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 368
Location: ...
...aw crap, it seems I did screw up that loop. I'll get on my pc and fix that.

I don't see how padding AND filling with $ea is better than just orging (which is padding) and taking the default filler of 0.

Edit: I see watcha mean now, but still don't think it's necessary.

And I guess I can add a dummy label to an rti.


Top
 Profile  
 
PostPosted: Fri Jul 10, 2015 1:23 pm 
Online
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 368
Location: ...
Alrighty then, fixed some of that up and tried cleaning up a few things. Note that other than asm6, I can't guarantee that any of these will work (my previous set-up went with my hard drive) so yeah, just go with my blessing. XD

EDIT: Broke ca65 on accident.


Last edited by nicklausw on Fri Jul 10, 2015 1:51 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Jul 10, 2015 1:29 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5825
Location: Canada
I don't really understand the point of filling with $EA. If you end up running code there it'll just NOP-slide all the way to the vectors, and then try to execute those as code, then if it's not dead yet, wrap around to the ZP and continue... what advantage is there to that?

I fill with BRK (which happens to be 0 as well), which means the IRQ routine gets executed if I ever accidentally start executing fill. Since I'm not using the IRQ for anything else, I put an error diagnostic screen in my IRQ handler. Helps me debug if I ever make a mistake (usually to do with a missing stack push/pop or something).

A lot of original NES games seem to fill with $FF. I don't know if there's any software advantage to this, but an "empty" EPROM has all bits set, so maybe this was an advantage during testing.


Top
 Profile  
 
PostPosted: Fri Jul 10, 2015 2:29 pm 
Offline

Joined: Sat Apr 12, 2014 12:11 pm
Posts: 120
Location: Gothenburg, Sweden
rainwarrior wrote:
I don't really understand the point of filling with $EA. If you end up running code there it'll just NOP-slide all the way to the vectors, and then try to execute those as code, then if it's not dead yet, wrap around to the ZP and continue... what advantage is there to that?


Technically there is none and I do some what agree with you on this. I totally see your point. If you also happen to have an irq/brk handler it would be really nice to use when ever you go out of boundry. However, as often as a nop slide can occur and wrap around, a brk might also end up - such as in this case - on zp and be equally confusing for someone not fully understanding how things work, which I assume a "Hello World" program is ment for. Setting all vectors, albeit to dummy values/labels, seem like a good idea to me atleast. Maybe I am looking too deep into something really simple here :wink:

_________________
I´ve got %01100011 problems but the BITs aint one.


Top
 Profile  
 
PostPosted: Fri Jul 10, 2015 2:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5825
Location: Canada
Yes, BRK is obviously not much use if you don't have something in your IRQ handler to catch it.

If you put a jmp ($FFFC) instruction just before your vectors (at $FFF7), an $EA fill NOP-slide will cause a soft-reset, which might be nicer than it going rogue? I actually did this for a while until I thought of using BRK instead.


Top
 Profile  
 
PostPosted: Sat Jul 11, 2015 5:42 pm 
Online
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 368
Location: ...
rainwarrior wrote:
Yes, BRK is obviously not much use if you don't have something in your IRQ handler to catch it.

If you put a jmp ($FFFC) instruction just before your vectors (at $FFF7), an $EA fill NOP-slide will cause a soft-reset, which might be nicer than it going rogue? I actually did this for a while until I thought of using BRK instead.

Is that why, iirc in the standard nes.cfg file, the segment VECTORS starts 3 bytes before $fffa?


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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