Idle hands in search of new programming project...



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


Author	Idle hands in search of new programming project... (Read 198076 times)
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #30 on: September 03, 2025, 05:09 Thanks Lauland for inspiring us to go beyond our comfort zones with these programming projects! Your programming skills truly are incredible and I still use Goliath almost daily to shuttle data between my Basilisk II Mac’s and my iPhone! I also use it along with the PPC Goliath as they both can run separately from each other on SheepShaver (or any other PowerPC Mac for that matter!) I do use MpegDec daily as well, so this would be a huge bonus to finally be able to update this tiny audio marvel, just show me what we’d need to do!

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #31 on: September 03, 2025, 20:57 @wove Re: "Networking guide/utility". I'd say a first step would be to draw a mock up of what you're thinking it would look like. Even just static screens. I think I get what you're talking about, but pictures would make it clearer for anyone interested in contributing. @cballero: I've downloaded the source code for mpegdec and am taking a look for it. It looks a bit odd, and its not clear which compiler/assembler they used (or what will work). Will see if I can figure out how to build a working copy from it. It looks like they were last interested in porting to the Motorola ColdFire, which is not Mac related. (It can be thought of as a "cut down" or "embedded" m68k processor).

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #32 on: September 03, 2025, 23:53 Oh, really? Wow that's cool! it was a port of Stephane Tavenard's MP3 decoder library, MPEGA for the Amiga MP3 player, AmigaAmp! MpegDec was made to be super fast on the slowest Macs per its website; and the original programmer/porter, Mark White, dropped from radar, but the webmaster, John Gilbert, can be emailed at john@jwgdesign.com; he's also dropped by the MG app page to comment on some things, and I'm pretty sure he designed the MpegDec icons. From his website: Quote from: the MpegDec website MpegDec uses 68k assembly language optimizations and is the fastest MP3 decoder for 68k CPUs. It supports playback and conversion of MP3, MP2, and MP1 files. On PowerPC Macs, it offers a graphic equalizer. It requires 68020, System 7.1, drag and drop and QuickTime 2.1, ideally QT 2.5+. The equalizer might be made to work on 68k Macs, I tried it in SheepShaver and it works well

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #33 on: September 04, 2025, 18:38 If I actually get it building, I'll start a separate thread, but it looks like it will trickier than usual. There's three parts in the source: "mac": This seems to include the source code for the Mac UI, but there are no Makefiles, or project files. My guess is they used MPW, as grep'ing for mpw shows a lot of references, but only in getargs.c. I'm guessing I can create a Makefile, or just build each .c by hand...but might try building it in CodeWarrior. The problem will be the .a assembly language source files, as assembly language is very non-standardized, even for the same chip (m68k in this instance)...but I'm guessing CodeWarrior will understand MPW assembly? "mpegdec_lib": This has a Makefile that looks like it is for x86 or ColdFire, and there are separate included Amiga SAS/C makefiles, but nothing for Mac. This is the actual decoder library, which "mac" above uses...at least that's my guess. "mpegdec_demo": This is probably a command line player that uses the above lib, and has a Makefile for linux, again x86 and ColdFire only. ---- So I'll first try building the stuff in "mac". If I can get it going, I guess I'll need to build what is in "_lib" also and link them together. I'll try CodeWarrior first, since it is loads more user friendly than MPW. This illustrates a point I've brought up before...even if you have the source code, you almost always need to use the same tools the original author used, and sometimes even the exact same versions. Just having the source code and turning that into a running Application can be quite tricky! Projects that use any assembly are especially difficult.
Last Edit: September 04, 2025, 18:40 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #34 on: September 04, 2025, 19:55 Was able to get all the C parts building in CodeWarrior, after fixing various problems because the C is so old, but, as I guessed, the assembly language bits are the problem. There are some needed functions that are only in assembly, it seems. Attempted to use MPW Asm command to build MPEGSUBB.a and output doesn't contain any actual binary code. Tried passing -l and -p to Asm, and output still doesn't contain anything. This means it is likely the .a files are NOT meant for the MPW assembler, but may be for the ColdFire one. Tried to use mpegsubb.S which looks like an alternate version of MPEGSUBB.a, but with major parts of it #if'd out?!? It gave invalid opcode error, making it also likely ColdFire. In other words, the source code may not actually include everything needed to build on mac. There may be a missing Mac assembly language file, in addition to there being no Makefiles.

Cashed 128 MB Posts: 192 System 7 Newcomer!	Reply #35 on: September 21, 2025, 23:51 Lots of great ideas were posted I didn’t want to throw in an idea I had -but I will if you are sure you are done with MpegDec. I can PM you the contact info of the developer if you want? Bet he’d luv to have someone reach out to him

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #36 on: September 22, 2025, 02:55 Dang Cashed, were you reading my mind!?! I'm relatively idle again and actually was just about to post "Ok, any ideas for a new project?" here! I'm not strictly done with mpeg-dec as a PROJECT, but did take what source code we have as far as it can go. If we need to reverse engineering the binaries, I'm probably not your guy. I don't see any harm in contacting the developer, but let's do it as a group, not as in "have lauland bother them to get more source, etc". ie, if YOU have the contact info already, why not contact them yourself? Especially since I've lost track of what you were interested in doing further with it. :p For me, it was strictly "Build the source code and then see what we have then." Let them know what you have in mind and that we are willing (and able) to take it further if they'd release the source. ---- I've been playing around with AROS a lot recently, trying to get it working on my Rasp PI, but it is currently broken on ARM cpus. I've had some thoughts about the possibilities of getting it running native on Mac hardware, but it doesn't run great even on '040 amigas, its just "too modern" and has relatively high requirements. It would run decently on PPC's, but m68k is dear to my heart. I have some ideas, but don't know if there's enough interest and/or the result would be worth the trouble of working on it. ---- With that said, I thought about what m68k stuff I've been meaning to look into but haven't yet. Two are the TI 89 calculator and the Sega Genesis. I might write a simple game for one of them. I've already done "Hello World" on the Genesis so have the toolchain ready. I installed the TI one, but have yet to do "Hello World". The Genesis would be easier and definitely would get prettier results, but console dev is a serious pain compared to computers. (They don't have bitmap'd displays strictly speaking, so can't run something like SDL). Speaking of calculators, there's also the TI 84 plus ce, which has an interesting processor. It is a 24-bit (not 32 bit!) extended version of the z80, and has lots of memory and is relatively speedy. I've been unable to track down a C compiler for it, so one project might be trying to extend a z80 compiler... I've also got a TI N-Spire (I'm a math geek), but coding for it isn't terribly interesting, as its an ARM cpu, and TI has protection from running 3rd party code...but people have gotten past that and already write stuff for it, but I'd have to jailbreak mine. I probably should get around to trying NetBSD on my quadra. The m68k version of MachTen would also run well on it too, and very few people have looked into it, an untapped classic I believe. ---- Other than the above, let me know if anyone has any ideas of what I might work on next. As before, I'd really love a group project, but know not everyone has (or at least think they have) coding knowledge. If there's source code for something, I'm pretty good at looking at it, and doing an m68k port of something is right up my alley. Or even judging that something wouldn't run well on real hardware without a hypothetical 3d accelerated video card. You get the idea.
Last Edit: September 22, 2025, 03:00 by lauland
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #37 on: September 22, 2025, 18:17 Lauland: again, thanks so much for the monumental lifting you did with MpegDec; too bad its source code was incomplete Besides my desire for a Classic ePub viewer, I've always been a huge fan of NES emulators on my Classic Macs and found one with source code called MacMESS! It plays perfectly on Mac OS 8.1; I did have to figure out that pressing the number one twice starts a game! this program would be really super nice to have a compatible version for 68k Macs! unfortunately, iNES never made the cut for me as it was never smooth on neither my PCC or 68k Macs, except possibly my G4 Macs!

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #38 on: September 22, 2025, 18:56 Hmm...will take a look at MacMess, and see about possible m68k version. They claim to have used cw5 pro to build it. With the caveat that even if I do get it building, it may not run well, ie be quite slow. As with mpeg-dec, if it looks even vaguely possible I'll start a separate thread to describe how it goes, assuming I have anything interesting to report about it. Otherwise, I'll note here why it isn't.

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #39 on: September 22, 2025, 19:12 That's awesome, Lauland! That might actually explain why iNES was never quite perky enough, but you never know! I'm still beside myself with the 68k Goliath and how incredibly useful it turned out; that was truly a next-level production-release! It just works so, so well, and it's all thanks to you my friend! so far, there's no trace of any ePub source code remotely close enough to warrant offering, but I'm happy with the ePub to Word solution I cobbled together to satisfy my e-reader needs

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #40 on: September 23, 2025, 02:12 So, there are two archives that say they have source on MG. I'm just going to look at those for now, if I can't build SOMETHING from them, I'll look further. Unlike the mpeg-dec situation, we KNOW there source for various versions of Mess out there! One archive seems to be just stock Mess, and the other is the Mac parts. Building a PPC binary is the first step, hopefully one that matches the binary on MG. (Have to make sure I can do that before I can even think about an m68k one!) It says it needs zlib, which is not included, but there is a URL in the readme, hopefully it will still work. It also needs Universal Headers 3.3, and includes an Apple URL which will obviously NOT work (it is far too old and apple far too zealous in deleting things), but luckily I can get them from other places. Unfortunately the first step in the "how to build" readme says "Build a working MacMame"...once you've done that, it explains how to take the folders from the two archives and put them in the right places in the Mame build folder. If I have ANY hope of using these sources, it means I will need to build the EXACT same version of Mame they used...because MacMess is basically a patch on top of Mess, and Mess is basically a patch on top of Mame. So, off to search for the source for MacMame 0.37b10! ---- Right off the bat, the archives are incomplete, and there's three other parts I'm going to need to find, two will be relatively easy...but the MacMame one may or may not be difficult, esp since MG doesn't have that version (let alone the source for it). I'm going to look now, but in case there's anyone out there reading this, you could help look also. If we can't find the right version, and it can't JUST be Mame, but must be MacMame, we won't be able to use these sources the way they were intended. If we can't do that, we can think about finding another version of MacMess sources...or...we could attempt some sort of Frankenstein idea with using these with some other version it was not intended for. If it gets to that point we'll have to consider "diminishing returns" and do a cost benefit analysis. We already know this will likely not run "great" on m68k, just because it is a very complicated emulator, meant for far faster cpus...so how much work is it worth doing, etc etc? You get the point. Don't want to threaten rain so early on the parade, but being realistic.
Last Edit: September 23, 2025, 02:14 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #41 on: September 23, 2025, 19:36 Found all the necessary pieces and put them together, and have been able to build the PPC version of MacMESS. Uploaded my build folder to MG, to save anyone in the future who might want to try the same thing. Converted all the projects to m68k, with 4 byte ints and "smart" segment model. But then immediately found a LOT of powerpc assembly: Time functions. Blitting. "Asgard" cpu cores. I put "#ifdef"s around all this to get past them. So I was able to compile everything, but can't link due to missing functions. Whether we can find C versions or not is a question...if so, they will be quite a bit slower. I'm going to hunt for C versions, and stub out what I can't (leaving empty "TODO" functions in their place). End result should be something that starts, but can't emulate or draw...but will be SOMETHING, even if its just a place for someone in the future to possibly continue. A good place to look for something to replace the powerpc assembly is if there is an m68k Amiga version of Mess. If there is, there may even be m68k assembly functions we could steal...er...borrow...

Cashed 128 MB Posts: 192 System 7 Newcomer!	Reply #42 on: September 23, 2025, 21:55 Old MESS versions -source

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #43 on: September 23, 2025, 22:22 Awesome forum thread find, Cashed! I dug up just a couple of AMIGA-related links too: https://github.com/krabobmkd/amigamame Thread (modern link) on AMIGA-MAME emulation port that may help! On it, I did find this link (modern link) to some AMIGA source code! It had links to (modern) AMIGA OS4 GUI+2nd link but was incompatible This next site has an older AMIGA MAME ver. but didn't see any source? Lastly, a (modern) OS4 AMIGA compiled version of MAME
Last Edit: September 23, 2025, 23:19 by cballero
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #44 on: September 23, 2025, 22:31 Ok, the timebase stuff I can work around. I've done that for other m68k ports. The cpu cores, there are definitely C versions, I'd just need to adjust the projects to use them. Will definitely look at the amiga sources in case they HAPPEN to have m68k assembly cpu cores, cross fingers. The blitter don't know about yet. I'm not sure how complex it is. In the simple case it is just copying blocks of pixels. Some of them will try and be smart about different "numbers of colors" aka screen depth. It was more code than I expected, but I think because it is highly optimized. Absolute worse case I can just use QuickDraw. It really is an amazing piece of software. I could also write a faster but dumber one in C if that isn't fast enough. I didn't mention it before, but there were some code fragment manager calls I worked around. So will take some more work, which I'll do tonight... Thank you guys loads, as always, for the useful links!

	Pages: 1 2 [3] 4

© 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.