Jump to content

BitJag

+AtariAge Subscriber
  • Content Count

    305
  • Joined

  • Last visited

Community Reputation

410 Excellent

1 Follower

About BitJag

  • Rank
    Moonsweeper

Contact / Social Media

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

6,571 profile views
  1. Thanks for all your work on this @SainT! I am also interested in Linux support if possible, or at least sources so I can build the tools myself. It has been great to be able to do Jag dev in Linux with the Skunkboard, and it would be great to add the Jag GD to my little workforce.
  2. How gratifying it is to set that auto destruct, and because you generally know the station due to having to do some map memorization, you dash straight to that escape pod after a long struggle. Not easy by any stretch of the imagination, but at the time, completely worth it. Also the anxiety of facing off with the alien queen to get that last key card, a very potent gaming memory for me. Now days, unless you are committed to that retro experience, it can definitely feel like a slog without codes. The game relies on taking breaks in a way, as power cycling resets ammo drops. The draw back is that this also resets all the enemies, and worst of all, your on-screen map. The map reset was a design mistake in my opinion, and I would almost prefer not having a map teasing me with the illusion of convenience, and have the game just force me to check my position at the computer consoles. They could have met the player halfway on this with some type of discovery threshold. For example after you discover ~%75 of the map, it just saves a bit in your save file that tells your save game to just show the whole map for a specific level the next time you load your game. This can obviously be abused when the player becomes aware of this, but would be better than nothing in my opinion. Looking at the 128 byte eeprom data in a hex editor, it looks like they would have space to save this kind of data as well (15 maps, 1 bit per map would be ~2 bytes per save file. 6 bytes would be taken for map saving, with a few bits to spare for other things). Looks like there are some free bytes near the beginning and the end of the eeprom, before the hash, that aren't being used after saving to all three save game slots. This is an assumption though, without digging into what data is actually being saved to eeprom... Screw it, I am thinking about this too much, just use codes.
  3. Another note about adjusting volume for Jaguar games in general. It seems that many official Jaguar releases from the 90's used a similar method to adjust music and sfx in games. Probably a convention that Atari insisted on. The SDK documents hint to these design requirements if you were developing a game for them. An example of this is using 0 on the number pad to mute music in your game. Just in case there are other audio issues in other games you play, checking in this hidden pause menu, or 0 on the number pad are good places to start. I have caught myself once or twice thinking that there was something wrong with my copy a game, but instead it was just a save state of the volume controls, slightly hidden within a not so easy to find options menu.
  4. When you are playing the game (any given level has started), press pause. Once paused, press B or A to reveal the instructions for adjusting volume for both music and sound effects.
  5. I remember seeing this as well. It's been a while since I last played Raiden on the Jag, but it seems like this would happen when there was a change of scroll speed? (during boss battles) To indicate the plane is more hovering than flying forward. It's a nice detail.
  6. Will be doing a rerelease through AtariAge with a compilation of two other games. Here's the thread
  7. I don't know much about what you have there, but if I had to guess, these are at least physically unique, at limited to just a few made for previewing purposes. For trade shows/coventions or maybe review copies for magazines? I am not sure though. Also, and someone else more experienced than me can confirm if this is a good idea or not, but you may want to get a piece of opaque tape over the chip that is missing a label. Having the window exposed on the chip like that risks having the data corrupted/erased because UV light might get in.
  8. 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.
  9. 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
  10. 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!
  11. 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!
  12. 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
  13. 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.
  14. 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
  15. 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.
×
×
  • Create New...