11–20 of 27 posts
Earlier quoted context omitted.
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
Brings 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
One of the biggest advantages over the 6502 was the ability to work with 16-bit registers. X and Y were 16 bit, and a user/local stack pointer was added, U. Even the A and B accumulators could be combined into one 16-bit register, D.
It's one of my favorite architectures. You could do a hell of a lot with very little room.
I 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.
http://software.intel.com/en-us/forums/topic/275765
Even more recently (Nehalem and beyond), they really started paying attention to optimising this instruction, so that even the byte/word variants will copy entire cache lines at once if possible.
http://stackoverflow.com/questions/8858778/why-are-complicat...
(IMHO the 2nd answer to that question should really have been chosen, since the 1st answer would be closer to reality a decade or two ago.)
I 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.
Here is LM and STM used in an IBM assembler calling convention: http://en.wikipedia.org/wiki/IBM_Basic_assembly_language_and...
In addition, there's no reason why one MOVEM can't contain data from multiple rows. For a 640x400 buffer like you find in the ST, each row requires approximately 1.5 MOVEM commands. No problem, since your buffer will have access to contiguous memory. Your second MOVEM call will copy the last half of the 1st row and the first half of the 2nd. Your buffer has to have a horizontal size that is a multiple of 32 pixels, but not 416.
I suspect the real reason for this weird resolution is boring memory constraints. If I'm reading the 68K code correctly, a MacPaint buffer was 416x200 - 10.4k. According to Wikipedia[1] MacPaint used 2 off-screen buffers = 20.8k. The ROM is 68k, then there's probably at least 1 system-reserved screen buffer of 10.4k. The OS has to fit in somewhere. That's quite a lot for a 128K machine.
Find the most comfortable painting layout where the horizontal canvas size is a multiple of 32 pixels and 2 buffers fit within 21k.
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…
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
http://blog.moertel.com/posts/2013-12-14-great-old-timey-gam...
(above ran on HN a couple weeks back)