ETI December 1987 — page 99

1617: Floppy Disk Controller

Remember the first article on the 1616? We said that we thought it was best to leave the disk controller to an expansion board and do the job properly. Well this is it! Its slave processor disguised as a disk controller. Its called the “Applix 1616 disk co-processor card” or SSDCC for short.


SSDCC Hardware Specifications


Given the need for a disk interface for the 1616, there are a number of ways in which this could be done:

Direct interface to MC68000:

Connect the disk controller IC to some form of memory buffer. During disk reading control hardware placed data from the disk controller into the buffer which may then be read out by the MC68000. This avoids the problem of totally occupying the processor time, however it requires a lot of tricky hardware.

DMA control:

During reading, data is moved from the disk controller IC directly into the 1616’s main memory by a Direct Memory Access controller. This is a very common way of interfacing a disk controller and it would be a quite reasonable way of solving the problem.

Slave microprocessor control:

This is the chosen technique. A stand alone 8 MHz Z80 computer which communicates with the 1616’s MC6800 microprocessor via an 8 bit data port and some handshake and interrupt signals. This is attractive because of its flexibility; with a separate Z80 to manage the disk I/O we can perform buffering of large amounts of data in the Z80’s memory, control the SCSI interface as well as the floppy interface and control a couple more serial ports.

The Z80 was chosen because the 8 MHz device is quite a fast microprocessor; it has the power to perform the I/O tasks needed and since all the data is handled in single bytes, a 16 bit CPU is not really an advantage. The cost is low, the Z80 is well known and development tools and software are common, finally, it is not impossible that the 1616 will one day be seen running the good old CP/M (or ZSYSTEM) operating system within its disk controller

The SSDCC circuitry’s major sections are the Z80 processor and its address decode circuitry, the Z80’s memory, the floppy disk interface, the SCSI hard disk interface, the dual serial I/O channels and the 1616 bus interface.

Unlike the 1616’s MC68000 microprocessor, the Z80 has separate memory and I/O address spaces, and a separate set of bus signals to control memory and I/O transactions. The Z80 decode PAL (IC8, ZPAL) and the 3 to 8 decoder (IC13) together perform the memory and I/O enabling.

The Z80 may be forced to insert extra clock cycles into a memory or I/O transaction by forcing it into a ‘wait state’. This is done when pin 13 of the Z80 PAL goes low; the arrangement of the flip-flop IC6 causes the Z80 to insert a single wait state into a memory of I/O access. Thus the programming of the PAL determines which addresses receive wait states and which do not. At present all I/O transactions and ROM reads have a wait state. RAM reads and writes proceed at full speed.

About 16L8 PALs:

The PALs which are used on the 1616’s main board are 16R8’s. The ‘R’ stands for registered, which means that these PALs have latched outputs, so that changes in the registered PAL’s output state can only occur on the rising edge of the PAL’s clock pin. A 16L8 PAL, however, is an array of simple logic gates whose output is immediately available.

A registered PAL is used in a situation where its outputs have to be synchronised or where memory about the PAL’s previous states is needed. The non-registered PAL (16R8) is used simply to detect certain combinations of its input pins, which make it ideal for address decoding applications.

The signals ‘MAP’ and ‘BANK’ which go into the Z80 PAL are provided for selecting a different memory map and for overlaying memory banks. The Z80’s memory map is as follows:

	0000H-5FFF H:ROM
	6000H-7FFF Common RAM bank H:
	8000H-FFFF Switching RAM bank H:

So that the Z80 may access all of the possible 64 kbytes of RAM whilst still reading from the ROM the RAM is split into two 32k halves. Only one of these halves may appear in the top 32k of address space at a time. When the ‘BANK’ signal is low the data in RAM0 (IC1) is accessible in this address range; when ‘BANK’ is high the data in RAM1 (IC2) is accessible. If 8 kbyte RAM chips are loaded in the board then only the first 8 kbytes of this 32k address space are useful. The first 8 kbytes of RAM is always accessible in the common bank. The ‘MAP’ signal is not used at present.

The Z80’s I/O port address map

Address	Name		Function
00H	PORT		Read only input port.
08H	LATCH		Read/write disk select latch
10H	ZINTS		Write: interrupt the 1616.
10H	ZCLRINT		Read: clear pending Z80 interrupt.
18H	SDATA		Read/write 1616 communications port.
20H	SCSIBASE	SCSI controller base address
40H	FDCBASE		Floppy disk controller base address.
60H	SCCBASE		Serial communications controller base address.

The input port enables a Z80 program to determine the level of the following signals:

Bit 0: The ‘SCOMMAND’ signal is set when the byte from the 1616 which is currently held in the receive latch is a command, meaning that the MC68000 put the data there by writing to its ‘SCOMMAND’ output port.

Bit 1: The ‘ZRXRDY’ signal is high if there is a data or command byte from the MC68000 within the receive register.

Bit 2: The ‘ZTXRDY’ signal is high if the 1616 has read the previous byte out of the transmit register.

Bit 3: This signal determines whether the Z80 is to enter its normal operating mode or to execute its diagnostic test mode.

The floppy disk interface

The disk controller uses Western Digital’s WD1772 all digital floppy disk controller IC. A floppy disk controller handles the low-level control of the disk drive: synchronisation of new data with that which is already on the disk, checking for errors in read data, searching for the correct disk sector, issuing stepping pulses to move the disk drive’s read-write head, etc. This leaves the Z80 with the task of issuing commands to the controller, transferring data to or from it and handling errors which the controller detects.

We have seen many generations of floppy disk controllers over the years; it is only this latest generation which have avoided the need for setting up magic frequencies with variable capacitors, devising ingenious data separators which occasionally worked, etc. The all-digital design of the WD1772 eliminates these problems. The chip still has a few problems which can keep a programmer quiet for a few days, however . . .

The disk select latch (IC16) contains signals which are set up by the Z80 and which are used for selecting between multiple drives (DS0 and DS1), ejecting the disk, selecting the desired side of the disk, etc.

SCSI hard disk interface

The SCSI (Small Computer Systems Interface) standard is a specification for communicating data over a high speed 50 wire bus which appears quite frequently in medium performance microcomputer systems. Hard disk drives are available which have an SCSI bus interface; host commands, data and error information are passed between the controlling computer and the disk drive electronics over this bus.

The NCR 5380 IC is designed for interfacing microprocessors to the SCSI bus. It incorporates line drivers and receivers and so yields a single-chip solution to the 1616’s need for a hard disk interface.

The SCSI interface and connection of the SSDCC to hard disks will be covered in full in a future article.

Serial ports

The design of the SSDCC allows the implementation of two serial ports. These were made to be identical to those on the 1616’s main board: the Z8530, the strapping blocks, the RS-232 drivers and receivers and the connector pinouts all match those on the 1616. For the record, we had serial ports on the SSDCC prototype to help with debugging and to allow downloading of code to the Z80. After some head scratching and shoulder shrugging it was decided that the SSDCC deserved its own dual serial I/O ports.

Think of this. In between the MC68000 and the serial ports on the SSDCC is a Z80H and 64K of RAM. This allows for some pretty powerful serial operations. For starters, what about a transparent (to the MC68000) serial protocol convertor, or an intelligent network server . . .

1616 interface:

The other 16L8 PAL on the SSDCC is referred to as the 1616 PAL (IC24, SPAL). It handles the 1616 address decoding, DTACK signal generation, status port multiplexing and handshaking control.

With this PAL we are using the PAL’s ability to turn its outputs into a high-impedance (or floating, or tri-state) condition under certain input signal combinations. The DTACK output pin is normally floating; it is actively driven only during MC68000 accesses. Similarly the D7 output pin directly drives the 1616 data bus and is floated until the MC68000 reads the SRZRDY, STXRDY or ZCOMMAND signals. When this happens the PAL routes the selected signal onto the D7 output and enables this pin to drive the bus.

The 1616’s MC68000 can read and write various registers within the controller at fixed addresses:


$FFFFFC1	R/W	ZDATA		Read: Data from Z80. Write: Data to Z80.
$FFFFFC3	Read	SCLRINT		Clear 1616 interrupt.
$FFFFFC3	Write	SINTZ		Interrupt Z80.
$FFFFFC9	Read	SRXRDY		Bit 7 set if receive latch full.
$FFFFFCB	Read	STXRDY		Bit 7 set if contents of the receive latch is a command.	
$FFFFFD1	Write	SCOMMAND	Write data to the data latch, set SCOMMAND bit.


Power and Ground connections


needs a lot of checking!

Chip	Device
no.	name			+5V		Gnd		+12	-12
IC1,2	6264/25256		38		14
IC3	2764/27128/27256	21,1		14
IC4	Z80H			11,25		29
IC5	SPARE
IC6	74LS74			14,1,10,13
IC7	74LS74
IC8	ZPAL16L8		20		10
IC9	SPARE
IC10	5380			27,26,31	11
IC11	74LS04			14		7
IC12	SPARE
IC13	74LS138			16,?		7
IC14	74LS74			14,1,13	7
IC15	74LS244			20		10 
IC16	74LS273			20		16
IC18	74LS74			14,2,4,10,13	7
IC18	74LS74			14,1,4,16,12	7
IC19	74LS38			14		7
IC20	74LS32			14		7
IC21	74LS06			14		7
IC22	74LS244			20		10,19
IC23	WD1772			15		14,26
IC24	SPAL16L6		20		10
IC25	74LS30			14		7
IC26	74LS30			14	
IC27	28636			7,8		31
IC28	74LS374			20		16
IC29	74LS374			20	
IC30,32	1489			14		7
IC31,33	1488					7		14	1

The communication between the two processors is quite simple. If the 1616 wishes to transmit a byte to the Z80 it waits for STXRDY to go true and then writes the byte to the ZDATA port. The action of writing to ZDATA causes STXRDY to go false until the Z80 has read the new byte.

Similarly when the Z80 wishes to transmit to the 1616 it waits for ZTXRDY to go true, indicating that there is valid data in the receive port latch. When the 1616 reads the data SRXDY goes false and the Z80’s handshake signal ZTXRDY goes false. In fact ZTXRDY is the complement of SRXRDY and ZRXRDY is the complement of STXRDY.

For software reasons it is desirable that the transmitting processor can add a flag to a transmitted byte to indicate whether it is a data byte or a command byte; a command byte is one which initiates a whole transaction such as reading a disk sector. Being able to flag commands simplifies the problem of synchronising each processor’s software.

The command bits are address triggered; when the 1616 writes to the data port latch the MC68000 address line A4 is latched in IC17 as the SCOMMAND signal. When the Z80 sees that data is available (via ZRXRDY) it inspects the SCOMMAND signal. If this is high then the Z80 knows that the 1616’s A4 signal was high when the data was written; the 1616’s command port is at an address which has A4 high whereas its data port’s address has A4 low, so the Z80 can differentiate between command bytes and data bytes.

Interrupts:

There is capability for the Z80 and the 1616 to interrupt each other. Interrupts are not used by the software in the SSDCC at present.

The interrupt mechanisms are as follows:

Z80 interrupted by 1616:

The 1616 writes a byte with a zero in its least significant bit (LSB) to the SINTZ port; this causes pin 9 of U14 to go low. This signal should be connected to the Z80’s /INT or /NMI signal on the interrupt strapping block.

When the Z80 accepts the interrupt it should clear the interrupt signal by reading from its ZCLRINT address.

1616 interrupted by Z80:

The Z80 writes a byte with zero in the LSB to the ZINTS port. This sends pin 5 of IC14 low, holding the 1616 bus EIRQ1 signal low. The EIRQ1 signal must be connected to one of the 1616’s interrupt pins on the ‘INT lever strapping block on the 1616 main board. When the 1616 interrupt is taken the 1616 must clear the interrupt signal from within the interrupt service routine by reading from the SCLRINT port.

Signals beginning with a '/' (e.g. /DTACK) are active low. A signal is referred to as being ‘asserted’ when it is in its active state. For an active low signal this is the low state. A signal in its inactive state is referred to as being ‘negated'


Buying the 1616 and SSDCC:

The 1616 computer and SSDCC computer is available directly from its designers, Applix. Pricing is as follows:

1616 MINI KIT: The Mini Kit costs $239 and includes the 1616 printed circuit board, EPROMs, PALs, 30MHz oscillator, MC68000 CPU, SSASM and set of four manuals. This kit would suit people who can source their own components and are familiar with a project of this type.

1616 BASIC KIT: The Basic Kit costs $449 and includes all the components, connectors plus the contents of the Mini Kit. This kit would appeal to most people and works out significantly cheaper than purchasing a Mini Kit and sourcing the components commercially. It is important to note that this kit does not include the necessary components to implement the serial, centronics and user ports, as most people would regard these as optional. It also does not include IC sockets.

1616 I/O KIT: The I/O Kit costs $59.95 and includes all the necessary components to implement the serial, centronics and user ports.

1616 IC SOCKET KIT: A complete set of high quality IC sockets for the 1616 motherboard. $39.95.

KEYBOARD: This high quality, IBM AT style, XT keyboard costs $139.

POWER SUPPLY: This ‘Apple type’ switching power supply costs $69. A heavy duty supply is also available.

SSDCC KIT: The SSDCC Kit costs $249 and includes the SSDCC printed circuit board, connectors, and components. It does not include IC sockets, 1616 motherboard expansion socket(s). SCSI hard disk or serial port options.

SSDCC IC SOCKET KIT: A complete set of high quality IC sockets for the SSDCC. $19.95.

DISK DRIVE: 3.5" 80 track, double sided disk drive. Includes free cables when purchased the SSDCC. $239.

SSBASIC: A powerful BASIC interpreter for the 1616 costs $69. It is available on cassette or disk.

FULLY BUILT: Fully assembled and tested 1616 systems and versions of all 1616 kits are available. Contact Applix direct for more details.

Coming soon: Hi-Tech C compiler and cross compiler, 32 bit FORTH, 1616 box, User groups and more.


Advert: Eastern Computer Services


Applix-1617:
1616 Disk Drive (part 2)

Paul Berger

IN THE LAST article we covered the 1616 Disk Co-processor Card (SSDCC) hardware and low level communication between the 1616 and the SSDCC. This month we’ll discuss the software that makes it all hang together.

Device Drivers:

The function of a device driver is to allow the implementation of 1616/OS, a standard high level method of communicating with input/output devices. 1616/OS allows the use of installable device drivers for both block oriented devices such as floppy disks, hard disks and RAM disks, etc, and character devices such as the keyboard, serial ports, etc.

To read (or write) data from a block device, you must pass the following information to the 1616/OS block read/block write system calls:

	block number 
	block device number 
	starting memory address for the transfer

For example: From the above diagram, you can follow the path of communication between 1616/OS and a block device, such as the RAM disk. 1616/OS “asks” the RD/ block device driver to read (or write) a block. It is the function of RD/ driver to act on this instruction and forward the appropriate block from (or to) the RAM disk. On completion, the driver returns either a 0 (indicating everything is alright) or an error code.

A number of standard device drivers are located within the 1616’s motherboard ROMs. Most drivers communication with the physical device directly. The floppy disk driver is slightly different in that it communicates with the software contained in the SSDCC’s ROM which in turn deals with the actual disk drive.

For example: 1616/OS “asks” to read a block from the floppy disk (drive zero or drive one). The F0/ (FI/) driver tells the SSDCC ROM to get the block. The SSDCC gets the block (returning an error message if there was a problem) and passes the block to the F0/ driver. It in turn places the block in the appropriate memory location (as defined in the 1616/OS system call). In this way, the 68000 processor is relieved of the tasks of retrieving or writing information; these tasks are off loaded to the Z80 processor.

Using 1616/OS with multiple block devices

1616/OS is designed to support multiple block devices. Up to now the only block device has been the RAM disk, so the problem of specifying separate devices has not arisen. You now have available three different block devices:

	RD/		The RAM disk
	F0/		Floppy drive 0
	F1/		Floppy drive 1

The concept of a filename is extended to include a specification of the block device upon which the file is saved. This is done by pre-pending the block device driver’s name onto the normal filename. For example:

	F0/myfile	is a pathname for a file on floppy 0.
	rd/MF2		is a pathname for a file on the RAM disk.

You may specify a pathname of this type wherever a normal filename is expected. Files whose names are given without a block device indentifier are assumed to reside on the currently logged device.

The currently logged device is identified in the 1616/OS command line prompt. Initially this is the RAM disk (RD/). You can change the default block device by typing its identifier. For example, typing ‘RD/’ logs onto the RAM disk, ‘FI/’ logs onto floppy disk drive 1, etc. Floppies may be changed without any need to inform the system. Swapping floppies when files are still open will have predictably disastrous results.

Interprocessor Communciation

The interprocessor communication commands are detailed below. In this description data going from the Z80 to the 1616 is represented in angled brackets: <>.

Block read command: 01

unit, blockhigh, blocklow, <errorcode or 0>	<1024 bytes>

The 1616 writes a $01 to the command port after which it writes the following bytes to the data port: The unit number (0 for drive 0, 1 for drive 1), the block number (high byte first). After this is the physical read is performed by the Z80 and an error code is returned to the 1616. If the errorcode is zero the 1616 may read out the 1204 bytes of data.

A non-zero error code indicates that something went astray; an interpretation of the error code may be obtained with command 3 (see below).

Block write command: 02

unit, blockhigh, blocklow, data <errorcode or 0>

Similar to the block read command, except that the 1024 data bytes are sent to the Z80 and then the 1616 must wait for the physical write to complete before an error code is returned.

Error message command:

03 errorcode <string> <0>

The Z80 is sent the error code byte. The Z80 then sends down a string for human interpretation, terminated by a zero byte. The various strings have differing lengths.

Format command: 04

$B5 $7E unit ntracks skewtable <errorcode or 0>

To physically format a disk, the 1616 selects command 4 and writes the values $B5 and then $7E to the data latch as a check against accidental issuing of format commands. After this send the unit number (0 or 1), the number of tracks on the disk (usually 80 or 40), then the 10 byte sector skew table. Wait for an error code.

The sector skew table consists of two consecutive 5 byte tables. The first is for side 0 of the disk, the second for side 1. All sectors receive the same interleave pattern with this format command. The Z80 driver code expects sectors to be numbered from 1, not from 0. The skew table sent by the SSDDUTIL.EXEC utility program is:

Side 0	1, 4, 2, 5, 3
Side 1	3, 1, 4, 2, 5

Format type 2 command: 05



This format command permits interactive track-by-track formatting and sector skewing. Its use is not documented at this stage.

Read Z80 RAM command: 07

Z80addrh, Z80addrl, lengthh, lengthl <data>

This command permits the 1616 to read ‘LENGTH’ bytes of the Z80’s memory, starting from the specified Z80 address.

Write Z80 RAM command: 08

Z80addrh, Z80addrl, lengthh, lengthl, data

This command permits the 1616 to write ‘LENGTH’ bytes to the Z80’s memory, starting at the specified Z80 address.

Call a Z80 program command: 09

Z80addrh, Z80addrl

This command causes the Z80 to perform a ‘CALL’ instruction to the supplied address. Upon return from the called program the Z80 resumes normal operation.

Read Z80 ROM version command: 0A

<ROM version>

The Z80 returns a version byte for its current ROM.

O/S version byte 0B

Version byte

1616/OS tells the disk controller which version it is.

Set floppy disk step rate command: 0C

unit, rate)

This command is used to change the floppy disk(s) head step rate as follows:

Value	Step rate	used
0	2 ms.
1	3 ms.
2	6 ms. (default)
3	12 ms.

Error messages produced by the controller:

The disk controller software produces various error messages. Some are first detected by the 1616’s processor and the error messages for these are produced by the 1616/OS disk driver. Other errors are detected by the Z80 and are reported to the 1616 by means of an error code; when the 1616 encounters such an error code it fetches an English language interpretation of the error code from the Z80 and displays it.

Error Messages Produced By The Z80:

These refer to disk I/O failures of various forms.

Seek failure: A particular cylinder cannot be found; possibly because the disk drive has the incorrect number of tracks, or the disk is incorrectly formatted or poorly calibrated.

Drive busy(1), Drive busy(2): The WD1772 is permanently busy and cannot be interrupted out.

Write error(n): NN, Read error(n): NN

These refer to errors detected during physical reading and writing. The second number NN is a copy of the WD1772 status register at the time of detection of the error.

Format error: The WD1772 reported an error during disk formatting.

No RDY signal: The /RDY signal from the disk drive (pin 34 of the 34 way signal cable) does not go low. This may be due to a cabling problem, incorrect disk drive strap setting or the absence of the selected drive. Bad error number: This is the message string which the Z80 returns when asked to interpret an unimplemented error code.

Error Messages Produced By 1616/OS:

These messages are produced by that section of 1616/OS which handles the communication with the disk controller — the F0/ and FI/ block device drivers. They generally indicate that something untoward has happened in the communication between the two processors, such as the Z80 coming unstuck. Disk controller timeout: This means that the Z80 failed to respond in any way to a command which was sent to it. No TXRDY: Command - $NN When attempting to send the command NN to the controller’s command port the 1616 could not detect a true level on the STXRDY handshake signal, meaning that the Z80 is probably ignoring its command port.

Disk Organisation:

Note that a ‘block’ is a 1024 byte unit of data. Earlier versions of 1616/OS (versions 1.X) had 512 byte blocks.

The Root Block:

The organisation of data on 1616/OS block device volumes such as the RAM disk and the floppies is determined by fields in the device’s block zero, referred to as the ‘root block’. The root block contains seven significant 16 bit words organised as follows:

Offet	Name		Value for	Usage	
			800k disk	
0	nblocks		800		Number of 1024 bytes blocks on the device.
2	ssosver		$24		Version of 1616/08 under which the disk was initialised (ver 2.4).
4	bitmap		$01		The block where the device bitmap exists.
6	dirstart	$03		The block where the disk directory starts.
8	ndirblocks	$07		The number of blocks allocated for director) space.
10	removable	$01		Non-zero If the device has removable media.
12	bootblock	$02		The block to be loaded into memory and executed at reset time.

The Bitmap:

The bitmap is a table of up to 8192 bits (per block allocated to the bit map), each of which indicates whether or not the corresponding block is currently used. Bit 7 of byte 0 corresponds to block 0, etc.

The Bootblock:

The ‘bootblock’ field indicates whether or not the disk contains a boot block to be loaded at reset time and, if so, what block it is. Whenever the 1616 is reset (by powering on, pressing the reset switch or by ALT-control-R) the operating system performs all initialisation and then goes through all the block drivers in order (RD/ first, then F0/ then FI/ then any others) looking for a device with its ‘boot-block’ field in the root block non-zero. When such a device is found the indicated block is loaded into memory and executed at address $3CQ0 in the 1616.

The current level of the reset (0, 1 or 2) and the block driver number from which the system is booting is passed on the stack at 4(sp) and 8(sp) respectively. This allows the boot code to perform whatever level of initialisation is needed.

Note that the RAM disk may be used in this manner. Block 3 is reserved for booting, however it is not normally used. To use it, read in the root block, set the ‘bootblock’ field to 3, write out the root block again and then put your boot code in block 3.

If the disk in drive 0 (F0/) does not contain a boot program then the system will attempt to boot from disk 1 (FI/). If there is no second disk or if the second drive has no disk in it then the attempt to read from the second disk will fail, taking a few seconds to time out. It is preferable when disks are formatted that the standard do-nothing boot program ‘boot’ (supplied ondisk with the controller kit) be written out on the boot block.

The 1616 Disk Drive Utility Program:

The program ‘SSDUTIL.EXEC’ is supplied on disk with your disk controller kit. It performs the functions of disk formatting, directory initialisation (as described above) and setting up or removing a disk’s boot program.

There are three levels of disk preparation available with this program. The most basic level is to simply alter the disk’s boot sector program; you enter the name of the new boot program and this is written onto the disk. If no boot program is written onto the disk then the disk is skipped in the booting sequence.

In the next level of disk preparation you may ‘initialise’ a disk. This recreates the disks root block, bitmap and directory. All files are lost. The boot block must be rewritten after this. The next level of disk preparation involves a physical format of the disk, followed by initialisation, followed by the boot code setup.

The Directory:

The directory lies from the block indicated by ‘dirstart’ up to ‘dirstart + ndirblocks T. The 64 byte directory entry is as follows:

Offset	Data type	Usage
0-31	chars	Null terminated file name (see below).
32-39	bytes	File creation data (yy/mm/dd/hh/mm/ss).
40-41	short	Type of file (see below).
42-45	long	File load address.
46-49	long	File size in bytes.
50-51	short	When the file is altered this field is zeroed.
52-53	short	Block number of file block map.
54-63	unused	Reserved by Applix.

The structure of directory entries is upward compatable with earlier versions of 1616/OS. The only differences are:

The ‘file name’ field has changed slightly. Filenames may only contain the following characters: -./0-9@A-Z

This is only enforced upon creation of the file (in the ‘creat’ and ‘rename’ system calls) so that any files existing files which do not conform to this standard may be read, copied, executed or renamed.

Earlier versions of 1616/OS deleted files by putting a zero at the start of the ‘file name’ field (to indicate an unused directory entry) and freeing up the blocks used by that file in the bit map block. 1616/OS version 2.0 and greater now copies the first character of the file name to byte 31 (which is normally not used or zero if the file’s name is the maximum length) before zeroing it. This allows utility programs to undelete the file, as long as the blocks that were allocated to that file had not already been reallocated.

The ‘file type’ field (bytes 40-41) are no longer required. At present this field is zeroed and reserved. For compatibility reasons a ‘dummy’ file type must still be passed to the ‘creat’ system call.

The ‘backed up’ field (bytes 50-51) have a slightly different use. When a file is altered this field is zeroed. Disk archiving utilities may set this bit to indicate that the file has been backed up. Backed up files are indicated by an ‘A’ appearing in the first column of a directory listing.

Zsystem:

One of the major reasons for basing the SSDCC around the Z80 CPU was to one day allow the 1616 to run the CP/M operating system. Well, this day has happened!

We currently have a CP/M replacement (ZSYSTEM/ZC-PR3) up and running.

It makes use of the 1616’s memory for RAM disk and printer spooling whilst running CP/M, and the 1616 handles the video, keyboard , etc.

It really screams along! Due to the large number of ex-Microbee owners who have switched to the 1616, we have made the disk format under CP/M compatible with the Microbee’s.

Zsystem is written entirely in Z80 assembly language (CP/M is 8080 code only) and offers many benefits over CP/M including fixing bugs in CP/M 2.2 itself. Zsystem takes full advantage of the Z80 instruction set and is downward compatible with all CP/M software. The Zsystem will be discussed further in a future article. Suffice to say, Zsystem has significantly greater utility and functionality than MS-DOS or plain CP/M 2.2.