Re: Why still using Apple II?

[Paul Schlyter <pausch@NOSPAMsaaf.se>]

In article <_dWdnUq3Cs1RQTrfRVn-2w@comcast.com>, alexf@mirrow.com says...

>We did get a bit off topic, but we do like to argue, right?
>
>To mention Apple 2 at least once, I had built my own clone back in the 80s
>because the real one was way too expensive for me. And recently I made another
>clone in a single FPGA including the 6502 CPU.  So I know a thing or two about
>the 6502 clock cycles :)
>
>Below.
>
>"Paul Schlyter" <pausch@NOSPAMsaaf.se> wrote in message
>MPG.1d10b46e1ab2250498969b@news.individual.net">news:MPG.1d10b46e1ab2250498969b@news.individual.net...
>
>> The 6502 was definitely faster than the 8080.  A lot of 6502 instructions
>> took only 2 clock cycles, while any instruction on the 8080 took a minimum
>> of 4 clock cycles.  So a 1 MHz 6502 ran about as fast as a 2-3 MHz 8080.
>
>Sure. And the very first 8080 ran at 2 MHz. So the speed was about the same.
>The one major drawback of 8080 was that it required 3 voltages to run.
>8080 had more instructions, but 6502 had more addressing modes.
>8080 had more registers, but 6502 had zero page.
>8080 had 16 bit addition, but ....
>
>So there was no clear winner.
>
>BTW Z80 started at 2.5 MHz and had a lot of improvements over 8080. No
>wonder it is STLL used after 30 years or so.

...and too bad the 8086/8088 didn't try to mimic the Z80 architecture 
instead...

>>>there is absolutely no question that 68000 was light-years ahead of 8088.
>>>Just consider 32 bit registers,
>>
>> ...which were somewhat limited on the 68000.  The multiply and divide
>> operations on the 68000 were 16-bit, not 32-bit, for instance.
>
>Well, AFAIK 8088 didn't do any better in this respect, did it?

Of course not, and I never claimed it did.  And no-one has called the 8088
a 32-bit processor.

BTW using your logic above one could also say e.g.

"there is absolutely no question that 8080 was light-years ahead of 6502.
Just consider 16 bit registers"

:-)


>>>4GB address space
>>
>> That came later.  The first versions of the 68K CPU had only a 24-bit
>
>I'm talking about LOGICAL memory space, not the number of physical address
>pins.

Did the 68K have some paging mechanism which allowed access to 4 GBytes
address space through its 24 address pins?  If not, that LOGICAL memory
space becomes quite useless, since no physical RAM can ever be attached
to most of that memory space.

>x86 still suffers from this problem. The  LOGICAL memory space is limited
>to 1MB in real mode.

Virtually nobody ever use that real "lobotomy" mode of the x86 anymore.
If you want to run a real mode x86 application on a modern PC, it is
run in a Virtual-86 process, which gives you 1 MByte of memory for every
such process.  And you can run 32-bit software concurrently as well.
This can be done in Windows (of course) as well as in Linux (by using
an MS-DOS emulator on Linux).

>Not to mention all the "extended" and "expanded" memory kluges of the late
>80s.  Once more memory was needed it was a simple matter of adding to the
>address bus on the 68K.

The "expanded" memory was the only kludge here -- it used bank switching
to access more than 1 MByte within that 1 MByte real mode address space.
A bit similar to what could be done on the Apple II; or on CP/M-80 machines.

The "extended" memory was a way to let the "lobotomy" real mode access
physical memory already attached and otherwise available only in protected
mode.  "Extended" memory was available only on the 286 and up.  And to use
"extended" memory the CPU had to leave real mode and enter Virtual-86
mode - a kind of protected mode which to the application appears as real
mode; more on that below.  EMM386.SYS contained the code which switched
the 286+ CPU from real mode to Virtual-86 mode.


>>> Now 386 was the first "real" CPU from Intel that allowed true
>>> multitasking.
>>
>> :-) ...actually almust any CPU can do "true multitasking" (I suppose you
>> mean preemptive multitasking by that) -- it's just a matter of hooking up
>> an interrupt from a timer chip to a task scheduler.
>
>I mean a lot more than that. Yes, you can do preemptive multitasking on a
>PIC chip, but things like separate stacks and user vs. supervisor mode helps
>a lot when writing a "real" OS.

The equivalent of user and supervisor mode existed already in the 286
as Ring 0, Ring 1, Ring 2 and Ring 3 (where Ring 0 corresponds to your
Supervisor mode and Ring 3 to your User mode - Rings 1 and 2 are available
if mode fine-grained access control than that is needed; they are mostly
unused).  This allowed true multitasking WITH memory protection (which was
a weak spot on the 68K unless you attached an external MMU to it. Btw that's
why Mac OS up to OS 9 had no real memory protection).  This real 
multitasking
on the 286 was used in OS/2 and Minix.  As you may know, Minix was the OS
which inspired Linus Torvalds to write Linux.


.......................

> The 386 was the 32-bit version of the 286, which also added paging as an
> alternative memory protection mechanism.  The segments are still there in
> the 386, but now each segment can be up to 4 GBytes large.  Which makes it
> practical to run in "flat address space", i.e. all segments overlapping
> one another - memory protection is then provided by the paging mechanism.

Not to mention the addition of return to real mode, hardware debugging
registers and a lot more.

The "return to real mode" instruction was really a kludge.  Intel's 
intentions was that once you entered protected mode you should remain there 
until the CPU was powered off.  Which seems reasonable -- after all what's 
the point of going back to the "lobotomy" real mode?  But then there was
that ever recurring question about backwards compatibility.... on the
AT, IBM added external hardware to make it possible to have the 286
return to real mode - that was accomplished by resetting the CPU.  It
worked byt was slow.  So Intel added the "return to real mode" on the
386 as a response to user demands.

A more useful addition to the 386 was the Virtual-86 mode, which enabled
you to run real mode applications in protected mode such that it appeared
to the application as if it ran in real mode.

>> When the x86 first was released there was no "installed base of PC's" so
>> that wasn't a factor at all at first.  However, backwards compatibility
>> was still an issue - not towards PC's but towards the older base of CP/M-80
>> computers.  And so the 8086/8088 was given a register and instruction set
>> which was backwards compatible to the 8080.  There was no binary backwards
>> compatibility though, but 8080 assembly language programs could fairly
>> easily be machine translated to 8086/88 assembly language programs.  And
>> some of the MS-DOS system calls closely mimiced the corresponding CP/M
>> system calls.
>
> Absolutely. Which contributed to the limitations of the 86 architecture
> that had deep roots in the 8 bit world.

Let's be happy that the backwards compatibility was towards the 8080
instead of e.g. the 6502 since, by 8-bit CPU standards, the 8080 had
a farily generous set of CPU registers.  Too bad the 8086 didn't try
to be backwards compatible to the Z80 -- but after all, Zilog was a
competitor to Intel....

>> For some years NEC manufactured the V20 chip which was an 8088 clone, with
>> one added feature: by setting a CPU flag, it miniced an 8080 instead, and
>> was then able to execure 8080 machine code directly.  There was at least
>> one CP/M-80 emulator for MS-DOS which utlized this feature of the V20, and
>> thus ran CP/M software efficiently.
>
> Yes. I think there was also V30(?) - same but 16 bit external bus.

True - the V30 was compatible to the 8086.  However, there never were that
many PC's with an 8086... the only one I ever used was made by Olivetti
and ran at 8 MHz.

NEC also planned to manufacture chips which could replace the 8087 (the
numeric coprocessor to the 8086 and 8088), but afaik that chip never
materialized.


-- 
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se
WWW:     http://stjarnhimlen.se/