Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Community Reputation

398 Excellent

About lachoneus

  • Rank

Contact / Social Media

Profile Information

  • Gender
  • 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,394 profile views
  1. Another place to check is while in-game, press pause, and then the A Button. This will reveal a volume slider for music. Pressing B will reveal a volume slider for SFX. There are quite a few official game releases that follow this convention. I thought I had a copy of Iron Soldier with no music, turned out to be the in-game volume option had been turned all the way down. These volume settings are often saved to EEPROM, and are persistent between power cycles.
  2. Looks like I should be thankful for what I have then, and be even more grateful that I have a solution that works in the meantime
  3. It seems so. I am going to be doing allot more work in the next few months with Crescent Memories before release with this tool chain. It doesn't cover every facet of rmvlib, but it should be a good opportunity to see how well everything is working between rmac/rln/jlibc/rmvlib. The setup script still has to make several modifications to several source files in rmvlib. I am fine doing these changes when I run the script, but would it hurt to make these changes to rmvlib at the source? These manual changes are executed between lines 112 - 127 in my setup script, you can see those here https://github.com/lachoneus/ubuntu-rmvlib-install-scripts/blob/master/rmvlib_install.sh . I don't expect this to be changed in rmvlib for my sake, but I wanted to see if this would be something you would be willing to change before we put this thread to bed. Just made the changes to the setup script and ran it. Working great! Like my request to Seb above, there is still one manual modification that is made to rmac's expr.c file to get rmac to play nice when building rmvlib. This was one of the first adjustments that we made when this thread started, and I wanted to look into the possibility of making this a permanent change to rmac, if it doesn't cause any problems for anyone else or the long term development of rmac. At line 55 in the setup script it changes line 467 in expr.c from. I believe this change was implemented to accommodate the changes made to rmvlib that I mention above to Seb. *a_attr = cursect | DEFINED; to *a_attr = DEFINED; Thanks again!
  4. Everything so far seems to be working great. I will keep testing jlibc/rmvlib functions to make sure there aren't too many leaks in the ship I also tested linking the exmaple program with jlinker with this modification for rmac, and it is working as well. Here is the git repository with the scripts I use to set everything up automatically, in case anyone else is interested in testing it out. https://github.com/lachoneus/ubuntu-rmvlib-install-scripts @ggn and @SebRmv , thank you, thank you for your help and your time!
  5. Thank again for looking into this. Everything you gave me builds and runs fine. I mimicked your process of collecting all the built .o files into a single folder and then manually linking them to see if my Makefile's might have a problem. I did this with my rmac/rln toolchain. All the .o files and all the .a files are produced with rmac and vincents gcc. After doing this, I couldn't get a working program. So, I did a byte for byte comparison with the .o files you uploaded and my latest build of jlibc and rmvlib (built with rmac). The following files are different. jlibc.a rmvlib.a sound.o protracker.o I replaced these one at a time, with a .o/.a file made with mac (not rmac), and then tried linking and running the program. It turns out that the only file I need to replace to get a working program is sound.o. The sound.o file that rmac produces seems to be at least part of the issue. I don't know if this is because we need to manually modify sound.s to get rmac to build the object file or not, or if this is something to do with rmac itself. Its strange that I don't need to switch out display.o as well, since we make manual changes to that file to get it to play nicely with rmac as well. I am not sure where you sourced the sound.o file you used in the archive you uploaded, because it doesn't seem to match any of the rmac built files or mac built sound.o files that I have. I need to double check this though. I uploaded an example with all the .o/.a files, with two sound.o files. One compiled from rmac, and one compiled mac (they are marked as such in the filename). I used the same linking command that you posted, but just switched out which sound.o to point to. All the other .o/.a files were built using the latest version of rmac, and with vincent's gcc cross compiler (a.k.a. all the new stuff). Thanks again for your help on this, it seems we are closing in on the issue. rmac_vs_mac_sound_object_file.zip
  6. The old tool chain, that I have been using for about a decade now, is not built from scratch each time I reinstall my OS or move to a new system. I stole this already built tool chain from and Michael Hill's old image and have been using it since. I simply archive the whole thing since it is in one folder, and then unarchive it on the new system. This is because I haven't taken the time yet to learn how to build my own cross compiler. It looks like the day that I will need to learn to do this is coming sooner rather than later... The script I sent you is just for Vincent's cross compiler, and then the environment setup and library/binary build for rmac/rln/jlinker/jlibc/rmvlib.
  7. I took the object files from my old tool chain m68k-aout/mac/aln and tried linking them with rln and jlinker. Both cases seem to fail. I have uploaded both build logs and the object files, so you can double check my work and/or in case you want to give it a try yourself. While I was doing this, I had a thought about my old tool chain. My old tool chain was running an old version of jlibc/rmvlib, (jlibc 0.5.9 & rmvlib 1.3.6). So I downloaded and rebuilt both libraries and with m68k-aout/mac rebuilt the newest versions of the libraries and then rebuilt mod example program, and it works fine. I did this thinking that the newer version of jlibc/rmvlib might be part of the problem, which is not the case. Since we are thinking it is the cross compiler, do you need the binaries for gcc from both tool chains (Vincent's & m68k-aout) for comparison? mod_example_m68k-aout_object_files.zip
  8. I would have never thought to take the .o files from m68k-aout cross compiler and link them with jlinker/rln. I will find some time this morning to do that and report back soon.
  9. @ggn The console functions in rmvlib seem to be working with your latest change rln. Thank you! Unfortunately, it seems that rln is manifesting the same problem as jlinker when it comes to playing back mod files (this is probably a big assumption to make, but it is an interesting coincidence that they are both having problems with mod file playback). I have spent the last couple hours exploring this to make sure that it wasn't a problem with my C code. To make sure that it was just amiga module playback code that was causing the problem, I created a simple program that focuses module playback only. I have built and tested this same program code in 3 completely independent tool chains to ensure that there isn't something wierd being share between tool chains or some other unknown causing problems from previous builds. Here are the results. rln build - atari-mint-cross-compiler/rmac/rln/jlibc/rmvlib(modified for rmac's sake) - program builds, but crashes when attempt to run in virtualjaguar or on real hardware jlinker build - atari-mint-cross-compiler/rmac/jlinker/jlibc/rmvlib(modified for rmac's sake) - program builds, but crashes when attempt to run in virtualjaguar or on real hardware (the behavior on real hardware is a bit different from the rln build. After uploading to the skunkboard with jcp, the screen goes black for a second, but then drops back to the green skunkboard screen. The rln build stops on the black screen and the skunkboard needs to be reset manually) aln build - seb-built-gcc-m68000-crosscompiler/madmac/aln/jlibc/rmvlib(unmodified) - program builds, and plays as expected in virtualjaguar and on real hardware I have included the COF files for byte comparison and testing on your end. I have also attached build logs for each program for each build environment. I have also included an archive with the source code for my program so it can be quadruple checked by someone else other than myself. I have also included my tool chain setup script, in case there is a problem there. To build rln vs. jlinker is a matter of commenting in/out a few lines, these sections are clearly marked if you want to try running this yourself. I don't have a script to build the old aln environment, if you want this, I can provide a link and instructions for setting up this environment. Please let me know if you need anything else from me to hunt down the problem, and thanks again for your time. @SebRmvPinging Seb on this as well. Thanks again Seb for helping out with this. aln_build_log.txt jlinker_build_log.txt rln_build_log.txt aln_modExample.cof jlinker_modExample.cof rln_modExample.cof mod_example.zip RMAC_RLN_JLIBC_RMVLIB_Setup_Scripts_For_Distribution.zip
  10. Same results when pushed with a skunkboard to real hardware. the rln version of the program seems to be running fine (music plays fine), while the jlinker version is not (no music).
  11. No worries. Using rln to link my program and then using the open_console() function from the remover's library results in rln failing (see attached build log). Seb addressed this problem by having me switch to jlinker, and this seems to the resolve the issue with the open_console() function. But now I am having issues with programs that playback MOD files crashing in virtual jaguar, when I use rmac/jlinker tool chain. If I comment out the functions for playing modules, the program runs fine. Comparing this with the rmac/rln toolchain, building the same program with the MOD music results in a successful build, and it runs just fine in virtual jaguar. In short, at the moment I have to choose between having music (rmac/rln) or having the console functions (rmac/jlinker). It seems that rln is the problem when it comes to the open_console() function, and it seems that jlinker is the problem when it comes to playing back MOD files. In regards to jlinker not liking MOD file playback anymore. The only guess I can make is that we made modifications to some assembly files pertaining to the routines to play MOD files in the removers library, in order for rmac to successfully build sound.s, paula.s and display.s. And these changes, when using jlinker, some how break the program when the program attempts to use functions for MOD file playback. Or maybe rmac compiles the assembler files into object files in such a way that rln can link correctly, buy jlinker cannot for some reason. I am not sure, its just strange that rln can handle the modified rmvlib files just fine, but jlinker cannot, assuming that the modified assembly files are the issue. open_custom_console_bug_build_log.txt
  12. Okay, first issue. I have been creating an example program before I upload the tool chain build install script I am working on, and I want this example program to have a little bit of the basics for a simple game (sprites, music, ect...) And I ran into a problem when trying to play a mod file. Below is my explanation and minor exploration of the problem. I have attached an archive for debugging. Included in this archive are two build environments. A jlinker environment and the rln environment. The only difference between each tool chain is the linker used. Both environments "successfully" build the same example program located in /Jaguar/example_programs/generic_example in each build environment. Again, the code and data for the example is the same between each tool chain, the only difference is the linker being used. This example plays a mod file with the Remover's Library. When the example program is built with the rln toolchain, the cof file builds successfully, loads successfully in virtualjaguar, and plays the song. When the example program is built with the jlinker tool chain, the cof file builds successfully, but crashes in virtualjaguar. To make sure that this isn't a coding error, I also built this example program with my "old" toolchain (madmac,aln), and the example builds and runs successfully. Where I believe the problem is is in the alterations to the following files in the Remover's Library. These changes allow rmac to successfully build these specific assembler files in the Remover's library. These changes are applied to both the rln and jlinker tool chain, again the only difference between these two tool chains is the linker being used. /Jaguar/src/rmvlib/sound/sound.s (about line 122) padding_nop (D_RAM+$20-*) changed to: pc1=* padding_nop (D_RAM+$20-pc1) /Jaguar/src/rmvlib/sound/paula.s (about line 67) padding_nop (D_RAM+$10-*) changed to: pc1=* padding_nop (D_RAM+$10-pc1) I am assuming the issue is here, but I don't know for sure. It seems like jlinker is having an issue with this alteration to the Remover's Library's source files. Or, rmac needs adjustments made to itself to make these adjustments to the Remover's Library unnecessary. There are build logs for all tools in both tool chains in /Jaguar/src/build_logs/. And there is a build log for each copy of the example program for each tool chain in /Jaguar/example_programs/generic_example. Before I finish up, here is a reminder of a few other changes needed to get rmac to build itself, and a few more adjustments to rmvlib source files that were implemented in previous posts in this thread. I am including these in case they also have an effect on the jlinker build of the example program. /Jaguar/src/rmvlib/display/display.s (about line 150) padding_nop (G_RAM+$10-*) changed to: pc1=* padding_nop (G_RAM+$10-pc1) /Jaguar/src/rmvlib/display/display.s (about line 169) padding_nop (G_RAM+$40-*) changed to: pc2=* padding_nop (G_RAM+$40-pc2) /Jaguar/src/rmac/expr.c (about line 467) *a_attr = cursect | DEFINED; changed to: *a_attr = DEFINED; Thanks again for any help, and let me know if you need me to test anything or provide any more files for debugging purposes. rln_jlinker_sound_bug.zip
  13. Works like a charm. Both the console example, and my game Crescent Memories. Thank you for taking the time to work this out Seb, I will let you know if I run into anything else with jlinker once I get some time behind it. It will be incredibly useful to have quick access to a console for on screen debugging again. @ggn I don't know if you have been following this, but does the bug that Seb mentions in the above post apply to rln as well?
  14. Sorry, I just realized that this isn't the entire tool chain. Do you want me to scrape out the binaries from my root folders for the gcc cross compiler as well?
  15. Sorry, missed your edit, here is my entire built tool chain just in case. The files you are looking for are in ./lib/lib Jaguar.zip
  • Create New...