 | | Re: fast firmware downloader
|
|
(...) Just for the record, I implemented a dual-speed downloader a few months ago and mailed John Tamplin with information about it with regards to the JVM port that seems to have died. I used a different strategy to hack the dual speed downloads. (...) (25 years ago, 3-Oct-99, to lugnet.robotics.rcx.legos, lugnet.robotics.rcx)
|
| |
| | egcs-1.1.1 patch, legOS projects structure
|
|
Hi, this night is proving productive. I went ahead and tweaked egcs to produce RCX-specific interrupt handler prologues and epilogues. Apply this patch against egcs-1.1.1/gcc/confi...0/h8300.c, and you will be able to create interrupt handlers the (...) (25 years ago, 3-Oct-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: fast firmware downloader - and compilers
|
|
(...) Not at all ;-) fast.srec works like this: - load new image, storing it immediately behind fast.srec - fix stack pointer, you'll start new firmware anyways - relocate a small routine immediately below SP - call that routine - relocate the (...) (25 years ago, 3-Oct-99, to lugnet.robotics.rcx.legos)
|
| |
| | RE: fast firmware downloader - and compilers
|
|
I'll have to try fastdl at some point. My pbFORTH image is assembled to live at 0x8000 and be loaded just like "real" firmware. If I use fastdl, how do I have to change my firmware assembly output to accomodate it? On the subject of configurable (...) (25 years ago, 3-Oct-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: fast firmware downloader
|
|
(...) Erm, hrm, well... the reason I didn't ship it yet is that it won't compile with any released version of legOS. In order to gain full configurability, I had to set up a seperate directory structure, with its own include tree and stripped down (...) (25 years ago, 3-Oct-99, to lugnet.robotics.rcx.legos)
|
