SpriteDemo should be fixed

Use this forum to share and discuss Uzebox games and demos.
Post Reply
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

SpriteDemo should be fixed

Post by Jubatian »

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).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: SpriteDemo should be fixed

Post by Artcfox »

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).
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.

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 

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.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SpriteDemo should be fixed

Post by Jubatian »

Artcfox wrote: Wed Oct 04, 2017 9:12 amEdit: 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: (...)
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).
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SpriteDemo should be fixed

Post by D3thAdd3r »

Nice find! :)
Post Reply