Tor wrote:
Wouldn't the improvements to the filesystem remove the possibility to read or write a disk (or image) in Linux? Having the ability could be useful. 14-char filenames are very painful when you operate on large filesystems (and yours will be much larger than what the original S51K used to handle), so that improvement (and the others) are very understandable of course, but it seems you may also lose something in the process too (although I imagine at least the filename size increase is something that could easily be incorporated into a patched Linux filesystem variant).
-Tor
-Tor
Your question is a good one and is about something I have contemplated in my design (BTW, your question also shows that you read most, if not all, of my diatribe
). At this time, I'm not particularly concerned with being able to interface to a raw Linux disk or image. The point of this exercise is to develop a working environment, not to wire in interoperability with another operating system.As an aside, my modified S51K filesystem will not be using the same magic number as the real S51K, so the door is always open to being able to read the genuine article at any time, if I choose to do so. Support for multiple filesystems would require that the data describing the filesystem geometry and access sequencing be separated from the code that manipulates the filesystem. Right now, it'll be more convenient to not do this until I have a working system. However, I have sketched out the methods by which such a thing could be accomplished.
A "feature" of my modified S51K filesystem is that it will not be using linked lists to manage data block and inode allocation/deallocation, as is done in the genuine article. Linked lists were a way to deal with the relatively slow disk access and compute-bound performance of the PDP hardware that Thompson used for much of his seminal development work. Again, he demonstrated some very clear thinking in doing it that way, and was able to achieve a good compromise between efficient disk space utilization and real-time performance.
However, contemporary hardware's compute-bound performance is such that an allocation bitmap is more efficient and less demanding of MPU time to search for and locate an unallocated block or inode (this applies to the 65C816, even at the relatively modest 10 MHz Ø2 clock rate I'm using in POC V1). Using 16 bit reads, writes and shifts to scan and manipulate the bitmap control words will help in this regard. For example, a 16 bit LDA <addr> comes with a one clock cycle penalty, due to it actually being back-to-back eight bit accesses, but is about 60 percent faster than LDA <addr> followed by LDA <addr+1> to read a word. So I anticipate substantially less compute-bound activity to manipulate the bitmap than I would see with manipulating linked lists.
Further to this performance angle is the fact that I have arranged the filesystem in a way that guarantees that bitmap structures will stored in contiguous disk blocks. Although it can't be done in the POC V1 unit due to its modest 52 KB of RAM, I will be able to read the entire inode allocation map into core in a single disk access in the POC V2 unit, since there will be enough RAM to support a large number of block buffers. The modified S51K layout will be configured with 64K of inodes. The matching allocation bitmap (IAM) will span eight logical blocks, or 16 physical blocks, which is 8 KB en toto. With POC V2's 1 MB of RAM, I can keep the entire IAM in core for a protracted period, which means that a disk access to retrieve the IAM doesn't have to occur every time a new file is created or an old one is deleted. A sync daemon would periodically write out the IAM when it becomes "dirty" so filesystem consistency is maintained.
The data block allocation bitmap (BAM) will be too big to be loaded en masse into core. However, I also have an algorithm worked out that will assist the kernel in figuring out which BAM block points to an unallocated data block, so only the relevant bitmap block is fetched when a data block is to be allocated. Once that block is ensconced in a buffer it can stay there as long as other buffers are available for use. The net result of this is that as a file is being written and data blocks are being allocated, the bitmap image is being manipulated with minimal disk accesses. This was something that wasn't particularly practical on the old PDP machines due to small core size.
In considering the idea of support for other filesystems, something worth noting is that the ext... series of Linux filesystems are effectively modifications and extensions of the basic S51K structure, with elements drawn from the Berkeley filesystem (BFS). This is also true of the AFS and EAFS filesystems that were widely supported in the SCO UNIX 3.2... series. So support for them could be provided as well. Again, it's primarily a case of separating the data from the logic, something that I'll eventually address when I have built hardware that can support pre-emptive multitasking.
------------------------
Fixed a typo that resulted in "core" becoming "code."
)
), and other than adding the SCSI commands and S-record loader, as well as extended addressing support, I didn't see any need for any functional improvement. The monitor's code is not a copy, however, as the '816 is sufficiently advanced over the 6502 to warrant starting with a blank canvas.
