Blast from the past... Z80!

[MooseFET]

@w39g2000prb.googlegroups.com>, [email protected] says...>




But there are a bazillion registers so percentage of load/store
instructions in a code stream drop like a stone.


Reduced Instruction Set Complexity.

Others seem to agree with me. See:
http://en.wikipedia.org/wiki/RISC

A modern RISC computer has just
as many, if not more (depending on how you count), instructions
than a modern CISC.

Since the instruction word length is the same it is still 2^N many
instructions so on that basis the count must be equal.

Yes it does.

No it doesn't.

[...]

Load/store ops get separated from ALU
ops and RMW ops are unheard of.  That is the *key* difference
between RISC and CISC.

This is only true of the ones that are generally on the market. It
doesn't mean that it must be the case. It is just where the market
went with the idea.

 

[MooseFET]

Never had any problems with tapes. The reliability depends mainly on the
input circuit. A simple RC bandpass, limiter and comparator worked very
well.

I think that the spectrum had a different input circuit than the
ZX80.

The circuit was:

C12 R29 ! !
EAR ---!!---/\/\/------+-------! IC10 !
100n 180 ! ! ! 74LS368
\ R1
/ 1K
\
!
GND

Transcribed form schematic.

IIRC the standard modulation was 1800 bps on the average, so the 90 min.
tape contained about 1.2MB. That was a lot of storage; one tape for
20..30 programs.

It was a strange sort of FSK system. The time between state changes
was the bit value.

I don't believe in wirewrap. My ZX 128K was soldered with the teflon
coated wires. The CAMAC breadboard was very convenient for DIP parts. A
friend of mine built a PC XT compatible computer on it, including the
CGA/Hercules video; all of the discrete parts.

It was what I could lay my hands on at the time. It worked which when
you think about it is amazing with dynamic RAMs

For some reason, the 555 wasn't known in Russia. There was popular
schematic for the +12/-5 source from +5V primary using the discrete
BJTs. But, that was required for the legacy of 8080; in the times of
Z80, pretty much everything was +5V single supply.

You must have been doing this later than me. Multivoltage RAMs where
the most common sort.

I am not familiar with the details of the original ZX. In the computer
of mine, the DRAM was shared transparently between the CPU and the
video, so there was no need to slow down.

The ZX was extremely clever in using as few parts as can be done. The
CPU jumped to a location that was 8000H plus the part of memory that
needed to be displayed. Some logic caused the CPU to see 00H
regardless of what got fetched. This caused the CPU to do NOP
instructions. The NOP is two bus cycles, the first is the fetch and
the second is the refresh.

Two machine cycles took 8 clocks so this was exactly the right timing
to get 8 bit bytes for the display. On the instruction fetch, what
really came from the RAM was latched. During the refresh cycle, the
fetched byte was used to address in the character table in PROM to et
the bit pattern.

At the end of each sweep, the CPU would get an NMI and would do the
sync pulse and then start the next pass.

 

[krw]

Others seem to agree with me. See:
http://en.wikipedia.org/wiki/RISC

THe term was originally as you state. The fact is that the key
difference is instruction complexity.

A modern RISC computer has just
as many, if not more (depending on how you count), instructions
than a modern CISC.

Since the instruction word length is the same it is still 2^N many
instructions so on that basis the count must be equal.
Idiot.

Yes it does.

No it doesn't.
Idiot.

[...]
Load/store ops get separated from ALU
ops and RMW ops are unheard of.  That is the *key* difference
between RISC and CISC.

This is only true of the ones that are generally on the market. It
doesn't mean that it must be the case. It is just where the market
went with the idea.

Ignorant idiot.

 

[Jasen Betts]

Consider a 200 MHz CPU, runing an instruction per clock from cache,
with 16 32-bit registers and MAC instructions. That describes both
Coldfire and ARM.

Might beat a Z80.

not if the Z80 gets 15 year head start.

 

[Jasen Betts]

I built ZX Spectrum with 128k RAM and the floppy drive using the
discrete logic ICs on the CAMAC breadboard. At the time, that was far
better computer then what was offered by Russian industry
Did quite a lot of real programming on it.
BTW, the Spectrum 48k ROM BASIC is a jewel of assembly programming; I
can see the hand of the distinguished master.

Speaking of Z80 architecture, it wasn't bad for C programming. I wonder
what it would take to make it pipelined 1 cycle per instruction, and how
it would compare to AVR/PIC18/HC11.

the mundane instructions weren't any more complex than the AVR ones

but, to get one instruction per cycle you'd need a harvard architecture.

things like LDI aren't going to work one-per-cycle.
as they go to ram twice

 

[Jasen Betts]

The saving to tape process was only moderately reliable at best. I
would save to program about 5 times on a tape. I bought the shortest
type of tape and only had one program per tape. I had about 10 or so
tapes with programs that did good stuff.

I only ever made two copies of anything, or if I was writing something
i used a C-60 and just reset the counter saved my next version after my
last. and rewound to the start of the save.

you had to have the right tape recorder. The sanyo hand-helds
were popular. I had a Sampo thing that was slightly larger and
marketed for computer tapes. it worked well too until I blew up
the input whilst trying to use it as a signal tracer.

The random number generator in the integer one was based on a simple
multiply by 77. That was kind of bad.

add 1, multiply by 75, mod 65537 , subtract 1

it worked well enough for most things.

the rom random code used the rom floating point library
and was kind of slow,

I re-wrote it in assenbler (it took about 13 bytes I think
less than the rom code took anyway) and used all of the normal
registers.

The semistandard 5 byte floats were darn good. It worked a lot like
the IEEE floating numbers. It had an implied bit and a binary
exponent.

commodore also used a very similar floting point format,
IEEE 32 bit floats are often just a little too small, the
40 bit ones seemed about right.
31 bits of mantissa made them almost wide enough to hold a 32 bit
integer value, (only couldn't hold the lowest one)

If you ran the ZX81's PROM in the ZX80s hardware, you had to add some
hardware to get "slow mode" to work.

For those who don't know:
The ZX80 series used the micro to do the screen display. In fast
mode, it stopped doin that while the program ran. In slow mode, the
program only ran during the retrace.

there's some people doing that with microcontrollers now.

how was the display driven? was it a 8 bit SIPO shift register

 

[Frank Buss]

I learnt machine code programming on the Sinclair Spectrum Z80, spent
5 years designing product using Z80s. It would have taken me months
to do this particular metering project

You would need a week for a Basic compiler, then you could do it in 5 hours
on a Z80, too.

 

[Jasen Betts]

The Z8000 wasn't a choice. Neither was Motorola. Intel could be
bought (and more or less was), if necessary.

They were only going to make 20000 PCs, why would thet consider
that?

 

[Nobody]

Since the instruction word length is the same it is still 2^N many
instructions so on that basis the count must be equal.

You wouldn't normally count a specific instruction type with different
embedded operands or different flags as being different instructions.
"add r0,r1,r2" and "add r3,r4,r5" are both just "add" instructions.

It's open to debate whether e.g. "add" and "sub" are different
instructions; the ARM essentially treats all of the arithmetic and logic
instructions (group 1) as a single instruction with the operator as an
embedded operand. Equally, you can argue whether different addressing
modes constitute different instructions (CISC has different opcodes for
different modes; RISC requires distinct load/store operations).

Yes it does.

No it doesn't.

[...]

Load/store ops get separated from ALU
ops and RMW ops are unheard of.  That is the *key* difference
between RISC and CISC.

This is only true of the ones that are generally on the market. It
doesn't mean that it must be the case. It is just where the market
went with the idea.

Well, it's the main mechanism by which the instruction set was
reduced.

If you have A distinct arithmetic/logic operations and B distinct
addressing modes, typical RISC has A + B instructions while CISC has A * B.

 

[MooseFET]

THe term was originally as you state.

So you now admit that I was right about what the term means.

Since what you posted below here was so out of character for you, I am
deleting it without comment.

 

[MooseFET]

You wouldn't normally count a specific instruction type with different
embedded operands or different flags as being different instructions.
"add r0,r1,r2" and "add r3,r4,r5" are both just "add" instructions.

Although you wouldn't normally count them that way, consider what the
number of bits always sets. 2^N is the maximum number of
instructions. If you have a fixed instruction word length, you can
trade around what those bits get used for but you can never break that
limit.

It's open to debate whether e.g. "add" and "sub" are different
instructions; the ARM essentially treats all of the arithmetic and logic
instructions (group 1) as a single instruction with the operator as an
embedded operand.

In the CDP1802 all of the instructions that sent values to the ALU
could be called the same instruction. If you read the manual on that
ugly processor, you will see that the makers seemed to think of it
that way sometimes. This would be the extreme to the ADD and SUB
being the same one.

Equally, you can argue whether different addressing
modes constitute different instructions (CISC has different opcodes for
different modes; RISC requires distinct load/store operations).

This isn't all that was done when RISC was first thought up. The
instructions that needed micro code or other large amounts of hardware
but were rarely used were often dropped altogether.

As an example of where this would be done: Quite a few processors have
a multiply but no divide because it was seen that the divide took more
hardware than was justified. IIRC, the AVR doesn't have a divide.

No it doesn't.

[...]
Load/store ops get separated from ALU
ops and RMW ops are unheard of.  That is the *key* difference
between RISC and CISC.

This is only true of the ones that are generally on the market.  It
doesn't mean that it must be the case.  It is just where the market
went with the idea.

Well, it's the main mechanism by which the instruction set was
reduced.

Yes, for those that went to market, the memory based operations were
removed. The divide, for example, could also be removed as I
suggested above.

 

[krw]

So you now admit that I was right about what the term means.

No, dickhead, I agreed about what the original term is, not what it
meant. It meant reduced *complexity*. A trade of complexity for
speed. Thus all loads/stores decoupled from the ALU.

Since what you posted below here was so out of character for you, I am
deleting it without comment.

You *are* an idiot. I simply stated the point when you made it clear.

 

[krw]

You wouldn't normally count a specific instruction type with different
embedded operands or different flags as being different instructions.
"add r0,r1,r2" and "add r3,r4,r5" are both just "add" instructions.

It's open to debate whether e.g. "add" and "sub" are different
instructions; the ARM essentially treats all of the arithmetic and logic
instructions (group 1) as a single instruction with the operator as an
embedded operand. Equally, you can argue whether different addressing
modes constitute different instructions (CISC has different opcodes for
different modes; RISC requires distinct load/store operations).

If ADD and SUB aren't different, then to be consistent, neither are
ADD and AND. They're both the same with a different parameter to the
ALU. They're generally considered different though. Register
reference, Memory reference, Indirection are much different, IMO,
since it involves a completely different area of the processor.

It really doesn't say which ones get taken out.  

Yes it does.

No it doesn't.

[...]

Load/store ops get separated from ALU
ops and RMW ops are unheard of.  That is the *key* difference
between RISC and CISC.

This is only true of the ones that are generally on the market. It
doesn't mean that it must be the case. It is just where the market
went with the idea.

Well, it's the main mechanism by which the instruction set was
reduced.

Reduced in complexity. There are still just as many instructions.

If you have A distinct arithmetic/logic operations and B distinct
addressing modes, typical RISC has A + B instructions while CISC has A * B.

It's all about how you count instructions (a rather silly thing to
do).

 

[krw]

They were only going to make 20000 PCs, why would thet consider
that?

The original plan (before the project was started) was for 250,000
with the number going up quickly after. Those are the facts.

 

[MooseFET]

I only ever made two copies of anything, or if I was writing something
i used a C-60 and just reset the counter  saved my next version after my
last. and rewound to the start of the save.

you had to have the right tape recorder.  The sanyo hand-helds
were popular.  I had a Sampo thing that was slightly larger and
marketed for computer tapes. it worked well too until I blew up
the input whilst trying to use it as a signal tracer.

I forget what brand recorder I was using. I don't think it had a
label that was very large marking what it was. It was a portable that
I had first bought to play music on. It was not a really cheap one.

 add 1, multiply by 75, mod 65537 , subtract 1

I remember it as 77. The code I had was for the ZX80.

 it worked well enough for most things.

It was good enough for games etc.

the rom random code used the rom floating point library
and was kind of slow,

I re-wrote it in assenbler (it took about 13 bytes I think
less than the rom code took anyway) and used all of the normal
registers.

On the integer basic, I had sin() and cos() that used 32758 as a half
rotation. I wrote a Startrek game that had space as a sphero-toroid.
Working out where the long range sensors would show stuff turned out
to need the math library I had written for other things.

commodore also used a very similar floting point format,
IEEE 32 bit floats are often just a little too small, the
40 bit ones seemed about right.
31 bits of mantissa made them almost wide enough to hold a 32 bit
integer value, (only couldn't hold the lowest one)

Yes it does work better. I have often seen the error an error in
programs where they lose the resolution on the input data by using
floats.

there's some people doing that with microcontrollers now.

how was the display driven? was it a 8 bit SIPO shift register

There is an parallel loaded shift register. Every time a NOP
instruction cycle causes the load of a character, it first puts the
character into a latch and then uses that to address the PROM to get
the bits that go into the shift register. The interrupt vector
register brought out on the bus during a memory refresh. It was used
to make the upper bits of the address so that the table location was
not fixed.

When I did bit graphics, I took advantage of this. I made my own
"character generator" that was in fact the graphic display I wanted
and then filled the character space with simply 0,1,2,3... So that the
bytes would be addressed.

 

[MooseFET]

the mundane instructions weren't any more complex than the AVR ones

but, to get one instruction per cycle you'd need a harvard architecture.

things like LDI aren't going to work one-per-cycle.
as they go to ram twice

If you fetch more bytes per fetch operation than an instruction is
long, you could have an extra trip to RAM here and there, but
generally, I agree with you.

If you look at some DSP chips, they have more than just the two busses
of the Harvard machine.

 

[JosephKK]

Others seem to agree with me. See:
http://en.wikipedia.org/wiki/RISC



Since the instruction word length is the same it is still 2^N many
instructions so on that basis the count must be equal.

Therein lies the rub. In particular X86 is a variable length
instruction set from one byte to over 8 bytes without the new(ish)
64-bit modes.

No it doesn't.

If you were around to read the literature of the time, the instruction
sets were also regularized. And instructions were also all the same
length.

[...]

Load/store ops get separated from ALU
ops and RMW ops are unheard of.  That is the *key* difference
between RISC and CISC.

Not really key. The original main objective was a short pipeline and
single cycle execution once the operands were available. This is what
rules out RMW opcodes.

 

[[email protected]]

Nice, but would not C be more portable?
I mean if you no longer can get that chip, or need to
implement it in some other project?
Not every micro has BASIC interpreter or compiler available for it.

Month? That is a very long time.....
I had Software Toolworks C (with floating point library) running on
that Z80 system of mine, on my own OS CP/M clone, that
actually only too 3 weeks to write itself, so it C it would
not have taken much longer then in your BASIC, assuming I knew the
digital filtering stuff, something I did not in the 1980 ties.
But the extra peripherals on your Mega88 make it look much like a PIC
Does it have a brownout timer too?

Long time maybe. But I'm comparing how much nice peripheral stuff is
now packed in as normal. I.e an 1985 meter would have required design-
in of not just the Z80 but lots of glue logic+RAM+ROM+ADCs+timers
+alphameric display+hefty power supply etc.
Code recycling has never been an issue, as I only design hardware and
each new job invariably has to start with a blank sheet. Most of the
stuff I've done has been in assembler and obsolescence seems not a
prob with the Z80s and PICs.
I've been coming across this 'C is portable' mantra, for the past 25
years. Yet when looked into find C no more or less portable than any
other language. The Basics I've used, port with ease.
Problem is the uni's have forced C to the forefront, leaving Basic
with fewer supporters, hence portability is now limited. But, that's
a problem for career programmers to worry over, not me!. .
Yep. the AVRs are like a PIC on speed, with a toke of coke thrown in
for clarity .
Has 3 brown out fuse settings and 2 internal clock rates. Used PICs
100% until last year, when A. Freemont here convinced me Atmel was the
way to go. Never looked back.
A Mega88 at 20MHz, runs each instruction in 50nS, has a hardware 8x8,
will do a signed longxlong in 3.75uS, NO sodding paging or banking or
256 byte breaks or movlw. Assembler is a breeze. From an equipment
POV, AVR seems about 10x more powerful than PIC.

 

[krw]

Others seem to agree with me. See:
http://en.wikipedia.org/wiki/RISC



Since the instruction word length is the same it is still 2^N many
instructions so on that basis the count must be equal.

Therein lies the rub. In particular X86 is a variable length
instruction set from one byte to over 8 bytes without the new(ish)
64-bit modes.

No it doesn't.

If you were around to read the literature of the time, the instruction
sets were also regularized. And instructions were also all the same
length.

[...]

Load/store ops get separated from ALU
ops and RMW ops are unheard of.  That is the *key* difference
between RISC and CISC.

Not really key. The original main objective was a short pipeline and
single cycle execution once the operands were available. This is what
rules out RMW opcodes.

I'll accept that refinement, though obviously load/store was never
single cycle. It also forces a separation in load/store and ALU ops,
not just RMW. Again, the point was reduced *complexity* of
instructions such that each could be as fast as possible.

 

[MooseFET]

Therein lies the rub.  In particular X86 is a variable length
instruction set from one byte to over 8 bytes without the new(ish)
64-bit modes.

The variable length in the X86 is mostly the result of the extra bytes
specifying details about what is to be done. Consider the ADD
immediate to memory or register as an example.

The upper 6 bits of the first byte gives you what is being done. The
two lower give you the width of the ALU action and the immediate
operand.

The later bytes give the addressing details. This is how it is for
pretty much all of the longer ones.

If you were around to read the literature of the time, the instruction
sets were also regularized.  And instructions were also all the same
length.

I was around and did read about it. This is why I pointed out that
the breaking apart of the load/store and the ALU operations was not
the only thing under consideration. Early in the RISC development
they went back to the fixed instruction length. The PDP-8 was fixed
instruction length and was created before instruction sets got complex
enough to need reducing.

[...]

Load/store ops get separated from ALU
ops and RMW ops are unheard of.  That is the *key* difference
between RISC and CISC.

Not really key.  The original main objective was a short pipeline and
single cycle execution once the operands were available.  This is what
rules out RMW opcodes.

That really was a sub goal to get to the goal of getting greater speed
by having more efficient use of transistors. Transistors were not
considered free so any that were used for an ASCII adjust for divide
couldn't be used for something else that really mattered.