Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why MacPaint's Original Canvas was 416 Pixels Wide

looksgoodworkswell.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Why MacPaint's Original Canvas was 416 Pixels Wide

#21

Post by kabdib »

Yup, MOVEM was pretty neat on the 68K. For the Atari ST I wrote a very fast memory-fill using a tower of MOVEM instructions; you could get to within a percent or so of the system memory bandwidth, and you might as well stop trying at that point.

(Also had to deal with some other company's programmers who thought their way to fill memory -- with an overlapping memory copy -- was more clever. But theirs was five orders of magnitude slower).

It's interesting that Atkinson's code doesn't unroll the MOVEM loop at all. He could have gotten another couple percent of loop overhead out of it :-)

Re: Why MacPaint's Original Canvas was 416 Pixels Wide

#22

Post by kalleboo »

teamonkey wrote: post #16

I know 68k from the Atari ST, and the MOVEM.L trick was well known. The ST had a similar M68K to the Mac 128K, but the screen buffer was 32k (640x400) instead of the Mac's 21.9k (512x342). The ST's CPU was more than capable of copying 32k from location to location within a single screen redraw, so I imagine the same was true for the Mac, especially since it had to shift less data. In addition, there's no reason why o…

> I suspect the real reason for this weird resolution is boring memory constraints.

Things were indeed very tight

http://www.folklore.org/StoryView.py?story=MacPaint_Evolutio...

  At the worst case, there was only 
  about 100 bytes free in MacPaint's heap

Re: Why MacPaint's Original Canvas was 416 Pixels Wide

#23

Post by gaius »

kalleboo wrote: post #22
teamonkey wrote: post #16

I know 68k from the Atari ST, and the MOVEM.L trick was well known. The ST had a similar M68K to the Mac 128K, but the screen buffer was 32k (640x400) instead of the Mac's 21.9k (512x342). The ST's CPU was more than capable of copying 32k from location to location within a single screen redraw, so I imagine the same was true for the Mac, especially since it had to shift less data. In addition, there's no reason why o…

> I suspect the real reason for this weird resolution is boring memory constraints. Things were indeed very tight http://www.folklore.org/StoryView.py?story=MacPaint_Evolutio... At the worst case, there was only about 100 bytes free in MacPaint's heap

The finished MacPaint consisted of 5,804 lines of Pascal code, augmented by another 2,738 lines of assembly language, which compiled into less than .05 megabytes of executable code

To put that into perspective, the date command alone on this Linux box is 49k.

Re: Why MacPaint's Original Canvas was 416 Pixels Wide

#24

Post by colomon »

gaius wrote: post #23
kalleboo wrote: post #22

Earlier quoted context omitted.

> I suspect the real reason for this weird resolution is boring memory constraints. Things were indeed very tight http://www.folklore.org/StoryView.py?story=MacPaint_Evolutio... At the worst case, there was only about 100 bytes free in MacPaint's heap

The finished MacPaint consisted of 5,804 lines of Pascal code, augmented by another 2,738 lines of assembly language, which compiled into less than .05 megabytes of executable code To put that into perspective, the date command alone on this Linux box is 49k.

The one that breaks me is the Clock application on my Android phone is using 20.29 MB of the phone's memory at the moment. What could it possibly be doing to justify that?

Re: Why MacPaint's Original Canvas was 416 Pixels Wide

#25

Post by teamonkey »

klodolph wrote: post #17
teamonkey wrote: post #16

I know 68k from the Atari ST, and the MOVEM.L trick was well known. The ST had a similar M68K to the Mac 128K, but the screen buffer was 32k (640x400) instead of the Mac's 21.9k (512x342). The ST's CPU was more than capable of copying 32k from location to location within a single screen redraw, so I imagine the same was true for the Mac, especially since it had to shift less data. In addition, there's no reason why o…

> In addition, there's no reason why one MOVEM can't contain data from multiple rows. The screen buffer is 512x384 (24.5 KB, not 10.4 KB), so you have to copy one row at a time. The source and destination pointers have to increment by different amounts after each row (13 and 16 words, respectively). See the following lines in the article's assembly: ADD #52, A0 ADD screenRow, A1 screenRow must be defined to 64.

A fair point, although I think the M68K was fast enough to copy the remaining pixels with a few MOVE.L calls if need be.

[Edit] by which I mean, yes, you're right that the MOVEM can't cross line boundaries in this case, but the CPU should be fast enough to deal with longer lines by using a MOVEM and adding a few extra MOVEs to copy individual longwords. Shorter lines would simply require using fewer registers in the MOVEM.

Re: Why MacPaint's Original Canvas was 416 Pixels Wide

#27

Post by ChickeNES »

teamonkey wrote: post #16

I know 68k from the Atari ST, and the MOVEM.L trick was well known. The ST had a similar M68K to the Mac 128K, but the screen buffer was 32k (640x400) instead of the Mac's 21.9k (512x342). The ST's CPU was more than capable of copying 32k from location to location within a single screen redraw, so I imagine the same was true for the Mac, especially since it had to shift less data. In addition, there's no reason why o…

Actually, screen RAM on the original Mac is not contiguous. The last byte on each "line" is used to provide 8 bit PWM sound. As each line is drawn on the screen the last byte in that "line" is sent to the digital to analog convertor instead of to the rasterizer.
Post reply on HN