Shamus Posted June 30, 2011 Author Share Posted June 30, 2011 (edited) BTW, put this zip into your "software" directory to get an idea of what's possible. Much more is possible. BEEBRIS_rom.zip Edited June 30, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
ggn Posted June 30, 2011 Share Posted June 30, 2011 Well, other than "people won't be arsed to pad their ROM collections (or won't know how to)", I can't see any reason why not to do it P.S. Damn, I just turned off my noisy compiling PC, I'll take a whack at building 352 for Windows tomorrow P.P.S. Shamus, I have managed to compile libcdio (sledgehammer approach FTW), so if your concern is whether it is supported on other platforms, it should be ok on windows Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 30, 2011 Share Posted June 30, 2011 @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. Maybe I didn't explain myself properly. Currently, the VJ makefile does the following. qmake virtualjaguar.pro -o makefile-qt The result of this is to create 'makefile-qt.xcodeproj', which we didn't know what to do with. If we use the method as presented in the makefile I provided, maybe the created Xcode project files can actually be used. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 30, 2011 Author Share Posted June 30, 2011 That's what I'm sayin': it's using xcodebuild to build those qmake made makefiles. Mac only. What I'm going to do is just put a check in the Makefile for MacOS and add a "-spec macx-g++" var to the qmake command line; that should fix the problem. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 30, 2011 Share Posted June 30, 2011 That's what I'm sayin': it's using xcodebuild to build those qmake made makefiles. Mac only. What I'm going to do is just put a check in the Makefile for MacOS and add a "-spec macx-g++" var to the qmake command line; that should fix the problem. Ahhh, so you wanted to avoid having a different compile path for different operating systems? I was thinking you could just use the Xcode method for Mac systems. The QMC2 source is cross-platform, so i figured it might give an idea on how to handle compiling across the different platforms. Adding "-spec macx-g++" will also address the issue, as well as changing to use static SDL libraries. R352 MACOS BINARY HERE!!!! virtualjaguar-macOS-r352.zip Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 30, 2011 Author Share Posted June 30, 2011 Changes are in, please test. Nothing new functionality-wise, just changes to the build system. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 30, 2011 Share Posted June 30, 2011 Changes are in, please test. Nothing new functionality-wise, just changes to the build system. Fails near end of compile. 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 `sdl-config --static-libs` --libs` -framework QtOpenGL -framework QtGui -framework QtCore -framework OpenGL -framework AGL /bin/sh: -c: line 0: unexpected EOF while looking for matching ``' /bin/sh: -c: line 1: syntax error: unexpected end of file make[1]: *** [virtualjaguar.app/Contents/MacOS/virtualjaguar] Error 2 make: *** [virtualjaguar] Error 2 There's an extra --libs' as part of the sdl-config call, causing this failure. Quote Link to comment Share on other sites More sharing options...
Shamus Posted July 1, 2011 Author Share Posted July 1, 2011 (edited) OK, one more time, r355. If it doesn't work on the first pass, try a 'make clean' before trying again. Edited July 1, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
goldenegg Posted July 1, 2011 Share Posted July 1, 2011 OK, one more time, r355. If it doesn't work on the first pass, try a 'make clean' before trying again. It's failing, because it's looking for jaguarcore.mak which doesn't exist. Quote Link to comment Share on other sites More sharing options...
Shamus Posted July 1, 2011 Author Share Posted July 1, 2011 (edited) r356 D'oh! Edited July 1, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
goldenegg Posted July 1, 2011 Share Posted July 1, 2011 r356 D'oh! It's still adding --libs` to makefile-qt, which results in an error near the end of the compile. EDIT: Just so you can see where the problem is LIBS = $(SUBLIBS) -F/Library/Frameworks -L/Library/Frameworks -lz -Lobj -lmusashi `sdl-config --static-libs` --libs` -framework QtOpenGL -framework QtGui -framework QtCore -framework OpenGL -framework AGL Look at where it references sdl-config Quote Link to comment Share on other sites More sharing options...
Shamus Posted July 1, 2011 Author Share Posted July 1, 2011 Look at the virtualjaguar.pro file. Near the top should be a "LIBS +=" variable. Is there a `sdl-config --libs` in that line? If so, then you should delete your virtualjaguar.pro file and update from svn again to pull a fresh copy. There is a second "LIBS +=" line down below, but those are enclosed in braces and not what I'm looking at here. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted July 1, 2011 Share Posted July 1, 2011 Look at the virtualjaguar.pro file. Near the top should be a "LIBS +=" variable. Is there a `sdl-config --libs` in that line? If so, then you should delete your virtualjaguar.pro file and update from svn again to pull a fresh copy. There is a second "LIBS +=" line down below, but those are enclosed in braces and not what I'm looking at here. I've been pulling clean copies from SVN instead of updating. Here's what's in my virtualjaguar.pro. LIBS += -lz -Lobj -ljaguarcore -lmusashi and further down we have macx { LIBS += `sdl-config --static-libs` } Quote Link to comment Share on other sites More sharing options...
ggn Posted July 1, 2011 Share Posted July 1, 2011 (edited) r356 Windows build is up (didn't have time to test it yet, and I have to go shopping now, so please test ) Edited July 1, 2011 by ggn Quote Link to comment Share on other sites More sharing options...
Shamus Posted July 1, 2011 Author Share Posted July 1, 2011 (edited) @goldenegg: What happens if you change macx { LIBS += `sdl-config --static-libs` } to macx { LIBS += $$quote(`sdl-config --static-libs`) } ? If that doesn't work, post your makefile-qt that it generates. Edited July 1, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
goldenegg Posted July 1, 2011 Share Posted July 1, 2011 @goldenegg: What happens if you change macx { LIBS += `sdl-config --static-libs` } to macx { LIBS += $$quote(`sdl-config --static-libs`) } ? If that doesn't work, post your makefile-qt that it generates. Now it's even more interesting LIBS = $(SUBLIBS) -F/Library/Frameworks -L/Library/Frameworks -lz -Lobj -ljaguarcore -lmusashi `sdl-config\ --static-libs` `sdl-config --libs` -framework QtOpenGL -framework QtGui -framework QtCore -framework OpenGL -framework AGL makefile-qt.zip Quote Link to comment Share on other sites More sharing options...
Ricardo99 Posted July 1, 2011 Share Posted July 1, 2011 P.P.S. Shamus, I have managed to compile libcdio (sledgehammer approach FTW), so if your concern is whether it is supported on other platforms, it should be ok on windows How the heck did you get libcdio to compile???? I tried everything, more to the point....how did you get libiconv to compile so you could try to compile libcdio?????? If I could have got those to compile I would have been compiling, or not and just helping Shamus find problems , VJ for a while. Thanks for the great work ggn and of course Shamus Ricardo Quote Link to comment Share on other sites More sharing options...
Shamus Posted July 1, 2011 Author Share Posted July 1, 2011 For some reason it's picking up macx AND unix. Very strange. In the meantime, r357. Quote Link to comment Share on other sites More sharing options...
ggn Posted July 1, 2011 Share Posted July 1, 2011 P.P.S. Shamus, I have managed to compile libcdio (sledgehammer approach FTW), so if your concern is whether it is supported on other platforms, it should be ok on windows How the heck did you get libcdio to compile???? I tried everything, more to the point....how did you get libiconv to compile so you could try to compile libcdio?????? If I could have got those to compile I would have been compiling, or not and just helping Shamus find problems , VJ for a while. Thanks for the great work ggn and of course Shamus Ricardo How did I get libcdio to compile? Well, doesn't ./configure && make && make install work for you??? No? Well, it didn't work for me either I didn't try to be orthological or provide a neat, clean, readable patch to the source in order for it to compile. Instead I threw crap at it till it compiled (there, I just gave you an insight how we make things work over at Reboot industries ). To be more precise (and I guess more useful ), I downloaded v0.82 of libcdio, hit ./configure && make, and waited till it exploded. (I know it would, as I have compiled it in the past, but I remember I had to do something to make it work). It decided to explode in rock.c and util.c where it just couldn't find reference to HAVE_S_ISSOCK and HAVE_S_ISLNK. I searched the source tree for them, and sure enough they were defined in cdio/rock.h. Including that file didn't seem to have any damn effect, although it should (it had nice #ifdefs and all). Next step was to copy/paste the definitions in the 2 .c files, #ifdefs included. But nnnooooooooooo! It still wouldn't compile! So, I applied the old sledgehammer approach: I just removed the #ifdefs. So, inside the 2 .c files there is now the following snippet of code: //#include <cdio/rock.h> //#if !defined(HAVE_S_ISSOCK) && !defined(S_ISSOCK) #define S_ISSOCK(st_mode) ((((st_mode)) & 0170000) == (0140000)) //#endif //#if !defined(HAVE_S_ISLNK) && !defined(S_ISLNK) #define S_ISLNK(st_mode) ((((st_mode)) & 0170000) == (0010000)) //#endif Miraculously enough, that seemed to do the trick . So a make install later, and everything was sorted . If you still can't make this work, I might be persuaded to archive up my whole msys/mingw folder and upload it somewhere, so you (and other people) will have an environment to compile vj for windows... Quote Link to comment Share on other sites More sharing options...
goldenegg Posted July 1, 2011 Share Posted July 1, 2011 For some reason it's picking up macx AND unix. Very strange. In the meantime, r357. r357 compiled perfectly ... and seems to work Quote Link to comment Share on other sites More sharing options...
miker Posted July 1, 2011 Share Posted July 1, 2011 Shamus - check your PM, please. Quote Link to comment Share on other sites More sharing options...
Shamus Posted July 2, 2011 Author Share Posted July 2, 2011 @ggn: I know this is going above and beyond the call of duty, but would you mind telling the libcdio guys about your troubles building on win32? If their goal really *is* to be cross-platform, I'm sure they'd like to know about your problems in getting it to build. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted July 2, 2011 Share Posted July 2, 2011 Just tried 356 - Pretty cool, however the cart should be a skunkboard, not an alpine for Beebris I'd still like an option to load something to a given address (either rom, or ram) outside of the "Insert Cart" button, just to make testing easier (Load/Run address from user) Quote Link to comment Share on other sites More sharing options...
miker Posted July 2, 2011 Share Posted July 2, 2011 Seconded. And also finding rom by hitting its first letter as well as launching it by doubleclick also will come handy. Quote Link to comment Share on other sites More sharing options...
miker Posted July 2, 2011 Share Posted July 2, 2011 (edited) (double post) Edited July 2, 2011 by miker Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.