Jump to content
IGNORED

Compiling Virtual Jaguar 2.0.2 in linux


Chilly Willy

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. :P And to fix (old) files that don't, there are tools like JiFFI. ;)

Link to comment
Share on other sites

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! :-D

 

 

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. :P 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 by Chilly Willy
  • Like 4
Link to comment
Share on other sites

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 :P
  • Like 1
Link to comment
Share on other sites

Remember, he uses Linux, he's used to user-hostile software :P

 

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.

  • Like 1
Link to comment
Share on other sites

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 :D), 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**. :P

 

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! :P

 

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? :P

 

*** For authors who will allow it, that is. ;)

Edited by Shamus
Link to comment
Share on other sites

Remember, he uses Linux, he's used to user-hostile software :P

 

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. :D

  • Like 1
Link to comment
Share on other sites

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 :D), 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**. :P

 

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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! :P
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 :D
Link to comment
Share on other sites

@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. :D

Edited by Shamus
Link to comment
Share on other sites

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! :P
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 :D

 

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. :grin:

Link to comment
Share on other sites

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. :D

 

Hence the winky. I was doing a little Futurama there. :grin:

 

 

Really, I can't understand why people want to cling so desperately to a broken non-format. :P

 

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! :grin: :mad:

  • Like 1
Link to comment
Share on other sites

  • 2 years later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...