Blast from the past... Z80!

ohn Larkin

h

hy I

y

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

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

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

Absolutely wrong.

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

Reply to
krw
Loading thread data ...

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

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

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.

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.

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

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

formatting link

Reply to
Vladimir Vassilevsky

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

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.

I wonder

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

Seems like a real waste of resources.

Reply to
krw

1802s are tame compared to F3850s. See this:

formatting link

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

Reply to
JosephKK

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.

Reply to
Nobody

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.

Reply to
Nobody

something.

and allowed

tick... tick done.

1GHz Athlon.

set,

at different times of day,

commands,

call code in page 2.

PIC, as they got burned

point is that

never left the noppp programmer,

simply soldered on the socket

some empty lines), and it all works.

resistors!

in a clear way,

the Z80 has the

synchronous communication,

setting the speed.

slow anything down.

need to sell,

get ever less new stuff.

H264 in real time is best done

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 :)
Reply to
john

w

John Larkin

ith

?

why I

nky

re

Others seem to agree with me. See:

formatting link

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

No it doesn't.

[...]

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.

Reply to
MooseFET

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.

st

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

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

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

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.

w
Reply to
MooseFET

:

John Larkin

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

Idiot.

Idiot.

Ignorant idiot.

Reply to
krw

not if the Z80 gets 15 year head start.

Reply to
Jasen Betts

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

Reply to
Jasen Betts

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.

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.

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)

there's some people doing that with microcontrollers now.

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

Reply to
Jasen Betts

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

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

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

Reply to
Jasen Betts

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

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.

Reply to
Nobody

On a sunny day (Sat, 31 Jan 2009 19:10:05 -0800 (PST)) it happened snipped-for-privacy@jjdesigns.fsnet.co.uk wrote in :

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?

Reply to
Jan Panteltje

e:

krw

ned John Larkin

rs.

m with

re'?

t's why I

any

kinky

store

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.

Reply to
MooseFET

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.

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.

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.

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.

B.

Reply to
MooseFET

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.