Jump to content

ggn

Members
  • Content Count

    1,628
  • Joined

  • Last visited

Everything posted by ggn

  1. I also sent a payment in August 21 but still have no reply or confirmation. Is everything ok?
  2. At least versions 4 onward do that, yes. If you want a particular file to not touch more registers you can compile the file with, for example, -fcall-used-d2.
  3. Hi folks, Due to reasons I'd rather not discuss, I'm henceforth stopping all RB+ development and support. The github and bitbucket repositories will remain in place for a couple of days and will then be taken down. Thank you for all your interest in this experiment, it's been a fun 6 years. It's time to move on. Please don't PM me or ask me about this using any means, messages will be ignored. See you around, GGN
  4. Okay, you got me too. So let's back that bus up. First of all, are you able to build zyx in any way right now? Secondly, did you always had assets marked as ROM or did you do that now that you're getting build errors?
  5. Ok, issue found. Head over to token.h, lines 131 and 132 and change the "32" to "64". Also read the comment, you just broke a record ;). I'll have a discussion with Shamus on how to handle with this but you should be fine for now...
  6. http://jlhconsulting.gotdns.com/bugs/buglist.cgi?component=Core&product=RMAC&resolution=---&list_id=388 but this thread is ok too.
  7. Also, I just submitted a patch for the macro issues that @SebRmv has. Hopefully it will be merged with the main tree, in the meantime the adventurous can try it out for themselves :).
  8. Awww shucks guys, you're the best! I opened the page and saw half a page's worth of new messages and thought I'd have to spend a few hours testing things, but everything was resolved at the end :). A couple of notes: I thought I fixed the issues with error reporting while evaluating macros and REPTs, but it seems it's not perfect yet. I'll have another go at it. In the meantime an accurate way to pinpoint the expanding issues is to produce a listing (switch -l or -l* if you prefer no pagination). As for the rest of the patches, hopefully @Shamus will get around to integrating them into the repository so people don't have to do magic hocus pocus all the time, but grab a binary instead and do some work @SebRmv thanks for trying out rmac and don't hesitate to report any issues!
  9. I assume you're trying to compile it by hand instead of using the supplied makefile? That won't work as some tools need to be built and produce some header files before the main code can be compiled. In other words, did you try typing "make"?
  10. Can you please paste your build log?
  11. Of course you can always use rmac since the test suite I posted above passes (after all it was designed to test the assembler :). For now only XEX format is supported, more will be added if people ask!
  12. Hi there, I've added a fix for the issue you raised on the issue tracker. If you could compile and test rln, it'd be great.
  13. Aaaaand we're probably fine now. Just waiting for Shamus to confirm and commit the fix and a new version will be released. For the impatient, grab the patch and build the assembler yourself :).
  14. Just to give an update: This is in the process of being fixed. Actually, there is a fix right now but it breaks other cases. (2020 is going to be the year of bad symbol exports by the looks of it)
  15. In the latest released versions you still had to insert comment lines to simulate blank lines. At least the editor auto formatted the code for you so you needn't have to worry about it. (However I was under the impression that v2.0 also auto formatted code)
  16. Well, you got me there. I thought about checking the code for RMACPATH but thought "It's probably fine, besides: who even uses RMACPATH"? Well, now we know! Thanks!
  17. You could ask @Gaztee and @omf if they're still doing physical releases. Otherwise AtariAge publishes Jaguar games as well.
  18. Hi there, I didn't see your post in time sadly. FWIW here's what we use to test the 6502 part of rmac. Perhaps you could use it to cross reference stuff? 6502.zip The idea is that running the source file past the assembler should produce an identical listing to the .ref file.
  19. Okay, my computer gave me the day off yesterday as it needed to install some very important updates, but I'm back at the helm now. What I did just now was to try and match my brownboot.o with the brownboot-old.o in post #120. I assume that one is linking fine for you. Skipping swiftly past the fact that jaguar.inc was different than the stock one and had to be recreated, I'm now able to produce a 1:1 copy of brownboot-old.o. My version is built from head (http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?p=rmac;a=snapshot;h=821279dcb7b5d069d175767edcd413b833b0cae3;sf=tgz) with the following changes: object.c: line 235 replaced with: uint16_t st_shndx = SHN_ABS; // Assume absolute (equated) number lines 243 and 244 replaced with: else if (globflag && !(w1 & DEFINED) && (w1 & REFERENCED)) { st_shndx = SHN_UNDEF; } object.h: the following inserted in the file (around line 35 but shouldn't matter) // // ELF special section indices (field st_shndx) // Lifted from glibc (https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h) // #define SHN_UNDEF 0 /* Undefined section */ #define SHN_ABS 0xFFF1 /* Associated symbol is absolute */ #define SHN_COMMON 0xFFF2 /* Associated symbol is common */ and that's it. If I want to match brownboot-new.o from post #120 I can do so by replacing line 561 in object.c with shstSize += DepositELFSHSTEntry(&shstPtr, "TEXT"); and "DATA", "BSS" in lines 570 and 579 respectively. Now, again, if brownboot-old.o links ok for you then this should also link as it should produce the same object file!
  20. Hmm, that's odd The differences start yet again on the name of the segments - old has ".text", new has "TEXT" etc. Did you apply that fix? [EDIT] On second thoughts, could you attach brownboot.s? I'll take a look at it here and not have to bother you.
×
×
  • Create New...