Implement fast firmware download #16
Description
Is your feature request related to a problem? Please describe.
It's annoying that firmware download is quite slow.
Describe the solution you'd like
Use quad-rate downloading as implemented in firmdl3. This involves downloading a stub first.
https://www.mralligator.com/rcx/tools.html:
Quad-rate downloading is a feature that significantly reduces firmware download times. It is implemented on top of a fast serial protocol that has a 2x baud rate with no complements or parity bits. The fast protocol is enabled by a short firmware stub that reconfigures some control registers and tweaks some ROM program state. Once the firmware stub is downloaded and executed, the ROM responds to the fast serial protocol, which the downloader then uses to transfer the actual firmware file. Because the initial firmware stub is small, all but the most trivial programs see a download time improvement when using quad-speed downloading.
The default baud rate is 2400, i.e. double the baud rate is 4800.
See fastdl.s:
/*
* fastdl.s
*
* A hack so to get the ROM running in a state with a doubled serial
* baud rate, at least until it is turned off and back on again.
*
* The contents of this file are subject to the Mozilla Public License
* Version 1.0 (the "License"); you may not use this file except in
* compliance with the License. You may obtain a copy of the License at
* http://www.mozilla.org/MPL/
*
* Software distributed under the License is distributed on an "AS IS"
* basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
* License for the specific language governing rights and limitations
* under the License.
*
* The Original Code is Librcx code, released February 9, 1999.
*
* The Initial Developer of the Original Code is Kekoa Proudfoot.
* Portions created by Kekoa Proudfoot are Copyright (C) 1999
* Kekoa Proudfoot. All Rights Reserved.
*
* Contributor(s): Kekoa Proudfoot <kekoa@graphics.stanford.edu>
*/
.lsym rom_init_handlers, 0x0688
.lsym init_timer, 0x3b9a
.lsym rom_main_loop_state, 0xee5e
.lsym rom_dispatch_struct, 0xee64
.lsym rom_counter_struct, 0xee74
.lsym rom_power_off_minutes, 0xee80
.lsym rom_update_function_state, 0xef06
.lsym rom_use_complements_flag, 0xef51
.global __start
__start:
; Set up as if ROM were waking RCX up
mov.w #15,r6
mov.w r6,@rom_power_off_minutes
mov.w #rom_dispatch_struct,r6
push r6
mov.w #rom_counter_struct,r6
jsr @init_timer
adds.w #2,r7
mov.w #rom_main_loop_state,r6
jsr @rom_init_handlers
; Double the baud rate
mov.b #103,r6l
mov.b r6l,@0xd9:8
; Turn off parity
bclr #5,@0xd8:8
; Turn off complements
sub.b r6l,r6l
mov.b r6l,@rom_use_complements_flag
; Hack the update function state so we don't hear two beeps
mov.b #2,r6l
mov.b r6l,@rom_update_function_state
; Hack the main loop state so we reenter ROM main loop correctly
mov.b #13,r6l
mov.b r6l,@rom_main_loop_state
; Return control back to ROM
rts
; String needed for new firmware
.string "Do you byte, when I knock?"
Assembled and converted to SREC:
S00E000066617374646C2E7372656398
S11880007906000F6B86EE807906EE646DF67906EE745E003BCC
S11880159A0B877906EE5E5E0006887FD87250FE673ED918EED4
S118802A6A8EEF51FE026A8EEF06FE0D6A8EEE5E5470446F2032
S118803F796F7520627974652C207768656E2049206B6E6F63C5
S10780546B3F00007A
S90380007C
The logic as taken from the firmdl tool: try fast mode by default
- Try to wake up the tower in fast mode
- When not alive in fast mode, download fastdl (
image_dl(fd, fastdl_image, fastdl_len, fastdl_start, 1);) in slow mode; then go back to fast mode - Download image in fast mode
Describe alternatives you've considered
Keep things slow as they are. At least this should be the backup option as it turns out to be more robust.
Additional context
Side effects:
- Doubling the baud rate may at least cause trouble with the DiyIrTower - but I guess almost nobody is using it anyways.
- Current software architecture may not consider changing the baud rate during runtime. Also need to check if WebUSB supports that, but probably it does.