6502.org

As Ed suggested in the recent DOS/65 thread, here's an attempt to start a new thread and hopefully get some traction for a more modern OS or filesystem that is based on the 65C02. Note that I purposely specify the CMOS version only.

Perhaps a simple recap to start. The 8080 and Z80 were very popular in their day and CP/M became the de facto OS for them. It is somewhat odd to realize that with the overwhelming popularity of the 6502 that nothing equivalent ever really came along that became a de facto OS for it. Lots of different ones of course, but nothing that bridged across platforms like CP/M.

Also, I tend to agree that implementing an OS form the 70's/80's is probably not the goal here, much less having filesystem compatibility for things like CP/M. I'm also specifically stating the 65C02 as an 8-bit implementation, not the 65C816 (at least not for now).

For the past two years, I've been sporadically working on a 16-bit IDE interface for my own C02 Pocket SBC. This is a separate I/O adapter which has a 44-pin (2.5-inch) IDE port and a realtime clock. I'm about ready to pull the trigger on getting the PCBs made, but as of yet to have written any code, except for adding I/O port definitions to my existing BIOS. Having giving this lots of thought, I'm basically taking the path of using the older (16-bit) FAT filesystem for disk layout. The reasons are fairly simple:

1- It's well documented and shouldn't be overly complex to implement.
2- Every current OS supports the file format for compatibility.
3- Based on above, you can always use another OS to format the media and check (and hopefully) repair the filesystem.

I also tend to like the Commodore concept of using a separate CPU system to implement the filesystem and have a simple, albeit faster, connection to a main SBC setup. It offloads a lot of work and allows a more complex subsystem to be implemented without worrying too much about the resources (ROM/RAM, CPU cycles) required. I also opted to use the older IDE interface as it too is well documented and is easily interfaced to a 65xx system.

Needless to say, this could turn out to be a very long project for me personally, given my retirement status and the fact that I'm now more busy than I ever imagined! So... post away... the good, the bad and even the ugly!

That makes sense, since the only NMOS ones anyone is actually stuck with are ones like C64, Apple II, etc. that already have file systems, and new builds have no reason to use NMOS.

viewtopic.php?f=9&t=5906 is working with a FAT32 filesystem in Tali Forth on an 65c02.

Hmm, interesting project! But if bridging across platforms is your goal, then how much sense does the " 'C02 only " stipulation make?

Garth has noted that C64, Apple II, etc. already have file systems, but owners of those machines still could be a target audience, it seems to me -- because it bridges across platforms. The common medium could be an IDE adapter (to Compact Flash or an actual IDE HDD), or floppies, or a wired link between machines.

Whether those C64 and Apple users are a big slice of the pie or a small one, bridging to those platforms is still pretty significant, IMO. (Not that I have any skin in the game -- I'm just a spectator. And for the record I am a big fan of the 'C02 enhancements for my own use.)

But if the proposition is, "We need to exclude those folks because the 'C02 enhancements are more important," then you might wanna reconsider. And CP/M may be an illustrative example. I'm not clear on the history of that. But I'd be surprised if CP/M achieved its popularity by ditching the 8080 in favor of Z80 enhancements.

Just my two cents!

-- Jeff

Well, the bridging comment was strictly a historical recap. I'm not looking to implement anything on older (vintage) 6502 machines.

I also noted that a standalone filesystem, e.g., intelligent storage subsystem, would be preferred. In this case, you could write a command processor for any system and add the appropriate hardware interface to the intelligent storage subsystem.

Also... re: the Forth FAT implementation... very interesting indeed, but I'm leaning towards a native assembler based filesystem. I will read up on that thread more however and thanks for pointing it out... I generally don't look in the Forth section.

There's still the option to implement something other than FAT, but there's trade-offs for going a different route, which could be a separate thread unto itself.

I'm using the Seagate ATA Interface Reference Manual (36111-001 Rev. C, dated 21st May 1993) for the hardware and BIOS design.
My current plan is to use 24-bit Logical Block Addressing. This will limit BIOS access to 8GB (16-million 512-byte blocks), but I think this should be sufficient for an initial release. With an 8GB limit, FAT32 will pretty much be a requirement to keep the cluster size down, as the media capacity goes up beyond 512MB.

I also have a decent collection of older 2.5-inch (Travelstar) IDE drives which have sizes below 8GB (5120MB, 4320MB, 3250MB, 2210MB and smaller!) which are mostly in near new condition. I also have some Apacer ATA modules (512MB) which plug directly into a 2.5-inch connector (and the PCB supports this module). I'm also considering a PCB layout that will have a Compact Flash Type-II socket instead of the 44-pin IDE connector. This would permit use of the older IBM Microdrive in addition to Compact Flash cards.

The CP/M filesystem is extremely primitive—more so than the filesystem implemented by Commodore in their floppy disks—and is easily corrupted (I have experience with this from many years ago). If at some point it is desired to be able to read and write CP/M files that capability can be addressed in a filesystem driver that can be attached to the kernel, same as is done in modern systems.
However, a 65C02 implementation should be able to work with the '816 running in either mode as long as the RMB/SMB and BBR/BBS instructions are not used—their opcodes on the '816 are used for other purposes. Once a 65C02 kernel is stable a native mode '816 version can be developed.
FAT would not be my choice as a primary filesystem. It too is easily corrupted (Peter Norton made his millions because of that "feature," something that was not lost on Microsoft when they developed Windows NT 25 years ago—the NTFS was the result), and FAT12 and FAT16 are significantly limited in maximum file and filesystem size. You'd really need a FAT32 implementation to support modern mass storage.

Also, like CP/M's filesystem, FAT doesn't distinguish file types except by filename extension. File type should be an immutable structural feature, not something that is interpreted from an arbitrarily-assigned name. What's to stop me from renaming abcdefgh.123 into abcdefgh.exe or abcdefgh.com and thus potentially fooling the operating system into thinking it's an executable binary?
Commodore's approach came about because they had a chip foundry at their disposal and they would be using fewer host resources than if they had decided to run the DOS in the computer, as was done with CP/M and is done with all modern systems. Also, for reasons that had to do with marketing, the PET and CBM machines (as well as the B-128) were equipped with an IEEE-488 interface to attach peripherals, which meant said peripherals had to be intelligent. This concept was carried over to the VIC-20, C-64 and C-128 (and others) mostly so kernel code could be reused and older disk designs could be adapted to newer models—the Commodore serial bus is basically IEEE-488 minus the 8-bit parallel interface (and it's greater speed).

However, working with Commodore's DOS is akin to trying to drive a car through a slalom while sitting in the back seat, a concept with which I became all too familiar back when I did professional development on the C-128 and its horrid (and slow) floppy disks. It was for this reason, and others, that the Xetec Lt. Kernal hard disk subsystem moved the DOS back into host processing space (specifically, into RAM inside the SCSI host adapter, which appeared at $8000 when disk communication was in process). In the process, the Lt. Kernal DOS ended up being far more powerful than anything Commodore developed, despite it being confined to 8KB of "shadow" RAM and despite having to bit-bang the SCSI bus.
IDE is good and although it disappeared from PC hardware over a dozen years ago, disks and CD drives are still available.

When the time came for me to add some mass storage to my POC unit I went with SCSI. The choice came about because I have a lot of experience with SCSI (dating back to before it was an ANSI standard) and I could get my hands on intelligent SCSI controller ASICs (specifically the AMD/NCR 53CF94, which is readily interfaced to a 65C02 or 65C816). Also, I have ready access to a lot of SCSI hardware scavenged out of old servers that have been rehabbed in my shop. SCSI is heavily documented (more so than IDE) and has the additional advantage of greater device intelligence and higher bus speeds, although the latter is of little importance in a 65C02 system.

What would be nice would be to figure out how to interface SATA disks to a 65xx system. SATA disks are cheap these days, reliable and available almost anywhere. Unfortunately, I know of no SATA ASICs that are available for the purpose—everything seems to be embedded in motherboard chipsets and not in discrete devices. In theory, bit-banging SATA should be possible, if slow. However, the SATA standard appears to be impenetrable unless one wants to spend a lot of money to purchase documentation.

However, I must hasten to add that the type of mass storage in itself has no bearing on the type of filesystem used. The two are completely separate entities that happen to be synergistic. In modern operating systems, mass storage of any kind is interfaced to the kernel with a suitable device driver—the kernel itself doesn't include the necessary software (also true about the filesystem—that too is implemented in a device driver module). By keeping the two as separate entities you pave the way for the use of different types filesystems in conjunction with different types of storage devices by developing appropriate drivers and devising a convention for passing commands from the kernel proper to the device driver and passing the results from the device driver back to the kernel. Modularity is the key.
That's the beauty of a hobby: there's usually no deadline—unless your death is imminent.
I think his meaning of "bridging across platforms" is that of developing a common OS that works with homebrew machines, not the Apples and Commodores of the world. I suppose one could reach back to the NMOS hardware by carefully choosing the instructions to be used. However, it would be a shame to not take advantage of the greater power of the 65C02 (and '816) just to maintain some yet-to-be-specified compatibility with the NMOS universe.
Interesting you mention that, as I earlier mentioned the Xetec Lt. Kernal (LK). That was a (very complex) adaptation of SASI disks to the C-64 and later the C-128. As one of the few people who had access to the technical details of the adaptation, I came to appreciate just how tightly integrated everything is in those machines. Roy Southwick and Lloyd Sponenburgh had something like three man-years invested in developing the LK, with about seventy percent of it in working around the rigid hardware architecture of the system. No Commodore 8-bit machine was ever intended to have a DOS running within, and the hoop-jumping it took to get there with the LK was mind-boggling (in fact, the "Lt. Kernal" monicker was a treacherous pun on the enormity of what was accomplished in getting the system to work).

While I would never discourage anyone from trying to repeat what Roy and Lloyd accomplished 35 years ago (it would be somewhat simpler with modern programmable logic), I'd say such an effort would be of limited value. If that sort of arrangement for a C-64 or C-128 were truly desirable the Rear Admiral subsystem, which was a second generation version of the LK (I have one in storage, along with my C-128D), would have been a resounding success.

The Rear Admiral was a dismal failure.

Something of a similar concept to the LK might be simpler with an Apple ][c (and possibly a ][e) due to a better machine architecture. In my opinion, if this was what Apple 8-bit users wanted it would have already been hatched.

I think the initial approach of targeting 65C02 systems makes sense, with a caveat. As we've seen here in different projects, memory maps can be idiosyncratic. That will pose a problem with portability. Going back to CP/M for a minute, CP/M placed certain requirements on the machine architecture, as contiguous RAM had to be available for the CCM, TEA, etc., and couldn't be interrupted by ROM. Unlike the 65xx family, the 8080 and Z80 have a separate I/O address space and a set of machine instructions to access it—this baggage continues to be carried in the x86 MPUs. This is not the case with the 6502, which sees I/O as ordinary memory. That gives rise to the specter of I/O breaking up the memory map in an odd way.

There would have to be some basic requirements about machine architecture if any kind of OS portability is to be achieved. I think that will be a significant stumbling block in trying to bridge the chasm between homebrew systems.

In my opinion, anything that will involve raw disk access with a 65C02/65C816 should be in the tightest assembly language possible. In fact, if you are going to do a FAT filesystem, you should go with FAT32, using 32-bit logical block addresses. Aside from gaining a larger maximum file size, 32 bit arithmetic is only slightly more expensive to implement in terms of processing time. Although your current target is the 65C02, eventually you or someone else will want to produce a native mode '816 version. 24-bit processing on the '816 is awkward and slower than 32 bit processing. Why saddle your code with that?
Have you read this topic? Also, to reiterate, the filesystem should be independent of the kernel so the door is open to implementing other filesystem types.
If the BIOS is in ROM you will have locked in the design to ATA devices unless there is a way to map out the BIOS or hook into it at boot time to work with non-ATA mass storage. If that sort of locking exists anyone with a machine that doesn't support ATA hardware will not be able to use your software.
See my comment above about use of 24-bit LBAs.

I suspect the key question should be: What constitutes a "modern" OS on a 65C02?

Usually when one describes a "modern" OS, they mean one with robust memory protection and pre-emptive multitasking, features which tend to require hardware support not commonly found in a 'C02 machine. At the very least, you'll want a way to map in individual stack and zero pages for each task. This is clearly easier to manage on the '816, on which you can also trivially allocate dedicated 64K banks for a task to use.

If you forego those particular features, the next step down would appear to be reinventing Acorn MOS.

For a discussion about what an OS is for and what it might do and how it might be built, I think there's much to say! One would do well to survey what has been done before, and why certain decisions and tradeoffs were made.

But I'm not sure if this is that discussion thread - it feels like it might be a thread about a particular project to make a particular OS. And in some way to do 'better' than CP/M.

Which is more or less what I did ... Not intentionally, and while I wanted more, I'm happy - for now.

If you want the boring details, read on...

Cheers,

-Gordon


A bit of a ramble, but the story so-far...

In 2018 Ruby was a bit of a personal project to celebrate my 40th anniversary of "knowing" the 6502... I wanted a sort of modern-retro system, so components I can buy today but with the ideas of "back then". I cheated and used a GAL (or 2 in the '816 version), but we did have complex chips back then - mask programmable ULAs and early PALs, so I don't feel too bad about that. Video was the issue and I decided to go for a separate video processor (like the TI99/4a) in the form of an ATmega1284p. That quickly turned into a very general purpose "host processor" which booted the 65C02/816 and did serial too. (It's just logic, right? Video turned out to be good, but slow and needed a composite video monitor or old CRT, so it was dropped after a few iterations - it did work well though.

And so the software - my first 6502 experience was on an Apple II, so a wozmon look-a-like was written - I started from scratch - I wasn't really intending to make it compatible with the Apple II monitor, but it did all I needed it to do and I ported EhBASIC and Applesoft to it. My monitor (gMon) isn't an OS, but it did for a while.

So my Apple II stuff started in '78 but in 1981 the BBC Micro was announced with a far superior and faster BASIC, graphics, sound and much more going for it than the Apple II. It was also 1/6 the price, so I bought one, did lots with it, used them at the uni I was at, played too much Elite and the Apple II was somewhat forgotten...

And so when poking about with Ruby one day I idly asked myself the question: How hard would it be to get BBC Basic running...

It was actually not that hard, (given that all I had was a ROM image), however to make it do anything more than the simplest of simplest things required support from the Acorn Machine OS - MOS and it's plethora of system calls - which, thankfully are very well defined and very well documented. The entry points were fixed over all iterations of the Beeb - Micro/Master/Electron, etc. so ROMs developed for one would work on others as long as they used the OS to do the hard work.

So I more or less scrapped my machine code monitor (my days of hand poking memory, dumping, disassembling, etc. were over) and I wrote a MOS compatible OS for Ruby complete with a nice command-line interface, editing and history. It's currently about 9KB long.

Today it's a command-line driven thing, (just like CP/M, DOS, etc.) it has graphics (and sound,etc. when I get round to it) layer for standard Acorn ROMs to use (So I can draw triangles from BBC BASIC) it also has a filing system. I could support a TSR type of application (Terminate, Stay Resident) called on a timer interrupt, or hooking into an unused interrupt or other hardware interface in exactly the same way you might do it on a BBC Micro. (Acorn MOS has 'vectors' for various functions in a similar way that the Apple Monitor has hooks for IO, but almost every single function in the MOS is vectored, so it's possible for a user program to take-over any function it wants to).

Ruby 6502 has no paged memory aka. "Sideways ROM" in the Beeb - just one 16KB block dedicated to applications ($8000:$BFFF). The OS starts at $C000. No memory protection, no multi tasking. I re-ported EhBASIC to it to use the new RubyOS interface and Applesoft (not complete yet - zero page clashes) and created a CC65 target for it too.

And then there was a filing system:

It does have a filing system - however I cheated there. I have written filing systems in the past for various esoteric systems in conjunction with various jobs I've had, however for this I wanted to still have a nod back to the old Apple II. (and I really did not like the Acorn way of doing it using dot as a directory separator) I did look at the CP/M way, but it was just lacking in many ways and really did feel "old".

Apple DOS had a good and well defined interface, but no directories. Apple ProDOS did have directories and a nice efficient storage mechanism, so I based my FS on that with an extended directory entry system that better suited the file attributes the BBC Micro needed. The FS runs on the ATmega host processor and is written in C. It manages a variable block sizes (64 bytes for the ATmegas 4KB of Flash and a 4KB RAMdisk, to 512 bytes for the SD card)

Could I move the FS code to the 6502 side? Yes, but on an Apple II ProDOS is some 10KB long and I'm not sure I want to write that from scratch, or even try to port it.

RuFS has a Posix-y style interface on the ATmega and this is extended through to the 6502, so while I've not yet written any, I think it would be relatively easy to get cc65 using it, however for the Beeb compatibility side, there is a translation layer that allows standard BBC Basic (etc.) programs which use the Acorn MOS interface to run unchanged. (although if they assume things about the Acorn filing systems like :drive.$.path.to.extension.file then they might be in for a surprise)

It also has the same partition and file size limitations of Apple ProDOS - namely 32MB partition size and 16MB file size. I don't really see this as an issue for now, and while currently I only have 4 primary MBR partitions on the SD card, I have plans to move to extended partitions - just to give the ability to use more space. However, the single 8GB SD card I'm using can probably hold all the Acorn (or Apple) software that was ever written ...

Acorn progressed their MOS after they developed the ARM processor into "Arthur" then RISC-OS. This featured a cooperative multi-tasking system which worked very well. RISC-OS is still in-use today, although I've not looked at it myself for a couple of decades now.

Where am I going to take Ruby? Well, I like the simple command line interface I have - go to multi-tasking? It can be done without an MMU - Linux does it with µC Linux and MP/M or Concurrent CP/M did it. Could I use the 816 system and give each task its own 64K Bank? Maybe. Relocatable code? That's already working in GekOS and I think it would not be too hard to write a run-time linker/relocater to take as65/cc65 object files, but ...

Do I want to? Don't know. What I do want is a stand alone system capable of compiling a high level language and once I have that, then who knows. We had various compilers that ran natively on 6502 hardware back then, so why not now.

Also... something that always nags away at the back of my mind... In 1980 I discovered Unix. It was Unix v6 running on a PDP11/40 with 256KB of core (128KW). That processor ran at approximately 4Mhz although core memory access was half that. The PDP11 is a 16-bit machine. The 65816 is a 16-bit machine, although with rubbish registers compared to the '11 and a segmented address space, however that PDP11 supported 6 terminals/users, a console and line printer. Shouldn't I at least be able to do something similar on my '816 that runs at 16Mhz? I think it could happen - using separate 64K banks for each process, but who has the time and/or energy to make it happen? I wish I had, but sadly life gets in the way...

So for now, I don't think I'm bringing anything new to the table - it's maybe an update or refresh of what we had in the early 80's really - at least what we had this UK side of the pond. The BBC Micro never really made it to the US so what effectively dominated the scene were "games machines" or Business machines. Apple discounted their computers for classroom use in the US (AIUI), but that never happened here to my knowledge. I was lucky to get hands-on an Apple II in my school because it was a brand new school (and sort of a new concept in 'community schools'), so money was being thrown at it in the first few years. The Beeb was aimed at education and schools bought them by the dozen - a few home users, but not until games caught up - however by then, we had better consoles, Vic20 not to mention the Sinclair computers which were half the price...

Ah well.
=-=

As expected, a fair amount of responses, which is all good, and of course, welcome.

However, I now must try and frame what my (personal) intent is here. Perhaps stating a "more modern OS" was a bit misleading. I have no intention to write that level of code (memory management/protection, multi-user, multi-tasking, etc.) on a 65C02 with it's 64KB address space. Not to mention that I simply don't have that much time left on this planet (not sure about the next one).

I'm thinking a simpler, single tasking environment with a good (albeit simple) filesystem, which will support easily obtainable media. I've chosen IDE as there's still a ton of it out there which is inexpensive to acquire and most of us out here probably already have a fair amount of it gathering dust. Note: I also have a collection of SCSI drives. Compact Flash can also use an IDE interface, so using this makes sense (to me at least).

Implementing BIOS in ROM is the goal, but one should be able to use different hardware and implement the same BIOS functions to maintain compatibility with the filesystem code. Again, this isn't a "boil the ocean" approach, but mainly to get a working filesystem on the 65C02 that supports media that can be attached to any modern machine for common utilities (format, chkdsk, mkfs, fsck, etc.) so I don't have to have those natively on the 65C02 (at least not initially).

My little 65C02 project has grown organically... and this is my next step, so to speak. The first I/O adapter for the C02 Pocket SBC, which has a DS1511Y realtime clock and a 16-bit IDE interface. A simple BIOS will be written first, then on to a, hopefully simple, filesystem to support it. I do want thoughts and ideas of course... as it's always a better plan to get feedback before jumping off the cliff.

Hi BDD,

I think we're in more agreement here than is obvious. I'm quite aware of using tape media... going back over 40 years, I worked on many high end computer tape drives... the same with early diskette drives, hard drives, removable hard drives... even drives with fixed heads for speed (as the only data access delay was latency). And I was more than aware of the operating systems and filesystems that used them, such was my career for almost 4 decades. BTW - do you remember the old IBM "noddle snatcher" tape storage??

My fairly simple view here is using a block storage device which has random access, meaning a diskette drive, hard disk drive or solid state drive with an industry standard interface, e.g., (Shugart SA-whatever for diskettes) or ST-506, ESDI, SCSI, IDE, SATA, etc. It's basically a random access block device and in all cases, it either defaults to a 512-byte block size or can be formatted as such. Looking at any form of tape or sequential data storage is not of interest.

The simple part gets down to the hardware... a simple (hardware) design for interfacing to a 65C02, which tends to mean no DMA controller. Also, by defaulting to a logical block addressing scheme, you eliminate the CHS (cylinder head sector) addressing which is more specific to diskette drives and early hard drives. The ability for the filesystem to query a block device via a single boot block to get details on the LBA count and details of the filesystem layout is key.

For my 65C02 system, the BIOS and Filesystem code can (and will) be in ROM... as it's dirt simple and quick to update. I can remove the EEPROM and reprogram it in under a minute, or I can use a simple utility to update the EEPROM insitu without any difficulty, code which I've had working for years now. One can always minimize ROM and maximize RAM to POST and load code to provide the OS, Filesystem and I/O access (BIOS), but for now, I'll be using my C02 Pocket SBC, which has 32KB of RAM and 32KB of EEPROM (less 160 bytes for I/O space).

The filesystem itself should be reliable and stable. I'm fine NOT going with FAT, as it can be problematic. I've also looked at the Minix filesystem as a possible option, as I do prefer to keep it simple. After all, there's no plans for this system to be used in a mission critical application or be on the Space Shuttle. I would prefer to keep the code size within 16KB, but no idea if that will be possible, as the choice of filesystem layout (FAT, EXT2, Minix, etc.) and the specific functions, will tend to govern how much code is required to implement.

The real down side is, once I finally lock in on the filesystem layout, coding it up will take a fair amount of time... and my other half sees other uses for my free time, like she does!

It ought to be possible. bear in-mind that ProDOS (which isn't a million miles from an early unix filing system in layout) is about 10KB and (from memory) 2K of that is the low-level RWTS hardware layer. Accessing a parallel bus IDE or similar ought to take less code that the highly timing critical Apple code needs. Go for it!

Cheers,

-Gordon

Ok, that does open up my ideas for a filesystem. I started working out bits of this last year, but your post here inspired me finally to sit down and document it some detail. You can find the latest version of the document here on the web; I've also attached the current version (converted from Unix to CR-LF format and a .txt extension added) to this post.

I've separated the block device interface from the filesystem implementation for obvious reasons. I'd anticipate even using multiple block device interfaces to, say, an SD card; one interface might use blocks on the card directly and another know enough about FAT to be able to read/write a file representing a disk image. (This is much easier than actually implementing FAT because you'd pre-allocate the entire image file using external tools, so the block driver need only be able to find the blocks in the file and read/write those directly, never writing FAT metadata. You'd need an external tool to put things into the images and copy them out, but that ought be fairly easy to write.) And of course it should support real 1970s and 1980s devices without any major problems.

If implemented correctly, this filesystem should be quite resilient; I've sacrificed some random I/O performance in favour of this. (Though on modern random-access memory devices, the sacrifice will be tiny.)

Comments welcome!