Allow nullary BinaryInFile::read() in Lua

[jpcrr.git] / manual.txt

JPC-RR: User's manual

1 Licence

JPC-RR is licenced under GNU GPL v2. See file “LICENSE”

2 Getting started

2.1 Prerequisites

To get started, you need BIOS image, VGABIOS image and DOS boot 
floppy and JDK for Java 6 standard edition (later versions should 
they appear should also work). Note: JRE is not enough. 

Note that to play back recorded movies, you need exact same 
version of BIOS image, VGABIOS image and DOS boot floppy as was 
used when making the movie (in addition to exact same versions of 
other needed media).

See compile.sh. The stuff in streamtools is only needed for 
recording videos.

2.2 Compiling

See compile.sh. The streamtools stuff is only needed for dumping 
videos.

2.3 Getting started

First you need to get and make some important images. Obtain BIOS 
image, VGABIOS image and DOS boot floppy from somewhere and do:

mkdir library

java ImageMaker --BIOS library/BIOS <bios image file>

java ImageMaker --BIOS library/VGABIOS <vgabios image file>

java ImageMaker --floppy1440 library/DOSfloppy <dos floppy name>

This makes loadable images out of what you obtained. Most DOS 
boot floppies are 1440KiB in size (if yours isn't change that 
floppy1440 part). You also might want to make some game images:

java ImageMaker --HDD=128,63,16 library/somegame <game 
installation directory>

This makes ~128MB HDD image out of installation directory.

2.4 Running emulator

There is premade autoexec script called assemble.bat that has 
fairly reasonable defaults. To use it:

java JPCApplication -library library -autoexec assemble.bat

The “-library library” specifies that contents of directory 
'library' are to be used as library. The script pops up settings 
for new emulated PC (if you want to load savestate, click 
cancel). Select BIOS and VGABIOS for BIOS and VGABIOS image (they 
should be already selected), DOSfloppy for fda (boot device 
should be set to fda) and game image as some HD drive 

2.5 Bootup tips

• Putting the game as hdd causes boot to be bit faster.

• Some BIOS versions have “press F12 to select boot device”. Hit 
  <enter> from emulated keyboard and that prompt will go away in 
  about half emulated second (it stays several emulated seconds 
  otherwise). 

• If game doesn't need lots of memory, hitting F5 to skip 
  intialization files is fastest. If it does need more memory, 
  run config.sys commands but not autoexec.bat. 

• Some DOS disks have DOSIDLE with them, don't use it as it 
  messes badly with emulator.

3 Making JPC-RR format images from raw images

Due to various factors, JPC-RR can't use raw image files directly 
but requires its own image format. There is tool called 
ImageMaker that can make JPC-RR images from raw images. Each 
image has format, ID an name. Format and name are specified when 
making image. ID is automatically calculated from format and 
contents. Name does not affect the ID but is purely for convience 
so one doesn't have to specify long image IDs manually.

3.1 Syntax

The syntax for ImageMaker when making images is:

$ java ImageMaker <format> [<options>...] <destination> <source> 
<name>

<destination> is file name for JPC-RR format image to write. 
<source> is either name of regular file (raw image file) or name 
of directory tree with files (supported for making floppy or hard 
disk images only). In case of directory tree, the files are 
layout deterministically to disk, so the ID will always be the 
same for given geometry and type. <name> is name to give to disk. 
<format> is one of:

--BIOS BIOS image (note: VGABIOS is also of this type).

--CDROM CD-ROM image.

--HDD=cylinders,sectors,heads Hard disk with specified geometry.

--floppy=tracks,sectors,sides Floppy disk with specified 
geometry.

--floppy160 160KiB floppy (40 tracks, 8 sectors, Single sided).

--floppy180 180KiB floppy (40 tracks, 9 sectors, Single sided).

--floppy320 320KiB floppy (40 tracks, 8 sectors, Double sided).

--floppy360 360KiB floppy (40 tracks, 9 sectors, Double sided).

--floppy410 410KiB floppy (41 tracks, 10 sectors, Double sided).

--floppy420 420KiB floppy (42 tracks, 10 sectors, Double sided).

--floppy720 720KiB floppy (80 tracks, 9 sectors, Double sided).

--floppy800 800KiB floppy (80 tracks, 10 sectors, Double sided).

--floppy820 820KiB floppy (82 tracks, 10 sectors, Double sided).

--floppy830 830KiB floppy (83 tracks, 10 sectors, Double sided).

--floppy880 880KiB floppy (80 tracks, 11 sectors, Double sided).

--floppy1040 1040KiB floppy (80 tracks, 13 sectors, Double 
sided).

--floppy1120 1120KiB floppy (80 tracks, 14 sectors, Double 
sided).

--floppy1200 1200KiB floppy (80 tracks, 15 sectors, Double 
sided).

--floppy1440 1440KiB floppy (80 tracks, 18 sectors, Double 
sided).

--floppy1476 1476KiB floppy (82 tracks, 18 sectors, Double 
sided).

--floppy1494 1494KiB floppy (83 tracks, 18 sectors, Double 
sided).

--floppy1600 1600KiB floppy (80 tracks, 20 sectors, Double 
sided).

--floppy1680 1680KiB floppy (80 tracks, 21 sectors, Double 
sided).

--floppy1722 1722KiB floppy (82 tracks, 21 sectors, Double 
sided).

--floppy1743 1743KiB floppy (83 tracks, 21 sectors, Double 
sided).

--floppy1760 1760KiB floppy (80 tracks, 22 sectors, Double 
sided).

--floppy1840 1840KiB floppy (80 tracks, 23 sectors, Double 
sided).

--floppy1920 1920KiB floppy (80 tracks, 24 sectors, Double 
sided).

--floppy2880 2880KiB floppy (80 tracks, 36 sectors, Double 
sided).

--floppy3120 3120KiB floppy (80 tracks, 39 sectors, Double 
sided).

--floppy3200 3200KiB floppy (80 tracks, 40 sectors, Double 
sided).

--floppy3520 3520KiB floppy (80 tracks, 44 sectors, Double 
sided).

--floppy3840 3840KiB floppy (80 tracks, 48 sectors, Double 
sided).

3.2 Notes

• If making image from directory, the names of the files must 
  conform to FAT naming restrictions (8+3 character names, no 
  spaces, etc). Avoid filenames with non-ASCII characters. 

• The DOS limit of 112 or 224 files for floppies does not apply 
  to images created from directory trees. The minimum limit value 
  used is 512. If even that isn't enough, the limit is 
  automatically increased to fit all the needed directory 
  entries.

• Making boot disks from tree does NOT work. Even if you got 
  system boot files there, it still won't work.

• Only floppy disks and hard drives can be made from directory 
  trees. BIOS images and CDROM images require image file.

• Avoid floppies with custom geometry (floppy geometry does 
  affect disk ID). Disks with over 63 sectors per track don't 
  work with DOS. Wheither disks with over 127 tracks per side 
  work with DOS is unknown. Also avoid 1024-tracks per side HDDs.

• The geometry limits are: 2-1024 tracks per side for HDD, 1-256 
  tracks per side for floppy. 1-63 sectors per track for HDD, 
  1-255 sectors per track for floppy. 1-16 sides for HDD, 1 or 2 
  sides for floppy. This gives size limit of 65280KiB for floppy 
  disks (but note the DOS limit!) and 516096KiB for HDDs.

• There are multiple image file contents that represent the same 
  image. The one with smallest size is picked when creating 
  image.

• Note: Although the IDs are 128 bits long, they are not MD5 
  hashes. 

3.3 Other options

--volumelabel=label Give specified volume label (affects ID). 
Only meaningful when making image out of directory tree. Default 
is no volume label.

--timestamp=YYYYMMDDHHMMSS Give specified timestamp for files 
(affects ID). Only meaningful when making image out of directory 
tree. The default timestamp is 19900101T000000Z.

3.4 Image information

When invoked as:

$ java ImageMaker <imagefile>

Variety of information about image is displayed (especially for 
floppies/HDDs). Two important fields are calculated and claimed 
disk ID. They should be the same. If they are not, then the image 
file is corrupt (sadly, imagemaker has bugs and bugs that cause 
it to write corrupt images have been seen).

3.5 Advanced: The disk ID algorithm

The disk ID is calculated as:

Skein-256-128-deprecated(<typecode>|<geometry>|<image>)

Where Skein-256-128-deprecated is Skein hash function with 
256-bit internal state and 128-bit output using the deprecated 
rotation constants (as specified in Skein hash function reference 
documentation versions 1.0 and 1.1). The <image> is the whole 
image, including parts not stored in image file. The reason for 
keeping using the deprecated constants are:

• Changing the constants would change the IDs, which would 
  invalidate existing images

• This is not about cryptographic security

• The new constants don't improve security that much anyway.

3.5.1 Floppies and HDDs

Floppies have <typecode> value 0 (single byte) and HDDs have 1 
(single byte). <geometry> is as follows (this is exactly the same 
form as it appears in image header):

Byte 0 bits 0-1: Bits 8-9 of track count per side - 1.

Byte 0 bits 2-5: Head count - 1.

Byte 0 bits 6-7: Reserved, must be 0.

Byte 1: Bits 0-7 of track count per side - 1.

Byte 2: Sector count per track - 1.

3.5.2 CD-ROM and BIOS images

CD-ROMs have <typecode> value 2 (single byte) and BIOS images 
have 3 (single byte). <geometry> is blank.

3.6 Advanced: Disk Image format

The disk image consists of following parts:

• Magic

• Disk ID

• Type code

• Disk name length

• Disk name

• type-specific geometry/size data

• Actual image data

3.6.1 Magic

Magic in disk image files is following 5 bytes: “IMAGE”

3.6.2 Disk ID

Disk ID is given as 16 bytes, encoding the 128-bit disk ID.

3.6.3 Type code

Type code is single byte. 0 for floppies, 1 for HDDs, 2 for 
CD-ROMs and 3 for BIOS images. Other values are reserved.

3.6.4 Comment length

Disk comment length is given as two-byte big-endian value. New 
images should have 0 here.

3.6.5 Disk coment

Ignored. Comment field is there for backward compatiblity. 
Comment length gives length of this field in bytes.

3.6.6 Type-specific geometry/size data (floppies and HDDs)

Floppies and HDDs have 3-byte geometry data:

Byte 0 bits 0-1: Bits 8-9 of track count per side - 1.

Byte 0 bits 2-5: Head count - 1.

Byte 0 bits 6-7: Reserved, must be 0.

Byte 1: Bits 0-7 of track count per side - 1.

Byte 2: Sector count per track - 1.

3.6.7 Type specific-geometry/size data (CD-ROMs)

CD-ROMs have 4-byte big-endian sector (512 bytes!) count.

3.6.8 Type specific-geometry/size data (BIOS images)

BIOS images have 4-byte big-endian byte (not sector or block) 
count.

3.6.9 Actual image data (floppy/HDD)

Floppy or HDD imagedata consists of following subparts:

• Storage method

• Sectors present

• Image data header

• Image data

Storage method is single byte. Sectors present gives number of 
last nonzero sector + 1 (zero if image is all zeroes)

3.6.10 Floppy/HDD storage method 0: Raw storage

This storage method has empty header. Image data is raw dump of 
first sectors present sectors.

3.6.11 Floppy/HDD storage method 1: Sectormap

Image data header contains bitfield with just enough bytes to 
have one bit per present sector. The order of bits is such that 
number of bit corresponding to each sector in byte is sector 
number modulo 8 and byte number is floor of sector number divided 
by 8 when sector numbers are counted from zero. If bit 
corresponding to sector is set, then the sector is present in 
image data, otherwise it is absent and assumed to be all-zeroes.

Image data contains dumps of all present sectors in order of 
increasing sector number.

3.6.12 Floppy/HDD storage method 2: Extent first sector zero

Image data is empty as storage-specific data is mangled with 
image data. The image data alternates between blocks encoding 
zero sectors and blocks encoding nonzero sectors. The first block 
encodes zero sectors. 

Block encoding zero sectors consist of single 1-4 byte 
little-endian value encoding number of sectors in block - 1. 
Number of bytes is determined by sectors present value. It is 1 
for 1-256 sectors, 2 for 257-65536, 3 for 65537-16777216 and 4 
for more than 16777216. All sectors in block are filled with 
zeroes and are not stored.

Block encoding nonzero sectors has same block count as zero 
sector block but is followed by the sectors stored raw.

3.6.13 Floppy/HDD storage method 3: Extent first sector nonzero

Same as storage method 2 but first block is nonzero sector block.

3.6.14 Actual image data (CD-ROMs and BIOS images)

These store image data raw. The amount of data is specified by 
sector/byte count.

4 Utilities

4.1 org.jpc.utils.RAWToPNG

Invoked as:

$ java org.jpc.utils.RAWToPNG <input> <outputprefix>

Reads RAW video data from <input> (may be named pipe) and dumps 
PNG frames received as '<outputprefix><runningcount>.png'. Also 
saves '<outputprefix>.timing' which contains frame timing data 
(each line consists of time in nanoseconds, space, and filename).

5 The actual emulator

The actual emulator is invoked as:

$ java JPCApplication <options>...

The valid options are:

-library <library> Use the specified directory when searching for 
images (can only be specified once).

-autoexec <script> Execute contents of specified file as commands 
when starting up.

5.1 Command line

When emulator is started, command line comes up. Following 
commands are known:

• 'exit': exit immediately

• 'load <plugin>': Load plugin (no arguments)

• 'load <plugin>(<arguments>)': load plugin with arguments.

• 'command <command> [<arguments>...]': Invoke command via 
  external command interface.

When one gets command line, its useful to load some plugins. See 
section about plugins. Note: Load runner plugin 
(PCControl/PCRunner and so) last, as some runners like to start 
PC immediately.

5.2 PC settings dialog notes

• CPU divider base frequency before division is 1GHz.

• Images can be specified by name or by ID. Name is relative to 
  library directory. If the image is in subdirectory of image 
  directory, the directory separator is is '/' regardless of what 
  the host OS uses.

• CD-ROM and hdc are mutually exclusive

• Modules is comma-seperated list of modules to load. To pass 
  arguments to some modules, enclose the arguments in (). Same 
  module can be specified twice only if parameters differ.

• FPU emulator is specified by class name. If core has built-in 
  FPU emulator, then this should be left blank. Without 
  core-builtin FPU emulator, blank value means “no fpu”.

• Setting boot device doesn't work with some BIOS versions. Those 
  versions prompt the boot device anyway.

5.3 Audio output channels

PC can have one or more audio output channels. The name of audio 
output associated with PC speaker is: 
'org.jpc.emulator.peripheral.PCSpeaker-0'. Modules that have 
audio outputs get channel names of form <classname>-<sequential>, 
where <classname> is name of main module class and sequential is 
number starting from zero. Note that same module can have 
multiple output channels. If multiple modules of same class 
request audio outputs, the <sequential> values of subsequent 
module start where previous left off.

5.4 Plugins

Plugins actually execute the tasks of the emulator. They can be 
loaded using “load <plugin>” or 'load <plugin>(<arguments>)” from 
command line.

Different Plugins using the same output (like running PCMonitor 
and PNGDumper) should not conflict because connector output hold 
locking is desinged to handle multiple readers.

If no plugin used requires GUI, then the emulator can be run 
without having GUI available.

5.4.1 plugin: org.jpc.plugins.PCControl

No arguments, requires and uses GUI.

Runs the PC emulator core. Has capability to start/stop 
emulation, breakpoint after certain time or start/end of VGA 
vertical retrace. Also can create, savestate and loadstate PC 
emulation. Memory dumping is supported. 

5.4.2 plugin: org.jpc.plugins.PCRunner

Takes 'movie=<file>' as argument and optionally 'stoptime=<time>' 
Does not require nor use GUI.

Loads PC from savestate and just runs it. CTRL+C to quit. Also 
automatically quits once stoptime is reached.

5.4.3 plugin: org.jpc.plugins.PCMonitor

No arguments, requires and uses GUI.

VGA monitor for emulated PC.

5.4.4 plugin: org.jpc.plugins.VirtualKeyboard

No arguments, requires and uses GUI.

On-screen keyboard for emulated PC.

5.4.5 plugin: org.jpc.plugins.PCStartStopTest

No arguments, requires and uses GUI.

Small plugin testing remote PC start/stop. Also supports sending 
some common keypresses.

5.4.6 plugin: org.jpc.plugins.RAWVideoDumper

Takes 'rawoutput=<file>' as argument. Does not require nor use 
GUI.

Dumps all generated frames to RAW file <file>. Rawoutput is 
required. The raw file consists of concatenation of zlib streams. 
The uncompressed stream is concatenation of time skips (FFh FFh 
FFh FFh), each acting as time offset of 2^32-1 nanoseconds and 
saved frames. The saved frame has time offset in nanoseconds (big 
endian) as first four bytes (must be at most 2^32-2, as 2^32-1 is 
reserved for time skip). The next two bytes are big-endian width, 
next two big-endian height. Finally frame has 4 * width * height 
bytes of data that encodes pixels using 4 bytes per pixel, in 
left-to-right, up-to-down order. Byte 0 of each pixel is 
reserved, byte 1 is the red channel, byte 2 is green channel and 
byte 3 is blue channel.

Dumping to pipe is supported.

5.4.7 plugin: org.jpc.plugins.RAWAudioDumper

Takes 'src=<name of audio output channel>', 
'file=<output-filename>' and 'offset=<offset>' as arguments, 
separated by ','. Does not require nor use GUI.

Dumps output from specified audio output channel (src, mandatory) 
to RAW-format file (file, mandatory). The resulting file consists 
of records, 8 bytes each. Each record has three fields. First 4 
byte unsinged little endian timedelta value (in nanoseconds), 
then 2 byte unsigned little endian new left channel volume, then 
2 byte unsigned little endian new right channel volume. 
Optionally 'offset' can be set to positive value (in nanoseconds) 
to delay the audio by.

5.4.8 plugin: org.jpc.plugins.LuaPlugin

Takes 'kernel=<name of lua kernel file>', other parameters are 
passed to kernel, requires and uses GUI.

Lua VM for executing scripts.

6 Some error messages and explanations

• <filename> is Not a valid image file

• <filename> is not image file

• <filename> claims to be floppy with illegal geometry: <x> 
  tracks, <y> sides and <z> sectors.

• <filename> claims to be HDD with illegal geometry: <x> tracks, 
  <y> sides and <z> sectors.

• Can't read disk image sector map.

• Can't read disk image extent.

Code expects <filename> to be valid JPC-RR format image, but it 
isn't JPC-RR image at all or its corrupt.

• <filename> is image of unknown type.

• <filename> has unrecognized geometry <x> <y> <z>

Possibly corrupt image, not JPC-RR image, or JPC-RR image from 
future version containing something current version can't 
comprehend.

• Invalid format specifier <something>.

• Invalid syntax of --floppy= or --HDD= option.

• Invalid format specifier/option <something>.

Invalid option or format specifier was given. Check for typos.

• java ImageMaker [<options>...] <format> <destination> <source> 
  <diskname>

Check syntax of command. Especially that diskname is present!

• The image has <nnn> sectors while it should have <yyy> 
  according to selected geometry.

• Raw image file length not divisible by 512.

• Trying to read sector out of range.

The selected geometry is wrong or raw image is incomplete.

• Invalid disk name (Should not happen!).

• Invalid geometry to be written.

This is a very likely a bug in program.

• What the heck <filename> is? It's not regular file nor 
  directory.

That sort of file can't be used as input for image making, or the 
file just doesn't exist.

• BIOS images can only be made out of regular files.

• CD images can only be made out of regular files.

Source image specified is not regular file, but image of that 
type can't be made of anything else.

• Can't read raw bios image file.

• Can't read sector <nnn> from image.

Reading the raw image file failed for some reason.

• Bad library line: "<something>". Ignored.

Syntax error in image library.

• Removing image <something> a.k.a. "<something>" as it no longer 
  exists.

The image file no longer exists so it gets removed from library.

• Removing image <something> a.k.a. "<something>" due to <some> 
  conflict.

Image library code killed some image from library due to some 
kind of conflict with image being added.

• Too much data to fit into given space.

The tree you gave contains takes just too much space to fit into 
disk of this size.

7 Advanced: Savestate/movie format

7.1 JRSR archive

JRSR archive format packs multiple text archive members to text 
archive. It does not support binary members. JRSR archives have 
first five bytes form the magic. It is “JRSR” followed by 
LINEFEED character (0x0A, 0x0D, 0x0D 0x0A, 0xC2 0x85). There are 
three kinds of lines after that (lines are terminated by LINEFEED 
character):

• Start member

• Member line

• End member

Sequencing rules are as follows: Start member is allowed 
anywhere. Member line is allowed only inside member (member 
started but not ended). End member is only allowed inside member. 
End of file is only allowed outside member. Note that those three 
are all the kinds of lines allowed.

7.1.1 Start member

Start member line is given as “!BEGIN” <SPACE> <membername> 
<LINEFEED>. <SPACE> is SPACE character (only one!, 0x20) and 
<LINEFEED> is LINEFEED chacter. Multiple <SPACE>s would mean 
member with name beginning with <SPACE>. The member name is UTF-8 
encoded and maximum allowed length is 1024 bytes (256-1024 
codepoints). Starting member inside another implicitly ends the 
previous member.

7.1.2 Member line:

Member line is given as “+”<content><LINEFEED>. It gives another 
line for member contents. <content> is passed raw to layers 
above.

7.1.3 End member

End member line is given as “!END”<LINEFEED>. It ends the current 
member. The following line can only be start member line or file 
may end.

7.2 Four-to-Five encoding

Binary members are encoded into text by so-called four-to-five 
encoding. This encoding can encode single byte to two, two bytes 
to three, three bytes to four and four bytes to five. 
Four-to-five encoding has five kinds of blocks. All SPACE and 
CHARACTER TABULATION characters are completely ignored, even in 
middle of blocks.

7.2.1 End stream block

End stream block is encoded as '!'. It ends the stream instantly. 
There is also implicit end of stream at end of input to decoding.

7.2.2 Other four block types

Other four block types take the value to be encoded, read it as 
big-endian value. Then they write it as base-93 big-endian value. 
Then length specific constants are added to digits of that number 
to yield ASCII values for characters (those are stored in order):


+------------+------------+------------+------------+------------+-----------+
| To encode  | 1st char.  | 2nd char.  | 3rd char.  | 4th char.  | 5th char. |
+------------+------------+------------+------------+------------+-----------+
+------------+------------+------------+------------+------------+-----------+
|  1 byte    |    34      |    34      |     -      |     -      |     -     |
+------------+------------+------------+------------+------------+-----------+
|  2 bytes   |    37      |    34      |    34      |     -      |     -     |
+------------+------------+------------+------------+------------+-----------+
|  3 bytes   |    45      |    34      |    34      |    34      |     -     |
+------------+------------+------------+------------+------------+-----------+
|  4 bytes   |    66      |    34      |    34      |    34      |    34     |
+------------+------------+------------+------------+------------+-----------+


Blocks which encode values greater than what is possible for 
value of that length are fatal errors. 

7.3 UTF-8 encoding

UTF-8 encoding is used to encode lines of Unicode codepoints into 
bytes.

7.4 Line component encoing

Line component encoding sits on top of UTF-8 encoding. Line 
component encoding encodes non-empty 1-D array of non-empty 
strings into line, and thus array of those into member. Empty 
lines or lines that don't contain any components are ignored. 
Line starts with depth value of 0 and must end with depth value 
of zero.

Components are seperated by component separators. Empty 
components are ignored. Following codepoints are separators on 
depth 0 if not escaped:

• Codepoint of '('. The depth is read pre-increment.

• Codepoint of ')'. The depth is read post-decrement.

• Codepoints 0x20, and 0x09.

• Codepoints 0x1680, 0x180E, 0x2028, 0x205F and 0x3000

• Codepoints 0x2000-0x200A.

The following characters are special:

• '('. Increments depth by 1 if not escaped (and appears in 
  component).

• ')'. Decrements depth by 1 if not escaped (and appears in 
  component). Depth going negative is an error.

• '\'. Next character is interpretted as literal. Error if at end 
  of line.

Otherwise, characters are interpretted as literals and appear in 
components. Depth must be zero at end of line.

7.5 Header section:

Header section is in archive member "header". It uses line 
component encoding. The first component of each line is name of 
header, and subsequent ones are arguments. How many parameters 
are expected is dependent on what header it is:

7.5.1 PROJECTID header:

• Header name: "PROJECTID"

• Components: 2

• Argument #1: <project-id-string>

• Mandatory: Yes

Gives project ID. Project ID is generated when PC is assembled 
and is then preserved in save states. It is used for computing 
rerecord counts. Emulator treats it as opaque string, the IDs it 
generates are formed by 48 random hexadecimal digits.

7.5.2 SAVESTATEID header:

• Header name: "SAVESTATEID"

• Components: 2

• Argument #1: <savestate-id-string>

• Mandatory: No

Gives save state ID. Each save state has its own save state ID. 
Treated as opaque string, but generated as 48 random hexadecimal 
digits. The presence of this header signals whether there is save 
state to be loaded. If this header is present, save state load 
will be attempted. If absent, save state is not to be loaded even 
if present (and correct savestate load would be technically 
impossible anyway).

The value is used to prevent loading incompatible save states in 
preserve event stream mode and also to find the point in event 
stream where one left off.

7.5.3 RERECORDS header:

• Header name: "RERECORDS"

• Components: 2

• Argument #1: <rerecords>

• Mandatory: Yes

Gives rerecord count. PC assembly (except when loading save 
state) initializes current rerecord count to zero. Must be 
non-negative and decimal number using ASCII digit characters.

On loading save state:

1) If project ID matches with previous:

1a) If loaded rerecord count is larger or equal to current 
rerecord count:

1a-a) Current rerecord count is loaded rerecord count + 1.

1b) Otherwise

1b-a) Current rerecord count increments by 1.

2) Otherwise

2a) Current rerecord count is loaded rerecord count + 1.

The current rerecord count at time of save is saved to save 
state.

7.5.4 AUTHORS header:

• Header name: "AUTHORS"

• Components: 2 or more

• Arguments: free form

• Mandatory: No

Gives authors of run. Each argument gives one author. May be 
present multiple times.

7.5.5 COMMENT header:

• Header name: "COMMENT"

• Components: 2 or more

• Arguments: free form

• Mandatory: No

Various kinds of free form data. Not parsed further by emulator.

7.6 Initialization segment:

If SAVESTATEID header isn't present (not a save state), member 
"initialization" gives PC initialization parameters for 
assembling the PC. It is present anyway even if SAVESTATEID is 
present (savestate).

Following parameters are used (space separates components):

"BIOS" <id>

Gives Image ID of main system BIOS (mandatory)

"VGABIOS" <id>

Gives Image ID of VGA BIOS (mandatory).

"HDA" <id>

Gives Image ID of hda. Present only if system has hard disk hda.

"HDB" <id>

Gives Image ID of hdb. Present only if system has hard disk hdb.

"HDC" <id>

Gives Image ID of hdc. Present only if system has hard disk hdc.

"HDD" <id>

Gives Image ID of hdd. Present only if system has hard disk hdd.

"DISK" <num> <id>

Gives Image ID of disk in slot <num>. Slot number must be 
non-negative.

“DISKNAME” <num> <name>

Gives image name of disk in slot <num>. Slot number must be 
non-negative. The slot must be previously declared using “DISK”.

"FDA" <num>

Gives Image slot to initially put into floppy drive fda. Disk 
must be of floppy type. If none present, no disk is initially put 
there.

"FDB" <num>

Gives Image slot to initially put into floppy drive fdb. Disk 
must be of floppy type. If none present, no disk is initially put 
there.

"CDROM" <num>

Gives Image slot to initially put into CD-ROM drive hdc. Not 
allowed if hard disk hdc is present. Disk must be of CD-ROM type. 
If none present no disk is initially put there.

"INITIALTIME" <time>

Number of milliseconds since Unix epoch to system start up time. 
Allowed range:

0-4102444799999. Mandatory.

"CPUDIVIDER" <divider>

Set CPU frequency divider (dividing the 1GHz master clock). 
Allowed range is 1-256. Mandatory.

"MEMORYSIZE" <pages>

Number of 4KiB pages of RAM memory. Allowed range 256-262144. 
Mandatory.

"BOOT" <device>

Set boot device. Valid devices are "FLOPPY" (boot from fda), 
"HDD" (boot from hda) and "CDROM" (boot from CD).

"LOADMODULEA" <module> <parameters>

Load module <module> with parameters <parameters>.

"LOADMODULE" <module>

Load module <module> with no parameters

“FPU” <fpu>

Use class <fpu> as FPU emulator.

7.7 Event record format:

Event record is in archive member "events". It uses line 
component encoding. Each line gives an event. First component of 
each line gives time stamp. These timestamps MUST be in 
increasing order and all MUST be non-negative. Time stamp time 
unit is exactly 1 nanosecond of emulated time.

The second component of each line is name of class to dispatch 
to. Further components are passed as-is to event handlers. 
"Class" name "SAVESTATE" is special. This takes one or two 
additional components, first of which gives the save state ID of 
save state that occurred there. The save state IDs MUST be unique 
in entire event stream. The second argument to savestate (if 
present) is rerecord count at time of saving that savestate 
(useful for calulating rerecord count of movie starting from 
savestate).

7.7.1 Keyboard keypress/keyrelease event:

• Dispatch to: org.jpc.emulator.peripheral.Keyboard

• Argument #1: Fixed: "KEYEDGE"

• Argument #2: Key number. Valid values are 1-83, 85-95, 129-197 
  and 199-223

Send key press or key release. Keys work in toggle button manner. 
The event time must be multiple of 66 666, and must not be less 
than 60 * 66 666 TUs after last PAUSE event, 20 * 66 666 TUs 
after last KEYEDGE on key >128 and 10 * 66 666 TUs after last 
KEYEDGE on key <128.

7.7.2 Pause event:

• Dispatch to: org.jpc.emulator.peripheral.Keyboard

• Argument #1: Fixed: "PAUSE"

Send pause key event. The time restrictions are identical to 
KEYEDGE event.

7.7.3 Reboot:

• Dispatch to: org.jpc.emulator.PC$ResetButton

• No arguments

Reboots the PC.

7.7.4 Fda disk change:

• Dispatch to: org.jpc.emulator.PC$DiskChanger

• Argument #1: Fixed: "FDA"

• Argument #2: Number of image slot to put there. 

The disk number MUST be -1 or valid disk number. -1 MUST NOT be 
used if there is no disk in floppy drive A. This event causes 
specified disk to be placed to FDA or FDA disk to be ejected with 
no replacement if disk number is -1. The specified disk if not -1 
must be of floppy type. The specified disk if valid must not be 
in any other drive.

7.7.5 Fdb disk change:

• Dispatch to: org.jpc.emulator.PC$DiskChanger

• Argument #1: Fixed: "FDB"

• Argument #2: Number of image slot to put there. 

The disk number MUST be -1 or valid disk number. -1 MUST NOT be 
used if there is no disk in floppy drive B. This event causes 
specified disk to be placed to FDB or FDB disk to be ejected with 
no replacement if disk number is -1. The specified disk if not -1 
must be of floppy type. The specified disk if valid must not be 
in any other drive.

7.7.6 Change CDROM:

• Dispatch to: org.jpc.emulator.PC$DiskChanger

• Argument #1: Fixed: "CDROM"

• Argument #2: Number of image slot to put there. 

The disk number MUST be -1 or valid disk number. -1 MUST NOT be 
used if there is no disk in CD-ROM. This event causes specified 
disk to be placed to CD-ROM or CD-ROM disk to be ejected with no 
replacement if disk number is -1. The specified disk if not -1 
must be of CD-ROM type.

This event has no effect if CD-ROM is locked.

7.7.7 Write protect floppy:

• Dispatch to: org.jpc.emulator.PC$DiskChanger

• Argument #1: Fixed: "WRITEPROTECT"

• Argument #2: Number of image slot to manipulate 

Write protects specified disk. The disk MUST NOT be in any drive 
and MUST be valid floppy-type disk.

7.7.8 Write unprotect floppy:

• Dispatch to: org.jpc.emulator.PC$DiskChanger

• Argument #1: Fixed: "WRITEUNPROTECT"

• Argument #2: Number of image slot to manipulate 

Disables write protection specified disk. The disk MUST NOT be in 
any drive and MUST be valid floppy-type disk.

7.8 Savestates

Actual savestate format is not documented here. It is close to 
impossible to comprehend without access to emulator source 
anyway.

8 Advanced: Making class dumpable

Class is made dumpable by implementing interface 
org.jpc.emulator.SRDumpable and implementing method 
dumpSRPartial(org.jpc.emulator.SRDumper) and constructor 
<init>(org.jpc.emulator.SRLoader). Non-static inner classes can 
not be dumpable (make them static using tricks similar to what 
javac uses).

If dumped class has dumpable superclass, the first thing dumping 
function needs to do is to call dumper function of superclass and 
first thing loading constructor needs to do is to call loading 
constructor of superclass. If class has no dumpable superclass, 
dumper doesn't need to do anything special, while loader needs to 
call objectCreated(this) on SRLoader object passed as parameter. 

Following these fixed parts, dump all members that are part of 
mutable state in emulator core.

8.1 Member dumping/loading functions

There is dumping/loading function for following (all functions 
dumping/loading reference types can handle null):

• boolean: SRDumper.dumpBoolean, SRLoader.loadBoolean

• byte: SRDumper.dumpByte, SRLoader.loadByte

• short: SRDumper.dumpShort, SRLoader.loadShort

• int: SRDumper.dumpInt, SRLoader.loadInt

• long: SRDumper.dumpLong, SRLoader.loadLong

• String: SRDumper.dumpString, SRLoader.loadString

• boolean[]: SRDumper.dumpArray, SRLoader.loadArrayBoolean

• byte[]: SRDumper.dumpArray, SRLoader.loadArrayByte

• short[]: SRDumper.dumpArray, SRLoader.loadArrayShort

• int[]: SRDumper.dumpArray, SRLoader.loadArrayInt

• long[]: SRDumper.dumpArray, SRLoader.loadArrayLong

• double[]: SRDumper.dumpArray, SRLoader.loadArrayDouble

• <dumpable type>: SRDumper.dumpObject, SRLoader.loadObject

• special object: SRDumper.specialObject, SRLoader.specialObject

8.1.1 Notes:

• Dumpable objects come out as type of 
  org.jpc.emulator.SRDumpable.

• Special objects are various static objects that don't need to 
  be stored because they don't have mutable fields.

• Don't dump fields related to event state feedback.

• Don't dump temporary flags that are only used while PC is 
  running. Savestate when PC is running isn't possible anyway.

• Some connectors dump fields related to connector output, some 
  don't.

9 Advanced: Making output connectors

Implementing interface org.jpc.emulator.DisplayController signals 
that this is display controller, inhibiting loading of the 
standard VGA display controller if loaded as module. 

9.1 Interface org.jpc.emulator.OutputConnector

Class is made to be output connector by implementing this 
interface. This interface specifies the methods used for output 
hold locking. Class org.jpc.emulator.OutputConnectorLocking has 
implementations of these that are suitable for calling. 

9.1.1 Method subscribeOutput(Object)

Subscribes the output, with specified object as handle.

9.1.2 Method unsubscribeOutput(Object)

Unsubscribe the specified handle object from output.

9.1.3 Method waitOutput(Object)

Wait for output on specified connector using specified handle 
object. Returns true on success, false if wait was interrupted by 
thread interrupt. Blocking.

9.1.4 Method releaseOutput(Object)

Release connector from p.o.v. of given handle. Does not block.

9.1.5 Method holdOutput()

Release threads waiting on waitOutput() and block until all 
subscribers have returned from waitOutput() and enteired 
releaseOutput().

9.1.6 Method releaseOutputWaitAll(object)

Like releaseOutput(), but waits until all handles have released 
their output.

9.2 Class org.jpc.emulator.VGADigtalOut

Class org.jpc.emulator.VGADigtalOut (already implements 
OutputConnector) implements VGA output connector. If module 
provodes output connector, it needs to implement 
org.jpc.emulator.DisplayController.

9.2.1 Method getWidth()

Get width of display (watch out, can return 0).

9.2.2 Method getHeight()

Get height of display (watch out, can return 0).

9.2.3 Methods getDirtyXMin(), getDirtyXMax(), getDirtyYMin(), 
  getDirtyYMax()

Returns the dirty region (region modified since last output).

9.2.4 Method getBuffer()

Get buffer of ints, at least width * height elements 
(left-to-right, top-down, one value per pixel) giving pixel data. 
Value for each pixel is 65536 * <red-component> + 256 * 
<green-component> + <blue-component>.

9.2.5 Method resizeDisplay(int _width, int _height)

Resize the display to be of specified size.

9.2.6 Method dirtyDisplayRegion(int x, int y, int w, int h)

Mark the specified region as dirty.

9.2.7 Method resetDirtyRegion()

Resets the dirty region to be empty.

9.3 Class org.jpc.emulator.PC method getVideoOutput()

Get VGA output connector for PC.

9.4 Interface org.jpc.emulator.DisplayController.

Implementing this class signals that module is VGA controller. 
There can be only one such module active at time and presence of 
such module prevents loading builtin VGA controller emulation 
code.

9.4.1 Method getOutputDevice()

Get VGA output connector for this VGA device.

9.5 Class org.jpc.emulator.SoundDigitalOut

Class org.jpc.emulator.SoundDigitalOut provodes output connector 
for sound. Each connector can transfer stereo signal at arbitiary 
sampling rate. Modules that have audio connectors need to 
implement interface org.jpc.emulator.SoundOutputDevice, as this 
signals that output connectors should be created.

9.5.1 Method addSample(long, short, short)

Add stereo sample at time given by first argument. The second and 
third arguments give volume on left and right channels.

9.5.2 Method addSample(long, short)

Add mono sample at time given by first argument. The second 
argument give volume on both channels.

9.5.3 Method readBlock(Block)

Reads block of output (atomic versus addSample). Block structure 
has following fields which are filled:

• timeBase: Time base for block.

• baseLeft: Left volume at time base.

• baseRight: Right volume at time base

• blockNo: Sequence number of block filled.

• samples: Number of samples in block

• sampleTiming: Number of nanoseconds since last sample

• sampleLeft: Left channel samples

• sampleRight: Right channel samples

9.6 Interface org.jpc.emulator.SoundOutputDevice

Implementing this interface signals that module has audio output 
channels.

9.6.1 Method 
  org.jpc.emulator.SoundOutputDevice.requestedSoundChannels()

Return the number of sound channels module has.

9.6.2 Method 
  org.jpc.emulator.SoundOutputDevice.soundChannelCallback(SoundDigitalOut)

This is called once per sound channel requested giving precreated 
sound channel.

9.7 Class org.jpc.emulator.PC method getSoundOut(String)

Get sound output with specified name.

10 Advanced: Writing event targets

Whereas output connectors are the way output is dispatched, input 
is dispatched via event targets. Event targets need to implement 
interface org.jpc.emulator.EventDispatchTarget.

Event targets also provode methods which then encode events and 
dispatch them forward (without doing anything else) to event 
recorder. Also, event targets may have methods for obtaining 
state.

10.1 Interface org.jpc.emulator.EventDispatchTarget

Interface that marks class capable of receiving events.

10.1.1 Method setEventRecorder(EventRecorder)

Set the event recorder input events are sent to.

10.1.2 Method startEventCheck()

Signals target to reset all state related to event checking and 
state feedback. This may be called at any time in order to 
reinitialialize event checking/feedback state.

10.1.3 Method doEvent(long, String[], int) throws IOException

Event dispatch handler. The first argument is event time, second 
is parameters and third is what to do with it. If target doesn't 
like the event, throw IOException. Following types (the integer 
parameter) are used:

0 (EventRecorder.EVENT_TIMED): Time has been assigned for event.

1 (EventRecorder.EVENT_STATE_EFFECT_FUTURE): Future event in 
event replay for reinitialization

2 (EventRecorder.EVENT_STATE_EFFECT): Past event in event replay 
reinitialization

3 (EventRecorder.EVENT_EXECUTE): This event occurs now. Execute 
the effect.

10.1.4 Method endEventCheock()

End event reinitialization. Usually unused.

10.1.5 Method getEventTimeLowBound(long, String[]) throws 
  IOException

Return the time value that's the earliest possiblity for this 
event to occur. Returning any time in past (including -1) causes 
event to fire as soon as possible. The long parameter gives the 
current scheduled time for event.

11 Writing modules

Modules are various extensions that run inside emulator core. As 
such, they affect sync. Modules must implement interface 
org.jpc.emulator.HardwareComponent (they are hardware components) 
and must be dumpable. Additionally, they need either constructor 
<init>() or <init>(String). The first is if no parameters are 
passed, the second is for case where parameters are passed.

Aside of the constructors, modules need to obey the ordinary 
conventions for hardware components. No code outside modules 
needs to know that module exists.

12 Writing plugins

Plugins handle various UI tasks. They need to implement interface 
org.jpc.Plugin.

12.1 Interface org.jpc.pluginsbase.Plugin

12.1.1 Method systemShutdown()

Called when emulator shuts down. Either called in dedicated 
thread or in thread that called emulatorShutdown(). These 
handlers should do the bare minimum to get files on disk to 
consistent state. After these calls from all plugins have 
finished, emulator exits. Do not try to manipulate UI from these 
methods, as doing that easily leads into deadlock.

12.1.2 Method reconnect(PC) 

Gives new PC to connect to. Null is passed if plugin should 
disconnect.

12.1.3 Method main()

Called in dedicated thread after plugin is initialized.

12.1.4 Method pcStopping()

Called after PC has stopped.

12.1.5 Method pcStarting()

Called before PC starts.

12.1.6 Method notifyArguments(String[])

Pass arguments from command line.

12.1.7 Constructor <init>(Plugins)

This constructor is used to initialize plugins that don't take 
parameters.

12.1.8 Constructor <init>(Plugins, String)

This constructor is used to initialize plugins that take 
parameters.

12.2 Class org.jpc.pluginsbase.Plugins

This class provodes various methods for manipulating plugins.

12.2.1 Method isShuttingDown()

Returns true if Plugins.shutdownEmulator() has been called 
somehow, either via VM exit, CTRL+C or explicitly. Useful to skip 
cleanups involving GUI, as these are too deadlock-prone.

12.2.2 Method shutdownEmulator()

Shut down and exit the emulator. All plugin shutdown functions 
are called in this thread.

12.2.3 Method reconnectPC(PC)

Signal reconnectPC event to all plugins.

12.2.4 Method pcStarted()

Signal pcStarting() event to all plugins.

12.2.5 Method pcStopped()

Signal pcStopping() event to all plugins.

12.3 Interface org.jpc.pluginsbase.ExternalCommandInterface

Implementing interface 
org.jpc.pluginsbase.ExternalCommandInterface signals that plugin 
can receive commands via external commands interface.

12.3.1 Method invokeCommand(String cmd, String[] args)

Invoke specified command using specified arguments. Return true 
if event is to be shallowed, false to continue trying to pass it 
to more plugins.

13 Lua kernel programming

At startup, kernel gets its arguments in 'args' table and the 
script name to run in 'scriptname' string. It should enter the 
named script in protected mode.

The Lua VM exports numerious callbacks to kernel. The kernel can 
then choose to omit, wrap or re-export these to Lua scripts.

• Always grab any functions used into local variables so nobody 
  can mess with them

• Don't use global variables in kernel (except for those passed).

13.1 Lua standard

All standard Lua functions in tables main, 'math', 'coroutine', 
'string' and 'table' (safe to re-export with exception of print, 
loadfile and dofile, which should be wrapped).

13.2 Bit manipulation: none

Bitwise none function is exported as 
'jpcrr_raw.bit_none(num...)'. It takes zero or more numbers and 
returns number (numbers have 48 bits). The number returned has 
those bits set that are set in none of inputs. Safe to re-export.

13.3 Bit manipulation: any

Bitwise any function is exported as 'jpcrr_raw.bit_any(num...)'. 
It takes zero or more numbers and returns number (numbers have 48 
bits). The number returned has those bits set that are set in any 
of inputs. Safe to re-export.

13.4 Bit manipulation: parity

Bitwise parity function is exported as 
'jpcrr_raw.bit_parity(num...)'. It takes zero or more numbers and 
returns number (numbers have 48 bits). The number returned has 
those bits set that are set in even number of of inputs. Safe to 
re-export.

13.5 Bit manipulation: all

Bitwise parity function is exported as 
'jpcrr_raw.bit_all(num...)'. It takes zero or more numbers and 
returns number (numbers have 48 bits). The number returned has 
those bits set that are set in all of inputs. Safe to re-export.

13.6 Bit manipulation: lshift

Left shift function is exported as 'jpcrr_raw.bit_lshift(num 
base, num shift)'. It takes two numbers and returns first number 
shifted by second. number places left. Numbers have 48 bits, 
using shifts outside 0-47 gives unpredictable results. Safe to 
re-export.

13.7 Bit manipulation: rshift

Right logical shift function is exported as 
'jpcrr_raw.bit_rshift(num base, num shift)'. It takes two numbers 
and returns first number shifted by second number places right. 
Numbers have 48 bits, using shifts outside 0-47 gives 
unpredictable results. Safe to re-export.

13.8 Bit manipulation: arshift

Right arithmetic shift function is exported as 
'jpcrr_raw.bit_arshift(num base, num shift)'. It takes two 
numbers and returns first number shifted by second number places 
right, with highest bit copied. Numbers have 48 bits, using 
shifts outside 0-47 gives unpredictable results. Safe to 
re-export.

13.9 Bit manipulation: add

Add function is exported as 'jpcrr_raw.bit_add(num...)'. It takes 
zero or more numbers and returns number (numbers have 48 bits). 
The number returned is sum of all of inputs modulo 2^{48}. Safe 
to re-export.

13.10 Bit manipulation: addneg

Add negated function is exported as 
'jpcrr_raw.bit_addneg(num...)'. It takes zero or more numbers and 
returns number (numbers have 48 bits). The number returned is 0 
minus of all of inputs modulo 2^{48}. Safe to re-export.

13.11 Bit manipulation: addalt

Add alternate function is exported as 
'jpcrr_raw.bit_addalt(num...)'. It takes zero or more numbers and 
returns number (numbers have 48 bits). The number returned is sum 
of odd arguments (first argument is odd) minus sum of even 
arguments modulo 2^{48}. Safe to re-export.

13.12 Bit manipulation: tohex

Add alternate function is exported as 'jpcrr_raw.bit_tohex(num 
number)'. It takes number and returns hexadecimal representation 
of it. Safe to re-export.

13.13 Console output:

Console ouput function is exported as 
'jpcrr_raw.print_console_msg(sring line)'. It prints its string 
argument as new line on Lua console (should not be re-exported, 
use to construct replacement print).

13.14 Binary I/O:

Binary I/O file open function is exported as 
'jpcrr_raw.io_openbinary(string name, string mode)'. It takes two 
strings, first is name of file to open, second is mode, either “r”
 or “rw”. The returned object has following methods:

• file:length(): Returns length of file as number.

• file:set_length(num len): Truncate file to len bytes.

• file:read(num offset, num length): Read up to length bytes 
  starting from offset offset. The file character set is assumed 
  to be Latin1.

• file:write(num offset, string str): Write str starting from 
  offset offset. Writing non-Latin1 characters gives 
  unpredictable results. Only available on files opened for 
  read/write.

• file:close(): Close file. No file operations can be done 
  anymore.

The function should be filtered to enforce path constraints.

13.15 Text input:

Text input open function is exported as 
'jpcrr_raw.io_opentextinput(string name)'. It takes one string, 
name of file to open. The returned object has following methods:

• file:read(): Read next line. The file encoding is assumed to be 
  UTF-8.

• file:close(): Close file. No file operations can be done 
  anymore.

The function should be filtered to enforce path constraints.

13.16 Text output:

Text output open function is exported as 
'jpcrr_raw.io_opentextoutput(string name)'. It takes one string, 
name of file to open. The returned object has following methods:

• file:write(string line): Write line line to file. File encoding 
  is assumed to be UTF-8.

• file:close(): Close file. No file operations can be done 
  anymore.

The function should be filtered to enforce path constraints.

13.17 ECI invoke:

ECI invocation functions 'jpcrr_raw.invoke(string name [, table 
args])' and 'jpcrr_raw.invoke_synchronous(string name [, table 
args])'. These functions run specified ECI function with 
specified arguments. The updates ECI call makes to arguments is 
reflected to table passed as parameter. The synchronous version 
waits that any slow command processing gets done before returning 
(assemble, save, load and dump have such slow processing). These 
functions return nothing. Safe to re-export, use as base for more 
functions.

13.18 PC Running:

'jpcrr_raw.pc_running()'. Returns true if PC is running, false 
otherwise. Assemble, save, load and dump require PC not being 
running to be possible.

13.19 PC Connected:

'jpcrr_raw.pc_connected()'. Returns true if PC is connected, 
false otherwise.

13.20 VGA wait/release:

'jpcrr_raw.wait_vga()' waits for VGA to enter frame hold mode and 
returns true (if it returns false, the wait got interrupted for 
some reason and VGA is in rendering mode). While VGA is in frame 
hold, PC execution is locked out and things like memory reading 
and writing can be done without races (but load/save is not 
possible). 'jpcrr_raw.release_vga()' acknowledges frame hold 
processing (VGA can re-enter rendering mode).

Frame hold happens once per frame at start of vertical retrace. 
Note that running Lua script must wait frame holds and release 
them or main PC execution will hang on first frame hold.