BitJag

Still moving along. There won't be a 2020 release at this point though. This naturally pushes it to sometime next year. We apologize for the continued shifting of the release date, and thank everyone for their patience. If you want to see the updates to Flappy McFur, we recently played in on our live stream a couple weeks ago.

Fell of my radar because of other interests to be blunt. Thanks for reminding me of this thread though. Read through this thread and I had already forgotten most of what was talked about here. It would still be nice to put together a more refined version of the layout drawing you provided along with a concise rundown of the information in this thread for anyone who might take on creating a method of using a modern device as a JagVR replacement. Just compile everything to make it a bit more digestible. I am interested in doing this, but I can't make it a priority at the moment.

I believe this is how to enable Super Turbo Draw. Press Option to go into menu, press 4 on the number pad to turn on Turbo Draw, then press 8 on the number pad to enable Super Turbo Draw.

I have been working on doing this in the Removers Library, strictly in C code, using Zerosquare's code linked above as a baseline for a while now. I can get things working pretty well, but I get a weird scrolling pixels visual glitch at the top of the screen though (only shows up on real hardware). I think that this has something to do with interrupts, but my knowledge ends there. After hours of blindly trying things with what is available in the Removers library, I haven't been able to get much further than this. Could be a problem with my simple vector library as well, but it seems like I got similar results after stripping the vector stuff out (Its been a few months since I last tackled this). I attached a sample program of the code that I am working with (a simple pong clone), I hope that this might help with getting some streamlined support for rotary in the Remover's Library. I definitely want to get this working in Odd-Ball before that game gets released. @SebRmv I am ready to go in regards to a build environment for the removers library (thanks to the great people here getting things building with rmac/rln), if you need another person to test things. pong_phys_2.zip

We had an episode of "JagVirgin" produced a while ago. No plans on doing more of these. A bit cringe looking back at it now, especially when compared to The Jag Bar's fun to watch format.

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.

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.

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.

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.

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.

Will be doing a rerelease through AtariAge with a compilation of two other games. Here's the thread

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.

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.

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

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!

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!

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

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.

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

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.

@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

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

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

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

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?