Plus D

Hardware

Technical info, well - the WD1772 is the controller chip (FDC) in the Disciple and Plus-D. I don't know if you can still find them. I do however have links to the Disciple/+D schematics directory at nvg and Ramsoft's pages with a complete technical document and Specification.

Programming the +D Interrupts

1. It loads the slowdown code which will get executed in the +D RAM to decimal address 12720, with the +D paged in.
2. It then does a POKE @16, 12720 to say where the code is, @16 being actual address 8192+16 in the +D. This turns it on.
3. It is deactivated by poking @16,8335 which looks like it is the default +D interrupt code.
4. Note: Use a normal RET (I think) at the end of the interrupt routine, not a RETN / RETI.

Disk structure/format and usage information

This information was originally posted to the Speccy newsgroup, comp.sys.sinclair by Simon Cooke (simonc@jumper.mcc.ac.uk).

Standard MGT format

10 sectors per track, 2 sides, 80 cylinders. 512 bytes per sector. Tracks are used linearly; track 0 on side 0 is followed by track 1, on side 0. Track 79 on side 0 is followed by track 0 on side 1.

Directory format

First 4 tracks (0-3) contain directory info. 2 entries per sector (each entry is 256 bytes long). This allows 80 files per disk, or more if proprietary alterations to the format are used.

First 11 bytes:

: (1) Attributes. bits 0-4 File type, or zero if erased
      ^^^^^^^^^^
I usually call this a directory byte - describes entry as shown in directory
listing.  Not to be confused with file byte (see below).  Not that it
matters much.


:                      6   Protected (read only)
:                      7   Hidden    (not shown) [I may have the functions 
: of bits 6 and 7 mixed up).

: (10) File name. If first byte of name is zero, and attributes byte is 
: zero, the directory after this point is unused, and does not/should not 
: be checked for more entries.

Not always... Some versions of G+DOS seem to continue checking, and when,
say you have a file containing all bad sectors at last directory entry
(no.80), it gets printed.

: The rest of the entry contains the bit mapped sector allocation for the 
: file (195 bytes) and file-specific information, including the length of 
: the file in sectors, and the start track and sector for the file. Tracks 
: on side 0 have bit 7 of the track number reset; tracks on side 1 have bit 
: 7 set. This convention is used throughout the system.

More info on this:

Considering offset 0 is first byte in 256 byte header, Offsets 0-10 as above (file type, name) followed by the following. All 2byte words are in low,high byte significance order.(lsb first)

offset 11/12=Number of data sectors in file (not including header)
offset 13=Track number of first data sector
offset 14=Sector number of first data sector
offset 15-210=Sector bitmap(1 bit for each sector, a 1 if used, 0 if not)
offset 211=file byte - same as tape format
		0=basic
		1=numerical array
		2=string array
		3=code
		(All attributes/directory byte types fit into one of these,
		 usually code if nothing else)
offset 212/213=file length in bytes
offset 214/215=file start address (only if code file or basic)
offset 216/217=autorun linenumber/number > 32767 for basic, or 65535 anyway
		for other file types???? Not too sure.
offset 218/219=0 (not sure what it's used for - maybe some BASIC parameter)
... ?????

If a byte(s) is not used, it is either 255/0 (can't remember)

The data area (tracks 4-79, 128-...) contains sectors of data. The sector pointed to by the directory area contains 510 bytes of data, plus a pointer to the next sector in the last two bytes of the sector (510, 511). If this pointer is null (ie both track and sector are zero), then this is the last sector of the file.

The first data sector of a file if it's one of the types used in tape also (eg basic/array/code) has 10 bytes as a consistency check, containing:

offset 0=file byte (as above)
offset 1/2=file length
offset 3/4=start address
offset 5/6=autorun/>32767 or 65535 ???? (as above)
offset 7/8=not sure (same as offset 218/219 above)
offset 9 (byte 10 in file)=first byte of data.

That should be everything. All filled in from my own experiments, and should be correct but don't go suing me if it's wrong cos I aint 100% sure.

Here's some more info on +D/Disciple techy details:

If the disk has an extended catalogue (used by Betados), then offset 255 (the last byte of the first header) in the first sector of the directory (track 0, sector 1) will contain the number of extra tracks used for the directory. So a 2 (decimal) would mean the usual 4 tracks(=80 files) + 2 tracks (10sectors*2per sector=20per track * 2=40) = 120 directory entries in total (if you understood that). Basically no. directory entries allowed is: 80 + 20 * , where n is the number in offset 255.

As said before, if bit 7 (value=128) is set then it's a hidden file, and if bit 6 (value=64) then it's protected (read-only) and cannot be saved over / erased.

Now for some useful calls. Not all are here, but that's cos I don't know them all. Try looking in "AlchNews" (disk/tapezine produced by Alchemist Research) issues around 14 for the info on direct ROM calls. AlchNews available at ftp.nvg.unit.no/pub/sinclair/ .../mags/... or at the AlchNews website.

Most disk operations can use the RST 8 : DEFB , although using ROM calls directly with +D/Disciple ROM switched in is quicker. Here's a list of the hookcodes.

UFIA is the User File Information Area, an area in the +D RAM used for information about open files, and to open a file you should make up a UFIA somewhere in conventional memory and call the relevant routines with IX pointing to it. I don't have the UFIA strucuture to hand, but I will type it up sometime.

Yet more hookcodes exist for Uni-Dos, but seeing as how I only know of a very few people with this DOS, I don't think it's worth me typing in. Unless you REALLY want me to (email me if so...) There are also those from 27 to 50, used for Microdrive. I could type those too...

When the drive is mentioned (eg sector routines), the value can be 1 or 2 or (I think) "*" ie 42 decimal for the last drive used.

There are also some variables in the +D/disciple RAM, at 8192 decimal onwards. RTFM (if you have one).

Well thats all I can be bothered to type, as I've said, there are some sections in AlchNews on it (issues 13/14/..??).

DISCLAIMER: If you do any experimenting, I *definitely* advise using a blank disk, or one with files you don't mind losing in case. And it might be a good idea to reboot the +D after testing things.

Uni-Dos

Uni-Dos is an extended ROM and system file that support more features than the standard Disciple or +D. There are a different ROM for Disciple or +D versions, but once you have it swapped (an easy-ish job) there is a single system file for each - thus the "Uni" part of the name.

Unfortunately, the changes also make it less compatible with software that uses +D or Disciple ROM calls directly although it should work for most (if not all) hookcode calls (RST 8:DEFB xx).

The Directory Bytes signifying the new filetypes are listed above with the others.

MB02 Disk Interface Hardware Page Speccy Techy Index

File last updated: 11 September 1998
Author: John Garner / john@breezer.demon.co.uk, many credits due to Simon Cooke