🚀 go-pugleaf

real-address-in-sig@flur.bltigibbet (Rowland McDonnell) writes:

> David Kastrup <David.Kastrup@t-online.de> wrote:
> 
> >  This lead
> > to longer execution times (and interrupt latencies).  For example,
> > things like rlc (ix+3) took up 23 clock cycles.  In contrast, ld e,3;
> > add hl,de; rlc (hl) took the same cycle count,
> 
> (just out of interest, is this all from memory, or (please tell me that
> you do) do you look up the fine details?)

No payoff.  This is from memory.  When I was wild and young, I
programmed a few arcade games for my Z80 based computer.  One was a
car race, including motor sound (on a text mode frame buffer, ASCII
graphics).  The computer had just an I/O port wired to the speaker.
It had no timer chip.  The pitch of the sound was accurate.  Every
branch in the code and logic took up exactly the same cycle count.
Need an instruction taking 5 cycles?  Use a conditional return
instruction with a condition you know to be false.

Later I programmed a graphics arcade game with graphics (Tutanchamun).
Still no timer chip.  Having gotten lazy, I just counted out
"important" stuff.  Later ported the stuff to SVGAlib (must be around
on sunsite or whatever its successor is called), and this time used
timer chips, and translated the assembly code rather 1:1 to C.  On a
33MHz 80486, the program slowed down in exactly the same manner as the
original (for example, when the screen was full of monsters), so was
playable with just the same schemes, while taking an average true
system load of something like 3% and an executable size of something
like 35kB or so.  Probably a good candidate for "doodle away while
installation progresses".

I also had to write a BIOS first before being able to use my computer
with CP/M.

The resulting brain damage has been pretty thorough.  At least I have
forgotten most opcodes by now: while things like 76, C3, CD, C9, DD,
FD, 00 and so are still present, most of the other stuff isn't.

> Something which was pointed out to me a *long* time ago - I can
> recall getting all excited over the powerful Z80 instructions until
> someone mentioned the time it took to execute 'em.

Take relative branches: one byte shorter opcode, but 12 cycles instead
of 10.  Can conceivably be a win mostly if conditional: absolute
branches always take 10 cycles, conditional branches not taken only
take 7.

> Well, yes; but up until that point, everything you'd said about the
> Z80 made it sound better than the 8080.

It is an 8080 with lots of stuff kludged on.  Its design is messy,
but it does not offer anything less than an 8080 does.  There is no
reason to be using an 8080 instead of a Z80 that I would know of.

IIRC, the bus interface also was easier for tacking hardware on.  The
interrupt system again was, well...  If you used standard IM2
(necessary for Z80 components), the peripherals had to snoop on the
memory bus in order to detect when the Z80 was returning from an
interrupt by looking at the instructions it got.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de