Blast from the past... Z80!

his perfboard appears to have a groundplane.

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.

n Larkin

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.

Larkin

Depending on how you look at things, you could say that an 8051 has

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

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.

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

On a sunny day (Fri, 30 Jan 2009 17:34:41 -0600) it happened krw wrote in :

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

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.

On a sunny day (Fri, 30 Jan 2009 15:45:39 -0800) it happened John Larkin wrote in :

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

On a sunny day (Fri, 30 Jan 2009 23:25:25 -0800 (PST)) it happened MooseFET wrote in :

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

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

se:

or

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.

ET

in

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

and have it print 3

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.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

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.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

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.

John

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.

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.

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.

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

On a sunny day (Sat, 31 Jan 2009 08:19:54 -0800 (PST)) it happened MooseFET wrote in :

hehe :-) I still have the book: 'The complete Timex Sinclair ROM dissasembly', by Dr Ian Logmn and Dr. Frank Ohara. ISBN 086161 113 6 Melbourne House Publishers. It goes into the internals of that BASIC in a nice way, including the math. Written some programs that called thoce ROM routines too.

Larkin

What's the big deal about 16 bit arithmetic. The Z80 doesn't have

Totally clueless.