search

SamCoVT / TaliForth2

A Subroutine Threaded Code (STC) ANSI-like Forth for the 65c02
Other
28 stars 4 forks source link

turnkey with warm start #88

Open patricksurry opened 2 months ago

patricksurry commented 2 months ago

In #87 you mentioned a turnkey word. Not sure if this is exactly what you were thinking but here's the approach that I've been using.

It adds a turnkey vector in a known rom location (just below the three system vectors). If the MSB is non-zero then that xt is execute'd at the end of cold. I normally point this to a blk-boot word which tries to boot from the block device if available.

I also add a forth_warm entrypoint which skips most of the initialization in cold. This is useful for making prebuilt memory images to simplify distribution - e.g. load and compile a bunch of words/data, then update both the turnkey vector (to run your code) and the reset vector (to a kernel_init that jumps to warm) and then dump the memory image to the block device. Now you have a standalone 64K image with your compiled code ready to go for pymon or c65 without needing block support or your original source code.

The other thing that might be relevant is TALI_USER_HEADERS. I use this so my platform can define its own header.asm/words.asm without having to modify the core source code at all. This mirrors your suggestion of (say) TALI_USER_FORTH which could conditionally include platform-specific forth source, perhaps replacing forth_code/user_words.fs

SamCoVT commented 2 months ago

I'll need to give this more thought. I've realized that users already have turnkey ability with the user_words.fs file (and could even implement your idea with : turnkey $fff8 @ dup if execute else drop then ; turnkey). I believe some platforms have vectors (for OS stuff) right under the hardware vectors, so it might be best to let users do this themselves if they want it.

patricksurry commented 2 months ago

maybe worth thinking first about how platform*.asm could be used to configure both forth_words and extra native words/headers without having to mess about elsewhere in the tali source code. I agree that the current user/forth words shared by all platforms is not ideal if you want to manage your platform-specific stuff independently of changes to the shared taliforth codebase.