boris@world.std.com (Boris Levitin) (10/31/90)
kr1@bushido (kahlil rowter) writes: >I have been using MacMeter for a while now. I've noticed that my SE/30 >typically spends 50-70% of the time on ROM accesses (no surprise here >right?). So I thought of the ability of 386 (DOS) machines to load its >ROM in RAM thereby cutting down access time and improving overall thruput. >Now comes the hard question: Has there been attempts to load the Mac ROM >onto RAM? If not, why? The posession of accesible Mac ROMs or a software copy of them (i.e. loadable into RAM) is all that stands between someone with a non-Mac 68000-series-based machine and Mac emulation. As far as I understand, some owners of the A-Max II Mac emulator on the Amiga, which requires either the ROMs or a software copy of them, have software copies of the Mac ROMs. I believe Apple's license for the ROMs makes it illegal to copy their contents into software...
ts@cup.portal.com (Tim W Smith) (10/31/90)
Code on the Mac executes at least as fast out of ROM as it does out of RAM for many Macintoshes (all?). On PCs, the ROM is often 8 bits wide (the 80x86 processors don't have any alignment requirements, so can handle 8 bit ROMs). Copying the 8 bit ROM to 32 bit RAM lets the PC go much faster. Tim Smith
mystone@mondo.engin.umich.edu (Dean Yu) (11/01/90)
In article <1990Oct31.032509.265@bushido.uucp> kr1@bushido (kahlil rowter) writes: >I have been using MacMeter for a while now. I've noticed that my SE/30 >typically spends 50-70% of the time on ROM accesses (no surprise here >right?). So I thought of the ability of 386 (DOS) machines to load its >ROM in RAM thereby cutting down access time and improving overall thruput. >Now comes the hard question: Has there been attempts to load the Mac ROM >onto RAM? If not, why? > On the Macintosh, ROM is at least as fast as RAM, probably faster, so that's one reason not to bother. Then there is the size of the ROM. If you copied the ROM into RAM, you'd suck up anywhere between 128K to 512K of your memory. (Not that it really matters these days, but I like lots of free RAM.) The last reason, and probably the most important is that this would break every single come-from patch, since they check the return address on the stack, and of course, moving ROM to RAM would cause these return addresses to change. _______________________________________________________________________________ Dean Yu | E-mail: mystone@mondo.engin.umich.edu Patches 'R' Us | Real-mail: Dean Yu A Division of Cyberite Systems | 909 Church St Apt C | Ann Arbor, MI 48104 I'm not the voice of Reason, much | Phone: 313 662-4073 less the voice of Cyberite. | 313 662-4163 -------------------------------------------------------------------------------
Garance_Drosehn@mts.rpi.edu (Garance Drosehn) (11/01/90)
In article <1990Oct31.162230.3292@engin.umich.edu> mystone@mondo.engin.umich.edu (Dean Yu) writes: > On the Macintosh, ROM is at least as fast as RAM, probably faster, so > that's one reason not to bother. Then there is the size of the ROM. If > you copied the ROM into RAM, you'd suck up anywhere between 128K to 512K > of your memory. (Not that it really matters these days, but I like lots > of free RAM.) > The last reason, and probably the most important is that this would break > every single come-from patch, since they check the return address on the > stack, and of course, moving ROM to RAM would cause these return > addresses to change. Well, you have to be wrong on that last point, because I have an accelerator that does just want the original poster talked about. It copies the ROM's into RAM at startup time (eating up a chunk of RAM), and everything works perfectly fine. The CDEV for the accelerator (an Irwin Magnetics XL25) has this as an option, so if something didn't work you can turn it off. I've never tripped across a bug where turning this off (and rebooting) made any difference. I don't have a clue how they do it, of course, but it is done. Perhaps they do some special trick to work with the patches you mention. On the accelerator this trick of copying ROM into RAM makes sense, because it's using the ROM's from a plain SE, but the accelerator is running a 25Mhz 68020 with 70ns memory in it. Copying the ROM into RAM does speed things up in that case. I doubt it would make any difference for a regular (non-accelerated) Mac. And since you have to have an official Apple ROM in the machine for this to work, it isn't any problem legally. Garance_Drosehn@mts.rpi.edu ITS Systems Programmer Rensselaer Polytechnic Institute; Troy, NY. USA
russotto@eng.umd.edu (Matthew T. Russotto) (11/01/90)
In article <1990Oct31.032509.265@bushido.uucp> kr1@bushido (kahlil rowter) writes: >I have been using MacMeter for a while now. I've noticed that my SE/30 >typically spends 50-70% of the time on ROM accesses (no surprise here >right?). So I thought of the ability of 386 (DOS) machines to load its >ROM in RAM thereby cutting down access time and improving overall thruput. >Now comes the hard question: Has there been attempts to load the Mac ROM >onto RAM? If not, why? Theoretically, RAM could be mapped into ROM space using the PMMU built into the 030-- I don't know if you would gain any access time, and you would lose a few pages of RAM. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu Tax the rich, and feed the poor -- until there are, rich no more.
davids@mondo.engin.umich.edu (David Snearline) (11/01/90)
First of all, I believe that Dean Yu was correct in that where the calls are made from make a big difference. Ever wonder why the Technotes say "No tailpatches!"? It's because of the fact that the routines do sometimes try to figure out where they have been called from. However, my guess is that Accellerator boards compensate for this -- not hard to do. Just make sure the addresses look right. Second, I have a friend who just designed his own upgrade for the Mac, and he explained how the ROM/RAM situation worked on the earlier Macs. Apparently, the ROM's went much faster on the original Macs because the RAM had to slow down for the video display. Whenever the access was in ROM, the CPU accessed it full speed since it didn't have to worry about the display attempting to access the ROM... --- davids -- David Snearline Computer Aided Engineering Network davids@mondo.engin.umich.edu University of Michigan Engineering
boris@world.std.com (Boris Levitin) (11/01/90)
francis@arthur.uchicago.edu (Francis Stracke) writes: >In article <1990Oct31.084937.28930@world.std.com> boris@world.std.com (Boris Levitin) writes: >>kr1@bushido (kahlil rowter) writes: >> >>>I have been using MacMeter for a while now. I've noticed that my SE/30 >>>typically spends 50-70% of the time on ROM accesses (no surprise here >>>right?). So I thought of the ability of 386 (DOS) machines to load its >>>ROM in RAM thereby cutting down access time and improving overall thruput. >>>Now comes the hard question: Has there been attempts to load the Mac ROM >>>onto RAM? If not, why? >> >>The posession of accesible Mac ROMs or a software copy of them (i.e. loadable >>into RAM) is all that stands between someone with a non-Mac 68000-series-based >>machine and Mac emulation. As far as I understand, some owners of the A-Max II >>Mac emulator on the Amiga, which requires either the ROMs or a software copy >>of them, have software copies of the Mac ROMs. I believe Apple's license for >>the ROMs makes it illegal to copy their contents into software... >Now wait a minute. Obviously, I have the right to read the ROMs (one >observes that this is the sole purpose of ROM :-). Obviously, when the >ROMs are read, the data goes *somewhere*. In fact, it goes into other >silicon. This silicon is writeable (the data went there), and readable >(we expect to get the data out of there). Therefore, this silicon is >RAM, whether it's the transient RAM on the CPU or the slightly longer- >term RAM in the dedicated RAM chips. Therefore I have the right to >copy ROM to RAM under some conditions. A reasonable condition here would >be that the RAM is in the same machine as the ROM, & not accessible to >any other machine. (A stronger condition would exclude the RAM chips; >but they are merely extensions of the CPU's internal memory. In a machine >designed to cache slow ROM in very fast, but still external, RAM, there >would be no reasonable distinction.) Thus, if I copy ROM to main RAM >within the same machine, remaining unable to give the data to any other >machine, Apple's rights have been maintained (though, admittedly, perhaps >not their license). >The basic point here is that, if I buy a Mac, I gain the right to use it >as I will. If I attempt to steal Apple's code, I have violated patent; >but copying it into RAM would not infringe that patent, because I have >not gained anything *except* the improved use of the machine I bought. >Surely I have the right to improve my Mac in this way! >The whole thing would be quite straightforward if *Apple* would come >out with a product to do this. Yes, you would be within your moral and possibly even legal rights if you copied your ROM into RAM for your own use. Besides, even if you were in violation of Apple's license by doing this, it would be unenforceable. I was trying to point out why Apple didn't make such copying any easier (besides, the more hardware-knowledgeable people on this group are pointing out that on a Motorola CPU-powered machine, there's no advantage to such copying).
jack@Taffy.rice.edu (Jack W. Howarth) (11/01/90)
Actually, putting the ROMs into RAM would not be that hard. The ROMs contain
routines accessed by A-trap calls which vector into ROM so all those would
require is for you to reset the A-trap table by whatever amount of memory
you have moved the ROMs by to map them into RAM. Those parts of ROM that
contain resources other than trap routines (dialog boxes, etc.) would have
to be handled a bit differently.
Jackjack@Taffy.rice.edu (Jack W. Howarth) (11/01/90)
The main use for copying the ROMs into RAM so far has been to allow the
accelerators for the Plus/SE to execute the ROM calls on a high speed
32 bit data/instruction bus. It is just as easily done for the SE/30 but
would not serve much of a purpose as the SE/30 already has taken the video
RAM and separated from the main RAM so that no clock cycles are needed for
the display to be refreshed (unlike the SE and Plus...)
Jackbayes@hpislx.HP.COM (Scott Bayes) (11/06/90)
To map RAM into ROM addresses doesn't require a PMMU. As long as your accelerator card (and the internal Mac bus) has the capability to disable the ROM and the ability to make the RAM segment respond to addressing at the ROM addresses, it's easy. If you can drive the "chip enable/disable" line to the ROMs, part one is solved, and part 2 is easy, if you use a soft-loadable address decoder on the accelerator board RAM. This should solve all come-from problems, etc, rather cheaply. Scott "not really a H/W hack, but seen it before" Bayes
jack@Taffy.rice.edu (Jack W. Howarth) (11/07/90)
Scott,
Why bother with hardware at all. Aren't all the ROM calls done by A-traps?
In that case, you just point the trap table entries to RAM locations instead
of ROM addresses.
Jack