Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

BitJag

+AtariAge Subscriber
 View Profile  See their activity

  • Content Count

    335

  • Joined

  • Last visited

Posts posted by BitJag

  4. Posted

    4 minutes ago, SebRmv said:

    You need a more recent version of ocaml. I believe 4.08 is OK (Pervasives has been deprecated and replaced by Stdlib)

    Or you can just revert the commit https://github.com/sbriais/jlinker/commit/2da16f5822d9e00cb38f883eb356718d8c76b339

     

    Just installed a more recent version, and I got jlinker built.

     

    Here is what I get if I just adjust the make file to jlinker.  I am not sure what to make of it, because I am not seeing any option in the makefiles that would refer to "read_long".  I have attached the program and makefiles below.

     

    I will keep investigating, but thought I would post this in case there is something obvious I am missing.

     

    m68k-atari-mint-gcc -mc68000 -Wall -fomit-frame-pointer -O2 -msoft-float -funroll-loops -I/home/lachoneus/Jaguar/lib/
    include -c main.c
    /home/lachoneus/Jaguar/src/jlinker/jlinker.native -a 4000 x x -rq -v -v -v -w -y /home/lachoneus/Jaguar/lib/lib -e -o
    main.cof crt0.o main.o    display.o interrupt.o rmvlib.a jlibc.a libgcc.a  
    File crt0.o found: /home/lachoneus/Jaguar/lib/lib/crt0.o
    File main.o found: main.o
    File display.o found: /home/lachoneus/Jaguar/lib/lib/display.o
    File interrupt.o found: /home/lachoneus/Jaguar/lib/lib/interrupt.o
    File rmvlib.a found: /home/lachoneus/Jaguar/lib/lib/rmvlib.a
    File jlibc.a found: /home/lachoneus/Jaguar/lib/lib/jlibc.a
    File libgcc.a found: /home/lachoneus/Jaguar/lib/lib/libgcc.a
    Invalid_argument("read_long")
    make: *** [Makefile.example:10: main.cof] Error 1

     

    jlinker_custom_console_build_error.zip

  5. Posted

    53 minutes ago, SebRmv said:

    Yes, jlinker is much easier to build than the image converter as it has no dependencies at all :)

    So, I am struggling to get jlinker to build.  I have installed every package available in the ubuntu repositories I can find for ocaml and I get the following error.  And its the same error if I run just make, or ocamlbuild linker.native.

     

    File "linker.ml", line 150, characters 86-100:
    Error: Unbound module Stdlib
    Command exited with code 2.
    Compilation unsuccessful after building 28 targets (0 cached) in 00:00:00.

     

    Since its not finding Stdlib, I assume it has to do with how ocaml is installed through the repositories or a version issue.

     

    My version of ocaml is 4.05.0 .

     

     

     

  6. Posted

    1 minute ago, SebRmv said:

    Maybe. I guess it fails when linking with rln, right? So you could try jlinker to see what happens (you need to install ocaml compiler to build jlinker, this is available on ubuntu). I am interested to hear if it works. And if it does not, please report me the error...

    If I remember right, its been a few months since I last tried.  I will let you know the outcome soon.

     

    I just got somewhat familiar with ocaml this morning trying to get your Jag Image Converter built, so it shouldn't be too much for me to get jlinker built.

  8. Posted

    5 hours ago, SebRmv said:

    On archlinux, you can install the following package to add support for old a.out format.

     

    https://aur.archlinux.org/packages/ia32_aout-dkms/

    Thanks for maintaining this module Seb.   To be honest I haven't done much exploring outside of the *buntu linux sphere since I started using Linux a decade ago.  I may need to see test the Arch Linux waters sometime soon.  I only have a surface understanding of building the Linux kernel, but I assume can add this source for the module into a kernel build for any flavor of Linux?

     

    The tool chain with rmac and rln that we have been able to cobble together in this thread, with the exception of not being able to use open_console() function in the Remover's library, seems to be working well.  Also, I still develop on a system with the my older tool chain, with a.out support in an older Linux kernel. So, I am currently using both the old and new tool chains to develop the same project.  I just have to swap a Makefile for some slightly different paths.  Probably not the wisest way to approach development, but it is currently working for me.  Ultimately, I am incredibly thankful for all the help I have received from everyone on this forum, I wouldn't be doing any of this without that help.  Being able to do any development for the Jag on any of my day to day workstations feels like a small miracle every time I think about it.

     

    I also have an updated script for the rmac/rln tool chain.  Some of the workarounds mentioned in this thread seem to have been implemented into the sources for rmac/rln over the last few months.  I will work on getting that uploaded for those who are interested.

  10. Posted

    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!

     

    cutter_red_alert.thumb.gif.d5412305cedb5c3a1a3b96af0158d039.gif

    • Like 12

  11. Posted

    On 11/6/2019 at 2:34 PM, ggn said:

    Right, so I managed to pass through the maze of twisty little tunnels, all alike, and came out with parts of my sanity :).

     

    I have a fix for the situation but it's super tentative for now - I'll have to run this past Shamus and we'll need to check with our regression suite to see if nothing breaks (because yes, we do have such a thing nowdays!). Without further ado:

     

    Open object.c and go to line 175. There should be an "else" in that line, a closing brace directly above and an opening brace directly below. Change the "else" to "if (w1 & DEFINED)", recompile rmac and you should be good to go!

     

    (unless I screwed something up. Never underestimate this!)

    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

  12. Posted

    On 11/6/2019 at 12:35 PM, ggn said:

    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?

    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

  14. Posted

    @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?

  15. Posted

    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

    • Like 1

  16. Posted

    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!

  17. Posted

    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...

  18. Posted

    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

  19. Posted

    Thanks Zerosquare!

     

    41 minutes ago, joeyaage said:

    Looking forward to trying this out. I have been wanting to install removers library for some time. I got sidetracked with RaptorAPI instead.

    I need to upgrade from Debian 8 (Jessie) to Debian 10 (Buster) before I can install vinvent riviere's gcc-m68k-cross-tools because of dependencies.

    I have made a start and upgraded to Debian 9 (Stretch) so far.

    I can make RMAC and RLN with the change, though.

    The 'install_rmvlib.sh' script works fine in Debian once adjustments are made for adding vinvent riviere's package. There is a web page that describes how to install the packages on Debian. It is a little different from Ubuntu. That's when I got to needing dependencies that require Debian 10 (Buster).

    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. 

  20. Posted

    4 hours ago, Zerosquare said:

    By the way, have you tried pinging SebRmv on his e-mail address?

    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.

  21. Posted

    23 hours ago, ggn said:

    Okay, many thanks for sticking with this - there's nothing more annoying than setting up the toolchain and build system and THEN having to fight with buggy tools :).

     

    Think of the current rmac workarounds as temporary. Me and Shamus will try to get to the bottom of this and fix these issues in the official source tree so nobody has to undergo the ordeal you did! I'll give your script a go soon though, thanks for sharing.

     

    The rmac authors hope that people use it in their toolchain to create useful software and move away from moldy old software that require VMs to use :).

     

    P.S. any other issue you encounter with rmac, let us know!

    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!

  22. Posted

    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

    • Like 4

  23. Posted

    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

    • Like 1

  24. Posted

    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.

    • Like 3

  25. Posted

    10 hours ago, Stephen Moss said:

    I don't know if belboz' Slax.iso uses the files you want but IIRC that is a bootable Linux (or Linux style) interface so if you want to keep working in a Linux style environment perhaps it could be easily adapted to use the files you need.

    Thanks for the suggestions for the slax image.  This is actually where I originally got the rebuilt cross compiler from that I was still using up to this point, so my current dev environment is a grand child of this image that Michael Hill put together 10 years ago.  My main goal with this thread is to see if we can bring the removers library out from under the now unsupported a.out binary emulation that Michael Hills tools set relies on.

    9 hours ago, ggn said:

    Sorry you couldn't get this to work. From your log I see that display.s gets compiled correctly now but sound.s isn't. I just went and double checked, no issues here. I can only assume that for some reason it's using the unmodded rmac version. Can you double check that your Makefile.config points to the freshly modded/compiled rmac? (MADMAC line at the top of the file).

     

    Also, this is not a C compiler program as the errors seem to lie on rmac, so for now you should focus there.

    So I have attempted this a few times from scratch to see if there was some kind of small mistake I made along the way, but I am still coming out with the same error.  I did a screen recording and I have also attached my build logs for rmac, jlibc, and rmvlib to see if there is something you might see that I am missing due to inexperience.

     

    A written break down of what I am doing.

    1. Create a folder to work from in my home directory for JAGPATH variable in make files
    2. Set that environment variable
    3. create a lib and src folder. lib folder is for jlibc and rmvlib to install header files and other essential files after they successfully build. src folder is for building everything
    4. git clone jlibc, rmvlib and rmac into src folder
    5. Install cross tools and gcc from m68k-mint-atari paa
    6. Make suggested change to source in rmac, and then build rmac
    7. Change Makefiles in jlibc to point to newly built rmac, and remove the need to build doxygen stuff
    8. make and install jlibc
    9. Change Makefiles in rmvlib to point to newly built rmac, and remove the need to build doxygen stuff
    10. make and get error.

     

    I am assuming it is something to do with my environment at this point, so I am going to spend more time in the makefiles to see if there is something I still need to change there.  Also, I may spin up a clean version of linux to work from to remove other potential issues. Thanks again for your time and help on this!

    jlibc_build_log.txt rmac_build_log.txt rmvlib_build_log.txt

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...