Could anyone look into this issue?
https://github.com/Uzebox/uzebox/issues/77
And maybe create a proper fix for it? I really don't want to get much involved in this, the sound & music engine is one of the parts of the kernel which I never really looked into: it seems like it would demand a bit too much effort for me right now.
By the way this as far as I remember a quite old problem, I can never recall being able to compile this demo right. So possibly something broke even from before 2015 or earlier (might be wrong with that, I don't know when I first noticed this, but it was quite long ago).
SpriteDemo should be fixed
Re: SpriteDemo should be fixed
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.Jubatian wrote: ↑Wed Oct 04, 2017 7:14 am Could anyone look into this issue?
https://github.com/Uzebox/uzebox/issues/77
And maybe create a proper fix for it? I really don't want to get much involved in this, the sound & music engine is one of the parts of the kernel which I never really looked into: it seems like it would demand a bit too much effort for me right now.
By the way this as far as I remember a quite old problem, I can never recall being able to compile this demo right. So possibly something broke even from before 2015 or earlier (might be wrong with that, I don't know when I first noticed this, but it was quite long ago).
Edit: 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:
Code: Select all
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
Re: SpriteDemo should be fixed
That's it, it is indeed larger than 60K, and worse, the actual main code is beyond the 60K mark, so no wonder it is broken when this part is chopped off due to being packaged into .uze.
Checking it a bit I found however a quite space wasting bug.
There is this page: https://access.redhat.com/documentation ... tions.html , it describes in 4.6.3 how the sections work during linking. So I discovered some ridiculous paddings with no apparent reason, purpose whatsoever, and tried to track down their origin. In particular not only here, but in other mappings of binaries I found the DisableSoundEngine routine aligned to a ridiculous 256 byte boundary for no apparent reason.
So by the above page I found the reason and confirmed it. It is that for example after DisableSoundEngine, there is the step table and the wave table, the latter in particular is aligned to a 256 byte boundary. And it is still inside the .text.DisableSoundEngine section! By the above documentation and the linker script used to link AVR binaries, I found that the ".text : { (...) }" case applies (in 4.6.3 there). So the section itself will get aligned to a 256 byte boundary since there is a 256 byte boundary alignment constraint within, and then again the actual wave table will be aligned again. Moreover it turns out that the DisableSoundEngine isn't even used...
Long story short: I am doing some bugfixing again in the kernel (I will hunt these down to eliminate such ridiculous waste).
Re: SpriteDemo should be fixed
Nice find!