In the past, this post would have been wildly off topic. But with both operating systems making moves to colonize the 6502 world, maybe it is time...

As I worked on implementing FLEX on the 6502, I compiled this list of significant contrasts with CP/M-80 version 2.2, its primary competition at the time. Note that I am a user and fan of both.

This is not a comparison of the characteristics of 80xx and 68xx processors unless they directly impact the design of the respective operating system.


Ways in which CP/M is better:

* More memory is generally available for user programs. The 808x and Z80 processors have special input and output instructions which meant that precious parts of the limited 64K address space did not have to be reserved for interfacing peripheral devices. CP/M was designed to reside in the uppermost end of the address space and it can be moved to adapt to the memory size of individual systems in a manner transparent to application programs. The command processor (CCP) was intended to be overwritten by user programs if the space it occupied was needed; it is automagically reloaded as part of a "warm boot" on program terminaton. The FLEX memory map usually contains "wasted" space because of the location of I/O devices; the system image is at a fixed address and cannot be moved to provide more usable contiguous RAM.

* Commonly used commands such as DIR and TYPE are built into the command processor so disk access is not required to use them. FLEX requires they reside as executable files on a mounted disk, however, this fact makes renaming or replacing FLEX commands not only possible, but easy.

* The "current drive" concept is a very convenient way to designate a "working drive." FLEX users have to use a utility program to set and view the designation of the working drive.

* CP/M was more popular. The primary benefits are greater software availability and better coverage in published works.

* Better console interface for programming. FLEX offers no standard way to determine whether a character is available or to read that character without echo.

* CP/M is faster writing to disk. FLEX uses links within sectors to manage space allocation. Writing a FLEX sector requires reading it first to get the linkage information.

* CP/M is faster processing files. CP/M deals in 128-byte records; the default FLEX interface is a byte at a time.

* CP/M can support up to sixteen disk drives; this is an advantage today using emulation as the only cost of additional drives are small incremental amounts of memory to manage them. Standard FLEX only handles four drives.

* CP/M supports larger physical sector sizes while FLEX is stuck at 256 bytes. Larger physical sectors equals higher storage capacity for the same disk due to less overhead from sector headers and gaps. Sector blocking and deblocking does add complexity but often results in faster disk throughput.

* A CP/M File Control Block (FCB) is only 33 bytes long (36 for random files) while a FLEX FCB is 320 bytes. CP/M files share one "DMA" buffer for data transfer while each FLEX FCB contains its own sector buffer.

* The CP/M system call interface is more "modern" with a function code in a register. The FLEX API is a jump table to subroutines and a bunch of global system variables. Expanding the capabilities of FLEX quickly runs into available memory space limitations. To make matters worse, there is no way to determine which version of FLEX is running.

* CP/M SUBMIT and XSUB scripting is more powerful than the FLEX EXEC command.

* CP/M implementations may support the IOBYTE with limited support for redirecting character input and output.

* CP/M came with a debugger as standard equipment. The FLEX DEBUG package was an added cost option and it was painfully slow to use; it was actually a processor simulator with advanced capabilities similar to an in-circuit emulator.

* CP/M text files may contain hard Tab characters to conserve disk space. FLEX offsets that somewhat by implementing automatic compression of consecutive space characters in text files.

* Direct access files may contain unallocated space AKA sparse files. This feature may not have been used very much?

* All files may be accessed in direct mode; FLEX supports random access only for specially created files.

* CP/M-80 uses the .COM extension for executable files; CP/M-86 uses .CMD so users cannot accidently attempt to run programs for the "wrong" processor. FLEX uses the .CMD extension for both 6800 and 6809 systems; there is no easy way to distinguish between them.


Ways in which FLEX is better:

* FLEX recognizes an "end of line" character, more accurately described as a command separator, to allow typing more than one command on a line.

* The operating system did not reserve much disk space for itself. CP/M disks reserved several tracks for the operating system even when the disk is not intended to be bootable. Once loaded, FLEX does not require a bootable disk remain mounted.

* FLEX reserves a "system" FCB in memory for loading programs. If a program does not need to access more than one file at a time, it may choose to "reuse" this FCB instead of allocating its own.

* FLEX sets aside a separate region of memory to load and execute most system utility programs. This is an historical artifact from the days of very little memory which has benefit today: something like a text editor or BASIC interpreter can easily allow the user to execute most FLEX system commands without having to exit and reload.

* FLEX has provision to automatically display meaningful error messages instead of an error number.

* A "system drive" can be designated to hold commonly used programs. While not as nice as a search path, it was quite usable. The system and working drive can be set to "automatic" so that multiple drives are searched to find a file. This facility could have been made perfect if FLEX had used a "current drive" concept like CP/M to specify the working drive, plus adding a third "temporary drive" designation for scratch files.

* File space allocation granularity is a single sector. This was especially beneficial when storing a large number of small files on a low capacity disk.

* File space allocation is managed by the use of linked lists of sectors. While not an ideal approach, it does provide some significant benefits:

- Only one directory entry is used for a file. Large CP/M files may occupy more than one directory entry.

- FLEX has a slight advantage in that once a file is opened, the directory need not be accessed again to read the entire file sequentially.

- There is no limit on the number of files on a disk until it is full. The directory can be expanded as needed.

- Damage to the directory of a disk leaves open the possibility to recover files as the sector chains still exist. Programs have been written to find "orphaned" chains of sectors and convert them to files.

- The cost in terms of memory usage to manage a disk is constant. The allocation vector of a large CP/M disk can be unreasonably huge unless wastefully big block sizes are adopted.

- A hierarchical directory structure may be created using a third-party addition (now only for 6809 systems), though application programs may only access the "current directory" on each drive. Still, half of a solution is better than no solution or worse, the user number kludge CP/M provided. A major redesign of the BDOS space allocation scheme would be required to add subdirectories to CP/M, and a disk containing such subdirectories cannot be safely written on unmodified systems.

- FLEX is much more hard drive and emulator friendly. The third sector of track zero on each disk is the "System Information Record" containing information about the volume such as a name, number, the date on which it was formatted along with structural parameters such as the number of tracks on the disk, the number of sectors on a track as well as the start and end of the free sector chain and the number of free sectors. This is enough metadata for the system or a disk emulator to properly handle the volume. You just have to provide a way to properly format the volume. The absolute minimum size of a virtual FLEX volume is two tracks of five sectors per track; I have actually created such tiny "disks" to transfer files to someone else. They can "mount" it in their emulator and copy the data to their main disk.

* The I, O and P commands allow redirecting program input and output. Not as nice as UNIX or DOS, but again, a partial solution is better than none. The CP/M XSUB utility provides a very limited form of redirection only for input.

* FLEX optionally "paginates" output to the console, pausing after each screenful of text. While not as usable as a general "MORE" command, it is better than nothing.

* Compression of consecutive space characters in text files is built in to the system. Unfortunately, it uses the hard Tab character, precluding its use in files.

* System utilities carry a version number and a command (VERSION) displays it. Unfortunately, many (most?) third-party programs do not adhere to this standard, but at least there is a standard.

* Files are automatically treated as a stream of bytes. But that comes at a cost; each file control block (FCB) contains a sector buffer and disk access is generally slower because data is moved twice.

* Operating system support is provided to aid parsing a command line and converting numbers. CP/M will parse the first two file names into default FCBs, but that is it.

* FLEX was doing "autoexec" long before IBM decided to get into the personal computer business. The final step of system startup is to look for a file named "STARTUP.TXT" on the boot disk. If found, the first line is read and executed as if it was typed by the user. Multiple commands may be executed this way by the use of the command separator character. If more is needed, the EXEC command may be used to pass control to a file containing more commands. The CP/M CCP may be patched to execute a command at boot time, but it is a manual process requiring proficiency with utilities such SYSGEN and the system debugger.

* FLEX is actually a two-task operating system. The second task is used for background printing if an interrupt timer is available.


The motivation for creating the list: relatively easy ways to improve FLEX

* Implement a "MORE" command

* Expand to handle up to 10 disk drives (10 because drives are identified by number rather than letter)

* Implement a native debugger

* Add RAM disk to make frequently used commands "resident"

* Add "temporary drive" designation

* Add an optional "current drive" mode

* Add hierarchical directories

* Add support to store the time a file is written (there are two reserved bytes in directory entries)

* Add installable disk driver

* Add command history

* Add support for more than one free memory pool

Edit: fixed some typing errors, specified version 2.2 of CP/M-80, added FLEX friendliness with hard drives and emulation, STARTUP

Great summary! I know about CP/M but I know nothing of FLEX. I'm interested in both for 6502. I hope to hear more about porting FLEX & CP/M to 6502.
Bill

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for the opening comparison.

I also would have an interest in having a port of FLEX on the 6502.

Also, for this particular thread, perhaps including DOS/65 (from Rich Leary) would be beneficial, as it's basically a functional remake of CP/M on the 6502, with full source available.

- as for CCP, I think the memory footprint is around 2KB, which I guess isn't too bad. But having the luxury of overwriting it for user programs is fine. However, if SUBMIT is used to do batch execution (from a .SUB file), then one would likely need to ensure that the CCP doesn't get clobbered in the process.

BTW - how is that 40-year old steak?

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Parsing would extract the command name, search for it in a command table and going to disk if not found. The size of the command table is not going to make a big difference in execution time. The concern about size is if a bigger CCP caused an overflow onto an additional reserved boot track.


The command line buffer is 128 bytes on both. It may matter for CP/M because the buffer is reused by default for a sector buffer. As for FLEX, the system call to read a line reuses that buffer so a program needs to either save the state of the command line or provide its own line entry code if needed.


It is a direct effect of the sector linked list allocation system instead of a block allocation system. The byte vs record transfer model had nothing to do with it.

Thanks for the comments.

I am still working on it. As they say, the final 20% of the operating system code is taking 80% of the development time. It appears you have changed your mind about putting the system image in ROM? The utilities are only about half done. The editor is still missing several commands and there are some bugs to fix. The assembler cannot handle much of the 6502 instruction set yet.


Rich and David will have to speak for themselves about their work as I am not familiar with them. Also, DOS/65 is sometimes confused with DOS65, a fairly mature system with lots of languages and other software: http://retro.hansotten.nl/6502-sbc/dos65/


Protecting CCP is not an issue.

This is how SUBMIT works: Create a file named $$$.SUB containing the lines of the script file in reverse order, one line per 128-byte record. Warm boot to reload CCP. If it detects the presence of $$$.SUB, it reads the last record of the file, decrements the record count, then executes the line. Repeat until the file is exhausted.

That was me, yesterday. Stomach bugs bite.

I thought CP/M did have autoexec facilities. On reset, the BIOS loads the BDOS and CCP, looks for BOOT.COM and BOOT.SUB and if found passes that to the CCP on startup.

_________________
--
JGH - http://mdfs.net