Originally posted by KilloZapitOriginally posted by HuFlungDuOriginally posted by KilloZapitAlso that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way
Yes, they do. #include "red/red.h" will include the file "red.h" the in the directory "red" as relative to the current file's position, and an include within "red.h" would look for that include in it's directory. If it didn't work like that, #include <Python.h> wouldn't work.
Most programing languages have multiple search paths and multiple files. Of course in C++ a .cpp file will search the current directory but I don't think a included .h file would. Python I have no idea. But an include directive mostly just dumps whatever is in the included file into the current file. That's why it searches the root file, because as far as the assembler knows, that's the current file. If that should change it should search both at least.
Originally posted by HuFlungDuOriginally posted by KilloZapitand old xkas didn't
Yes, and it was the cause of a lot of annoyance (Namely that you couldn't "install" xkas because it had to be run in the directory with the file, which meant you needed a whole lot of copies).
I have no idea what you are talking about here. If your saying it will only search the path where the xkas.exe is, that is definitely a problem. But that's not what I am talking about. I am talking about include changing the directory. Really it's a nitpick, but it's one that is bound to have unforeseen consequences.
I checked how C++ does it. The result is that #include is relative to the current directory, not the directory with the C++ file.
Test it yourself if you don't trust me.
If C++, HuFlungDu and myself says the same thing, then I belive we're right. Your idea may make sense for you, but it does not make sense to me.
Let's just conclude that we disagree and leave it at that.
QuoteOriginally posted by AlcaroIf you're thinking of allowing multiple architectures with the same tool, that's the only solution I'm going to consider.
Well yeah. Doesn't bass use user-defined opcode tables for that?
...what? First imamelia thinks that, and now you think that too?
Tell me how
this is user-defined in any way.
QuoteOriginally posted by AlcaroQuoteHow does it check anyway? Internal rom name?
Correct.
Guess: You're going to find a reason why this is a horrible idea.
Well, LM does allow you to change the internal rom name, but it's so rarely used I think it's mostly an acceptable way to do it. I think a way to set what name to check for is a good idea though.
Yes, that is an acceptable compromise. I implemented that yesterday (the default is still SUPER MARIOWORLD, but it's documented in stdlib.asm so that shouldn't be a problem).
QuoteOriginally posted by AlcaroQuoteIt might be best to move it to a setting in something like stdlib.asm but honestly the whole stdlib.asm idea sounds kinda iffy. I mean, it's a nice idea to include some shared code library, but I think it's better if the user has to explicitly include it.
...and the advantage of a shared library if it's not universally accessible is...?
If you don't like it, leave it blank and use db _sqrt(9) as much as you want.
My reasoning is this: If it's a user defined library, which it looks like it is, people are bound to add code to it and it will need to be distributed with patches, which totally defeats the point of having a standard library because everyone is using a different one. If it's not a user defined file, and is filled with things people might find handy but most will never use, it's just going to take up extra time to parse that people don't need to waste. I mean, it's a nice idea to have a shared library in some projects, but that is what the include function is for. On the other hand, stdlib.asm is a good place to put default any assembler settings that can be overwritten later, like what rom name to check for, freespace settings, what arch to use, or stuff like that.
So what you're saying is person A adds code A to file 1, person B adds code B to file 1, person C wants to use one patch made by person A (requires file A) and one by person B (requires file B), and neither file A nor file B accepts anything made by the other?
That could indeed be annoying. Proposed solution: Official stdlibs are released only by a trusted user working off the latest one.
QuoteOriginally posted by AlcaroQuoteAlso that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way, and old xkas didn't. It's just bound to cause confusion. I see the point of it, but I think it's too much of a bother. I guess you could have it both ways where if it fails to find the file one way it checks the other.
...how does including a file from a folder other than the one with the current file make sense?
If anything, the macro handling is screwy, but doing it the other way (relative to the caller) would be just as screwy.
It's just that in my experience included files usually are not treated as a different file from the one that included it accept for error reporting. Really the difference is moot, but I for one use paths that expect it. It isn't really a big deal though, I don't have that many nested includes anyway. It's just something to think about.
Answered earlier.
QuoteOriginally posted by AlcaroI look for an all-00 and RATS-free area in bank $10 or higher. It should work for all non-256KB ROMs, and I'm pretty sure that's all of them.
I am not sure if most utils actually bother with zero filling though, but that is probably not that big of a deal as a number of tools don't check if free space is zero filled either.
I consider all tools that don't check for 00s horribly broken.
You don't need to agree, but I find it better to skip a usable freespace than breaking something. Besides, unprotected and unused areas are very rare - much rarer than protected and unused ones or unprotected and used.
QuoteOriginally posted by AlcaroQuoteThe trouble I see with that approach though, is that patches are NOT reverted or cleaned. If you fiddle with patches and hijacks when repatching the same asm, you still run into a situation where you can't trust exactly what you are doing. It might be a good idea to add a way to check an addresses's contents to make sure it is what the patch expects it is, but I am not sure how to do that and allow the same patch to be applied multiple times without failing.
Except patches ARE cleaned. That's exactly what autoclean does.
If you want to know where it is, I kept print pc from xkas.
Oh? So it does keep track of all changes to a file? I am not sure what print pc has to do with it.
print pc is irrelevant. It just tells the user where in the ROM it is, it doesn't do anything this tool cares about. I just added it since some users like it.
(It can be used for debugging freespace overruns (if you're replacing a routine and not using expanded-area freespace), but that's not relevant. (Besides, warnpc is better.))
QuoteOriginally posted by AlcaroQuoteIt just seems like it would be much easier to manage if the assembler keept all of the writes it did when patching a file (a romname.patchname.log file maybe) and reversed it.
I see no reason why a JSL from a known location wouldn't be enough to find it.
Freespace blocks only referenced from inside other freespaces would indeed be annoying, but it's solvable with a bunch of dl's at the start of the main freespace and some read3()s.
So do you mark JSL's somehow then? What about JML? Keep track of the labels in freespace? I am not sure why, if autoclean reverses patches, it doesn't reverse freespace too though. Unless autoclean just copies from the original rom or something.
For the 1/0th time, it does not add any housekeeping data in the ROM. Both JSL and JML will work fine for this.
...urgh. I'll just draw some crappy tables.
Let's assume the ROM is 64 bytes. The first 16 bytes are the original ROM, and the next 48 are freespace that this tool looks in.
A5 19 85 80 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(I know it's garbage, but that's not relevant.)
The patch wants to place a JSL at the start of the ROM.
Codeorg $008000
autoclean JSL Mymain
freecode
Mymain:
LDA $19
INC A
STA $80
STZ $19
RTL
The assembler sees an autoclean, but there's no JSL in the ROM, so it ignores it and assembles the JSL normally.
22 18 80 00 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
53 54 41 52 07 00 F8 FF A5 19 1A 86 80 64 19 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Now the user wants to edit and reinsert the patch.
Codeorg $008000
autoclean JSL Mymain
freecode
Mymain:
LDA $19
INC A
STA $80
STZ $14
RTL
Now, the assembler sees that the autoclean contains a JSL - and the ROM does as well! It responds by removing (00ing out) the RATS tag and its contents. It does not try to repair the JSL, it just assumes it'll get reoverwritten. It's not designed to be 100% failproof.
22 18 80 00 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Then it assembles the patch. (In reality, I think it may ignore autocleaned freespaces (it'll use them next time), but that shouldn't matter.)
The resulting ROM is as follows:
22 18 80 00 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
53 54 41 52 07 00 F8 FF A5 19 1A 86 80 64 14 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
There, that should be unambigous.
QuoteOriginally posted by AlcaroI have no multisize jump opcodes (not even JMP.l).
However, it does what you describe for LDA/etc.
But only for labels? It seems to me assuming what data bank you are in is a bad idea. There are times it's just easier to load from a explicit bank then mess around with them. But again, I guess that's what .l is for.
If you're going to use B!=K, then you will indeed need .l. I've seen lots of complaints on xkas doing this weirdly, so I'm going to fix it.
I did indeed get a few odd bugs from fixing this, but two .l's is a smaller pain than 40 .w's or unoptimal code.
QuoteOriginally posted by AlcaroHonestly, I'm not sure if you're interested in helping this project at all. Half of your ideas just seem totally counterproductive (allowing memory leaks or forcing people to keep using slogger everywhere? Not gonna happen.), and I'm not entirely sure if the rest are useful in any serious context.
I think I just have different goals in mind. I have no idea what memory leaks have to do with it though, and I do not at all think freespace finding is a bad idea.
If we take our nonsense ROM from before, remove the autoclean from the patch, and reassemble it, it'd look like this:
22 28 80 00 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
53 54 41 52 07 00 F8 FF A5 19 1A 86 80 64 19 6B
53 54 41 52 07 00 F8 FF A5 19 1A 86 80 64 14 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Note that there's 16 bytes wasted here. This is known as a memory leak (or freespace leak in this case, since it's not RAM). While wasting 33% of the ROM space with one patch is unlikely in any serious context, it could add up if you're inserting large patches many times.
QuoteI am just a bit confused and unsure about your methods, because they are different from the way I would do it. And maybe the way I would do it is not the best way. From what I can figure out, you use labels in patches (in the context of patching the original code) to find out where the freespace is, and delete it, which is fine on it's own, but leaves the patches in the rom (which mostly get overwritten anyway to be fair). Then you say autoclean takes care of these patches (I assume in the same context), but the only way for autoclean to do that is to remember what was patched last time (because you can add and delete patches) and if it remembers that, why dosn't it remember what it put in freespace?
As I said earlier, it's not 100% bulletproof. If you remove a hijack, you'll have a few broken bytes in your ROM, but most patch makers know how to solve that anyways (patch makers usually use temporary ROMs anyways).
QuoteIf you think I am being needlessly negative and nitpicky it's only because I care about such things. These are great features, but I think you are doing them in a slightly problematic way.
Yeah, I guess weird comments are better than no comments. To paraphrase someone I can't find on Google:
"Are people complaining about what you do? Good, that means they care about your project. It is only when they get silent that you should start worrying, for then they have given up hope on you."
I also belive it's time to release a new version of this tool. (Well, technically it isn't, but I want it released before I go to bed. Don't worry, I'll cut down on the daily releases when it's more done.)
Here it is.
Changes:
- !a += +1 has been implemented.
- If you type "freespace", the tool gives a more detailed error message that "Unknown command."
- A bug related to using pushpc inside a freespace has been fixed. That bug destroyed half of the point of pushpc.
- The tool has been renamed to Asar. Pronounciation: The first A is short, and the second is long (as in "Bazaar", except without the B). I don't care if the S is pronounced as S or Z, pick the one that fits best with your tongue. This pronounciation applies in Swedish as well.
Planned for tomorrow:
- Rewrite parts of the length handler, so JML.w can be blocked.
- Add a command to disable the label size optimizer, if I can figure out how to do that without breaking .w-only commands.
- Allow LDA $9E,y (repoint to LDA.w), but print a warning for that.
- Make a command to allow a define as "expand all defines in this string, then run the math parser and give me results" instead of "here's a string that may contain defines, enter an infinite loop if it contains yourself" (see my previous post for details), if I can find any unsucky syntax for that.
<blm> zsnes users are the flatearthers of emulation
