Orchid XP v8 wrote:
> But anyway, I was under the impression they used to be M68k-based, and 
> then PPC, and then recently went to Intel Core 2.

 From Wikipedia*: "Throughout the 1980s and much of the 1990s, the Apple 
II was the de facto standard computer in American education; some of 
them are still operational in classrooms today.

...

The first Apple II computers went on sale on June 6, 1977[2] with a MOS 
Technology 6502 microprocessor running at 1 MHz, 4 kB of RAM, an audio 
cassette interface for loading programs and storing data, and the 
Integer BASIC programming language built into the ROMs."

Heh... while I never used the original model, most of the schools where 
I lived used IIe's or later.  As the article says, there are *still* 
schools around that have labs full of them.

...Chambers

*http://en.wikipedia.org/wiki/Apple_II

Post a reply to this message

Warp wrote:

>   How did the world survive before computers, cellphones and frozen pizza?

Quite well, from what I've heard... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Chambers wrote:

> Heh... while I never used the original model, most of the schools where 
> I lived used IIe's or later.  As the article says, there are *still* 
> schools around that have labs full of them.

Must be a regional thing... When I was at school, it was the BBC Micro - 
and nothing else!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> I thought this was true for *all* processors?

No, as already said, RISC gets close to 1 instruction per clock cycle on 
average, but new CISC processors can do instructions in parallel inside the 
same core, so you can get more than 1 instruction per clock cycle on 
average.  Actually it seems like the latest Intel processors can do getting 
on for 20 instructions per clock cycle on average.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I don't think that's sufficient to make it a RISC processor. That would 
> mean both the PDP-11 and the X-560 were RISC processors.

  Who says they weren't?

> The X-560 had 
> built-in instructions for COBOL data types, string manipulation (aka 
> block moves/compares/character set and case conversions/etc), 
> instructions that would do things like push a word on a stack whose 
> pointer was in a particular register and set the condition bits to stack 
> full/empty/almost full/almost empty, etc. Yet it had 7 bits of opcode, 
> one "indirect" bit, four bits of register ID, then either three bits of 
> index register and 17 bits of address, or 20 bits of absolute 
> (immediate) data. Very straightforward enough that I can still remember 
> how the opcodes were laid out after 20 years not using it. Pretty much 
> all the microcoded CISC machines were like that, especially those 
> expected to be programmed in assembler.

  I don't think RISC has been ever defined to mean "you can only perform
very simple operations with a single opcode". RISC stands for *reduced*
instruction set computer, not *simplified* instruction set computer.
Just because the total amount of different instructions may be small
(eg. because only 7 bits of the opcode have been reserved for the
instruction, and thus the number of different instructions is limited
to 128), that doesn't mean that an instruction couldn't perform very
complicated things.

  I don't really understand where the concept of a RISC opcode being
*simple* has come from.

  What makes RISC processors simpler is that their fetching and decoding
steps, pipelines and code caches are simpler because all the opcodes have
exactly the same size and the meaning of the bits in each opcode has
been fixed. CISC processors are more complicated because of variable-sized
opcodes which can contain almost anything.

> You'd have to talk about addressing modes, pipelines, generalness of 
> registers, etc.  Sure, the original RISC processors had a very simple 
> model so they could fit more registers, but I think we've gone past that 
> now. What you describe might be true of *typical* RISC processors and 
> untrue of *typical* CISC processors, but I think everything's complex 
> enough now that you need to measure things on multiple dimensions in 
> order for it to make any sense.

  It's not a question of simple or complicated.

-- 
                                                          - Warp

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Orchid XP v8 wrote:
> > But anyway, I was under the impression they used to be M68k-based, and 
> > then PPC, and then recently went to Intel Core 2.

>  From Wikipedia*: "Throughout the 1980s and much of the 1990s, the Apple 
> II was the de facto standard computer in American education; some of 
> them are still operational in classrooms today.

  There's no use in trying to convince him that Apple computers are or have
ever been popular anywhere. He will never believe it, no matter how much
evidence you pour to him.

  Let him live in his illusion in peace.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
> John VanSickle wrote:
> 
>> There were games on the Apple (6502-based) which had seven versions of 
>> any given sprite graphic so that they wouldn't have to be shifted in 
>> order to display them on the screen.  8-bit game programmers learned 
>> much about squeezing every last drop of performance out of limited 
>> speed and memory.
> 
> Wouldn't having 7 copies of the same data eat more memory?

This is what programmers call a trade-off; the only way to get 
acceptable speed was to use up seven times as much memory (not eight, 
because only the lower seven bits of each video byte represented screen 
pixels; the MSB selected the colors).

> Did it actually store 7 copies, or just precompute them?

The computer did not precompute them; the programmer did.

> Also... Apple made a 6502-based product??

Yes, it was called the Apple ][.

> The equations for simple 2D acceleration and reflection are fairly easy, 
> and probably implementable in fixed-point arithmetic.

I suspect that they actually used angles, probably 256ths of a circle, 
which on a screen with 320 x 200 pixels was all the precision anyone 
needed.  When a ball moving at angle X hits a wall set at angle Y, the 
ricochet angle is calculated with addition and subtraction, and no 
multiplication is needed at all.  To move the ball, the angle was used 
to index a lookup table of sine and cosine values, and they probably 
used one table for both (add 0x40 to the 8-bit index to get cosine values).

> The *hard* part about physical simulations is that they usually involve
 > a huge number of items; *one* marble isn't too big a deal.

Yeah; gravity sims are an O(n^2) problem.

Regards,
John

Post a reply to this message

Orchid XP v8 wrote:

> I just wrote the assembly on a piece of paper, and when the program was 
> properly finished, it'd do the "assembling" part by hand. (I.e., open my 
> dad's book and leaf through the op-code table.)

Hand assembly was actually a common practice until 16-bit processors 
made this too troublesome; with at most 256 opcodes to remember 
(although the 6809[1] had prefix opcodes that made the following opcode 
take on a different meaning), many 8-bit assembly programmers were 
perfectly capable of reading and writing the opcodes directly from/to a 
memory listing.

> Eventually I tired of this, and wrote my old assembler.

The C64 had a cartridge port on the back end, and one fine company put 
out a cartridge called HESMon, which provided a mini-assembler, memory 
dump and editing, and so on.  I could have used the mini-assembler, but 
opcodes were two keystrokes while mnemonics were three, so for the sake 
of speed I usually typed the opcodes.  The monitor would disassemble 
them for me so I caught any errors quickly.

Regards,
John


[1] The 6809 was the nicest, IMHO, of the 8-bit processors.  It had 
hardware multiply and sixteen-bit index registers (with preincrement and 
postdecrement).  Code for that processor was usually smaller than the 
6502 equivalent.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I don't think that's sufficient to make it a RISC processor. That would 
>> mean both the PDP-11 and the X-560 were RISC processors.
> 
>   Who says they weren't?

Maybe because both were obsolete before the term RISC was invented? 
Because neither had lots of variables? Because they both had complex 
addressing modes beyond LOAD and STORE? Because they both had 
instructions that took variable numbers of cycles?

*I* say they weren't. They might meet your definition of RISC, but I'm 
pretty sure your definition doesn't align with the definitions of most 
others when talking about it.

>   I don't think RISC has been ever defined to mean "you can only perform
> very simple operations with a single opcode". RISC stands for *reduced*
> instruction set computer, not *simplified* instruction set computer.

No, but it also means the ALU only talks to the registers, and there 
aren't any complex addressing modes. Neither of those are true of the 
two CPUs I named here.

>   I don't really understand where the concept of a RISC opcode being
> *simple* has come from.

Well, because that made it fast. Read the link I pointed you to. The 
point of reducing the instruction set and addressing modes was to make 
it faster and to make more room for registers, by eliminating the 
microcode.

>   What makes RISC processors simpler is that their fetching and decoding
> steps, pipelines and code caches are simpler because all the opcodes have
> exactly the same size and the meaning of the bits in each opcode has
> been fixed. CISC processors are more complicated because of variable-sized
> opcodes which can contain almost anything.

Again, I think you're oversimplifying. You're using a definition for 
RISC at odds with the definition created by the people who created the 
term. By leaving off significant portions of the original "meaning" of 
the term, you're turning it into a binary situation. However, the 
original meaning of RISC has several components (addressing modes, 
increased number of registers, simplified decoding), and processors 
nowadays combine these things to different degrees.

I think if you asked a modern CPU designer whether he'd consider a 
hardware operation equivalent to sprintf() to be "RISC", you'd almost 
invariably get the answer "no".

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.

Post a reply to this message

On 14-Jul-08 9:13, Orchid XP v8 wrote:
> Warp wrote:
> 
>>   How did the world survive before computers, cellphones and frozen 
>> pizza?
> 
> Quite well, from what I've heard... ;-)
> 
I heard it doesn't exist anymore. So I don't think it did so well after all.

Post a reply to this message