Asteroids for ReGIS

[Phillip Stevens]

For interest, I've ported an existing Asteroids game using SDL windowing to use the ReGIS serial interface. Asteroids is an original vector display game from 1979. It is derived from the original SpaceWar! game from 1962.

Using ReGIS for display means that any RC2014 based system can drive a Xterm screen to produce high resolution colour vector graphics.

My game repository is here.
https://github.com/feilipu/asteroids_regis

How to get ReGIS working on XTerm is here.
https://github.com/feilipu/ReGIS?tab=re ... port-regis

I have tested a bunch of different build options for a general CP/M target with 8085, z80, or z180 hardware. Obviously, the best performance is on z180 using 16-bit floating point. Only the BDOS STDIO interfaces are used for output and input. Of course either the punch or list output could alternatively be used for screen output.

Unfortunately the game is very very slow on an RC2014 z80 at 7.2MHz, so the next work is to optimise where possible.

The slowest code is rotating the asteroids (each with 10 vertices) on each iteration. Each vertice calculation requires a sin() and cos() calculation and matrix multiplication. Temporarily removing the ability for asteroids to rotate does speed things up substantially, but still nowhere near enough to make this game usable.

I mention this so that if anyone is interested in building or optimising this game so that it can run on period correct z80 based hardware (aka RC2014), it makes a good start to have working code from which to proceed.

I've used this code to further test completeness for different math libraries and machine types within z88dk. And specifically done some code optimisation using some useful z88dk math functions.

The hypot() function is worth special mention, as using it saves a lot of loading and unloading of intermediate variables over the simple implementation of sqrt(x*x + y*y). There are special assembly implementations for math16, math32, and for the APU math library am9511.

Hope this is interesting reading.

Cheers, Phillip

[Kevin Buhr]

Very interesting! I gave it a try (commit 4d4d7853) and managed to get a few frames displayed. Note that the frame would *only* advance when I hit a key (S, D, or A). Is this expected behavior? (I'm using an SIO/2 module for serial, if it makes a difference). Anyway, the ship did respond (very slowly) to the controls, though after a few frames of turning right, it displayed a line of mangled ReDIS and locked up. (And then eventually threw a "BAD INT" error.)

[Phillip Stevens]

On Friday 26 July 2024 at 06:44:01 UTC+10 Kevin Buhr wrote:

Very interesting! I gave it a try (commit 4d4d7853) and managed to get a few frames displayed. Note that the frame would *only* advance when I hit a key (S, D, or A). Is this expected behavior? (I'm using an SIO/2 module for serial, if it makes a difference).

I changed the key scan behaviour from getk() to fgetc() recently. Without checking precisely. Perhaps fgetc() is a blocking call? getk() immediately returns, but it is only available in the z88dk classic library. There might be a stdio library call that can be substituted that doesn’t block if no keystroke.

Anyway, the ship did respond (very slowly) to the controls, though after a few frames of turning right, it displayed a line of mangled ReDIS and locked up. (And then eventually threw a "BAD INT" error.)

Hmm. That’s odd. There is no interrupt code in the game. Just BDOS, behind the fprintf() and fgetc() calls.

Which CPU and math library did you build?

Cheers Phillip

[Kevin Buhr]

On a subsequent test, it crashed to a broken CP/M prompt before rebooting, so I think it's likely there's some kind of general memory corruption problem, and the "BAD INT" error was just a side effect of a corrupted BDOS/BIOS.  I'm running on a Z-80 and used the "SCCZ80 CP/M math 32 compile" method from the "README.md". I wasn't able to get the "SCCZ80 CP/M math16 compile" to work -- it gave an "error: undefined symbol: _sqrf16", and I haven't looked into it further.  I don't have AM9511 or Z-180 modules, so I wasn't able to test the others.

Yes, it looks like `getc(stdio)` is blocking. Switching back to `getk()`, the frames advance without key input. It still locks up after about a dozen frames, though.  Anyway, I'll keep fiddling with it.

[Phillip Stevens]

On Saturday 27 July 2024 at 04:05:36 UTC+10 Kevin Buhr wrote:

On a subsequent test, it crashed to a broken CP/M prompt before rebooting, so I think it's likely there's some kind of general memory corruption problem, and the "BAD INT" error was just a side effect of a corrupted BDOS/BIOS.  I'm running on a Z-80 and used the "SCCZ80 CP/M math 32 compile" method from the "README.md".

Ah. That is interesting! Usually with a memory issue someone (usually me) has written something that unbalances the stack. But in this case it is all C code so there’s something interesting happening, if it is crashing after multiple iterations or, better said, running correctly for a dozen iterations and only crashing at some specific point. Odd and interesting.

I switched my playing / testing to using a z180 because it was faster by clock speed and by hardware (with mul instruction), so that gives me a hint as to where the issue may be.

 

I wasn't able to get the "SCCZ80 CP/M math16 compile" to work -- it gave an "error: undefined symbol: _sqrf16", and I haven't looked into it further.

You will be using a slightly older version of z88dk. Try to download and use the latest nightly build.

Part of the fun of running other peoples’ code is to find out where there are issues with your own code. In the case of Asteroids, we found that missing entry points for sqr() in both math16 and mbf32 libraries. Also some missing entry points in the fix16 math library. And finally Dom improved the handling of callee functions in 8080/5 and Gameboy systems. All good outcomes from this simple game.

Yes, it looks like `getc(stdio)` is blocking. Switching back to `getk()`, the frames advance without key input. It still locks up after about a dozen frames, though.  Anyway, I'll keep fiddling with it.

I’ll have to find another standard way to do non-blocking key scanning if fgetc() is blocking. Anyway thanks for testing this.

Cheers, Phillip