ggn Posted June 20, 2016 Share Posted June 20, 2016 Small bug in RMAC: in DSP code, a jr instruction to a non-existent label gives a "Error: relative jump out of range" error message instead of complaining about the label not existing Maybe it was just testing you to see if you were paying attention? 2 Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted June 21, 2016 Share Posted June 21, 2016 (edited) Okay, here's a bug that's a bit more serious: This: .dsp load (r5+2), r0 generates the "Error: Malformed opcode [internal $07]" error message, as expected since r5 can't be used for indexed adressing. (a clearer message would be a plus, but heh.) However, this: .dsp foo .equr r5 load (foo+2), r0 assembles with no warning, and actually generates this! load (r7), r0 Yeah I know, it's invalid code. But this is not always obvious when your .equr is far way from the place you're actually using it Edited June 21, 2016 by Zerosquare 1 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted June 21, 2016 Share Posted June 21, 2016 Yeah I know, it's invalid code. But this is not always obvious when your .equr is far way from the place you're actually using it Who would have thought actually using these tools would help debug them. Subqmod could have done with some developers back when he was active 3 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted June 21, 2016 Share Posted June 21, 2016 Got a fix for the 1st one load (r5+2), r0 Generates the message: test.s 4: Error: Attempted index reference with non-indexable register (r5) Just wrapping my head around the second, and then I'll get a patch over to Mr Shamoo or see if I can still submit commits direct to the repo (Having a productive day off so far ) 2 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted June 21, 2016 Share Posted June 21, 2016 Patch submitted 1 Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted June 21, 2016 Share Posted June 21, 2016 Amazing! An obscure bug report brought Linko back from the dead! That must be the power of RMAC. 6 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted June 21, 2016 Share Posted June 21, 2016 Small bug in RMAC: in DSP code, a jr instruction to a non-existent label gives a "Error: relative jump out of range" error message instead of complaining about the label not existing Is this under Windows? when I do a super simplistic test on my Linux box it segfaults for this (also not desirable behaviour, I just think Linux has it's shit together more with invalid memory access ) .dsp pizza: nop cheese: movei #0,r0 jr pizza nop jr loop nop nop I have stopped it seg-faulting but throwing an invalid expression error (which is a little more correct, but still not correct ) Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted June 21, 2016 Share Posted June 21, 2016 (edited) Yes I'm using Windows. Your example doesn't cause a segfault, I get the "Error: relative jump out of range" error message for the "jr loop" line. (love your label names, btw! Now I'm hungry...) Edited June 21, 2016 by Zerosquare 2 Quote Link to comment Share on other sites More sharing options...
ggn Posted June 21, 2016 Share Posted June 21, 2016 Mmmmm, I like cheese too! (obscure joke only linko will get - hopefully!) 1 Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 21, 2016 Share Posted June 21, 2016 It would be much better if you guys could file a bug on the tracker; that way it has a better chance of getting fixed. Forum posts tend to be forgotten after a while. 3 Quote Link to comment Share on other sites More sharing options...
Cyprian Posted January 27, 2019 Share Posted January 27, 2019 Hi team, where I can find the latest rmac/rln? Quote Link to comment Share on other sites More sharing options...
ggn Posted January 28, 2019 Share Posted January 28, 2019 http://virtualjaguar.kicks-ass.net/builds/ Or if you require the source: git clone http://shamusworld.gotdns.org/git/rmac 3 Quote Link to comment Share on other sites More sharing options...
Cyprian Posted January 28, 2019 Share Posted January 28, 2019 thank Quote Link to comment Share on other sites More sharing options...
+BitJag Posted November 2, 2019 Share Posted November 2, 2019 ggn directed me here post about a possible bug with rmac/rln and the removers library. I have attached an archive that has a bare bones example program that should be clear enough that playing a module in the removers library is causing the program to crash. There is a log folder in the archive that contains logs for both mac and rmac builds for comparison. It also includes makefile.config files for rmac and mac, for each toolchain, for comparison as well. I also attached a current version of my rmac/rln/jlibc/rmblib tool chain setup script. I have only tested this in Kubuntu 19.10, but it should work in any flavor of linux that has access to the Ubuntu repositories (needed for the cross compiler). As for my old tool chain, if you want to test against this directly, I can get a link for the 200MB archive that has a prebuilt cross compiler and jlibc/rmvlib from 2010. It also has prebuilt deb packages of a older kernel version that supports a.out binary emulation(this has been dropped in the most recent versions of the linux kernel). This old tool chain has been my go to for jag dev for a decade now, but I would like to move to a tool chain that I know is buildable and usable in the future. The reason why I think that rmac might be the source of the problem is because if I build the same program with my old tool chain (mac/aln) the program seems to work fine. My old tool chain also uses a different version of the m68k cross compiler, but, from what I understand, because the source files for the sound engine seem to all be assembly files, the cross compiler doesn't actually interact with this source. Its just linked with rln after rmac compiles the code. I am not sure what other information might be helpful for this post, but if there is anything else that is needed to help troubleshoot this problem, let me know. Thanks! 10-29-19_mod_tracker_crash.zip 11-2-19_RMAC_RLN_JLIBC_RMVLIB_Setup_Scripts.zip Quote Link to comment Share on other sites More sharing options...
ggn Posted November 3, 2019 Share Posted November 3, 2019 23 hours ago, lachoneus said: ggn directed me here post about a possible bug with rmac/rln and the removers library. I have attached an archive that has a bare bones example program that should be clear enough that playing a module in the removers library is causing the program to crash. There is a log folder in the archive that contains logs for both mac and rmac builds for comparison. It also includes makefile.config files for rmac and mac, for each toolchain, for comparison as well. I also attached a current version of my rmac/rln/jlibc/rmblib tool chain setup script. I have only tested this in Kubuntu 19.10, but it should work in any flavor of linux that has access to the Ubuntu repositories (needed for the cross compiler). As for my old tool chain, if you want to test against this directly, I can get a link for the 200MB archive that has a prebuilt cross compiler and jlibc/rmvlib from 2010. It also has prebuilt deb packages of a older kernel version that supports a.out binary emulation(this has been dropped in the most recent versions of the linux kernel). This old tool chain has been my go to for jag dev for a decade now, but I would like to move to a tool chain that I know is buildable and usable in the future. The reason why I think that rmac might be the source of the problem is because if I build the same program with my old tool chain (mac/aln) the program seems to work fine. My old tool chain also uses a different version of the m68k cross compiler, but, from what I understand, because the source files for the sound engine seem to all be assembly files, the cross compiler doesn't actually interact with this source. Its just linked with rln after rmac compiles the code. I am not sure what other information might be helpful for this post, but if there is anything else that is needed to help troubleshoot this problem, let me know. Thanks! 10-29-19_mod_tracker_crash.zip 484.55 kB · 3 downloads 11-2-19_RMAC_RLN_JLIBC_RMVLIB_Setup_Scripts.zip 2.86 MB · 3 downloads First of all thanks ever so much for deciding to stick with rmac. We'll get it fixed, don't worry! Unfortunately I don't have any Linux machines around as I've given up on Linux running smoothly on my machines at home. I'm trying to get WSL on Windows 10 updated to ubuntu 19.10 but it seems like it'll take some time. However I think that if you also upload the generated object files from all folders (rmac/mac/gcc) so I can have a "golden" reference I can then see the differences and when things go haywire. My gut feeling for now is that rln is at fault but I'd like to double check that the object files are also okay before going there. (Yes I suppose I can find a copy of mac/aln and run them on dosbox but I think it'd be better if I had your copy of the object files altogether!) 1 Quote Link to comment Share on other sites More sharing options...
Welshworrier Posted November 3, 2019 Share Posted November 3, 2019 Warning: data segment size of sound_data.o is not a phrase multiple AddSymbols: for file sound_data.o t_bbase = $0 d_bbase = $0 o_bbase = $0 tsize = $0 dsize = $3A9E2 bsize = $0 reloc.tsize = $0 reloc.dsize = $0 AddSymbolToHashList(): hptr=$E1D79510, sym="_song", ofile=$E1F2D8F0, value=$0, type=$7000000 Warning: data segment size of display.o is not a phrase multiple AddSymbols: for file display.o t_bbase = $0 d_bbase = $0 o_bbase = $0 tsize = $5CA dsize = $22 bsize = $20 reloc.tsize = $68 reloc.dsize = $0 In the log file would appear to be an issue when linked in that the linker could be not padding. 1 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted November 3, 2019 Share Posted November 3, 2019 GGN: If you are not using Hyper-V under Windows 10, I'd recommend grabbing VMWare Player (VMWare Desktop Free, or whatever it's called this week), and use that to spin up a Linux VM.. I use it myself for $dayjob and some Jagdev funs, works really well and you can always have a VM for a specific task. It's free to use as long as not commercial use. Might be easier than fighting whatever abomination MS has fused into Win10 Quote Link to comment Share on other sites More sharing options...
+BitJag Posted November 4, 2019 Share Posted November 4, 2019 9 hours ago, ggn said: First of all thanks ever so much for deciding to stick with rmac. We'll get it fixed, don't worry! Unfortunately I don't have any Linux machines around as I've given up on Linux running smoothly on my machines at home. I'm trying to get WSL on Windows 10 updated to ubuntu 19.10 but it seems like it'll take some time. However I think that if you also upload the generated object files from all folders (rmac/mac/gcc) so I can have a "golden" reference I can then see the differences and when things go haywire. My gut feeling for now is that rln is at fault but I'd like to double check that the object files are also okay before going there. (Yes I suppose I can find a copy of mac/aln and run them on dosbox but I think it'd be better if I had your copy of the object files altogether!) Thanks for taking a look at this. Here is a link of the archive I use to setup my old tool chain. There is a readme folder with a readme inside, along with a prebuilt kernel with a.out emulation enabled. This is if you want to test building with this toolchain yourself. If the instructions aren't clear enough, let me know and I can step you through it on a VM if that is most convenient. https://drive.google.com/file/d/10Zk1lYoclQo72DWjewiEvX_hmgvCip6G/view?usp=sharing As for object files. There are object files for the gcc cross compiler, jlibc (not current version), rmvlib, in this archive. I only have the executables for mac/aln. And now that I am thinking through this I feel a bit silly, I have actually never looked for the sources for these programs. I was blissfully ignorant because they just worked until recently. I guess I assumed that the source was so old and unable to build on a modern platform that it wouldn't be worth the effort to look into. Here is an archive of the new rmac/rln tool chain, all object files included in the src folder. https://drive.google.com/file/d/1aS0I6hJHXhtvrvkPtyu7UwyIJi8ZDm4q/view?usp=sharing The gcc cross compiler is installed through a ppa repository. But here is an archive of the files I could find for it in my root. If you need install this like I did either use my setup script, or, follow steps 1 and 2 on this page. http://vincent.riviere.free.fr/soft/m68k-atari-mint/ubuntu.php Just some copying and pasting in a terminal. I wish building a cross compiler from source was this easy... @Welshworrier Nice catch! I don't know if that is the source of the problem, but with my limited understanding it seems Jag does insist on phrase alignment in memory for some things. I don't know exactly what things though... Quote Link to comment Share on other sites More sharing options...
+BitJag Posted November 4, 2019 Share Posted November 4, 2019 Awesome! Glad I looked into where the Madmac sources might be at this point. http://www.dadhacker.com/blog/?p=1049 Turns out that rmac is the litteral progeny of Madmac. (Also saw a familiar name in the comments section down in the comment section, @SubQMod). I know in various places on the web rmac was referred to as the grandchild of rmac. I thought this was from a reversed engineered perspective, not from a derived from the same source code perspective. Thanks again to everyone involved for keeping this updated! Quote Link to comment Share on other sites More sharing options...
ggn Posted November 4, 2019 Share Posted November 4, 2019 Oh damn, I should have been more explicit when I mentioned "object files". I meant the object files created when you built the two examples, not the compilers themselves (so the .o files created like modTkrCrsh.o, gfx/data/gfx_data.o, etc). Sorry I put you into all that trouble really. Although it's not in vain as I'd probably end up asking you for the library files as well (rmvlib.a, jlibc.a, libgcc.a). Yesterday I tried assembling the project's assembly files using rmac and mac. The resulting object files were byte for byte identical between assemblers. So it all points to linker problems (like @Welshworrier pointed out above). 16 hours ago, LinkoVitch said: GGN: If you are not using Hyper-V under Windows 10, I'd recommend grabbing VMWare Player (VMWare Desktop Free, or whatever it's called this week), and use that to spin up a Linux VM.. I use it myself for $dayjob and some Jagdev funs, works really well and you can always have a VM for a specific task. It's free to use as long as not commercial use. Might be easier than fighting whatever abomination MS has fused into Win10 Jesus Christ no :). Never mind that my PC is an old fossil by now, I'm pretty much against running VMs for developing! As Mr xkcd put it eloquently: In comparison WSL is a much better compromise than the trainwreck that is called "spin a VM" - much less resources consumed, shared file system and the ability to run native linux binaries on Windows without spending tons of disk space and RAM :). I was in the process of bringing it up to the latest ubuntu yesterday, but thought to ask @lachoneus for the files to accelerate the process a bit. No harm done though, I'll take a look at rln like I said. Quote Link to comment Share on other sites More sharing options...
+BitJag Posted November 4, 2019 Share Posted November 4, 2019 3 hours ago, ggn said: Oh damn, I should have been more explicit when I mentioned "object files". I meant the object files created when you built the two examples, not the compilers themselves (so the .o files created like modTkrCrsh.o, gfx/data/gfx_data.o, etc). Sorry I put you into all that trouble really. Although it's not in vain as I'd probably end up asking you for the library files as well (rmvlib.a, jlibc.a, libgcc.a). Yesterday I tried assembling the project's assembly files using rmac and mac. The resulting object files were byte for byte identical between assemblers. So it all points to linker problems (like @Welshworrier pointed out above). No worries. I should have though to pre-compile these programs for you, instead of just giving you the source. 11-4-19_mod_trkr_bug_compiled.zip 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted November 5, 2019 Share Posted November 5, 2019 On 11/4/2019 at 6:13 PM, lachoneus said: No worries. I should have though to pre-compile these programs for you, instead of just giving you the source. 11-4-19_mod_trkr_bug_compiled.zip 1.22 MB · 1 download Okay, many thanks for this, it really helped with my findings. So here's what I got: 1. The .o files you supplied that are assembled with rmac and mac are byte for byte identical. This proves that rmac is rock solid and (almost) a drop in replacement for mac - high five! 2. This also stands true for the .o sets of files I produced independently of yours. So we're two for two :). 3. Linking - geez, that proved a major source of pain. I really ought to add a patch to rln that validates search paths instead of blindly accepting them, someone has to get this right :/. As usual, it's no fun adding a path that you have a typo and then the tool proudly reporting that your requested file could not be found, leaving you scratch your head in order to understand if the relative path was wrong or there was a typo or whatever (ok, rant mode off now, sorry!) 3a. Once I sorted out all the files etc (in my usual style I just copy all .o and .a files into the build folder and let rln parse the files from there!) I created a linked .cof file that run on virtual jaguar without crashing - yay! 3b. Out of curiosity I then took your "mod_tracker_crash_rmac" and just pasted the object files and libraries that I used to link my build files and that also resulted in a working binary - double yay! I went ahead and attached the winning combo of .o and .a files. Which leads us to takeaways: 1. Yeah we probably need some more work when it comes to user experience for rmac and rln. Bear with us! 2. I'm not sure what happens with your setup. Some file you link against seems to have an issue. I'd suggest you try linking with my set of object files and see if that works for you. If yes (I sincerely hope so!) then you can take it from there and check your build environment for the bad file(s) that produce the bad .cof. 3. Sadly I couldn't repro a crashing binary after all the above. So if you find the offensive file(s) it'd be interesting if you share them with us for further analysis into what went wrong There we go, sorry for the wall of text but I hope this helps fixing your problem and hopefully we can put this unpleasant experience (for you at least) behind us! object_files_and_libs.zip 2 Quote Link to comment Share on other sites More sharing options...
+BitJag Posted November 6, 2019 Share Posted November 6, 2019 @ggn Just to clarify, and to make sure I understand how you tested this. You took the object files of the example program, the necessary .a file from gcc, and then with the two different sets of .a and .o files for jlibc/rmvlib from the two different tool chains I uploaded, and then did two different links with rln? One linked .cof file with the object files from my old tool chain, and one linked .cof file with the new tool chain. The reason why I ask, and why it's important to test both of these sets of object files, is that I am using two different versions of jlibc/rmvlib in each of these tool chains. And now I realize I may have sent you out on a wild goose chase having you test rmac against two different versions of jlibc/rmvlib. Sorry about that. I think I may have found a clue though. I noticed that the object files from the rmvlib in your archive are from my old tool chain, built back in august of 2018. So, thinking that it could just one object file that could be causing the problem, I decided to replace the object files from a newly built version of rmvlib one-by-one with the ones in your archive, until the program started to work correctly in the emulator. After replacing just sound.o it started working. So, to clarify, I replaced sound.o, built from the most current version of rmvlib, with sound.o file from your archive, built from some version back in august of 2018. Does this mean there is a problem with rmvlib in the most recent assembly code of sound.s? Quote Link to comment Share on other sites More sharing options...
+BitJag Posted November 6, 2019 Share Posted November 6, 2019 Sorry, I should have included a build log for rmvlib. Let me know if you need build logs from any other libraries in my new tool chain. 11-5-19_rmvlib_build_log.txt Quote Link to comment Share on other sites More sharing options...
ggn Posted November 6, 2019 Share Posted November 6, 2019 (edited) First of all, no worries about the supposed wild goose chase - it's all good! As for which sound.o I used: well, I just unpacked the "Jaguar_linux_dev_setup_rv6.zip" and started looking for the filenames of the objects I wanted to link against. It might have been from the "old" folder or the "new" but I'm not sure. The thing is, all sound.o files in that archive (and there are 3 of them) are byte for byte identical between each other. I also did some byte comparisons between the files in the folders the 3 sound.o files are and the files in the .zip file I uploaded above. I still get byte match for all files. Next thing I tried was to assemble sound.s with rmac myself. The resulting .o file isn't byte match identical to the archive's .o files. So that's progress I guess! I'll see what happens from here, there were quite a few changes that happened for v2.0.0 of rmac so it's not impossible that something upset the jrisc parts. I'll have a look and will report back when I have something. Stay tuned.... [EDIT] Now that I think about it: do you happen to know what version of rmac you used to assemble the sound.o in the archives? Or have I got it wrong and it was assembled using mac? Edited November 6, 2019 by ggn Clarification Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.