6502.org

As another view on zeropage, it's also common to have a subsystem (say, a set of floating point routines) which use some area of zero page as a scratchpad (say, two or three multibyte values.)

Indeed Sweet16 is such a subsystem, but I think that's more often mentioned than actually used!

Yes, I'd say that was ubiquitous for 6502 systems (was going to say operating systems, but for most of the computers of that time saying they had an operating system was probably a stretch in todays terms). The most advanced operating system that I can think of GS/OS still had allocated direct page locations, and as in the example above, the SANE floating point library did make use of a documented set of locations, as did most other libraries.

In terms of modern operating systems this is all very problematic as things like a context switch require saving the active processor state, which may mean saving zero page locations if they were unique to the current process. Multitasking might be a step too far, but if we did want networking, for example, then we need at least some limited multitasking, or maybe just interrupt routines would be enough, but it still leads to the same issues.

That's one of the interesting things about 6502 systems, by necessity they needed to come up with quite different solutions to issues than modern operating systems have standardised on. I'm sure I need to adapt my thinking to consider that.

I just checked the approach used in Acorn's 8-bit MOS, as used in the BBC Micro and successors. It's not a multi-tasking system, but it supports paged ROMs which are in effect independent software subsystems. In response to some OS calls, a series of paged ROMs may be called on to respond, and so there has to be a memory allocation story for them. However, there's one long-term tenant which is "the current language" and one medium-term tenant which is "the current filesystem."

Restricting the story to zero page, the "current language" has 144 bytes of zero page, whereas the "current filesystem" has 32 bytes of zero page. There's 16 bytes for the Econet system and the rest is used by the various parts of the OS.

I think this illustrates that an OS is not just a set of calls but also a set of conventions about resource use: zero page allocations and wider RAM allocations must be part of that.

It is so finite! I always feel pressured dealing with the zpage, especially in my own (usually trivial) bootloaders and systems. I wind up changing things around, and fidgetting to the point of deadlocking myself, trying to come up with the 'ultimate' way to use and share the zero page.

Even a big, 64K direct page would not resolve my tension -- more space but it still must be managed, and possibly relocated. A fully-movable DP of the 6809 seems nice, but I have yet to try to use it.

I still like it more than just giving up on the timing and using a cache, but it is a subject of concern.

Yes ... I like the common Forth layout of two to four vectors and a small transient workspace ... the fact that if there is a lot of space available in the zero page, there is a strong incentive to allocate a lot of it to whichever X indexed stack you have helps keep uses of the zero page primarily to transient "pseudo-registers" with most larger data storage out in main RAM.

I tried to use it, but there is the price for changing it, so I had to do at least 6 DP access to be equal (7 for it to be profit), so I did not used it in interrupts after all.

Yes, it seems rather to have an area of whichever direct page is in use reserved for interrupts, and have different two or more direct pages for different foreground tasks, so that interrupts don't have to adjust the D register, they can just take their direct page workspace for granted.