SpriteDemo fails to run

[Jubatian]

SpriteDemo simply crashes when attempting to run it. I noticed this since a while, but only looked at it now thinking it was a Mode 3 demo possibly pinpointing some issue in Mode 3.

It is however a Mode 2 demo, and why it fails is that something is broken in the INTRO_LOGO=2 feature. Changing this to INTRO_LOGO=1 makes it running (and it is a quite nice looking demo). The feature is described using a PCM synth voice for the intro sound, and it works correctly in the Atomix game.

Could someone look at it with more knowledge of the audio part of the kernel? And possibly fix SpriteDemo to work with INTRO_LOGO=2 as intended? (It could be fixed cheaply by just reverting it to INTRO_LOGO=1 which at least makes it running, but that's a bit too cheap, and it doesn't even appear to have the sample necessary for the "bling")

[artcfox]

I just tested it now, and it runs fine for me. However, like a few of the demos (and even some finished games like Roguze), you must run the .hex file through the emulator for it to work properly. The .uze file for SpriteDemo and Roguze (and some others) are what is broken.

When I manually run packrom on that SpriteDemo.hex file (or if I look in the logs when I just run make on the uzebox source tree) it says this:

    Packing file: SpriteDemo.hex
    Game Name: SpriteDemo
    Author: Alec Bourque (Uze)
    Year: 2008

    ***Warning***: The hex file has instructions after
    the 60KB mark, which are being ignored and is, probably, incompatible with the
    bootloader. Note: This might not be a problem if your hex is a dump from the
    chip's flash.

    CRC32: 0x9c3d352c
    Program size: 61440 

So that's probably why the .uze file doesn't work. I think the solution should be to edit the Makefile for SpriteDemo to not run packrom, and just produce a .hex file, since it is a demo that assumes no bootloader.

[Jubatian]

I see, and as mentioned in the forum, I also discovered that a significant part of the actual demo code is beyond the 60K mark. Packrom will not even include it in the .uze, so no wonder it dies horribly.

CUzeBox by the way is not capable to run it since if it sees stuff above the 60K mark, it assumes a bootloader is present, and fuses the emulated AVR accordingly (this also applies to the "real thing", the AVR is normally fused to start the bootloader, if you forget about it, the demo won't run on the real Uzebox either).

[uze6666]

I can't recall if this demo predated the bootloader or if the kernel just got fatter, but indeed, the roms exceeds the allotted size. I have resized the beat sample to make it fit. All works fine now.