Re: Reproduction micros

[Peter Corlett]

On Mon, Jul 25, 2016 at 01:46:43PM -0700, Guy Sotomayor Jr wrote:
>> On Jul 25, 2016, at 1:34 PM, Sean Conner  wrote:
>> It was thus said that the Great Peter Corlett once stated:
>>> Unsurprisingly, the x86 ISA is brain-damaged here, in that some
>>> instructions (e.g. inc") only affect some bits in EFLAGS, which causes a
>>> partial register stall. The recommended "fix" is to avoid such
>>> instructions.

>>  I'm not following this.  On the x86, the INC instruction modifies the
>> following flags: O, S, Z, A and P.  So okay, I need to avoid INC to prevent
>> a partial register stall, therefore, I need to use ADD.  Let me check ...
>> hmm ... ADD modifies the following: O, S, Z, A, P and C.  So now I need to
>> avoid ADD as well?  I suppose I could use LEA but then there goes my bignum
>> addition routine ... 
>>  -spc (Or am I missing something?)

Yes, in that I was taking a potshot at x86's expense, and skipped the technical
details because contemporary x86 architecture is seriously off-topic. But since
I've now been asked...

> No Peter is wrong. All of the modern x86 (at least the Intel CPUs) are OOO
> machines with large register files (192 comes to mind) that do register
> renaming to map the register(s) used by a particular instruction back into an
> “architectural” register (no copy is actually done). The flags register is
> also part of the register re-naming. The only stalls occur when one
> instruction needs the results from an instruction that hasn’t committed it’s
> results yet (ie the instruction is still in “flight”).

It is the *partial* update that's key. If you do an INC and then read EFLAGS or
execute an instruction such as JBE that needs C and some other flag(s), the
information has to be derived from *two* renamed registers. This typically
involves an extra micro-op in the instruction stream to do this fixup, although
the details will obviously vary by CPU model.

But I'm only repeating this information from the experts, so if you still think
I'm wrong, read their reference material:

http://www.agner.org/optimize/microarchitecture.pdf is Agner Fog's optimisation
guide with more detail that mere mortals really need. Page 154 covers this for
the latest Skylake CPUs and uses INC in its example.

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html
is Intel's own optimisation guide. Section 3.5.2.6 discusses partial flag
register stalls, although it doesn't specifically mention INC.

This stuff is way more complex than any normal person can keep in their head.
It's possible to learn all the edge cases and avoid the performance hit in
hand-written assembly, but it's a lot easier to just give it to the compiler to
puzzle out. That's its job.

Can we now go back to talking about interesting CPUs? :)

Re: Reproduction micros

[Guy Sotomayor Jr]

> On Jul 25, 2016, at 1:34 PM, Sean Conner  wrote:
> 
> It was thus said that the Great Peter Corlett once stated:
>> 
>> Unsurprisingly, the x86 ISA is brain-damaged here, in that some instructions
>> (e.g. inc") only affect some bits in EFLAGS, which causes a partial register
>> stall. The recommended "fix" is to avoid such instructions.
> 
>  I'm not following this.  On the x86, the INC instruction modifies the
> following flags: O, S, Z, A and P.  So okay, I need to avoid INC to prevent
> a partial register stall, therefore, I need to use ADD.  Let me check ...
> hmm ... ADD modifies the following: O, S, Z, A, P and C.  So now I need to
> avoid ADD as well?  I suppose I could use LEA but then there goes my bignum
> addition routine ... 
> 
>  -spc (Or am I missing something?)

No Peter is wrong.  All of the modern x86 (at least the Intel CPUs) are OOO
machines with large register files (192 comes to mind) that do register renaming
to map the register(s) used by a particular instruction back into an 
“architectural”
register (no copy is actually done).  The flags register is also part of the 
register 
re-naming.  The only stalls occur when one instruction needs the results from an
instruction that hasn’t committed it’s results yet (ie the instruction is still 
in “flight”).

TTFN - Guy

Re: Reproduction micros

[Sean Conner]

It was thus said that the Great Peter Corlett once stated:
> 
> Unsurprisingly, the x86 ISA is brain-damaged here, in that some instructions
> (e.g. inc") only affect some bits in EFLAGS, which causes a partial register
> stall. The recommended "fix" is to avoid such instructions.

  I'm not following this.  On the x86, the INC instruction modifies the
following flags: O, S, Z, A and P.  So okay, I need to avoid INC to prevent
a partial register stall, therefore, I need to use ADD.  Let me check ...
hmm ... ADD modifies the following: O, S, Z, A, P and C.  So now I need to
avoid ADD as well?  I suppose I could use LEA but then there goes my bignum
addition routine ... 

  -spc (Or am I missing something?)

Re: Reproduction micros

[Paul Koning]

> On Jul 25, 2016, at 12:19 PM, Chuck Guzis  wrote:
> 
> On 07/25/2016 02:31 AM, Peter Corlett wrote:
> 
>> Eliminating condition codes just moves the complexity from the ALU to
>> the branch logic (which now needs its own mini-ALU for comparisons),
>> and there's not much in it either way. Where it *does* win is that
>> the useful instructions are all single-output and so one can use the
>> noddy code generators found in undergraduate-level compiler
>> construction textbooks such as the Dragon Book.
> 
> Sorry, I'm not following this bit.  I am speaking about a three-address
> ISA here, BTW.
> 
> Simply adding a flag to each register reflecting its zero/nonzero
> content should do the job.  The high-order (sign) bit is the only other
> bit necessary.  Branch instructions need only inquire if either, neither
> or both flags are set.
> 
> I suppose that one could also have several flags registers, being set
> selectively as dictated by a field in the instruction.

The point is that instructions that set condition codes have two outputs: their 
output register, and the condition code register.

That creates both software and hardware complexity.  Software complexity in the 
compiler, which has to track the assignments to both these outputs and do 
instruction rearranging accordingly.  Hardware complexity, because the 
instruction issue logic has to issue the instructions for the correct outcome 
in both these outputs.

paul

Re: Reproduction micros

[Chuck Guzis]

On 07/25/2016 02:31 AM, Peter Corlett wrote:

> Eliminating condition codes just moves the complexity from the ALU to
> the branch logic (which now needs its own mini-ALU for comparisons),
> and there's not much in it either way. Where it *does* win is that
> the useful instructions are all single-output and so one can use the
> noddy code generators found in undergraduate-level compiler
> construction textbooks such as the Dragon Book.

Sorry, I'm not following this bit.  I am speaking about a three-address
ISA here, BTW.

Simply adding a flag to each register reflecting its zero/nonzero
content should do the job.  The high-order (sign) bit is the only other
bit necessary.  Branch instructions need only inquire if either, neither
or both flags are set.

I suppose that one could also have several flags registers, being set
selectively as dictated by a field in the instruction.

--Chuck

Re: Reproduction micros

[Peter Corlett]

On Mon, Jul 25, 2016 at 05:54:51AM -0600, ben wrote:
[...]
> The other factor is that the 3 big computers at the time IBM 360/370's PDP 10
> and PDP 11 where machines when the Dragon Book came out thus you favored
> register style code generators. Later you got the Pascal style one pass
> generators that is still with us.

Those backend designs are completely obsolete now. Modern machines have more
grunt, so can use more complex algorithms to eke out more performance.

> After that the Intel hardware mess, and the growth of (to me useless
> languages like C++ or JAVA) or features like OBJECTS has made every thing so
> complex, that only few people can even understand just what a compiler is
> doing.

A C++ object is a C struct, and a C++ method is a C function that has an
invisible first parameter that is a pointer to the object. The generated
machine code is bitwise identical. Dynamic dispatch muddies the water a bit,
and is equivalent to (but not usually implemented as) a function pointer in the
struct. This is not exactly rocket science.

There are more features in C++, and they tend to get overused by newcomers who
are blinded by the shinies, but it is possible to exercise good judgement to
make it *easier* to read than the equivalent C program by tucking all the
boilerplate out of the way.

> PS: Has computer science really advanced since the late 1970's? What about
> hardware?

Is that a rhetorical question? I'm going to answer it anyway :)

One of my favourite bits of CS is Andrew Tridgell's PhD thesis, from 1999. The
advancement to human knowledge was his algorithm to very efficiently run a
sliding window across data using rolling checksums and compute deltas in a
network-efficient manner. This is the business end of rsync(1), and it can also
be used for data compression.

On compilation itself, there are a few interesting advances. Single Static
Assignment form was invented by IBM in the 1980s; ISTR it's covered in my 1986
edition of the Dragon Book. The essence of the idea is that variables can only
be assigned once, and since they are immutable values, it enables many very
worthwhile optimisations that wouldn't be as simple were the values liable to
change.

Functional programming is finally mainstream. Yes, Lisp has been around since
the 1950s, but it's been refined somewhat over the 2000s. It's used for
immutability (which Lisp didn't really have) and so is easier to reason about
on multi-threaded and multi-processor machines because one now doesn't need to
worry about shared mutable state.

There are *loads* of novel algorithms and techniques out there, but it seems to
take decades for them to appear in algorithm textbooks.

Re: Reproduction micros

[ben]

On 7/25/2016 3:31 AM, Peter Corlett wrote:

On Fri, Jul 22, 2016 at 11:59:59AM -0700, Chuck Guzis wrote:
[..]

Something that's always bothered me about three-address architectures like
ARM is why there is the insistence on that scheduling bottleneck, the
condition code register? You can see how two-address architectures like the
x80 and x86 try to get around the problem by having certain instructions not
modify certain condition code bits and even have specialized instructions,
such as JCXZ, that don't reply on a specific condition code.



Anyone have a clue?


The condition code register can be treated as a regular register that partakes
in register renaming. Effectively, you have *many* CCRs in flight, so only
*reads* of the register may cause stalls. These reads are usually branches, so
there's branch prediction caches to try and deal with those stalls.

Unsurprisingly, the x86 ISA is brain-damaged here, in that some instructions
(e.g. inc") only affect some bits in EFLAGS, which causes a partial register
stall. The recommended "fix" is to avoid such instructions.

Eliminating condition codes just moves the complexity from the ALU to the
branch logic (which now needs its own mini-ALU for comparisons), and there's
not much in it either way. Where it *does* win is that the useful instructions
are all single-output and so one can use the noddy code generators found in
undergraduate-level compiler construction textbooks such as the Dragon Book.

I favor testing a register rather than using  flags.(I also like 9 bit 
bytes too).

The other factor is that
the 3 big computers at the time IBM 360/370's PDP 10 and PDP 11 where 
machines when the Dragon Book came out thus you favored register style 
code generators. Later you got the Pascal style one pass generators that 
is still with us. After that the Intel hardware mess, and the growth of 
(to me useless languages like C++ or JAVA) or features like OBJECTS has 
made every thing so complex, that only few people can even

understand just what a compiler is doing.

Ben.
PS: Has computer science really advanced since the late 1970's?
What about hardware?

Re: Reproduction micros

[Peter Corlett]

On Fri, Jul 22, 2016 at 11:59:59AM -0700, Chuck Guzis wrote:
[..]
> Something that's always bothered me about three-address architectures like
> ARM is why there is the insistence on that scheduling bottleneck, the
> condition code register? You can see how two-address architectures like the
> x80 and x86 try to get around the problem by having certain instructions not
> modify certain condition code bits and even have specialized instructions,
> such as JCXZ, that don't reply on a specific condition code.

> Anyone have a clue?

The condition code register can be treated as a regular register that partakes
in register renaming. Effectively, you have *many* CCRs in flight, so only
*reads* of the register may cause stalls. These reads are usually branches, so
there's branch prediction caches to try and deal with those stalls.

Unsurprisingly, the x86 ISA is brain-damaged here, in that some instructions
(e.g. inc") only affect some bits in EFLAGS, which causes a partial register
stall. The recommended "fix" is to avoid such instructions.

Eliminating condition codes just moves the complexity from the ALU to the
branch logic (which now needs its own mini-ALU for comparisons), and there's
not much in it either way. Where it *does* win is that the useful instructions
are all single-output and so one can use the noddy code generators found in
undergraduate-level compiler construction textbooks such as the Dragon Book.

Re: Reproduction micros

[Paul Koning]

> On Jul 22, 2016, at 8:10 PM, Cameron Kaiser  wrote:
> 
>>> It's not.  Peter is talking about a four-bit field in the
>>> instructions. You're talking about a six-bit field in the program
>>> counter.
>> 
>> Something that's always bothered me about three-address architectures
>> like ARM is why there is the insistence on that scheduling bottleneck,
>> the condition code register?  You can see how two-address architectures
>> like the x80 and x86 try to get around the problem by having certain
>> instructions not modify certain condition code bits
> 
> I realize I'm a broken record here, but PowerPC does the same thing. 

It seems that a great many things that some modern reporter thinks are new, or 
recent, and unusual, have been done in any number of places.  And possibly (as 
in this case) at least 20 years earlier than the reporter is aware of.

paul

Re: Reproduction micros

[Cameron Kaiser]

> > It's not.  Peter is talking about a four-bit field in the
> > instructions. You're talking about a six-bit field in the program
> > counter.
> 
> Something that's always bothered me about three-address architectures
> like ARM is why there is the insistence on that scheduling bottleneck,
> the condition code register?  You can see how two-address architectures
> like the x80 and x86 try to get around the problem by having certain
> instructions not modify certain condition code bits

I realize I'm a broken record here, but PowerPC does the same thing. You
have to ask for the bits to be updated (specialized forms like the "dot"
instructions) unless you do an explicit compare instruction, and in many
cases there is a special form to only update a certain set of bits instead
of them all (e.g., "addo" updates overflow but nothing else, "addo." does
overflow and CR bits, "addco." does carry too).

> and even have
> specialized instructions, such as JCXZ, that don't reply on a specific
> condition code.

... bdnz, which decrements CTR and branches if not zero, ...

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- "Use gun kata for fun! Because you worth it!" --

Re: Reproduction micros

[Adrian Graham]

On 22/07/2016 21:23, "Pete Turnbull"  wrote:

> On 22/07/2016 20:36, Adrian Graham wrote:
>> On 22/07/2016 10:04, "Pete Turnbull"  wrote:
> 
>>> If you have those, I would strongly recommend you arrange an offsite
>>> backup.  Say, about 170 miles north via the A14/A1 :-)
>> 
>> I remember why I've never fired them up, this is the label on the one with
>> the Beeb connecting podule:
>> 
>> http://binarydinosaurs.co.uk/acorna500label.jpg
>> 
>> Of course 'smoke' in these PSUs just means the mains cap has blown but I'm
>> not sure about the fizzing.
> 
> Well, those A500s use a standard Master 128 power supply.  I can fix
> that :-)

Feast your eyes. Not pictured are the Dark Matter keyboards because they're
in another room probably weighing something down so it won't fly away...

http://binarydinosaurs.co.uk/acorna500.jpg

It'd be interesting to see if the Rodimes in there power up and start given
their sticky head problems, the label on the other one says 'disc works,
contains lots of useful stuff'.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Reproduction micros

[Pete Turnbull]

On 22/07/2016 20:36, Adrian Graham wrote:

On 22/07/2016 10:04, "Pete Turnbull"  wrote:



If you have those, I would strongly recommend you arrange an offsite
backup.  Say, about 170 miles north via the A14/A1 :-)


I remember why I've never fired them up, this is the label on the one with
the Beeb connecting podule:

http://binarydinosaurs.co.uk/acorna500label.jpg

Of course 'smoke' in these PSUs just means the mains cap has blown but I'm
not sure about the fizzing.


Well, those A500s use a standard Master 128 power supply.  I can fix 
that :-)


--
Pete

Re: Reproduction micros

[Karl-Wilhelm Wacker]

If these are switching power supplies, the fizzing may be the output filter 
caps

overheating and about to pop their safety 'corks' due to self heating due to
high ripple currents.

I can across this probelm in a Clary Datacomp 404 computer that I worked
on in the late 60's.  The initial fix was a plastic sheild across the top of 
the caps
so that if they vented while a tech was working on the unit, they would not 
spew

the fluid inside them into the tech's face.

Karl

- Original Message - 
From: "Adrian Graham" <wit...@binarydinosaurs.co.uk>
To: "General Discussion: On-Topic and Off-Topic Posts" 
<cctalk@classiccmp.org>

Sent: Friday, July 22, 2016 3:36 PM
Subject: Re: Reproduction micros



On 22/07/2016 10:04, "Pete Turnbull" <p...@dunnington.plus.com> wrote:


On 22/07/2016 00:33, Adrian Graham wrote:

On 22/07/2016 00:07, "Liam Proven" <lpro...@gmail.com> wrote:


There were only a few
made.  They were used internally during development - hence the podule 
to
connect it to a Beeb, which provided the I/O early on - and in the 
later

stages before the Archimedes launch in 1987, several were loaned to
software
developers.


This is the machine Dick Pountain reviewed, I think.


Pretty sure I've got 2 of those, the keyboards are made of Dark Matter. 
I've

never dared power one up though.


If you have those, I would strongly recommend you arrange an offsite
backup.  Say, about 170 miles north via the A14/A1 :-)


I remember why I've never fired them up, this is the label on the one with
the Beeb connecting podule:

http://binarydinosaurs.co.uk/acorna500label.jpg

Of course 'smoke' in these PSUs just means the mains cap has blown but I'm
not sure about the fizzing.

--
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Reproduction micros

[Adrian Graham]

On 22/07/2016 10:04, "Pete Turnbull"  wrote:

> On 22/07/2016 00:33, Adrian Graham wrote:
>> On 22/07/2016 00:07, "Liam Proven"  wrote:
>> 
 There were only a few
 made.  They were used internally during development - hence the podule to
 connect it to a Beeb, which provided the I/O early on - and in the later
 stages before the Archimedes launch in 1987, several were loaned to
 software
 developers.
>>> 
>>> This is the machine Dick Pountain reviewed, I think.
>> 
>> Pretty sure I've got 2 of those, the keyboards are made of Dark Matter. I've
>> never dared power one up though.
> 
> If you have those, I would strongly recommend you arrange an offsite
> backup.  Say, about 170 miles north via the A14/A1 :-)

I remember why I've never fired them up, this is the label on the one with
the Beeb connecting podule:

http://binarydinosaurs.co.uk/acorna500label.jpg

Of course 'smoke' in these PSUs just means the mains cap has blown but I'm
not sure about the fizzing.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Reproduction micros

[Chuck Guzis]

On 07/21/2016 11:34 PM, Lars Brinkhoff wrote:

> It's not.  Peter is talking about a four-bit field in the
> instructions. You're talking about a six-bit field in the program
> counter.


Something that's always bothered me about three-address architectures
like ARM is why there is the insistence on that scheduling bottleneck,
the condition code register?  You can see how two-address architectures
like the x80 and x86 try to get around the problem by having certain
instructions not modify certain condition code bits and even have
specialized instructions, such as JCXZ, that don't reply on a specific
condition code.

Anyone have a clue?

--Chuck

Re: Reproduction micros

[Adam Sampson]

Lars Brinkhoff  writes:

> The link you posted above says "Sophie maintains that "inspired by"
> isn't the right choice of words." [...] I'm just genuinely curious
> exactly which features of the 6502 and ARM instruction sets people
> think are so alike?

I've always interpreted the "inspired by" description as being about
*how* the ARM was designed, rather than about the design itself. There's
a story Sophie Wilson's told in several interviews about a visit to
WDC...

>From The Inquirer:
http://www.theinquirer.net/inquirer/feature/1687452/birth-world-beater

| A visit Wilson and her colleague Steve Furber made to the Western
| Design Centre at Phoenix, Arizona, to check out a successor to the
| 6502 has passed into UK computing legend.
|
| The two British engineers, expecting high-tech buildings bristling
| with expert brains, were astonished to find just two developers
| working in a bungalow with "a bunch of college kids" on holiday
| jobs. "We came away thinking if they can do it, so can we."

Later in the same article:

| The instruction set, Wilson said, "came from that strange place inside
| my head where computer design comes from. Most engineers like to
| proceed from A to B to C in a series of logical steps. I'm the rare
| engineer who says the answer is obviously Z and we will get on with
| that while you guys work out how to do all the intermediate steps. It
| makes me a dangerous person to employ in IT but a useful one."

-- 
Adam Sampson  

Re: Reproduction micros

[Liam Proven]

On 22 July 2016 at 10:26, Pete Turnbull  wrote:
> I took that as "SA110 came in a plastic QFP, ..., with threaded shanks".
>
> I see that what you evidently meant was "the Alpha, which had threaded
> shanks".

Well, no, I meant to write exactly what I did write, drawing a
comparison between the two. However, you have made me aware of the
possible ambiguity in the sentence.


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Pete Turnbull]

On 22/07/2016 00:56, Paul Koning wrote:

PLCC and PQFP both are plastic packages with leads on all 4 sides.
But PLCC specifically means a package with J-leads: the legs come out
the package side, go straight down, and tuck under the package in a
J-shaped curve.  PQFP (and variations with similar acronyms) have
"gull wing" leads: out the side, down to near the board, and then
outward resting on the board.

SA110 is definitely PQFP.


The StrongARM data sheet does actually show all three types: PLCC, PQFP,
and PPGA.  All of mine are PPGA.

--
Pete

Re: Reproduction micros

[Peter Corlett]

On Thu, Jul 21, 2016 at 09:55:26PM -0600, ben wrote:
[...]
> A read and cuss item I see. Thank you, but it seems it is still big $$$ for
> good compiler to follow the ever changing rules.

Eh? The LLVM backend generates excellent code for at least x86 and ARM, and is
effectively BSD-licenced.

Re: Reproduction micros

[Pete Turnbull]

On 22/07/2016 00:33, Adrian Graham wrote:

On 22/07/2016 00:07, "Liam Proven"  wrote:


There were only a few
made.  They were used internally during development - hence the podule to
connect it to a Beeb, which provided the I/O early on - and in the later
stages before the Archimedes launch in 1987, several were loaned to software
developers.


This is the machine Dick Pountain reviewed, I think.


Pretty sure I've got 2 of those, the keyboards are made of Dark Matter. I've
never dared power one up though.


If you have those, I would strongly recommend you arrange an offsite 
backup.  Say, about 170 miles north via the A14/A1 :-)


--
Pete
Pete Turnbull

Re: Reproduction micros

[Pete Turnbull]

On 22/07/2016 00:07, Liam Proven wrote:

On 21 July 2016 at 23:26, Pete Turnbull 
wrote:



There were only a few made.  They were used internally during
development - hence the podule to connect it to a Beeb, which
provided the I/O early on - and in the later stages before the
Archimedes launch in 1987, several were loaned to software
developers.


This is the machine Dick Pountain reviewed, I think.


Indeed, the Personal Computer World August '87 article does mention he 
had an A500 on loan, though the photos are of an A310. They appear to me 
to be Acorn stock photos, which I remember being shot in June (IIRC) 1987.
  It seems he had an A310 by the time he wrote the article for Byte 
Vol.12 No.11, though.


--
Pete
Pete Turnbull

Re: Reproduction micros

[Pete Turnbull]

On 22/07/2016 00:07, Liam Proven wrote:

On 21 July 2016 at 23:26, Pete Turnbull 



Hmm.  Never seen one like that.  None of the ones I've seen in
real life are PQFPs, and none have a heatsink.


Perhaps you misread my message.


Ah, I misunderstood.  You wrote:


The SA110 came in a plastic QFP, and it came from the same company
and around the same time as the Alpha, with threaded shanks on the
packaging for screwing a heatsink into place. Spoke volumes. :-)


I took that as "SA110 came in a plastic QFP, ..., with threaded shanks".

I see that what you evidently meant was "the Alpha, which had threaded 
shanks".


--
Pete
Pete Turnbull

Re: Reproduction micros

[Lars Brinkhoff]

Liam Proven writes:
> Peter Corlett wrote:
>> In ARM, *all* instructions can be predicated. Because instructions
>> are 32 bits wide, it has the luxury of allocating four bits to select
>> from one of 16 possible predicates based on the CPU flags.
>
> If I understand it correctly, this caused considerable problems for
> the RISC OS people later. The original Acorn ARM machines used 26 bits
> of the program counter as the PC, and the rest as flags.
>
> I'm not sure this is the same phenomenon you're describing.

It's not.  Peter is talking about a four-bit field in the instructions.
You're talking about a six-bit field in the program counter.

Re: Reproduction micros

[Cameron Kaiser]

> An occasionally forgotten feature is that ALU operations also have a S-bit to
> indicate whether they should update the flags based on the result, or leave
> them alone.

Power ISA also has this feature (the so-called "dot" instructions). It also
has special forms of instructions for setting the overflow and carry flags,
when appropriate.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- "Garbage in -- gospel out" -

Re: Reproduction micros

[Guy Sotomayor Jr]

> On Jul 21, 2016, at 8:55 PM, ben  wrote:
> 
> On 7/21/2016 9:34 PM, Guy Sotomayor Jr wrote:
>> 
>>> On Jul 21, 2016, at 6:53 PM, ben  wrote:
>>> 
>>> On 7/20/2016 10:42 AM, Pete Turnbull wrote:
 On 20/07/2016 16:44, Paul Koning wrote:
 
> It is true that a few RISC architectures are not very scrutable.
> Itanium is a notorious example, as are some VLIW machines.  But many
> RISC machines are much more sane.  MIPS and ARM certainly are no
> problem for any competent assembly language programmer.
 
 Indeed.  I've written a modest amount of assembly language code for
 MIPS, and a bit more for ARM, and I didn't find either at all
 inscrutable.  Yes, be aware of pipelining and branches and so on, but
 it's not hard.
>>> 
>>> But alas , they seem to change cache and pipeline with every cpu
>>> starting with 386. How can one write effective programs for large
>>> data memory access, with out this knowledge?
>> 
>> You read the Intel Optimization Guide.
>> 
>> http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html
>> 
>> TTFN - Guy
> 
> A read and cuss item I see. Thank you, but it seems it is still big $$$
> for good compiler to follow the ever changing rules.

And yet they do.  Processors are getting more and more complex in order
to deliver power/performance improvements.  Larger caches with more ways,
deeper/wider pipes, more execution slots, number of rename registers, etc.

What do you expect?  TNSTAAFL if you want to extract every last cycle of
performance out of a particular uArch.  The good news is that most of the
time the uArch improvements work reasonably well with relatively non-specific
optimizations.

TTFN - Guy

Re: Reproduction micros

[ben]

On 7/21/2016 9:34 PM, Guy Sotomayor Jr wrote:



On Jul 21, 2016, at 6:53 PM, ben  wrote:

On 7/20/2016 10:42 AM, Pete Turnbull wrote:

On 20/07/2016 16:44, Paul Koning wrote:


It is true that a few RISC architectures are not very scrutable.
Itanium is a notorious example, as are some VLIW machines.  But many
RISC machines are much more sane.  MIPS and ARM certainly are no
problem for any competent assembly language programmer.


Indeed.  I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable.  Yes, be aware of pipelining and branches and so on, but
it's not hard.


But alas , they seem to change cache and pipeline with every cpu
starting with 386. How can one write effective programs for large
data memory access, with out this knowledge?


You read the Intel Optimization Guide.

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html

TTFN - Guy


A read and cuss item I see. Thank you, but it seems it is still big $$$
for good compiler to follow the ever changing rules.
Ben.

Re: Reproduction micros

[Guy Sotomayor Jr]

> On Jul 21, 2016, at 6:53 PM, ben  wrote:
> 
> On 7/20/2016 10:42 AM, Pete Turnbull wrote:
>> On 20/07/2016 16:44, Paul Koning wrote:
>> 
>>> It is true that a few RISC architectures are not very scrutable.
>>> Itanium is a notorious example, as are some VLIW machines.  But many
>>> RISC machines are much more sane.  MIPS and ARM certainly are no
>>> problem for any competent assembly language programmer.
>> 
>> Indeed.  I've written a modest amount of assembly language code for
>> MIPS, and a bit more for ARM, and I didn't find either at all
>> inscrutable.  Yes, be aware of pipelining and branches and so on, but
>> it's not hard.
> 
> But alas , they seem to change cache and pipeline with every cpu
> starting with 386. How can one write effective programs for large
> data memory access, with out this knowledge?

You read the Intel Optimization Guide.

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html

TTFN - Guy

Re: Reproduction micros

[ben]

On 7/20/2016 10:42 AM, Pete Turnbull wrote:

On 20/07/2016 16:44, Paul Koning wrote:


It is true that a few RISC architectures are not very scrutable.
Itanium is a notorious example, as are some VLIW machines.  But many
RISC machines are much more sane.  MIPS and ARM certainly are no
problem for any competent assembly language programmer.


Indeed.  I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable.  Yes, be aware of pipelining and branches and so on, but
it's not hard.


But alas , they seem to change cache and pipeline with every cpu
starting with 386. How can one write effective programs for large
data memory access, with out this knowlage?
Ben.

Re: Reproduction micros

[Chuck Guzis]

On 07/21/2016 04:56 PM, Paul Koning wrote:
> PLCCs have fairly limited lead counts; they were common for 44 lead
> packages, and perhaps a bit more.

I"ve probably got more 68 pin PLCCs than anything else; I've got various
ICs in 84 pin PLCC, including a some CPLDs and CPUs (e.g., 80C188EB).
The convenient part is that sockets are available to provide a
convenient 0.010" pin spacing by translating one row of pins to two and
removal/insertion is simple.   Probing for signals is likewise
straightforward.  After that you have to go to QFP/BGA (not terribly
socket-able) or PGA.  High pin-count packages are pretty large, however.

--Chuck

Re: Reproduction micros

[Paul Koning]

> On Jul 21, 2016, at 7:07 PM, Liam Proven  wrote:
> 
> ...
>>  They're all plastic pin grid array
>> packages.  No heatsink at all.  Nor does the datasheet for the PQFP show
>> anything related to a heatsink.  It also shows a PLCC version; no heatsink
>> there either, and again I've never seen one.  Maybe that's just because I
>> normally only saw them in Acorn machines, of course.
> 
> You seem to misunderstand my remark about heatsinks.
> 
> It is also possible that I am misusing the term "PQFP" but I have
> attempted to confirm it with Google image searches and I think it's
> what I meant.
> ...
> Is that not a PQFP chip? A flat plastic package with pins on all 4 sides?

PLCC and PQFP both are plastic packages with leads on all 4 sides.  But PLCC 
specifically means a package with J-leads: the legs come out the package side, 
go straight down, and tuck under the package in a J-shaped curve.  PQFP (and 
variations with similar acronyms) have "gull wing" leads: out the side, down to 
near the board, and then outward resting on the board.

SA110 is definitely PQFP.  Here's a PLCC for comparison:

http://www.batronix.com/images/products/chips/PLCC32-500-330.jpg

PLCCs have fairly limited lead counts; they were common for 44 lead packages, 
and perhaps a bit more.  PQFP goes well over 100, especially in the "fine 
pitch" ones with lead pitch under 1 mm.  (Pain in the *** to solder...)  Beyond 
what those can do, or for extra small packaging, we get BGA -- ball grid array.

paul

Re: Reproduction micros

[Adrian Graham]

On 22/07/2016 00:07, "Liam Proven"  wrote:

>> There were only a few
>> made.  They were used internally during development - hence the podule to
>> connect it to a Beeb, which provided the I/O early on - and in the later
>> stages before the Archimedes launch in 1987, several were loaned to software
>> developers.
> 
> This is the machine Dick Pountain reviewed, I think.

Pretty sure I've got 2 of those, the keyboards are made of Dark Matter. I've
never dared power one up though.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Reproduction micros

[Liam Proven]

On 21 July 2016 at 23:26, Pete Turnbull  wrote:

> Um, isn't that pretty much what I wrote?  I'm pretty sure the first
> batch(es) weren't rated for the full 200.

I don't know; I'm basing this comment mainly on Wikipedia.

>
> Hmm.  Never seen one like that.  None of the ones I've seen in real life are
> PQFPs, and none have a heatsink.

Perhaps you misread my message.

My point was that DEC's own Alpha RISC CPU was so dependent on good
cooling that the actual chip package included bolts to screw a
heatsink on.

In comparison, StrongARM, a DEC chip based on a licensed-in ISA,
needed so little cooling it shipped in a plastic package. No need for
ceramics here.

>   They're all plastic pin grid array
> packages.  No heatsink at all.  Nor does the datasheet for the PQFP show
> anything related to a heatsink.  It also shows a PLCC version; no heatsink
> there either, and again I've never seen one.  Maybe that's just because I
> normally only saw them in Acorn machines, of course.

You seem to misunderstand my remark about heatsinks.

It is also possible that I am misusing the term "PQFP" but I have
attempted to confirm it with Google image searches and I think it's
what I meant.

PQFP:

https://www.google.com/search?q=pqfp=off=lnms=isch=X=0ahUKEwjSy5jp04XOAhUCsxQKHdGLBZIQ_AUICCgB=1650=985

StrongARM SA110:

https://www.google.com/search?q=strongarm+sa110=off=lnms=isch=X=0ahUKEwiT-Mbv04XOAhXB1hQKHUb4CxQQ_AUICSgC=1650=985

Is that not a PQFP chip? A flat plastic package with pins on all 4 sides?

>>> I wish I'd kept an A500, though.  All I have now is the
>>> podule to connect it to a Beeb.  Anybody got the machine to put it in?
>>
>>
>> I have an A5000, near-new in box. But it's not been removed for about
>> 15y and I've no idea what working condition it's in. I could post it
>> to you when I'm next in the UK -- probably early next month. If you're
>> interested, make drop me a line off-list. It's in my storage unit in
>> South Wimbledon, where I have no power or anything, so I can't
>> plausibly get it out and test it.
>>
>> I am planning to move the rest of my stuff here to Czechia next month,
>> mainly for cost reasons due to the falling GBP. If you wished you
>> could come and meet me and inspect it in person?
>
>
> There's a thought.  I'd be up for that, though it's not actually an A5000 I
> meant; the A500 was the development system - looks rather like an A310 but
> without the fancy front bezel, and painted blue/grey.

Ah, sorry, that was my mistake!

> There were only a few
> made.  They were used internally during development - hence the podule to
> connect it to a Beeb, which provided the I/O early on - and in the later
> stages before the Archimedes launch in 1987, several were loaned to software
> developers.

This is the machine Dick Pountain reviewed, I think.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Liam Proven]

On 21 July 2016 at 22:22, Peter Corlett  wrote:
> On Wed, Jul 20, 2016 at 09:02:41PM +0200, Liam Proven wrote:
>> On 19 July 2016 at 17:04, Peter Corlett  wrote:
> [...]
>>> RISC implies a load-store architecture, so that claim is redundant.
>> Could you expand on that, please? I think that IKWYM but I'm not sure.
>
> A load-store architecture is one where the ALU only operates on registers. The
> name comes from having separate instructions to load registers from memory, 
> and
> store them to memory.
>
> The converse is register-memory, where ALU instructions can work directly on
> memory. However, this means that the instructions have to do quite a lot of
> work because now data has to be brought in from memory to an anonymous 
> register
> to be worked on and then stored back to the same location. This also results 
> in
> a proliferation of instruction and addressing mode combinations. Sounds rather
> CISCy, doesn't it?
>
> Meanwhile, a load-store architecture would have to decompose that into simpler
> independent load, operate, store instructions. Hey presto, RISC!

Thanks for that. It confirms, in a considerably clearer way, what I
had a dim apprehension of.

But load/store automatically RISC? Aren't there non-RISC load/store
processors, and indeed, RISC non-load/store ones?

> [...]
>>> IMO, it's the predicated instructions that is ARM's special sauce and the
>>> real innovation that gives it a performance boost. Without those, it'd be
>>> just a 32 bit wide 6502 knockoff.
>> Do tell...?
>
> You've already answered the "6502 knockoff" elsethread, so I assume you're
> asking about the predicated instructions.
>
> A predicated instruction is one that does or does not execute based on some
> condition. CISC machines generally use condition codes (aka flags), and only
> have predicated branch instructions. Branch-not-equal, that kind of things.
>
> In ARM, *all* instructions can be predicated. Because instructions are 32 bits
> wide, it has the luxury of allocating four bits to select from one of 16
> possible predicates based on the CPU flags. One predicate is "always" so one
> can also unconditionally execute instructions.

Aha. Interesting. This I did not know.

If I understand it correctly, this caused considerable problems for
the RISC OS people later. The original Acorn ARM machines used 26 bits
of the program counter as the PC, and the rest as flags. Later ARM
chips do not support this mode, and the OS had to be partially
rewritten for ARMs with a true 32-bit PC -- breaking binary
compatibility with 26-bit code.

I'm not sure this is the same phenomenon you're describing.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Phil Blundell]

On Thu, 2016-07-21 at 17:20 +0200, Liam Proven wrote:
> On 21 July 2016 at 16:45, Lars Brinkhoff  wrote:
> > I have both the ARM and the 6502 instruction sets very fresh in my mind
> > right now.  I don't see how the ARM could be a 6502 knockoff, even
> > without that sauce.  Care to explain in more detail?

> This is a matter of historical record, AIUI.

It's certainly an often-repeated claim but I don't think that
necessarily makes it true.  Clearly yes, Acorn had done a lot of work
with the 6502 previously, the original ARM architects were obviously
familiar with its instruction set, and there are some similarities in
terminology and conventional assembler mnemonics/syntax between the two.
But in terms of the actual structure of the instruction set it's hard to
see all that much that they really have in common.

6502 is a three-register machine with variable-length instructions that
require varying numbers of cycles to complete, complex and not entirely
orthogonal addressing modes (indirect addressing works differently for X
and Y), arithmetic instructions that operate on memory directly (INC
&1234), global flags which change the behaviour of instructions
("decimal" mode), dedicated instructions for stack manipulation, no
direct ALU access to the program counter or stack pointer, and no
predication other than on branches.

ARM was, in its original incarnation at least, a 16-register machine (of
which 2 registers are architecturally special) with fixed-length
instructions, almost-entirely orthogonal addressing modes, memory access
restricted to dedicated load/store instructions, support for direct ALU
operation on the program counter (albeit with slightly weird semantics
due to early implementation decisions), no specific
architecturally-defined stack, and explicit predication on every
instruction, again orthogonal to the operation itself (even to the point
of reserving 268 million of the possible instruction patterns for "never
execute" instructions that were effectively NOPs).  

So it's certainly not a trivial derivative or imitation of the 6502 in
the way that "knockoff" might imply, and even without the predication
the architectures would still be quite different.  Obviously though the
ARM architecture has evolved somewhat over the past three decades and
not all the points above are still true of the latest versions.

FWIW there are now at least a few 32-bit CPU designs floating around
that really are stretched 6502s, usually including binary compatibility
with old 8-bit programs, and could legitimately be called "knock-offs".

p.

Re: Reproduction micros

[Pete Turnbull]

On 21/07/2016 15:12, Liam Proven wrote:

On 21 July 2016 at 15:24, Pete Turnbull  wrote:


But a StrongARM [ ... ] initially ran 3 times as
fast [ ... ] and eventually SA-110 ran to over 200MHz) yet
uses less power.



OK. I think the first announced StrongARM, the SA110, was announced as
running at 100, 133 and 200, mind you.


Um, isn't that pretty much what I wrote?  I'm pretty sure the first 
batch(es) weren't rated for the full 200.



But the point about transistor count is well made. For the casual, it
was displayed by the packaging. The SA110 came in a plastic QFP, and
it came from the same company and around the same time as the Alpha,
with threaded shanks on the packaging for screwing a heatsink into
place. Spoke volumes. :-)


Hmm.  Never seen one like that.  None of the ones I've seen in real life 
are PQFPs, and none have a heatsink.  They're all plastic pin grid array 
packages.  No heatsink at all.  Nor does the datasheet for the PQFP show 
anything related to a heatsink.  It also shows a PLCC version; no 
heatsink there either, and again I've never seen one.  Maybe that's just 
because I normally only saw them in Acorn machines, of course.



I wish I'd kept an A500, though.  All I have now is the
podule to connect it to a Beeb.  Anybody got the machine to put it in?


I have an A5000, near-new in box. But it's not been removed for about
15y and I've no idea what working condition it's in. I could post it
to you when I'm next in the UK -- probably early next month. If you're
interested, make drop me a line off-list. It's in my storage unit in
South Wimbledon, where I have no power or anything, so I can't
plausibly get it out and test it.

I am planning to move the rest of my stuff here to Czechia next month,
mainly for cost reasons due to the falling GBP. If you wished you
could come and meet me and inspect it in person?


There's a thought.  I'd be up for that, though it's not actually an 
A5000 I meant; the A500 was the development system - looks rather like 
an A310 but without the fancy front bezel, and painted blue/grey.  There 
were only a few made.  They were used internally during development - 
hence the podule to connect it to a Beeb, which provided the I/O early 
on - and in the later stages before the Archimedes launch in 1987, 
several were loaned to software developers.


--
Pete

Re: Reproduction micros

[Lars Brinkhoff]

Liam Proven  writes:
> On 21 July 2016 at 16:45, Lars Brinkhoff  wrote:
>> I have both the ARM and the 6502 instruction sets very fresh in my mind
>> right now.  I don't see how the ARM could be a 6502 knockoff, even
>> without that sauce.  Care to explain in more detail?
>
> This is a matter of historical record, AIUI.
> http://forum.6502.org/viewtopic.php?t=1892

I know it's a widely circulated claim, but I haven't seen much evidence
for it.  The link you posted above says "Sophie maintains that "inspired
by" isn't the right choice of words."  In which case I suppose
"knockoff" is even less right.

I'm just genuinely curious exactly which features of the 6502 and ARM
instruction sets people think are so alike?  Please, name specific
details!

Re: Reproduction micros

[Paul Koning]

> On Jul 21, 2016, at 4:22 PM, Peter Corlett  wrote:
> 
> ...
> A predicated instruction is one that does or does not execute based on some
> condition. CISC machines generally use condition codes (aka flags), and only
> have predicated branch instructions. Branch-not-equal, that kind of things.
> 
> In ARM, *all* instructions can be predicated. Because instructions are 32 bits
> wide, it has the luxury of allocating four bits to select from one of 16
> possible predicates based on the CPU flags. One predicate is "always" so one
> can also unconditionally execute instructions.
> 
> An occasionally forgotten feature is that ALU operations also have a S-bit to
> indicate whether they should update the flags based on the result, or leave
> them alone.

I didn't realize that.  This feature makes it more like the Electrologica 
machines, which invented this approach back in 1958.

paul

Re: Reproduction micros

[Paul Koning]

> On Jul 21, 2016, at 4:22 PM, Peter Corlett  wrote:
> 
> On Wed, Jul 20, 2016 at 09:02:41PM +0200, Liam Proven wrote:
>> On 19 July 2016 at 17:04, Peter Corlett  wrote:
> [...]
>>> RISC implies a load-store architecture, so that claim is redundant.
>> Could you expand on that, please? I think that IKWYM but I'm not sure.
> 
> A load-store architecture is one where the ALU only operates on registers. The
> name comes from having separate instructions to load registers from memory, 
> and
> store them to memory.
> 
> The converse is register-memory, where ALU instructions can work directly on
> memory. However, this means that the instructions have to do quite a lot of
> work because now data has to be brought in from memory to an anonymous 
> register
> to be worked on and then stored back to the same location. This also results 
> in
> a proliferation of instruction and addressing mode combinations. Sounds rather
> CISCy, doesn't it?
> 
> Meanwhile, a load-store architecture would have to decompose that into simpler
> independent load, operate, store instructions. Hey presto, RISC!

I would point out that RISC is not a goal in itself.  Instead, the reason RISC 
is interesting is that -- at least at some point in the evolution of technology 
-- it was an architecture approach that results in more cost effective 
computers.  That is, faster for the same money or less expensive for a given 
speed.

It's easy to be led to the equivalence "register-memory instructions" == 
"complex instructions". If you're most familiar with Intel x86, or even saner 
architectures like VAX (which have memory to memory instructions, with a pile 
of addressing modes), that seems plausible.  But, for example, the PDP-8 has 
register-memory instructions but it has a very simple instruction set and can 
be implemented in a tiny amount of logic.  Similarly, register-memory 
instruction sets were used in many older architectures, and clearly were easy 
to do -- if your logic is tubes, you're not likely to implement large execution 
units!  Even machines like the CDC 6000 peripheral processors, which have a 
pile of extra logic for controlling the CPU and surprising features like a 
barrel shifter, take only a few thousand gates.

paul

Re: Reproduction micros

[Ryan K. Brooks]

In ARM, *all* instructions can be predicated.

Until recently.

Re: Reproduction micros

[Peter Corlett]

On Wed, Jul 20, 2016 at 09:02:41PM +0200, Liam Proven wrote:
> On 19 July 2016 at 17:04, Peter Corlett  wrote:
[...]
>> RISC implies a load-store architecture, so that claim is redundant.
> Could you expand on that, please? I think that IKWYM but I'm not sure.

A load-store architecture is one where the ALU only operates on registers. The
name comes from having separate instructions to load registers from memory, and
store them to memory.

The converse is register-memory, where ALU instructions can work directly on
memory. However, this means that the instructions have to do quite a lot of
work because now data has to be brought in from memory to an anonymous register
to be worked on and then stored back to the same location. This also results in
a proliferation of instruction and addressing mode combinations. Sounds rather
CISCy, doesn't it?

Meanwhile, a load-store architecture would have to decompose that into simpler
independent load, operate, store instructions. Hey presto, RISC!

[...]
>> IMO, it's the predicated instructions that is ARM's special sauce and the
>> real innovation that gives it a performance boost. Without those, it'd be
>> just a 32 bit wide 6502 knockoff.
> Do tell...?

You've already answered the "6502 knockoff" elsethread, so I assume you're
asking about the predicated instructions.

A predicated instruction is one that does or does not execute based on some
condition. CISC machines generally use condition codes (aka flags), and only
have predicated branch instructions. Branch-not-equal, that kind of things.

In ARM, *all* instructions can be predicated. Because instructions are 32 bits
wide, it has the luxury of allocating four bits to select from one of 16
possible predicates based on the CPU flags. One predicate is "always" so one
can also unconditionally execute instructions.

An occasionally forgotten feature is that ALU operations also have a S-bit to
indicate whether they should update the flags based on the result, or leave
them alone.

Between these, a conditional branch over a handful of instructions can be
replaced by making those instructions predicated, and the S bit set to not
update the flags. Not only has the conditional branch been deleted completely
from the instruction stream which makes code noticably more compact, but
there's now no branch-induced pipeline stall. Specila sauce.

Unsurprisingly, x86 eventually noticed this sort of thing is useful and pinched
the idea, but did it in the usual half-arsed fashion that it is famous for.

Re: Reproduction micros

[Liam Proven]

On 21 July 2016 at 16:45, Lars Brinkhoff  wrote:
> I have both the ARM and the 6502 instruction sets very fresh in my mind
> right now.  I don't see how the ARM could be a 6502 knockoff, even
> without that sauce.  Care to explain in more detail?


This is a matter of historical record, AIUI.

http://forum.6502.org/viewtopic.php?t=1892

There's a little more here:

http://www.theregister.co.uk/2012/05/03/unsung_heroes_of_tech_arm_creators_sophie_wilson_and_steve_furber/

In essence, Wilson designed it and Furber implemented it. Wilson knew
6502 inside-out and had been designing 6502 systems while still a
student, before Acorn existed, so it inspired the ARM ISA, rather than
ARM actually being based on it.

6502 is widely held as being, if not actually RISC, then at least
RISC-like, or as Brits put it, RISCy.

http://everything2.com/title/6502

https://news.ycombinator.com/item?id=11703717


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Lars Brinkhoff]

Peter Corlett  writes:
> IMO, it's the predicated instructions that is ARM's special sauce and
> the real innovation that gives it a performance boost. Without those,
> it'd be just a 32 bit wide 6502 knockoff.

I have both the ARM and the 6502 instruction sets very fresh in my mind
right now.  I don't see how the ARM could be a 6502 knockoff, even
without that sauce.  Care to explain in more detail?

Re: Reproduction micros

[Paul Koning]

> On Jul 21, 2016, at 8:38 AM, Liam Proven  wrote:
> 
> On 20 July 2016 at 21:29, Paul Koning  wrote:
>> I don't remember the earlier ARM designs, but it was my impression that 
>> DEC's StrongARM was the one that made really large strides in low power 
>> (especially power per MHz of clock speed).  Interestingly enough, StrongARM 
>> was one of the few (and the first?) independent designs; it used the ARM 
>> architecture specification but not the actual logic design as others did.
> 
> Hmm. That wasn't my impression at the time, no.
> 
> ...
> So at least in the marketing to the Acorn user community, no, power
> draw wasn't even mentioned. It never came up. The original ARMs were
> low-power, and so was StrongARM.

Remember that the marketing in question was DEC marketing, well known for its 
utter ineptitude.  That had its origin in Ken Olsen's belief that marketing 
wasn't really needed (and, for that matter, that sales people didn't need to be 
paid commission).

I very definitely remember discussions at the time about the unprecedented 
power/bandwidth value delivered by the SA110.  "One mW per MIPS" is one phrase 
that I remember from that time.

paul

Re: Reproduction micros

[Liam Proven]

On 21 July 2016 at 15:24, Pete Turnbull  wrote:
>
> Yes and no.  StrongARM was even lower power as well as faster.  If you're
> suggesting that that's just evolution due to things like reduced process
> size, I possibly agree.  But a StrongARM has many times as many transistors
> as an ARM3 (for example) let alone an ARM2, and initially ran 3 times as
> fast (100MHz vs 33MHz - the earliest ARM3s were 20MHz, but production runs
> were 25MHz and later 33MHz, and eventually SA-110 ran to over 200MHz) yet
> uses less power.  I don't have the data sheets for ARM6 and ARM7 so I can't
> compare, though.

OK. I think the first announced StrongARM, the SA110, was announced as
running at 100, 133 and 200, mind you.

But the point about transistor count is well made. For the casual, it
was displayed by the packaging. The SA110 came in a plastic QFP, and
it came from the same company and around the same time as the Alpha,
with threaded shanks on the packaging for screwing a heatsink into
place. Spoke volumes. :-)


> As for the marketing, I recently came across an Acorn press release
> announcing ARM, in which Sam Wauchope (CEO) was quoted saying it delivered
> 100MIPS per watt, so power was indeed a selling point.  I worked for Sam at
> the time[1], so I remember that.  OK that's for one of the Acorn ARM chips,
> not StrongARM, but the point is still made.  Not all the marketing was
> directed at the Acorn community.

Fair dos!

> [1] and I still have my Archimedes A310 Serial No. 002 (and the box with
> all the bits and pieces :-)) as well as my A410 and R260, both from the
> first batches.  I wish I'd kept an A500, though.  All I have now is the
> podule to connect it to a Beeb.  Anybody got the machine to put it in?

I have an A5000, near-new in box. But it's not been removed for about
15y and I've no idea what working condition it's in. I could post it
to you when I'm next in the UK -- probably early next month. If you're
interested, make drop me a line off-list. It's in my storage unit in
South Wimbledon, where I have no power or anything, so I can't
plausibly get it out and test it.

I am planning to move the rest of my stuff here to Czechia next month,
mainly for cost reasons due to the falling GBP. If you wished you
could come and meet me and inspect it in person?



-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Pete Turnbull]

On 21/07/2016 13:38, Liam Proven wrote:

On 20 July 2016 at 21:29, Paul Koning 
wrote:

I don't remember the earlier ARM designs, but it was my impression
that DEC's StrongARM was the one that made really large strides in
low power



Hmm. That wasn't my impression at the time, no.

The big deal with StrongARM was that it had a dramatically increased
speed -- whereas Acorn ARMs ran from 8MHz in my original Archimedes
A305 to 12MHz for the first SoC ones (A3010 with ARM 250) to 25MHz
for the ARM3-powered A5000, Digital's first StrongARM ran at
100-200MHz. To keep the core fed with data at this ridiculous speed,
it had onboard L1 instruction & data caches.



So at least in the marketing to the Acorn user community, no, power
draw wasn't even mentioned. It never came up. The original ARMs were
low-power, and so was StrongARM.


Yes and no.  StrongARM was even lower power as well as faster.  If 
you're suggesting that that's just evolution due to things like reduced 
process size, I possibly agree.  But a StrongARM has many times as many 
transistors as an ARM3 (for example) let alone an ARM2, and initially 
ran 3 times as fast (100MHz vs 33MHz - the earliest ARM3s were 20MHz, 
but production runs were 25MHz and later 33MHz, and eventually SA-110 
ran to over 200MHz) yet uses less power.  I don't have the data sheets 
for ARM6 and ARM7 so I can't compare, though.


As for the marketing, I recently came across an Acorn press release 
announcing ARM, in which Sam Wauchope (CEO) was quoted saying it 
delivered 100MIPS per watt, so power was indeed a selling point.  I 
worked for Sam at the time[1], so I remember that.  OK that's for one of 
the Acorn ARM chips, not StrongARM, but the point is still made.  Not 
all the marketing was directed at the Acorn community.


[1] and I still have my Archimedes A310 Serial No. 002 (and the box 
with all the bits and pieces :-)) as well as my A410 and R260, both from 
the first batches.  I wish I'd kept an A500, though.  All I have now is 
the podule to connect it to a Beeb.  Anybody got the machine to put it in?


--
Pete
Pete Turnbull

Re: Reproduction micros

[Liam Proven]

On 20 July 2016 at 21:29, Paul Koning  wrote:
> I don't remember the earlier ARM designs, but it was my impression that DEC's 
> StrongARM was the one that made really large strides in low power (especially 
> power per MHz of clock speed).  Interestingly enough, StrongARM was one of 
> the few (and the first?) independent designs; it used the ARM architecture 
> specification but not the actual logic design as others did.

Hmm. That wasn't my impression at the time, no.

The big deal with StrongARM was that it had a dramatically increased
speed -- whereas Acorn ARMs ran from 8MHz in my original Archimedes
A305 to 12MHz for the first SoC ones (A3010 with ARM 250) to 25MHz for
the ARM3-powered A5000, Digital's first StrongARM ran at 100-200MHz.
To keep the core fed with data at this ridiculous speed,  it had
onboard L1 instruction & data caches.

http://www.zdnet.com/pictures/decs-40-years-of-innovation/10/

https://www.netogram.com/strongarmprocessor.htm

Original PR:

http://www.cpushack.com/CIC/embed/announce/DigitalStrongARMIntro.html

Self-modifying code could write back to and thus run from the cache
before it was propagated to the main RAM, which meant that some RISC
OS code had to be rewritten.

E.g. http://www.riscos.com/ftp_space/370/index.htm

The "Kinetic" StrongARM upgrade for the RISC PC therefore had RAM on
the CPU daughterboard, as the motherboard RAM was not even close to
fast enough.

http://www.riscos.info/index.php/Kinetic

So at least in the marketing to the Acorn user community, no, power
draw wasn't even mentioned. It never came up. The original ARMs were
low-power, and so was StrongARM.

StrongARM wasn't a big win for the Newton, inasmuch as the Original
MessagePad (OMP) had an ARM610 in it. The Newton 2000 was the first
model with a StrongARM but it was merely an upgraded CPU for the newer
hardware.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 6:28 PM, Pete Turnbull  wrote:
> 
> On 20/07/2016 20:29, Paul Koning wrote:
> 
>> I don't remember the earlier ARM designs, but it was my impression
>> that DEC's StrongARM was the one that made really large strides in
>> low power (especially power per MHz of clock speed).  Interestingly
>> enough, StrongARM was one of the few (and the first?) independent
>> designs; it used the ARM architecture specification but not the
>> actual logic design as others did.
> 
> That's almost right.  An ARM2 dissipates less than 2W (according to my data 
> sheet, but that's maximum allowed dissipation and I think typical consumption 
> is much less than 1W) with its normal 5V supply, averaging some 6-8 MIPS with 
> a 12MHZ clock.  It's a 2micron CMOS process.  The original ARM used a 3micron 
> process but was only used for testing and development; I can't remember what 
> ARM3 used but IIRC it was a lot smaller though still the same core design, 
> and it's certainly low power (under 1W) despite having a lot more transistors 
> (largely for cache) and a higher clock speed.
> 
> StrongARM SA-110 uses roughly 450mW, but with Vcc around 1.75V it claimed 
> about 100 MIPS at 100MHz, in a 0.35micron process.  It was a collaboration 
> between ARM and Digital, but AIUI the hardware design was done mainly or 
> perhaps completely by Digital.  Yes, it was the first independent design, as 
> far as I know.  Earliest designs were done by Acorn and later I think by 
> Acorn with VLSI, and ARM with Digital (ARM6/7).  I had access to early SA-110 
> development stuff for a project in 1996 but I had to go to Digital to get it, 
> not Acorn/ARM.

Thanks for the backup data.  I have the impression that power gating and clock 
gating (essentially only running small parts of the chip rather than all of it 
all the time) is one big reason why the SA-110 is so power-efficient.

I still have an SA-110 eval board tucked away in the workshop.

paul

Re: Reproduction micros

[Pete Turnbull]

On 20/07/2016 20:29, Paul Koning wrote:


I don't remember the earlier ARM designs, but it was my impression
that DEC's StrongARM was the one that made really large strides in
low power (especially power per MHz of clock speed).  Interestingly
enough, StrongARM was one of the few (and the first?) independent
designs; it used the ARM architecture specification but not the
actual logic design as others did.


That's almost right.  An ARM2 dissipates less than 2W (according to my 
data sheet, but that's maximum allowed dissipation and I think typical 
consumption is much less than 1W) with its normal 5V supply, averaging 
some 6-8 MIPS with a 12MHZ clock.  It's a 2micron CMOS process.  The 
original ARM used a 3micron process but was only used for testing and 
development; I can't remember what ARM3 used but IIRC it was a lot 
smaller though still the same core design, and it's certainly low power 
(under 1W) despite having a lot more transistors (largely for cache) and 
a higher clock speed.


StrongARM SA-110 uses roughly 450mW, but with Vcc around 1.75V it 
claimed about 100 MIPS at 100MHz, in a 0.35micron process.  It was a 
collaboration between ARM and Digital, but AIUI the hardware design was 
done mainly or perhaps completely by Digital.  Yes, it was the first 
independent design, as far as I know.  Earliest designs were done by 
Acorn and later I think by Acorn with VLSI, and ARM with Digital 
(ARM6/7).  I had access to early SA-110 development stuff for a project 
in 1996 but I had to go to Digital to get it, not Acorn/ARM.


--
Pete

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 3:02 PM, Liam Proven  wrote:
> 
> ...
> I think it's fair to say that ARM was a relatively early RISC
> implementation *in term of single chip processors*, that it was
> remarkably simple compared to others of that time (as in, smaller,
> more reduced, fewer transistors, etc.), that its power consumption
> always was remarkably low and its performance, for its first decade or
> so, remarkably high.

I don't remember the earlier ARM designs, but it was my impression that DEC's 
StrongARM was the one that made really large strides in low power (especially 
power per MHz of clock speed).  Interestingly enough, StrongARM was one of the 
few (and the first?) independent designs; it used the ARM architecture 
specification but not the actual logic design as others did.

paul

Re: Reproduction micros

[Liam Proven]

On 19 July 2016 at 17:04, Peter Corlett  wrote:
> From there, it seems to be saying that the essence of the invention is that 
> the
> ARM ISA is RISC, it is a load-store architecture, and the CPU was pipelined.
>
> RISC implies a load-store architecture, so that claim is redundant.

Could you expand on that, please? I think that IKWYM but I'm not sure.

> Pipelining is an older idea: the 1979-vintage 68000 does it, and the 
> 1982-vintage
> 68010 even detects certain string/loop instructions in its pipeline and avoids
> re-fetching them from memory when repeating the sequence.

I don't think that article or anything else is claiming that ARM
invented RISC, was the first RISC processor, or even significantly
advanced the RISC art.

What is says is that ARM was built by a very small team -- which it
was. That part of that is that Wilson did a lot of the design
single-handed -- which is true.

I don't know about her simulating the design in her head; from what
I've heard from several sources, including Wilson herself in a talk at
ROUGOL, was that the first simulation of the ARM instruction set was a
BBC BASIC program running on a BBC Micro. That in itself is quite
remarkable.

I think it's fair to say that ARM was a relatively early RISC
implementation *in term of single chip processors*, that it was
remarkably simple compared to others of that time (as in, smaller,
more reduced, fewer transistors, etc.), that its power consumption
always was remarkably low and its performance, for its first decade or
so, remarkably high.

> IMO, it's the predicated instructions that is ARM's special sauce and the real
> innovation that gives it a performance boost. Without those, it'd be just a 32
> bit wide 6502 knockoff.

Do tell...?


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Liam Proven]

On 20 July 2016 at 19:34, Cameron Kaiser  wrote:
>> Also, RISC does not use, or need, microcode.
>
> I'm not sure what you mean by this, but (for example) many POWER
> implementations have microcode (example: the 970/G5, which is descended from
> POWER4).

Isn't the general belief that many successful architectures that
started out as RISC, and are still marketed as RISC, aren't actually
very RISC-like at all any more?

And, secondarily, that ARM is one of the ones that has stayed closest
to its roots, unlike, e.g., POWER, SPARC and, well, most of the big
hot UNIX workstation chips of the '90s?


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Liam Proven]

On 20 July 2016 at 17:44, Paul Koning  wrote:
> It is true that a few RISC architectures are not very scrutable.  Itanium is 
> a notorious example, as are some VLIW machines.


Hang on. Itanium is not RISC -- it *is* VLIW. Isn't it?

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Cameron Kaiser]

> > > Also, RISC does not use, or need, microcode.
> > 
> > I'm not sure what you mean by this, but (for example) many POWER
> > implementations have microcode (example: the 970/G5, which is descended from
> > POWER4).
> 
> What I meant is that I had no idea such things existed.  Very curious.
> Learn something new every day.  What do they use this for?

A number of instructions on G5 processors are broken down into smaller
uops which are sequenced, and affect execution flow and instruction level
parallelism. The microcode used by the uops is purely internal to the chip
and is stored in a sidecar ROM. Part of my optimizing code for G5 systems
was to avoid microcoded/cracked instructions as much as possible except
where there was no alternative for functionality.

The Cell PPU, also Power ISA, also contains microcoded instructions and
they have similar penalties.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- I've had a wonderful time, but this wasn't it. -- Groucho Marx -

Re: Reproduction micros

[Al Kossow]

On 7/20/16 10:34 AM, Cameron Kaiser wrote:
>> Also, RISC does not use, or need, microcode.
> 

this confuses architecture and implementation

the Ridge 32 has a RISC instruction set, but was implemented in micrcode

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 1:53 PM, Swift Griggs  wrote:
> 
> On Wed, 20 Jul 2016, Paul Koning wrote:
>> The closest to microcode I'd ever heard of before is the "epicode" in 
>> Alpha.  Or was that Prism?
> 
> PALcode? That's sort of an amalgamation of microcode and emulation, IIRC. 
> I don't know what 'epicode' is, though.

PALcode sounds right.  I think "epicode" was the same thing, but in PRISM -- 
which was the second RISC chip architecture DEC built, and canceled before 
shipping it.  (Titan was the first; Alpha the third.)

paul

Re: Reproduction micros

[Swift Griggs]

On Wed, 20 Jul 2016, Paul Koning wrote:
> The closest to microcode I'd ever heard of before is the "epicode" in 
> Alpha.  Or was that Prism?

PALcode? That's sort of an amalgamation of microcode and emulation, IIRC. 
I don't know what 'epicode' is, though.

-Swift

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 1:34 PM, Cameron Kaiser  wrote:
> 
>> Also, RISC does not use, or need, microcode.
> 
> I'm not sure what you mean by this, but (for example) many POWER
> implementations have microcode (example: the 970/G5, which is descended from
> POWER4).

What I meant is that I had no idea such things existed.  Very curious.  Learn 
something new every day.  What do they use this for?

The closest to microcode I'd ever heard of before is the "epicode" in Alpha.  
Or was that Prism?  Anyway, a DEC RISC architecture where some privileged stuff 
was done in code running in a corner of the chip.  Not actual microcode because 
it was essentially the standard instruction set, somewhat extended and running 
in a special processor state.

paul

Re: Reproduction micros

[Cameron Kaiser]

> Also, RISC does not use, or need, microcode.

I'm not sure what you mean by this, but (for example) many POWER
implementations have microcode (example: the 970/G5, which is descended from
POWER4).

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- There are three kinds of people: those who can count and those who can't. --

RISC assembly by hand dammit was Re: Reproduction micros

[Cameron Kaiser]

> > It is true that a few RISC architectures are not very scrutable.
> > Itanium is a notorious example, as are some VLIW machines.  But many
> > RISC machines are much more sane.  MIPS and ARM certainly are no
> > problem for any competent assembly language programmer.
> 
> Indeed.  I've written a modest amount of assembly language code for 
> MIPS, and a bit more for ARM, and I didn't find either at all 
> inscrutable.  Yes, be aware of pipelining and branches and so on, but 
> it's not hard.

I actually find PowerPC assembly very tractable. No branch delay slots,
for example, and reasonable orthogonality. The major thing that's annoying
about it is the "mscdfr" instructions (Means Something Completely Different
For r0 -- addi(s), for example). I've handwritten a great deal of PPC
assembly over the years, and even written a JIT for it.

The late PA-RISC was also a very sane ISA to handwrite assembly in.

SPARC is a little tricky with the register windows, but I guess that's
really no different than writing for any other particular ABI.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Po-Ching Lives! 

Re: Reproduction micros

[Pete Turnbull]

On 20/07/2016 16:44, Paul Koning wrote:


It is true that a few RISC architectures are not very scrutable.
Itanium is a notorious example, as are some VLIW machines.  But many
RISC machines are much more sane.  MIPS and ARM certainly are no
problem for any competent assembly language programmer.


Indeed.  I've written a modest amount of assembly language code for 
MIPS, and a bit more for ARM, and I didn't find either at all 
inscrutable.  Yes, be aware of pipelining and branches and so on, but 
it's not hard.


--
Pete

Re: Reproduction micros

[Paul Koning]

> On Jul 20, 2016, at 9:56 AM, Noel Chiappa  wrote:
> 
>> From: Paul Koning
> 
>>> I always felt that RISC meant 'making the basic cycle time as fast as
>>> possible by finding the longest path through the logic - i.e.  the
>>> limiting factor on the cycle time - and removing it (thereby making the
>>> instruction set less rich); then repeat'.
> 
>> "Making the cycle time as fast as possible" certainly applies, in
>> spades, to the 6600.  The deeper you dig into its details, the more
>> impressed you will be by the many different ways in which it does things
>> faster than you would expect to be possible.
> 
> My formulation for RISC had two parts, though: not just minizing the cycle
> time, but doing so by doing things that (as a side-effect) make the
> instruction set less capable. I'm not very familiar with the 6600 - does this
> part apply too?

Depending on what you mean by "less capable", I don't know that I would agree 
with that.  For example, I doubt that anyone would argue MIPS isn't a RISC 
architecture.  Yet MIPS is certainly very capable, and it certainly has a 
rather large instruction set.  The key point is that those instructions are, by 
and large, conceptually straightforward, and lend themselves to efficient 
(small cycle count, small transistor count) implementation.  Also, RISC does 
not use, or need, microcode.

In that sense, the 6000 certainly qualifies.  It has load/store, integer and 
float arithmetic on registers, boolean ops, and basic transfer of control 
instructions.  That's about it.  And the implementation is certainly 
straightforward.  A 6600 has a fair number of gates, but that stems from its 
multiple functional units, memory scheduling, and intense emphasis on speed, 
not from the inherent complexity of its instruction set.  A 6400, which is a 
single functional unit implementation of the same instruction set, is a whole 
lot smaller.

I recommend the excellent (and rather short) book by Thornton, one of the 6600 
designers: 
http://bitsavers.trailing-edge.com/pdf/cdc/cyber/books/DesignOfAComputer_CDC6600.pdf
  It will take you through the design all the way from transistor 
considerations and circuit elements to the instruction and memory scheduling 
machinery.

>>> RISC only makes (system-wide) sense in an environment in which memory
>>> bandwidth is plentiful (so that having programs contain more, simpler
>>> instructions make sense)
> 
> I should have pointed out that programs of that sort take not just more memory
> bandwidth, but more memory to hold them. In this day of massive memories, no
> biggie, but back in the core memory days, it was more of an issue.

I don't think that's necessarily all that big a delta.  Again using MIPS as an 
example, its program sizes are not that much larger than, say, the PDP11 for 
the same source code. 
> ...
>> I think a lot of machine designers, though not all, were seriously
>> interested in making them go fast.
> 
> Again, RISC has two legs, not just making the machine fast, but making them
> fast by using techniques that, as a side-effect, make them inscrutable, and
> difficult to program. The concept was that they would not, in general, be
> programmed in assembler - precisely because they were so finicky.

It is true that a few RISC architectures are not very scrutable.  Itanium is a 
notorious example, as are some VLIW machines.  But many RISC machines are much 
more sane.  MIPS and ARM certainly are no problem for any competent assembly 
language programmer.   Alpha is a bit harder but definitely doable too.

The burden on compiler optimizers tends to be higher.  But I would argue that's 
true for any high performance design: those have multiple pipelines, caches and 
prefetch, and lots of other stuff that affects performance.  The code optimizer 
has to know about these things.  (So does the assembly language programmer, if 
assembly is used for performance rather than for esoteric bare metal stuff like 
boot or diagnostic code.)  But, with the possible exception of extremely 
bizarre designs like Itanium, that's all perfectly doable.

paul

Re: Reproduction micros

[Pete Turnbull]

On 20/07/2016 14:56, Noel Chiappa wrote:


My formulation for RISC had two parts, though: not just minizing the cycle
time, but doing so by doing things that (as a side-effect) make the
instruction set less capable.


At least for some RISC, that's more than a side effect.  While at Acorn 
in about 1987, I attended talks run by Sophie Wilson and Steve Furber 
where they described some of the design criteria for ARM.  They were 
very clear that the design goal was for every instruction to be executed 
in a single cycle[1], not just discarding longer instructions.  Thus the 
process wasn't about removing instructions but rather about deciding 
what (instructions and hardware) to put in as necessary and useful, so 
that more complex operations could be built up from short sequences of 
very fast instructions.  Kind of like the Unix philosophy of pipelining 
small utilities, in a way.


They also studied what had gone before: IBM 801, the Berkeley RISC 
project, Clipper, and others.  Steve describes some of this in his book 
"VLSI RISC Architecture and Organisation", which is a good read if you 
can find a copy.


[1] actually it's three clock cycles - fetch,decode,execute - but 
there's a three-stage pipeline so although the duration of any given 
instruction is 3 clocks, overall you get one instruction per clock [2].


[2] except I'm simplifying; for example there's only one memory port so 
load and store instructions take an extra cycle, since they need one 
memory access for the instruction fetch and one for the data - or more 
if it's a block data transfer, obviously.  And BTW it does have a mode 
to take advantage of reduced access times for sequential access in 
memories that support it. That's why the data sheets quote instruction 
times in terms of S (sequential) and N (non-sequential) cycles.


--
Pete

Re: Reproduction micros

[Noel Chiappa]

> From: Paul Koning

>> I always felt that RISC meant 'making the basic cycle time as fast as
>> possible by finding the longest path through the logic - i.e.  the
>> limiting factor on the cycle time - and removing it (thereby making the
>> instruction set less rich); then repeat'.

> "Making the cycle time as fast as possible" certainly applies, in
> spades, to the 6600.  The deeper you dig into its details, the more
> impressed you will be by the many different ways in which it does things
> faster than you would expect to be possible.

My formulation for RISC had two parts, though: not just minizing the cycle
time, but doing so by doing things that (as a side-effect) make the
instruction set less capable. I'm not very familiar with the 6600 - does this
part apply too?

>> RISC only makes (system-wide) sense in an environment in which memory
>> bandwidth is plentiful (so that having programs contain more, simpler
>> instructions make sense)

I should have pointed out that programs of that sort take not just more memory
bandwidth, but more memory to hold them. In this day of massive memories, no
biggie, but back in the core memory days, it was more of an issue.

>> One of the books about Turing argues that the ACE can be seen as a RISC
>> machine (it's not just that it's load-store; its overall architectural
>> philosophy is all about maximizing instruction rates).

I looked, and it's "Alan Turing's Automatic Computing Engine"; in Chapter 8,
"Computer architecture and the ACE computers", by Robert Doran (which is not,
for some reason, listed in the ToC).

> I think a lot of machine designers, though not all, were seriously
> interested in making them go fast.

Again, RISC has two legs, not just making the machine fast, but making them
fast by using techniques that, as a side-effect, make them inscrutable, and
difficult to program. The concept was that they would not, in general, be
programmed in assembler - precisely because they were so finicky.

Remember, the 801 was a combined hardware/compiler project, in which
complexity was moved from the hardware to the compiler; and early RISC
machines has things like no interlocks between pipeline stages. So they really
were not intended to be programmed in assembler - the compiler was critical.

The ACE, on the surface, didn't follow this, as it had no compiler. However,
at a higher level, Turing definitely followed the RISC philosophy of making
the machine as fast as possible, by using techniques that made it very hard to
program; instead of moving the complexity to the compiler, he moved it to the
programmer - the latter not being a problem, if you're Alan Turing! :-)

Noel

Re: Reproduction micros

[Eric Smith]

On Tue, Jul 19, 2016 at 9:36 AM, Paul Koning  wrote:
> RISC, as a term, may come from IBM, but the concept goes back at least as far 
> as the CDC 6000 series.  Pipelining, to the CDC 7600.

Possibly depending on exactly how you define it, pipelining may go
back to the IBM 7030 "Stretch" (1961). Also speculative execution.

A lot of "modern" computer architecture concepts are actually quite old.

Re: Reproduction micros

[ben]

On 7/19/2016 9:04 AM, Peter Corlett wrote:

On Tue, Jul 19, 2016 at 03:30:19PM +0200, Liam Proven wrote: [...]

There's a hint here, though:
https://www.epo.org/learning-events/european-inventor/finalists/2013/wilson/feature.html



 From there, it seems to be saying that the essence of the
invention is that the

ARM ISA is RISC, it is a load-store architecture, and the CPU was
pipelined.

RISC implies a load-store architecture, so that claim is redundant.

Pipelining is an older idea: the 1979-vintage 68000 does it, and the
1982-vintage 68010 even detects certain string/loop instructions in
its pipeline and avoids re-fetching them from memory when repeating
the sequence.

IMO, it's the predicated instructions that is ARM's special sauce and
the real innovation that gives it a performance boost. Without those,
it'd be just a 32 bit wide 6502 knockoff.


And I go the other way, no CPU speed up was really was needed back then.
Cpu's bigger than 8 bits could have decoded and executed the 1st 
instruction, with empty bus cycle then for video or dma or dynamic ram 
refresh.

As for any RISC the 32 bit fetch and the ability
to cache effective addresses makes its speed.
Ben.
PS: With the amount cache to today's cpu's, would a delay line computer
be a better working model, than that of Random Access Memory?

Re: Reproduction micros

[Paul Koning]

> On Jul 19, 2016, at 12:10 PM, Noel Chiappa  wrote:
> 
>> From: Paul Koning
> 
>> The article, as usual, talks about a whole bunch of things that are
>> much older than the author seems to know.
> 
> "The two most common things in the universe are hydrogen and stupidity." OK,
> so technically it's ignorance, not stupidity, but in my book it's stupid to
> not know when one's ignorant.
> 
>> RISC, as a term, may come from IBM, but the concept goes back at least
>> as far as the CDC 6000 series.
> 
> Hmm; perhaps. I always felt that RISC meant 'making the basic cycle time as
> fast as possible by finding the longest path through the logic - i.e. the
> limiting factor on the cycle time - and removing it (thereby making the
> instruction set less rich); then repeat'. (And there's also an aspect of
> moving complexity from the hardware to the compiler - i.e. optimizing system
> performance across the _entire_ system, not just across a limited subset like
> the hardware only).

"Making the cycle time as fast as possible" certainly applies, in spades, to 
the 6600.  The deeper you dig into its details, the more impressed you will be 
by the many different ways in which it does things faster than you would expect 
to be possible.  (For example, how many other machines have divide logic -- not 
"reciprocal approximation -- that divides N bit values in N/2 cycles?)  Or 
context switching that requires just a single block-memory transaction?

> As I've previously discussed, RISC only makes (system-wide) sense in an
> environment in which memory bandwidth is plentiful (so that having programs
> contain more, simpler instructions make sense) - does that apply to the CDC
> machines?

Yes, 32 way interleaving, 1 microsecond full memory cycle, 100 ns CPU cycle.  
The Cybers are not memory bandwidth limited.  Note that the 6600 has quite 
advanced memory operation scheduling and queueing.

>> Pipelining, to the CDC 7600.
> 
> Didn't STRETCH have pipelining? Too busy/lazy to check...

Could be.  I meant to apply "goes back at least as far as" here as well.

> 
>> And if you equate RISC to load/store with simple regular instruction
>> patterns, you can probably go all the way back to the earliest
>> computers
> 
> Well, I'm not at all sure that load-store is a good indicator for RISC - note
> that that the PDP-10 is load-store... But anyway, moving on.

No, but I said "load/store with simple regular instruction patterns".  On 
reconsideration, I think I'll cancel what I said, though.  Early machines 
tended to be single address but not load store; rather, you'd find operations 
like "add memory to register".  A CDC 6000, though, clearly is strictly load 
store.

> One of the books about Turing argues that the ACE can be seen as a RISC
> machine (it's not just that it's load-store; its overall architectural
> philosophy is all about maximizing instruction rates).

I think a lot of machine designers, though not all, were seriously interested 
in making them go fast.  For an example I'd point to the Dutch ARMAC, from 
around 1956, a drum main memory machine with a one-track RAM buffer, allowing 
the programmer to make things go much faster by arranging for bits of code and 
associated data to be all in one track.  When your basic machine has a 20 
millisecond operation time because of the drum, the need to optimize becomes 
rather obvious...

paul

Re: Reproduction micros

[Noel Chiappa]

> From: Paul Koning

> The article, as usual, talks about a whole bunch of things that are
> much older than the author seems to know.

"The two most common things in the universe are hydrogen and stupidity." OK,
so technically it's ignorance, not stupidity, but in my book it's stupid to
not know when one's ignorant.

> RISC, as a term, may come from IBM, but the concept goes back at least
> as far as the CDC 6000 series.

Hmm; perhaps. I always felt that RISC meant 'making the basic cycle time as
fast as possible by finding the longest path through the logic - i.e. the
limiting factor on the cycle time - and removing it (thereby making the
instruction set less rich); then repeat'. (And there's also an aspect of
moving complexity from the hardware to the compiler - i.e. optimizing system
performance across the _entire_ system, not just across a limited subset like
the hardware only).

As I've previously discussed, RISC only makes (system-wide) sense in an
environment in which memory bandwidth is plentiful (so that having programs
contain more, simpler instructions make sense) - does that apply to the CDC
machines?

> Pipelining, to the CDC 7600.

Didn't STRETCH have pipelining? Too busy/lazy to check...

> And if you equate RISC to load/store with simple regular instruction
> patterns, you can probably go all the way back to the earliest
> computers

Well, I'm not at all sure that load-store is a good indicator for RISC - note
that that the PDP-10 is load-store... But anyway, moving on.

One of the books about Turing argues that the ACE can be seen as a RISC
machine (it's not just that it's load-store; its overall architectural
philosophy is all about maximizing instruction rates).

Noel

Re: Reproduction micros

[Paul Koning]

> On Jul 19, 2016, at 11:04 AM, Peter Corlett  wrote:
> 
> On Tue, Jul 19, 2016 at 03:30:19PM +0200, Liam Proven wrote:
> [...]
>> There's a hint here, though:
>> https://www.epo.org/learning-events/european-inventor/finalists/2013/wilson/feature.html
> 
> From there, it seems to be saying that the essence of the invention is that 
> the
> ARM ISA is RISC, it is a load-store architecture, and the CPU was pipelined.
> 
> RISC implies a load-store architecture, so that claim is redundant.
> 
> Pipelining is an older idea: the 1979-vintage 68000 does it, and the 
> 1982-vintage
> 68010 even detects certain string/loop instructions in its pipeline and avoids
> re-fetching them from memory when repeating the sequence.
> 
> IMO, it's the predicated instructions that is ARM's special sauce and the real
> innovation that gives it a performance boost. Without those, it'd be just a 32
> bit wide 6502 knockoff.

The article, as usual, talks about a whole bunch of things that are much older 
than the author seems to know.

RISC, as a term, may come from IBM, but the concept goes back at least as far 
as the CDC 6000 series.  Pipelining, to the CDC 7600.  And if you equate RISC 
to load/store with simple regular instruction patterns, you can probably go all 
the way back to the earliest computers; certainly I can point to early 1950s 
Dutch computers with load/store single-address instructions.

Finally, predicated instructions are also much older.  It may be that the ARM 
team reinvented them independently, but you can find them in the Electrologica 
X-1, which shipped in 1958.  In fact, that machine and its successor X-8 had a 
significantly more powerful scheme, because the flag controlling the 
conditional execution could be set on request, rather than being a condition 
code set by fixed rules.  https://en.wikipedia.org/wiki/Electrologica_X1 has a 
brief example.

paul

Re: Reproduction micros

[Peter Corlett]

On Tue, Jul 19, 2016 at 03:30:19PM +0200, Liam Proven wrote:
[...]
> There's a hint here, though:
> https://www.epo.org/learning-events/european-inventor/finalists/2013/wilson/feature.html

>From there, it seems to be saying that the essence of the invention is that the
ARM ISA is RISC, it is a load-store architecture, and the CPU was pipelined.

RISC implies a load-store architecture, so that claim is redundant.

Pipelining is an older idea: the 1979-vintage 68000 does it, and the 
1982-vintage
68010 even detects certain string/loop instructions in its pipeline and avoids
re-fetching them from memory when repeating the sequence.

IMO, it's the predicated instructions that is ARM's special sauce and the real
innovation that gives it a performance boost. Without those, it'd be just a 32
bit wide 6502 knockoff.

Re: Reproduction micros

[Liam Proven]

On 19 July 2016 at 06:30, Eric Smith  wrote:
>
> I've seen this claim in the past. I've looked over the chipset design,
> and I don't think it did any more wonderful a job of supporting cheap
> commodity DRAM than the other common chipsets of the era. Perhaps
> someone with greater familiarity with the MEMC chip can tell us if
> there is some tricky DRAM support feature I've overlooked.

I will look.

There's a hint here, though:

https://www.epo.org/learning-events/european-inventor/finalists/2013/wilson/feature.html

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Eric Smith]

On Mon, Jul 18, 2016 at 9:59 AM, Liam Proven  wrote:
> In detailed
> technical ways I confess I do not fully understand, the ARM2 and its
> chipset's design was optimised to work with cheap DRAM with relatively
> slow cycle times.

I've seen this claim in the past. I've looked over the chipset design,
and I don't think it did any more wonderful a job of supporting cheap
commodity DRAM than the other common chipsets of the era. Perhaps
someone with greater familiarity with the MEMC chip can tell us if
there is some tricky DRAM support feature I've overlooked.

The only uncommon and particularly clever thing I saw a system do to
optimize for DRAM (as opposed to any other read/write memory type) was
to use the low-order address lines for the DRAM row address, and to
start the DRAM cycle (assert RAS strobe) before the MMU had done the
address translation. This avoids a portion of the DRAM cycle latency
by taking advantage of the DRAM only needing half of the address bits
at the start of the cycle.

If a translation fault occurs, or the upper part of the translated
address turns out not to be intended for the DRAM array (e.g., ROM or
I/O access), the DRAM cycle has to be either:
* completed normally (OK for read cycles, discard the data)
* completed but forced to be a read (OK for read or write cycles, but
for write, don't assert WE signal, and somehow prevent bus contention)
* aborted (never assert CAS strobe, OK for read or write cycles).

I saw this done on at least one MC68000-based systems with a discrete
logic MMU, but I don't recall which one. The technique became
generally inapplicable when MMUs were integrated into tthe CPU chips,
because such CPUs generally don't give you the untranslated low
address bits any sooner than the translated upper address bits.

The technique wasn't generally useful with the MC68451 segmented MMU
or MC68851 paged MMU, because those supported translation granularity
down to 256-byte boundaries, so only six or seven low-order address
lines were unmapped (for 16-bit or 32-bit memory systems,
respectively). DRAMs at 64K and larger capacities require at least
eight row address bits.  Paged MMUs with a minimum page size of 4K
bytes would be somewhat better suited to this technique.

The major drawback to this technique is that it isn't possible to use
DRAM page-mode access to read consecutive locations, because
consecutive locations are in different rows of the DRAM, rather than
in different columns. However, the technique was used in machines that
didn't have hardware support for the processor to request multiple
consecutive sequential accesses, so it didn't matter. The bus support
for bursts of consecutive addresses mostly appeared when caches became
integrated into CPU chips. Note that bursts could still be supported
by interleaving multiple DRAM banks, but that would cut down on the
number of unmapped low address lines available for use for the DRAM
row address, which was barely adequate without interleaving.

Re: Reproduction micros

[Liam Proven]

On 17 July 2016 at 20:54, Peter Corlett  wrote:
> I think it should be quite obvious from the prices why the Amiga 2000 didn't 
> ship with a 68020 as standard.

Exactly so.

This is part of the brilliance of the Archimedes, AIUI. In detailed
technical ways I confess I do not fully understand, the ARM2 and its
chipset's design was optimised to work with cheap DRAM with relatively
slow cycle times. The OS also ran directly from ROM.

Even PCs at the time copied their BIOS ROM to RAM for faster
execution. Acorn designed around this.

Similarly, one of the pleasant features of the Psion 3 & 5 series PDAs
was that their OS ran from ROM. Thus, although the OSes were very
stable & seldom needed reboots, when they did, it was reasonably quick
and the machines were highly functional with, even in the late models,
as little as 8-16MB of RAM, running a rich pre-emptive multitasking
GUI OS.

Compare with, e.g., Android or iOS, where the OS is stored in ROM but
can't execute from it. Thus, slow boot times as the entire thing must
be *copied* to RAM at IPL. And of course as these run
not-very-cut-down 1960s/1970s minicomputer multiuser OSes, the OSes
themselves occupy many hundreds of meg, these days edging to gigabyte
range.


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Peter Corlett]

On 17 Jul 2016, at 17:28, Liam Proven  wrote:
[...]
> Again with the "braindead" jibes. You have not clarified or explained
> what your objection to the machine was.

We perhaps forget just how eyewateringly expensive these things were. They were 
"braindead" because to build them "properly" would price them out of the 
market. I can't quickly find 1987 pricing, but I found a plausible price list 
from Calco Software on page 83 of the September 1989 issue of Amiga Format. I 
also give an approximate RPI-adjusted price in 2016 pounds:

Amiga A500: £349 (£800).
Amiga A590 20MB hard disk: £395 (£900).

Amiga B2000: £895 (£2,000).
Plus an A1084S monitor: £1,125 (£2,500).
Plus an XT bridgeboard and 5.25" drive: £1,395 (£3,100).
Plus a 30MB hard disk: £1,595 (£3,600).

A suitable floppy drive to fit the A2000: £79 (£180).
A2620 68020 accelerator card: £1,395 (£3,100).

Based on this price list, we can estimate the price of the models:

> It seems that there were about 5 models...

> A1500 -- A2000, no hard disk but dual floppies. A sensible affordable
> model for 1987 or so.

£895 + £79 = £975. (ISTR them selling for a grand at launch in 1990, so at 
least this estimate is good.)

> A2000 -- an expandable A1000 with slots and provision for an on-board hard 
> disk.

The A2000 was a ground-up redesign. It even got a new Agnus chip!

£895.

> A2000HD -- an A2000 with a hard disk preinstalled.

£895 + (£1,595 - £1,395) = £1,095.

> A2500 -- an A2000 with a CBM processor upgrade preinstalled, either a
> 68020 or a 68030.

£895 + £1,395 = £2,290.

> If you are arguing that the A2000 should have been launched with a
> 68020 on the motherboard, rather than a 68000, well, yes, that would
> have been great -- but also very expensive, and the Amiga was a
> low-cost machine in a very price-sensitive market. A 68020 in 1987
> might have been just too much, too expensive.

I think it should be quite obvious from the prices why the Amiga 2000 didn't 
ship with a 68020 as standard.

Re: Reproduction micros

[Liam Proven]

On 16 July 2016 at 19:16, Christian Corti
 wrote:
> The A2000 did *not* have a built-in hard disk, that was the A3000. The A2000
> was just an "updated" A1000 in a large desktop case with Zorro slots...
> completely braindead.

Again with the "braindead" jibes. You have not clarified or explained
what your objection to the machine was.

It seems that there were about 5 models...

A1500 -- A2000, no hard disk but dual floppies. A sensible affordable
model for 1987 or so.
A2000 -- an expandable A1000 with slots and provision for an on-board hard disk.
A2000HD -- an A2000 with a hard disk preinstalled.
A2500 -- an A2000 with a CBM processor upgrade preinstalled, either a
68020 or a 68030.

If you are arguing that the A2000 should have been launched with a
68020 on the motherboard, rather than a 68000, well, yes, that would
have been great -- but also very expensive, and the Amiga was a
low-cost machine in a very price-sensitive market. A 68020 in 1987
might have been just too much, too expensive.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[TeoZ]

A2000HD had the built in hard drive.

-Original Message- 
From: Christian Corti 
Sent: Saturday, July 16, 2016 1:16 PM 
To: General Discussion: On-Topic and Off-Topic Posts 
Subject: Re: Reproduction micros 


On Sat, 16 Jul 2016, Peter Corlett wrote:

main compelling feature of the A2000 was the built-in hard disk.


The A2000 did *not* have a built-in hard disk, that was the A3000. The 
A2000 was just an "updated" A1000 in a large desktop case with Zorro 
slots... completely braindead.


Christian

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Reproduction micros

[Christian Corti]

On Sat, 16 Jul 2016, Peter Corlett wrote:

main compelling feature of the A2000 was the built-in hard disk.


The A2000 did *not* have a built-in hard disk, that was the A3000. The 
A2000 was just an "updated" A1000 in a large desktop case with Zorro 
slots... completely braindead.


Christian

Re: Reproduction micros

[Adam Sampson]

Peter Corlett  writes:

> Commodore UK also released the A1500 which was an A2000 without hard
> disk but with an extra floppy drive, i.e. the same spec as a typical
> A500 gaming rig. It apparently flew off the shelves, although I'm not
> sure why given it cost somewhat more than the A500 equivalent.

Looking at the prices in Amiga Shopper issue 1 (May 1991), the A1500 was
a reasonable deal *if* you wanted a machine with expansion
slots. Evesham Micros were selling the A1500 bundle with a 1084 monitor
for £949, when the A500 "Screen Gems" bundle with 1MB and an extra drive
-- but no monitor -- was £419. Add the £239 for a Philips monitor and
£199 for a Checkmate A1500 expansion box (or £350 for a Bodega Bay), and
you were in nearly the same ballpark with a much less tidy system.

It was definitely worth a look if what you really wanted was an A2000
with a hard disk, since you could buy a non-Commodore hard disk
controller, many of which were faster and/or cheaper than the A2090.

That said, though, the A1500 definitely wasn't flying off the shelves
anything like as fast as the A500. I saw lots of A500s in the early 90s
in Kent, but only one A1500 (with an accelerator, KCS PC emulator, and
various other expansions, which eventually meant it remained in use long
after the rest of us had upgraded to A1200s).

Cheers,

-- 
Adam Sampson  

Re: Reproduction micros

[Peter Corlett]

On Thu, Jul 14, 2016 at 01:03:31PM -0600, ben wrote:
[...]
> I had hopes on the Amiga until they came out with the 2000*.
> * Lets add a brain dead cpu and run DOS.

The A2088 was an add-in option. Back in the day, only one of my A2000-owning
friends had a bridgecard. I was given a demo, and it was rather clunky. The
main compelling feature of the A2000 was the built-in hard disk.

Commodore UK also released the A1500 which was an A2000 without hard disk but
with an extra floppy drive, i.e. the same spec as a typical A500 gaming rig. It
apparently flew off the shelves, although I'm not sure why given it cost
somewhat more than the A500 equivalent.

Re: Reproduction micros

[Liam Proven]

On 14 July 2016 at 21:03, ben  wrote:
> * Lets add a brain dead cpu and run DOS.

Oh, come on, for the time, it was OK.

DOS compatibility looked like it'd be a selling point, although it
didn't actually prove to be a big one AIUI.

The A2000 came out in '87, the same year as the 68030, so including
that wasn't really viable. They probably should have used a 68020
(released 1984) but the performance and functionality gains over the
68000 were not that significant, I believe. And I think exploiting
some of them would have broken binary compatibility in AmigaOS.




-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[ben]

On 7/14/2016 8:50 AM, Swift Griggs wrote:


I do wish I'd got the chance to use Amigas to do something "real" when
they were state of the art. That or I wish I'd had an A500 the day they
hit the shelves and had all the cool games. I'm sure that would have been
a lot of fun.


I had hopes on the Amiga until they came out with the 2000*.


-Swift


Ben.
* Lets add a brain dead cpu and run DOS.

Re: Reproduction micros

[Liam Proven]

On 12 July 2016 at 18:10, Steve Browne  wrote:
> The ZX Spectrum Next is going to be interesting http://www.specnext.com/
>
> Look at that industrial design! Designed by Rick Dickinson who was behind
> the ZX80,ZX81, ZX Spectrum, Spectrum Plus and QL


It's pretty but they're only renders so far. There's no hardware yet.
It will, in theory, be a redesigned TBBlue in a retro-ish case.

If you want an off-the-shelf FPGA enhanced Spectrum, it already exists:

http://zxuno.speccy.org/index_e.shtml

Availability is limited and erratic, though. Like a Mac mini, it's
BYODKM. And it doesn't have a Spectrum expansion connector, because
it's a 3.3V device and the Speccy was 5V -- but they're working on it.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Liam Proven]

On 14 July 2016 at 17:56, Brad H  wrote:
> My question about the FPGA Amigas is can you not just emulate pretty much
> anything on a PC these days?  I never tried Amiga emulation (if I have the
> real thing I always go to that).  Not sure how much the emulators can
> handle.

Yes you can, and sometimes with better fidelity, but it doesn't
_transform_ your generic C21 computer into a retro machine. You're
running a program under your normal OS. It doesn't look or feel the
same.

But running vintage kit takes effort, knowledge, possibly
troubleshooting & repair skills, and you need to own it or know where
to get it.

Whereas you can buy a new FPGA-based recreation, usually for not much,
and whereas it's not the same, it is a computer. It boots and runs the
same OS as the old machine. No emulation, it's real hardware, and
probably better than the original.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

RE: Reproduction micros

[Brad H]

I have kind of a counter around my 'office' and I've laid out stuff on top
of and under it (and even stuff on top of the stuff).  I have one 'work'
desk where I set up a machine or two and play.  My Digital Group Z80 has
been occupying that spot for months -- just too much fun to play with.  But
my Amiga 2000 is right next to it.

I remember after seeing that Amiga 2000 at the store trying desperately to
convince my Dad to buy one.  I don't remember what the exact price point was
but it was up there, and his concern was compatibility with work.  An IBM
loyalist, he went from PCjr to PC to AT to PS/2.  I do remember knowing that
they had the XT emulation board available for the Amiga and trying that
angle with him to no avail.  Later on as a consolation he acquiesced to
putting in a (then) very expensive 2400 baud modem into our PS/2 so I could
BBS.

My question about the FPGA Amigas is can you not just emulate pretty much
anything on a PC these days?  I never tried Amiga emulation (if I have the
real thing I always go to that).  Not sure how much the emulators can
handle.

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Swift
Griggs
Sent: Thursday, July 14, 2016 7:50 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org>
Subject: RE: Reproduction micros

On Wed, 13 Jul 2016, Brad H wrote:
> I think the Amiga project is neat, although personally I'm not sure 
> I'd find a need for one.

I have an Amiga 3000 (my personal favorite), but I have limited space so I
can only have about two "classic" systems set up at once (and those are
usually SGI machines in the retro-spots-of-active-honor). I'm not one of
those types who has a personal warehouse with loads of old gear stacked on
huge shelves. So, I find that I spend a lot more time with a MIST FPGA Amiga
than my real 3000. The main reason being that since it can use VGA + USB,
it's small, and it's super easy to put on a KVM make it attractive in my
case. Plus it can emulate so many micros, I get more time with them. 

> The thing about the Amiga was its wow factor

I totally agree. I'm not a huge fan of Workbench, but the Amiga hardware and
the way folks exploited it in games, demos, and applications was the thing
that impressed me. All those custom chips doing interesting things (music
and graphics - there was no bean-counting-co-processor thankfully) while at
the time my impression of PeeCees was that they just bottleneck'd everything
through one pathetically slow CPU with brain-damaged memory management and
then wanted to brag in a dull magazine about mind-numbing things like how
fast you could get a spreadsheet done or reconcile accounts payable for your
boss... ie, ral inspiring stuff to a 14 year old (*yawn*). I see things
a bit differently, now, (I actually think DOS and x86 is cooler now than I
did back in the day) but that's how I felt as a teen.

Of course the x86 today just feels like it's so complex that the actual
microcode you "get" to access & play with isn't really reflecting what's
going on inside. It's just some shared fiction while the CPU really does
super-complex optimizations way beyond what any one person can really
understand anymore. It's also why I haven't curiously disassembled any C
code in probably a decade. I realized the compiler could always do a better
job and use instructions or features I didn't even know existed.  
Perhaps, I think that way because I'm not a specialized EE staring at chip
lithography all day. However, others have made the point more elegantly
before on the list.

> I remember walking into Compucentre (Canadian chain) in the mid-80s.. 
> and there's all the computers from 8 bit heaven and their 16 color 
> graphics (if you were lucky).. and then there's this one computer on a 
> pedestal featuring a totally real jungle cat prowling onscreen.  It 
> just blew the doors off everything else there [...]

I had nearly the same experience at a chain here in the states called
"Electronics Boutique". They'd have a couple of PeeCees running demos and
facing out the storefront. Your eyes would always been drawn to the Amiga
running a Dragon's Lair or Space Ace demo (or something else awesome). I
remember being in the store talking to the staff and people walking in to
get a PeeCee and walking out with an Amiga because the kids were so
impressed with the games and graphics etc...

Also, I've heard versions of this same story from at least three other
people. It seems to be a very common experience. It definitely whet my
appetite for Amigas, too. However, at the time $$$ was a big problem for me
and my family. So, it really wasn't until they were started to become quite
obsolete that I finally got to own one. By that time, I was into UNIX and so
it was already just a "retro curiosity" but one I still enjoy.

I do wish I'd got the chance to use Amigas to do something &quo

RE: Reproduction micros

[Swift Griggs]

On Wed, 13 Jul 2016, Brad H wrote:
> I think the Amiga project is neat, although personally I'm not sure I'd 
> find a need for one.

I have an Amiga 3000 (my personal favorite), but I have limited space so I 
can only have about two "classic" systems set up at once (and those are 
usually SGI machines in the retro-spots-of-active-honor). I'm not one of 
those types who has a personal warehouse with loads of old gear stacked on 
huge shelves. So, I find that I spend a lot more time with a MIST FPGA 
Amiga than my real 3000. The main reason being that since it can use VGA + 
USB, it's small, and it's super easy to put on a KVM make it attractive in 
my case. Plus it can emulate so many micros, I get more time with them. 

> The thing about the Amiga was its wow factor

I totally agree. I'm not a huge fan of Workbench, but the Amiga hardware 
and the way folks exploited it in games, demos, and applications was the 
thing that impressed me. All those custom chips doing interesting things 
(music and graphics - there was no bean-counting-co-processor thankfully) 
while at the time my impression of PeeCees was that they just bottleneck'd 
everything through one pathetically slow CPU with brain-damaged memory 
management and then wanted to brag in a dull magazine about mind-numbing 
things like how fast you could get a spreadsheet done or reconcile 
accounts payable for your boss... ie, ral inspiring stuff to a 14 year 
old (*yawn*). I see things a bit differently, now, (I actually think DOS 
and x86 is cooler now than I did back in the day) but that's how I felt as 
a teen.

Of course the x86 today just feels like it's so complex that the actual 
microcode you "get" to access & play with isn't really reflecting what's 
going on inside. It's just some shared fiction while the CPU really does 
super-complex optimizations way beyond what any one person can really 
understand anymore. It's also why I haven't curiously disassembled any C 
code in probably a decade. I realized the compiler could always do a 
better job and use instructions or features I didn't even know existed.  
Perhaps, I think that way because I'm not a specialized EE staring at chip 
lithography all day. However, others have made the point more elegantly 
before on the list.

> I remember walking into Compucentre (Canadian chain) in the mid-80s.. 
> and there's all the computers from 8 bit heaven and their 16 color 
> graphics (if you were lucky).. and then there's this one computer on a 
> pedestal featuring a totally real jungle cat prowling onscreen.  It just 
> blew the doors off everything else there [...]

I had nearly the same experience at a chain here in the states called 
"Electronics Boutique". They'd have a couple of PeeCees running demos and 
facing out the storefront. Your eyes would always been drawn to the Amiga 
running a Dragon's Lair or Space Ace demo (or something else awesome). I 
remember being in the store talking to the staff and people walking in to 
get a PeeCee and walking out with an Amiga because the kids were so 
impressed with the games and graphics etc...

Also, I've heard versions of this same story from at least three other 
people. It seems to be a very common experience. It definitely whet my 
appetite for Amigas, too. However, at the time $$$ was a big problem for 
me and my family. So, it really wasn't until they were started to become 
quite obsolete that I finally got to own one. By that time, I was into 
UNIX and so it was already just a "retro curiosity" but one I still enjoy.

I do wish I'd got the chance to use Amigas to do something "real" when 
they were state of the art. That or I wish I'd had an A500 the day they 
hit the shelves and had all the cool games. I'm sure that would have been 
a lot of fun.

-Swift

Re: Reproduction micros

[Peter Corlett]

On Thu, Jul 14, 2016 at 12:44:19AM -0500, Sam O'nella wrote:
> I haven't built or marketed anything myself but i believe if i understood
>  correctly from several folks who have that vga was a cheaper choice due to
> licensing costs for dvi or hdmi at the time. 

Parts of DVI are patented, but there are royalty-free licences available. It's
also fairly like that the patents have all bit expired, or are invalid. HDMI
can be treated as DVI with a different plug.

I doubt supporting either interface would be a problem on licensing grounds. If
nothing else, these things aren't made in high enough volume to attract the
attention of the attack lawyers.

> Not sure if vga is past that point or open but when keeping home brew kits
> cheap for us hobbyists every dollar counts.

This is the more likely reason: DVI and related standards use TMDS signalling
which requires a reasonably complex logic block running at a minimum of 250MHz
to scramble and multiplex the 24 bit RGB into the four output signals. This is
not impossible on low-end FPGAs, but it does eat enough LEs that the designer
may decide to just support VGA rather than cut back functionality elsewhere or
require a more expensive FPGA.

RE: Reproduction micros

[Dave Wade]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Sam
> O'nella
> Sent: 14 July 2016 06:44
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk@classiccmp.org>
> Subject: RE: Reproduction micros
> 
> I haven't built or marketed anything myself but i believe if i
> understood  correctly from several folks who have that vga was a cheaper
> choice due to licensing costs for dvi or hdmi at the time.

I didn't think there were licencing costs for DVI but apparently I am wrong. 
The connector is absolutely horrid.

> 
> Not sure if vga is past that point or open but when keeping home brew kits
> cheap for us hobbyists every dollar counts.
> 

As far as I know VGA has always been open. I can't see anything patentable in 
the spec, its really just RGB with higher sync rates.

> It would be interesting maybe as a Wikipedia page (thought there was one)
> to show which projects were out there and preferably which are still
> active.  A shrinking but understandable issue when buying  im batches with
> personal money in hopes that theyll sell eventually.

That would take some updating...

Dave

RE: Reproduction micros

[Sam O'nella]

 Original message 

The thing about the Amiga was its wow factor -- I remember
walking into Compucentre (Canadian chain) in the mid-80s.. and there's all
the computers from 8 bit heaven and their 16 color graphics (if you were
lucky).. and then there's this one computer on a pedestal featuring a
totally real jungle cat prowling onscreen.  It just blew the doors off
everything else there, and I would go wanting for one for 20 years afterward
(now I have 5 :)).  Not sure a replica can revive *that*.


Thats an awesome story and experience that unfortunately i agree is hard to 
relay to people these days.  To see how great lots of classics were during 
their heyday in comparison to what was out is what made so many historic 
memories. 

I think its unfortunately harder for younger generation sometimes to put away 
their cinematic quality vr and experience vintage gaming for what it was.  
Graphics drawn by programming, music while gaming, going for blocks and blips 
to fully animated sprites and tracked music playing all while fitting on a 
floppy disk.

Or even the wealth and size of the virtual text world at a terminal or personal 
computer.  Preaching to  the choir here but when i did finally get around to 
showing selections of systems at our past vcf it was a blast and i enjoyed 
showing some of the comparison of commodore to some pc ascii games but also 
being fair and switching out to some of my favorite dos games too as well as 
pointing out the crispness of the pc display for text making it a probable 
better system out of the box for staring at text all day.

I miss closer vcfs :-( 

RE: Reproduction micros

[Sam O'nella]

I haven't built or marketed anything myself but i believe if i understood  
correctly from several folks who have that vga was a cheaper choice due to 
licensing costs for dvi or hdmi at the time. 

Not sure if vga is past that point or open but when keeping home brew kits 
cheap for us hobbyists every dollar counts.

It would be interesting maybe as a Wikipedia page (thought there was one) to 
show which projects were out there and preferably which are still active.  A 
shrinking but understandable issue when buying  im batches with personal money 
in hopes that theyll sell eventually.

RE: Reproduction micros

[Brad H]

It's pretty cool seeing what people are doing out there.  I like when people
replicate things that are super rare -- like the Mark-8, SCELBI, etc.And
it's definitely cool to see projects like the Altair clone, with its big
empty case, all the hardware being emulated by a tiny little replacement
inside.

I think the Amiga project is neat, although personally I'm not sure I'd find
a need for one.  The thing about the Amiga was its wow factor -- I remember
walking into Compucentre (Canadian chain) in the mid-80s.. and there's all
the computers from 8 bit heaven and their 16 color graphics (if you were
lucky).. and then there's this one computer on a pedestal featuring a
totally real jungle cat prowling onscreen.  It just blew the doors off
everything else there, and I would go wanting for one for 20 years afterward
(now I have 5 :)).  Not sure a replica can revive *that*.

Re: Reproduction micros

[ben]

On 7/13/2016 5:29 PM, Dave Wade wrote:

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of ben
Sent: 14 July 2016 00:24
To: cctalk@classiccmp.org
Subject: Re: Reproduction micros

On 7/13/2016 3:53 PM, Dave Wade wrote:



The modern replacements have the advantage they can use a "modern"

VGA

display, SD-Card for data not slow cassette tape.


So you ARE THE EVIL ONE!  I had to pick up a "MODERN" VGA and can not do
any thing with the *#%&!@* wide screen. Even GOOD TV like STAR TREK or I
LOVE LUCY is 4:3 ratio.



I was being sarcastic. VGA is now becoming obsolete, modern screens are
starting to drop it for DVI/HDMI 

>

KEEP THE VGA'S, PS/2 MICE AND KEYBOARDS! All the latest FPGA projects 
use them and *STANDARD* SD cards.

Ben.

RE: Reproduction micros

[Dave Wade]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of ben
> Sent: 14 July 2016 00:24
> To: cctalk@classiccmp.org
> Subject: Re: Reproduction micros
> 
> On 7/13/2016 3:53 PM, Dave Wade wrote:
> 
> >
> > The modern replacements have the advantage they can use a "modern"
> VGA
> > display, SD-Card for data not slow cassette tape.
> 
> So you ARE THE EVIL ONE!  I had to pick up a "MODERN" VGA and can not do
> any thing with the *#%&!@* wide screen. Even GOOD TV like STAR TREK or I
> LOVE LUCY is 4:3 ratio.
> 

I was being sarcastic. VGA is now becoming obsolete, modern screens are
starting to drop it for DVI/HDMI 
... I keep some "legacy" 3:3 flat panel LCD displays for the same reason...


> I thought that would be floppy drive of some kind.
> 
> > Dave
> 
> 
> 
Dave

Re: Reproduction micros

[ben]

On 7/13/2016 3:53 PM, Dave Wade wrote:



The modern replacements have the advantage they can use a "modern" VGA
display, SD-Card for data not slow cassette tape.


So you ARE THE EVIL ONE!  I had to pick up a "MODERN" VGA and can not do 
any thing with the *#%&!@* wide screen. Even GOOD TV like STAR TREK or

I LOVE LUCY is 4:3 ratio.

I thought that would be floppy drive of some kind.


Dave

RE: Reproduction micros

[Dave Wade]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of ben
> Sent: 13 July 2016 19:49
> To: cctalk@classiccmp.org
> Subject: Re: Reproduction micros
> 
> On 7/12/2016 10:41 AM, Dave Wade wrote:
> > There is an on-going CoCo 3 in FPGA.
> >
> > http://www.brianholman.com/retrocompute/files/coco3fpga.html
> >
> > Spectrum III
> >
> > http://www.mike-stirling.com/retro-fpga/zx-spectrum-on-an-
> fpga/comment
> > -page-
> > 1/
> >
> > but lots more about
> >
> > Dave
> 
> Strange ... how all the computers that hit the dumpsters many moons ago
> are coming back again. Ben.
> 
> 

But that's true of much vintage computing. Original CoCo III and even
Speccy's sell well on E-Bay.

The modern replacements have the advantage they can use a "modern" VGA
display, SD-Card for data not slow cassette tape.

Dave

Re: Reproduction micros

[ben]

On 7/12/2016 10:41 AM, Dave Wade wrote:

There is an on-going CoCo 3 in FPGA.

http://www.brianholman.com/retrocompute/files/coco3fpga.html

Spectrum III

http://www.mike-stirling.com/retro-fpga/zx-spectrum-on-an-fpga/comment-page-
1/

but lots more about

Dave


Strange ... how all the computers that hit the dumpsters many moons ago 
are coming back again. Ben.

Re: Reproduction micros

[Steve Browne]

On 12 July 2016 at 21:41, Swift Griggs  wrote:

> On Tue, 12 Jul 2016, Steve Browne wrote:
> > The ZX Spectrum Next is going to be interesting
> http://www.specnext.com/
>
> Wow! I hope that takes off. It's beautiful. Plus, in other news, they will
> ship schematics! Wow.
>
> > Look at that industrial design! Designed by Rick Dickinson who was
> > behind the ZX80,ZX81, ZX Spectrum, Spectrum Plus and QL
>
> That's pretty impressive. It'd be like Jay Miner (RIP) returning to
> re-create an Amiga 5000.
>
> Thanks for pointing that one out. It's exactly the kind of thing I was
> looking for. Now, if they'll only ship...
>
> -Swift
>

Well I'm hoping so. There was an update a couple of days ago on the
Facebook page, where they said:

"This resulted in the current price of the Spectrum Next to be around £160
including the accelerator board"

"The original plan of starting the campaign on Kickstarter in June is now
pushed back around a couple of months"

So keep alert!

Steve

Screen Printing (was Re: Reproduction micros)

[Swift Griggs]

On Tue, 12 Jul 2016, Rod Smallwood wrote:
> Well I could do front and back panels. In fact anything that needs silk 
> screening. Rod (Panelman) Smallwood

As a hobbyist I've made a few tee-shirts, bags, and other items using a 
real silk screen, transparencies, photo resist emulsion, PVC inks, and a 
heat gun. I've done primitive "trap color" using registration marks, but 
never "process color" (too hard without a 4 screens and better gear). 

Is the process you use similar? I'm only asking because I'm curious. Also, 
just out of curiosity, what kind of color process can you do on a circuit 
board or side panel ?

The most complicated thing I've seen is CMYK process-color done with water 
based inks and fancy super-tight registration. The results (not by me) 
were really awesome, but I'm guessing that kind of thing isn't done the 
same way on non-fabric materials (perhaps PVC inks work, though).

-Swift

Re: Reproduction micros

[Swift Griggs]

On Tue, 12 Jul 2016, Steve Browne wrote:
> The ZX Spectrum Next is going to be interesting http://www.specnext.com/

Wow! I hope that takes off. It's beautiful. Plus, in other news, they will 
ship schematics! Wow. 

> Look at that industrial design! Designed by Rick Dickinson who was 
> behind the ZX80,ZX81, ZX Spectrum, Spectrum Plus and QL

That's pretty impressive. It'd be like Jay Miner (RIP) returning to 
re-create an Amiga 5000. 

Thanks for pointing that one out. It's exactly the kind of thing I was 
looking for. Now, if they'll only ship...

-Swift

Re: Reproduction micros

[Swift Griggs]

On Tue, 12 Jul 2016, Eric Christopherson wrote:
> MEGA65 FPGA-based Commodore 65 remake: http://mega65.org/

That project looks amazing! Does anyone know how far along they are? The 
web page is dated 2015, but that probably doesn't mean much. However, it's 
clear they aren't shipping, yet. 

One thing that I notice right away about that picture is how bright white 
that case is! Even with retr0brite, that's hard to do... helps that it's 
brand-new, though.

-Swift

RE: Reproduction micros

[Dave Wade]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Kurt K
> Sent: 12 July 2016 19:10
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk@classiccmp.org>
> Subject: Re: Reproduction micros
> 
> I haven't heard of these projects.  Do you have a larger list of projects
that
> exist?

I found a list on the MIST site

https://github.com/mist-devel/mist-board/wiki/FPGA-Projects

https://github.com/mist-devel/mist-board/wiki/TheBoard

which is a project to let you run multiple emulations on a single board...

There is also another IBM1130 emulation which is functional rather than
cycle accurate...

http://ibm1130.org/party/v06

Dave

> 
> > On Jul 12, 2016, at 11:41 AM, "Dave Wade" <dave.g4...@gmail.com>
> wrote:
> >
> > There is an on-going CoCo 3 in FPGA.
> >
> > http://www.brianholman.com/retrocompute/files/coco3fpga.html
> >
> > Spectrum III
> >
> > http://www.mike-stirling.com/retro-fpga/zx-spectrum-on-an-
> fpga/comment
> > -page-
> > 1/
> >
> > but lots more about
> >
> > Dave
> >
> >> -Original Message-
> >> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of
> >> Swift Griggs
> >> Sent: 12 July 2016 17:02
> >> To: General Discussion: On-Topic and Off-Topic Posts
> >> <cctalk@classiccmp.org>
> >> Subject: Reproduction micros
> >>
> >>
> >> I'm probably dreaming, but is anyone aware of DIY efforts or business
> >> ventures aiming to reproduce a classic micro or "next-gen" classic
micro?
> >> I have seen a lot of efforts, but only one quite like that (the
> >> Altair 680
> > project
> >> nails it). I'm just thinking that with 3D printers and FPGA hardware
> > emulation
> >> it's probably not as hard as it once was.
> >>
> >> Here are some similar efforts I'm already aware of.
> >>
> >> Project BreadBox (dead)
> >>
> http://www.lemon64.com/forum/viewtopic.php?t=47834=ae3e721d8d
> >> 800cbe5d6b003afe70d79b
> >>
> >> The truly kick ass MIST. A nice clone of several systems implemented
> >> in
> > FPGA,
> >> but design wise, it's a shabby little metal box. I have one and I
> >> think it
> > really
> >> rocks. I just wish there were more cases and accessories.
> >> http://lotharek.pl/product.php?pid=96
> >>
> >> The Firebee ST clone project
> >> https://en.wikipedia.org/wiki/Atari_Coldfire_Project
> >>
> >> The C64 Joystick clone
> >> https://en.wikipedia.org/wiki/C64_Direct-to-TV
> >>
> >> Commodore.net used to sell PeeCee C64 and Amiga look-a-like clones
> >> dead
> >> link: http://www.commodore.net
> >>
> >> The C-One. A FPGA board to emulate the C64, again no case.
> >> https://en.wikipedia.org/wiki/C-One
> >>
> >> The awesome Altair 680 kit that appears to be a very complete clone
> >> of the system. It comes with a case et al.
> >> http://www.altair680kit.com/
> >>
> >> A bunch of PDP-X replicas in FPGAs with various degrees of usefulness
> >> http://www.aracnet.com/~healyzh/pdp_fpga.html
> >>
> >> These guys are trying to build a NEW Amiga with backward compatibility.
> >> Sounds like a wonderful project. They seem to be pretty far along
> >> with
> > many
> >> prototype boards built. FPGA guts with a real 060' for CPU! They
> >> never
> > seem
> >> to have made boards for sale, though, and there was no effort toward
> >> a complete system design (case, keyboards, etc...). The last noise
> >> they made seems to be in 2007.
> >> http://www.natami.net/
> >>
> >> For consoles there are plenty of clones:
> >> http://segaretro.org/Unlicensed_Mega_Drive_clones
> >> https://www.amazon.com/Hyperkin-Retron-System-GENESIS-Nintendo-
> >> Entertainment/dp/B003O3EFY2
> >>
> >> Then there is the Cray1 remake
> >> http://www.chrisfenton.com/homebrew-cray-1a/
> >>
> >> -Swift
> >

Re: Reproduction micros

[Kurt K]

I guess if I checked the email chain, I'd get my answer.  Pity no way to get 
ahold of a C-One, sold out.  I'd love to get one.

> On Jul 12, 2016, at 1:09 PM, Kurt K <kur...@centurylink.net> wrote:
> 
> I haven't heard of these projects.  Do you have a larger list of projects 
> that exist?
> 
>> On Jul 12, 2016, at 11:41 AM, "Dave Wade" <dave.g4...@gmail.com> wrote:
>> 
>> There is an on-going CoCo 3 in FPGA.
>> 
>> http://www.brianholman.com/retrocompute/files/coco3fpga.html
>> 
>> Spectrum III
>> 
>> http://www.mike-stirling.com/retro-fpga/zx-spectrum-on-an-fpga/comment-page-
>> 1/
>> 
>> but lots more about
>> 
>> Dave
>> 
>>> -Original Message-
>>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Swift
>>> Griggs
>>> Sent: 12 July 2016 17:02
>>> To: General Discussion: On-Topic and Off-Topic Posts
>>> <cctalk@classiccmp.org>
>>> Subject: Reproduction micros
>>> 
>>> 
>>> I'm probably dreaming, but is anyone aware of DIY efforts or business
>>> ventures aiming to reproduce a classic micro or "next-gen" classic micro?
>>> I have seen a lot of efforts, but only one quite like that (the Altair 680
>> project
>>> nails it). I'm just thinking that with 3D printers and FPGA hardware
>> emulation
>>> it's probably not as hard as it once was.
>>> 
>>> Here are some similar efforts I'm already aware of.
>>> 
>>> Project BreadBox (dead)
>>> http://www.lemon64.com/forum/viewtopic.php?t=47834=ae3e721d8d
>>> 800cbe5d6b003afe70d79b
>>> 
>>> The truly kick ass MIST. A nice clone of several systems implemented in
>> FPGA,
>>> but design wise, it's a shabby little metal box. I have one and I think it
>> really
>>> rocks. I just wish there were more cases and accessories.
>>> http://lotharek.pl/product.php?pid=96
>>> 
>>> The Firebee ST clone project
>>> https://en.wikipedia.org/wiki/Atari_Coldfire_Project
>>> 
>>> The C64 Joystick clone
>>> https://en.wikipedia.org/wiki/C64_Direct-to-TV
>>> 
>>> Commodore.net used to sell PeeCee C64 and Amiga look-a-like clones dead
>>> link: http://www.commodore.net
>>> 
>>> The C-One. A FPGA board to emulate the C64, again no case.
>>> https://en.wikipedia.org/wiki/C-One
>>> 
>>> The awesome Altair 680 kit that appears to be a very complete clone of the
>>> system. It comes with a case et al.
>>> http://www.altair680kit.com/
>>> 
>>> A bunch of PDP-X replicas in FPGAs with various degrees of usefulness
>>> http://www.aracnet.com/~healyzh/pdp_fpga.html
>>> 
>>> These guys are trying to build a NEW Amiga with backward compatibility.
>>> Sounds like a wonderful project. They seem to be pretty far along with
>> many
>>> prototype boards built. FPGA guts with a real 060' for CPU! They never
>> seem
>>> to have made boards for sale, though, and there was no effort toward a
>>> complete system design (case, keyboards, etc...). The last noise they made
>>> seems to be in 2007.
>>> http://www.natami.net/
>>> 
>>> For consoles there are plenty of clones:
>>> http://segaretro.org/Unlicensed_Mega_Drive_clones
>>> https://www.amazon.com/Hyperkin-Retron-System-GENESIS-Nintendo-
>>> Entertainment/dp/B003O3EFY2
>>> 
>>> Then there is the Cray1 remake
>>> http://www.chrisfenton.com/homebrew-cray-1a/
>>> 
>>> -Swift
>>