how permanently protected does the 6 byte hole need to be? presume the RAM must contain opcodes and not just data? a commonly used place is "Hayash"...thats 6 bytes
On Wed, Sep 11, 2019 at 10:49 AM Kurt McCullum <[email protected]> wrote: > Got the code working properly but this leads to another question. I am in > search of 6 bytes of RAM. I used the same idea behind TS-DOS when the > DOS-ON feature is used. That inserts 6 bytes of code that calls the OptRom > ON routine and then jumps to the specific section of the Option ROM. When > that routine is done, it calls the OptRom OFF routine and returns. This is > really clean and only requires one EXEC statement in Basic to work. But it > does require the 6 bytes of RAM. I'm looking through the technical > documents right now to see if I can find a slice but I thought I would ask > in case someone may know of a specific area I could use. > > Kurt > > On Tue, Sep 10, 2019, at 1:07 PM, Kurt McCullum wrote: > > Thanks John, > > You are correct. It appears to be a stack issue. I've got the initial > error resolved but I've still got to do a little more work. Appreciate the > insights. > > Kurt > > On Tue, Sep 10, 2019, at 12:18 PM, John R. Hogerhuis wrote: > > Seems like you've embedded code in OptROM that you copy to ALT-LCD. > > When you say "the cold start recovery routine of TS-DOS" do you mean the > NEC POKE and EXEC to activate TS-DOS? > > If so it seems your only trigger to do the LINE install is the BASIC ROM's > OptROM install EXEC routine. So whenever the ROM installs, it will fill in > your code into ALT-LCD. > > I can't think of anything that you would have to do different than > whatever TS-DOS does. > > I suspect some stack imbalance, clobbered registers or clobbered RAM > variables. > > -- John. > > > >
