OSes besides the “official” ones

No need to go to that extreme. I did mention those issues a couple of posts ago. You kind of got hung up on how the number of forks isn’t really limited to 127 and skipped over everything else I mentioned.


That is it exactly, yes.


‘Outbankable’ does indeed mean that. It’s like ‘relocatable’ on steroids… in addition to being moveable within its current bank, it can also be bumped to a different bank or to a different (slower to be accessed) type of memory entirely, say to REU space or a disk swapfile.

‘Relocatable’ sounds like a lot of effort to go to, but is absolutely vital if you want to avoid getting wedged due to memory fragmentation. After a program has been running for a while, in the pathological case you might have 48 KiB free but it’s all broken up into a bajillion little chunks due to some memory still being allocated in between. If most of that still-allocated memory is relocatable, a call to MemGrab would cause all of the still-allocated chunks to be moved to one contiguous region in RAM, coalescing most or all of that free 48KiB into one big, useful lump. The classic Mac OS worked like that and it worked quite well. Rather than some hairy callback scheme like you describe, all you need to do is reference memory via what are called handles instead of via simple pointers. A handle is a pointer to another pointer… the pointed-to pointer, called a ‘Master Pointer’, is locked (which means it is neither relocatable nor purgeable), and whenever the actual blob of data gets relocated, the master pointer is updated appropriately. That way you can have as many handles in your data as you want, and they all point to the fixed-position master pointer which is kept current by the memory manager.

‘Purgeable’ simply means that the data is known in advance to not be used very often and to not be writeable, so if the system gets a bit short of space it can just erase the block in question and set a flag in the master pointer. Then, if the datum is in fact referenced again, the resource management system simply reloads it from wherever it originated (usually a data file on disk, but it could just as easily be in battery-backed expansion RAM or the like). In the old Mac OS purgeability was a concept from the resource manager and had no particular bearing on the memory manager, but with how slow a 2MHz machine can feel, the two might need to be a little more closely intertwined. That said, purgeability and relocatability are largely orthogonal.

My thoughts on enforcement of ‘writeable’ and ‘executable’ are pretty straightforward. Here are the relevant passages from my notes:

Security concerns: There is no hardware-level protection mechanism of any sort. Erroneous or malicious code _will_ compromise the system, so reliable intrusion detection is the only recourse. Due to the nature of IEC networking, all nodes on the local segment are necessarily of equal trustworthiness and must be considered to have the same user (or mutually benevolent group thereof). That said, remote users are entirely possible via gateway units and the like; therefore, some consideration of operational security is necessary, beyond the obvious concern that random code off the Internet might do nasty things to the system, whether by accident or by design.

Partial solution: Periodic task that verifies system components by CRC (Cyclic Redundancy Check), one per time-slice, on a rota (always checks itself first; failure there is an automatic system panic). Include a system-wide hot key (chickenhead-restore?) that checks everything and reloads failed modules from disk. Maybe make it happen automatically on check failure? Eventually, at least. Don't want to get in the habit of ignoring serious bugs because things don't always stay corrupted.


I seem to have skipped over rather a lot of detail that was old knowledge to me but would not be such to most other people. My apologies.

The pointers that take up different numbers of bytes thing is based on the rather clever memory management model Craig Bruce came up with for his text editor, ZEd, which he later refined for his ACE OS. Basically, in an unexpanded C64, you might have a two-byte pointer, and that suffices for most needs. You could add a third byte to specify whether you want RAM or ROM, or perhaps something more exotic like GeoRAM or an REU. In a C128 you also might be referring to internal or external function ROM. Of course, we’re programming for a 128, not just a 64. Now that you’ve opened those possibilities, suddenly you need a fourth byte to indicate the bank within the C128, GeoRAM or REU. I took it one step further and added a fifth byte to specify which of the nodes on the local IEC segment holds the RAM in question. Imagine, if you will, a bank of three or four 128s and a CMD hard drive, acting as a cluster computer!

Basically, a Live pointer refers to an address within the active bank (the 64 KiB that the CPU sees right now). A Near pointer is similar but can refer to any bank in the current type of RAM (e.g., internal C128 bank or REU bank). A Far pointer can refer to other types of RAM as well, say if you want to refer to something in the REU from main RAM. Then, of course, an External pointer can identify memory in any node on the local network segment. All of these are useful in certain circumstances and not so useful (being either overkill or inadequate) in others.


Not really, no. ‘Locked’ is a short way of saying ‘neither relocatable nor purgeable.’ One thing an OS needs to keep track of is what memory is allocated and what is not. That depends what program you're looking at. Suppose I allocate a block of memory, and tell another program about it. Then I finish what I was doing and terminate myself. Suddenly the other program has a dangling pointer to the memory I told it about before I quit. Thus, MemShar. If I call that, the shared block is no longer unallocated when I stop executing.

There are practical concerns here too. If we implement basic sanity-checking such that a program can only write to its own ‘zone’ of memory, suddenly we can’t access shared memory blocks. Okay, we’ll just require that they be relocatable and sharing them causes them to be moved to a special region of RAM where we explicitly allow writes even though it’s not within a program’s own private memory space. Sanity checking slows things down a lot, so this one may not be a concern, but it’s still worth considering if the resource manager or something tries to implement it just on system calls.


Agreed about the stack relocation. It needs to be tried both ways before we can say which works better. I fully intend that VIC applications would use “fast borders” to achieve ≈1.3MHz operation, so it wouldn’t be quite so dire as all that, but I agree it would need to be looked at.


AFAIK the VDC does not have a built-in raster interrupt (demos do what they do by careful CIA timing), so this is a false concern. I only specifically mention the VIC-IIe raster interrupt because it is already halfway implemented by the Kernal, and not providing similar functionality would be regressive.

What you say about “head” and “tail” vectors is pretty much what I meant when talking about how an ISR would need to have its exit vector right after the beginning so it could be identified by software. Trust you to find a much simpler way to describe it… *grin*


It is not actually impossible on a ‘raw’ or abstracted medium. You would just make a directory with extension “.VLIR” and its contents would be the various VLIR forks, named with numbers so as to keep them straight. This is no different in concept from flat files with extensions “.SEQ” or “.PRG”.


VLIR 2 is exactly as you describe, like VLIR 1 but with a side-sector structure for each fork. I honestly didn’t think I’d done that poor a job of explaining it! There would be no need for a record size; once you worked out where in the fork you wanted to access, you’d just divide by 254 bytes per sector and use the side-sector structure to look up the sector in question. REL files only need a notion of ‘record size’ because they keep track of that position in the file based on a record number, a concept which we would not be making use of.


The concept of “resources” is largely orthogonal to the concept of a VLIR file, though having VLIR makes resources much easier to implement. A resource is a numbered and potentially named fragment of data, having a known format. In the classic Mac OS they were basically a small subsidiary filesystem stored in the “resource fork” of a file. The resource fork was divided into sections according to a resource’s “type”, which was a 32-bit quantity uniquely identifying the format of the data in question. The 32-bit resource type was usually specified as a 4-character MacRoman ASCII string for simplicity. For example, executable code was stored in resources of type ‘CODE’, pull-down menus were defined by resources of type ‘MENU’, and the program’s icons were stored in a set of six standardized icon resources (black and white, 16-colour and 256-colour, in 16x16-pixel and 32x32-pixel sizes). The black and white resources also included a mask that defined what parts of the icon were clickable with the mouse, so they didn’t have to be always full-sized squares.

Once you knew what type of resource you wanted, you would access the specific one you were after by knowing its number. Later the concept of named resources made life a little easier. There were system routines for finding, accessing, purging, isolating, and doing various other maintenance tasks on individual resources. Something akin to this system would be of enormous utility in a new OS, though there are lessons to be learned from what did and didn’t work as well as hoped in the old Mac OS implementation.