Upcoming Virtual Jaguar 2.0.0 release

[+CyranoJ]

Looks much nicer than the old VJ that's for sure

 

Any chance of letting it load binaries as well as carts? Also, it doesn't recognize Beebris, SuperflyDX or Downfall .ROM versions despite them having the correct headers. I'm guessing its doing file size checking too? Would they work if I pad them up to 2mb?

[ggn]

Here's a R346 for Windows. Please note that because of all the supporting DLLs (most notably QT), it's a pretty hefty size

If you rebuild Qt statically linked, it'll make statically linked versions of anything it builds too, meaning no need for extra DLL's.

 

I really wish there was a flag at compile time to make it do that, but it seems the only way is to rebuild all of Qt statically first.

 

1. I hate C with passion. I don't even want to touch C source code. This has just been a week's fiddling with dependancies and getting my build system "sane"
   
2. If people download this build once, all subsequent builds will not include the dependant DLLs, so it'll be much smaller
   

[Shamus]

Hey CJ! Yeah, it only does carts ATM but the infrastructure is there to support all the rest. So don't change anything, just give me a little time to hook in proper support. After all, this is a prerelease. BTW, your ROMs are standard Alpine style ROMs, right (sans 8K RSA cart header)? /me needs to go download them and give them a try.

 

And have to agree with dynamic vs. static linking: With static linking you'd have to distribute an ~200 MB executable every time you made a change, which is just crazy talk.

[Putty]

Shamus. Just gave the windows version a try here.

 

a couple notes.

 

* After editing the config file I suggest rescanning the updated directories. Noticed that I had to restart vj for the games to popup.

 

 

* When starting vj you seems to reserve some memory from the gfxcard and immediately show it without flushing the data first. I was actually looking at my own textures (I'm a games developer) that I had in the video memory before running vj. I've also been able to read the MESS changelogs on vj

Edited June 28, 2011 by Putty

[Shamus]

There is no more vj.cfg file, it's not in the latest SVN anymore (how about updating that ggn? ). As I've said before, VJ uses the system's native configuration handling (=registry on win32, ~/.config on Linux, ??? on MacOS).

 

VJ scans only once at the beginning when run; adding support for monitoring the software folder seems like a bit of overkill at this point. Though if lots of people need it for some reason, I could see adding it. Now if you mean scanning it if you change it in the configuration dialog, well, then, you have a point. That's easy enough.

 

And yeah, I noticed the video hash & trash on running it but didn't care about it all that much, but it's fixed now.

Edited June 28, 2011 by Shamus

[Putty]

Gosh. Excuse my last post. Not sure why i used the term config file.

 

Yes i did mean rescanning the directory after changing the path in the config dialog window.

Edited June 28, 2011 by Putty

[ggn]

For your pleasure, Revision 350 compiled, with a couple of caveats for Shamus:

 

src/gui/mainwin.cpp - #include <unistd.h> for the windows build, as usleep() is defined there.

src/gui/glwidget.cpp - #include <GL/glext.h> for the windows build, as some constants you use are defined there.

 

Or, if you prefer, I could do this sort of maintenance work for you if you give me svn access...

 

[EDIT]Hmmmm, I can't seem to make this build find any rom files - weird...[/EDIT]

[EDIT2]Seems it can only find rom files (software) in vj's directory, not on subfolders[/EDIT2]

Edited June 28, 2011 by ggn

[Shamus]

@Putty: No big deal, just a small misunderstanding on my part. And good suggestions.

 

@ggn: I'll add those includes ASAP. And yes, VJ doesn't recurse into subdirectories, it simply looks in the directory that you name in the config dialog. And only ROMs listed in filedb.cpp are recognized ATM. I'm working on expanding that.

 

The "bios" subdirectory may be going away soon; that stuff will likely end up in the "software" subdirectory.

[+CyranoJ]

BTW, your ROMs are standard Alpine style ROMs, right (sans 8K RSA cart header)? /me needs to go download them and give them a try.

 

They have the "universal AB" header on them, but they are not padded up to the nearest 1mb/2mb/4mb

[+Mitch]

For your pleasure, Revision 350 compiled, with a couple of caveats for Shamus:

 

src/gui/mainwin.cpp - #include for the windows build, as usleep() is defined there.

src/gui/glwidget.cpp - #include for the windows build, as some constants you use are defined there.

 

Or, if you prefer, I could do this sort of maintenance work for you if you give me svn access...

 

[EDIT]Hmmmm, I can't seem to make this build find any rom files - weird...[/EDIT]

[EDIT2]Seems it can only find rom files (software) in vj's directory, not on subfolders[/EDIT2]

 

Just tried it out, thanks for the compile.

 

Mitch

[goldenegg]

Shamus,

 

What assumptions does VJ make regarding the location of SDL? For the majority of Mac users, SDL headers will be located here:

 

/Library/Frameworks/SDL.framework/Headers

 

It appears the compile will only use SDL if present in /opt/lib, which is where the MacPorts version exists. Since it's using the MacPorts SDL library to compile, it requires the same to exist on any system running the binary. This is a problem, as most Mac users will not be using MacPorts.

 

any thoughts?

[Shamus]

If you have the "Frameworks" style SDL installed and the MacPorts version uninstalled, are you able to run sdl-config? If so, you should be able to remove the MacPorts version and compile with the other.

[goldenegg]

If you have the "Frameworks" style SDL installed and the MacPorts version uninstalled, are you able to run sdl-config? If so, you should be able to remove the MacPorts version and compile with the other.

 

No. The Frameworks style SDL does not have SDL-CONFIG.

[ggn]

R351 is out. Compiled out of the box here, so I'm happy . I could have sworn though that one of the conditional dependencies is libcdio, but the current build seems not to need it at all? Shamus? Edited June 29, 2011 by ggn

[goldenegg]

If I uninstall SDL from MacPorts, I can modify makefile-qt prior to compiling and add the path /Library/Frameworks/SDL.framework to INCPATH. Doing so gets me much further through the compile, but it still fails. At multiple points it's trying to run SDL_CONFIG, which doesn't exist. It errors out with undefined symbols:

 

Undefined symbols:
 "_SDL_UnlockAudio", referenced from:
     DACWriteWord(unsigned int, unsigned short, unsigned int)in dac.o
     DACWriteWord(unsigned int, unsigned short, unsigned int)in dac.o
 "_SDL_LockAudio", referenced from:
     DACWriteWord(unsigned int, unsigned short, unsigned int)in dac.o
     DACWriteWord(unsigned int, unsigned short, unsigned int)in dac.o
 "_SDL_Init", referenced from:
     _SDL_main in app.o
 "_SDL_JoystickGetAxis", referenced from:
     JoystickExec()     in joystick.o
     JoystickExec()     in joystick.o
 "_SDL_JoystickGetButton", referenced from:
     JoystickExec()     in joystick.o
     JoystickExec()     in joystick.o
     JoystickExec()     in joystick.o
 "_main", referenced from:
     __start in crt1.o
    (maybe you meant: _SDL_main)
 "_SDL_CloseAudio", referenced from:
     DACDone()    in dac.o
     DACWriteWord(unsigned int, unsigned short, unsigned int)in dac.o
 "_SDL_GetError", referenced from:
     _SDL_main in app.o
     DACWriteWord(unsigned int, unsigned short, unsigned int)in dac.o
 "_SDL_PumpEvents", referenced from:
     JoystickExec()     in joystick.o
 "_SDL_OpenAudio", referenced from:
     DACInit()    in dac.o
     DACWriteWord(unsigned int, unsigned short, unsigned int)in dac.o
 "_SDL_PauseAudio", referenced from:
     DACDone()    in dac.o
     DACInit()    in dac.o
     DACWriteWord(unsigned int, unsigned short, unsigned int)in dac.o
ld: symbol(s) not found

 

Is SDL_CONFIG responsible for the missing symbols? Do you think including sdl_config.h would help?

 

EDIT:

 

Just got A LOT further. Edited makefile-qt again, removing `sdl-config --lib' and adding '-framework SDL' to LIBS. Now the compile gets all the way to linking before it fails.

 

g++ -headerpad_max_install_names -o virtualjaguar.app/Contents/MacOS/virtualjaguar obj/about.o obj/app.o obj/configdialog.o obj/controllertab.o obj/filelistmodel.o obj/filepicker.o obj/filethread.o obj/generaltab.o obj/glwidget.o obj/imagedelegate.o obj/mainwin.o obj/blitter.o obj/cdintf.o obj/cdrom.o obj/crc32.o obj/dac.o obj/dsp.o obj/eeprom.o obj/event.o obj/file.o obj/filedb.o obj/gpu.o obj/jagdasm.o obj/jaguar.o obj/jerry.o obj/joystick.o obj/log.o obj/memory.o obj/mmu.o obj/objectp.o obj/settings.o obj/state.o obj/tom.o obj/universalhdr.o obj/unzip.o obj/wavetable.o obj/moc_about.o obj/moc_configdialog.o obj/moc_controllertab.o obj/moc_filepicker.o obj/moc_filethread.o obj/moc_generaltab.o obj/moc_glwidget.o obj/moc_mainwin.o obj/qrc_virtualjaguar.o   -F/Library/Frameworks -L/Library/Frameworks -lz -Lobj -lmusashi -framework QtOpenGL -framework QtGui -framework QtCore -framework OpenGL -framework AGL -framework SDL
Undefined symbols:
 "_main", referenced from:
     __start in crt1.o
    (maybe you meant: _SDL_main)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [virtualjaguar.app/Contents/MacOS/virtualjaguar] Error 1

[Shamus]

@ggn: Great news on the compilation front! libcdio is not a hard dependency at this point, and, depending on how things go, may reappear on the Linux side only until I can figure out if it's truly going to be cross-platform.

 

@goldenegg: sdl-config (note, all lower case) is a script that comes with the SDL libs that should be put somewhere in the path where it can be run from a terminal; it's what tells the compiler what and where to include and link stuff from on your local filesystem. If the "frameworks" version doesn't have that, how do they expect you to be able to compile anything against it?

 

I think I'm getting to the point where my knowledge of how things work on a Mac has reached its limit. Maybe someone else knows? Maybe the SDL guys would know?

[goldenegg]

@ggn: Great news on the compilation front! libcdio is not a hard dependency at this point, and, depending on how things go, may reappear on the Linux side only until I can figure out if it's truly going to be cross-platform.

 

@goldenegg: sdl-config (note, all lower case) is a script that comes with the SDL libs that should be put somewhere in the path where it can be run from a terminal; it's what tells the compiler what and where to include and link stuff from on your local filesystem. If the "frameworks" version doesn't have that, how do they expect you to be able to compile anything against it?

 

I think I'm getting to the point where my knowledge of how things work on a Mac has reached its limit. Maybe someone else knows? Maybe the SDL guys would know?

 

I'm quite familiar with sdl-config. Unfortunately the 'official' SDL framework for MacOS does not come with it. I believe that simply including the SDK framework as I did manually in makefile-qt is all that should be needed to compile against it. The problem is that there remains a compile error as listed at the bottom of my previous post.

 

It might be worth taking a peak at another emulator like sdlmame, SSNES or PUAE to see how they handle it.

[Shamus]

Stuff like -framework is an Apple only extension to gcc and not portable (= untestable by anyone who doesn't have a Mac). Does sdl-config on the Mac have a --static-libs option? Linking it in statically would be a better way to do it, as it's not nearly as monstrous in size as Qt is.

[goldenegg]

Stuff like -framework is an Apple only extension to gcc and not portable (= untestable by anyone who doesn't have a Mac). Does sdl-config on the Mac have a --static-libs option? Linking it in statically would be a better way to do it, as it's not nearly as monstrous in size as Qt is.

 

Yup. I've compiled r351 using --static-libs. Let's see how that works for people.

 

COME GET YOUR r351 MACOS BINARY!!!

virtualjaguar-macOS-r351.zip

[goldenegg]

Looks like r351 has a problem finding ROMs. No matter what path I give (full or relative), it won't show any ROMs in the app.

 

EDIT:

 

As GGN reported, it appears VJ is looking at it's location for ROMs and ignores the path in preferences.

 

EDIT 2:

 

I've started doing some work with the QMC2 frontend for MAME/MESS. Like VJ, it uses QT. I've noticed that they have QT create the xcodeproj file and use that for the compile. I've attached the makefile to this post if you want to have a look. This might make compiling on MacOS more straightforward.

 

You can grab the full source from their site.

 

http://qmc2.arcadehits.net/wordpress/download/#sources

Makefile.zip

[Shamus]

Yeah, there's a slight problem with it not kicking off the file discovery thread in that revision for some reason. Usually if you close and reopen VJ, it works. Dunno why. I *think* I've solved it in the latest version, though (not yet committed). I still have some stuff to fix in the file discovery part before I commit it.

[Shamus]

@goldenegg: Unfortunately that makefile uses xcodebuild which is Mac only, so it's a no-go. Someone who wants to take it upon themselves to convert the makefile to use xcode and all that is certainly welcome to do so, but there's no way that we can support it at all.

 

@CJ: I'm starting to think that padding out the files is probably the right way to go as otherwise there's no way to detect what the file is other than detecting the universal header or go by file extension (.j64 in this case). If you pad them out, then at least we can have an idea what the file is, even if it doesn't have a proper file extension.

 

If you do decide to go that route, you can leave the universal header off and then the .rom extension is applicable, but you have to pad it out to then nearest 1MB - 8K in that case (it's an "Alpine" ROM then).

 

I don't know what your guys' needs are in this area, so I'd love to hear your thoughts on this.

[ggn]

Well, here's what I do to detect stuff in JiFFI:

 

1. Check for COFF header
   
2. Check for JAGR v2/v3 header
   
3. ROM files created by JiFFI (essentially homebrew stuff with universal rom header and a small program to copy the program to memory and run it)
   
4. Check for ULS image (you can extract the homebrew binary without booting from CD)
   
5. Check for universal rom header
   
6. If none of the above is true, assume ROM or BJL
   

 

The program doesn't really care what size is the ROM, but when it creates ROMs out of homebrews, they are padded to 1 or 2mb.

 

So essentially what I'd personally do would be to check for everything else first and when it comes down to bjl/headerless rom, ask the user to take the responsibility of selecting whether it's a ROM or a BJL (in which case, select load/run address - or even hardcode it to $4000). The way I see it, since ROM files for the Jaguar is a mess, let's try to do our best to support everything.

 

 

My 5 eurocents

Edited June 30, 2011 by ggn

[Zerosquare]

Here are a few heuristics you can try if you reach step 6 on ggn's list :

 

- Check the (big-endian) longword at address $404 . If it is equal to $00802000, then it is a ROM with a header. (This is the initial 68K PC address ; almost all ROMs use this value).

- Check the 4 bytes at address $400. If they are all identical, there is a good chance it is a ROM with a header. (This is the MEMCON1 value ; the 4 bytes are identical so that no matter how the bus width is configured, you get the same value).

- Check if the file is larger than 2 MB. If it's the case, it's a ROM (can't be a BJL file, since it wouldn't fit into RAM).

- Check if the file size is equal to a power of two. If it is, it's probably a ROM with the header.

- Check if the file size is equal to a power of two minus 8,192. If it is, it's probably a ROM without the header.

[Shamus]

Agreed, it is a mess but I think I was able to distill it down to a few use cases which you can read about in the README under the section "Read This or Else!" or here. I think that my approach (figure out what you can, forget the rest) is a good one and eventually we can tame this nonsense by refusing to give an inch.

 

I think that for a debug build of VJ that asking for a load/run address for an unknown file is possibly a good idea, but for most "point-and-duh" users out there, they don't care about any of that stuff, they just want to be able to select it and run it without any hassle.

 

The way VJ does it is to check the file for a universal header, then take a CRC32 of the file and check against its internal database for a match (this is mainly because people can't seem to be arsed to rename their ROM files, and it's better overall as VJ then knows for sure what it's dealing with). If it isn't in there, it tries some heuristics to determine if it's a ROM/Alpine ROM (by file size) or a ABS/COF/Jaguar Server executable (by header).

 

I suppose it would be possible to assume that files with the universal header in front are really "ROMs", it just makes the file handling code *that* much more complicated. I guess what I'm getting at is this: Is there any reason that you guys would *prefer* to have these kinds of "ROMs" unpadded?

 

BTW, r352 is available and has the ability to run "unknown" software (look in the config dialog). Beebris works a treat.

Edited June 30, 2011 by Shamus