Why MacPaint's Original Canvas was 416 Pixels Wide
looksgoodworkswell.com
Why MacPaint's Original Canvas was 416 Pixels Wide
1–10 of 27 posts
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#2Except it didn't because there are 14. Unsurprisingly it was aesthetics.
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#3Brings back memories of writing 68K assembly, back in the day when writing raw was the difference between screaming fast and dog slow. 6502 was even more fun.
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#4Except it didn't because there are 14. Unsurprisingly it was aesthetics.
One was reserved for the stack pointer, so 13*32=416.
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#5Except it didn't because there are 14. Unsurprisingly it was aesthetics.
One was reserved for the stack pointer, so 13*32=416.
Thanks. This is close but off then: The drawing area is evenly divisible by 13 long words (13x32=416). This is exactly the number of registers that were available in the loop above for the MOVEM.L operation (It appears it could have used 14 registers, but I am guessing the extra 32 pixels would have made the drawing area more cramped by reducing the gray whitespace.
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#6Earlier quoted context omitted.
One was reserved for the stack pointer, so 13*32=416.
Thanks. This is close but off then: The drawing area is evenly divisible by 13 long words (13x32=416). This is exactly the number of registers that were available in the loop above for the MOVEM.L operation (It appears it could have used 14 registers, but I am guessing the extra 32 pixels would have made the drawing area more cramped by reducing the gray whitespace.
MOVEM.L can address all 16 registers on the 68K but keeping the source and destination pointers in the register bank made the routine run much quicker. You also need SP to get back home, so 13 was all Hertzfeld could use.
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#7I wonder if MOVEM was inspiration for ARM's (V)LDM/STM instructions?
x86 has provided an optimised memory copy instruction ever since the 8086: REP MOVS. The history and evolution of this instruction has quite an interesting story from a CPU architecture perspective.
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#8I wonder if MOVEM was inspiration for ARM's (V)LDM/STM instructions? x86 has provided an optimised memory copy instruction ever since the 8086: REP MOVS. The history and evolution of this instruction has quite an interesting story from a CPU architecture perspective.
> The history and evolution of this instruction has quite an interesting story from a CPU architecture perspective.
I'd love to read about that if you have any references. I've used the MOVS instructions a million times without really thinking about them much.
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#9Brings back memories of writing 68K assembly, back in the day when writing raw was the difference between screaming fast and dog slow. 6502 was even more fun.
The 6502 was fun and it was the first assembly I programmed[1]. The 6809 also deserves a look if anyone is reviewing old instruction sets / assembly code. I am still not sure which of the three I preferred.
1) on an Apple II, sadly not on my Atari 400
Re: Why MacPaint's Original Canvas was 416 Pixels Wide
#10Earlier quoted context omitted.
Thanks. This is close but off then: The drawing area is evenly divisible by 13 long words (13x32=416). This is exactly the number of registers that were available in the loop above for the MOVEM.L operation (It appears it could have used 14 registers, but I am guessing the extra 32 pixels would have made the drawing area more cramped by reducing the gray whitespace.
MOVEM.L can address all 16 registers on the 68K but keeping the source and destination pointers in the register bank made the routine run much quicker. You also need SP to get back home, so 13 was all Hertzfeld could use.
> Hertzfeld
Atkinson