
                     SCSI-64: SCSI controller for the C64
                                       
(c) 1997-1999 Andr Fachat (a.fachat@physik.tu-chemnitz.de)

   This is the description of several SCSI controllers for the Commodore
   C64 computer. Some of them may be used with a VIC20 or C128 as well.
   All of the controllers are based on one hardware interface that is
   built into different setups. So after going a bit into the SCSI
   standard first I present the generic interface.
   
   The driver code is made in a modular way. It consist of the hardware
   driver and the partition handler. Both are separated by a well-formed
   programming interface, as well as the partition handler presents a
   nice interface to the filesystem code. This architecture is presented
   in the second part.
   
   The different hardware projects using the generic SCSI interface are
   described in the third chapter. Those include a SCSI interface
   directly for the C64, as well as disk-drive-like small computers that
   can be used via the C64s serial IEC bus.
     _________________________________________________________________
   
Disclaimer

   Before you go on, you should know that all this stuff comes with no
   warranty at all . Of course this hardware is not to be used in any
   important or even life-critical systems. The hardware schematics and
   software are provided 'AS IS', WITHOUT WARRANTY of any kind. The
   entire risk as to the quality and performance of the hard- and
   software is with you. Should the hard- or software prove defective,
   you assume the cost of all necessary servicing, repair or correction.
   
Distribution

   Warning: This computer system is public domain for NON-COMMERCIAL
   purposes only! If you want to do something useful with it, please
   contact me. Also if you like to produce PCBs, or want to earn money
   with it, please contact me first.
     _________________________________________________________________
   
SCSI Standard

   SCSI means "Small Computer System Interface". It is an interface that
   connectes computers with peripheral devices, like disks, scanners,
   CD-ROMs etc. As such it is very flexible.
   
   The first SCSI interfaces were using asynchronous I/O mode. Each
   transfered byte was requested and acknowledged with a special
   handshake. Nowadays synchronous modes with up to 40 or 80 MByte/s are
   supported. Yet, all devices still know the asynchronous mode and can
   be used with this interface (at least I did not encounter one, but I
   also did not test that many).
   
   The SCSI-II standard defines a number of command sets for a variety of
   devices. Disks are accessed as "direct access devices", and commands
   for CD-ROM devices, Printers, coprocessors etc are defined. The
   commands are transferred in a standard way, which makes the transport
   level flexible. And once you know how to send one command, you can
   easily send any other. To send a command you can have a look at the
   software from this page, that includes SCSI drivers for the 6502.
   
   Unfortunately the SCSI standard cannot be found on the net, but has to
   be purchased from the ANSI organization (see http://web.ansi.org/) or
   other sources. A technical or university library might be a place
   where you can at least read the standard if they have it. The SCSI-II
   standard is refered to as ANSI X3.131-1990 Small Computer Systems
   Interface-2 (SCSI-II). The SCSI-I standard is X3.131-1986.
   
   A good source (although a bit hard to read) is the linux kernel source
   code. Recommended reading are the comments at the beginning of
   drivers/scsi/aha152x.c, the defines in include/scsi/*, especially the
   SCSI command opcodes. greping for them in the code will give you an
   idea how to use them. One example is the function scan_scsis_single()
   in drivers/scsi/scsi.c. All code references relative to the main
   source directory, usually under /usr/src/linux/, of linux kernel
   version 2.0.36 (although the linux version should not matter that much
   here).
     _________________________________________________________________
   
Generic 6502 SCSI Interface

   The SCSI controller is derived from a very old SASI interface card
   published by the german magazin "elektor". I implemented this
   interface (heavily modified and modernized) in 1998 as a CS/A board
   (my own design for 6502-based computers, see on
   http://www.tu-chemnitz.de/~fachat/8bit/csa/index.html).
   
   The schematics can be found in csascsi1.ps.gz or csascsi1.gif. A parts
   list and a hardware description are available.
   
   The interface is still not at SCSI-II level and it only does basic
   asynchronous I/O mode, but nevertheless, it works with my Seagate
   ST 1096N (80M) as well as with my IBM Ultra-Wide SCSI-II disk with
   4.3G (I love SCSI for that. Try to add an MFM disk that was still in
   use when I bought my Seagate to a PC of today...).
   
   This interface has been designed for the CS/A65 bus system. However,
   this bus system basically is the 6502 bus. In fact, besides the /IOSEL
   line only 6502 CPU lines are used./IOSEL selects the I/O area and is
   generated from the address lines in the usual way. This means that the
   interface can be used on a variety of systems, and it is used on
   selfbuilt computers as well as the C64, as will be seen below. The
   6809 has the same bus interface as the 6502, so it could even be used
   with this CPU (although no drivers exist for the 6809).
     _________________________________________________________________
   
Software architecture

   The software architecture is kept as flexible as possible. Three
   levels work together, the hardware driver, the partition level that
   transforms block numbers in a partition into block numbers in the
   device, and the third level which is the filesystem code.
   
   The hardware layer is a low level driver that can detect the devices
   connected to the SCSI bus, inquire the device (it returns the type
   etc), get the blocksize and read or write single blocks. As SCSI
   devices just hold a number of linearly numbered blocks there is
   absolutely no need to use any track/sector numbering etc. In the
   driver code (see below) the file csascsi1.a65 contains the low level
   driver for the generic SCSI interface described above. The file
   ramdscsi.a65 holds a driver for another interface, that I implemented
   in the VICE emulator, not in hardware. You write the block number to
   some I/O locations and get the right block memory mapped. This code
   shows how easy it is to replace the hardware level if necessary.
   
   The partition level consists of three parts, where only two are
   implemented so far. First in the file part.i65 the format of the
   partition table is defined. paccess.a65 then translates the block
   numbers given to the absolute block numbers on the device using the
   partition table. The table is filled in on init by the code in
   pcpart.a65 that scans the disk for PC-like partition tables. To use
   other types of partition tables (like Amiga-type for example), simply
   replace this file with a new one that fills in the partition table
   appropriately. The third part would be an fdisk program that uses the
   low level routines to manipulate the partition tables. But here I
   still rely on the Linux counterpart I already have :-)
   
   The upper level is the filesystem level. It contains code to handle
   directories, files, allocation tables etc. This is not contained in
   the basic SCSI drivers, because it is heavily depending on the
   operating system. It should be easy to implement any filesystem you
   like on the level provided by the partition code.
   
   The most recent SCSI drivers can be found in the GeckOS/A65 operating
   system in oa-2.0.8.tar.gz in the directory oa-2.0.8/devices/scsi. An
   example of a filesystem implementation can be found in
   oa-2.0.8/sysapps/fs/fsibm*, that implement a fileserver task for the
   GeckOS/A65 operating system. It handles PC-style disks with the FAT12
   or FAT16 filesystem (no FAT32 and no long filenames). But be warned,
   it is an early beta!!! Don't ever try it on a disk that contains
   anything valuable to you!!!
     _________________________________________________________________
   
Hardware projects

   Now I will describe the different approaches to use the generic SCSI
   interface in a Commodore system, more specifically with a C64 or C128.
   
  C64 SCSI (harddisk) adapter
  
    Idea
    
   This interface should directly connect a harddisk to the C64. The C64
   would then have to do all the filesystem handling itself, but it is
   fast (no serial IEC bus) and cheap.
   
    Description
    
   This is a simple example of how to use the C64-CS/A adapter with a
   CS/A65 I/O card. The C64-CS/A adapter (schematics in c64csa.ps.gz,
   c64csa.gif, parts list and description) is plugged into the expansion
   port using one I/O area (at $de** or $df**). It uses a VIA 6522 to
   expand the address range so that you can use the full CS/A bus system
   with all cards.
   
   The results of the combination with the CS/A-SCSI card is a simple C64
   expansion port card without CS/A bus interface, in this case in the
   C64 SCSI controller.
   
   A picture says more than a thousand words, so here is the C64 SCSI
   interface schematics as c64scsi.gif or c64scsi.ps.gz. This is a
   combination of the CS/A SCSI controller and the C64 CS/A adapter.
   However, as only the SCSI controller will be used, some parts of the
   combined schematics can be left out (shaded grey), and only one
   additional connection has to be made (indicated).
   
   Matthias Kirchner provided me with an Eagle schematics and board
   layout for the C64-SCSI board. However, There is absolutely no
   warranty with this schematics and layout, as I could not fully check
   it. You can find it in c64scsi.zip.
   
    Status
    
   The interface consisting of the C64-CS/A adapter and the CS/A-SCSI
   card has been tested on a C64 and works. The "imploded" version with
   the left out parts has not been tested.
     _________________________________________________________________
   
  VC-SCSI 1.0 drive
  
    Idea
    
   Provide a separate computer like the VC1541 and interface it with the
   C64 via the serial IEC bus. This would keep a lot of work off the C64,
   and provide easier access.
   
    Description
    
   This is a combination of the Gecko computer and the SCSI board.
   
   The Gecko (see the gecko directory) is a small single-board 6502
   computer. The base system provides 32k RAM, 32k ROM and access to the
   CS/A I/O bus (which is the CS/A bus itself, but only using the lower
   12 address bits with /IOSEL). The full Gecko includes an RS232
   interface, as well as a VIA6522 with serial IEC and keyboard
   interface.
   
   Combining the Gecko with the SCSI interface is simple, just attach it.
   If you remove the backplane by putting both cards on the same board
   you can also leave out some parts of the Gecko that are of no use.
   Those parts are shaded grey in the schematics. This board can be used
   with the C64, C128 and VIC20.
   
   The schematics are available as vcscsi-1.0.gif or vcscsi-1.0.ps.gz.
   
    Status
    
   The Gecko board and the SCSI interface have been tested separately and
   both work. Also the Gecko board works with several other CS/A cards
   (my Gecko prototype board developed a bad soldering so I cannot test
   it with the SCSI board at this time.). The SCSI interface has been
   tested with the orignal CS/A65 computer and with the C64 using the
   adapter from above. This will work with >99.5%.
     _________________________________________________________________
   
  VC-SCSI 1.x drive
  
    Idea
    
   Modify the Gecko board such that the VIA appears at the same place as
   the IEC VIA in the VC1541, and also use the very same IEC schematics
   as in the VC1541. This would allow building a VC1541 emulation mode
   for all speeders that use the standard FDC routines to acces a floppy
   - these routines would then be replaced to access a large file on the
   harddrive (a .d64 image basically)
   
    Description
    
   This is basically still the Gecko board. Only the address selection of
   the I/O area around IC2 would have to be changed, as well as the
   address value at IC9. The VIA would get the very same IEC electronics
   as the VC1541 has, removing anything else. The UART (RS232) would be
   removed as well.
   The 32k ROM would be divided into an upper 16k part and a lower 16k
   part. The upper part would be filled with a modified VC1541 ROM, and
   the lower part with the SCSI filesystem code.
   To make the emulation mode reasonably secure part of the RAM - that
   would then contain the mapping of VC1541 blocks -> blocks on the disk
   drive - should be made write-protectable. This way any floppy speeder
   going haywire could with high probability not overwrite other parts of
   the HD.
   
    Status
    
   Idea
     _________________________________________________________________
   
  VC-SCSI 2.0 drive
  
    Idea
    
   When the 6522 is replaced with a 6526 the burst mode of the VC1571 can
   be used.
   
    Description
    
   In this schematics I have molded the Gecko and the SCSI boards more
   together, without a bus in between. Also I replaced the 6522 with a
   6526. This allows to use the fast serial IEC bus as used with the C128
   (or with a modified C64). A place for a Speeder Cable is also
   provided.
   
   Thanks to Nicolas Welte I have improved the parallel speeder cable
   support, and provided a way to set the IEC ID.
   
   One word of warning, though: The schematics are preliminary, untested,
   and a mess! Again, they are provided AS IS, without warranty!
   
   The schematics are available as vcscsi-2.1C.gif or vcscsi-2.1C.ps.gz.
   And there is the vcscsi-2.1C-parts.txt parts list.
   
   The memory map has RAM at $0000-$7FFF, ROM at $8000-$DFFF and
   $E800-$FFFF. I/O is at $E000-$E7FF, with $E000-$E3FF mirrored at
   $E400. $E0** is the 6526, $E1** is the SCSI interface and $E2** is the
   IEEE488 ID and speeder flag port. $E3** is not (yet) used, so there is
   place for a disk controller or whatever.
   
    Status
    
   Schematics exist, but they are preliminary, untested, and a mess!
   Again, they are provided AS IS, without warranty!
     _________________________________________________________________
