DOS/65

An operating system for the 6502. Published here with permission by the author Richard Leary, 2021.
In the following text “I” is Richard Leary.

What you will find here:

Introduction
Latest sources and documentation V2 and V3
OSI version V2 2015
Version on z80.eu: C64
DOS/65 V3.03 65C02 version by Kevin Maier
Port DOS/65 to a new system
nhyodyne modular backplane system DOS/65 V2

License
“DOS/65 software and documentation are provided as shareware for non-profit, educational, or private use. Any other use is prohibited without approval of Richard A. Leary.”

The DOS/65 V3 ROM software and all other DOS/65 software are free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the license, or any later version.

Introduction

Of all the problems which plague the 6502 enthusiast, the lack of a low-cost, compatible operating system is one of the most critical. The operating system, the media, and the floppy disk hardware of the common 6502 systems (Commodore, Apple, OSI, Atari, and AIM/SYM/KIM) are not compatible and can not readily be interfaced to systems other than the original. This incompatibility has been the major factor which has prevented the 6502 machines from achieving the status that other systems have achieved.

The challenge then is to establish a standard which minimizes cost, allows easy use by different systems, and ultimately will help make the 6502 and its derivatives the universal processor it is capable of being.
What Richard has done is attack the software side of the problem in order to make any 6502 system a truly workable disk based system. In addition a degree of compatibility is now possible not only between 6502 systems but with large parts of the world of CP/M systems. The result of my efforts is a system of software which Richard has named DOS/65.

DOS/65 itself is a software system which has the same basic structure as the foremost 8080/Z80 software standard, CP/M, and is file compatible with CP/M Version 1.4 and later versions. Since the machine language software obviously can not be compatible between the 8080/Z80 and the 6502, the term “file compatible” simply means that a DOS/65 diskette could be inserted into a CP/M system or vice-versa and the files manipulated in every way except actual execution.

The system could not tell the difference between files created on the host versus those created on a CP/M system. For example a BASIC-E source program which had been created, edited, and used on a CP/M system could be used on a DOS/65 system using the BASIC-E/65 compiler and interpreter with at most only minor changes. Data files of all forms could be exchanged between systems without restriction

The reasons for selecting CP/M as the standard are simple. CP/M has many features including:

Nearly total hardware independence
Easy access to operating system primitives
Easy alteration to accommodate system unique characteristics
Large library of compatible software that in many cases can be ported to DOS/65
Simplicity

None of these claims are overwhelming in themselves, but taken as a whole they stand as a compelling reason to use CP/M as the format and structure standard for a 6502 operating system.

CP/M is a trademark of Caldera.

Version 3, upto 2020

DOS/65 V3 can run from a read-only memory (ROM). To prove the concept I’ve implemented the ROM version on two different platforms. The first is the WDC W65C02SXB and the second is Daryl Rictor’s SBC2. In both cases I built an auxiliary board using Andre Fachat’s VIA-based SPI interface design. Both platforms are up and running with a micro-SD card as the storage media. Each system has four 8 MB drives provided by the micro-SD card. The interfaces are implemented as four layer printed circuit boards from Express PCB. Because the connector configuration on the two platforms are slightly different each is a unique interface.
Changes associated with DOS/65 V3.0 are small in number, they significantly improve the utility of DOS/65 especially for those users having some sort of high capacity mass storage device attached to their system.
The key changes are:

PEM and CCM changes to implement a CP/M 2.2 compatible “USER” area concept for storage devices.
Addition of a COPY3 transient that is able to set source and destination USER areas for any file copy operation.
CCM changes to implement a CP/M compatible batch command processing capability.
Addition of the CP/M compatible SUBMIT transient command to initiate batch command processing by CCM.
Change to SYSGEN to allow either .KIM or .HEX input files for the BOOT and SIM modules used when building a new system.
Use of the IOSTAT defined but previously unused storage location as a means of exchanging USER and DRIVE data between CCM and SIM.

All software has used 6502 op-codes and addressing modes. No 65C02-only code has been used.

Downloads:
Documents DOS/65 V3
Sources DOS/65 V3

DOS/65 for OSI

From http://osiweb.org/osiforum/viewtopic.php
Files come form here: https://github.com/osiweb/DOS65/tree/master/DOS65_v2.1

I released (sold in those days) a version for 5.25 inch drives for OSI and an eight inch OSI version. Development of these was frozen in 1986 as there was not enough demand to continue OSI support. I did normally ship DOS/65 as a two disk start up where the first disk was used under OS65D. I did the ROM because for all practical purposes I never used OS65D. If I remember correctly the 5.25 inch version need 9 or 10 diskettes and the 5 inch version a lot less because of the increased diskette capacity.

The SIM (system interface module) code – that is what talks to the hardware – was straightforward and could easily be expanded to handle larger capacity drives. I strongly recommend that for 5.25 inch systems.

DOS/65 manages disk use by dealing with 128 byte logical records. However because of the characteristics of the OSI floppy disk controller the physical sectors are full tracks and a full track is what is read from or written to the diskette. The SIM code maps logical records from or into the full track buffer. A physical track for the standard 5.25 in drive is 2048 bytes. Every track on a DOS/65 5.25 inch diskette is 2048 bytes long.

Downloads:
Documents OSI DOS/65
Sources OSI DOS/65

Version of 2008 on z80.eu: C64

C64 port of DOS/65
“What I (Richard A. Leary) have done is attack the software side of the problem in order to make any 6502 system a truly workable disk based system. In addition a degree of compatibility is now possible not only between 6502 systems but with large parts of the world of CP/M systems. The result of my efforts is a system of software which I have named DOS/65.”
Richard’s implementation is initially made for S-100 based systems, but he began to port it to the C64 also (see below).
DOS/65 has a lot of CP/M look-alike commands for the command line and also some applications like BASIC-E included.
Of course some differences between CP/M-80 and DOS/65 exist – the lowest memory areas (e.g. the “zero page”) are not usable for the TPA, so the usable system memory area starts at a higher address (e.g. $0400).

Richard has prepared two .D64 images
DOS65-1C.D64 (Bootdisk with updated SIM C64S304.ASM)
DOS65A.D64 (Blank disk)

Load the bootdisk with: LOAD “DOS65”,8,1:RUN

Downloads:
Sources DOS/65 V2 2008
Documents DOS/65 V2 2008

DOS/65 V3.03 65C02 version by Kevin Maier

Kevin, a.k.a floobydust enhanced the DOS/65 V3 system to his 65C02 system.

See the topics on the retrobrew forum 6502.org and his github repository.

Port DOS/65 to new hardware

What makes CP/M and DOS/65 special is the separation between hardware and the operating system with a well defined interface. In CP/M terms this is the BIOS, the only part to implement for new hardware. In DOS/65 system this is the interface module (SIM). Various examples are in the sources archives.
This part of the “V3 ROM Supplement”, see the V3 section illustrates how this works in DOS/65.

The first steps in implementing the ROM version of DOS/65 on a new platform are:

First, determine functions to be provided by the OEM monitor or other software that can support the overall DOS/65 processing needs. For example in the case of the W65C02SXB the only functions that would make sense to use for DOS/65 are the character I/O functions, i.e., those that support console I/O. The W65C0SXB has no storage I/O capability built into it so there was nothing to exploit in designing the system.
Second determine what resources are essential to performing the functions previously assessed as required. Then either allocate existing resources or acquire additional resources. That is exactly what was done for the SPI/SD interface. It did not exist but there was a VIA and a VIA was what was used by Andre Fachat in his elegant SPI/SD interface.
Third, test the resources assigned to ensure that the intended functions are provided correctly. For this step a standalone software package is recommended.
Finally, build the operational software around the resources and functions tested and conduct further testing as the software is built. This is precisely the process that was followed in the development of the SPI/SD interface and the ROM version of DOS/65. One key advantage of such a process is that problems are found when the complexity of the software is limited thus allowing easier debugging. It does not mean that problems will not be found at the top level but discovery should be at a sufficiently low level to allow clear resolution.

Implementation is straightforward. The basic DOS/65 software structure need not change. However, the specific addresses of functions may have to change as a function of the platform monitor or other software elements. The process of implementing D0S/65 for the SBC2 drew heavily upon the experience involved in producing the version for the WDC SXB but was actually simpler because of the capabilities provided by the SBC2 monitor.