Jump to content

lachoneus

+AtariAge Subscriber
  • Content Count

    276
  • Joined

  • Last visited

Community Reputation

388 Excellent

About lachoneus

  • Rank
    Moonsweeper

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Utah, USA
  • Interests
    Retro Gaming, Digital Painting, Animation, Programming
  • Currently Playing
    Elite Dangerous, Zelda II: The Adventure of Link, Hellblade: Senua's Sacrifice, Battlemorph
  • Playing Next
    Myst, Riven, Pong, The Gods Will be Watching

Recent Profile Visitors

6,233 profile views
  1. Quick update. Summer 2020 is the target release window. I have a basic road map laid out to help us reach that goal, and for a set of games that really aren't that complicated, this is more than realistic at this point. This has been discussed with Albert as well, to help keep our feet to the fire to get this one out the door this coming year. The primary thing that has been holding us up are visual assets. I didn't take into account how asset heavy Odd-It Will Be Watching would be for one man to complete. But I am determined to finish what was started though, and I look forward to having a large amount of pixel work under my belt with this project. I am excited to finish these games and even more excited to move onto other projects. Thanks for your interest and patience!
  2. Thank you for you work here! This tentative workaround seems to be working. I have tested out with the example program and it works great in my new tool chain. I have attached a prebuilt version of the tool chain (still need to manually download m86k-atari-mint-gcc through ubuntu ppa if you want to compile jag programs from source), along with an updated version of the bash script for anyone interested installing everything from scratch in Linux. Just to clarify, there isn't anything wrong with the rmvlib source, specifically rmvlib/sound/sound.s, this bug seems to be all on rmac? 11-7_19_RMAC_RLN_JLIBC_RMVLIB_Setup_Scripts.zip 11-7-19_RMAC_RLN_JLIBC_RMVLIB_linux_static_build.zip
  3. Sorry for taking so long to respond. I will respond to this quoted post, and then to your latest post shortly after. I am running two completely different tool chains right now. My "old" one, using mac/aln and old versions of jlibc/rmvlib (I am attempting to completely move away from this static tool chain, now unusable with the latest linux kernel). Then there is my "new" tool chain, this is the latest versions of rmac/rln/jlibc/rmvlib from git hub (I assume they are the latest since these sources are from the links I was provided in the other thread about a.out support). These links are where I am getting what I assume are the latest sources for my new tool chain. git clone http://shamusworld.gotdns.org/git/rmac git clone http://shamusworld.gotdns.org/git/rln git clone https://github.com/sbriais/jlibc.git git clone https://github.com/sbriais/rmvlib.git The Jaguar_linux_dev_setup_rv6.zip archive I provided is my old tool chain and everything is built with mac (nothing is built with rmac as far as I know). I dropped the ball by not providing you a built version of my new tool chain (I only provided the bash script that builds this new tool chain from scratch in linux). I didn't register in my head that you weren't planning on getting a linux install going to test my environment, and I don't expect you to do so. I already implemented the suggested change to rmac/object.c that you have in your latest post, and my new tool chain is now compiling the new program just fine. But I still want to post archives of my old tool chain, and my new tool chain (before the change to object.c) for comparison, so you are able to reproduce this scenario if necessary. Keep in mind that both these tool chains are completely separate in their use and testing in my case, and are separated by two different physical computers. I am compiling the same program in both tool chains, my old tool chain gives me a working program (the object files I believe you have been testing against in the post I have quoted above), my new tool chain, minus your latest suggested edit to rmac/object.c, does not give me a working program (object files you haven't been able to test until now). Old Tool Chain - (this is the google drive link to Jaguar_linux_dev_setup_rv6.zip, which you have already downloaded once before - https://drive.google.com/file/d/10Zk1lYoclQo72DWjewiEvX_hmgvCip6G/view?usp=sharing New Tool Chain - (you haven't had access to this until now. This is built using the bash script posted from before) - See File Attached to This Post Program to Compile - (same program that can be compiled in either tool chain, after makfile.config changes. compiled program works in old tool chain, but is not working in new tool chain) - Posted multiple times and can be found in one of my posts above Thanks again, I will be responding to your latest post in just a moment. 11-7-19_new_tool_chain.zip
  4. 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
  5. @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?
  6. 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
  7. 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!
  8. 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...
  9. 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
  10. Thanks Zerosquare! Good to hear. You may need to set the JAGPATH environment variable yourself after running the script, adjust the the paths in Makefile.config to be absolute. With exact paths that point to the library objects, header files, and necessary bin files.
  11. I haven't yet. The last few times I have emailed him (last email was in May), I didn't get a response. Thought I might be bugging him too much with my coding problems, so I decided to focus on other things in the meantime. I will shoot an email off to him today though. Just to let him know about this thread and brief overview what is going on. I was also going to post the open_console() function bug on the rmvlib git repo in case that is where the source of that bug is, and hopefully he will get a notification for that. Also, where should I post possible bugs in rmac/rln? Here or is there a bug tracker somewhere? I don't see an obvious place on Shamus's site where I originally git clone these two programs from. I'm thinking that rmac is not compiling code correctly for the mod tracker routines. I need to do a few more tests, and get some simpler example code together to try as an example for a bug report and to help pinpoint the problem. All I know is that my old tool chain with mac/aln I don't get a program crash when the mod tracker begins playing music, but when I build the same code with the new tool chain rmac/rln it seems to crash at the point where the mod tracker starts playing. If I comment out the code that starts the tracker routine, and build with rmac/rln again, there is no crash.
  12. No problem. I really can't emphasize enough how liberating this is to get out from under executable formats that are slowly disappearing. Huge thanks to you and Shamus, and any others involved, for your efforts to modernize these tools. I will look forward to an update of rmac that doesn't require the minor alteration needed to get this to work, and I will definitely keep you informed if we find anything unusual with rmac. Thanks again!
  13. For ggn and others to test, here is an archive with bash file that will download, modify, patch, build, and install gcc mint cross compiler tools from Ubuntu PPA, RMAC, RLN, JLIBC and RMVLIB. It also has a modified version of Seb's example1 program to test the installation of the tool set. Also included is a uninstall script that will reverse everything the install script does. The script installs everything, but the gcc cross compiler tools, to your home directory in a folder called "Jaguar". Also, the environment variable JAGPATH is only set for the session, and it will disappear if you logout/shutdown. If you want this to be persistent, add the following line to /etc/environment or to /home/<your user name>/.bash_profile . You will need to logout/reboot in order for the change to reflect on your set environment variables. export JAGPATH=/home/<your user name>/Jaguar A few notes: This has only been tested in one distribution, Kubuntu 19.10. Should work on any flavor of ubuntu, and any other flavor of linux if you can properly install the m68k mint atari cross compiler tools. This script is dependent on specific versions of these tools, and the script may break in the future due to continued development. GCC 4.6.7, RMAC 2.0.0, RLN 1.6.1, JLIBC 0.5.11, RMVLIB 1.3.6. You will need to download and build virtualjaguar, or JCP to dump to skunk, in order to test the compiled example1.cof file yourself. I will eventually extend this script to do these two things along with a few other tools for creating graphics. If anyone is interested in a more comprehensive script, let me know and I will make sure to post it here when the script gets to that point. RMAC_RLN_JLIBC_RMVLIB_Setup_Scripts.zip
  14. So Crescent Memories builds without much trouble. I had to comment out any calls to open_custom_console(), a function from the removers library. I am thinking this is a bug in the removers library, as calling the same function in Seb's example gives the same result. I am not 100% sure though. I will attach a log and the c file from the example so other know what I mean. Not having this function is a small sacrifice for knowing that I can continue to dev in a modern OS for the foreseeable future. Huge thank you ggn! Really, this made my year. Now off to making that bash file. rmvlib_open_custom_console_bug.log.txt example1.c
  15. Got it! Thank you so much ggn. I had to alter paula.s and sound.s in the same way that display.s was modified. Just replacing that * token with an equate as explained by ggn above. I then downloaded and modified Seb's example 1 makefiles to point to the appropriate executables and include/lib folders. I had to patch and rebuild RLN so RLN doesn't complain about the -y flag that is used with ALN, using Seb's patch on jagware . And as a last step, I had to manually lin libgcc.a to the JAGPATH/lib/lib folder so RLN can find it. ggn, let me know if there is any information you need from me. I am going to try build Crescent Memories with this as a final test, and then I want to build a quick bash file with the patches as a way of recording this process for anyone else who might be interested in getting these libraries up and running on Linux in the future.
×
×
  • Create New...