dlyons@Apple.COM (David Lyons) (08/24/89)
In article <8908212244.aa15584@SMOKE.BRL.MIL> SEWALL@UCONNVM.BITNET (Murph Sewall) writes: >[...] UNLESS (to improve performance) applications routinely copy the Rev 3 >ROM into the RAM space it would occupy in a Rev 1 machine. That (if I >grasp the concept I only read about last week) is the "shadow RAM" >technique some PC clone vendors are using to improve performance. In the >MS-DOS World RAM is faster memory than ROM; is that true of the IIgs? Nope. In the GS, running from ROM is actually faster than running from RAM. (So copying the ROM into RAM wouldn't help, even if it were not a no-no of mammoth proportions, which it is, and even if it would work, which it won't.) (Why? About 8% of the time, RAM is getting refreshed. If you're *running* from RAM, you have to stop and wait for it. If you're running from ROM, you don't. This explanation is missing some details, but the idea is there.) >[...] the "shadow RAM" technique makes sense in a IIgs, would an application be >able to tell the difference between a Rev 1 and Rev 3 machine? Applications *can* tell the difference between the ROM versions, but hardly any will actually bother. We don't generally *want* applications to care which machine they're on. (For completeness, here's how to check: Use the IDROUTINE routine at $FE1F to get the ROM version. From the 16-bit world, you can use the Misc. Toolset function FWEntry to call IDROUTINE.) --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
brianw@microsoft.UUCP (Brian Willoughby) (08/26/89)
In article <34254@apple.Apple.COM> dlyons@Apple.COM (David Lyons) writes: >In article <8908212244.aa15584@SMOKE.BRL.MIL> SEWALL@UCONNVM.BITNET (Murph Sewall) writes: >>[...] UNLESS (to improve performance) applications routinely copy the Rev 3 >>ROM into the RAM space it would occupy in a Rev 1 machine. That (if I >>grasp the concept I only read about last week) is the "shadow RAM" >>technique some PC clone vendors are using to improve performance. In the >>MS-DOS World RAM is faster memory than ROM; is that true of the IIgs? > >Nope. In the GS, running from ROM is actually faster than running from >RAM. (So copying the ROM into RAM wouldn't help, even if it were not a >no-no of mammoth proportions, which it is, and even if it would work, >which it won't.) > >(Why? About 8% of the time, RAM is getting refreshed. If you're *running* >from RAM, you have to stop and wait for it. If you're running from ROM, >you don't. This explanation is missing some details, but the idea is there.) > > > --Dave Lyons, Apple Computer, Inc. | DAL Systems The only reason that is true, Dave, is that currently the GS is not running anywhere near the limits of RAM access speeds. If it was, then the ROM access speed would be more of a speed limiting factor. This may not be true of the latest and greatest ROMs, but in my experience the fastest RAMs are much faster (even pausing for refresh) than ROM. As an example, when my II+ is running at 3.58 MHz, the ROMs are much slower than the 120 nsec RAMs, and that's why AE uses ROM shadowing on their TransWarp. An 8 MHz 65C816 (which I benchmarked as equivalent to a 16 MHz 68000, for my best code on each processor) might run faster from RAM than from ROM. And 10 MHz 65C802s are easily available (I have one) these days. I believe that the TransWarp GS has to cache the ROM (i.e. copy recent accesses to ROM into RAM) to achieve its full speed. And since everyone keeps comparing the speed of the GS to other 68000 or 80x86 CPUs, I thought I would add this: The 65xxx doesn't need to be clocked as fast to get the same amount of computing done as an 80x86. The 68000 and 8086 eat 4 cycles reading a memory address, and the newer 80x86s eat 3 or 2 cycles (the 80386 takes the fewest, of course). Compare this to 1 cycle for the 65xxx. This means that a slower 65xxx is an awful lot closer to the limits of today's RAM access speeds than a faster uP from "the other guys". Of course, this 4 times factor (between a 68000 and 65816) is somewhat misleading. The plus for the 65xxx is that its instructions take much fewer cycles to complete. The drawback is the 8 bit bus, and that you can't operate on 32 bit data (yet). Moral: don't wait for Apple to come out with a 33 MHz Apple II, it would run circles around a 33 MHz PC (if you could find fast enough RAM :-) Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP Microsoft no longer cares about the Apple II, why should they care what I say about the Apple II?
bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) (08/28/89)
Brian, you say that 10MHz 65C802s are EASILY available. Aren't 65C816s and 65C802 almost EXACTLY the same internally? If so, why is it that 10MHz 65C816s aren't readily available? I guess one possible answer to that is that fewer people are looking for the 65C802s...but then, who's buying up all the 10MHz 65C816s? AE is still just using the 6 and 7 MHz versions... Hmmm...I have also have a question about how the imporvements on newer 16 and 32 bit versions of the 65 series will work, if they ever come into existance. Will WDC ever change the clock cycles that a basic 65XXX chip in 6502 emul mode will take to do an instruction? If not (I can see a lot of arguments against it), will they remeain the same in emul mode, but possibly be improved in native mode using the same instruction? Also, since most of the one byte instructions are used up, how are new instructions going to work? Will WDC use a two byte system, or will they create a whole new set of one (and possibly two) byte instructions when in native mode? Thanks! Brendan
brianw@microsoft.UUCP (Brian Willoughby) (08/30/89)
In article <8YyJ4KW00WB3Q7MFhy@andrew.cmu.edu> bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) writes: >Brian, you say that 10MHz 65C802s are EASILY available. Aren't 65C816s and >65C802 almost EXACTLY the same internally? If so, why is it that 10MHz >65C816s aren't readily available? > >I guess one possible answer to that is that fewer people are looking for >the 65C802s...but then, who's buying up all the 10MHz 65C816s? You answered your own question, at least partially. Regarding who is buying 65C8xx's, I just asked Western Design myself when I ordered the 10 MHz 65C802. Their response was that the 65C816, and several of their other 6502 spinoffs, all CMOS, are used in biomedical applications because of the low power CMOS, and also in embedded controllers and communications devices. I wish she had gone into more detail. She promised to send more info, and I recieved a wad of data on several juicy stand-alone 6502 supersets, complete with built-in serial ports, parallel ports, RAM and ROM. But, alas, no list of company names who use W65C8xx's. >AE is still just using the 6 and 7 MHz versions... I wish AE would at least come out with a 65C816 TransWarp for the Apple II Plus - sort of a mix of their 65816 option for thier memory expansion card and the accelerator. 7 MHz or so would be fine, especially considering high speed DRAM prices (or the alternative - cache RAM - which is also expensive once you get the whole cache system set up). >Hmmm...I have also have a question about how the imporvements on newer 16 and >32 bit versions of the 65 series will work, if they ever come into existance. >Will WDC ever change the clock cycles that a basic 65XXX chip in 6502 >emul mode will take to do an instruction? If not (I can see a lot of arguments >against it), will they remeain the same in emul mode, but possibly be improved >in native mode using the same instruction? My guess is that WDC will not change the 6502 Emulation mode. They have already gone to great pains to make a step "backward" in compatibility when compared to the 65C02. This is regarding the RDY input to the 6502, where the W65C802 is more 6502 compatible than the 65C02. I think they have good reasons for this. Probably that the companies mentioned above need exact 6502 emulation to boot WDC's newer processors on their existing boards. The 6502 and its spinoffs are fairly popular. I interviewed for a job in NC doing 6502 programming for a security safe that had a 6502 based computer inside. The safe was intended for important documents, and would mark the contents with traceable dye if the allotted time to reach the bank deposit from the company site expired (i.e. if someone stole it and left town). >Also, since most of the one byte instructions are used up, how are new >instructions going to work? Will WDC use a two byte system, or will they >create a whole new set of one (and possibly two) byte instructions when in >native mode? Your guess is as good as mine, perhaps there will be two modes with 255 new single byte opcodes when in the 32 bit mode. If they do use 2 byte opcodes, though, I would like to see improved code prefetching. >Thanks! >Brendan Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP