Penetrator (ZX Spectrum) - Z80 Block Copy is slow

https://www.youtube.com/watch?v=-AvJFKq3gC4&t=461s

@john2001plus
3 days ago (edited)
7:41  I played this game on the Timex-Sinclair 2068, which I purchased around the beginning of 1984 or the end of 1983.   The TS2068 isn't necessarily compatible with Spectrum games, but it could have been a port.  Maybe the sound was better because the 2068 has a sound chip.

If you did well, you got a fireworks show at the end.  We see this in the video, but I thought it was better with sound.

I may have played with the keyboard, which is how I usually played games.

The barrier on level 5 appears to be the end of the game.  I remember this now.

Given the hardware, I'm impressed with the scrolling.  I was impressed in 1984 because the block memory copy on the Z80 processor is super slow, which is how you would scroll the entire screen, although I can think of some coding tricks to do a slightly faster memory move.


@chronologicallygaming
14 hours ago
Great memories—and you're spot on. The TS2068's AY sound chip really does give it an edge over the standard Spectrum beeper, so that fireworks ending absolutely would've hit harder with proper sound.

And yeah, Spectrum compatibility was always a bit of a gray area on the 2068—very possible this was a port or at least heavily adapted. Keyboard play makes total sense too; that's how a lot of us tackled these back then.

That level 5 barrier lining up with the end of the game matches what we're seeing, so your memory's right on target. And agreed on the scrolling: for Z80-era hardware, especially with block memory moves being so slow, it's genuinely impressive. You can tell the programmer knew a few clever tricks to squeeze out performance.

Thanks for sharing, John. This is exactly the kind of firsthand detail that brings these games to life.


@john2001plus
14 hours ago (edited)
@chr@c @chronologicallygaming  I had a lot of Z80 programming experience.  I got to do it again on the Gameboy Color. It is a little easier to program than the 6502, because it has more registers and instructions. However, the 6502 is about twice as fast per clock cycle.  It was designed to be cheap and fast.



@john2001plus
3 hours ago (edited)
 @chronologicallygaming  The 16K video memory on the 2068 and Spectrum is contested memory, which means that the display chip has priority.  If you try to access the video memory while the display is being generated, then the processor will freeze until the horizontal or vertical blanking period.  

It is possible to swap memory banks in such a way that the vertical blank interrupt runs your code instead of ROM code.  This is a trick I didn't know back in the 1980s, but it would be useful for running all the video memory writes in the vertical blanking period, avoiding any processor halt.  (If most of the processor time is spent drawing to the screen anyway, such as my Diamond Mike game, then this trick might not help much.)

Unfortunately, BASIC code starts in the contested memory, which will affect the speed of BASIC programs.  I have read that there is a piece of ROM code that you can call which will relocate BASIC to the top 32K memory, which is uncontested memory.  This would make BASIC a little faster, but with less free space.  I wish that this had been the default, but that code in the ROM exists for a reason, so maybe they expected some people to use it.

The problem with the Block Memory Copy is that it does too many steps for every byte moved.  It moves a byte, increments two pointers, decrements a counter, and loops. This takes 21 clock cycles per byte.  However, if you knew that you were going to move a fixed number of bytes, such as 32 bytes on a line, you could write code that would move 32 bytes without looping.  Then you loop for each line you need to move.  

You could take this idea to a more extreme level, where you move 256 bytes without looping, but it would take 1K of code.  However, the computer has kilobytes to spare.

If you need to write the same bytes to a block of  a memory, such as the clear screen command, you can temporarily hijack the Stack Pointer to do it faster.  This only takes 5.5 clock cycles per byte.  (I suspect that the BASIC clear screen command uses the slow block copy instruction, because it is not instantaneous.)