nesdev.org

Yes, I realize that double colons have been used for other purposes, and I don't care. If I cared about how every assembler has used every symbol, there'd be nothing left for me to use.

Repeated colon, repeated label, it just makes sense to me.

If it's something you specify in the file like .org, I would think that a right align would have two directives, one that opens it with padding, and a second one that closes it with an address to meet.

Though TBH I think a CC65 linker config property on a segment would be a lot better way to express it.

tokumaru wrote:Right aligning means aligning code to an upper address, useful when you use a mapper that swaps the entire 32KB and you need to simulate a fixed bank near the CPU vectors, containing a reset stub, trampoline routines and other things.

I'm a little curious how often this code needs to change for you that you consider setting a fixed starting address not a good enough solution. Do those listed things change frequently, or is this more about the "other things"?

... The reason I'm making this thread is not to advertise my assembler, create hype (as if!), take requests, or anything like that. I'm actually a little insecure about my design ideas and ways to implement them, seeing as I've never written a program like this before, so I'd like to discuss some of these ideas with you guys first, to make sure I'm not missing anything important and making bad decisions left and right. ...

If you're going to simply do whatever you want to do regardless of what feedback people give you, including materials that might give you some ideas or let you think about things differently, then how do we give you constructive feedback, or feedback that you'll find useful?

Rephrased: I'm 100% for people making tools for themselves (incl. not sharing them if they don't want to -- folks should do whatever they wish!) but it's strange to ask for advice/feedback/insights/etc. and then basically say "I don't care, I'm doing what I want, for me". Why should the community provide feedback if that's the modus operandi? How do we give you helpful and constructive feedback?

(I'm asking this with a tremendous amount of respect BTW, and not to start an argument or to get things off-topic. I'm about at a point where I'm probably going to have to make my own disassembler for similar reasons (for the 2nd time in my life nonetheless!). It's so strange how we have better tools today in some regards, but worse in others.)

koitsu wrote:I'm about at a point where I'm probably going to have to make my own disassembler for similar reasons (for the 2nd time in my life nonetheless!).

The last one being Tracer?

rainwarrior wrote:If it's something you specify in the file like .org, I would think that a right align would have two directives, one that opens it with padding, and a second one that closes it with an address to meet.

I'm intentionally trying to avoid making this look like a block directive, but I guess that it kinda is anyway, with the PC clearing and the subsequent required .ORG.

Though TBH I think a CC65 linker config property on a segment would be a lot better way to express it.

That'd be great, but I can't do it myself and I can't rely on other people doing it for me. Plus this is far from from being the only ca65 drawback that affects me.

I'm a little curious how often this code needs to change for you that you consider setting a fixed starting address not a good enough solution. Do those listed things change frequently, or is this more about the "other things"?

Trampolines are added as I write the banked subroutines, which takes a while. Another thing that makes this more complicated is that different banks have different configurations of "fixed" content: there's the stuff that goes in every bank, but banks containing level maps, for example, have subroutines for accessing that data, testing collisions and the like. Banks containing graphics have decompression subroutines. Banks containing object definitions have code to load those definitions. These things aren't supposed to change all the time, but they do sometimes, and the different configurations make this even more annoying to manage.

It's not impossible to do it the "conventional" way, since I'm making a tool that deals with all the things that bother me, why not making this particular thing automatic so I can worry about managing 1 less thing?

koitsu wrote:If you're going to simply do whatever you want to do regardless of what feedback people give you, including materials that might give you some ideas or let you think about things differently, then how do we give you constructive feedback, or feedback that you'll find useful?

I do value good criticism, but I ignore what I find irrelevant. I know you were trying to help, but like you said in your post, you didn't know what I was talking about (right-aligning), and didn't seem to acknowledge my effort in preserving the typical/classic functionality of ORG, so what you said didn't help at all.

ASM6 for example allows code/data before the first ORG, as long as the value of the PC isn't needed. I've used that to write the NES header, for example. That's semantically better than doing ORG $7ff0 or whatever, since the header doesn't really get mapped to that or any other address. That would keep working with my proposed solution.

The link you provided to that assembler's documentation was very relevant though, since I have in fact been reading the documentation for various assemblers, taking some cues from here and there, so thanks.

I'm 100% for people making tools for themselves (incl. not sharing them if they don't want to -- folks should do whatever they wish!)

I'm not opposed to sharing my tools, but they're hardly ever "release-ready", and I don't want to spend the time necessary to make them that way. This assembler is no different... It's written in JavaScript and has the functionalities *I* think she gonna speed up *MY* workflow when coding, but if anyone thinks it can be useful for them, great, I'll share, I'm just not going to be making changes I don't think are useful to me personally.

That may sound selfish when put like that, but this forum is essentially meant for people to ask for help with their projects, and my current project is an assembler. If someone doesn't feel like helping because they're not getting anything out of it, then they can simply not help. I don't expect anything back when I help people with their games here, for example.

but it's strange to ask for advice/feedback/insights/etc. and then basically say "I don't care, I'm doing what I want, for me".

Doesn't everyone keep the ideas they like, and toss the rest?

How do we give you helpful and constructive feedback?

The most important thing is: understand what the problem I'm trying to solve is. Even if it's not a problem for you, due to your workflow being different, try to see why it's a problem for me.

It's so strange how we have better tools today in some regards, but worse in others.)

I guess that people have different backgrounds, workflows, expectations and goals, so what's better for one person isn't necessarily better for the other.

tokumaru wrote:

I'm a little curious how often this code needs to change for you that you consider setting a fixed starting address not a good enough solution. Do those listed things change frequently, or is this more about the "other things"?

Trampolines are added as I write the banked subroutines, which takes a while. Another thing that makes this more complicated is that different banks have different configurations of "fixed" content: there's the stuff that goes in every bank, but banks containing level maps, for example, have subroutines for accessing that data, testing collisions and the like. Banks containing graphics have decompression subroutines. Banks containing object definitions have code to load those definitions. These things aren't supposed to change all the time, but they do sometimes, and the different configurations make this even more annoying to manage.

Hmm, it's a little surprising to me how much stuff you want in there. Like for me with BxROM it only ever contained a few lines of code that write the bank register, because that had to be in a fixed location to work. For things that were trampolines, the rest of that trampoline didn't need to be in any particular place.

Of course I don't really know what kind of mapper you're dealing with, or what other schemes you're using to organize your work. Would having a decompression routine somewhere else in the bank cause a problem?

For my last game I did move some segments around just for the sake of visualization, or in one or two cases to facilitate potentially cleaner IPS patches. For the vast majority of this though the final segment order/position didn't really matter in any functional way. Is this generality different for you?

Actually that's one of the reasons I like CC65's segment/linker system so much. This was really easy to reorganize in the .CFG with almost no impact on the rest of the code.

rainwarrior wrote:Would having a decompression routine somewhere else in the bank cause a problem?

Since there's more than 1 bank with graphics, the decompression routine needs to be in the same place in all of them. Actually, that's not true: since there's a trampoline in each bank, each trampoline could jump to a different location, but honestly, having copies of the same routine scattered around different addresses sounds like a mess to me, and in some cases I might need the timing to remain consistent across the different copies, so I wouldn't want them to be aligned differently relative to the memory pages.

Anyway, in this particular case I guess I could put the routine in the beginning of the banks, since there are no alignment requirements for compressed graphics, but for other kinds of data there might be, so my default is to put stuff at the end.

For the vast majority of this though the final segment order/position didn't really matter in any functional way. Is this generality different for you?

I like to know where things are, for the most part, but I often have a significant amount of timing-sensitive code and data (mostly related to vblank updates - I often use every last cycle of vblank time) for which I absolutely have to control the page alignment, and I find that easier to control if I can just look at the INCLUDES that are near an ORG statement with a readable address.

Actually that's one of the reasons I like CC65's segment/linker system so much. This was really easy to reorganize in the .CFG with almost no impact on the rest of the code.

I reorganize stuff by moving INCLUDEs around. Every subroutine and data table that I write has its own file, and my main file is just a bunch of ORGs (or SEGMENTs, if using ca65) and INCLUDEs, so I can quickly look at that file and see the entire ROM structure right there, I can see where everything goes, and I can move stuff around by cutting and pasting whenever necessary.

koitsu wrote:A copy of x816's manual is here, along with several other manuals from assemblers. Just remember that x816 was intended for 65816 (which supports 24-bit addressing and native banks), but it should give you some good ideas on how to do things (like .base and how to handle some scope-related bits): https://www.dropbox.com/sh/15z9w4v0s6h7 ... Knina?dl=0

It looks like ASM6 was *heavily* inspired by this assembler! I always wondered where the ideas used in ASM6 came from.

x816 was also Norman Yen's 3rd assembler. His earlier works were snesasm, followed shortly after by trasm (Tricks Assembler, which was like snesasm but better). All 3 were written in Turbo Pascal, and source is available for snesasm and trasm but not x816 (hence my quest to get it, but Norman was kind enough to state that it's been lost). Also, don't confuse snesasm with another 65816 cross-assembler from that time *also* called snesasm, which was written in C, nor confuse any of those with SNASM, which was also in C and was a 2-pass assembler (but pretty awful).

I rank x816 quite highly because I dealt with a lot of crappy cross-assemblers over the years (I think I tried a total of 7 or 8 on PC), and x816 was the cream of the crop -- it's what I used to do 6502 code for the Neo Demiforce FF2e intro (when DOS was still a thing), actually. It felt very natural and made a top-notch general-purpose assembler that made starting out doing 65xxx easier, and making SNES-oriented ROMs even easier.

For native 65xxx assemblers, I can really only speak about Merlin 8 (Apple II series), and later Merlin 16 and ORCA/M (Apple IIGS). ORCA/M really spoils you, but was very much a IIGS-oriented assembler (though some people did use it for some general SNES development). Otherwise for older stuff, I started with the built-in Apple II ROM mini-assembler and Monitor, which were convenient for small programs but tedious as hell for long ones (especially if you made any mistakes); if people were to show you it today, you'd probably lose your mind wondering how people tolerated it... but they were built-in to the Apple II, thus essentially "free".

A lot of the general pseudo-ops you see used in all of these programs, and in asm6 and others, tend to be similar because those pseudo-ops date back to even older assemblers (early 90s, late 80s, and beyond). For the SNES-oriented assemblers above, you'll find many from completely different authors who all seem to share similar pseudo-ops -- and that's because everyone wanted to be as compatible as possible with one another (so you could move your source to/from assemblers without too much pain). Else there's a pretty common set of directives that people have gotten used to over the years, but there's no reason those have to be retained as long as the assembler comes with good documentation (ca65 is a great example).

So in short, I'm fairly certain asm6 was inspired by a lot of previous assemblers that Loopy had used. I don't know what systems he grew up working on, but everyone seems to have their own preference.

Footnote: I'm in the process of trying to put together a directory of old assemblers as well, since a lot of the old stuff seems to be lost over time as sites go down and the like. There's a lot of old tools/assemblers/disassemblers that are essentially lost because of that. Not everything from the days of floppies got transferred to the Internet. :)

tokumaru wrote:

For the vast majority of this though the final segment order/position didn't really matter in any functional way. Is this generality different for you?

I like to know where things are, for the most part, but I often have a significant amount of timing-sensitive code and data (mostly related to vblank updates - I often use every last cycle of vblank time) for which I absolutely have to control the page alignment, and I find that easier to control if I can just look at the INCLUDES that are near an ORG statement with a readable address.

Hmm, I wasn't including alignment under order/position because that's separately guaranteed for me with either .align directives or segment alignment (or both). Yes, the alignment definitely matters but there's no code that needs to run on any specific page. I can still reorganize those simply by moving the segment in the CFG without any worry, except when the bank becomes extremely full and I need to manage segmentation (but that's kind of a one time task).

How does right alignment figure into this though? Does that solve a technical problem, or is this just an organizational thing for you? Do you sort of manage your code as two stacks, one growing up from the bottom, and on growing down from the top, with a big hole in the middle? Where does the need to fill a space from the right come in? ("I just want it there" is a valid reason, BTW, I don't want you to feel like I'm demanding that you justify it.)

The one case where I could think I might want it would be trying to fit in DPCM without having to split the 32k space into two halves. (...but I also probably wouldn't try to use DPCM with 32k banking.)

rainwarrior wrote:that's separately guaranteed for me with either .align directives or segment alignment (or both).

Doesn't that result in wasted ROM space?

Do you sort of manage your code as two stacks, one growing up from the bottom, and on growing down from the top, with a big hole in the middle?

That's exactly it.

Where does the need to fill a space from the right come in?

It's mainly because I have two cases that require careful positioning of code/data: a) stuff that needs to be in multiple banks and therefore must be in the same address every time (CPU vectors, trampolines, data-processing subroutines, etc.) and b) stuff that needs careful alignment relative to the memory pages for timing reasons. I find it very convenient to put each of these groups in opposite ends of the bank, so they don't interfere with each other, and they both grow inward as I add new stuff.

If everything was left-aligned, the fixed stuff would have to come first (or I wouldn't be able to map all instances to the same address), and it'd interfere with the alignment of the code/data following it, or I'd have to waste ROM space with padding to guarantee the alignment.

tokumaru wrote:

rainwarrior wrote:that's separately guaranteed for me with either .align directives or segment alignment (or both).

Doesn't that result in wasted ROM space?

Not really... at least I've never found it significant. However, your proposed alternative is just setting the address with .org, right? Doesn't this have the exact same padding problem?

.align will create padding, but only as much as needed. You can always rearrange stuff around the code to take up that padding. (In general I don't actually start worrying about the small amount of bytes lost to padding until I actually run out of space, though.)

If you have a short routine, you can use .align 32, or .align 16, etc. to get the guarantee you need with less potential padding.

You can also put all your alignment requiring routines in one segment (or after one .align). Like the real problem is just branch crossings, right? Guarantee those with an assert, and you can put as many pages worth of code as you want after a single guaranteed page alignment, and just manually stick a few bytes in between your routines whenever one of those asserts triggers.

Sort of an extension of that idea, you can use generally asserts instead of .align to guarantee it for compilation without any implicit padding, and just add it as needed.

Yeah I use asserts too a lot and never had an issue with alignment.

You can use this macro instead of .align to verify you're not wasting too much space: