Uzebox SD Gameloader V0.4.5
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Uzebox SD Gameloader V0.4.5
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)
So far we have one person that can and three who it fails for. (One Linux and two Win7 users who can't)
Re: Uzebox SD Gameloader V0.4.5
I have been using Atmel Studio 6.2 on Windows to compile bootloader. Tried Atmel Studio 7 too, but it didn't work.
Re: Uzebox SD Gameloader V0.4.5
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
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
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Uzebox SD Gameloader V0.4.5
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.
Having the old one compile along side the new one for some test would have been useful.
Re: Uzebox SD Gameloader V0.4.5
Well if you can still find GCC4.6.1, I guess it should work.
Re: Uzebox SD Gameloader V0.4.5
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:
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:
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:
into a terminal, and then inside that terminal, you will be using avr-gcc 4.5.1.
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
then you can type:
Code: Select all
cd ~/uzebox/demos/Bootloader/default/
make clean
make
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
Re: Uzebox SD Gameloader V0.4.5
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!
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!
Re: Uzebox SD Gameloader V0.4.5
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?
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 663 times
Re: Uzebox SD Gameloader V0.4.5
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.
Re: Uzebox SD Gameloader V0.4.5
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?
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?