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