Though this site is not about home computer systems, but about small SBC’s, it is nevertheless interesting to look at the Atari 850 system.
Atari produced the 850 Interface Module to provide access to devices complying with two important interface standards of the time, RS-232-C serial and Centronics parallel.
Four serial interfaces, one parallel interface in self contained case, with its own power supply. Connected to the Atari via the standard SIO cable.

When you look into the system you discover it is actually a simple microprocessor system. The heart is a 6507 CPU, the serial and parallel lines are built with two 6532 IC’s, a ROM with the software.
Serial interfaces and the 6532? This means bit banging.
So this fits well in the theme of small SBCs!

I show you here the circuit diagram, operator, service and technical manual and the sources/binaries of the ROM.

	Circuit diagram
	Atari 850 interface Module Operator Manual
	Atari 850 interface Module Technical Manual
	Atari 850 interface Module Service Manual
	Sources and binaries of the 850 ROM
	Parts list page 1, 2

While the Atari's SIO and controller ports did not conform to established
industry standards, Atari produced the 850 Interface Module to provide access
to devices complying with two important interface standards of the time,
RS-232-C serial and Centronics parallel.

RS-232-C Serial Interface
-------------------------
The Electronic Industries Association (EIA) introduced the RS-232 standard,
entitled "Interface Between Data Terminal Equipment (DTE) and Data Circuit-
Terminating Equipment (DCE) Employing Serial Binary Data Interchange," in 1960
in an effort to standardize the interface between DTE (usually a terminal or a
computer emulating a terminal) and DCE (usually a modem).  Although emphasis
then was placed on interfacing between a modem unit and DTE, other
applications for the standard gained popularity.  Early versions of the EIA
232 standard included RS-232 (1960), RS-232-A (1963), and RS-232-B (1965).
From 1969-1987, including most of the time of the 8-bit Atari, the standard
was formally known as EIA RS-232-C.  Revisions since then have included EIA-
232-D (1987), EIA/TIA-232-E (1991), and the current version from the
Telecommunications Industry Association, EIA/TIA-232-F (1997), known as of
2011 as TIA-232-F.  Especially in the 1980s, 232 was widely adopted for low-
cost serial connections between the DTE and peripherals such as an external
modem, mouse, plotter, printer, scanner, digitizer, track ball, and myriad
others.  In more recent years TIA-232-F has essentially been supplanted by
USB.  In keeping with the context of the time period, this FAQ will normally
refer to the 232 standard as RS-232-C.  

The Atari 850 interface connects to the SIO port on the Atari computer and
provides the system with:

- Four serial interface ports (RS-232-C)
- One 8-bit parallel output interface port (Centronics)

Serial interface port key features:
- The 850 functions as RS-232-C Data Terminal Equipment (DTE).
- RS-232-C Circuits (signaling lines):
                 (Send / Out)  | (Receive / In)
       Port 1:   XMT, DTR, RTS | RCV, DSR, CTS, CRX
       Port 2:   XMT, DTR      | RCV, DSR
       Port 3:   XMT, DTR      | RCV, DSR
       Port 4:   XMT           | RCV
- Port 4 primarily serves as a 20 mA current loop interface, supporting
  20 mA current loop peripherals such as a teletype machine.
- Baud rates:
    45.5 bit/s*, 50 bit/s*, 56.875 bit/s*, 75 bit/s**, 110 bit/s, 134.5 bit/s,
    150 bit/s, 300 bit/s, 600 bit/s, 1200 bit/s, 1800 bit/s, 2400 bit/s, 
    4800 bit/s, 9600 bit/s
  * These baud rates are useful for communications with Baudot teletypes, for
    RTTY (radioteletype) applications.  They are more commonly referred to as
    60, 67, and 75 words per minute.
 ** This baud rate is sometimes used for ASCII communications, and may also
    be used for 5-bit Baudot RTTY.  The latter is commonly referred to as
    100 words per minute.

The Atari Operating System does not include a resident device handler for the
serial ports of the 850, but the 850 contains an R: handler, supporting
devices R1: through R4:, in its ROM.  
   - Bootstrap without disk drive-- With no powered disk drive #1 present, the
     R: handler loads from the ROM of a powered 850 into computer RAM on 
     system startup.  (The 850 masquerades as disk drive #1, responding to the
     Atari OS attempt to boot from disk.)  An extended beep is emitted through
     the computer's audio signal as the handler is loaded.
   - Bootstrap with disk drive-- The R: handler can be loaded from the
     850 ROM as part of a Disk Boot.  (Atari DOS 2.0S, DOS 3, DOS 2.5, and 
     DOS XE include provisions for this.)
   - The R: handler can be loaded from the 850 ROM by software after system 
     boot.
Many alternatives to the 850 ROM R: handler have been developed.  Please see a
separate section of this FAQ list regarding R: and T: device handlers for the
850 for more details.

The Atari Operating System's resident P: Printer device handler supports the
parallel output interface port of the 850.
- 400/800 OS: Responds to P: and ignores any device number
    XL OS: Responds to P:, P1:, and P2:

PINOUTS
=======
Serial Interface Port 1 (DE-9 Socket - female):
                1. DTR Data Terminal Ready (Out)
                2. CRX Carrier Detect      (In)
  5         1   3. XMT Send Data           (Out)
   o o o o o    4. RCV Receive Data        (In)
    o o o o     5. Signal Ground
   9       6    6. DSR Data Set Ready      (In)
                7. RTS Request to Send     (Out)
                8. CTS Clear to Send       (In)

Serial Interface Port 2 (DE-9 Socket - female):
  5         1   1. DTR Data Terminal Ready (Out)
   o o o o o    3. XMT Send Data           (Out)
    o o o o     4. RCV Receive Data        (In)
   9       6    5. Signal Ground
                6. DSR Data Set Ready      (In)

Serial Interface Port 3 (DE-9 Socket - female):
  5         1   1. DTR Data Terminal Ready (Out)
   o o o o o    3. XMT Send Data           (Out)
    o o o o     4. RCV Receive Data        (In)
   9       6    5. Signal Ground
                6. DSR Data Set Ready      (In)

Serial Interface Port 4 (DE-9 Socket - female):
                        / 20 mA Current Loop Operation
                1. +10V / TXD+ Send Data +
  5         1   3. XMT  / TXD- Send Data - (Out)
   o o o o o    4. RCV    Receive Data     (In) --+  A 20 mA current loop
    o o o o     5. Ground                         |  device must tie together
   9       6    7. +10V / RXD+ Receive Data +   --+  pins 4 and 7.
                9. -8V  / RXD- Receive Data -

Parallel Interface Port (DA-15 Socket - female):
                     1. /Data Strobe
                     2. Data bit 0
                     3. Data bit 1
 8               1   4. Data bit 2
  o o o o o o o o    5. Data bit 3
   o o o o o o o     6. Data bit 4
  15            9    7. Data bit 5
                     8. Data bit 6
                     9. Data Pins Pull-Up (+5V)--+ A device that cannot hold
                     11. Signal Ground           | /Fault high may instead tie
                     12. /Fault (high required)--+ together pins 12 and 9.
                     13. Busy
                     15. Data bit 7

Prototype 850 units are in an all-black brushed steel case, but production
units are in a beige plastic case matching the 400/800 computers.

Front of unit (left-to-right):
 - Power In jack
 - On power indicator light
 - Power Off / On switch
 - Two I/O Connectors (Atari SIO)
Right side of unit:
 - Parallel Interface port
Rear of unit (left-to-right):
 - Four Serial Interface ports, 4 - 3 - 2 - 1

850 internals:
 - 6507 MPU (MOS Technology MCS6507 or equivalent), C010745
 - 6532 PIA.  Two of: 
    - MOS Technology 6532 RAM-I/O-Timer (RIOT) or equivalent, C010750
 - 4KiB X 8 Bit ROM, C012099

Manuals:
- Atari 850 Interface Module Operator's Manual C015953 Rev. 1 1980
  (preliminary version shipped with earlier/most 850 units; 102 pages)
- Atari 850 Interface Module Operator's Manual C017651 REV. B 1982 (15 pages)
- Atari 850 Interface Module Technical Manual C017652 REV. B 1982 (106 pages)
- Atari 850 Interface Module Field Service Manual
   - CS 400/800-S004-B 4/81
   - FD100036 April, 1981

Power: Used with an external 9 volt AC transformer power supply rated for at
least 17 watts: Atari CA014748 or equivalent.

The 850 was designed by R. Scott Scheiman at Atari, 

The 850 was alo sold as bareboard with a parts list

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.

The SD interface for the W65c02SXB based on Andre Fachat’s v1.1 design using a VIA and three eternal ICs.

nhyodyne modular backplane system

DOS/65 V2 as implemented on the nhyodyne modular backplane system.

More information in the 6502proc folder at this github page.