Release Notes – F15 D’Gamma Clone

It’s release day again here at C64CD and, since most people will have noticed that we’ve established a routine, this new demo is for the Apple II and takes influences from the previous Code Notes instalments for the same platform (along with a couple of ideas from C64 demos as well). So here is F15  D’Gamma Clone, a crack intro style affair – there’s no sound because that’s what an Apple II intro in 1985 was more likely to do!

F15 D'Gamma Clone (Apple II)

There are three effects in operation here; the moving bars are loosely on Black Bag’s F-15 Strike Eagle intro but tweaked a little so that they’re split into twenty chunks[1] across the line with each being at a different position within the sine curve. We also have the logo moving, although the five tiles are shuffled one character at a time rather than the entire graphic bouncing up and down – this is based loosely on the first part of a C64 demo called Pastime 2 by Amok and Future Technologies 2009, except the Apple II version uses bitmapped graphics whilst the C64 is handling things in characters.

The final effect is below the static picture is four lines of text similar to the routine in Clonemas, but with the character inversion being randomly toggled on a cell by cell basis in a similar way to how the Lantern Of D’Gamma intro by The Six Pack worked – the randomisation code comes from a discussion at demo scene website Pouet and your correspondent’s 6502 assembly language version can be found within the source at Github by searching for the subroutine random.

One final thing to note is that in order to synchronise with the screen refresh, this demo relies on $C019, the topmost bit of which is set whilst the display is being rendered and clear during the upper and lower border areas. Although this appears to be quite well documented, your correspondent has previously read that said technique may not be compatible across the Apple II range; if anybody reading should find the time to test on their own system, please let C64CD know through the usual channels what the result was and which expansions are present!

Addendum added 2016-05-20 – Whilst the second edition of Apple’s own Apple IIc Technical Manual states that the vertical blank sync via $C019 mentioned above works, said official tome is apparently wrong and your correspondent will at some point write an updated version of his code to work around that difference. We have to note dear reader that this is precisely the kind of incompatibility that changes to a computer’s specification can cause and why your correspondent has always argued that Commodore’s decision to not upgrade the C64’s BASIC after the machine’s release was a sensible one!

Addendum added 2016-05-21 – An Atari Age forum user called “cybernesto” has very kindly fixed the vertical blank sync issue in your correspondent’s code and tested it as working on his Apple IIc and IIc Plus systems. If that solves the issue remains to be seen, but it runs on far more models of Apple II than before.

Addendum added 2016-06-03 – Marco Verpelli has tweaked the demo a little and converted the source for the Merlin-8 native assembler, this image has been uploaded to the Asimov archive.

[1] Your correspondent went with twenty rather than the possibly forty because it would have caused all manner of visual artefacts.

Advertisements
This entry was posted in Programming and tagged , , , , , , , , . Bookmark the permalink.

4 Responses to Release Notes – F15 D’Gamma Clone

  1. The //c is an odd duck. So $C019 didn’t exist for the early ][ models. The //e and //gs set $c019 one way and the //c basically does the same thing but inverted hi-bit. Hence, there was never a very reliable VBL sync and most games would only officially support //e, //c and //gs so that only thing was needed was some kind of machine ID routine to determine if it was a //c or not. BTW: The intro looks sweet on Jace. I’ll send you a screenshot.

  2. TMR64 says:

    Ouch… i wonder what Apple were thinking breaking compatibility like this?! I can see why the support focused on only the IIe, IIc and IIgs and it seems a sensible move; is there any online documentation covering machine detection by any chance?

    i did previously try the technique that checks what is being drawn and waits for a unique byte to go past, but there seemed to be inconsistent as though it could “see” the same run of bytes at more than one place on screen? It could just be the emulator wasn’t drawing properly of course, but i don’t have real hardware to test with for the moment.

  3. Michael says:

    Very impressive! At first I thought it was something like French Touch’s “Scroll, Scroll, Scroll” technique, but this seems to be doing brute force rastering, but only during the VBL…?

    • TMR64 says:

      It waits for the vertical blank and then updates the various elements from the top of the screen downwards to stay ahead of the refresh.

Comments are closed.