283 replies to this topic

[Putty]

I wont be able to give compiling vj a try untill the end of next week.

My desktop broke down. Seems to be a faulty power supply. (OMFG 4 months out of warranty. last time I buy zalman)

So I hope someone else will give it a try before next week

[Shamus]

Hey CJ, I had totally forgotten about Steem (wow, what a beaut of an emu!). I never used the debug build, but if it has your endorsement I'll definitely have a look.

I know they intended to open up the source for Steem, I wonder what happened? The Linux build was quite spiffy.

BTW, I almost have the qmake/.pro building the whole thing, so hope to have a non-broken build system in place very soon.

[goldenegg]

Shamus, on Fri Jun 24, 2011 9:10 PM, said:

@goldenegg: Awesome! You got it to build! \o/ \o/ \o/

Not sure why it's not finding the BIOS, and it should be able to use relative paths just fine (as long as you prefix that rel path with a dot slash "./"). Also you might want to look through the log file that it makes (virtualjaguar.log) to see if there are any clues in there as to why it isn't finding stuff.

A lot of games require the BIOS in order to work properly, some require both the BIOS and the DSP (Checkered Flag comes to mind). Attack of the Mutant Penguins is one of those that requires at least the DSP (maybe the BIOS too).

vj-2.0.0-aotmp-1.png

The blitter is much slower than the older (less compatible) blitter, but it can and will be optimized. Any game that makes heavy use of it (like AvP) are naturally going to be slow at this point. Games that don't use it will be faster; Rayman plays at almost full speed (sans DSP) on my old 1.7GHz Pentium-M.

The latest version (r344) has a rudimentary config dialog which lets you edit the paths at least. Still sorting out the rest and trying to figure out how to do it right. That and the Qt build system.

BTW, how much of a pain was it to install pkg-config? Just wondering what is and isn't reasonable to expect from the build system.

I found out why relative paths are broken in MacOS. When you run VJ from Finder, it opens a terminal window and runs the program from your user directory instead of where the executable is located. Because of this, all relative paths are based on your user dir. I can get around this for now by running VJ from a terminal window in the proper dir.

I still can't get the BIOS to load and can't confirm the DSP is enabled. The defaults in VJ.CFG have both the BIOS and DSP disabled. I tried enabling them, but that didn't make a difference. I did clear the previously save preferences before trying this.

Here's my log output when trying to run Mutant Penguins. Do you see anything which may be causing problems?

Spoiler

VJ: SDL (joystick, audio) successfully initialized.
MainWin: Paths
    jagBootPath = "./bios/[BIOS] Atari Jaguar (USA, Europe).zip"
    CDBootPath  = "./bios/jagcd.rom"
    EEPROMPath  = "./eeproms"
    ROMPath     = "./software"
Virtual Jaguar SVN Jun 25 2011 (Last full build was on Jun 25 2011 10:41:54)
Initializing jaguar subsystem...
--> GPU stats were reset!
DAC: Successfully initialized.
CDINTF: No suitable CD-ROM driver found.
About to attempt to load BIOSes...
JaguarLoadROM: Attempting to load file './bios/[BIOS] Atari Jaguar (USA, Europe).zip'...Succeeded in finding extension (.zip)!
VJ: Loading "./bios/[BIOS] Atari Jaguar (USA, Europe).zip"...(ZIPped)...FILE: Found software file 'jagboot.rom'.
FILE: Uncompressing...success! (131072 bytes)
OK (131072 bytes)
VJ: BIOS is available...
JaguarLoadROM: Attempting to load file './bios/jagcd.rom'...Succeeded in finding extension (.rom)!
VJ: Loading "./bios/jagcd.rom"...OK (262144 bytes)
VJ: CD BIOS is available...
JaguarLoadROM: Attempting to load file '/Users/goldenegg/Documents/Source/vj344/software/Attack of the Mutant Penguins (World).j64'...Succeeded in finding extension (.j64)!
VJ: Loading "/Users/goldenegg/Documents/Source/vj344/software/Attack of the Mutant Penguins (World).j64"...OK (2097152 bytes)
CRC: CD5BF827
EEPROM: Could not open file "./eepromsCD5BF827.eep"!
GUI: Resetting Jaguar...
--> GPU stats were reset!
Jaguar: 68K reset. PC=802000 SP=00200000
TOM: Vertical Interrupt written by M68K: 2047
Write to DSP CTRL by M68K: 00002000
Write to DSP CTRL by M68K: 00000001

Rayman seems to work perfectly on my Core i7. Still a little surprised AvP is so slow with this type of processing power, but it probably is just an optimization issue.

Installing pkg-config is simple when done through MacPorts. There's really nothing difficult at all about setting up a Mac build environment for VJ. As I posted on the other forum, I'd be more than happy to provide regular Mac binary updates.

EDIT 2:

Just had a crash playing Tempest 2000. The game was playing at approx 10 - 15fps and ended up crashing VJ after 5 or so minutes of play. I've attached the log as an attachment to this post

Attached Files

•  virtualjaguar.log.txt   66.12K   16 downloads

[Zerosquare]

Shamus, on Fri Jun 24, 2011 9:10 PM, said:

A lot of games require the BIOS in order to work properly

That's weird. Games don't rely on the code in the boot ROM (unlike some other consoles, it doesn't contain any functions / data intended to be used by games), and they work fine with the BJL ROM, which is very different from the orignial ROM. How do you initialize the hardware registers when BIOS is disabled ? (I think the problem originates here).

[Shamus]

@Zerosquare: You're right, there's no functionality in the BIOS that the games are relying on, it's the way it sets up the environment. Some programmers rely on the BIOS setting things a certain way and won't work 100% without that (Checkered Flag comes to mind, I know there's others, but I just can't remember which). I could check the RAM & I/O space after the BIOS has run and initialize the system that way without it, but I just haven't gotten around to it.

@goldenegg: There is no more vj.cfg file anymore. It's all done through whatever the system uses for its native configuration and the GUI now. Hm, it's finding the BIOS (and CD BIOS too) and loading them; I'm not sure why it's not running them... I can see it's going straight to the cart in this line:

Jaguar: 68K reset. PC=802000 SP=00200000

I guess I have to stick those config options in the GUI now...

Also, you can bring even a fast processor to its knees by utilizing judicious waste and bad algorithms. If you look at the blitter code, you can see it's based upon ASIC code and as such, is very unoptimized. I'm not surprised at all that AvP runs so slowly on it.

[ggn]

Hi,



I wish I had good news to share with the Win32 build I'm doing atm, but it's not done yet.

Most of the time, I fiddled a lot with my mingw-msys install in order to make it sane (or "sane" enough for vj ). For reference, I used the install method described here, as this installs a more recent gcc than mingw. Also, setting up qt properly on windows is really required, read [url=http://sector.ynet.sk/qt4-tutorial/preparations.html[/url] for some infos).

After this, while compiling the qt GUI, I noticed that some header files on the parent dir (../) weren't being included, In the end I added this line to virtualjaguar.pro:

INCLUDEPATH =..

and running qmake made everything happy...

...until I stumbled upon lots of dependency errors . These seem to be glibc related, mostly to do with endianess, so for the time being I just stripped off the header files from the source release of glibc (I couldn't find a compiled version for mingw) and shoved them into my includes dir. I know this is going to bite me in the ass at some point, but well one problem at a time .

After compiling of the GUI finished I tried to run make on the top level dir, but it seems that some of the gui files still haven't compiled. So I added these lines to virtualjaguar.pro:

HEADERS += controllertab.h
HEADERS += filelistmodel.h
HEADERS += imagedelegate.h
SOURCES += controllertab.cpp 
SOURCES += filelistmodel.cpp 
SOURCES += imagedelegate.cpp

and they were compiled happily again.

Next step was the icon (boy, the fun never stops around these sources, huh? ). make just couldn't find the rule to compile the icon file, even when I removed the fancy #$(ICON): thing and replaced it with the filename of the object file directly. In the end I just invoked windres from the command line and it created the object file with no probs (shrug my makefile-fu is non existent!).

Oh yes, I forgot to mention that no matter where I included gl.h on glwidget.c/.h, it wouldn't find the 2 defines needed, so I did the logical bit and sledgehammered the 2 defines from the gl header file directly to the target header

#define GL_UNSIGNED_INT_8_8_8_8                 0x8035 
#define GL_CLAMP_TO_EDGE                        0x812F 

Finally, came the linking bit. "Oboy!" I said and waited for gcc to spit out the .exe. Instead of that, it whined that it couldn't find pkg-config files for qtgui and qtopengl and started dumping tons of linkage errors to the console.

D'OH!

So I briefly read what the hell's pkg-config and why I should care () I set about making my own .pc files and putting them where the tool can find them. But still no dice. It should be my path settings.

I don't think I have more patience for tonight and I thought I'd share some of my findings with other people so maybe someone could help with this. And of course Shamus is always welcome to step up and give some help / fix some of the broken stuff I described above. Also note that C was never my language of choice, so what I usually apply is common sense, lots of patience, and a tremendous amount of hacks .

[Shamus]

Thanks for looking at this. Most of the problems that you had to work around will most likely go away soon, as I think I got the qmake/.pro file building the whole thing.

Some random thoughts: The sdlemu opengl stuff should go away as the OpenGL dependency is on Qt now. I'm probably going to make the core into a library and rip out all of the stuff that doesn't belong in there that you had to work around.

There is no rule to make the icon ($&#$! OS dependent crap) but the icon file object should have been laying somewhere where the linker could find it (yup, in res/, called vj-ico.o).

Really have no idea why Qt is barfing pkg-config files, it should create them itself and install them, but it's been a while since I've played in that yard.

TL;DR: The build mechanism should be getting better very soon. Will post once I make the commit to SVN.

[Shamus]

Ok, hopefully r345 will make the build system a bit better for you awesome people. Let me know how it goes for you.

EDIT: Make sure you do a "make clean" after "svn up" to ensure no dirty objects are left over to muck things up.

Edited by Shamus, Sat Jun 25, 2011 9:13 PM.

[goldenegg]

Shamus, on Sat Jun 25, 2011 9:04 PM, said:

Ok, hopefully r345 will make the build system a bit better for you awesome people. Let me know how it goes for you.

EDIT: Make sure you do a "make clean" after "svn up" to ensure no dirty objects are left over to muck things up.

I don't think QMAKE is working on MacOS as you're expecting. The result of running 'qmake virtualjaguar.pro' is the creation of 'virtualjaguar.xcodeproj'. I opened it in Xcode, but it refuses to compile (doesn't understand -fcflags option). Even the resulting 'makefile-qt' is output as a Xcode project.

Using the previous make file doesn't work either, as it appears to be missing a rule to compile 'sdlemu_config.o'.

make: *** No rule to make target `obj/sdlemu_config.o', needed by `virtualjaguar'.  Stop.

So as it currently stands, r345 won't compile on MacOS.

[Shamus]

What happens if you do

qmake -makefile virtualjaguar.pro

or

qmake -spec macx-g++ virtualjaguar.pro

?

If the 2nd one works, then you can do a

make -f musashi.mak

and then make with the Qt generated makefile and that should then work. I hope.

Edited by Shamus, Sat Jun 25, 2011 9:53 PM.

[goldenegg]

Shamus, on Sat Jun 25, 2011 9:47 PM, said:

What happens if you do

qmake -makefile virtualjaguar.pro

?

Ugh, I'm going to have to slog thru the qmake documentation to figure out why it won't make a makefile on Mac.

Same result. It creates an uncompilable Xcode project file.

In regards to the compile fail with the old make file, was there a change in src/objectp.cpp which would cause a problem? It's during that compile when the error occurs regarding obj/sdlemu_config.o.

[Shamus]

Look above: Post was edited.

[goldenegg]

A little more on QMAKE.

I unpacked the Xcode project that was created and found two make files: qt_preprocess.mak and qt_makeqmake.mak. Trying to use the preprocess file results in the following.

goldenegg$ sudo make -f qt_preprocess.mak 
Password:
/Developer/Tools/Qt/moc -D__GCCUNIX__ -D_OSX_ -D__GCCUNIX__ -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/Qt4.7/mkspecs/macx-xcode -I. -I/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/usr/include/QtCore -I/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/usr/include/QtGui -I/Library/Frameworks/QtOpenGL.framework/Versions/4/Headers -I/usr/include/QtOpenGL -I/usr/include -Isrc -Isrc/gui -I/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers -I/System/Library/Frameworks/AGL.framework/Headers -Iobj -I/usr/local/include -I/System/Library/Frameworks/CarbonCore.framework/Headers -F/Library/Frameworks -D__APPLE__ -D__GNUC__ src/gui/about.h -o obj/moc_about.cpp
moc: Cannot create obj/moc_about.cpp
make: *** [obj/moc_about.cpp] Error 1
[code]

Trying to use the other does pretty much nothing.

[code]
goldenegg$ make -f qt_makeqmake.mak 
make: `virtualjaguar.xcodeproj/project.pbxproj' is up to date.

I've attached both make files to this post if you want to see them.

Attached Files

•  makefiles.zip   2.01K   16 downloads

[Shamus]

Look at post #60.

[goldenegg]

Shamus, on Sat Jun 25, 2011 9:47 PM, said:

qmake -spec macx-g++ virtualjaguar.pro

?

If the 2nd one works, then you can do a

make -f musashi.mak

and then make with the Qt generated makefile and that should then work. I hope.

That worked! Compiled flawlessly!!

Still won't load my BIOS though I'm shutting down for the night. Thanks for all your hard work on getting this running!!

[Shamus]

The bad news is that I can't put that into the .pro file and have it work in a cross-platform way; as a matter of fact, the QMAKESPEC variable is completely ignored inside of a .pro file which has to be one of the most boneheaded moves ever made by the Qt guys.

So it seems like I have to put OSX detection back into the makefile. Either that, or tell ppl building on OSX to configure that var on their system by hand. Way to go, Qt.

I mean, it would be as simple as doing

qmake -set QMAKESPEC macx-g++

once and then the regular makefile should work just fine. But still, bonehead move.

Edited by Shamus, Sat Jun 25, 2011 10:19 PM.

[goldenegg]

One last thing I forgot to mention. The compile still has problems with endian.h and byteswap.h. I have to manually edit memory.h and put the path to those files. Not sure how you want to handle that moving forward, especially since MacOS doesn't have byteswap.h.

[Shamus]

I commented it out, since it's not used ATM and I'm going to have to find some way that's truly cross-platform, or use platform specific hacks.

And so, on to r346.

[ggn]

Yawn (just woke up)...


Right, so I deleted all traces of previous builds from my build pc and got a fresh checkout for it to try.

• Firstly, it barfed again on glwidget.cpp on those opengl #define stuff. I fixed this by including <GL/glext.h> because gl.h says that those defines are there when on windows.
  
• After that it whined about usleep() on mainwin.cpp. I forgot to mention this, but it happened yesterday and I got round this by including <unistd.h> (don't ask me, I just had total commander search all the mingw include folder for "usleep" )
  
• Then there was a minor zlib problem that was due to my setup - fixed.
  
• And then came linkage time again...
  

  Quote

  g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -mthreads -Wl -Wl,-subsystem,windows -o debug/virtualjaguar.exe object_script.virtualjaguar.Debug -L'c:/msys/1.0/home/Administrator/vjdeps/Qt/lib' -lglu32 -lopengl32 -lgdi32 -luser32 -lmingw32 -lqtmaind `sdl-config --libs` -lz -Lobj -lmusashi -lQtOpenGLd4 -lQtGuid4 -lQtCored4
  c:/msys/1.0/home/Administrator/vjdeps/Qt/lib/libqtmaind.a(qtmain_win.o): In function `WinMain@16':
  C:\\iwmake\\build_mingw_opensource\\src\\winmain/qtmain_win.cpp:93: undefined reference to `_Unwind_Resume'
  C:\\iwmake\\build_mingw_opensource\\src\\winmain/qtmain_win.cpp:131: undefined reference to `qMain(int, char**)'
  C:\\iwmake\\build_mingw_opensource\\src\\winmain/qtmain_win.cpp:135: undefined reference to `_Unwind_Resume'
  c:/msys/1.0/home/Administrator/vjdeps/Qt/lib/libqtmaind.a(qtmain_win.o):C:\\iwmake\\build_mingw_opensource\\src\\winmain/../../include/QtCore/../../src/corelib/tools/qvector.h:484: undefined reference to `_Unwind_Resume'
  c:/msys/1.0/home/Administrator/vjdeps/Qt/lib/libqtmaind.a(qtmain_win.o):C:\\iwmake\\build_mingw_opensource\\src\\winmain/../../include/QtCore/../../src/corelib/tools/qvector.h:485: undefined reference to `_Unwind_Resume'
  c:/msys/1.0/home/Administrator/vjdeps/Qt/lib/libqtmaind.a(qtmain_win.o):qtmain_win.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
  collect2: ld returned 1 exit status
  make[2]: *** [debug/virtualjaguar.exe] Error 1
  make[2]: Leaving directory `/home/Administrator/vj'
  make[1]: *** [debug] Error 2
  make[1]: Leaving directory `/home/Administrator/vj'
  make: *** [virtualjaguar] Error 2
  

Ideas? I'm using latest qt, if I didn't state this before...

Edited by ggn, Sun Jun 26, 2011 12:44 AM.

[SubQMod]

Shamus, on Fri Jun 24, 2011 9:32 PM, said:

JagChris, on Fri Jun 24, 2011 9:26 PM, said:

lol ok sorry havent heard much about VJ at all really. And the almost simultaneous announcements of two Jag emulators both hitting version 2.0 status confused me.

Yeah, I thought I kinda funny myself, seeing how I had the 2.0.0 designation set upon almost a year ago.

Jagulator was always going to step up to release 2.0.0 as the last release, a loooong time ago, was 1.5.1. Lots of changes since then so it made sense to go to v2.0.0. As you notice, subsequent releases are minor path releases to date, eg x.x.1.

Really cool that both VJ and Jagulator are live and active together. Anyone know the status of Project Tempest???

[Shamus]

@ggn: Good morning! Ok, I've got a few things to fix in the source, but it looks like you're almost there! You might look at:

http://www.qtcentre...._personality_v0
http://www.zen-works..._unwind_resume/

@SubQMod: I figured there was a likely explanation for that. Don't know whatever happened to Mr. Linde, seems like he's dropped off the face of the earth. BTW, have you had any success building VJ?

[Putty]

Ive actually been keeping close track for a couple of months now on the status of jaguar emulation.

The only project that seemed somewhat alive was vj. I noticed shamus replying to forum posts but never saw updates on the svn. Hence i asked about it.

About pt: nothing seems to behappening there. I dont know the author. Its just what i know from searching.

Mess jaguar support is supposedly quite ok. I have not been able to run more than the bios rom though. Bios rom did have sound. Apart from global commits to sync mess with mame there have been no targetted commits to the jaguar driver for a long time.

I must say though i was surprized and amused jagulator got pulled out of the fridge. I beleive your last statement about it over 10 years ago was that you would be back to finish it eventually.

My hopes are up for some friendly competition/cooperation. Maybe someone will even update mess with the information found when both jagulator and virtual jaguar are improved.

[goldenegg]

Shamus, on Sat Jun 25, 2011 10:44 PM, said:

And so, on to r346.

r346 compiled using the 3 step process. When you want me to test another method for the compile, let me know.

BTW, thank you for fixing the build to make a proper .APP file for MacOS!! Now VJ can be run from Finder and all relative paths works based off its directory!

Let me know when you feel comfortable enough with the state of VJ and I can start providing Mac builds for people to use. I think we should track down the BIOS issue first though, since a lot of games don't seem to work without it.

EDIT:

I've attached the output of make from the r346. Didn't know if you might want to look at the various warnings and such thrown during the compile, to make sure nothing unexpected is messing up.

Attached Files

•  r346 compile.txt   68.06K   23 downloads

[ggn]

Well, after I educated myself over dw2 vs sjlj, downloaded the mingw package from nokia's official site, installed it on a different dir, added the required header files (only zlib tbh), and put an #undef main at each source file <sdl.h> is included, I got this:

Attached Thumbnails

• 

Edited by ggn, Sun Jun 26, 2011 9:38 AM.

[ggn]

What I wanted to ask is: "Is that normal?"