CAESAR Logo

Catalogue of Arcade Emulation Software - the Absolute Reference

Valid XHTML 1.0! Valid CSS!

X-Arcade

X-Arcade

Large CAESAR Logo

halleys.c

0.61 [Phil Stroffolino, Jarek Burczynski, MacFarlane]


TODO:

- Status reads from blitter RAM aren't well understood. They probably includes both completion and collision flags.

- The blitter is missing many features, in particular certain sprites aren't erased properly.

- It isn't known how many independent planes of graphics the blitter manages. The starfield, for example, probably involves at least two additional planes orthogonal to the sprites and scroll layer.

- Background tiles inside the comet have wrong coordinates.

- Score digits have wrong colors.

- Blitter functions, especially those capable of screen warping, are unoptimized.

- The starfields can probably be represented and rendered by two simple lists instead of costly bitmaps.

- Ben Bero Beh has collision problems with the falling fireballs and a minor priority glitch with the "Elevator Action" baddies.

- Halley's Comet's undocumented dipswitches only work if the player1 start button is depressed during boot-up.


NOTES:

- Halley's Comet was created by Fukio Mitsuji (MTJ), who also created Bubble Bobble, Rainbow Islands, Syvalion, etc.

- Halley's starfields: Each star map is generated by two data sets pointed by the second source address. The first 256-byte set has scattered bits to reflect the star population while the second 256-byte set appears to have random values. When the game runs the star fields are updated a small portion at a time by a third data set containing gradient patterns which may indicate gray shades or alpha levels. Halley's Comet draws and clears the two star fileds as if they are independent from the backgrounds, making it a total of four scrollable layers. However, only two pairs of scroll registers are in use and they affect the stars and the backgrounds together - possibly afterthoughts on the original Ben Bero Beh hardware. This algorithm is based on speculation and deemed inaccurate.

- Halley's sound: How the custom chips handle sound latching is largely unknown. Halley's Comet dumps sound commands to register ff8a so rapidly the AY8910 core sometimes fails to reset itself and the music stops. Masking sound NMI is not enough to ensure successive writes are processed properly so it is advisable to queue sound commands or make the main CPU yield for a minimum of 600 Z80 cycles. Furthermore, soundlatch NMI interval should not be too much shorter than music IRQ's period(27306667ns), and must be longer in case of a reset(00).

- Halley's collision detection: The blitter hardware does per-pixel comparison between two sprite groups. When a collision occurs the ID's(memory offsets/16) of the intersecting pair are written to ff8b(certain) and ff67(?). Then the blitter causes an alternate IRQ to alert the CPU and a second check is performed in software to verify the collision. The trial emulation of the above was painfully slow and inaccurate because collisions are not verified immediately during IRQ. Instead, a dedicated loop is run between game logic and VBLANK to constantly check whether new collision ID's have been reported. The blitter somehow knows to IRQ at the right moment but I couldn't find any clear-cut triggers within the register area. It is possible to bypass blitter-side collision altogether by feeding a redundant sprite list to the main CPU, given that the processor is fast enough. This method works reliably at 5MHz or above and will certainly break under 4MHz.

- Driver: Phil Stroffolino for the creation of a solid framework, Jarek Burczynski for adding sound and providing awesome hand-drawn schematics and Jason MacFarlane for invaluable videos and screen shots.


WIP:

- 0.72u1: Acho A. Tang made many fixes and cleanups to Halley driver.