CS/A65 SCSI interface

•  
  2007-05-26 Added new board revision (with I2C flash and RTC/RAM). It also adds the missing pullups for I2C SDA and SCL.
•  
  2006-12-14 Added new board revision (with I2C interface) and new driver code.
•  
  2006-11-01 Added driver code.

• Hardware Architecture
• Software Architecture
• • Hardware layer
  • Partition layer
  • Filesystem level
  • Drivers
• Driver
• • OS/A65 I2C driver
  • PETCPU fat40 I2C driver
  • PETCPU fat40 SCSI driver
  • OS/A65 SCSI driver
• Board Revisions
• • 1.2B (untested)
  • 1.1A (ok)
  • 1.0A (ok)

The hardware architecture is actually very simple. As only asynchronous data transfer is needed, the board provides bidirectional access to the 8 data lines, plus access to the control lines. Parity check is provided, as well as automatic REQ/ACK handling by simply accessing the data register. For more information see the board description below.

The SCSI board has a heavily modified version of an old SASI interface from the german elektor magazin (around '88 or so). It has been reworked to get more SCSI-II compliance, but it is still not there. It works, however, with my Seagate ST1096N harddisk :-)

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.

Hardware layer

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.

Partition layer

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 :-)

Filesystem level

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.

Drivers

The most recent SCSI drivers can be found in the GeckOS/A65 operating system. 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!!!