That's all good Seairth. Now I have to let you down by saying that's the unsanctioned simple approach.
The official line is use one of two controlled handover methods. Either by always reverting to RCFAST first, called RCFAST handover, or by passing a copy of the currently set mode to the loaded program, called Mailbox handover, at hubRAM address $18. Further reading - https://forums.parallax.com/discussion/comment/1466702/#Comment_1466702
Hey, if Chip agrees that those are the "official line", I'll just take that code wholesale and put it in the Doc.
Back on Prop_Clk, though, I'm starting to question if there's too much there. The reality is that the only time someone is going to call it is just prior to doing a Prop_Hex/Prop_Txt. And, once the binary is loaded, it starts executing. In other words, there'll never be a chance to change the clock again (using Prop_Clk).
It's a limited command line. It doesn't have to be automated but obviously most uses will be. In reality I doubt anyone uses Prop_Clk because a small second stage loader will be loaded at the reset default of RCFAST and from there set the clock, if at all, using HUBSET.
Comments
Hey, if Chip agrees that those are the "official line", I'll just take that code wholesale and put it in the Doc.
> Prop_Clk 0 0 0 0 F0 or whatever just runs after boot up or reset, right?
and then we should be at rcslow, right?
Or does the old clock setting survive a reset?
confused,
Mike
It's a limited command line. It doesn't have to be automated but obviously most uses will be. In reality I doubt anyone uses Prop_Clk because a small second stage loader will be loaded at the reset default of RCFAST and from there set the clock, if at all, using HUBSET.