info-mac@uw-beaver (01/18/85)
From: olson@harvard.ARPA (Eric Olson) I don't see how the display on the Macintosh could slow it down (by 80%?!?!). Display memory doesn't take processor time: it may take longer to write to the display memory (by having the hardware shove wait states onto the bus). Assuming you aren't writing to the display, there ARE other things which slow the Mac down. The Vertical Blanking Interrupt updates the tickcount and cursor every 60th of a second, the SCC generates an interrupt on any received character and any mouse movement, and the VIA generates an interrupt on mouse movement. If you have a task that must execute at high speed and cannot be interrupted, you can turn off interrupts-- but it's not easy. You must re-vector a TRAP (68000 trap, not Mac Trap) to your code (in order to get into supervisor mode), execute the TRAP, set the interrupt level to 7 (no interrupts serviced), execute your routine, and (for completeness ) restore the TRAP vector. Note that the mouse won't work while this is happening, and the TickCount will not update (I think the clock still keeps good time, though). This code fragment does the trick: MOVE.L #$80,A0 ;TRAP 0 Vector Address MOVE.L (A0),D2 ;Save the old vector JSR CURLOC ;Call next instruction to get PC CURLOC: MOVE.L (SP)+,A1 ;Pop CURLOC off the stack ADD.L #14,A1 ;Add offset to BEGING MOVE.L A1,(A0) ;Change Trap vector TRAP #0 ;Execute trap BRA.S DONE ;Go back to calling routine BEGING: MOVE.W #2700,SR ;Set interrupt level 7, super mode . . ;Your code here . RTE ;Return from Exception DONE: MOVE.L #$80,A0 ;TRAP 0 Vector Address MOVE.L D2,(A0) ;Restore old vector RTS ;Return to caller Note: Since Mac code is relocatable, the PC is determined by JSR and POP off the stack. The #14 added to A1 is enough to change CURLOC to BEGING. I assume the code does not move during execution (a valid assumption). Ciao! Eric.
info-mac@uw-beaver (01/24/85)
From: Thomas.Newton@cmu-cs-spice.arpa
The display on the Mac does indeed slow the main processor down, though I
think it's more on the order of 45-50% when accessing only RAM, and about
25% overall if you use the Toolbox routines a lot.
Note that there is only one "row" of memory chips in either a 128K Mac (64K
bits/chip by 16 chips/word) or a 512K Mac (256K bits/chip by 16 chips/word).
Since these are not dual-ported RAMs, the processor and the display hardware
cannot access them simultaneously. Accessing "display memory" ties up ALL of
memory because "main memory" is on the same chips as "display memory".
The ROMs have their own private bus to the 68000, which is why the "average
speed" of the processor is higher if you use the Toolbox routines a lot. If
someone added extra RAM beyond 512K (or implemented the 512K as four "rows"
of 64K chips), it would probably be desirable to hook the extra memory up in
the same fashion as the ROMs.
-- Thomas Newton
Thomas.Newton@cmu-cs-spice.ARPAinfo-mac@uw-beaver (01/25/85)
From: kato.SV@XEROX.ARPA Do they use the same trick as on the Apple //? The 6502 operates at 1MHz and the RAM can be accessed at 2MHz. This allows the scanning hardware to access RAM wthout slowing the 6502 down (I believe that 1MHz is 6502 full speed). Is this possible on the Mac or is the 68000 too fast? Kato.sv@Xerox.ARPA
info-mac@uw-beaver (01/25/85)
From: Thomas.Newton@cmu-cs-spice.arpa
I think the Mac is set up in a way similar to the Atari 800. On the Atari,
the 6502 is run at 1.8 MHz, but the display hardware steals enough cycles to
make the effective rate ~ 1 MHz when running in text mode or 320 by 192 mode.
I believe the Lisa 1 ran at a clock speed of 5 MHz, so that it could use the
same trick as the Apple //.
-- Thomas.Newton@cmu-cs-spice.ARPA