Notes on IBM 7094 emulator implementation and source code.

This file contains some notes on the accompanying source code files.
The last section describes some aspects of Borland Delphi for those unfamilar
with the language used to write the emulator.

The code was developed using Borland Delphi, Version 5.
Later versions should work, 3 & 4 may, versions 1 & 2 won't.
If you wish to compile the code, remember to load the components to the Delphi
palette before loading the project (from B709Cmps), otherwise Delphi will screw
up the forms for you.


*** First make it work - Then make it fast.
Apart from the hashing function used for opcode table lookup, very little effort
has been made to achieve high emulation performance. It's fast enough for what
it can do now, and there is plenty of room for improvement should that become
neccessary in the future.

*** PUN intended, but not implemented.
As yet, no 7094 code has been run on the emulator that requires the card punch
device, and therefore this has not yet been implemented. Work was directed to
other functions that were required more immediately.

*** FP-DP Ops not tested.
Mike Hore has developed the floating point code for the emulator, but the double
precision part of this has not yet been tested.

*** Comments in the source code.
Most of the code is reasonably well commented, especially those areas that deal
intimately or directly with 7094 functions. Others parts, which simply involve
the mechanics of a Delphi/Windows application may be more sparsely documented.

Some code snippets have been "commented out" but remain in the code.
For the most part, they are probably junk that can removed, but they may indicate
an area of uncertainty, and could provide clues for future development and
debugging.

*** Convoluted transfer of control in device object hierachy.
Just a general observation.
Especially in the I/O device implementations, use has been made of the inheritance
and polymorphism aspects of Object-Oriented Programming. This can be quite hard
to follow as functions are invoked downwards into ancestor objects, and sideways
into associated objects. This sort of thing becomes a bit clearer when the code
is loaded into the Delphi IDE, but even then it can still be quite confusing.

*** Instruction Command table.
The 7094 instructions and some of their attributes are loaded into a large table
at initialization time. This information makes it easier to decode and dispatch
instructions during fetch and execute, and helps with writing meaningful trace
entries. But the format of 7094 instructions, and the design aim of having many
of the instruction table entries be autogenerated, together with other opcode
decoding issues, makes this section more complex than might be expected.

*** Source files:-
B7094.DPR    - Main project file
B709Main.pas - Main form - console window
B709Spls.pas - Splash screen
B709Core.pas - Core Storage display form
B709DRDR.pas - Reader display form
B709DLST.pas - Printer display form
B709TapF.pas - Tape drive display form
B709DTAP.pas - Tape cluster display form - holds instances of the above
B709Cnfg.pas - Configuration display form
B709Stop.pas - Address stops display form
B709Trce.pas - Trace display form
B709Eror.pas - Error display form
B709OCLD.pas - Scripting display form
B709OCLE.pas - Script editor display form

All the above have associated .DFM files of the same name

B709Defs.pas - Global definitions
B709Misc.pas - Miscellaneous functions
B709CPU.pas  - CPU main control functions
B709Chan.pas - Channel and basic device operations
B709IBIS.pas - Instruction emulation - Basic instructions
B709IINA.pas - Instruction emulation - Fixed point arithmetic
B709IFPA.pas - Instruction emulation - Floating point arithmetic
B709IIOC.pas - Instruction emulation - Input/Output
B709IEPS.pas - Instruction emulation - Extended performance set
B709Inst.pas - Instruction Control Table
B709OCLI.pas - Scripting interpreter
B709Cmps.pas - Specialized display components for console and unit record


*** The following are a few notes for readers unfamiliar with Delphi ***

*** DPR, DFM and PAS files
These are the three main types of source file in Delphi.

The DPR file is the main project file that links all the others together, and
initiates execution of the application. There is only one DPR file in a project.

The PAS files contain actual Object Pascal code. Each defines a "unit" which is
compiled separately and then linked together with all others. The guts of the
code lies in the "implementation" part of the unit, and is generally private to
the unit. However, items within a unit can be exposed for access by other units
by placing their declaration information in the "interface" part of the code at
the start of the unit. The interface part also contains a "uses" clause that
specifies the names of other units that have exposed items which this unit needs
access to.

DFM files are descriptions of the "Forms" (or windows) that make up the visible
part of the application. This code is rarely edited directly by the programmer.
Delphi maintains these files as the programmer edits the form layout using
graphical editing facilities. Each DFM defines exactly one form or window, and
is always associated with a PAS file that contains the code for responding to
user events coming from the form, and for updating the form display to the user.


*** Private, Protected and Public areas in Delphi objects.
These keywords delineate which fields and methods of an object are visible, and
to what other entities they are visible.
Private is known only to the methods of the object itself.
Protected is known only to the object, and its descendants.
Public is visible to all.


*** Properties in Delphi.
An object may control how its fields are externally accessed by the use of
properties. The property specifier in the public section of the object definition
may simply link to the name of the underlying data field (defined in the private
part), or may exercise more control by linking to a function for read access
and/or a procedure for write access. By convention, the underlying field variable
name is prefixed with the letter "F", and the read function/write procedure names
are the name of the variable, prefixed with "get" and "set" respectively.


*** Delphi is a single-pass compiler.
And therefore all items must be defined before they are referenced.
This leads to higher level procedures being placed towards the end of the code
in a unit, after any sub procedures and data items that they reference.
This is less true for object methods, which are all declared in the object
definition, and so may be placed freely anywhere after that.


