Attempts to build m68k mpeg-dec



Welcome, Guest \| Home \| Search \| Login \| Register


Author	Attempts to build m68k mpeg-dec (Read 159584 times)
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #15 on: September 10, 2025, 16:28 So the kinds of things Sidd does is coming from the opposite direction than I usually do. It is reverse engineering the already built binaries, and hacking and modifying them. This is usually to "de-protect" them, or remove or disable licenses or restrictions on running. Extremely necessary as there are countless products now abandoned, that require getting license codes, or registering with sites that no longer exist. This requires a lot of programming knowledge also, but tends to be lower level, and requires heavy use of things like resedit and hex editors. It can be, and almost always is, done for apps that we don't have the source code for. For this knowing assembly language for different cpus is key, or, more specifically, "machine language", ie the raw assembled assembly language that actually runs on the cpu. Knowing your way around disassemblers and debuggers are a necessity. Things rarely, if ever, get up to higher level languages like C. This is because, despite what you may have heard, there are yet to be ANY really good workable "decompilers". When you hear about "decompiling", they usually really mean disassembly. I can do a bit of this, and have for 68k and even more ancient processors like the 6502 and z80 (but I can't "read" powerpc machine code). Sidd, though, is in a class of his own! Sometimes you will find there is code in a built app that is there, but not active or accessible, or doesn't work, and you can activate it or fix it, etc. So that could be done with the mpeg-dec binaries we have on MG, but is the opposite of what I've been trying. (Which is building a new binary). But there is only so much you can do with this approach. You usually can't add new code or functionality. (This IS possible, but requires linking it in, and getting the old code to call it in many different hard to find places, so is extremely difficult). ---- My next step is concentrating on the code in the "mac" folder, and letting whatever is there override and only using the parts in the "lib" folder that are absolutely necessary (and ignoring the Makefile that is there, ie I won't be building the lib itself, but just using the parts that it really needs).
Last Edit: September 10, 2025, 16:32 by lauland
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #16 on: September 11, 2025, 19:59 Got it: it's two very separate approaches to solution mostly different things! Sidd and the whole software-fixing gang have really blown me away with some of the crazy-cool things they've pulled off with their decompilers, making me think they can do almost anything, so I thought there might be some Scooby Doo clues hidden beneath approaching the code from the angle they use to maybe discover things like what languages were used to code

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #17 on: September 11, 2025, 23:00 No, actually you're not wrong at all...so I took a look at the binary from MG in ResEdit and found a few interesting things immediately: 1. Found the string "Metrowerks, Inc" so I know they did INDEED use CodeWarrior. (How did they assemble the .a files?!?) 2. Found a "cfrg" resource and that the binary is FAT! So, they DEFINITELY built a version not using m68k assembly language at all! 3. Realized the source was missing something key: The resources! There is no .r file, nor a supplied file of resources. (This is easily gotten around, as I can just copy them from the MG binary). So, thanks for reminding me! Rooby-rooby-roooooo!
Last Edit: September 11, 2025, 23:03 by lauland
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #18 on: September 12, 2025, 06:30 Sweet! That's exactly what I hoped for, Lauland! just small clues that can shortcut though all kinds of variables to give you a clear path to know what you need to move further forward. I'm a power user in the sense that I can visualize strategies to get something done, even if I have absolutely no clue how some thing are done; those I just try winging it. Case in point, kinda? — well, it's more of just a recent, real cool story of a roadtrip I just did — I drove 22 hours across four state lines to drop off a spare car to someone I know who desperately needs it for college now that she moved cities. I had it checked out and worked on at a car shop of friends of mine, but the engine light turned on an hour and a half before reaching my final destination, otherwise I would have gotten there an hour and a half earlier. I used the car's built-in service communication system to make a call to eventually find out what the issue code was, then called my mechanic friend and he recommended going to a dealership to get it checked out, which I already figured I'd do first. Then I rerouted my trip to avoid freeways rather than have the engine rev down on the freeway. I'm a praying man so I took a leap of faith and just got to my hotel and parked for the night. The next morning I drove to the nearest dealership and I was assisted by my stepsister's cousin who had just moved to the city I was in, which was the most random and unexpected event in the whole trip, but like I said, I'm a praying man. She told me of a recall on the vehicle, so I gave the okay to work on it too. I'd given myself time to fly back so I figured it would be at least checked within three days before my Sunday flight; sadly it wasn't. I figured to then try to find a mechanic to work on the vehicle instead on that Saturday afternoon, but the car refused to budge out of the parking lot, so I had them keep the car instead. I flew back the next day and a few days later they fixed the issue; it turns out it was the recall issue, so it was a completely free fix! I had played every hand I knew to play the best I could and just left the rest in better hands. The car was then picked up and it couldn't have worked out better than the way it all went down, especially since dealerships do perform meticulous vehicle inspections, and what do know? I even had a relative I didn't know was working there! Some things simply require leaps of faith when you've reached your capacity, but generally we try to determine the best course of action in every step. The real godsend there was that I was unable to take the car to a mechanic who would have done a very costly repair in the tune of thousands of dollars. Not all my adventures end that gracefully, nor pocketbook painlessly, but I was very grateful for how everything worked out in the end — and I hear the car's running great! I feel like some of my Mac adventures are nearly as crazy of a rollercoaster rides as that roadtrip: I have no clue just how things will turn out sometimes, but I just give it my best shot and trust the rest to those far more capable than I, and that often includes my friends right here!

Cashed 128 MB Posts: 192 System 7 Newcomer!	Reply #19 on: September 12, 2025, 17:37 @lauland cool! I’ve seen the magic folks do with Ghidra and IDA Pro for debugging and reverse engineering. @cballero Wow! I luv what seems apparent coincidences -I get ya 100% Wild trip -you are a wild one! It never goes wrong when ones heart and values are intact Thank you so much for sharing that story with the rest of us my friend

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #20 on: September 12, 2025, 23:00 Hey, hope is a very valuable thing! Sometimes I 'll seemingly get some wild breakthrough, but the last thing I ever do even if I don't is give up without a fight, even when the odds are stacked against me I've been rescued too, which is why I love having any small opportunity to pay things forward when I can; here too of course! I never count it a small thing when we try to rally around an issue and get really creative to solution some obscure thing or manage to lift some impossible technical hurdle! But that roadtrip was simply way too "what just happened right now?" that certainly was a one-in-a-million occurrence!

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #21 on: September 14, 2025, 04:20 @Cashed, yes Ghidra and IDA Pro are amazing! I don't have call to do much x86 reverse engineering, so downloaded and installed them (I believe?) but never actually tried them on anything. I think I tried loading a random executable into one of them just to see but never got past that point. I don't know if they have support for m68k and/or ppc, so not sure if would be useful for Mac hacking...will take fresh look, just in case one of them does... ---- Going to make fresh attempt at building. Will use cw6, and ignore "mpegdec_lib", at least at first, and start with "mac". Will only use what is in the lib folder that is absolutely necessary. To get around the problem of, as far as I know, cw not being able to assembly "naked" assembly language files, will see if I can build a version that doesn't use them and just uses the C files. Since the MG binaries are fat, we KNOW this must be possible since the original author MUST have done so to build the PPC version. Another thing I was thinking was trying older versions of cw than cw6, which is my go-to for m68k. I ran into a bunch of tiny C dialect problems with cw6, and probably wouldn't if I used an older version. (ie highly likely original author used older version). I've got disk images for sheepshaver and basilisk with cw1 and cw5 already installed that I needed for other projects. FYI I needed cw1 to build an ancient version of Mesa, which is a software rendering only version of OpenGL. This was to look into the possibility of adding OpenGL support for m68k SDL 1.2. My conclusion: Probably could be done but any real games would run like a snail, even on Basilisk on a fast host, so not worth the time to do it.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #22 on: September 15, 2025, 16:06 So tried cw5 and it was no better, and cw1 was far worse, so it is still a big mystery which compiler the original author used. But did make progress working "backwards" using, for now, JUST the "mac" folder. I've at least solved which parts it overrides in the "lib" folder. So going to continue that way, adding only the parts from "lib" that are absolutely necessary. I mentioned I needed to tweak the C files before, and still did this time, and part of me is now wondering if I have the age of the code wrong. There's a lot in there that just doesn't compile out of the box in CodeWarrior without fixing it, which is very strange, as looking at the binary in ResEdit, I can see they did use it. It's very possible the source we have is not directly related to the binary. It might be incomplete, from an earlier (or later?!?) version, or it might be different pieces of different versions. Here are the specific issues: * In getargs.c it uses K&R (pre-ANSI) C syntax. This usually denotes VERY old code. MPW understands it, but CW doesn't. There's references to MPW in that file. * C++ style "//" comments are used throughout. CW doesn't allow this in C code, so you need to turn on the C++ compiler, although the source is all just C. This is usually seen in NEWER code. * There are parts of the decoder in "mac" that override what is in "lib", but they take (sometimes radically) different function parameters. This would seem to indicate one folder is newer than the other (ie changes didn't propigate). CodeWarrior doesn't allow this as it includes files from the "lib" folder so I needed to add func prototypes to use them. * I had to add a bunch of tiny type casts, like to the return value of malloc, otherwise CW doesn't like it. * There are "naked" assembly language files, which I've now verified CW doesn't support, nor do they assemble in MPW. All of the above made me kinda think maybe they used a NEWER version of CW that supported all the above. But that isn't possible because cw6 is the last version that supports m68k! So, the upshot is, you can't build it in CW out of the box without a LOT of teeny tiny fixes, but you can't build it in MPW either because it uses CW's SIOUX. And we know from the binary they used CW. So, we have to conclude we don't have the right source. The good news is the source is still useful, and (probably?) complete, so with a lot of elbow grease I can probably get SOMETHING building. But it probably won't match any of the binaries from MG. We'll see...

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #23 on: September 16, 2025, 03:55 Ok, mysteries FINALLY solved. The included sources ONLY include the decoder. They do NOT include the player itself. So no gui at all is included in the source that we have. I was able to build what sources we do have, using only the C files, and what results is just a decoder, and nothing else. It looks like it can read an mp3 and output a file either in raw audio, or in aiff formats. I'm going to upload it to the MG page, just for completeness, and for anyone else who might get the bright idea to follow this Quixotic quest. To save them the time. ---- So, if you guys want a PLAYER, we will need to find some other source. (And before you ask, converting an Amiga player that we have source for into a Mac app would take quite a lot of work, as you'd be creating the gui basically from scratch).

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #24 on: September 17, 2025, 18:31 Ah, wow and nice! That's a huge step in getting to the NeXT-step. Lauland! ..I just had to add Job's "NeXT" in there, lol So I imagine that the follow-up question would be if the goal is to build a few back-end things that tie to the front-end, then the big question there is if there are any other source code Mac audio software, at least in the PowerPC side, that ran as far back as Mac OS 8.1 or earlier? It doesn't necessarily have to be able to play MP3's, as I imagine that the MpegDec decoder can do that already: basically design a new PPC MP3 player with spare parts of two programs, then see if there's any chance of making it work on a 68k Mac. At least we know the decoder works fine on 68k Macs and emulators! Again, awesome work as always, Lauland!

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #25 on: September 17, 2025, 20:02 Personally, I have no further goals with this. I see myself as basically a hired hand (unpaid other than through thanks) . If somebody wants me to try building something from source (to possibly fix bugs, etc) and/or do a port, and its something my particular skill set is suited for, something the community wants and will hopefully use, or never existed (like m68k versions of things), I'm your guy. If you find source code for a different player, that might be interesting. If you find one, we can look at it. BTW, The code in the built binaries from MG are linked as a single segment, so unfortunately, it would be extremely difficult (near impossible) to pull just the front end out. You could disassemble the whole thing, and then recognize which parts do which, and modifications could be done that way (you'd re-assemble the disassembled code after modifying it). For some apps, especially older m68k ones, you'll see mutliple CODE segments (resources), sometimes even usefully named. In those cases, you could just work on the part you were interested in. PPC binaries tend to be one hunk of code (so as bad as a single m68k CODE segment), but sometimes have sub-libs, etc.
Last Edit: September 17, 2025, 20:04 by lauland
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #26 on: September 18, 2025, 01:10 I get it, it would have been a whole other story if the source code would have had the whole thing included but no worries, you uncovered so much already, and for that you have my utmost respect, appreciation and gratitude thanks, Lauland!

	Pages: 1 [2]

© 2021 System7Today.com.
The Apple Logo, Macintosh™, Mac OS™, and others property of Apple Computer, Inc.
This site is in no way affiliated with Apple Computer, Inc.