-
Content Count
335 -
Joined
-
Last visited
Posts posted by BitJag
-
-
1 minute ago, Zerosquare said:Support for a.out was marked deprecated last March and planned to be removed a few releases later:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Dropping-A.Out
So it's likely it has now been removed completely.
Well, there's some confirmation. Thanks Zerosquare!
-
7 hours ago, ggn said:Ok, so first things first: rmac and rln do have an official distro here: http://virtualjaguar.kicks-ass.net/builds/ or if you need to build from source: "git clone http://shamusworld.gotdns.org/git/rmac" and "git clone http://shamusworld.gotdns.org/git/rln". The first link holds the windows and mac builds, so there's no need to upload versions anywhere. Also I noticed that the version @swapd0 uploaded is an older one, so it's also another reason :). For obvious reasons we don't host any linux binaries so people are encouraged to build from source in that o/s.
A clear indicator to how uninformed I am, I tried just pasting the links for the git repository, without "git clone" to see if I could just see the file structure. Turns out you get a 404 when you do that. Learned that you have to use git to download these. Got em' now.
7 hours ago, ggn said:With that out of the way, I had a go at building the removers' libraries, which meant I had to fiddle with makefiles (yuck!). I'll get back to the topic in a bit, I'll just skip forward a bit to mention the rmac assembly issues:
a) There is a small issue with rmac not handling * as program count on expressions. I didn't fix that inside rmac itself but I bypassed it by altering the offending code. If you open display\display.s you'll find a line that says "padding_nop (G_RAM+$10-*)" and another "padding_nop (G_RAM+$40-*)" which both give out some cryptic errors. These can be overcome by equating * to a symbol in the previous lines. I.e. go to the first padding_nop line and add a line directly above that says "pc1=*", then modify the offending line to ""padding_nop (G_RAM+$10-pc1)". Likewise, go to the second line and add a "pc2=*" immediately above and modify line to "padding_nop (G_RAM+$40-pc2)". That should take care of that.
b) But there's another issue inside rmac that can't be fixed that easily unfortunately. For this you need to modify the code and recompile rmac for now. Namely, open file expr.c and go to line 421. The line there should read "*a_attr = cursect | DEFINED;". Change that to "*a_attr = DEFINED;" and recompile rmac.
If you do these two steps correctly and you've set up your paths to point to the correct tools you should be able to compile the code all the way through. At least on my setup with gcc 9.2.0-m68k it seems to create the library no problems. I just skipped the doxygen doc generation as I don't want to install that.
Thanks for this. I am going to give this a go tonight and tomorrow morning to see if I can get the libraries built. I am hoping that I don't have to rebuild my cross compiler, I will cross that bridge if I need to.
7 hours ago, ggn said:mistakenly thought that the a.out format was dropped back then and only elf was available (that was true to some extent).
A few years back they just disabled a.out binary emulation in the kernel .config file (marked to just not build with the kernel). To remedy this, so I could execute MAC and ALN for compiling, I just needed to re-enable this in the kernel .config file, and rebuild my kernel. I just tried doing this with the latest kernel, and the option is completely gone. I don't know if Ubuntu is just a branch of the kernel, and it only effects that branch, but I did pull the latest kernel from kernel.org (5.3.7 if I remember right), and the flag to enable a.out binary emulation is completely gone. I found that bug report I linked in an early post, and I assumed it was pulled completely from the kernel at this point. I haven't dug any further than that though.
I would still like to get away from the original MAC and ALN anyways for long term support. Because even if a.out emulation isn't gone yet, based on that bug report, the people working on the kernel are assuming no one uses it anymore and it causes more problems than its worth.
7 hours ago, ggn said:Ideally a small test project that uses the library and builds a small binary would be a great help at this point, since I'm not familiar with the library at all!
Thanks again gnn, I believe this will help out allot! I will do my best to get to this point over the next couple days.
4 hours ago, Alex Czarnowski said:compile your own kernel with a.out support enabled
Alex, I don't know if you have the time, but could you check to see if the option to enable a.out emulation is still available on the latest stable version of the Linux kernel? I have tried it a couple times, and don't see it through opening and manually editing the .config file, or by using the make menuconfig command. Its just gone as far as I can tell. The only mention that I was able to find that supports its disappearance is the one bug report where they say that keeping this option in the kernel is actually causing problems.
-
38 minutes ago, ggn said:FWIW I'm taking a look on why Seb's code won't assemble under rmac, so far it seems that a macro is making the assembler mis-behave. (I guess worst case the macro can be rewritten to comply but I'll take a crack at fixing the issue first. Since it's working with madmac and all...)
gnn thanks! Let me know if there is anything that I could possibly help out with. I don't consider myself anywhere near the same caliber of programmer as anyone that has been involved with the removers or RMAC/RLN, but having this so I can continue to dev in my current and future Linux environments is a huge incentive for me to be as useful as I can.
-
12 minutes ago, zzip said:That's a good option too. From your post, I thought you were just trying to get development tools running, which would be a fine use for a VM, but running VirtualJaguar in it I agree would be a problem.
Getting the tools back to a usable state is the best situation for my current workflow. But I am beginning to think the reality is, without having to invest time into learning how to push RMAC and RLN myself, this might be the end of the line for Removers Library in Linux.
4 minutes ago, swapd0 said:These are the latest version that I have.
rln.zip 224.09 kB · 1 download rmac.zip 1.28 MB · 1 download
Thank you! I didn't want to give up on these yet and I wanted to try building these in Linux ti see if I run into the same problems that Seb did or not when trying to build with RMAC.
-
14 minutes ago, zzip said:you could run a version of linux that still supports it in a virtual machine like KVM or virtualbox
Thanks for the suggestion. I have used virtual machines before, but run into the inconvenience of not being able to to get virtualjaguar emulating well inside a virutal machine. It has been a while since I have tried this though, I should give it another shot.
A work around for slow Jaguar emulation in a virtual machine is to create a shared drive between the virtual machine and my host machine and then run virtualjaguar outside of the virtual machine. This does slow down my workflow though. At that point my personal preference would be to have a dedicated, non-updatable linux pc, considering how many times I am booting up virtualjaguar to test code.
As a side note, I am having a hard time finding the source code for RMAC and RLN, everything I have found so far here and here are windows/mac builds. It seems the original repo isn't available anymore. Does anyone know where the source is available for these? Is it supposed to be available?
-
Reloaded a most recent flavor of Ubuntu and noticed that a.out binary emulation is now gone from the Linux kernel. As much as I am able to understand this means that MADMAC and ALN aren't options anymore in Linux, making it impossible to build with the Removers Library as it currently sits. I understand that there was allot of effort put into some replacements a few years back with RMAC and RLN, but RMAC doesn't seem to be a good replacement for the Removers Library at the moment, according to Seb. This was 5 years ago, and I might be missing a forum thread somewhere on the web that might shed some light on moving over to RMAC & RLN/Seb's Linker.
Besides the obvious other options, like moving to Windows or learning to code my own macro assembler over the next 20 years, are there any other options I am missing for getting the Removers Library/MADMAC/ALN working in Linux? I can't complain that I have been able to use Linux and the Removers Library for over a decade with what ever system I am using for my day job, but I don't fancy the idea of being isolated to a static/non-updatable dev system for the foreseeable future.
-
1
-
-
@8bit-Dude It has been a few years since I have touched this stuff, but I did assemble a project to help me get back into it when the time was right. I can't walk you through the project at this point, since it has been a while since I have done anything with it. But I am going to trust my past self to have set this project up in such a way that the code works out of the box once you have a proper build environment set up. I do remember composing the song that plays in this program in Chipper, and that I put this together not too long after my posts in this thread. I hope this helps.
-
11 hours ago, Clint Thompson said:Any news on this? I've been salivating for Odd-It Will Be Watching since October 16th, 2018
Long overdue for an update. Thanks for the nudge.
Most of the programming work before play testing is complete at this point (there will be more after the play testers start). After re-programming Flappy McFur and Odd-It from the ground up, there are still a few gameplay polishes found in the older versions of those games that still need to be added into these rebuilt versions. The reason for the reprogramming of both of these games was that there were problems with combining all three games into a single ROM. Poorly written code was the main culprit. I have learned allot over the last few years, so it felt prudent to start from scratch on both of these to solve the problems I was running into. This ended up feeling like the correct course when I implemented some eeprom stuff later on for Flappy McFur (Highscore tables!).
I have rotary support in Odd-Ball, but there is a visual glitch that I can't resolve after setting the PIT. I reached out to several people for help on this, and the problem has stumped me for quite a few hours, but still no solution to this bug. So, I am planning on doing a post in the programming section of the forum sometime in the future to seek help from the community in general. There is a lot of talent here, I guess I should leverage it a bit more.
With most of the programming out of the way, I have approached the heavy workload of visual assets for Odd-It Will Be Watching. There is ton to be done, and to be honest probably a bit more than there needs to be. I am taking this game as an opportunity to build small portfolio of sprite work for future goals. So at least the extra visual assets will be good for me, and I am hoping they will enrich the experience for players as well.
Work is steady, but taking much longer than anticipated. So, to help satiate those who are eager for these games, and to even get a bit of feedback, here are a few close to finished shots for the pre-title introduction scene.
-
15
-
-
In defense of the A+left/right for page flipping. Anyone who has used a standard jag controller for any length of time knows how easy it is to accidentally pressed left and right when the intention was up or down. Locking left or right behind a button press is wise in my opinion, even if its believed to be common convention. I do like the idea of an auto scroll on the name though.
Also, nothing like a good pain stick every once in a while... Time to turn on my Jag.
-
2
-
-
-
One of us is in San Francisco for Google i/o this week, and have decided to make a little pilgrimage to old Atari HQ tomorrow evening.
We won't being going into the buildings, but will be walking around the premises. If anyone knows anything interesting, or knows somethings he should check out while he is there, we would love to see you at the live stream to share in the experience. It will only be for a few minutes, but we thought it might interest those who haven't been there before.
We will be starting around 6:00pm Pacific Time (sorry for those who are in Europe... It was the only time we could find during Google i/o to do this). And we will be streaming through the BitJag/Jagcorner YouTube channel here https://www.youtube.com/channel/UCjcnSIzsCTi4vGGhO2tg9VQ
-
3
-
-
I've recompiled the VLM boot ROM present on the JagCD with modifications to run on the JagSD and also written a new bios.
(assuming your married...)
Spouse 1
"So what did you do today honey?"
Spouse 2
"Oh... Nothing big, just wrote a new working BIOS for the Jaguar CD."
Spouse 3
"Really? Is that all?"
To us commoners, this seems pretty amazing. I am super excited for this by the way. Thanks to everyone here that has worked with SainT to get through this road block, and of course thanks to SainT for moving mountains.
-
5
-
-
Another thing worth checking.. have you checked the system with another cart that has sound? I am thinking the fault MAY be the actual Audio hookup to the TV (or the TV
). I have had SCART plugs partially come out which has left the picture working perfectly but one audio channel vanishing. Depending on what you are using cable wise might be worth checking too. Perhaps check the AV connector on the back of the Jag, make sure it is nice and happy and that the cable is well seated there too. Or if you have an RF enabled (never thought I'd refer to RF as "enabled"
) perhaps try tuning that in and see if the audio is present there?I have tried a few other games on the same console, they all seem to be working fine, all have good audio. It's just Atari Karts that seems to be having an issue on my main console.
I just tried the same copy of Atari Karts on another console, and the audio is working great. There is something wrong with my main console, and nothing wrong with my copy of Atari Karts thank goodness. This is the first time I have ever had a Jag console start to go out on me. I will take it to a friend that can do some basic testing on the board, but it sounds like I will just have to use another console to enjoy the full glory that Atari Karts has to offer.
Thanks again for all the help, and if anyone has any tips for testing my Jags motherboard for a highly specific audio issue that doesn't seem to effect other games, please share.
Man I love this console

-
1
-
-
Just to be thorough, I dumped Atari Karts to my skunk. Same problem, definitely something to do with the console.
I just did a thorough cleaning of the cart connector, this didn't make a difference unfortunately.
I don't know if I want to spend anymore time outside of testing this on another console just to make sure I can play this game with sound in the future.
If anyone has any other ideas other than testing current on everything on the my Jag's motherboard, it is appreciated. Unfortunately I can't remember or confirm if Atari Karts worked properly on this specific console in the past. This console is a recent purchase, and I only started using it more than I did in the past only a few months ago.
-
Thanks for the feedback everyone. I think I confirmed it is the console that is causing the problem. I just burned a couple eeproms to test a different copy of the game on the same console, and this "new" copy of the game is having the same exact audio problem. I will confirm this with another console tomorrow (I am starting to think it will work fine on another console). But in the meantime, I will take some time to clean the cart connector on the console itself. Up to this point I have been assuming its fine because every other game I try seems to work fine.
I did swap my BIOS back to the original BIOS with no difference, also tried both Jag BIOS versions to see if there was a difference, and there doesn't seem to be an improved difference there either.
Most likely the console though, and I am hoping it is just the cart connector.
-
1
-
-
I've got an Iron Soldier cart that has lost its audio. I've got others, but I've never figured out what happened to that one.
I thought I had lost the audio on an Iron Soldier cart a few years ago, and then I realized that the audio was turned down in-game and that the volume settings were saved to the eeprom when you finish a level or die. So when you boot the console back up to play again, it will have the same audio settings. Not saying your audio is permanently gone, but it would be worth starting a level and making sure the audio settings are turned up.
Do you remember any of the other games you had issue with?
-
A bit obvious maybe, but doesn't the 0 key toggle music on/off in a lot of Jag carts?
Thanks for bringing this up. I tried hitting the 0 key in every place I could think of in the game. Still no response, and based on the little bit of buggy sound that I am getting, it seems to be unrelated to an in-game setting.
-
Is this an official Atari Karts made by Atari, Skunk running ROM or a Repo?
If there is a bad contact or incorrect ROM (corruption) then the initial signature of the cart should fail and red screen. However if the header has been changed to the universal header then there will be no cart check and it would try and run even with corruption. Same is true of Skunk as it replaces the header with it's own, so if the flash isn't quite right or your skunk isn't perfectly seated you may get errors in the flash. (I have also seen my Skunk behaving oddly if the USB cable is connected to the skunk but not to a PC, I assume it's acting like an antenna/capacitor and upsetting things).
Official cart purchased in 95. Good to know that if there is a problem with ROM it should just fail. This gives me hope that it may work on another console. Or there is something else wrong but fixable.
lachoneus mentions a custom BIOS, so he may be using the BJL ROM which doesn't check the signature.
I socketed my BIOS on this console, made a dump of my BIOS and then I just switched the graphics on the Jag cube that shows up before the game starts, and then flashed to a new chip. (Just tinkering) I still have my original BIOS, and until this conversation, I didn't think to switch it back to the original chip to see if that makes a difference.
If this doesn't change anything, and if other consoles don't change anything, I was planning on opening the cart to see if there is something physically wrong. Maybe a dead bug causing a short

-
Did you try an other game in your Jag to see if you have the same problem?
I just went through a handfull of different games and there doesn't seem to be any problems with them. Seems to be specific to my copy of Atari Karts. I am hoping to comfirm this on a couple separate consoles in the coming days.
-
Yes.
Odd things can happen when the contacts are dirty.
Just did a thorough visual inspection of the contacts, and cleaned them. Did notice a bit of gunk on one contact that I had to work at to get cleaned, got it off. Tested with no differences, still no good audio.
Thank you all for the suggestions and keep them coming if you have more. I am going to test this on a couple different consoles over the next couple days to see if there is a difference. I had forgotten that my current console has a custom bios on it, but I haven't noticed anything funny with other games, and I feel like a slightly adjusted bios is reaching at this point...
-
Did you try resetting the cartridge?
* + # + option
Tried it again for good measure. Got the message on the title screen saying that it cleared. Didn't seem to make anything better with the audio.
Clean your connectors.
Will give that a try soon.
Its so strange that no other parts of the game seem to be affected visually or from a gameplay stand point. Also, would the cart even boot if their was the slightest thing different in the data when it verifies the cart?
-
1
-
-
Well, if I had to make a guess, there is an issue with the ROM data. It seems that the SFX kind of work, they seem to layer on top of each other as they occur during gameplay, but continue to loop endlessly until the race ends and the next race begins. I had to crank the audio gain on this to even hear this happening. Unless someone else has any ideas, I am thinking this is a lost cause unless I replace the ROMs... Below is a recording of what I'm talking about, sound kicks in at about 50 seconds in.
https://youtu.be/eNgtgdKYtpw -
Pause the game and hit A, B , or C to bring up the volume controls for each of the sound levels.
Thank you, but no luck unfortunately. Both SFX and music in the pause menu were turned up all the way. Still no audio.
-
Dropped Atari Karts into my Jag and noticed that the game has no audio. I can't seem to find an option in the game or the manual to toggle it on or off and I have tried it with and without my CD attachment with the same effect. Other games seem to be working fine. Am I missing something?
I don't have another console to test to see if the problem is the same on another console. Also, I haven't tried cleaning the pins or anything physical to cart yet.
I played the game for about 30 minutes to see if there might be other errors with the game caused by a hardware issue, but everything else seems to be working fine. Just no audio.
Has anyone had this issue with this game or other games before? I am hoping I am just missing an in-game option, as I would hate to have to buy a replacement for this game because of how expensive they have become.

Removers Library - a.out Binary Emulation Dropped From Linux Kernel
in Atari Jaguar Programming
Posted
Before I hit the sack. This is where I was able to get to.
I was able to get jlibc (from git repo) built using rmac from git, and the ppa for m68k-atari-minit cross-tools, and making the appropriate adjustments to makefiles and environment paths. I ran into an error with sound.s in rmvlib (from git repo), after implementing the two suggested fixes to display.s and to rmac's source file.
rmac -fb sound.s
adding 8 padding nop
adding 0 padding nop
sound.s 192: Error: illegal relative address
sound.s 192: Error: mis-nested .endr
adding 8 padding nop
adding 8 padding nop
adding 8 padding nop
adding 8 padding nop
sound.s 141: Warning: NULL offset in LOAD ignored
sound.s 192: Warning: NULL offset in LOAD ignored
sound.s 266: Warning: NULL offset in STORE ignored
Sound driver code size (DSP): 27C
Available DSP Ram after D_RAM+22C
make[1]: *** [../Makefile.template:6: sound.o] Error 2
make[1]: Leaving directory '/home/lachoneus/tmp/Jaguar/src/rmvlib/sound'
make: *** [Makefile:39: sound] Error 2
Thinking it was the version of gcc provided by the ppa (version 4 something), I decided to try and build the cross compiler from scratch using source files from here http://tho-otto.de/crossmint.php . Dropped an additional pile of hours on top of the many hours over the last decade trying to figured this one out, no luck.
So, resorting to the pre-compiled binaries provided by the same site, I was able to build jlibc again, with a newer version of gcc (9.1.1), but building rmvlib gives me the same error that I was receiving at the beginning of this post. I am not sure if it is a bug/incompatibility with rmac, a mistake in my Makefile (I don't think this is the problem because it is compiling other assembler files just fine up until it gets to sound.s), or something to do with my cross compiler tool set. When it comes to troubleshooting my setup of cross compiler tools, I will need some help stepping through this, because there is something my head just isn't wrapping around when it comes to this.
I am planning on spending more time on this tomorrow.