Uzebox SD Gameloader V0.4.5

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox SD Gameloader V0.4.5

Post by CunningFellow »

Can anyone else compile and flash the boot loader then.

So far we have one person that can and three who it fails for. (One Linux and two Win7 users who can't)
xiaolong
Posts: 12
Joined: Thu Nov 19, 2015 7:40 am

Re: Uzebox SD Gameloader V0.4.5

Post by xiaolong »

I have been using Atmel Studio 6.2 on Windows to compile bootloader. Tried Atmel Studio 7 too, but it didn't work.
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox SD Gameloader V0.4.5

Post by uze6666 »

Yeah, it's not the first time I hear "later" version of GCC produces an unworkable bootloader. I really don't know why though.

Do you absolutely need to compile it yourself or you would just like a working HEX? If so, attached to the main post of this thread is the exact version I use with my kits and it works fine. It's been compiled some time ago with gcc...4.6.1!
http://uzebox.org/forums/download/file.php?id=2044
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox SD Gameloader V0.4.5

Post by CunningFellow »

I am working on a new bootloader that supports SDHC, Fat32, SD-CRC checking and flash verification.

Having the old one compile along side the new one for some test would have been useful.
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox SD Gameloader V0.4.5

Post by uze6666 »

Well if you can still find GCC4.6.1, I guess it should work.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzebox SD Gameloader V0.4.5

Post by Artcfox »

We just discovered that the current bootloader compiles and runs correctly when compiled with avr-gcc 4.5.1, which can be downloaded for Linux here: http://www.atmel.com/images/avr8-gnu-to ... _64.tar.gz

Installation instructions on Linux:
Download the above file (it should be stored in your ~/Downloads directory). Then open a Terminal and type the following:

Code: Select all

cd ~/Downloads
tar xf ~/Downloads/avr8-gnu-toolchain-3.2.3.314-linux.any.x86_64.tar.gz
export PATH=~/Downloads/avr8-gnu-toolchain-linux_x86_64/bin:$PATH
and then in that terminal only avr-gcc 4.5.1 will be on your PATH, and will be found before any other installed version of GCC.

then you can type:

Code: Select all

cd ~/uzebox/demos/Bootloader/default/
make clean
make
to compile the bootloader.

Note: If you close that terminal window, and open it again (or open a second terminal window), you will be right back to using whatever other version of avr-gcc you may have installed, so this is a great way to have multiple versions installed without them interfering with each other. If you want to switch to using avr-gcc 4.5.1 again, simply type:

Code: Select all

export PATH=~/Downloads/avr8-gnu-toolchain-linux_x86_64/bin:$PATH
into a terminal, and then inside that terminal, you will be using avr-gcc 4.5.1.
Vikt0r
Posts: 7
Joined: Fri Dec 26, 2014 5:16 pm

Re: Uzebox SD Gameloader V0.4.5

Post by Vikt0r »

Hi everyone!
Any ideas why the 0.4.5. gameloader behaves strange on my TV? When I go with the 0.4.4. version - everything works fine,
the SCART-connected TV detects the video signal as NTSC and displays it appropriately.
But when I flash the 0.4.5. gameloader - the display initially is OK, but in a second the TV detects the input as PAL-M(!), switches
something and the top of the image gets bent to the right, as well as some artifacts displaying on the bottom. Of course, when I load
games - they works just the same way as before, but the spoiled image is annoying...
I did use the binary attached to this thread, didn't compile it for myself...
Any thoughts why my TV thinks it's PAL-M? What changes since 0.4.4. could make this happen?
Thanks in advance!
xiaolong
Posts: 12
Joined: Thu Nov 19, 2015 7:40 am

Re: Uzebox SD Gameloader V0.4.5

Post by xiaolong »

Hi Vikt0r!
There were some problems with vertical sync in bootloader that led to problems with my TV too. Attached is bootloader with slightly different vertical sync. Could you try if it works for you?
Attachments
Bootloader.hex
Bootloader with slightly different vsync
(8.76 KiB) Downloaded 656 times
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox SD Gameloader V0.4.5

Post by uze6666 »

Hmm, i think only a couple NOPs where added to 0.4.5 for the SD interface. Should not have impacts on the video. That said it is well possible that it was compiled with a different version of GCC and we all know the generated code then changes almost every time...sometime for the worst :(. I guess then if for some 0.4.4 works better then use that one since it's functionally equivalent.
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox SD Gameloader V0.4.5

Post by D3thAdd3r »

Jubatian's work on CUzebox bootloader emulation has me interested in this topic again.

I think the most useful possible feature that could be added to the bootloader, would be the ability to flash itself from a file on the SD card. There is some risk if it should fail, but then it will require an ISP, which the user would have needed anyway if they really wanted/needed a new version of the bootloader. Part of the reason a user might want a new version, would be timing issues with an SD card. In that case it would even be semi-useful, so long as they had any other SD card that worked. Maybe they have a bigger card with worse timing, and they want to support it or something.

I am unaware of any reason this wouldn't be feasible. As I found some place some time ago, the bootloader is even susceptible to timing attacks from a normal user program which can force an SPM to an arbitrary location. I have no idea if this is something that would work in the emulator, but it is not an ideal solution anyway, compared to built in functionality.

Is there any reason besides code space and work that this wouldn't be possible?
Post Reply