Difference Between Apple /// & IIGS?

[Mac128]

I'm a little confused. I read that the Apple /// was intended to eventually replace the Apple II line, but allowed limited Apple II+ "emulation" to encourage users to switch, but inhibit further expansion on the platform. Bad move on Apple's part. Now the Apple /// used the 6502B chip, a faster variant of the Apple II's 6502, but still basically the same 8-bit 6502 processor at the heart of the II. So where exactly did the "emulation" come into play? It seems to me, the /// ran Apple II software no differently than on an Apple II+. I understand one was required to boot into the Apple II mode, likely very similarly to the way one must boot into Boot Camp in order to run Windows on an Intel Mac. Likewise, not all of the Mac hardware is available to the PC, but otherwise, Windows runs on the Intel chip natively. At least that's how it all looks to me.

Now we come to the Apple IIGS. This computer used and entirely different 65802 16-bit processor at its heart. Yet, the Mega II chip allowed Apple II software to access all of the IIGS features, while the 16-bit processor emulated the 8-bit routines of its 6502 predecessor. Fortunately Apple chose to allow the emulation mode to run simultaneously with the 16-bit GS-OS processes so Apple II users could potentially take advantage of everything the new hardware had to offer. Yet, the Apple II software did not run natively on the 65802, so this is true emulation, not an actual Apple II. It strikes me as the same thing as Classic under OS X, where the PPC emulates the 68K instructions, but otherwise has access to all of the hardware enhancements the latest technology offers.

Interestingly, the Apple IIe card, unlike the IIGS had an actual 65C02 chip on it, along with the Mega II chip, so aside from shared hardware with the Mac, it was essentially an Apple II, and like the Apple ///, one could only use the Mac or the Apple II, not both at once, unlike on the IIGS, though it had access to virtually all of the Mac's hardware.

So, back to my original question: does the Apple /// actually have more in common with a real Apple II than the IIGS which carries the Apple II name? In other words, if one never used the features of the Apple ///, wouldn't it run identically to an Apple II, right down to the same processor? Granted at the time, the Apple /// was priced a little high to be little more than an Apple II+, however, it did come with a built-in drive. Otherwise, what was the actual difference? Wasn't "emulation" a term that in fact only meant the /// limited the available hardware, thereby emulating the fewer functions of the Apple II+?

The IIGS by comparison handled everything in emulation, and while one could use it as an Apple II only, that's like saying a PPC is a Macintosh II because it can execute 68000 code and one could use it only as a Macintosh II if they wished.

So I would appreciate thoughts ...

 

[david__schmidt]

I'm a little confused. I read that the Apple /// was intended to eventually replace the Apple II line, but allowed limited Apple II+ "emulation" to encourage users to switch, but inhibit further expansion on the platform. Bad move on Apple's part. Now the Apple /// used the 6502B chip, a faster variant of the Apple II's 6502, but still basically the same 8-bit 6502 processor at the heart of the II. So where exactly did the "emulation" come into play?

The hardware, specifically memory control and several other I/O aspects were different on the /// than the II. The emulation code (actually collaboration between hardware and software) conspired to make the machine look, feel, and smell like a 48k II+ with several of the hardware resources marshalled - like the internal drive was mapped to "slot" 6, the serial port was mapped to "slot" 7, and so on, even though the /// only had four physical slots.

It seems to me, the /// ran Apple II software no differently than on an Apple II+. I understand one was required to boot into the Apple II mode, likely very similarly to the way one must boot into Boot Camp in order to run Windows on an Intel Mac. Likewise, not all of the Mac hardware is available to the PC, but otherwise, Windows runs on the Intel chip natively. At least that's how it all looks to me.

That's actually a pretty good assessment.

Now we come to the Apple IIGS. [...] It strikes me as the same thing as Classic under OS X, where the PPC emulates the 68K instructions, but otherwise has access to all of the hardware enhancements the latest technology offers.

I suppose this could be considered emulation, but it is all really handled in hardware. So, not quite the same as the Classic situation.

So, back to my original question: does the Apple /// actually have more in common with a real Apple II than the IIGS which carries the Apple II name?

The /// was closer technologically (and temporally) to the II than the GS, not just down to the instruction set of the CPU.

In other words, if one never used the features of the Apple ///, wouldn't it run identically to an Apple II, right down to the same processor?

Well, yes, but some hardware chicanery is going on to make it appear identical to an Apple II.

Granted at the time, the Apple /// was priced a little high to be little more than an Apple II+, however, it did come with a built-in drive. Otherwise, what was the actual difference?

Big hunks of bank-switched memory. More CPU speed. Flexibility to be both a II and a ///. A numeric keypad. Cursor control buttons that moved the cursor faster if you pressed them harder. (Seriously.)

Wasn't "emulation" a term that in fact only meant the /// limited the available hardware, thereby emulating the fewer functions of the Apple II+?

I suppose you could look at it that way. It marshalled /// resources in a way that made them appear like a II.

Some thoughts from another forum:

"What's the difference betwee Apple II+.IIGS. IIe, IIc. and ///?"

 

[luddite]

Cursor control buttons that moved the cursor faster if you pressed them harder. (Seriously.)

I never knew that... it's bloody ingenious!

 

[Mars478]

Cursor control buttons that moved the cursor faster if you pressed them harder. (Seriously.)

I never knew that... it's bloody ingenious!

I would pay to add that feauture to todays Macs.

 

[david__schmidt]

Cursor control buttons that moved the cursor faster if you pressed them harder. (Seriously.)

I never knew that... it's bloody ingenious!

I would pay to add that feauture to todays Macs.

It really is a very Jobsian/Mac-esque feature. Kind of like the "breathing" light on my iMac when it falls asleep. One of those little creature comforts that is subtle, but sets it apart.

 

[waynestewart]

The Apple III was meant to be a business machine. There was software that allowed it to emulate an Apple II but you couldn't run Apple II software without first running that emulation software. So in some ways that made it more like an Apple II emulator on a Mac or PC. A IIgs will directly boot apple II software. Actually an Apple III won't run a lot of Apple II software. It won't run anything that needs more than 48k RAM or 80 column or does a lot of hardware pokes. So a lot of games and some other software wouldn't run on it but almost all would on a IIgs.

When the IIgs was due to come out a lot of people bought 65802s for their Apple II. Almost all were people that wanted to learn to program for the IIgs There's only a couple of Apple II programs that'll utilize a 65802. Sort of a pity but understandable.

 

[barana]

the IIgs didn't use a 65802, but a 65c816. when a iigs ran 6502 software is wasn't emulation, but running on a real 6502. _inside_ the 65816. the '816 is register compatible with the '02. The extra sixteen bit functions are tacked on to the end of the 6502 register set in the '816. so it runs all of the old software. full speed or double speed.

 

[Mac128]

There was software that allowed it to emulate an Apple II but you couldn't run Apple II software without first running that emulation software. So in some ways that made it more like an Apple II emulator on a Mac or PC. A IIgs will directly boot apple II software. Actually an Apple III won't run a lot of Apple II software. It won't run anything that needs more than 48k RAM or 80 column or does a lot of hardware pokes.

Actually, it may seem like it is an Apple II "emulator" because of the way it behaves, but clearly it is NOT since it actually uses the same processor as the as the Apple II. What seems clear to me is that the software required to initialize the III to run Apple II software, was more of an inhibitor/limiter as I already related it to Apple's OS X Boot Camp to run Windows on an Intel processor. But perhaps a more apt comparison is to look at efforts to put OS X on a PC. Apple has intentionally crippled the software so it will not install on a PC, despite the fact it runs perfectly well on the exact same processors. It is my understanding that Apple intentionally installed similar, but hardware traps in the III to interrupt an Apple II direct boot, and therefore the limited use of the II software had to be "enabled" via software which also defined the restrictions of the expansive hardware otherwise available to it. It seems like it only "emulated" a II in the sense it forced the more advanced hardware to behave in a more limited fashion. The fact that cards were later developed to overcome the Apple II limited operation capabilities, seems to indicate a hardware issue rather than a software one.

When you say the Apple III won't run a lot of Apple II software, do you mean software available in 1980, or software later developed for the IIe?

Also, could you stick a boot disk from a IIe into a IIGS and it would start up without any other assistance?

the IIgs didn't use a 65802, but a 65c816. when a iigs ran 6502 software is wasn't emulation, but running on a real 6502.

Ah, so what you are saying is, unlike the RISC PowerPC chips which literally had the 68K code "instantaneously" converted by software, the Apple II code on the IIGS actually ran in a sub-section of the 65802, literally dedicated to the 6502 processes, like a Math Co-processor which could be integrated into the CPU or on a separate chip. In which case, the Apple II & Apple III are both Apple II hardware at their cores.

Having said that, after pointing out how Windows and OS X will both run on the same processor at the core of both Macs & PCs, yet are limited by the surrounding hardware, I suppose the III truly is a different Apple, whereas that integration ensures the IIGS is a II. However, by that same token, Running Windows on a Mac, makes the Mac no different than a PC. I suppose the Mega II Card in the IIGS is the difference –– if a similar PC hardware card were added into an expansion slot, then one could call such a machine the "Apple PC".

So the next question is whether Apple III software will run on an Apple IIe?

 

[david__schmidt]

So the next question is whether Apple III software will run on an Apple IIe?

No native /// software runs on any II of any stripe. Even though SOS and ProDOS are related and have a lot of similar calls, the calling mechanism is different. BASIC is different (Apple Business BASIC for the ///, MS or Woz BASIC for the II) and all have different tokenizations. One similarity of note: Pascal leveled the playing field somewhat. The same source code (and object code, it turns out) can run on either /// or II "virtual" Pascal machines; P-code has a lot in common with Java classes and JVMs. Anything that make explicit calls to hardware, except where those hardware addresses were identical (screen, etc.) would of course fail.

 

[barana]

Who told u the IIGS used a 65802?

IIRC the ppc chips have a real 68LC040@33mhz onboard. no software conversion at all.

There was software that allowed it to emulate an Apple II but you couldn't run Apple II software without first running that emulation software. So in some ways that made it more like an Apple II emulator on a Mac or PC. A IIgs will directly boot apple II software. Actually an Apple III won't run a lot of Apple II software. It won't run anything that needs more than 48k RAM or 80 column or does a lot of hardware pokes.

Actually, it may seem like it is an Apple II "emulator" because of the way it behaves, but clearly it is NOT since it actually uses the same processor as the as the Apple II. What seems clear to me is that the software required to initialize the III to run Apple II software, was more of an inhibitor/limiter as I already related it to Apple's OS X Boot Camp to run Windows on an Intel processor. But perhaps a more apt comparison is to look at efforts to put OS X on a PC. Apple has intentionally crippled the software so it will not install on a PC, despite the fact it runs perfectly well on the exact same processors. It is my understanding that Apple intentionally installed similar, but hardware traps in the III to interrupt an Apple II direct boot, and therefore the limited use of the II software had to be "enabled" via software which also defined the restrictions of the expansive hardware otherwise available to it. It seems like it only "emulated" a II in the sense it forced the more advanced hardware to behave in a more limited fashion. The fact that cards were later developed to overcome the Apple II limited operation capabilities, seems to indicate a hardware issue rather than a software one.

When you say the Apple III won't run a lot of Apple II software, do you mean software available in 1980, or software later developed for the IIe?

Also, could you stick a boot disk from a IIe into a IIGS and it would start up without any other assistance?

the IIgs didn't use a 65802, but a 65c816. when a iigs ran 6502 software is wasn't emulation, but running on a real 6502.

Ah, so what you are saying is, unlike the RISC PowerPC chips which literally had the 68K code "instantaneously" converted by software, the Apple II code on the IIGS actually ran in a sub-section of the 65802, literally dedicated to the 6502 processes, like a Math Co-processor which could be integrated into the CPU or on a separate chip. In which case, the Apple II & Apple III are both Apple II hardware at their cores.

Having said that, after pointing out how Windows and OS X will both run on the same processor at the core of both Macs & PCs, yet are limited by the surrounding hardware, I suppose the III truly is a different Apple, whereas that integration ensures the IIGS is a II. However, by that same token, Running Windows on a Mac, makes the Mac no different than a PC. I suppose the Mega II Card in the IIGS is the difference –– if a similar PC hardware card were added into an expansion slot, then one could call such a machine the "Apple PC".

So the next question is whether Apple III software will run on an Apple IIe?

 

[~Coxy]

Who told u the IIGS used a 65802?
IIRC the ppc chips have a real 68LC040@33mhz onboard. no software conversion at all.

68K software on PPC machines runs in a JIT software emulator. There's an interesting writeup of it on wiki: http://en.wikipedia.org/wiki/Mac_68K_emulator

 

[waynestewart]

There was software that allowed it to emulate an Apple II but you couldn't run Apple II software without first running that emulation software. So in some ways that made it more like an Apple II emulator on a Mac or PC. A IIgs will directly boot apple II software. Actually an Apple III won't run a lot of Apple II software. It won't run anything that needs more than 48k RAM or 80 column or does a lot of hardware pokes.

Actually, it may seem like it is an Apple II "emulator" because of the way it behaves, but clearly it is NOT since it actually uses the same processor as the as the Apple II. What seems clear to me is that the software required to initialize the III to run Apple II software, was more of an inhibitor/limiter as I already related it to Apple's OS X Boot Camp to run Windows on an Intel processor. But perhaps a more apt comparison is to look at efforts to put OS X on a PC. Apple has intentionally crippled the software so it will not install on a PC, despite the fact it runs perfectly well on the exact same processors. It is my understanding that Apple intentionally installed similar, but hardware traps in the III to interrupt an Apple II direct boot, and therefore the limited use of the II software had to be "enabled" via software which also defined the restrictions of the expansive hardware otherwise available to it. It seems like it only "emulated" a II in the sense it forced the more advanced hardware to behave in a more limited fashion. The fact that cards were later developed to overcome the Apple II limited operation capabilities, seems to indicate a hardware issue rather than a software one.

When you say the Apple III won't run a lot of Apple II software, do you mean software available in 1980, or software later developed for the IIe?

An Apple III had built-in II Plus emulation and that was with 40 columns and only 48k RAM. Not having a language card, how do you load integer basic programs or run Pascal. So technically you couldn't get it to run a huge amount of pre 1980 software? Also some Applesoft programs needed 64k

More importantly if you stick a disk for a IIe or II Plus in a IIgs drive and turn it on, it'll run it. If you load integer basic into it's built-in language card then you can run the first Apple II programs to come on a floppy disk.

 

[Mac128]

Who told u the IIGS used a 65802? IIRC the ppc chips have a real 68LC040@33mhz onboard. no software conversion at all.

Typo. Had 65802 on the brain. :beige: Can't edit anymore so ... so it lives for posterity and leads to pointless correction posts like this one.

But, who told you the PPC chips have a real 33MHz 68LC040 chip embedded into them? I can find nothing anywhere on the internet that indicates that.

 

[barana]

Who told u the IIGS used a 65802? IIRC the ppc chips have a real 68LC040@33mhz onboard. no software conversion at all.

Typo. Had 65802 on the brain. :beige: Can't edit anymore so ... so it lives for posterity and leads to pointless correction posts like this one.

But, who told you the PPC chips have a real 33MHz 68LC040 chip embedded into them? I can find nothing anywhere on the internet that indicates that.

You know, I'm not sure! I just have always held that idea, And thought it was encouraged by ars tecnica's ppc article.

Thx for clearing that up fellas. you learn something new.....

 

[Dog Cow]

Who told u the IIGS used a 65802? IIRC the ppc chips have a real 68LC040@33mhz onboard. no software conversion at all.

But, who told you the PPC chips have a real 33MHz 68LC040 chip embedded into them? I can find nothing anywhere on the internet that indicates that.

...Because it's not true. Gary Davidian wrote the emulator which resides in the ROM of every Power Mac.

 

[Mac128]

An Apple III had built-in II Plus emulation and that was with 40 columns and only 48k RAM. Not having a language card, how do you load integer basic programs or run Pascal. So technically you couldn't get it to run a huge amount of pre 1980 software? Also some Applesoft programs needed 64k

Again the solution seems to be in that the Apple III was built around Apple II Hardware. According to the Apple III FAQ:

Titan made a ///+// card for the /// - it increased memory up to 128K in //+ emulation and offered a RAM disk in native mode. The "Titan ///+//e" - a set of two-cards that really turns your /// into a 128k //e. You'll want to add a 65c802 CPU (in place of the 6502) toensure compatibility with newer Apple // programs (it has no effect on native mode applications). The cards

offer a RAM disk in native mode as well.

So it seems pretty clear that third party cards could make the Apple III just as capable as similar cards required to make the II Plus as powerful.

Now that I am clear on exactly what the 65c816 was doing vis-a-vis hardware, I'd have to say that the III had as much right to be called a II as the IIGS. The only difference being that the III did everything it could to cripple support for the Apple II mode out of the factory and the IIGS did everything it could to facilitate it. Nevertheless, with the same kinds of add-on cards required to provide the same functionality on an actual II Plus, the III was a perfectly capable II Plus (indeed even a IIe), with the same processor running at its core. Had the Apple III stuck around longer, I wonder if more developers would have attempted to circumvent Apple's debilitating efforts. In researching this it seems the main reason for the III's failure was a complete lack of advance developer support (a problem Jobs astutely avoided with the Macintosh). Even if the hardware had been trouble free, the lack of available software and lower price would have likely kept the Apple II alive for many more years anyway. Who knows, eventually Apple might have merged them into the IIGS anyway, as Apple realized the folly of trying to separate the two systems.

 

[H3NRY]

Apple used to brag at the time that the /// was a 16-bit machine because there was a state machine appended to the 6502 to handle 16-bit words and the data buss fetched 16 bits at a time. As it turned out, other than Great Plains accounting software and a few other business packages, what people used it for was running Apple II software, and the fact that Apple added hardware to specifically cripple Apple II mode made that difficult. It was a wakeup to Apple that users would not automatically move from one platform to another just because it was there. They expected the Apple II to III transition to happen the way the Apple I to II had gone, and 20 years out, we'd all be using Apple IXes. It hadn't occurred to anyone that once there was an OS and software base, it became more important than hardware to customers. That lesson resulted on the IIgs.

 

[II2II]

I have often heard the claim that the Apple /// was intentionally crippled, usually for marketing reasons and always with the implication that it did not have to be done. But is there anything to substantiate that?

Here's my thoughts:

The original Apple II had a rather quirky design. Sometimes that was due to technical limitations, such as the tiny memory windows to Apple Bus cards. Sometimes that was to simplify the hardware design, such as the non-linear mapping of the video frame buffer. Software developers often compounded the problem, by depending upon the hardware and firmware's implementation rather than using higher level abstractions. (Not that the had much of a choice, since that abstraction was limited and performance was always a consideration.)

On top of that, the design experience within Apple would have been quite limited. Indeed, design experience would have been limited in the PC industry as a whole. Backwards compatibility was not really a factor in an industry that had a plurality of incompatible vendors, and vendors that were barely compatible within their own product-lines. The PC had yet to learn the lesson of the mainframe (in the business or technical context). So it may have made more sense to have mode splitting.

 

[H3NRY]

I have often heard the claim that the Apple /// was intentionally crippled, usually for marketing reasons and always with the implication that it did not have to be done. But is there anything to substantiate that?

Woz says the limits on compatibility were intentional. I can't say; wasn't there. Wendel Sander was a "real" engineer with a PHD in computer science, so his design for the /// might have simply reflected his idea of a proper computer. The Apple II was (as has been mentioned) quite unusual for the day, and the A/// used the same slots and disk drives as its predecessor, so it was a bit of a mongrel. Not as conventional as IBM's Apple II copy (the original PC), but not as brilliantly minimal as Woz's baby. I was tempted by the Apple/// Plus and its super hi-res interlaced video, but during the short time it was made, I was too broke.

I have a couple of IIGSes in the closet, and some day I'll set them up and see what they can do. Assuming I find some more tuits, that is. Getting a round tuit here is near impossible.