jeff@eniac.seas.upenn.edu (Jeff White) (07/05/90)
In article <1990Jul4.003731.336@hellgate.utah.edu> tjones%peruvian.utah.edu@cs.utah.edu (Ray Jones) writes: > > Don't expect the new low-cost Macs before the late fall. Actually >they probably will not be available until the end of the year. The >new Macs should be released with system 7.0, and concurrently with the >new Apple II. Probably all in January... On a related note, does anyone know if the 68000 can address more than 4 Megs of RAM (ie. is the present 4 Meg limit with Pluses and SE's a 68000 limit or just the way Apple designed those systems)? With 7.0 requiring a minimum of 2 Megs of RAM, I'm wondering whether Apple might design their newer machines to be able to handle more than 4 Megs, since 4 Meg under 7.0 may not leave a lot of extra memory for MultiFinder applications. Jeff White jeff@eniac.seas.upenn.edu
daveo@Apple.COM (David M. O'Rourke) (07/05/90)
jeff@eniac.seas.upenn.edu.UUCP (Jeff White) writes: > On a related note, does anyone know if the 68000 can address more than 4 Megs >of RAM (ie. is the present 4 Meg limit with Pluses and SE's a 68000 limit or >just the way Apple designed those systems)? With 7.0 requiring a minimum of >2 Megs of RAM, I'm wondering whether Apple might design their newer machines to >be able to handle more than 4 Megs, since 4 Meg under 7.0 may not leave a lot >of extra memory for MultiFinder applications. The 68000 can address up to 16 megs of memory using it's 24-bit address bus. The 4 meg limitation is due to the way the Mac OS/Hard-ware addresses various I/O devices and the ROM's. I'm not positive, but I don't believe there is a straight forward way to make a 68000 mac address more than 4 megs of memory with out modification to the motherboard, and possibly changes through out the ROMs. I'm not a hardware person, and although I work at Apple I don't go down deep into the OS {in fact I'm not ever sure I have access to do so, I'm still a new person on the block.} so I'm not sure how deeply ingrained the memory map is to the OS. Hope this helps. -- daveo@apple.com David M. O'Rourke _______________________________________________________________________________ I do not speak for Apple in *ANY* official capacity.
magik@chinet.chi.il.us (Ben Liberman) (07/05/90)
In article <26708@netnews.upenn.edu> jeff@eniac.seas.upenn.edu.UUCP (Jeff White) writes: > > On a related note, does anyone know if the 68000 can address more than 4 Megs >of RAM (ie. is the present 4 Meg limit with Pluses and SE's a 68000 limit or >just the way Apple designed those systems)? If my memory (no pun intended ;-) serves me, the 68000 will directly address 16,777,216 bytes of ram, rom...whatever (24 bit address). The newer Motorola chips will address 4,294,967,296 (that's 4 Gigabytes - a 32 bit address) The 4 meg limit on SE's is just the way the board is designed (there are prob. memory upgrade mods. out there to get you more). The current Mac OS memory limitation of 8 meg. is a matter of Apple design. OS space (rom and hardware address?) were mapped to start at 8 meg. because, at the time, it was inconceivable that anyone could want more memory than that! Computers - Life in the fast lane -- ------------ ------------ ---------------------- Ben Liberman USENET magik@chinet.chi.il.us GEnie,Delphi MAGIK
austing@Apple.COM (Glenn L. Austin) (07/05/90)
jeff@eniac.seas.upenn.edu (Jeff White) writes: > On a related note, does anyone know if the 68000 can address more than 4 Megs >of RAM (ie. is the present 4 Meg limit with Pluses and SE's a 68000 limit or >just the way Apple designed those systems)? The problem is that the ROMs on the Plus and SE are located at the 4MB address location. Since the Memory Manager doesn't know how to handle non-contiguous RAM, 4MB is the limit on these machines. -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Communications Toolbox Hacker | - Jim Russell Racing School Instructors | | Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | | Internet: austing@apple.com |-------------------------------------------| | AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | | Bellnet: (408) 974-0876 | who else would want them? | -----------------------------------------------------------------------------
russotto@eng.umd.edu (Matthew T. Russotto) (07/05/90)
In article <1990Jul5.063108.14564@chinet.chi.il.us> magik@chinet.chi.il.us (Ben Liberman) writes: >The current Mac OS memory limitation of 8 meg. is a matter of Apple design. >OS space (rom and hardware address?) were mapped to start at 8 meg. because, >at the time, it was inconceivable that anyone could want more memory than that! Or at least it was to a certain apple.person who made a similar statement to the effect of "nobody will ever use all 16K of the Apple ][".... Come on, now, the IBMs and the Lisas of the time had more memory than the mac. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
gchow@ipsa.reuter.com (george chow) (07/05/90)
In article <42651@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >jeff@eniac.seas.upenn.edu (Jeff White) writes: > >> On a related note, does anyone know if the 68000 can address more than 4 Megs >>of RAM (ie. is the present 4 Meg limit with Pluses and SE's a 68000 limit or >>just the way Apple designed those systems)? > >The problem is that the ROMs on the Plus and SE are located at the 4MB >address location. Since the Memory Manager doesn't know how to handle >non-contiguous RAM, 4MB is the limit on these machines. But surely the newer Macs can handle non-contiguous RAM (the ci has got non-contiguous memory due to its onboard video, I believe). Why can't Apple just patch the Memory Manager as they've done before for other Managers? >----------------------------------------------------------------------------- >| Glenn L. Austin | "Turn too soon, run out of room, | >| Auto Racing Enthusiast and | Turn too late, much better fate" | >| Communications Toolbox Hacker | - Jim Russell Racing School Instructors | >| Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | >| Internet: austing@apple.com |-------------------------------------------| >| AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | >| Bellnet: (408) 974-0876 | who else would want them? | >----------------------------------------------------------------------------- George Chow
austing@Apple.COM (Glenn L. Austin) (07/06/90)
russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <1990Jul5.063108.14564@chinet.chi.il.us> magik@chinet.chi.il.us (Ben Liberman) writes: >>The current Mac OS memory limitation of 8 meg. is a matter of Apple design. >>OS space (rom and hardware address?) were mapped to start at 8 meg. because, >>at the time, it was inconceivable that anyone could want more memory than that! >Or at least it was to a certain apple.person who made a similar statement to >the effect of "nobody will ever use all 16K of the Apple ][".... >Come on, now, the IBMs and the Lisas of the time had more memory than the mac. Really? When did DOS out-of-the-box start using more than 640K?!? I also seem to remember another machine of the same time period that only allowed 512K (the original IBM PC/XT). No, nobody (myself included) expected that anyone other than ourselves would even BE ABLE to use more than xMB (where x is some arbitrary number ;-). -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Communications Toolbox Hacker | - Jim Russell Racing School Instructors | | Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | | Internet: austing@apple.com |-------------------------------------------| | AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | | Bellnet: (408) 974-0876 | who else would want them? | -----------------------------------------------------------------------------
tim@efi.com (Tim Maroney) (07/06/90)
jeff@eniac.seas.upenn.edu (Jeff White) writes: >>On a related note, does anyone know if the 68000 can address more than 4 Megs >>of RAM (ie. is the present 4 Meg limit with Pluses and SE's a 68000 limit or >>just the way Apple designed those systems)? In article <42651@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >The problem is that the ROMs on the Plus and SE are located at the 4MB >address location. Since the Memory Manager doesn't know how to handle >non-contiguous RAM, 4MB is the limit on these machines. Couldn't you do a software fix? At startup, tweak the MultiFinder pseudo-heap so that the ROM space is marked as allocated? This would fragment the MF heap, of course, but it seems as if it would allow the memory above the ROM to be used with only a small change in software. Naturally, no applications could straddle the gap, given the Memory manager limitations.
austing@Apple.COM (Glenn L. Austin) (07/06/90)
gchow@ipsa.reuter.com (george chow) writes: >But surely the newer Macs can handle non-contiguous RAM (the ci has got >non-contiguous memory due to its onboard video, I believe). Why can't Apple just >patch the Memory Manager as they've done before for other Managers? >George Chow The ci (as I recall) just makes a big "memory block" of the non-contiguous memory (1MB in bank A, 4MB in bank B), and just takes the RAM off the top for video. So, the Memory Manager is happy (it's got "contiguous" memory) and the user is happy. The problem with simply patching the Memory Manager is that almost everything in the Mac is piped through the Memory Manager at one time or another... -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Communications Toolbox Hacker | - Jim Russell Racing School Instructors | | Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | | Internet: austing@apple.com |-------------------------------------------| | AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | | Bellnet: (408) 974-0876 | who else would want them? | -----------------------------------------------------------------------------
amanda@mermaid.intercon.com (Amanda Walker) (07/06/90)
In article <1990Jul5.204534.14336@efi.com>, tim@efi.com (Tim Maroney) writes: > Couldn't you do a software fix? At startup, tweak the MultiFinder > pseudo-heap so that the ROM space is marked as allocated? Nice idea, but as I remember, the Mac Plus/SE hardware doesn't do full address decoding above the 4M boundary. Normally, all this means is that the ROM image and I/O spaces are duplicated throughout the upper parts of the processor's address space. However, if you wanted to put more RAM in, you'd have to intercept the processor's address lines before they hit the normal decoding hardware (by moving the 68000 to a daughterboard, for example). If you're going to go to all that trouble, you may as well map the ROM and I/O out of the way while you're at it... The "make the ROMs an unrelocatable block in the heap" idea *is* quite clever, though. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation -- "I can only assume this is not the first-class compartment." --Hitchhiker's Guide to the Galaxy
daveo@Apple.COM (David M. O'Rourke) (07/07/90)
tim@efi.com (Tim Maroney) writes: >Couldn't you do a software fix? At startup, tweak the MultiFinder >pseudo-heap so that the ROM space is marked as allocated? This would >fragment the MF heap, of course, but it seems as if it would allow the >memory above the ROM to be used with only a small change in software. >Naturally, no applications could straddle the gap, given the Memory >manager limitations. For more information on this topic you can see pages 200-204 in "Technical Introducation to the Macintosh Family." Althought that suggestion would work if all we had to contend with was the ROMs. But the 680x0 family is a memory mapped processor so the orginal Mac HW design put the SCC in $80,000 page, and the IWM and VIA are in the last $C0,000 page. So above rom you have 2 4 meg pages for I/O devices and such. It's unclear from the documentation as to why these address spaces are so large, and if we actually need them to be that large. But for now that's the way the hardware likes it, and I'm not sure it's a simply software fix to change this memory map design. Hope this helps. -- daveo@apple.com David M. O'Rourke _______________________________________________________________________________ I do not speak for Apple in *ANY* official capacity.
ccw@nvuxr.UUCP (christopher wood) (07/13/90)
In article <1990Jul5.063108.14564@chinet.chi.il.us> magik@chinet.chi.il.us (Ben Liberman) writes: >If my memory (no pun intended ;-) serves me, the 68000 will directly address >16,777,216 bytes of ram, rom...whatever (24 bit address). The newer Motorola >chips will address 4,294,967,296 (that's 4 Gigabytes - a 32 bit address) >The 4 meg limit on SE's is just the way the board is designed (there are prob. >memory upgrade mods. out there to get you more). Same with a plus, if anyone cares. The motherboard was laid out for 4 SIMMs, either 256K or 1 M SIMMs. Give them credit for thinking ONE generation ahead... >The current Mac OS memory limitation of 8 meg. is a matter of Apple design. >OS space (rom and hardware address?) were mapped to start at 8 meg. because, >at the time, it was inconceivable that anyone could want more memory than that! This was a design decision made on the origional 128K Macintosh. The 68000 had 24 bit address (16 M addresses), (Hmm, doesn't the processor also have 16 bit data paths, so that it could address 32 M 8-bit bytes?) so they divided the address map in half, with the lower 8 M for RAM, and the upper 8M for ROM, IO, etc. >Computers - Life in the fast lane > ------------ ------------ ---------------------- > Ben Liberman USENET magik@chinet.chi.il.us > GEnie,Delphi MAGIK -- Chris Wood Bellcore ...!bellcore!nvuxr!ccw or nvuxr!ccw@bellcore.bellcore.com
bayes@hpislx.HP.COM (Scott Bayes) (07/18/90)
> This was a design decision made on the origional 128K Macintosh. The > 68000 had 24 bit address (16 M addresses), (Hmm, doesn't the processor > also have 16 bit data paths, so that it could address 32 M 8-bit bytes?) Nope. It only has 23 address lines, and 2 auxiliary lines called BUDS and BLDS (Byte Upper/Lower Data Strobe). The 23 address lines decode 16M _words_, and BUDS provide upper or lower byte, or word access. > so they divided the address map in half, with the lower 8 M for RAM, and > the upper 8M for ROM, IO, etc. > > -- > Chris Wood Bellcore ...!bellcore!nvuxr!ccw > or nvuxr!ccw@bellcore.bellcore.com Scott Bayes Hewlett-Packard Co
daveh@cbmvax.commodore.com (Dave Haynie) (07/20/90)
In article <1782@nvuxr.UUCP> ccw@nvuxr.UUCP (22456-christopher wood) writes: >In article <1990Jul5.063108.14564@chinet.chi.il.us> magik@chinet.chi.il.us (Ben Liberman) writes: >The 68000 had 24 bit address (16 M addresses), (Hmm, doesn't the processor >also have 16 bit data paths, so that it could address 32 M 8-bit bytes?) The 68000, like all of the 680x0 family, are address memory in terms of bytes, not words. So the 16M of address space handles 16M 8-bit bytes. This design allows characters to be handled as first class objects (play with a DEC-20 for awhile to see what happens with characters on word-addressed machines), and it makes the actual data bus width an implementation detail. The actual 68000 chip provides 23 address lines (A1-A23), plus two data strobes (UDS*, LDS*) which serve to select the byte(s) of interest out of a word. The 68020 and 68030 have a much more sophisticated mechanism for addressing data. >Chris Wood Bellcore ...!bellcore!nvuxr!ccw > or nvuxr!ccw@bellcore.bellcore.com -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM