Chilly Willy Posted February 12, 2012 Share Posted February 12, 2012 If you go to the Virtual Jaguar homepage, you'll find the only version they have for linux is source. Well, that's not too bad - you only need to make one correction to get it to actually compile - In virtualjaguar.pro, change line 19 from LIBS += -lz -Lobj -ljaguarcore -lm68k to LIBS += -Lobj -ljaguarcore -lm68k -lz It's a dependency thing - libjaguarcore requires libz, so the -lz has to come AFTER it in the link order or it doesn't link. After you have that changed and it compiles, now you want to make one more change for an extra feature. Go to file.cpp line 184 where you find // We can assume we have JST_NONE at this point. :-P Add this code right after it and delete the "return false;" line. // CW - I'm going to assume this is a BJL file that loads/runs at 0x4000 WriteLog("FILE: Setting up homebrew (BJL)... Run address: %08X, length: %08X\n", 0x4000, jaguarROMSize); memcpy(jagMemSpace + 0x4000, buffer, jaguarROMSize); delete[] buffer; jaguarRunAddress = 0x4000; return true; And now it loads BJL files that are missing the header. Just give them a file extension of .bin or .bjl and they should load and run fine. The "Gorf 2000 (PD).jag" file is an example of this. To compile, you need gcc, g++, the SDL libs and developer files, and the qt4 libs and developer files. Just use the package manager to select and install them from the repo. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted February 12, 2012 Share Posted February 12, 2012 I've never compiled from source before. Is this amount of assumed knowledge (different argument order, hacking of code, etc..) typical? Quote Link to comment Share on other sites More sharing options...
kskunk Posted February 12, 2012 Share Posted February 12, 2012 I've never compiled from source before. Is this amount of assumed knowledge (different argument order, hacking of code, etc..) typical? It seems pretty common. On various projects I build, I have to patch for differences in my exact environment/build choices, or just fix bugs that slipped into the latest release. Usually, older/stabler builds have fewer problems. Cutting edge releases can be hit or miss. After a while it's second nature. - KS Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 12, 2012 Author Share Posted February 12, 2012 Some of the time, the primary cartaker of a project is working with a different platform. He updates all the different platform makefiles, but cannot test them. So he relies on folks like me to build those other platforms and let him know when the makefiles need a little adjusting. Quote Link to comment Share on other sites More sharing options...
Shamus Posted February 12, 2012 Share Posted February 12, 2012 If you look a little ways down the page in the download section, you'll see a little section under that which tells you how to download the very latest sources from anonymous SVN where this link order problem has already been fixed (seems to bite some architectures and not others). As far as headerless files (so-called "bin" files) goes, they will never be officially supported. It's trivial for developers to create a proper file for popular consumption by adding (or more likely, removing) a single flag in the link stage. And to fix (old) files that don't, there are tools like JiFFI. Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 12, 2012 Author Share Posted February 12, 2012 (edited) If you look a little ways down the page in the download section, you'll see a little section under that which tells you how to download the very latest sources from anonymous SVN where this link order problem has already been fixed (seems to bite some architectures and not others). Good - that would have been the next thing to check. When reporting bugs, always check to see if they have a) already been reported, and even more importantly, b) already been fixed! As far as headerless files (so-called "bin" files) goes, they will never be officially supported. It's trivial for developers to create a proper file for popular consumption by adding (or more likely, removing) a single flag in the link stage. And to fix (old) files that don't, there are tools like JiFFI. That is true to some extent, but you have to remember that complete idiots will be using the program (any program, really) and the author really should take efforts (ESPECIALLY simple ones) to allow for a certain level of idiocy proofing on the program. Look for the most common failures and provide a simple workaround. That will make those idiots go from ranting about your lack of "user friendliness" to ranting about how great the program is to automatically deal withwhatever it is that is their current pet peave. I realize you can't please all the people all the time, but that doesn't mean you shouldn't bother pleasing anybody anytime. Edited February 12, 2012 by Chilly Willy 4 Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted February 12, 2012 Share Posted February 12, 2012 That is true to some extent, but you have to remember that complete idiots will be using the program (any program, really) and the author really should take efforts (ESPECIALLY simple ones) to allow for a certain level of idiocy proofing on the program. Look for the most common failures and provide a simple workaround. That will make those idiots go from ranting about your lack of "user friendliness" to ranting about how great the program is to automatically deal withwhatever it is that is their current pet peave. I realize you can't please all the people all the time, but that doesn't mean you shouldn't bother pleasing anybody anytime. Don't bother. I've been pleading this to Shamus for quite some time and he won't change his mind on the question. Remember, he uses Linux, he's used to user-hostile software 1 Quote Link to comment Share on other sites More sharing options...
Hyper_Eye Posted February 12, 2012 Share Posted February 12, 2012 Remember, he uses Linux, he's used to user-hostile software Fallacy!!! Anyway, I run Gentoo amd64 and I didn't have to modify the link order. So even the ability to test a platforms build doesn't guarantee all flavors will work properly. You can't beat people willing to figure out why something isn't working properly and report it to you. I'm always thankful for a bug report but a bug report that comes with a fix is the taste. 1 Quote Link to comment Share on other sites More sharing options...
Shamus Posted February 12, 2012 Share Posted February 12, 2012 (edited) I'm all for making the user experience as nice and easy as possible (take your Cybermorph ROM image and rename it foobar.baz and Virtual Jaguar will still recognize it ), but the situation with headerless files* on the Jaguar has a long and checkered history--and quite frankly I can't think of any other platform that ever had to put up with such nonsensical crap. Only on the Jaguar do you have the appalling situation where developers put out binaries with absolutely no information on where it goes and where it executes**. Sure, you can make guesses on what to do with that stuff, but in the end it just creates more confusion on the part of end users who really don't understand why the file with no header that they fed to emulator, that was assembled at $5000, doesn't work. I can't think of anything more user hostile than giving the user a dialog box asking where they think the file should be placed in memory and where it should execute! Really, I don't see why the Jaguar has to remain the exception to the well accepted rule that binaries should contain the information within themselves to enable their proper execution. Old headerless files can and should be fixed, and I would be willing to host such fixed files on the Virtual Jaguar website***. @Zerosquare: I'm allergic to user hostile software, that's why I don't use Windows anymore. * Images of cartridges (& Alpine images) are technically headerless, but they are easily detected by size. A random headerless file confers no such advantage. ** Some headerless files put this information in the filename--a laudable but ultimately useless practice. Why not just use a tool like JiFFI to fix the file? *** For authors who will allow it, that is. Edited February 12, 2012 by Shamus Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 12, 2012 Author Share Posted February 12, 2012 Remember, he uses Linux, he's used to user-hostile software Fallacy!!! Anyway, I run Gentoo amd64 and I didn't have to modify the link order. So even the ability to test a platforms build doesn't guarantee all flavors will work properly. You can't beat people willing to figure out why something isn't working properly and report it to you. I'm always thankful for a bug report but a bug report that comes with a fix is the taste. Hmm - sounds like different archs of gcc are less agressive about pruning unused code when linking. That's what that is with the link order - only those functions that are used are actually linked into the final object, but that relies on the linker being able to figure out what is dead code and what isn't. Just for a guess, I'd say the x86 branch (what I'm using) is better at that than the AMD64 branch (what you use). I ran into the dead-code issue with C++ on the MD - the linker was COMPLETELY incapable of telling what was dead code due to the special MD header for the rom, so it left EVERYTHING in. That made my 6KB example almost 500KB in size. 1 Quote Link to comment Share on other sites More sharing options...
Hyper_Eye Posted February 12, 2012 Share Posted February 12, 2012 I'm all for making the user experience as nice and easy as possible (take your Cybermorph ROM image and rename it foobar.baz and Virtual Jaguar will still recognize it ), but the situation with headerless files* on the Jaguar has a long and checkered history--and quite frankly I can't think of any other platform that ever had to put up with such nonsensical crap. Only on the Jaguar do you have the appalling situation where developers put out binaries with absolutely no information on where it goes and where it executes**. One simple approach could be an xml configuration that maps checksums for known headerless files to the location and execution addresses. It certainly beats having to look it up and, barring error on the part of people who report the values for inclusion, it is very unlikely to be wrong. Should the file be unknown or a failure occurs then the dialog could be shown. Granted I don't know a lot about this issue. I usually just punch in 0x4000 and off I go. Quote Link to comment Share on other sites More sharing options...
Shamus Posted February 12, 2012 Share Posted February 12, 2012 Sure, it's possible to do that, but ffs, why? Back in the day maybe there was some reason for it (I'm guessing pure laziness--after all, programmers are a lazy bunch ) but now there is absolutely no reason to put up with such nonsense. Hell, even BJL has had support for .cof files since 1999. And if someone is going to go to the trouble of creating such a thing, they could just as easily put headers on the files and never have to deal with the problem ever again. Distribute a tool like Cowering's GoodJag (*shudder*) to audit and patch them automagically, and call it a day. Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted February 12, 2012 Share Posted February 12, 2012 in the end it just creates more confusion on the part of end users who really don't understand why the file with no header that they fed to emulator, that was assembled at $5000, doesn't work. I can't think of anything more user hostile than giving the user a dialog box asking where they think the file should be placed in memory and where it should execute! That's mostly a non-issue, as 99% of BIN files use $4000 for both the load and start addresses. In fact, I don't think I've ever seen a BIN file with different addresses (programs that don't load at $4000 are usually supplied in a format that includes a header). Just preload the dialog box fields with $4000, include a disclaimer about how the user should check the addresses and BIN is an horrible format and all that, and be done with it. The users will just click OK, it'll work, and they'll be satisfied. In the rare case where it doesn't, you'll have the opportunity to tell them to RTFM Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 12, 2012 Share Posted February 12, 2012 In fact, I don't think I've ever seen a BIN file with different addresses (programs that don't load at $4000 are usually supplied in a format that includes a header). Sinister Asteroids. D-Bug Jetpac 1 Quote Link to comment Share on other sites More sharing options...
Shamus Posted February 12, 2012 Share Posted February 12, 2012 (edited) @Zerosquare: That horse is dead, dead, dead. It's given up the ghost, kicked the bucket, pushed up the daisies, taken a dirt nap, gone to Abraham’s bosom, slept the big sleep, gone to its narrow bed, gone to its reward, met its maker, gone to feed the fishes, bitten the dust, bought the farm, just up and done croaked. Edited February 12, 2012 by Shamus Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted February 12, 2012 Share Posted February 12, 2012 Has it flown over Macho-Grande? 1 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 13, 2012 Author Share Posted February 13, 2012 in the end it just creates more confusion on the part of end users who really don't understand why the file with no header that they fed to emulator, that was assembled at $5000, doesn't work. I can't think of anything more user hostile than giving the user a dialog box asking where they think the file should be placed in memory and where it should execute! That's mostly a non-issue, as 99% of BIN files use $4000 for both the load and start addresses. In fact, I don't think I've ever seen a BIN file with different addresses (programs that don't load at $4000 are usually supplied in a format that includes a header). Just preload the dialog box fields with $4000, include a disclaimer about how the user should check the addresses and BIN is an horrible format and all that, and be done with it. The users will just click OK, it'll work, and they'll be satisfied. In the rare case where it doesn't, you'll have the opportunity to tell them to RTFM That's why my little patch just loaded the rom to 0x4000 and set that as the run address. It's so simple and should take care of those 99% you mention. Problem solved once and for all! Has it flown over Macho-Grande? I don't think it'll ever get over Macho Grande. Quote Link to comment Share on other sites More sharing options...
Shamus Posted February 13, 2012 Share Posted February 13, 2012 Only it doesn't solve the problem once and for all--besides which, it's an ugly hack. Proper headers truly solves the problem once and for all. Really, I can't understand why people want to cling so desperately to a broken non-format. Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 13, 2012 Author Share Posted February 13, 2012 Only it doesn't solve the problem once and for all--besides which, it's an ugly hack. Proper headers truly solves the problem once and for all. Hence the winky. I was doing a little Futurama there. Really, I can't understand why people want to cling so desperately to a broken non-format. If someone stumbles across a file without a header (and they're all over the net), are they going to a) do a little research into why it doesn't work and correct the problem by adding a header or altering the emu, or will they b) whine and bitch and moan and tell their friends that VJ sucks because it can't load that one single file? Three guesses! 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted February 13, 2012 Share Posted February 13, 2012 do a little research into why it doesn't work and correct the problem by adding a header Been there, done that, uploaded the results 1 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted February 13, 2012 Author Share Posted February 13, 2012 do a little research into why it doesn't work and correct the problem by adding a header Been there, done that, uploaded the results Wow - very cool, man. I certainly wouldn't have had the patience to do that. I'd take the EASY way out and hack the emu... like I did. Quote Link to comment Share on other sites More sharing options...
Shamus Posted February 13, 2012 Share Posted February 13, 2012 Let 'em bitch and moan and tell everyone they know that VJ sucks because it won't run Arkanna Demo (PD).bin or Goof 2000 (PD).bin. If they're determined enough, they'll find the answer--it's even built in to the executable in form of Help | Contents. 1 Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted February 13, 2012 Share Posted February 13, 2012 Really, I can't understand why people want to cling so desperately to a broken non-format. Really, I can't understand why people want to cling so desperately to a failed video games console. 3 Quote Link to comment Share on other sites More sharing options...
19rsn007 Posted March 16, 2014 Share Posted March 16, 2014 I don't know what is going on, but on my lubuntu 12.10 32bit installation I can't compile the damn thing...I compiled o2em, and some other emulators and programs in the past with suc6, but this thing is killing me ! Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted March 16, 2014 Share Posted March 16, 2014 Maybe try a higher rev. It must be up to Suck7 by now I compiled o2em, and some other emulators and programs in the past with suc6, but this thing is killing me ! 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.