|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Jabbernaut for m68k new attempts (Read 64855 times) | ||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
Reply #15 on: April 26, 2024, 05:37
Got it running in SheepShaver. It was failing a SndNewChannel() call in ZSoundPlayer, for unknown reasons. Commenting out the FailNIL() call in SoundManager::Init() in SoundManager.cpp allows it to run. I'm going to look into why the SndNewChannel() call fails, it looks like it might be requiring stereo output and maybe SheepShaver doesn't support that? |
||||||||||||||||||||||||||||||||||||||||||||||
|
daptdore
|
4 MB Posts: 6 System 7 Newcomer!
Reply #16 on: April 26, 2024, 12:47
|
Quote from: lauland I'm going to look into why the SndNewChannel() call fails, it looks like it might be requiring stereo output and maybe SheepShaver doesn't support that? Apologies if this is too simplistic, but maybe you need to enable sound? https://www.emaculation.com/forum/viewtopic.php?t=11674
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #17 on: April 27, 2024, 05:43
|
No apologizes needed, you guessed correctly, my sound is not working! Unfortunately, I'm on a Mac. I can't remember where I got my SheepShaver from, but it came with /dev/dsp and /dev/mixer in its config for sound. Two devices that do not exist on a Mac! I need to read the SheepShaver manual to set things up proper, but I did notice something interesting...when I checked "Disable sound" and blanked out the wrong device names in the config, I now get a DIFFERENT error (-200) when launching Jabbernaut! So it still isn't running, but it is closer! ---- It turns out the original Jabbernaut author put FailNIL()'s around almost EVERYTHING that could possibly fail...ie return a NULL pointer...and that causes a fatal exit. This is a great idea when you're debugging and you KNOW, while you're testing, those pointers shouldn't ever be NULL. But in our case where we're dealing with funky code of unknown status, probably never even finished, it does more harm than good. NOTE: FailNIL() reports an "Out of memory" error regardless of what actually caused it. Which is obviously not the case with me. The trick is that Jabbernaut's SoundManager class actually already CHECKS if the ZSoundPlayer pointer is NULL, and just doesn't even try to play any sound if it is. So, the FailNIL() in this case is a really bad idea. Sound should obviously be optional, and since it already checks if it got it, it should just be fine...instead it refuses to start. I think removing the FailNIL() in SoundManager::Init() around the ZSoundPlayer creation is a really good idea because of the above.
Last Edit: April 27, 2024, 05:46 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #18 on: April 27, 2024, 05:52
|
garambo, Knezzen, I uploaded new .mcp files to the Hotline Jabbernaut "Uploads:Jabbernaut Upload" folder. The only change for the m68k and PPC is they include non-debug targets. Those use Prefix.h instead of DebugPrefix.h, but I haven't noticed much differences with the produced apps. Now we can test them. ---- I'm working on getting the Carbon version to compile, mostly adding some type casting to fix mismatches, etc. It originally linked with a Carbon version of GUSI which we don't have, so that's something we'll have to look for if we actually want to get it running. I may need to create Carbon versions of OpenSSL, since it is using CodeWarrior's MSL and Mac headers. It should at least use the Carbon versions of those. The author's Carbon project file just used the same OpenSSL as the normal PPC build, which I don't know is a good idea. Which brings me to wonder if MacJLIb would also need a Carbon version...probably...again, the original author just used the PPC one. But in my experience with Carbon, you should go all Carbon or none. Technically it is possible to link any PPC library in building a CFM (ie not Mach-O) Carbon app...but my feel is that isn't safe. (calling sizeof() on structs could be different at the very least).
Last Edit: April 27, 2024, 06:54 by lauland
|
Knezzen
|
Administrator 512 MB  Posts: 608 Village idiot
Reply #19 on: April 27, 2024, 10:39
|
Really nice! Downloading now 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #20 on: April 27, 2024, 23:24
|
Got the carbon version to fully compile...but not link...we need a carbon version of gusi...will find that... Changes were commenting out many parts of carbon printing...it looks like cw6 headers were from when carbon printing was still being developed like the author mentioned in comments a #warning in the code...needs newer Universal headers...will probably work on cw8 and I'll try that soon to verify... Also needed to fix typing on a few UPP's, which wasn't unexpected and very typical with Carbon. Not Carbon related: Removed the useless FailNIL around ZSoundPlayer creation, but still doesn't run in ShapeShifter...oh well...more investigating to come... Uploaded to hotline folder as "Jabbernaut-lauland-27042024.sit". Changes do not affect normal ppc or m68k builds so it's safe to just replace your build folder with mine, if you are so inclined.
Last Edit: April 27, 2024, 23:26 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #21 on: April 28, 2024, 06:07
|
Found Carbonized GUSI and was able to build Carbon version...need to test it...it (of course) doesn't run in my shapeshifter... Fixed TOQ project and it now builds...for what it's worth! When run it prompts for name and password with prefilled name. It probably will try and connect to server that no longer exists in Brasil...but the app is there if anyone can figure out a use for it. Created 68k version of TOQ just because it was easy to do while I was at it. FYI TOQ seems to put up window of XML output and then crash when you try and enter a password, after showing a couple "login" errors. ---- Added debug versions of carbon Jabbernaut, and TOQ for ppc and m68k, and replaced garambo's Jabbernaut_CW_Project.sit with mine at MG. (Use Jabbernaut_CW_Project.sit from MG going forward, instead of what is on Hotline, as that one is older).
Last Edit: April 28, 2024, 06:16 by lauland
|
garambo
|
16 MB Posts: 29 System 7 Newcomer!
Reply #22 on: April 30, 2024, 19:52
|
That's wonderful news @lauland, great stuff as usual! I'm just back from vacation and I might take a look at the Carbon version in the next few days. I took a look at the previous post and I think we should definitely investigate a bit more on the FailNIL() usage - on a general note, though, I would agree with the original author's idea of throwing an exception for null arguments, but I see what you mean with your observation: Quote But in our case where we're dealing with funky code of unknown status, probably never even finished, it does more harm than good. It would be interesting to maybe add a ZErrors.cpp implementation to retrieve additional debug information? Anyway, let me know if you need any specific help in the meantime, happy to contribute!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #23 on: April 30, 2024, 20:04
|
Maybe having something exactly like FailNIL(), but it returns a different error than "out of memory", I'm thinking. Then go through the code and use that instead in places where it is more a general failure... What I'd do in my own projects is have the error handler pass (or log) a string that described the error, so instead of it just putting up a numeric error, it'd say "unable to allocate sound channel" (etc). So, absolutely throw exceptions on NULLs...but only when they're fatal! Maybe just adding a non-fatal version of FailNIL() (if there isn't already one in Zoop), and deciding where to use it? ---- The next thing I have on my list is creating a CW8 version of the Carbon project and uncommenting the parts of the printing code that I had to comment out to get it building in CW6. They may compile as is, or may need some tweaking, since the code was written while the api was in flux. If you get bored, and can, you could try that, and beat me to it. I'd also love to get it building in XCode, so we could use its very nice debugger...would definitely make it easier for fixing ACTUAL bugs in Jabbernaut.
|
garambo
|
16 MB Posts: 29 System 7 Newcomer!
Reply #24 on: April 30, 2024, 20:10
|
Quote So, absolutely throw exceptions on NULLs...but only when they're fatal! Maybe just adding a non-fatal version of FailNIL() (if there isn't already one in Zoop), and deciding where to use it? Yes, exactly! Quote I'd also love to get it building in XCode, so we could use its very nice debugger...would definitely make it easier for fixing ACTUAL bugs in Jabbernaut. That would be great indeed, I might start looking into it
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #25 on: April 30, 2024, 20:17
|
The trick with building it in XCode will be dealing all the libraries which are dependencies. So we'd be dealing with not just building Jabbernaut itself, but OpenSSL, MacJLib, GUSI, and Zoop! I think building each dependency as separate libraries, maybe each with their own XCode project files, would be easier...to break it down to manageable portions. Each one will have their own challenges moving from CodeWarrior to XCode's gcc/llvm...lots and lots of little compiler issues...things that are legal in CodeWarrior but not in a "modern" compiler. Using classic MacOS resource files in XCode requires a little finesse, so creating .r versions of them would be a good idea. But if we got it building in XCode PPC...we could also try building an Intel version! (Only useful on older versions of MacOS X that support Carbon, tho). We'd have to be on the look out for endian differences. Definitely give it a try if you have time (although creating those projects will be a bit of a pain!), and we can toss what you get back and forth between us as we tweak it into something working. I think XCode used to include an option to import CodeWarrior projects...at least the really old ones did. That'd save a LOT of time...although the results would still need serious work...
Last Edit: April 30, 2024, 20:31 by lauland
|
garambo
|
16 MB Posts: 29 System 7 Newcomer!
Reply #26 on: May 01, 2024, 10:59
|
Thanks for all these great suggestions, @lauland! I will definitely give it a go in the next few days and keep you posted
|
|
Pages: 1 [2]
|
| ||||||||||||
|
© 2021 System7Today.com. |
