[Coco] Coco3 warm start...

[William Astle]

William Astle wrote:
> Yes, but that test does NOT run unless the test in block $38 fails first
> so if Basic is initialized, it never checks block $00 but rather
> branches into the warm start code. That is to say, $C0DE does not
> execute if the Basic warm start vector is valid. That means on a warm
> start, the ROM is not copied to RAM (which is as it should be).
> 

Okay, replying to myself. Tacky I know, but I figured out where I went
wrong with my analysis.

After tracing the code in mess, I realized that because the system is in
ROM mode, when it checks the ordinary Basic reset vectors, it finds
invalid data there (Disk basic is not present and the Extended Basic ROM
is set to have $FF at the reset point rather than $12 which gets set
back by the patching code). Then, after it has finished copying and
patching the ROM code, it jumps into Basic which then determines that it
really is a warm start.

Upon reflection, it does make some sense that they would do that since
if you are pressing reset to recover from a runaway program, that
program may have clobbered the "ROM" area.

What it does mean, though, is that if you have a reset routine somewhere
between $6000 and $7FFF or below $4000 (in the basic memory map), you
could bypass the ROM copy process. (If it's between $4000 and $5FFF, it
won't be visible to the startup code because it will be swapped out
while said code is running although you could fool it by pointing the
reset vector to $4002 or so where a bunch of NOPs are in the startup code).

Of course, you can also throw some code in the bottom block of RAM and
arrange things that way, too.

Now my brain is straightened out, I can stop worrying. :)

-- 
William Astle
finger lost at l-w.ca for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w---
!D !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?