The Cirtech Flash drive

Hardware

The Flash drive is a variation on the Gem Drive concept. Instead of an XTA or ATA hard drive, it uses one or two Intel E28F008SA flash chips to provide a 1Mb or 2Mb solid-state boot drive. In normal use the drive is read-only; special utilities are supplied to erase it and copy files to it.

The drive is mapped into PCW memory by a read from I/O port 0xxD8h, with the high byte of the address specifying which 32k bank to select. This mechanism would allow a Flash Drive of up to 8Mb. However the supplied utilities are only aware of the 1Mb / 2Mb configurations. Reading from I/O port 0xxD9h pages the drive out again.

When the drive is paged in, the selected memory bank is visible at 00h-7Fh, 0100h-017Fh, 0200h-027Fh, and so on up to 0FF00h-0FF7Fh. Code that is accessing the drive, and any transfer buffers, must therefore be between addresses 0xx80h-0xxFFh.

Because of the physical layout of the interface, the data lines are reversed for the first chip as opposed to the second. This doesn't affect reads, but it means when commands are written to the chips, they must be reversed bitwise. For example, when an erase is being performed the command sent would normally be 80h; on the Flash Drive, the utilities send 80h to erase the second chip, but 01h to erase the first.

Startup

If the 'autoboot' switch is turned on, then when the PCW is booted bank 0 of the drive is mapped into memory, and therefore should contain a valid boot program. As with the Gem drive, the boot program's first action is to read the standard (floppy) boot ROM into memory by repeated memory reads from 80h, until the byte sequence D3 F8 [OUT (0F8h),A] is encountered. Then it executes its own write to that port to switch to normal execution, and copies itself into RAM.

The first I/O port access uses 16-bit I/O [OUT (C),A style], with the top 8 bits of the address set to 80h. Later ones switch to the usual PCW 8-bit style [OUT (0xxh), A]. On the Gem drive this would page out the boot ROM, but as the Flash drive does not have a separate boot ROM I suspect this may just be legacy code.

Once the floppy boot ROM has been read in, the Flash boot loader copies itself into RAM and continues execution from there.

Boot image

The boot image combines the behaviour of the Gem drive's 4k boot ROM and system track. The install program provided with the drive uses it to initialise a new Flash drive. On the utilities diskette it is stored in a file called FD.SYS.

The boot image starts with a header:

Offset	Size	Description
0	Word	Short jump to boot code at 001Fh
2	Word	Offset to boot programs table
4	Word	Offset to image of FDRIVER.FID
6	Word	Offset to the splash screen
8	Word	Offset to image of FDRIVER.FIC
0Ah	Byte	Default operating system: Bit 7 set for CP/M, reset for LocoScript
0Bh	17 bytes	CP/M Plus DPB for the drive
1Ch	Word	Sector number of first sector of directory (ie, length of boot image in 512-byte sectors)
1Eh	Byte	Checksum of preceding 30 bytes
1Fh	3 bytes	Jump to first stage boot code at 0100h. Note that the code is stored in FD.SYS at offset 0080h, but at boot time becomes visible at 0100h.

The boot programs table

This table contains a list of boot programs. Each entry is five bytes long:

Offset	Size	Meaning
0	Byte	8-bit checksum of the first 512 bytes of the EMS/EMT file
1	Word	Offset of boot program from start of table
3	Word	Length of boot program

The end of the table is indicated by a boot program with offset 0. If the checksum of the first 512 bytes of the EMS/EMT file does not match any of the entries in the table, the boot ROM will give a single beep and refuse to execute it.

If a matching boot program is found, it will be copied to 0D000h and run with the following parameters:

HL = length of FDRIVER.FID. FDRIVER.FID will be in memory at 0D000h + length of boot program.
C = boot program number (1-based).
The selected EMS / EMT file will be in memory from 0000h up.

The task of the boot program is to inject the FDRIVER.FID image into the loaded EMS / EMT file, so that it boots from the flash drive rather than the floppy.

The FDRIVER.FID image

This is an exact copy of the FDRIVER.FID used to access the flash drive when booting from floppy.

The splash screen

This is a 720×146 bitmap. It is stored as 19 rows, each containing 90 8×8 character cells. The first row should be blank, because it is used to draw the 55 scanlines above and below the picture.

The FDRIVER.FIC image

This is a slightly modified version of FDRIVER.FID used when booting later versions of LocoScript (probably LocoScript 4, and maybe some later 3.x versions; messages in FCOPY.COM suggest version 3.06 and later). It contains an extra Supervisor Call to inform LocoScript that it is being started from a hard drive rather than a floppy.

Driver RSX

The supplied utilities DELETE and FCOPY are written in a high-level language (probably Borland Pascal). They access the flash drive hardware through a separate RSX attached to the program; this ensures that the access code is located in the correct areas of memory, something a compiler can't guarantee. The INSTALL utility does not use the RSX, but directly incorporates a similar library of functions.

The RSX is called using BDOS function 60:

C = 3Ch
DE = address of RSXPB:
	DEFB	function
	DEFB	num_parameters	;All calls have 2 parameters
	DEFW	param1
	DEFW	param2

Returns A=result:
   	0: OK
	1: General error
	2: Flash chip not responding
	3: Programming voltage low (fault in PCW 12v power line)
	4: Flash write error
	5: Flash drive not detected
	6: Function out of range
	7: Flash drive not initialised
     0FFh: RSX not present

Function 0: Read 2k block

	param1 = offset of data to read in Flash
	param2 = address of result buffer

Function 1: Write 2k block

	param1 = offset of data to write in Flash
	param2 = address of source buffer

Internally, the code library also supports some other functions: 2 (which would determine the size of the Flash drive in 512-byte sectors and return it in HL) and 80h (to read the Flash header) but these are not exposed by the RSX interface.

John Elliott 31-5-2022