Ive been reading the programming docs for the #Tandy600 , and, keeping in mind that I've done 8080 and x86 (32bit) assembly but not 8086 assembly...
I think we've got enough info to actually write programs for the 600. It would be a lot easier if the "microsoft works utility disk" actually existed anywhere, a debugger is always nice. But it sounds to me like the mysterious "execvt" just undoes whatever magic masm 4 insists on doing to build .exe files.
A less msdos-focussed 8086 assembler would be a good starting point. There's lots of possibilities there!
anyway, long term thoughts. even if i had the time, #Tandy600 dev work is behind "build a new battery pack" and "throw money at a maker to build me some RAM expansions".
Also HHOS (yes thats what MS called the OS - "HandHeld Operating System") really is the descendant of the #Model100 OS... The files in RAM have that same incredibly fragile edited-in-place thing going on.
That is, in fact, why the ROM apps have such huge minimum data file sizes. The in memory data file is the process's data segment: stack, variables, and the data set! Hence the 64k limit of data files...
Any user keypress may be a kill or a task-switch, and it is the process's job to make sure the RAM filesystem is sane before going away.
One neat part is that, when you load a file into an app, that app is in *exactly* the state you left it in! Unless it was confused...
This means however that data file compatibility is a lost cause. ðŸ˜
I mean I've read complaints that modern MS data files are just raw memory dumps but I doubt they include the full stack... 😉
The HHOS work may be where that habit started!
Willard Goosey