Archive

These items were removed from this FAQ as part of this update. If you feel these items should be restored, please contact us with an updated entry, and we'll include it in the next revision. Items listed in this section are included as a courtesy to their author(s) and will be removed after two subsequent revisions of the FAQ have taken place with no alteration to the entry shown. Entries marked as 'Expired' will remain in the archive, but will no longer be maintained.

Emulators - Acorn / RISC OS:
2 emulators for the Acorn / RISC OS platform appear to no longer be actively maintained and will be removed during later revisions.

MZX v1.10 - Pending Removal

Emulates: 48K ZX Spectrum.
Tape/Disk Formats: Loads and Saves .sna files.
Requirements: Unknown.
Created by: Graham Willmott.
Last updated: Unknown.
Speculator - Pending Removal

Emulates: 48K ZX Spectrum.
Tape/Disk Formats: Emulator specific.
Requirements: Unknown.
Created by: Dave Lawrence.
Last updated: Unknown.

Emulators - AmigaOS:
7 emulators for the AmigaOS appear to no longer be actively maintained and will be removed during later revisions.

CB Speccy v0.25b - Pending Removal

Emulates: 128K ZX Spectrum.
Tape/Disk Formats: Unknown.
Requirements: Unknown.
Created by: Code Busters.
Last updated: May 24th, 1999.
KGB v1.3 - Pending Removal

Emulates: Unknown.
Tape/Disk Formats: Unknown.
Requirements: Unknown.
Created by: KGB support BBS.
Last updated: September 30th, 1997.
Spectrum 128K Emulator v0.2 - Pending Removal

Emulates: 48K / 128K ZX Spectrums.
Tape/Disk Formats: Unknown.
Requirements: Unknown.
Created by: Alberto Ord��ez.
Last updated: March 24th, 1999.
Spectrum v1.7 - Pending Removal

Emulates: Unknown.
Tape/Disk Formats: Unknown.
Requirements: Unknown.
Created by: Peter McGavin.
Last updated: September 30th, 1997.
Speculator '97 - Pending Removal

Emulates: 48K ZX Spectrum, partial 128K emulation.
Tape/Disk Formats: .zx82 (Emulator specific), .kgb, .z80, .zx, .sp, .sna
Requirements: Kickstart 2.04 and 68020 or above.
Created by: William James.
Last updated: 1997 or before.
Speccylator v1.0 - Pending Removal

Emulates: 48K ZX Spectrum, partial 128K emulation.
Tape/Disk Formats: Loads and Saves .sna files.
Requirements: Kickstart 2.04.
Created by: Richard Carlsson.
Last updated: September 1996.
ZX-Spectrum v4.71 - Pending Removal

Emulates: Unknown.
Tape/Disk Formats: Unknown.
Requirements: Unknown.
Created by: Jeroen Kwast.
Last updated: September 30th, 1997.

Emulators - Atari ST/TT:
2 emulators for the Atari ST and TT appear to no longer be actively maintained and will be removed during later revisions.

Specci v2.07 - Pending Removal

Emulates: 48K Spectrum, ZX Interface I.
Tape/Disk Formats: Loads and Saves .sna and .snx files.
Requirements: Atari ST / TT.
Created by: Christian Gandler.
Last updated: Unknown.

Comments: Not full speed. All documentation in German.
Speccy - Pending Removal

Emulates: 48K Spectrum.
Tape/Disk Formats: Unknown.
Requirements: Unknown.
Created by: Hansjoerg Oppermann.
Last updated: Unknown.

Emulators - BeOS:
2 emulators for BeOS systems appear to no longer be actively maintained and will be removed during later revisions.

Beccy - Pending Removal

Emulates: Unknown.
Tape/Disk Formats: .tap and .sna files.
Requirements: BeOS x86.
Created by: Max Gontcharov.
Last updated: March 5th, 2000

Comments: Development preview (incomplete).
BeZX v1.1 - Pending Removal

Emulates: Unknown.
Tape/Disk Formats: .tap files.
Requirements: Unknown.
Created by: Jens Kilian.
Last updated: April 5th, 2000

Comments: A BeOS port of XZX-Pro. Available for PPC and x86 platforms. Source code is available.

Emulators - Macintosh:
1 emulator for the Macintosh appears to no longer be actively maintained and will be removed during later revisions.

MacSpeccy v1.1 - Pending Removal

Emulates: 48K ZX Spectrum.
Tape/Disk Formats: Loads .sna and .z80 files.
Hardware requirements: 68040.
Created by: Danny Keogan.
Last updated: 1997 or before.

Emulators - MSX:
1 emulator for the MSX platform appears to no longer be actively maintained and will be removed during later revisions.

ROMU6 v2.07 - Pending Removal

Emulates: 48K ZX Spectrum (BASIC only).
Tape/Disk Formats: Direct tape loading.
Requirements: MSX I / II with 128Kb Memory mapper.
Created by: Cesar Hernandez and Juan Hernandez.
Last updated: Unknown.

Emulators - Unix / Linux:
4 emulators available for Linux / UNIX systems appear to no longer be actively maintained and will be removed during later revisions.

SpectEmu v0.94 - Pending Removal

Emulates: 48K ZX Spectrum.
Tape/Disk Formats: .sna, .tzx, .tap and .z80 files.
Requirements: Linux or other UNIX OS. Color X11 server and/or SVGALIB console graphics library on Linux.
Created by: Miklos Szeredi.
Last updated: May 18th, 1998.
Spectrum - Pending Removal

Emulates: 48K ZX Spectrum.
Tape/Disk Formats: .sna and .z80 files.
Requirements: Intel 386 or above. Linux with XLib, sound card using /dev/audio at 8000 Hz.
Created by: Lozevis Jean-Francois.
Last updated: August 6th, 1996.
x128 v0.5 - Pending Removal

Emulates: 128K ZX Spectrum.
Tape/Disk Formats: .z80, .sna, .voc, .tap and .slt files.
Requirements: Unix based machine running X-Windows.
Created by: James McKay.
Last updated: July 1996
xz80 v0.1d - Pending Removal

Emulates: 48K ZX Spectrum.
Tape/Disk Formats: .sna, .tap and .z80 files.
Requirements: Tested on SunOS 4.1.1, HPUX 9.01, IRIX 5.2, AIX 3.2.5 and Linux 1.2.11.
Created by: Ian Collier.
Last updated: August 10th, 1995.

File Formats:
These entries were removed during this update. The formats are either emulator-specific, infrequently used, exceptionally well documented by their developers, or used primarily by emulators that have also been archived with this revision.

SP Format - Expired

   Offset   Size   Description
   ------------------------------------------------------------------------
   0        2      byte   "SP" (signature)
   2        2      word   Program length in bytes (normally 49152 for 48K
                          snaps, or 16384 for 16K snaps)
   4        2      word   Program location (normally 16384)
   6        8      word   BC,DE,HL,AF
   14       4      word   IX,IY
   18       8      word   BC',DE',HL',AF'
   26       2      byte   R,I
   28       4      word   SP,PC
   32       2      word   0 (reserved for future use)
   34       1      byte   Border color
   35       1      byte   0 (reserved for future use)
   36       2      word   Status word
   ------------------------------------------------------------------------

   Status word:
   Bit     Description
   ------------------------------------------------------------------------
   15-8    Reserved for future use
    7-6    Reserved for internal use (0)
      5    Flash: 0=INK/1=PAPER
      4    Interrupt pending for execution
      3    If 1, IM 0; if 0, bit 1 determines interrupt mode
           (Spectrum v 0.99e had this behaviour reversed, and this
           bit was not used in versions previous to v 0.99e)
      2    IFF2 (internal use)
      1    Interrupt Mode (if bit 3 reset): 0=>IM1, 1=>IM2
      0    IFF1: 0=DI/1=EI

ZX Format - Expired
All values stored in big-endian format; on 680x0 the most significant byte goes first.

   Offset   Size   Description
   ------------------------------------------------------------------------
   0        49284  bytes  RAM dump 16252..65535
   49284    132    bytes  unused, make 0
   49416    10     word   10,10,4,1,1 (different settings)
   49426    1      byte   InterruptStatus (0=DI/1=EI)
   49427    2      byte   0,3
   49429    1      byte   ColorMode (0=BW/1=Color)
   49430    4      long   0
   49434    16     word   BC,BC',DE,DE',HL,HL',IX,IY
   49450    2      byte   I,R
   49452    2      word   0
   49454    8      byte   0,A',0,A,0,F',0,F
   49462    8      word   0,PC,0,SP
   49470    2      word   SoundMode (0=Simple/1=Pitch/2=RomOnly)
   49472    2      word   HaltMode  (0=NoHalt/1=Halt)
   49474    2      word   IntMode   (-1=IM0/0=IM1/1=IM2)
   49476    10     bytes  unused, make 0
   ------------------------------------------------------------------------
   Total: 49486 bytes

ZX82 Format - Pending Removal
Amiga Speculator has its own file format called ZX82 format because it contains a file identifier in the first four bytes consisting of the ASCII characters "ZX82". The format has a 12 byte header which contains the normal Spectrum type file information like length, type, start etc. as well as a compression flag which is set if the file is byte run compressed. Snapshot files have a further 32 bytes of register values and border colour information. Listed below are the offset definitions taken from the Speculator source code in case you need to write a conversion utility. All registers and other values are in Motorola format (High, Low). I have defined everything in bytes to avoid any possible confusion.

* The Standard ZX82 Header
ZX_ID           rs.l    1       Identifier for a Speculator file "ZX82"
ZX_Type         rs.b    1       0:BASIC 1:Numeric 2:String 3:Code 4:Snapshot
ZX_Comp         rs.b    1       Is data block byte run compressed ? $00=No $FF=Yes
ZX_Length_H     rs.b    1       File length up to 64k (ELINE-PROG for BASIC)
ZX_Length_L     rs.b    1
ZX_Start_H      rs.b    1       Start address for code (AUTOSTART for BASIC)
ZX_Start_L      rs.b    1
ZX_ProgLen_H    rs.b    1       Array name (VARS-PROG for BASIC)
ZX_ProgLen_L    rs.b    1
ZX_ZXHdrLen     rs.b    0       Length of ZX file header
ZX_ZXData       rs.b    0       Start of Data block for standard ZX file

* The extended Snapshot ZX82 Header
ZX_Border       rs.b    1       Border colour
ZX_IntMode      rs.b    1       IntMode over-ride (0=use i_reg, 1=im1 and 2=im2)
ZX_Registers    rs.b    0       Z80 register values for Snapshot Files
ZX_iy_H_reg     rs.b    1       (High then Low i.e. Motorola format)
ZX_iy_L_reg     rs.b    1
ZX_ix_H_reg     rs.b    1
ZX_ix_L_reg     rs.b    1
ZX_de_H_reg     rs.b    1
ZX_de_L_reg     rs.b    1
ZX_bc_H_reg     rs.b    1
ZX_bc_L_reg     rs.b    1
ZX_hl_H_reg     rs.b    1
ZX_hl_L_reg     rs.b    1
ZX_af_H_reg     rs.b    1
ZX_af_L_reg     rs.b    1
ZX_de_H_alt     rs.b    1
ZX_de_L_alt     rs.b    1
ZX_bc_H_alt     rs.b    1
ZX_bc_L_alt     rs.b    1
ZX_hl_H_alt     rs.b    1
ZX_hl_L_alt     rs.b    1
ZX_af_H_alt     rs.b    1
ZX_af_L_alt     rs.b    1
ZX_sp_H_reg     rs.b    1
ZX_sp_L_reg     rs.b    1
ZX_if_H_reg     rs.b    1
ZX_if_L_reg     rs.b    1
ZX_rf_H_reg     rs.b    1
ZX_rf_L_reg     rs.b    1
ZX_pc_H_reg     rs.b    1
ZX_pc_L_reg     rs.b    1
ZX_SnpHdrLen    rs.b    0       Length of Snapshot file header
ZX_SnpData      rs.b    65496   Start of data block for Snapshot type file

The ZX_Type field is derived from the MGT disciple directory MGT_Type-1, so further file types may be supported in this way in the future.

The compression used is the standard byte run compression as used by ILBM IFF files. The whole 48k data block is compressed as if it were one long row. See Amiga ROM Kernel Reference Manual: Devices Third Edition, Appendix A - IFF Specification (P347), Appendix C - Example Packer C code (P538).

ITM and PAN Formats - Pending Removal
These tape formats, used by the MSX Spectrum emulator, start with a two byte header; the first byte specifies the number of tape blocks in this file, and the second specifies which block has some data contained in the supplementary .pan file. (This byte is zero if there is no data in the .pan file).

A sequence of tape blocks then follows; each block has a four byte header. The first byte of the header is the LSB of the length of the block, excluding the four byte header), the second byte is the MSB of the length, the third byte is unknown (the high nibble is always 0110), and the fourth byte is the block number (the first block is number 1). The data then follows; this is exactly as would be produced by the Spectrum's ROM routine, apart from the fact that there is no checksum byte at the end.

For the block which is marked in the second byte of the file as having data in the .pan file, the actual block length is 12295 (0x3007) bytes longer than specified in the .itm file. The final 12295 bytes of the data block are stored as the first 12295 bytes of the .pan file.

Finally, note that both the .itm and .pan files have apparently random bytes at the end. A converter for converting .itm/.pan files to .tap format is available, however.
NET Format - Pending Removal
NET files are used by Warajevo to emulate the Interface I Network, which allowed up to 8 different Spectrums to communicate.

The format of the network files is very simple. They have 260 bytes (or more, but excess bytes will not be used), with the following structure:
```
   Byte    Length  Description

     0       2     Package ID (used for fast checking whether content of the
                   Net file is changed)
     2       2     Reserved; not yet used
     4     256     Content of the package
```
PAL Format - Pending Removal
The WARAJEVO.PAL file is used by Warajevo to set its colour palette. They have a very simple 48-byte format: the first three bytes correspond to R, G and B value for color 0, next three bytes correspond to RGB for color 1, etc; the first 24 bytes are related to BRIGHT 0 colors, and next 24 bytes are related to BRIGHT 1. All values must be in the range 0-63.
TAP (Warajevo) Format - Pending Removal
Warajevo's tape files (TAP) has the format as follows:

At the beginning of the file there are four bytes with the pointer to the first block. Then follow four bytes with pointer to the last block. The next four bytes contain #FFFFFFFF. So, empty tape has a format:
```
#04 #00 #00 #00 #00 #00 #00 #00 #FF #FF #FF #FF
```
Sequence #00 #00 #00 #00 #FF #FF #FF #FF is, in fact, a EOF (end of file) marker. Every block contains following:
- 4 bytes, a pointer to the previous block, which is 0 for first block;
- 4 bytes, a pointer to the next block or to the EOF marker for last block;
- 2 bytes, block size;
- 1 byte, a flag byte;
- the data bytes.
If the block size is 65534, it is a block which contains tone record samples. The structure is:
- 4 bytes, a pointer to the previous block, which is 0 for first block.
- 4 bytes, pointer to the next block, or to the EOF marker for last block.
- 2 bytes, value 65534.
- 1 byte, a status byte; bits B0-B2 in this byte contain informations which tell how many bits in the last byte in the block are used (number of used bits is, in fact, number stored in B0-B2 increased by one), bits B3-B4 contain information about the sampling frequency (with meaning 00 - 15000 Hz, 01 - 22050 Hz, 10 - 30303 Hz, 11 - 44100 Hz), and bits B5-B7 are not used.
- 2 bytes, decompressed (logical) block size.
- 2 bytes, compressed (psychical) block size; if these 2 lengths are equal, the block is not compressed.
- 2 bytes, signature length (internal, for compressed blocks).
- the samples (binary), 8 samples are packed into one byte (starting from B7 to B0); whole package of such sample bytes may be either compressed or uncompressed (the last byte need not contain all 8 bits).
If bytes 9, 10, 11 and 12 into a TAP file are not equal to #FF, this is TAP file which is not in native Warajevo TAP format. In this case, Warajevo assumes Z80's .tap format.

If the block size is 65535, it is a compressed block. It looks like:
- 4 bytes, a pointer to the previous block;
- 4 bytes, pointer to next block;
- 2 bytes, 65535;
- 1 byte, a flag byte;
- 2 bytes, decompressed size;
- 2 bytes, compressed size;
- 2 bytes, signature length (internal);
- the data bytes.
Signatures are important for the imploding algorithm used by Warajevo. This algorithm, when decompressing, copies bytes from the source file, or returns for a few bytes, and copies some bytes from a destination file.

The explanation of compressed data bytes is rather complex. We used format similar to those in PKLITE, but unlike PKLITE where signature bytes are mixed with data bytes, authors divided them in two parts, for easier debugging.

Remember elements of Imploding (LZ77) algorithm. It depends on copying of some byte sequences. For example:
```
3D 18 2E 42 3D 18 2E 15 42 3D 19
```
will be encoded as:
```
3D 18 2E 42 [return for 4 bytes and copy 3 bytes]
   15 [return for 5,copy 2] 19
```
The archivers differs on way of encoding of this special 'Return for...' code.

In Warajevo compressed format, there are two parts: signatures and data. In our example coding of signatures will be (binary):
```
00001001 010100xx
```
while data bytes will be:
```
3D 18 2E 42 04 15 05 19
```
The signatures are finite automat that describe what to do with data bytes. If the bit is 0, this is simple data byte, if the bit is 1 this is code for returning.

In our example, four zeros in signatures means that four bytes can be simply copied (3D, 18, 2E, 42) to output buffer. The next bit is 1. This means: Return for xxxx bytes and copy yyyy.

The value of yyyy (size of string to be copied) is in signatures if less than 10 or in signatures and data bytes if >= 10.

The size depends on next 2-4 signature bits:
```
    010: size=2
     00: size=3
    100: size=4
    101: size=5
    011: size>=10
   1100: size=6
   1101: size=7
   1110: size=8
   1111: size=9
```
If size is greater or equal than 10, the next data byte contains actual size-10. That means: maximal string size is 265.

The next data byte determine lower byte of distance of string to be copied (lower byte of xxxx). If size=2, higher bit is always zero (so for this size distance can be maximally 255). If size differs from 2 the next 1-6 signature bits determine higher byte:
```
        1: higher byte=0
     0000: higher byte=1
     0001: higher byte=2
    00100: higher byte=3
    00101: higher byte=4
    00110: higher byte=5
    00111: higher byte=6
   01nnnn: higher byte=7+nnnn
```
Experiment with some ASCII text compressed. There is algorithm in Pascal for decompressing to understand the format:
```
procedure decompress_b;
label
  lb,b0,b1,b11,b01,b10,b110,b111,b010,b00,b100,b101,b011,b1100,
  b1101,b1110,b1111,v,v0,v1,v00,v01,v000,v001,v0000,v0001,v00100,v00101,
  v00110,v00111,v0010,v0011,izlaz;

var
  b,put:byte;
  bytes,return_for,i,auxilary:word;
  finished:Boolean;
begin
  OutputBufEnd:=0;
  CurrPosInputBuffer:=SignatureSize+1;
  CurrentSignaturePosition:=0;
  CurrentSignature:=InputBuffer^[CurrentSignaturePosition];
  BitCounter:=0;
  if duzina_ul_dek=0 then finished:=true else finished:=false;
  while not finished do begin
    if nextbit=0 then begin
      TakeFromInputBuffer(b,finished);
      PutToOutputBuffer(b);
    end
     else begin
       I know, it is  goto, but more readable than
        nested if then else sequences
        lb: if nextbit=0 then goto b0 else goto b1;
        b0: if nextbit=0 then goto b00 else goto b01;
        b1: if nextbit=0 then goto b10 else goto b11;
        b11: if nextbit=0 then goto b110 else goto b111;
        b01: if nextbit=0 then goto b010 else goto b011;
        b10: if nextbit=0 then goto b100 else goto b101;
        b110: if nextbit=0 then goto b1100 else goto b1101;
        b111: if nextbit=0 then goto b1110 else goto b1111;
        b010: bytes:=2;
          TakeFromInputBuffer(b,finished);
          return_for:=b;
          goto izlaz;
        b00: bytes:=3;goto v;
        b100: bytes:=4;goto v;
        b101: bytes:=5;goto v;
        b011: TakeFromInputBuffer(b,finished);
          bytes:=b+10;goto v;
        b1100: bytes:=6;goto v;
        b1101: bytes:=7;goto v;
        b1110: bytes:=8;goto v;
        b1111: bytes:=9;goto v;
        v: TakeFromInputBuffer(b,finished);
        return_for:=b;
        if nextbit=0 then goto v0 else goto v1;
        v0: if nextbit=0 then goto v00 else goto v01;
        v1:goto izlaz;
        v00: if nextbit=0 then goto v000 else goto v001;
        v01: Auxiliary:=7;
          if nextbit=1 then Auxiliary:=Auxiliary+8;
          if nextbit=1 then Auxiliary:=Auxiliary+4;
          if nextbit=1 then Auxiliary:=Auxiliary+2;
          if nextbit=1 then Auxiliary:=Auxiliary+1;
          return_for:=return_for+256*Auxiliary;
          goto izlaz;
        v000: if nextbit=0 then goto v0000 else goto v0001;
        v001: if nextbit=0 then goto v0010 else goto v0011;
        v0010: if nextbit=0 then goto v00100 else goto v00101;
        v0011: if nextbit=0 then goto v00110 else goto v00111;
        v0000: return_for:=return_for+1*256;goto izlaz;
        v0001: return_for:=return_for+2*256;goto izlaz;
        v00100: return_for:=return_for+3*256;goto izlaz;
        v00101: return_for:=return_for+4*256;goto izlaz;
        v00110: return_for:=return_for+5*256;goto izlaz;
        v00111: return_for:=return_for+6*256;goto izlaz;
        izlaz:
        for i:=1 to bytes do begin
          put:=OutputBuffer^[OutputBufEnd-return_for+1];
          PutToOutputBuffer(put)
        end;
     end else
  end while
end; decompress_b
```

comp.sys.sinclair FAQ

FAQ Archive