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.
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.
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).
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).
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!!!
Now I will describe the different approaches to use the generic SCSI interface in a Commodore system, more specifically with a C64 or C128.
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.
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.
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.
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.
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.
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%.
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)
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.
Idea
When the 6522 is replaced with a 6526 the burst mode of the VC1571 can be used.
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.
Schematics exist, but they are preliminary, untested, and a mess! Again, they are provided AS IS, without warranty!
