New bootloader

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian » Wed Dec 13, 2017 9:52 pm

I am experimenting with some changes to the programming behavior, I will test it further on real hardware tomorrow.

Nothing radical, just that I introduced an approx. 4 sec delay to the user requested flashing. So when you call the bootloader to flash a new .uze, it will first show the empty progress bar for a little more than 4 seconds, and only then starts programming.

I also added a small delay (< 1secs) after programming before starting the game, so you can have an impression of the completed progress bar (which carries some info, like how much actual programming happened).

In total, this means that there is at least 5-7 seconds between each programming even if you wrote something (a pair of .UZE files) which tries to kill the ATMega, anyway, so there is time to pull the plug (it would demand almost a day to destroy the ATMega at this rate if it survived only 10K cycles).

I am doing some tests tomorrow still not because anything could be wrong here, rather to see how it looks like on actual television (including losses of sync).

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian » Thu Dec 14, 2017 5:46 pm

I finalized the changes, version is updated on the top post (5.0.09).

You may try how user-requested flashing looks like by downloading the API demo from a previous post.

If you find this bootloader OK, I will introduce this onto the master (Alec accepted it, so I guess now it is all set for the transition). Only 4 bytes free :P

User avatar
Artcfox
Posts: 945
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New bootloader

Post by Artcfox » Thu Dec 14, 2017 6:27 pm

Sweet! That seems like a good compromise. I'm excited to try this, hopefully I'll get the chance soon.

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: New bootloader

Post by D3thAdd3r » Fri Dec 15, 2017 4:03 am

Jubatian wrote:
Thu Dec 14, 2017 5:46 pm
You may try how user-requested flashing looks like by downloading the API demo from a previous post.
:shock: You mean it works for a program to trigger the bootloader to load another program automatically?!

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian » Fri Dec 22, 2017 3:18 pm

I added the bootloader to Master (under the name "Bootloader5"). Hopefully it works fine for everyone then! There are no changes, it is the same 5.0.09 version which is available to download from the top post here, but I didn't exactly receive much reinforcements on whether it works well on actual hardware. On my Uzeboxes it works fine of course.

User avatar
ry755
Posts: 154
Joined: Mon May 22, 2017 6:01 am
Location: California, United States

Re: New bootloader

Post by ry755 » Tue Jan 02, 2018 11:08 pm

If a program sets up an external interrupt, then uses the bootloader API to flash a different .uze file, will that interrupt still work? Or does it clear all the interrupts while flashing?

(I'm still kinda a noob when it comes to the AVR architecture :mrgreen: )

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian » Wed Jan 03, 2018 8:21 am

ry755 wrote:
Tue Jan 02, 2018 11:08 pm
If a program sets up an external interrupt, then uses the bootloader API to flash a different .uze file, will that interrupt still work? Or does it clear all the interrupts while flashing?

(I'm still kinda a noob when it comes to the AVR architecture :mrgreen: )
It won't work for two reasons.

First, when you pass over to the bootloader, it immediately disables all interrupts, then starts the bootloader's init sequence. The bootloader starts like normal, the API function just copies off the structure you pass to it to a safe spot in RAM where it can access it later. The bootloader has its own interrupt vector table (at 0xF000, beginning of the bootloader), so once it enables interrupts, your vector is not there.

Secondly, the bootloader of course programs the new .uze image, overriding the old one. Not wholly, only to the size of the .uze, but this still means that you interrupt handler (at least its initial jump) is gone. You could do tricks though by writing an incomplete .uze which requires data within the upper end of the game area in Flash, but this possibly have no much practical use.

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: New bootloader

Post by uze6666 » Thu Jan 18, 2018 9:09 pm

I have finally have a chance to install and play with your bootloader. I have to say I'm quite impressed and happy about it. :) Moreover it can read without issues a batch of cheap cards I've received and that totally fails to init with the current bootloader. So I will be testing it thoroughly and plan to use it for the next batch of kits.

Two comments:
  • Is there any way to makes the clicks when moving the cursors more "soft" like in the current bootloader? On my monitor they are a bit irritating.
  • How hard would it be to have an auto-repeat on up/down when using the cursor?
Awesome work Jubatian! :mrgreen:

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian » Fri Jan 19, 2018 10:39 pm

uze6666 wrote:
Thu Jan 18, 2018 9:09 pm
I have finally have a chance to install and play with your bootloader. I have to say I'm quite impressed and happy about it. :) Moreover it can read without issues a batch of cheap cards I've received and that totally fails to init with the current bootloader. So I will be testing it thoroughly and plan to use it for the next batch of kits.

Two comments:
  • Is there any way to makes the clicks when moving the cursors more "soft" like in the current bootloader? On my monitor they are a bit irritating.
  • How hard would it be to have an auto-repeat on up/down when using the cursor?
Awesome work Jubatian! :mrgreen:
That "click" was a dirty hack, however I could discover a more elaborate dirty hack to get something milder in the same ROM space: https://github.com/Jubatian/uzebox/tree/boot5010
Check it out, if you agree that it is more pleasant, I will merge this.

I gave some thoughts to the auto-repeat (it didn't came in my mind this far, usually I bounced the button anyway even in the old bootloader as it was faster than waiting for the repeats to come). Along with the audio modification, I could free up 4 bytes, so I have now 8 bytes, 4 instructions. I couldn't discover any hack which could get such a functionality done in that. Moreover what I wouldn't like is if a held-down button for bootloader entry was interpreted as an user action (due to an autorepeat), which would require even more code to filter out. So for now I would rather pass this one, as I think it is still more user-friendly without it (that is, if there was no way to avoid registering a held-down button as a repeating press on startup).

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: New bootloader

Post by Jubatian » Sun Jan 21, 2018 8:25 am

Huh, sorry, if you are worrying about compiling it yourself, here I provide a .hex for it. You shouldn't worry about it, though, it is full assembly, so it is completely deterministic, you would get the same bootloader binary. I just forgot that I should have provided one.

(If you like it, this will be the 5.0.10 version, otherwise just a test, don't save it yet)
Attachments
Bootloader5.hex
Using a different "click" sound.
(11.28 KiB) Downloaded 85 times

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest