Search results

It’s not the 68000 that’s tripping you up, it’s the ROM. The Plus ROM doesn’t have the Graphics Devices calls in it, so you can’t call GetMainDevice. Pre-Device Manager, you can check the QuickDraw global variable screenBits.bounds to get the bounding rectangle of the display. (You meant...

Coding a floating window in classic Mac OS was always Hard. There are some MacTutor articles on it, but it’s a pain in the butt, unfortunately. Auto-showing the dock on a mouse move would require writing an INIT, yeah. You’d probably have to patch _OSEventAvail (some apps won’t call...

It was quite recent, maybe last year? One of the cutaway videos had an engineer in front of a bookcase that had a MacEffects case on a shelf behind him as I recall …

Ha, that is amazing. I never noticed that difference between SEs and SE/30s despite using an SE/30 daily for years. Thanks for pointing this out. So obvious now that you mention it…

You’re right about the decline of UIGs, but with this comment I respectfully think you go too far … Apple’s software produced by Apple, whatever its flaws, still actually comports pretty consistently to a set of standards. The tools broadly match each other, including to an extent across Apple...

Totally agree it’s a weird and hacky assumption no doubt!

First of all, so glad this is working in color - congrats! This issue sounded super weird so I couldn’t resist looking into it, and so checked out the source for for the Icon Utilities which you can find here...

It runs once to get the mask, which is always in the ICN# resource. Then, unless you’re in b&w mode, it has to run a second time to get the actual icon data, which is (for example) in the icl8 resource.

Yeah you’ll probably just have to write it. “I want a text file with an ASCIIfied hex dump of a whole volume” sounds like a pretty bespoke use case.

That’s weird. I have a half baked idea why that might happen (Finder doesn’t actually have a BNDL/ICN# in a normal sense but simply knows to displays a standard generic “system file” icon for itself … in a way, the question is almost more why does this even work in color for the Finder?) but...

I agree! This seems like a weird aspect of using PlotIconMethod(). I would either do what you suggest, or (presuming you are plotting one icon at a time) just have PlotIconMethod stuff the handle into a global variable and call DisposeHandle() every time. I don’t think there’s a better way.

Isn’t this just a disk image? Have you tried making a Disk Copy image and examining the hex?

Maybe not interesting to others but I an annoyed enough to share that I will not be there even though it’s about a 20 minute drive from my house — I was excited to go for the first time but a family vacation got scheduled for the same weekend. Next year, I really hope ….

Yes that’s right. C functions pass arguments right-to-left to support variadic functions, require the caller to clean up the stack (since they don’t know how many arguments they got), and also return their result in register D0. Pascal functions pass arguments left-to-right, clean up the stack...

This is well expressed. I agree - I am mainly a software guy, and really enjoyed using old programs like (the best one ever) MacPaint, because I could sit down and read the manual (I liked reading the whole manual!) and in a little while feel like I knew everything about the tool and what it...

Nice and great to see the intuitive results match the benchmarking! This is a really nice project by the way. Side note: in your asm code as you shared above, you were actually OK using a0, a1, d0, etc. Those registers are considered “trashable“ registers by the ROM and so can be nuked any...

Oh, I see why the optimizations aren’t improving your timing. Highly suspicious fact: Your benchmarks are always giving the same result. 100*166 = 200*83 = 500*33 ≈ 16600 microseconds = 1/60 second = exactly 1 tick. Explanation: You are getting all these blits done inside the timing...

Even on a 68000, a MOVE.L (a0)+, (a1)+ takes (I believe) only 67% longer than a MOVE.W. Source: https://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/timmove.HTML Looks like 20 vs 21 clocks. So if you do (MOVE.L DBRA) instead of (MOVE.W DBRA MOVE.W DBRA) it should definitely be faster. But yeah...

Oh, you want DBRA not DBEQ there. DBEQ says “first check if condition code Z is true and if so, stop looping, else continue unless the counter has run out”. You just want to loop until the counter runs out, which is DBRA (equivalently DBF ... “never stop looping unless the counter has run...

Oh, I thought you were blitting from screen to screen. I didn’t realize your source bitmap (as opposed to the desired image within the bitmap) was only 128 pixels wide. In that case, Your source bitmap is 128 pixels wide. That’s an even multiple of 16. Your rowBytes should be 16. You don’t...