|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | SDL 1.2.x for M68k attempt... (Read 118260 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
cballero
1024 MB  Posts: 1176 System 7, today and forever 
|
Reply #30 on: January 06, 2025, 08:20
Quote from: Lauland Booted up my Performa 630, and it also only goes up to 256 colors. The more I thought on it, the more I believe Apple never released any M68k hardware that could do Thousands of colors.16-bit color on most desktop Macs was limited to 640 by 480 unless you had a video card; a few notable exceptions were: Three 68k Macs actually did millions natively with added VRAM!  I love quoting Mac specs!  As far as resolutions (not counting greyscale bit depths, of course)The Quadra 700, 900 & 950, w/2 mb VRAM installed, can all display 832x624 at 24-bit! The Centris 660AV: natively does 640x400 at 24-bit color and up to 832x624 at 16-bit The Quadra 840AV natively does up to 640x400 at 24-bit and up to 832x624 at 16-bit Finally, many other 68k desktop models natively support 512x384 at 16-bit color, and a few others 640x480, just not most 68k PowerBooks, except the color Duo 270c & 280c, which both can display 640x400 at 16-bit; the color classic’s VRAM could be increased to display 512x384 at 16-bit I did a lot of research and hands-on on this topic because I wanted to play with image editing and video back in the day, which I did, but a lot of that happened on PPC Macs due to the cost of these 68k Mac models! |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: January 06, 2025, 18:30 by cballero
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #31 on: January 06, 2025, 15:57
|
Well dang, I feel dumb. I was using a mac->vga adapter that was set to 1024x768! I'll take a fresh look at my 630. I also have an Quadra 800 (with Centris 650 motherboard so that's what it really is) and will see if it can do Thousands also. I've also got an LC 475 and will boot it up too. I know video ram is just plain weird, and can be very proprietary, but I have a box of simm/dimms I've collected over the years and will look there and/or if I can swap video ram between machines...if they don't have enough, to upgrade them so they do, if possible. Not only that, but Breaker's art is all 256 colors, and it requests a 256 color screen. So, if SDL were working in that mode, at least that game would run well...maybe even better than in Thousands/Millions. ---- So I took a look at the Mac video driver, and there IS code in there to handle displays with palettes, and it looks like it is well written and does what it should, so may just have broken at some point as the maintainers stopped testing it. The video blit routine is also just a relatively thin layer over CopyBits() (as expected). So the code is definitely not Thousands/Millions specific. My best guess so far is that it sets up the wrong palette in a particular place (or two), so QuickDraw gets confused. It thinks it is drawing with one, but the screen is set to another. Commenting out ALL the palette code in the video driver has no effect in running in Thousands/Millions. It, of course, changes how it acts in 256 color mode, but it is still, of course, displaying wrong. The Mac driver doesn't have any code to switch video modes, so it just runs on whatever your screen is set to, and lets QuickDraw handle the conversion from what I can tell. I need to test the DrawSprockets driver...it MIGHT change modes, and see if it also displays wrong in 256 colors.
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #32 on: January 06, 2025, 19:39
|
I also got me a refurbished Quadra 630 some time after it came out because of its processor speed as well as its high bit depth resolution!  out of the box, I remember it did 512x384 and 640x480 at 16-bit color!Now both your LC 475 and Centris 650 in the Q800 case can also do 512x384 at 16-bit color, but if upgraded to 1 MB of VRAM, they can also do 16-bit color at up to 832x624!However, some Centris 650 models were sold with a full MB of VRAM, so your might be one of those lucky owners! Hey, we can hope, right? So basically, all of your 68k Macs can do 16-bit color!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #33 on: January 07, 2025, 01:02
|
BTW, I took a look at SDL2...for MacOS 9...in CodeWarrior of all ill considered notions...IMHO the problem won't be "adding back the mac bits" (there's so much that needs to be there, that never WAS), nor would much be possible to salvage from SDL1. The problem being it assumes you are on a "modern" platform, using a "modern" compiler, with everything that comes with that, which is a whole lot these days. What I did was start with an empty project and took testrendercopyex.c, which is the rough equivalent of testwin.c (in SDL1), which loads a bitmap and draws it. By default it uses SDL_config_minimal.h, where ALL drivers are dummy'd out. Then added SDL_main and compiled. Then started adding all the base .c files from the primary folders in src. I did...a lot of things... Every time I'd hit a "please define your plaform", I'd add empty dummies. Every time I'd hit a link error, I'd find where the function was defined, and added that file. It detects your CPU and there's a lot of PowerPC assembly, but the syntax is different from CodeWarrior so it I just #ifdef'd it out... Rinse, repeat...eventually hit a point where it assumes if you aren't Windows, you've got posix threads, which we in no way have. It's a significant, but still small (a third?) chunk of it. Beyond saying "whee...I'm really compiling SDL2!" it's not worth much, and CodeWarrior is missing so much (and MPW would be worse) that I can (pretty) confidently say this is a non-starter. I'll probably dummy out the pthreads, and keep going until it no longer makes any sense to do so, but, even if I did end up with a runable "application" it won't actually do anything at all with no drivers. The drivers rely on a huge amount of new infrastructure, so "porting" the SDL1 ones isn't really possible. I can upload what I end up with someplace here, so, in the very least, maybe @Jatoba can experience the "thrill of victory" mixed with the "agony of defeat" himself if he wishes. And/or leave this either for someone else to (futilely?) continue to try, and/or serve as a cautionary example. ---- With that said...back to the real world and SDL1...ah...feels so small and safe...I'm going to test the M68k version on real world hardware probably tonight, now that I know some of mine SHOULD be able to run in Thousands of colors...
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #34 on: January 07, 2025, 07:22
|
This evokes images of Thomas Edison working on the lightbulb filaments..
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #35 on: January 07, 2025, 15:54
|
SDL2 I think I felt more like Nikola Tesla did. A more apt comparison since SDL2 for MacOS 9, like many of Tesla's more outre ideas, will probably only exist in theory, on paper, as an impractical, theoretical design. A lot like some of his efforts, there are good reasons they don't work in the real world, or would require infrastructure or materials that either don't exist or are not financially feasible. One thing I want to point out, if anyone gets anything out of it, is the approach I took, which illustrates some of what I've been saying about programming philossophy in other posts. Similar to me reading (or trying to) a book in Catalan, I knew I didn't know what I was doing, or fully understand what I was seeing, but just DID IT anyway. Other people might've been tempted to start by setting up a lovely looking hierarchic project in CodeWarrior like SDL1's, read the docs about how SDL2 works, look at posts of people talking about it, research research research, etc, before they even tried compiling a SINGLE file. They would end up with absolutely nothing to show, not a single line of code at all, and probably have spent days before they realized any of the actual real world problems. Instead, I already have many pieces that DO compile, it may not end up working, but I struck right into the building of it FIRST. This may seem backwards, but gives immediate results, and I've learned a lot by rolling up my sleeves and DOING rather than researching. I have something tangible to show others, that someone else might use as a base in the future, or, at the very least see why they shouldn't even try. I saw the problems right before my eyes, instead of based on hearsay or "what people have been saying", etc ec. ---- SDL 1.2 Similar to our beloved platform, I also took a look at the state of Amiga SDL, which is a royal mess, with at least three separate unrelated branches, none of them official. The m68k branch itself then splits with more than one person's efforts, and it unclear which actually works, if any. Very sharp contrast to the Atari world, which is still actively maintained in the main official repo. Had lots of fun trying to test my m68k SDL build on actual hardware. None of my M68k macs have working ethernet. The 630's comm slot is physically blocked by the "DOS Compatibility" boards. My LC 475 has an Apple IIe card in its slot (which I can take out...but where did I squirrel away the comm slot ethernet board?). And I can't find my Apple AUI ethernet adapter. So just getting the apps onto the machines is a challenge. Probably will set up localtalk with a bridge. I've been meaning to anyway... I ended up trying ZIP disks, but ran into problems there too. My M2 MacBook, of course, won't read HFS (non-plus) disks, but I had some PC formatted ones. Of course I forgot that the filenames and resource forks are handled EXTREMELY differently between MacOS Classic and MacOS X. Should've used stuffit. Anyway, I'll either do that, or use an intermediate machine which CAN read and write plain HFS... I feel pretty dang silly, not knowing Apple very much DID make m68k models that can do Thousands of colors just fine... Have uploaded the m68k version of Breaker to the MG page.
Last Edit: January 07, 2025, 16:00 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #36 on: January 07, 2025, 18:29
|
@lauland Ah, yes, I got threads and tasks mixed up, thanks for pointing that out. Out of curiosity, what about the oldschool "Desk Accessories"? They do a good job of giving the illusion of "multitasking" in System-1-era software. Also, if SDL runs in 256 colors in other platforms, ideally the Mac should also have that option, just like multithreading, but again SDL seems to sideline most platforms despite being "cross-platform". Well, let's see what we end up doing over time. Quote from: lauland I did "Find Differences..." between "SDL-1.2-main.zip" and "SDL-1.2.15.zip" and saw way more than expected. It looks like main is newer, and some things were removed, for example support for older PC Borland and EMX compilers, just to start...but at the same time, a lot of work for Watcom on OS/2 and other oddness, and ARM64 work. I think we will likely be better off basing everything on 1.2.15 like it's been so far. Actually, last night and tonight, I was/am trying to build the 1.2.15 Release CodeWarrior target, since everything else builds, but surprisingly that is not working for me. It fails during linking with these 3 errors: Link Error : export symbol 'SDL_LoadObject' is undefined Link Error : export symbol 'SDL_LoadFunction' is undefined Link Error : export symbol 'SDL_UnloadObject' is undefined These are defined in SDL_loadso.h, which is certainly added to the project for all targets, and SDL_loadso.c and everything else compiles, yet linking fails with those errors. If I go to project settings > Linker > PPC PEF > Export Symbols, the pre-selected option is "Use .exp file". Changing that to "None" compiles and "links", but the resulting Shared Library, I think, is incapable of functioning since the methods are not expose for entry (is my understanding correct?), and so if you try to use it on e.g. SDL Mini vMac, it instantly errors out. It's funny how I can compile the Shared Lib and nothing else with MPW, and everything with CW except the Shared Lib! At least I have a working route for each target. But still, I'd like to understand this, and fix this. I see that we have "SDL.mcp.exp", and it's included with the project, and I see a huge list of method names in there, including the ones the errors mention, so I don't know why it is happening, and only with those 3 methods and no other. Incidentally, they were newly-added in SDL 1.2.6 I think, so they are rather "new", and I wonder if knowing that could be... relevant. Maybe I will try the included CWPro5 project next to see if somehow it doesn't have that issue?
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #37 on: January 07, 2025, 18:36
|
I forgot to mention, the reason for basing things on 1.2.15 instead of the rolling 1.2.16 is that it is not clear yet to us that 1.2.16 is indeed "better" to use for Mac OS. In short, once we get the CW "Release" target to compile, then I can move on and try to do the same for 1.2.16 (for all targets: Debug, Release, SDLmain, Stub Lib and Resource). If all of those pass in 1.2.16, and we use it on SDL vMac, Breaker etc. and it works, then I'd say we could then base it on 1.2.16, but until then, I find 1.2.15 "safer". Of course, don't mind me on that, to me eitherway is fine! The important thing is that the Mac improvements roll in one way or another.
Last Edit: January 07, 2025, 18:38 by Jatoba
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #38 on: January 07, 2025, 19:06
|
Quote from: Jatoba Link Error : export symbol 'SDL_LoadObject' is undefined Ok... so... I got it to compile, but I don't understand why the step I took was necessary. So essentially the project file had already "SDL_loadso.c", and I forcibly later even shoved "SDL_loadso.h" in there, as well, for good measure. BUT, I just noticed under the "Link Order" tab that the long list of files did NOT include "SDL_loadso.c" at all! So then I noticed the "N/A" value for the "Code" and "Data" columns inside the project files window for "SDL_loadso.c", as opposed to a numerical value like for most files. I wanted to make sure it was compiled. But when I right-clicked on it etc., there was no "Compile" option. But for files that had a numerical value for those columns "Compile" (and a lot else) was there! So I instantly picked "SDL_loadso.c" from the Finder and dragged it onto the project window. Ta-da! Numbers! The columns no longer showed "N/A". And then it compiled! And then the whole of "Release" compiled! Why did I have to add a file that was, at least seemingly, already added to the CodeWarrior project? What's up with that? Never seen this behavior in any IDE. Is this a C thing, or is this one of those infamous "CW quirkiness" things? Anyway, glad to see this dealt with. Now will test the resulting shared lib. Also, regarding that file, I noticed it was also "N/A-ed" for the Debug target, yet that one compiles without complaints. But does that mean it was compiling it wrong all along, and just waiting for runtime errors to happen? I'd love a bone on this one, to understand the severity of things. EDIT: Oh, and, incidentally, the BeOS version of "SDL_loadso.c" of all things was inside the project's "loadso > macos" virtual folder, so I kicked that out. The Mac version of the file I had inside a "Rescued Items" folder at the very top, for some reason. Was there some mess up by whoever readied that file for SDL Mac OS, and the mess up went totally undetected? Anyway, now things are looking good, since the .exp file seems to find all listed functions during the link phase. So I guess I shouldn't be concerned anymore about this happening again with any other source file. (Right? Unless if that .exp file is missing some functions that, actually, should be in there so that SDL-based apps can access them. Anyone please feel free to correct me if I'm concluding anything wrong in here.)
Last Edit: January 07, 2025, 19:13 by Jatoba
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #39 on: January 07, 2025, 19:47
|
Quadruple post, but here it goes. I tried out my "Release" SDL 1.2.15 newly-compiled-via-CWPro6 Shared Library in SDL Mini vMac II with Color to see if it would work this time around: http://revontulet.org/2025/01/07/9bb4f56aee6743b599f83c2ed4bab467.jpg Even won a Shanghai II game with it in Color for the first time and got a fortune cookie!
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #40 on: January 07, 2025, 20:46
|
Yeah, I tried compiling SDL 1.2.16 and... is it just me, or are the source files rather... "vandalized"? Or at the very least, the source has changes which would require a number of "Mac Adjustments"(tm) in it and in the CW project file... Is that correct? In short, I can't compile it in CWPro6. I tried deleting a bunch of files that seemed to be getting in the way that were platform-specific and not Mac related, but... it doesn't seem like doing just that is enough. It really does seem like 1.2.16 is really just a wild, "everything goes", "no rules, law nor order" codebase, and not what we want any of our changes to be based on. I'd say 1.2.15 is the latest we should make modifications to. What do you think, @lauland? Did you give compiling 1.2.16 a go?
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #41 on: January 07, 2025, 21:48
|
Desk Accessories: Don't get me started. They technically are really "device drivers" and so get their cpu cycles that way. They have to use a different register for most things (a5 instead of a6), if memory serves. They are REALLY WEIRD. I'm pretty sure they are still not truly preemptively mutlitasked, at least their user interfaces can't be since they call the ToolBox. ---- 256 color mode: It looks like it broke at some point. In the video driver they call NewPalette(), but don't change any of the colors in it, so I don't know if it gets defaults or not. The SetColors works and actually sets the video card's palette, but it doesn't tell QuickDraw about it correctly(?). There seems to be a mismatch between what the offscreen surface actually has vs what the hardware is set to. I think QuickDraw is getting confused. I actually got SDL Scavenger to work in 256 colors, but with all the wrong colors, if I comment out some of the palette code in the video driver. Breaker just draws blank cycling colors because it is trying to do more sophisticated animation. I'm going to work more on this...or not...at some point. If m68k macs can run it well in Thousands of colors, it can wait for later. ---- SDL_loadso: I have been only building static because I need to be sure the application is actually using the version of SDL that I just built. Otherwise, it will use the "SDL" file in the folder with the app. I'll look some more into building as a shared lib. It looks like maybe the CW project only builds the lib stub, at least the project files I've been looking at. I don't actually see a target for a shared lib! So maybe only MPW is set up to do that? Check if you are actually building a shared lib with CW. If the end result is just an "SDL" file, then you are, if it's a ".lib" then it is really static. I think the file showing n/a in the project was because CW was only set up for static? I'll take a closer look... ---- "Rescued Items": I was getting the same thing when I was trying to switch some of the drivers to dummies for the m68k. The problem is the files for the various platform drivers have the same name, so ALL the shared lib drivers are called "SDL_loadso.c"...CodeWarrior will NOT let you have two files in a project with the same name, even if they really are different and in different folders. CodeWarrior also tries to be "helpful" by finding the files in the folders for you, but sometimes gets confused and probably grabs the first one alphabetically in some cases. (Hence BeOS) I've never built shared libs in either CW or MPW, so I'm not sure what is going on, but suspect (well...I know) things are a bit of mess with building SDL on MacOS. I haven't dealt with stubs or .exp files either, so you're ahead of me there. ---- 1.2.15 vs 1.2.16: I downloaded and did "Find Differences..." on several versions from 1.2.13 on, and there don't seem to be ANY Mac changes (since 2012?). There were across the board changes, particularly OS2 and Atari and Windows. I'll take another look and see if I can see the "vandalization" you're seeing. It wasn't clear at first glance. I'm guessing 1.2.16 is the one with newer copyright dates, and the one you're thinking would be best, if we can get it to build, right?
Last Edit: January 07, 2025, 21:51 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #42 on: January 07, 2025, 21:53
|
SDL2 for MacOS 9: Believe it or not, I got the whole thing built, but with all dummy drivers. I got file io working so SDL_Log works and can actually see output from some of the tests. I do NOT know pthread mutexes, so wrote just enough stubs that it will compile and the funcs all just return non-error values (I don't think it matters unless we actually used threads, for which there's no driver even in SDL1). I think it is using the wrong code for byte swapping, but I think I can fix it, hence the errors you'll see below. There's a problem with memory allocation functions, probably it is calling a dummy that says "always fails" but I think I can figure that out. This causes all non-trivial tests to just immediately quit. Here's the output of testver: INFO: Compiled with SDL 2.0 or newer INFO: Compiled version: 2.30.11 () INFO: Linked version: 2.30.11 () Here's the output of testplatform (note the errors!), and I did NOT put "MacOS Classic" in there, it was already there! :INFO: This system is running MacOS Classic INFO: All data types are the expected size. INFO: Detected a big endian machine. INFO: Detected a big endian float word order machine. INFO: Value 16 = 0xCDAB, swapped = 0x1 INFO: 16 bit value swapped incorrectly! INFO: Value 32 = 0xEFBEADDE, swapped = 0x1 INFO: 32 bit value swapped incorrectly! INFO: Value 64 = 0xEFBEADDECDAB3412, swapped = 0xDEADBEEFDEADBEEF INFO: 64 bit value swapped incorrectly! INFO: All 64bit instrinsic tests passed INFO: CPU count: 1 INFO: CPU cache line size: 128 INFO: RDTSC not detected INFO: AltiVec not detected INFO: MMX not detected INFO: 3DNow! not detected INFO: SSE not detected INFO: SSE2 not detected INFO: SSE3 not detected INFO: SSE4.1 not detected INFO: SSE4.2 not detected INFO: AVX not detected INFO: AVX2 not detected INFO: AVX-512F not detected INFO: ARM SIMD not detected INFO: NEON not detected INFO: LSX not detected INFO: LASX not detected INFO: System RAM 0 MB Since all the drivers are dummies, it's not terribly useful, but it IS the real thing, for what it's worth. Once I've fixed the byte swapping and memory allocation I'll share it someplace.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #43 on: January 08, 2025, 16:05
|
Quote from: lauland I'm guessing 1.2.16 is the one with newer copyright dates, and the one you're thinking would be best, if we can get it to build, right? "Better" only if, after building, it works fine with other SDL apps to confirm it's working fine, like SDL Mini vMac, Breaker etc.. The copyright dates are still stuck at 2012 (which is when SDL 1.2.15 came out), I believe. About building shared libraries in CW for SDL, that's one of the pre-configured targets: "Release" is pre-configured to compile a "Shared Library", in contrast to "Debug" which is pre-configured to compile a "Library" (Static Library). Incidentally, the shared lib resulting from the CW project is called "SDLClassic" by default, rather than "SDL". I seemed to be able to use it without having to rename it in SDL vMac. I thought I'd have to rename it to "SDL" for sure, or recompile Mini vMac to use it with the new name, but it seems not. It still works if you do rename it, though. It also uses a different file icon than it does when we compile it via MPW, which I found interesting. The CW-compiled one looks fancy!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #44 on: January 08, 2025, 18:27
|
SDL-1.2-main has a few 2020 and 2021 (at least) datestamps in it. I'm going to try building it and folding my changes into it. I'll let you know how that goes. If I can't get it to work "out of the box", I'll make an effort to do so. I might ignore whatever CW project files it comes with and just copy the ones I've been using over. They should work "as is", since there probably weren't any major .c files added. (includes don't count). I have to admit, I've only been doing debug (and no release) builds so didn't see the CW shared lib at all. I'll take a look. I don't know if shared libs have a name inside them and it looks for that...it might also be finding and using some other "SDL" file someplace on your drive. The trick being making sure which one it is actually using when you run an app, so we can be sure, when we have changes, we know it is using them. That's the primary reason I've been doing it all static.
Last Edit: January 08, 2025, 18:28 by lauland
|
|
Pages: 1 2 [3] 4 5 ... 8
|
| |||||||||||||||
|
© 2021 System7Today.com. |
