|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Idle hands in search of new programming project... (Read 198078 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
cballero
1024 MB  Posts: 1176 System 7, today and forever 
|
Reply #15 on: December 13, 2024, 20:58
Here's something about me: anything I ask for, I'll always use it  and as far as custom icons within Goliath, here is how my Goliath window looks like on my desktop! Was that what you were not seeing?  Let's just say I have been able to move things far more easily using Goliath and it makes doing it a breeze, especially with a desktop icon I can use to click and connect 
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #16 on: December 14, 2024, 11:03
|
@lauland I'd second @MTT's motion for us to work out color in Mini vMac: Mini vMac is the missing bridge between what earlier Mac models could run, and PowerPC Mac OS, all within the ecosystem of the original Mac OS. All System 1 ~ Mac OS 9.2.2 software, in black and white, OR color, from a natively-booted actual Mac OS system? Count me in! I mention it briefly on that Garden page, but I read somewhere from the original developer a comment that stated Color was simply not implemented for the Mac OS version of Mini vMac. So porting the relevant Mac OS X or Windows code would be required. Am I correct to assume we will likely be looking into using Color Quickdraw routines for Mac II builds as opposed to whatever drawing mechanism, perhaps "regular" QuickDraw, that is used for non-Mac-II guests, and that is currently used for Mac-II-on-Mac-OS guests? What ought we expect? Let's inspect! That being said, realistically, I wish I could actually put the time into this: using most of my short free time to take extra measures (like cooking a lot of food that is carefully-crafted) to deal with gallstones in the gallbladder (successfully, but veeeeeeery slowly), and all other free time being sucked up by work, I cannot find much time at all to do any hobby work like this, short of a few "gasps" like now during the weekend (and that too only sometimes). That is also why I stopped (for now) any work on my C-based Mac game, and my REALbasic-DR1-based Mini vMac helper app. In short, I cannot uphold my own end of the bargain of "coding this together", but I can promise to try here and there. I believe I can inspect Mini vMac 3.4.1 ( and 3.5.8 )'s source code tomorrow and try to see what part of the code we would have to work on to get color on the Mac going, and what code we would use.
Last Edit: December 14, 2024, 11:08 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #17 on: December 15, 2024, 05:01
|
Golaith m68k: I think I tested with my Tiger Server mini. On MacOS 9 I always saw all the right icons, but in System 7.5.x I'd see generic ones (sometimes?). I'll get my old machines out and take a fresh look. I wasn't sure how it was getting the icons, but suspected through Internet Config mime types (so it SHOULD work). It might be it is using MacOS 8.5+'s Icon Services (is that the right name, does that exist or did I make it up? I THINK there's such a beast...), which wouldn't exist on 7.5, so like Unicode, it works, but it's a hack around missing functionality, and would need someone to write a whole other library to actually make it work. That was my thought at the time. ---- Mini vMac Mac II on PPC host color: Probably one of two reasons it doesn't work...it was "hard" or the programmers were "lazy". If "lazy" it could be nobody ever bothered to work on it because it wasn't "easy" or "fun", and there wasn't a great demand for it. If that's it we're gold, because it just needs someone to roll up their sleeves and code. I can't, off the top of my head, think of a reason why it would be "hard". QuickDraw automatically handles pixel formats wonderfully...so maybe they left it out because their implementation was too slow to be usable? If we're extremely lucky, there will be comments in the code spelling things out. Or code already there but disabled, and it'll be clear why. But, if it's just that nobody ever bothered to do it because there never was enough time or demand...I've got some time, and you guys have some "demand". I didn't follow 100% when you said "drawing mechanism", but keep in mind it is a bit of a goofy situation: It would be emulating the Mac II's version of Color QuickDraw using the PPC host's Color QuickDraw! So it WILL be a little confusing. In the code, when you see a PixMap, is it the host's or the emulated one? It might be hard to tell. It is ENTIRELY possible it wasn't done simply because it is hard to not get the two confused. If you have similar variable names, how can you tell without REALLY understanding the code? I could understand someone not bothering because it was just a pain in the butt to write it! And, to be clear, I've heard the way Mini vMac does color AT ALL is a real hack! It doesn't REALLY emulate a full Mac II, but only just enough to get things working. ---- Gallstones: I feel (felt?) your pain...literally! My gallbladder is mercifully gone, years ago late night trip to the ER and then straight to the OR. I'd actually been feeling the effects for YEARS but didn't know what it was until one day, bam!
Last Edit: December 15, 2024, 05:35 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #18 on: December 16, 2024, 07:33
|
@lauland There was a visible, gradual decline in interest from the original author in keeping Mini vMac running on the original Mac OS, sadly. But hopefully that will mean it wasn't due to a technical challenge, and was simply a matter of just willing to put in the effort for it. Versions of Mini vMac after 3.5.8 (3.6.x AKA 36, and the current version, 37) no longer build on Mac OS (rather, the "source code preparer" tool was no longer provided, and I could not compile the newer "preparer" on Mac OS when I tried a while back). I guess that is in and of itself another "project candidate": getting Mini vMac 36 and 37 to compile on the Mac OS again. But somehow I get the feeling bringing color on 3.5.8 / 3.4.1 might be less difficult than that...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #19 on: December 16, 2024, 20:13
|
@Jatoba, I'm setting up my MvM build environment, to work on MvM 3.5.8 and 3.4.1, and wondering which MPW you used, it looks like it might be a German version of 3.6d2 from the gif. I'm going to try the MPW-PR.img_bin (from MG MPW page), which is 3.6d7 (English), but it looks like it is just an update because it doesn't include all the tools, among other things. Do you think the exact version of MPW matters much? I'm guessing probably not? @MTT You described using CodeWarrior to do a build of MvM in the comments here http://macintoshgarden.org/apps/mini-vmac-source-code How did you do it? I'm guessing you still used the MPW Shell (and not something crazy like creating a CW project), but maybe with the CodeWarrior MPW compiler? Or did you just use the MPW that comes with CodeWarrior as-is (which probably used the Apple compiler)? And, regardless, I'm guessing you used CW 8 Pro just because it was a personal favorite version, and not for any other reason? ---- At both you guys: Instead of cobbling together an MPW from parts like I describe above, might it be better to use just a clean MPW install (the GM 3.5.0 maybe?), or someone else's pre-made build environment from somewhere? The point being, we should probably all have the exact same (or as close as possible) build environment...if it actually matters. Which, it likely doesn't really, from my experience on other projects. ---- Update: Have built both MvM 3.5.8 and 3.4.1 using stock MPW 3.5.0 GM. Used same "System 6.img" and "MacII.ROM" to run both on MacOS 9 using ShapeShifter. Compared to native MvM ("mnvm0026-36.04-mc64") on MacOS X 14 MacBook Pro. Can see that on MacOS 9 there is no color...so I'm good to go to look at the source...will see what I find...
Last Edit: December 16, 2024, 20:36 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #20 on: December 16, 2024, 20:56
|
Findings: In the MvM source, where you see "#if 0 != vMacScreenDepth" you can read it as "#ifdef WE_ARE_USING_COLOR", correspondingly where you see "#if 0 == vMacScreenDepth" it means "#ifdef WE_ARE_BLACK_AND_WHITE". Changing both UseColorMode and ColorModeWorks to "trueblnr" in COSMOSGLU.h file enables 256 colors in Montitors control panel. You can then switch to it, but display is obviously not correct. It looks like the emulated Mac II is creating 8 bit pixels, but it is still getting interpreted as 1 bit pixels. Probably need to change the default Mac display mode for host somewhere...it should switch itself, but that is obviously not working.
Last Edit: December 16, 2024, 21:01 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #21 on: December 16, 2024, 21:40
|
Ok, by reading OSGLUMAC.c, I can definitively say: "They just didn't bother". The code is obviously not even trying to use the host's Color QuickDraw. That is NOT color coding I see. I'm hacking on it now...things like changing "NewWindow" to "NewCWindow" and "BitMap" to "PixMap" (and casting "src" in call to CopyBits), and "src.rowBytes = vMacScreenMonoByteWidth" to "src.rowBytes = (1L<<15)||vMacScreenMonoByteWidth" are first stabs at converting it to real Color QuickDraw code. (The 1L<<15 is needed to tell MacOS that this is a PixMap and not a BitMap...they assumed you'd never REALLY have than many bytes in a row!!! BitMaps are 1 bit only, PixMaps can be anything). In the results are after booting, the emulated Mac II still thinks it is in 1 bit pixel mode, but MvM is (probably? I think?) displaying 8 bit pixels (or at least SOMETHING more than 1). So you can't see enough to change the Monitors Control Panel to color, as the emulated Mac defaults to B&W. If this were hacked around, to force the Mac II to boot into color, it MIGHT be working right now...but, I do see the grey background, and what DOES display after booting, looks sheared, so something is still likely off. ie You might see a color display but it'd be distorted. The offscreen buffer MvM uses is likely not the right format, so looking at that next. Probably plenty more to fix... Even if we do see color, we'll have to add palette handling or the colors will be wrong...so REQUIRING the host be set to Thousands or Millions may be a Good Idea(tm). (Changing both ScrnMapr_SrcDepth and ScrnMapr_DstDepth to 3 is probably needed). NOTE: Blindly hold down the control key, then "c", then "q" then "y" to make MvM quit. ---- Now THIS is the kind of programming I've been talking about in other posts. I have no idea how the code works, but I do know the differences between classic black and white code and Color QuickDraw code, so I just jump right in without a clue what I'm doing and change things on the fly and see what happens. It is real seat of the pants crazy dirty cowboy coding, but this is exactly what is done all the time in the "real world", just to get things working.
Last Edit: December 16, 2024, 22:18 by lauland
|
MTT
|
256 MB Posts: 394 SSW7 Oldtimer
Reply #22 on: December 17, 2024, 00:52
|
Hello @lauland: Firstly, thank you for finding time to dig into getting color working in the Mac II variation builds. Secondly, my apologies if this turns into a forlorn exercise. @Jatoba is correct in that color was not implemented (or at least wasn't c2014) in the classic Mac OS builds. I hadn't seen that notice or had skimmed over it, and had only read it today under the section for Screen Depth on the MvM Options page (WA): "Color is currently only implemented for Macintosh OS X and Windows, and experimentally in the X versions." Bah, I wish I had noticed that statement earlier. And why hadn't it been implemented? Mini vMac (all variations) work great in native PPC Mac OSs 7.5 to 9.2.2 - Lack of color being the big drawback in Mac II builds. You asked how had I used CodeWarrior/MPW for my builds? I'm a total novice to compiling source in a classic Mac OS and I hadn't installed or used CodeWarrior or MPW, before compiling the MvM 3.5.8, 3.4.1 source. Therefore I followed (almost) to the letter, the advice given in the Building Mini vMac guides. Specifically: The advice for compiling under Mac OS 9 Building Mini vMac Additional Options, as listed in the Mini vMac Options page. <- totally missed the color not implemented in classic bit  Plus advanced tweaks as outlined in the Mini vMac Developers page <- if you haven't seen these pages, they are all worth investigating So, I chose CW 8 Pro and the final gold MPW, not as a personal favorite, but because these were the versions used by Paul C. Pratt in developing and building from these src versions. The instructions given on the build page are very simple to follow, anybody could use them to build Mini vMac, even me Anyway, I do appreciate you looking into this with some depth, I only hope that it won't be a waste of your time, lauland.
Last Edit: December 17, 2024, 02:29 by MTT
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #23 on: December 17, 2024, 11:55
|
@lauland I used MPW version 3.6b2 (Beta 2) rather than d2 (Developer 2), which is the final and latest version of MPW. The GIF picture quality is not the best, so it is easy to accidentally see the "b" as "d". All Apple software from the time seems to follow a version pattern of "d" (developer, rather than "Deutsch" AKA German) versions, which are then "promoted" to "a" (alpha) versions and the version number resets (so for example a2 > d8), which then gets "promoted" to "b" (beta) versions, which is what we have here (3.6b2), and then, finally, to GM (gold master) versions once it is ready to be released in its final form, thus dropping all such suffixes to the version number (so for example the last GM version of MPW was 3.5, no "d", "a" or "b" appended to the version number at the end). In the MPW page in the Garden, I took and installed the GM 3.5 version (download #1), then overwrote all files with those updated by the final pre-release 3.6d7 version (download #2), then finally did the same with the latest updates for MPW, bumping it up to 3.6b2 (download #3). The MrC and SC compilers, and all the other tools and files, are also updated to their final versions through these same downloads and steps. The reasons I used this setup are two-fold: - Like @MTT pointed out, it is the exact version that is specified in the official Gryphel Project website, which hosts and used to develop Mini vMac; - It is the latest version of MPW and all the tools, so I figured since I had to start from somewhere, I might as well pick up the latest stuff, then go from there. I completely agree we should be using the exact same tooling and versions so we are on the exact same page. However, like you, I also do feel that, most likely, most versions of MPW and its associated tools produce the same or "similar-enough" results. However, from the looks of it, it seems you already got a very good grasp of the codebase situation regarding Color QuickDraw before @MTT or I got started, so we would be more than happy to go with any tooling/version you like. Although at this rate I wonder how we could actually possibly help when you are already rocking and rolling, and got this far so quickly! That's awesome!Incidentally, I assume you are working on the 3.5.8 source? Mini vMac is visually-glitchy, and overall glitchy, on Mac OS 9 and earlier, at least when that version is compiled via MPW like @MTT pointed out ( as opposed to CW Pro 8 ). So the visual oddities you described you were getting sound exactly like what I would get with 3.5.8 + MPW compilation. Perhaps it's worth a shot to see if they are also present for you when compiling with CW Pro 8 instead? Or, alternatively, see if they happen with the 3.4.1 source. I suspect whatever color patches are done to 3.5.8 can most likely be easily ported back to 3.4.1 if we ever need to, no? Anyway, very exciting to see this!
Last Edit: December 17, 2024, 12:01 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #24 on: December 17, 2024, 15:22
|
I'm going to start a new thread under "Emulation" for this "color MvM PPC" project, where it belongs, and continue there. This thread could be used for anything else, like if we talk further about Goliath m68k, possibly a HyperCard financial project, or anything else.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #25 on: September 02, 2025, 16:31
|
I'm looking for my next programming project. Let me know if you guys have any ideas. I don't necessarily take requests, unless they're "interesting" (by some vague definition), something the community is missing, or that would help the Mac 6/7/8/9 world. Ideally, I'd love to work with other people on something, so if any of you wants to stretch or learn your programming skills that'd warm by my cold tired heart. One possibility I'm considering is a port of "Linapple", which is one of the countless Apple 2 emulators out there. Someone out there has asked about an Amiga m68k version, and since it uses SDL, if I did work on that, I'd make classic Mac versions too. (It looks like there is already an OS X port). There are plenty of good ones already, so I'd just do the Mac version as a side effect. Don't know how much work it would take, but probably not too much...mostly dealing with things that don't exist in classic MacOS. https://linapple.sourceforge.net/ https://github.com/linappleii/linapple (modern links)
Last Edit: September 02, 2025, 16:34 by lauland
|
68kmac
|
32 MB Posts: 51 System 7 Newcomer!
Reply #26 on: September 02, 2025, 16:47
|
Make a tutorial for Those, who want to Code. Dont try to teach a programming language, but make lessons Step by step (open Windows, Buttons, and as last step, make graphic/sprites. That would be cool.
|
wove
|
1024 MB Posts: 1363
Reply #27 on: September 02, 2025, 17:15
|
One of the most common reoccuring questions on the forums involves connecting to a network. There are a lot of different possibilities on the older Macs, from stuff that Apple make, to third part cards and dongle type things. Apple also had different control panels and extensions to configure a network, and of course time has brought a whole lot more into the mix. A utility to guide a user through the mixture would be handy. Something that would probe the hardware on the Mac, perhaps get some user input on what sort of network they are trying to attach to and then assist in setting it up. It is something that could grow over time. It could have a database of control panels needed for different use case, perhaps eventually adding some common software/extensions/control panels. Having the ability to turn extension off/on as needed. People that can code could code, the community could provide the control panels and extensions they use for various configurations. Perhaps it could be setup like a hypercard stack adding the ability to write configurations and install needed and missing software. It does sound pretty complex, and maybe undoable. However it could involve input from many people with a vide range of abilities. It is something that could also evolve and grow over time and remain very useful for many years.
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #28 on: September 03, 2025, 02:44
|
Besides still loving to give MpegDec a facelift, here's are a couple of things the sole MP3 player for 68k Macs could have: If an MP3's album art is over 20k in size, MpegDec cannot display the MP3's title nor artist, but what if this limitation was fixed? And could it be made to also display the album art somehow? Now that would be a super-crazy cool! Believe it or not, mendelson.org added a Mac OS 8.1 SheepShaver app for Mac and Windows, but of the many PPC MP3 players I tried with it, all crashed except for one; you guessed it: MpegDec!  so it's still king of the hill in my book!Additionally, Mike at the MG even added a pros and cons of using MpegDec, and it had a list of some insightful shortcomings that looked pretty surmountable; well, not to me, of course  besides Mike's keen observations, I did notice that any streaming radio links that end with .mpg/.mpeg rather than .mp3 are readable by MpegDec, but to play these, I have to save the stream first so it doesn't actually play the stream, just the saved files from it; it seems like something that sounds like it could actually stream but it does not know to do so I think?I'd love to try to help this time out, even with some caveats that I have no clue what's whatsoever of what's needed behind the scenes to undertake such a beast!  thankfully the source code is included in the download in its MG page!
|
snes1423
|
256 MB Posts: 458 A Man born of Mechina
Reply #29 on: September 03, 2025, 03:39
|
isnt that just Basilisk translated into Java?
|
|
Pages: 1 [2] 3 4
|
| |||||||||||||||
|
© 2021 System7Today.com. |
