🚀 go-pugleaf

David Kastrup <David.Kastrup@t-online.de> wrote:

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

Ye gods.

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

Coo.  I had wondered how that sort of thing was done, and now I know.

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

Coo!

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

<chuckle>

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

Uhuh.

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

Righto.

> IIRC, the bus interface also was easier for tacking hardware on.

I don't know about easi*er*, but it was certainly easy when I tried it.

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

Bleh.

Rowland.

-- 
Remove the animal for email address: rowland.mcdonnell@dog.physics.org
PGP pub key 0x62DCCA78                      Sorry - the spam got to me
                                                 http://www.mag-uk.org
UK biker?                    Join MAG and help keep bureaucracy at bay