Jump to content
IGNORED

Upcoming Virtual Jaguar 2.0.0 release


Shamus

Recommended Posts

@ggn: Well, knock me over with a feather. I guess those guys never got around to getting the point release out, eh? :P BTW, if you have any ideas for how to make the various iconography in VJ better, I'd seriously love to see it. :)

 

@CJ: Did you download and use the "ROM" from this post? :) http://www.atariage.com/forums/topic/183828-upcoming-virtual-jaguar-200-release/page__view__findpost__p__2315102

 

Also, if you have a decent picture of a Skunkboard, send it my way. ;) Still debating about load/run, I'm still leaning towards having it in for the version that will have the debugger vs. the one for general use. Although I'd change my mind if there was enough demand for it. :D

 

@Miker: All great ideas, and will go in as soon as I code them in. :D

Link to comment
Share on other sites

Nice one with the licdio there ggn.

 

Been looking for that post,or one that explain the problem, for about a year but could never find a damn thing. Guess it helps if you know where to look...:/

 

Thanks for the heads up. I'll be experimenting with this a little bit now to see what happens.....whatch this space, or not, you might get bored :P

  • Like 2
Link to comment
Share on other sites

 

Yep, that one worked fine. The issue is that if a hash value for a ROM has to be in the internal database for it to be recognized then the emulator becomes useless for development. It should also recognize .ABS/.COF/.BIN for that very same reason (even if it has to prompt for addresses)

 

[EDIT]

 

Allow unknown software in the broswer lets you load .ABS/.COF ;-) Still can't load headerless, or headered ROM images that are not checksummed.

Link to comment
Share on other sites

It'll allow you to load them either with or without the universal header as long as they're padded out to 1/2/4MB boundary (-8K if headerless). If you read back a few posts, you can see the discussion about it. ggn said there's no reason why you guys would prefer those to be unpadded and it makes the heuristic easier to deal with if they are.

 

Hashes go into the database for released stuff only, and once I know where they come from I can mark them as "verified". I also put hashes in there for known bad dumps as well, to keep the "why doesn't VJ work with Super Foo?" type of comments to a minimum. The idea is to make it give as much information to the user as possible about what they're attempting to run, and hopefully give VJ the chance to act on that information as well.

 

BTW, did you notice that with that "ROM" package for Beebris that the image in the cart loader was different? :)

Edited by Shamus
Link to comment
Share on other sites

It'll allow you to load them either with or without the universal header as long as they're padded out to 1/2/4MB boundary. If you read back a few posts, you can see the discussion about it. ggn said there's no reason why you guys would prefer those to be unpadded and it makes the heuristic easier to deal with if they are.

 

Guess I'll add a padder app to my build chain then :-)

 

BTW, did you notice that with that "ROM" package for Beebris that the image in the cart loader was different? :)

 

I did indeed. sh3 will love you for it, means more artwork required :)

 

btw, Steem Engine went open source, maybe you could "borrow" chunks of the Boiler Room now ?

Link to comment
Share on other sites

mr Shamus, ...when are we going to see it....version 2.0 that is (or will the rejigged 'jagulator' beat it to a new release)

 

Also i recently downloaded a svn version from emucr, there seems to be a couple of issues with it

 

A- the telly mode don't work

 

B- you can't use 'old style rendering' mode (the emulator crashes) (old style rendering mode makes the emulator window smaller and runs faster)...only opengl mode works on that version

 

Any chance you could fix those two issues in your next svn release

Link to comment
Share on other sites

Cheers Carmel,

 

To answer your first question, VJ 2.0.0 will be released when it's ready. ;) I know people hate to hear that, but it's the truth. :) There are a few loose ends that need to be tied up (like the controller config), but as soon as those are done and the people testing give the go-ahead, we'll do an official release.

 

Also, it seems that those guys at emucr are several revs behind as r336 is quite old now. :) Your best bet is to download a copy from this thread from the guys who are making win32 (ggn) and mac (goldenegg) compiles of the latest svn available; the latest rev is r357 (and it will say so in your title bar when you run it).

 

Run that and then we can talk about issues with it. :D

Edited by Shamus
Link to comment
Share on other sites

Hey all, I'm thinking of merging the qt-experimental branch to trunk ahead of schedule, since it seems that the codebase is pretty stable now.

 

Any objections? Please speak up now. :)

 

I'm good with this!

 

Also, here are the MacOS r357 and r358 binaries.

virtualjaguar-macOS-r357.zip

virtualjaguar-macOS-r358.zip

Link to comment
Share on other sites

Hey all, I'm thinking of merging the qt-experimental branch to trunk ahead of schedule, since it seems that the codebase is pretty stable now.

 

Any objections? Please speak up now. :)

 

I'm good too. (also, UI is a bit secondary to me, I'd vote for increasing the emulation accuracy over it any day ;))

 

Plus, attached r358 windows

vj2_r358.zip

Edited by ggn
Link to comment
Share on other sites

@ggn: I agree vis-a-vis accuracy, but people want the shiny. So I'm giving them the shiny in order to buy some time to fix the other stuff. ;)

 

@CJ: Could you show me some examples? If it's low enough hanging fruit, maybe I can get it in for 2.0.0. :)

Link to comment
Share on other sites

That would be great. :)

 

OK, qt-experimental has been merged back into trunk. Won't the emucr guys be surprised when they compile the latest. :D

 

Should we use trunk from this point forward and stop using the experimental branch? I ask since I noticed the experimental branch is now r359.

Link to comment
Share on other sites

Yes, all development from here on out will be in trunk (at least until I decide to go out on another branch ;)). You'll notice that if you update your branch no files will change. It's an artifact of the way SVN does things. :P

Link to comment
Share on other sites

Merci beaucoup Mr Shamus, will d/l the windblows rev's very shortly

 

silly question to ask but i think it needs answering, i am guessing that VJ 2.0 will only support existing game images (i.e bin/rom/j64/jag etc) and not supporting iso's/cdi or large bin's etc (even though i could swear i saw someone mentioning here that future rev's. of VJ might support cd/iso images)

Link to comment
Share on other sites

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