TUTTI FRUTTI 64 by Spider Jerusalem // Release Date: 31.12.2014

Sorry, no Makefile this time.
Compiling info can be found in compile.sh and build-release.sh files.

Sources can be compiled with
ACME crossass, release 0.95.4 ("Fenchurch"), 26 Nov 2014
http://sourceforge.net/projects/acme-crossass/

Used cruncher was Exomizer v2.0.6.
http://hem.bredband.net/magli143/exo/

Other Tools used:
=================
- Charset Editor of C64Studio
    http://www.georg-rottensteiner.de/files/C64StudioRelease.zip
- CharPad 1.0 + CharPad 1.8
    CharPad V1.0
    CharPad V1.8.3
- Geany Text Editor
    http://www.geany.org/
- NinjaTracker V2.04
    NinjaTracker V2.04
- Regenerator 1.3
    Regenerator 1.3
- SID-Wizard 1.7
    SID-Wizard V1.7
- SpritePad 1.8
    SpritePad V1.8.1
- VICE
    http://sourceforge.net/projects/vice-emu/
- YAPE 1.0.6
    http://yape.homeserver.hu/

Added features/changes since v0.1:
==================================
- Alternative Sprite Set
- Attract / Demo Mode
- Built-in Trainer
- Docs File
- Gameplay Features Complete
- Highscore Saver + Topscore Reset Feature
- Introduction Sequence
- Multicolor Rastersplit and additional Charset GFX
- Music Data moved to one single Tune + Subtunes
- Several Bugfixes
- SFX volumes and priorities adjusted

Flaws/Bugs of the C16/Plus4 original that were left out:
========================================================
- Apple fall slowdown when having 2 or more apples fall and running from
  left to right
- On player death Half-Tiles stayed on screen, Cherry score was already
  counted when "collecting" half of the cherry
- Add points to Score as level reward failing most of the time (at least
  from the disassembly I assume scoring was planned like I implemented
  it in this version)

Flaws/Bugs of the C16/Plus4 original that were reproduced:
==========================================================
- Moving chests/boxes in Gametype 3 will disappear from map on player
  death, but still be visible on screen. Fixing here would have
  influenced the gameplay. While it would have been nice to avoid that
  the solid apple tiles can get erased, allowing the moving boxes to
  finish their moves on player death would also have meant they could
  kill enemies. This seems logical, but it would influence the enemy
  counter and create a big difference to the original.
- Enemies are allowed to walk over tiles blocking the enemy base.
  Because of hard sprites this looks a bit weird in the C64 version,
  but overall it's still more logical than in the original where those
  tiles get erased from screen, but not from the map.

Technical info:
===============
 I read some discussions in WWW why this turned out as a port (re-write)
of the original instead of a straight conversion of the C16/Plus4 code.
Fact is, my first approach was to do a straight conversion. I started
disassembling the code and getting it to run on a C64 by changing TED
registers to VIC/SID/CIA registers and only rewrote part ot the IRQ and
input routine first. This resulted in a playable version (with no sound
of course because TED & SID registers work differently) with horrible
graphic glitches and sprite flickering. I was hoping by optimizing and
rearranging the IRQ this could be easily fixed. I was wrong.

 Accoring to Wikipedia the 8501 runs at 1.76 MHz while the 6510 runs at
0.985/1.023 MHz (PAL/NTSC). I thought because of the possibilty to
replace software sprites with C64 hardware sprites the speed difference
would be compensated. In theory this is true.

 In case of Tutti Frutti the original code did fire up a raster IRQ
around line ~$f0 just before the bottom border and had all its game and
display logic executed from there until the top of the screen display
(around line ~$30). But meant my first straight conversion try didn't
finish this whole code until around ~$70-$80 on C64, because of less CPU
time. The big problem now was that Shaun Southern didn't care for
proper speration of game logic and display routines because all the
calculations would be ready until screen display on C16/Plus4 anyway.
The only thing I was able to extract from the main IRQ to be executed
while screen display were the enemy A.I. routines. But still the rest
of the routines wasn't executed fast enough, so there was flickering
left in the first 3-4 screen lines. That maybe doesn't sound much, but
keep in mind I'm living in PAL-land and on NTSC this would have been as
worse as my first PAL version (because of less rasterlines around VBLANK
on NTSC). So my next steps were trying to optimize the routines and re-
arranging them to avoid flicker.

 But the big problem you get when fiddling around with external code is
that you can't just move around some routines here and there without
creating more and more bugs. Ever since I tried to add SID music to this
conversion mess I had created I realized: a straight conversion is a
dead end.

 So I started all over again, re-writing the whole engine and just took
the most important parts for the game logic of the original disassembly
to get the gameplay as original as possible. Of course in my rushed v0.1
release for the RGCD competition I missed out a lot of things. Keep in
mind I did v0.1 within two weeks. And even with that approach combining
original algorithms with my re-write wasn't that easy. The bug that
shooting can destroy memory is a good example for that. On the one hand
I needed to leave the shoot routine as close to the original as possible
to get the same behaviour, on the other hand I wanted to replace most of
the coordinate calculations with look up tables on C64 for faster
execution, i.e. to make sure the game would also run on NTSC and to have
enough raster time left for other features. Getting rid of that shoot
bug was one of the hardest parts in development of this final version.

 In the end I think it was a good decision and the version you can play
now is both: very close to the original, but also runs smooth and hope-
fully bug-free [ in case: blame the testers, not me ;-) ] on C64 PAL and
NTSC machines. If someone still isn't satisfied with the result, you now
have my sources and can improve it further. But I hope this shouldn't be
necessary. If I ever do any port/conversion again, I'll for sure won't
my waste time to get some other code to run on the C64, but only analyse
and then do a re-write from the start. I have deep respect for
crackers/reverse engineers who manage to do serious bug-fixing on 80ies
original code. It's way more hard to sort shit out that others had
produced than sorting your own.

 I hope the sources are understandable. I tried commenting more than I
usually do. But due to laziness on some routines I just copied over my
comments from the disassembly and did some changes with search/replace,
so they may not be 100% fitting everywhere for the final routines.

Additional info:
================
 Especially game coders may be also interested in my modification of the
NinjaTracker V2.03 gamemusic playroutine. Many PAL coders only do a
framedrop to adjust songspeed when playing tunes on NTSC. The reason why
this doesn't sound good in many cases isn't just the framedrop, but also
the fact that on NTSC the SID note frequencies are different to those on
PAL. For Tutti Frutti 64 I just extended the player source by a NTSC
frequency table that can easily be copied over the PAL table after
successful NTSC detection. Just take a look in src/nt2play.asm.

Special Thanks:
===============
- Sunny for introducing me to this game on Plus4
- Momo, our cat who was doomed to listen to the game tunes several hours
  almost every day for 7 weeks now while I was working on the game
- Peiselulli for his inspiring Vectrex & Atari ports
- Enthusi for the Attract-/Demo Mode idea

Have fun!
spider.