Blast from the past... Z80!

[MooseFET]

No wonder you hate programming.
You simply never programmed a good processor.

The Z80 is a very very very nice processor to work with.

It having the 16 bit I/O space along with the 16 bit code/data space
was a nice feature for its time. There were lots of nice things you
could make the built in refresh circuit and interrupt modes do.

It you want to see a case of tricky, take a look at how the ZX80 did
its video.

 

[MooseFET]

RISC operates on registers, so anything to do with memory will
will have to be done with a load and/or a store

RISC means Reduced Instruction Set Computer. It really doesn't say
which ones get taken out. Ideally they are faster because they
implement the low number of instructions very efficiently. There is
no law that says that a very awful machine can't be made as a RISC.

 

[MooseFET]

what does 8051 have that Z80 doesn't
(I see twice as many register banks, but no 16bit arithmentic)

Depending on how you look at things, you could say that an 8051 has
128 registers. Of them 32 have short ways to get to them.

The built in timers and UART and stuff make them handy chips.

 

[MooseFET]

If you enjoy moving data from here to there and back.  I'm with
John.  Yuck.

Seems to be going okay for me, though it's annoying how everything
goes so damned slowly...

ld a,(counter) ; two microseconds
add b ; one microsecond
ld (counter),a ; two microseconds
; ...

And with only the accumulator to do any reasonable math (INC and DEC
at least are available on other registers), you're always loading
accumulator-memory and memory-accumulator stuff.  It takes three
operations to add memory!

Now 8086 on the other hand,
add dx,[bp+si+06]
Ohh yeah baby...indirect offset addressing modes...droool...
Okay, so effective addressing calculations went snail slow on the 8086

Look up how long it took to do a conditional jump. The 8051 was
faster. The instruction set of the 8086 is a dreadful mess. You had
to use 32 bits worth of registers to get at 20 bits of address space
and every memory access took a trip through the ALU. It needed a lot
of support chips to make it o.

 

[MooseFET]

Hear, Hear! I also enjoyed working with the 6502. The 8051 isn't bad when
you get used to its foibles and learn how to use the timer. ;-)

But the first time I worked with the 68HC11 I fell in love with
its timer system.

Yeah but I'll bet that the second time you tried to get the chips for
production you fell out of love.

 

[Nico Coesel]

I put together a Z80 microcomputer the other day. Real simple:
processor, clock oscillator, NVRAM holding program and data, pair of
74LS138s for memory and I/O decoding, and two 74LS273 latches for
output. And a forest of jumper wires. Right now I have it scrolling
a message across four matrixed digits of seven-segment display. Seven
segments make really ugly Latin characters though. :-(

Youtubification:

Cool. Reminds me of the old days. I did a lot of assembly programming
on the Z80.

 

[MooseFET]

I dunno John , I do not want to waste time arguing,
but you must be aware that that involves moving data
to / from that external memory ?

In a PIC I can write
 movlw D'33'
 addwf my_register

And the 'memory' is on chip.
So your remark is highly irrelevant, there are programmers
who think that writing in C:
a = my_function( some_function( an_other_function(variable) ) );
is faster then splitting it over several lines.
Or they think a shorter variable name is faster then a long one so they use:
int a, b, c;
and not
int speed, altitude, temperature;
making their code unreadable for everybody, and for themselves
after a couple of days doing something else.

It is all illusion.
You will find out with arm too, it is not that much faster then a processor
with a more complex instruction set.

Oh, and BTW, the Z80 *has* 16 bit arithmatic,
for example sbc HL, DE (substract with carry the 16 bit register DE from HL).

The DAD and XCHG instructions that let you add to HL and exchange the
register pairs made a multiply on the Z80 a fairly easy bit of code to
write.

The IX, IY and HL memory addressing made an optimized search for a
string fairly easy.

 

[MooseFET]

Yes, I had one ZX80 and 2 ZX81.
The ZX81 integrated the Z80 TTL in one chip.
Very good BASIC too.

I had my ZX80 extended to 16K of RAM. I had an FFT written for it and
code that made nice plots on the printer. You could do quite a lot
with very little RAM in the ZX80. The floating point basic of the
ZX81 took up more space for your program. With a twice as big of a
EPROM chip and a switch a ZX80 could be made as a "multi-boot"
machine.

The ZX81 basic stored every number twice in the program. One copy was
the text to be displayed and the other was the actual floating point
value. As a result, with some poking, you could make a program that
appeared to say

10 LET A=1 + 1
20 PRINT A

and have it print 3

 

[Vladimir Vassilevsky]

MooseFET wrote:

The ZX81 basic stored every number twice in the program. One copy was
the text to be displayed and the other was the actual floating point
value.

Yes, it also did the same way with the integers and it used the
non-standard 5-byte representation for float.

As a result, with some poking, you could make a program that
appeared to say

10 LET A=1 + 1
20 PRINT A

and have it print 3

I can't recall if your example is correct. However the common trick to
save memory was using the expressions like VAL("1234.567") instead of
just 1234.567 . In the first case, it stored only the character string.
Programming was fun set of tricks those old days.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[MooseFET]

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

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.

BTW: My 16K DRAM bread board was wire wrapped. The extra voltages
were made with a LM555 based regulating booster.

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.

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

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.

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.

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.

Why stop at one instruction per cycle?

Since not all of the instructions changed the same registers, you
could fetch code in lets say 32 bit chunks and run them down a
pipeline. As you go down the pipe, if two instructions don't
conflict, one step could be crushed out of the pipe on the next
clock. Since most of the op-codes are one byte, each 32 bit fetch
would grab about 4 of them.

Such a machine would likely beat the tail off of all the
microcontroller like machines on the market if the clock speed was
high.

The SiLabs 8051 like machine that does 100MIPs fetches in 32 bit
chunks.

 

[MooseFET]

Yes, it also did the same way with the integers and it used the
non-standard 5-byte representation for float.




I can't recall if your example is correct. However the common trick to
save memory was using the expressions like VAL("1234.567") instead of
just 1234.567 . In the first case, it stored only the character string.
Programming was fun set of tricks those old days.

You can get a simulation of the ZX80 for free that runs on Linux. If
you really want to try out the example.

 

[krw]

what does 8051 have that Z80 doesn't
(I see twice as many register banks, but no 16bit arithmentic)

What's the big deal about 16 bit arithmetic. The Z80 doesn't have
32 bit arithmetic, or the 8086 64bit. So? Any third grader can
figure out how to do whatever precision arithmetic is required.

huh? risc is all load/store.

Totally clueless.

 

[krw]

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

RISC means Reduced Instruction Set Computer.

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

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

Yes it does. He's right. Load/store ops get separated from ALU
ops and RMW ops are unheard of. That is the *key* difference
between RISC and CISC.

Ideally they are faster because they
implement the low number of instructions very efficiently.

Absolutely wrong.

There is
no law that says that a very awful machine can't be made as a RISC.

There is no law that says that a very awful machine can't be made
of CISC (oh, wait). The difference is that we have an example of a
commercially successful CISC that is truly awful. No such example
exists of a RISC.

 

[krw]

I really liked the 6809.
OTOH it's just a real shame that IBM chose the 8086 for the PC and not
the Z8000 (or 68000).

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

 

[Vladimir Vassilevsky]

The saving to tape process was only moderately reliable at best.

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 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.

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.

BTW: My 16K DRAM bread board was wire wrapped.

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.

The extra voltages
were made with a LM555 based regulating booster.

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.

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.

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.

Why stop at one instruction per cycle?

The figure of merit is bang for the buck. I.e. how many features can we
get from the same piece of silicon, if we employ the different
architectures on it.

Since not all of the instructions changed the same registers, you
could fetch code in lets say 32 bit chunks and run them down a
pipeline. As you go down the pipe, if two instructions don't
conflict, one step could be crushed out of the pipe on the next
clock. Since most of the op-codes are one byte, each 32 bit fetch
would grab about 4 of them.

Such a machine would likely beat the tail off of all the
microcontroller like machines on the market if the clock speed was
high.

The SiLabs 8051 like machine that does 100MIPs fetches in 32 bit
chunks.

There were the experiments with GaAs Z80 running at 200MHz, and of the
Josephson effect Z80 at 500MHz


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[krw]

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

Tapes never worked for me either. I preferred paper (mylar,
actually) tape on an ASR-33 over crappy audio tapes. The ASR-33
drove teh technicians crazy though. ;-)

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.


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.

WireWrap is great stuff. It's certainly more reliable than
soldering wires all over and a *lot* faster. I came into work
today to build a test jig and the only choice I have is soldering
wires to a breadboard. It's a good thing I only have a few dozen!
What a PITA.

The figure of merit is bang for the buck. I.e. how many features can we
get from the same piece of silicon, if we employ the different
architectures on it.

The figure of merit is performance, and now power. Transistors are
free. ;-) 1IPC is for sissies. ;-)

There were the experiments with GaAs Z80 running at 200MHz, and of the
Josephson effect Z80 at 500MHz

Seems like a real waste of resources.

 

[JosephKK]

I like the Z80 and 8051. They are very nice processors.
Is the CDP1802 available as a free core? Now there's a nasty
processor if there ever was one.

1802s are tame compared to F3850s. See this:

http://members.cox.net/seanandalicia/f3850.pdf

The program counter is not on the CPU chip. 1802 at least got that
right.

 

[Nobody]

Yes, I had one ZX80 and 2 ZX81.
The ZX81 integrated the Z80 TTL in one chip.

My favourite part of the ZX80/81 was the video hardware: an 8-bit shift
register (the same 8-bit shift register which it used for the cassette
interface) plus something akin to a 6845 emulated in software.

You could do some neat things by replacing the video IRQ handler with
custom code.

 

[Nobody]

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 ZX80/81 video hardware was a shift register. You load 8 pixels of data
(one byte), which it shifts out to the video-out. After 8 pixels, it
triggers an IRQ. The IRQ handler determines the next 8 pixels (emulating a
6845 or similar) and loads them into the shift register.

This is why it ran at 4 times the speed if you disabled video: the video
IRQ consumed 75% of the CPU cycles. Also why you got weird stripey
patterns on the screen when using the casette interface: it used the same
8-bit shift register (at a much lower clock speed) for the audio.

With 16KiB of RAM, you could replace the video IRQ handler with one which
implemented pixel-based (as opposed to character-based) graphics, or which
implemented pixel-aligned sprites.

 

[[email protected]]

I dunno. maybe I have a different look at hardware and programming.
When I started building that Z80 system, it was in my spare time.
In the evenings mainly.
In my daytime job at that time I was designing hardware for small
and huge projects, some involving designing ISA cards for
the IBM PC / XT whatever it was.
So I am familiar with the different platforms, and the X86 asm too,
although I am so rusty with that, really as I only use C on those platforms.

So, when making my little Z80 project, something that gave me some ideas
that resulted in million $ projects for, my boss, the question was:
What makes this slow?
Answer: disk IO (5 1/4 inch floppy, you must have heard
the rrrrrr crack rrrrrr plonk rrrrr for minutes) while for example compiling something.
There are many solutions, but speeding up a processor by adding more registers and allowed
operations on those, is _not_ one of them.
My solution was: Copy the floppy to RAM, and use the RAM as floppy,
work that way, until finished, that copy everything back to floppy.
As it is all sequential and needs no seeks, it is fast, like format, tick tick tick... tick done.
Now after that speed increase, it compiled a C source faster then gcc now on a 1GHz Athlon.

So, improve where it counts, not in the margin.
I hear J. Larking about ARM, sure RISC processors have a simpler instructions set,
but need many more instructions.
The Z80 was incredibly (is) code efficient.
Just imagine the bit set and test, these days in C we all use integers
(and that may actually be 64 bits long whoopy) for a flag, whoaaaa!, yes you
really need to optimise to work that speed loss away!
The story is much longer of course.
Yesterday I worked some more on the PIC color controller,
added 5 timers, a clock, so it can do color sequencing, set different colors at different times of day,
all is saved in EEPROM, it has a RS232 interface with help menu, and many commands,
it drives 3 PWM color channels, and guess what:
I am sill below 2 kB (it is 4kB code space chip), so below where I have to call code in page 2.
Now I am well aware that some here get the hickups if you mention the 16Fxxx PIC, as they got burned
by bank select, the complicated way to write to external memory, etc, but the point is that
bank select with an assembler like gpasm is extremely simple,
'banksel VRCON' will select the correct bank (1 actually) for VRCON, etc.
In this whole project I did only use the scope when it was finished, the PIC never left the noppp programmer,
as that programmer has now a RS232 connection to the PIC, and the 3 LEDS were simply soldered on the socket
of the programmer, now that saves time.
I use no debugger, and no ICE, nothing. it is 3055 lines of code (subtract some empty lines), and it all works.
need to add the new menu options to the help menu,
then it will likely be released as the next version (0.6) on my site.
So, it is not the processor, and this circuit has as external parts only 3 resistors!
It is the designer, it is the programmer, and it is to look at the situation in a clear way,
Sure, that PIC is not suitable for decoding H264 in real time.
OTOH we use hardware to assist us in cases where software makes little sense, the Z80 has the
DMA chip, the CTC (timer) chip, the DART (serial UART), a chip for serial synchronous communication,
all with a special interrupt structure (daisy chain) optimised for speed.
Who cares if you have to move the value of a register, THAT is not what is setting the speed.
Unless you are doing something you should not be doing.

Sure, companies like MS write such outrageous incredible bloat that it will slow anything down.
they do not want better performance, they have no new ideas, nothing to bring, need to sell,
are in bed with the big processor makers, to add ever more speed and memory to get ever less new stuff.
It all ends with video.
Maybe some voice recognition, but that wont be the main driving force.
And lets get this right, 1GHz is already plenty for playback, and encoding H264 in real time is best done
with the aid of : YOU GUESSED IT extra dedicated hardware.
So much for that.
Sure 4 core 4 GHz, too bad the trend is now towards netbooks.
And _still_ the biggest speed break is disk access.

Maybe you should do some actual programming to get the hang of it again.
On a PIC or Z80 for example
Man ain't PIC cool, I love them.

An hour ago finished an AVR Mega88 project for mains true power
metering. Nearly 6k of machine code.
Uses signed 32 bit and floating point maths, digital filtering, ADC
sampling, LCD driving, auto-ranging, menus, calibration etc etc and
took (I still can't believe it) about 5 hours to write from scratch.
320 lines of Basic and I'm there (assembler? what's that . Modern
Silicon and a decent compiler make it soooo fantastically easy these
days.
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 but I still love the Z80, can
happily still write code for it but essentially it's like the old
350cc Enfield Bullet I had, a classic in it's own right but a piece of
shit as compared to modern machinery