Macpaint and quickdraw source code posted — #28

Post #28 by Gorgonops

Source Forum	68kMLA
Category	Development
Post Date	Tue, 27 Jul 2010 - 18:32
Original URL	https://68kmla.org/bb/threads/macpaint-and-quickdraw-source-code-posted.20973/

Post

4. With regards to QuickDraw, was there any foundation for color in the original programming? I remember reading somewhere about the classic Macs having colors built in somewhere despite not being able to show them on the screen natively (I know there were some color boards available for older Macs many moons ago, not sure if they relied on QuickDraw, the ROM, or something else).

I remember reading on folklore.org that the original Macs supported "spot color" in some fashion in order to run the color Imagewriter, but undoubtedly someone else knows far more about that. Let's see... Here's a link to an InfoWorld review of a color board for the Macintosh SE. It mentions that it works with "... some programs that use Color Quickdraw, provided they support the Imagewriter in eight colors...

A quick grep of the code shows definition blocks like this:

Code:

;-----------------------------------------------
;
;  QuickDraw Color Separation:
;
normalBit       .EQU    0                       ;normal screen mapping
inverseBit      .EQU    1                       ;inverse screen mapping
redBit          .EQU    4                       ;RGB additive mapping
greenBit        .EQU    3                       ;for photos from screen
blueBit         .EQU    2
cyanBit         .EQU    8                       ;CMYBk subtractive mapping
magentaBit      .EQU    7                       ;for ink jet printer
yellowBit       .EQU    6
blackBit        .EQU    5

That looks suspiciously like "eight Imagewriter colors". So it doesn't really look like there's inherent general-case "arbitrary depth" RGB color support.

I still haven't gotten a chance to examine what's in here, but I'm not sure how much of it I'd really find useful. I took courses in BASIC, C++, and JAVA, plus I know HyperCard very well, but have never studied regular C (not sure how different it is from C++) and don't have a good grip at all on assembly language. (I do want to learn a bit more about this down the line, perhaps I'll study it a bit this fall in my spare time).

None of it is in C, actually. The assembly language is very well documented, so even if you don't do assembly at all you can pretty much grasp what an individual function is doing. (Where it gets hard is there are a *lot* of variables and constants to keep track of, many of which appear to be globals. So tracking the code path across modules rapidly turns my brain into mush.) As for the MacPaint code I've never written Pascal but it "reads" fairly easily. Again, the issue is that there really isn't that much done inside the main program itself. It's essentially a huge collection of calls to EXTERNAL functions and API hooks, so to understand it you'll have to backtrace everything through the referenced assembly code or the "Inside Macintosh" API reference.

I'll admit I have a terrible time following other people's code once it grows beyond a certain size. If you don't suffer that limitation it should be less daunting than I'm finding it.