I guess I can see where you're coming from now. It's kind of a foreign idea to me because I have never had to work with someone else's OS on the 6502 since 1982 when we used the AIM-65's in school. I've always had full control of every speck of code, and my workbench computer quickly compiles applications on the fly every time I load them up to use them, so even the possibility of changing addresses in the kernel are no threat. I commented above about the problem of task-switching happening at the worst possible times.
Garth
Understood.
As an avid Forth programmer myself, I fully desire having full control over everything. I'm currently hacking up a new native Forth implementation for my old, otherwise useless 486 laptop (not enough resources to run any OS of modern value, including Linux). I'm really enjoying the experience, but I fear that when it comes time to control the video, I won't have the degree of control that I desire. The chipset is Cirrus Logic, and that's all I know about it. It's really bizarre. I originally wanted to go into protected mode and utilize all available memory, but it's looking like I can't do that now, because going into protected mode eliminates any possibility of invoking BIOS services to set video mode.
I'll just use "flat real mode" to fake a protected-mode environment in real-mode, I guess, and although program code will be limited to the first 640K (indeed, in my system, it'll probably be limited to a single 64K segment!), and set up extended RAM as a super-fast cache for block I/O. That should give me the next best thing in convenience and speed.
Just as a side project, I'm planning on building a wire-wrapped home computer around the 65816, probably running at 4MHz (since I have 7 CPUs of this type, I might as well do something with them). This is a long-term project for me, unfortunately, as I have many other things competing for my brain at the moment. It'll probably have 128K of RAM to start off with. And as much as I love preemptive multitasking, seeing as how the kernel will be Forth, I've decided to stick with cooperative multitasking instead. It's easier to implement in the kernel (indeed, for the Forth VM, it's utterly trivial), and as long as the applications are multitasking aware, it can be sufficiently responsive enough to rival preemptive systems. I have no real-time requirements, so preemption is a complexity not worth investing in. (Though I've done it in the past, and it's not that much harder to do once you've gotten cooperative multitasking implemented. So if I ever need it again, it would be rather easy to add.)
The nice thing about Forth is that switching from one application to another involves, literally, recompiling the source of the application from scratch. Suppose I have a calculator on-screen. I want to switch (back?) to a word processor. When I do that, the word processor invokes a word along the lines of "NEW" or something (it's usually Forth specific), which resets the Forth dictionary, and provides a clean slate for the WP code to load in. Since it's all source-based, fixups and OS entry points aren't a consideration. In fact, the coupling between the application and the Forth kernel is so tight that it's hard to tell where one starts and the other ends.
Moreover, the persistence mechanism of Forth mimicks how a data cache operates; thus, even though your application is swapped out of memory, if your application's DATA space is kept purely in blocks, you still get excellent performance with the additional benefit of near-full persistence.
Another nice thing about Forth is that the language itself makes making multitasking-aware applications dead simple. In fact, they're as simple as non-multitasking-aware applications. Unless you're going to be doing heavy inner-loop calculations, you'll almost never call PAUSE yourself, which relinguishes the "time-slice" to another task, but otherwise appears as a NOP to the application. Forth's I/O words, including KEY(?), BLOCK/BUFFER, etc. all implicitly invoke PAUSE after initiating the I/O operation (hardware permitting), allowing some form of overlap to occur. It might sound primitive (and it is), but I've used systems like this, and considering the Forth kernel is kilobytes in size, the results are absolutely impressive. When developing code, I honestly thought it had preemptive multitasking at first.
But I'm digressing, and it's way off topic for this channel.
I'll go back to my notebook and continue daydreaming about the '816 project.
