6. On target, connect a tftp archive server (tftp_asf) to PRH and usePRH to load the Erlang load module from the host. Finally start theload module. Note that this does not start Erlang. It must be doneexplicitly (see instructions below).7. If you are going to build and load Erlang linked-in driversseparately as load modules (see Writing Erlang Linked-in Drivers forOSE Delta below), you need to create an Erlang user library file(liberl_user.a) for the drivers to link with. Run gmake with flagerllib in the lm/erl directory.Starting and Stopping ERTS--------------------------When OSE Delta has been started on target, use the local command shellor a remote Telnet shell to start ERTS. The shell command start_erlspawns the erts process and starts the emulator. start_erl takes anyvalid Erlang flag as input. Example:  $ start_erl -sname erl_ose -kernel raw_files false -master  boots@blackbush -loader inet -hosts 134.138.177.125 -setcookie  marylandNote the kernel variable raw_files. Setting the value of this variableto false causes the raw option to be ignored in any call tofile:open/2. (Opening files in raw mode is impossible if there's nolocal file system). If the flag is omitted, raw_files defaults totrue.Read the System Principles chapter in the Erlang/OTP SystemDocumentation to learn more about general start flags and, forexample, how to start a target slave node without local disk access.ERTS can be started in interactive or embedded mode. This works thesame way as for Erlang on any other platform. The same is true forstopping the emulator.If you wish to start the epmd process before starting ERTS, runstart_epmd from the shell prompt (otherwise epmd starts with ERTS).Memory handling---------------For heap memory management, the Erlang emulator uses the elib_malloclibrary which is released as part of Erlang/OTP. When ERTS is startedit reads the block environment variables OSE_EXT_HEAP_SIZE andOSE_EXT_HEAP_ADDR. These variables should be defined in osemain.conand should specify the size of the memory area to be reserved for ERTSand the start address of the same area.The command erl_mem_show may be called from an OSE shell prompt (whenERTS is running) to show information about the current heap memoryusage.The start function for the Erlang emulator also reads block variablesERL_HEAP_SIZE and ERL_HEAP_ADDR. If the heap memory for OSE needs tobe extended (with heap_extend_heap) before Erlang is started, you mayspecify the size and start address of a memory area with thesevariables.Writing Erlang Port Programs for OSE Delta---------------------------------------------------------Port programs need to be implemented differently for OSE Delta thanfor other platforms. The main reason is that they run as OSE processesand communicate with Erlang by means of OSE signals rather than bysending and receiving data on file descriptors.A port program is started in Erlang by calling functionerlang:open_port/2, like this:		open_port({spawn,PortProgName}, PortSettings)PortProgName is the name of the port program. For Erlang to recognisea port program, the OSE process entry point must be registered withERTS. To register a port program that is statically linked with ERTS,declare the entrypoint - which must be the same as the port programname - in erl_user_pgm.c (this file is compiled and linked whenbuilding ERTS). For details, see the instructions in the same file. Toregister a port program which is separately built and is supposed tobe loaded by OSE PRH, you need to have the following lines of code ina function being called at the time the module is loaded or started:	ERL_PORT_PROG_DECL (<PortProgName>);	ERL_PORT_PROG_REG  (<PortProgName>);When the port program is no longer to be used, it may be unregisteredwith:	ERL_PORT_PROG_UNREG(<PortProgName>)The file that uses these macros must include ose_erl_port_prog.h. Youwill find a static port program example in erl_stat_port_ex.c and an example of a dynamic program in erl_port_ex.c. They are located in the port_progs directory.When open_port/2 is called, ERTS will create and start a new OSEprocess with the registered name of the port program as entrypoint. To declare the port program start function, instead ofusing OS_PROCESS, use:	ERL_PORT_PROG(<PortProgName>)The PortSettings argument to open_port/2 is a list that may containthe following settings:	stream	{ose_process_type,ProcType}	{ose_process_prio,Priority}	exit_status	in	out	binary					Atom stream is the only valid communication protocol setting. This isalso the default mode if stream is not specified explicitly. ProcTypeis the atom ose_pri_proc, ose_bg_proc, ose_int_proc, ose_phantom orose_ti_proc. The emulator starts the port program as an OSE process ofthe corresponding type. If this setting is not specified, ose_bg_proc(OS_BG_PROC) is used as default. Priority is an integer value0-31. The port program will run as an OSE process with thispriority. Default is 20. exit_status may be used to keep a port aliveif the port program terminates and to let the connected Erlang processreceive a notification about the event. It works as documented in themanual page for module erlang, except the exit status integer valuethe Erlang process receives contains no information. It's a dummyvalue. For information on the in, out and binary settings, please seethe manual page.The OSE signal type the port program should use to communicate withERTS is declared in port_signals.sig. Data sent from an Erlang processis received by the port program in the buf element of the PortDatasignal. The length of the data is indicated by the element len. Theport program will use the same data structure the same way for sendingdata to an Erlang process (the signals should be sent to the ertsprocess). For examples of this, see the previously mentioned port program example files.Writing Erlang Linked-in Drivers for OSE Delta---------------------------------------------------------Linked-in drivers are implemented in a very similar way for Erlang onOSE Delta as for Erlang on other platforms. Please see the Tutorialsection of the Erlang/OTP System Documentation for details. ERTShandles drivers similarly to port programs. The important differenceis of course that a port program runs as a separate OSE process, whileas a driver is implemented by a set of runtime system callbackfunctions.A driver must register with ERTS for the runtime system to be able tocall the driver's initialisation function. If you link the driverstatically with ERTS, you should declare the driver name inerl_user_pgm.c (this file is compiled and linked when buildingERTS). For details, see the instructions in the same file. To registera driver which is separately built and is supposed to be loaded by OSEPRH, you need to have the following lines of code in a function beingcalled at the time the module is loaded or started:	ERL_DRIVER_REG(DriverName);	ERL_DRIVER_REG(DriverName);The initialisation function of the driver should look like this:	ERL_DRIVER_INIT(DriverName)	{	  DRIVER_INTERFACE_INIT();	  ...	  return &driver_entry;	}The file that uses these macros must include ose_erl_driver.h. Notethat it must not include erl_driver.h (which is the common header filefor Erlang drivers on other platforms). You will find a static driverexample in erl_stat_portdrv_ex.c and a dynamic driver example in erl_portdrv_ex.c. The files are located in the drivers directory.To load a driver from Erlang, call:	erl_ddll:load_driver("", DriverName)ERTS will as a result invoke PRH to localise and load a module withname DriverName (from whatever archive server you've previouslyconnected to PRH). If you have a module with an elf extension, don'tspecify this extension in DriverName. The function will look forDriverName.elf automatically. Note that this function must be also becalled for statically linked drivers for Erlang to be able torecognise the driver when open_port/2 is called (see below). Therewill be no attempt to load a module for a driver that has beenregistered as static (i.e. declared in erl_user_pgm.c).Drivers are started from Erlang the same way as port programs:	open_port({spawn,DriverName}, PortSettings)See the section Writing Erlang Port Programs for OSE Delta above fordetails. DriverName is the name of the driver as well as the loadmodule (for dynamic drivers).To remove a driver, call:	erl_ddll:unload_driver(DriverName)This unregisters the driver and invokes PRH to unload the correspondingload module (if the driver is dynamic).It is possible to load a dynamic driver module from outside of Erlang(e.g. from the OSE shell). However, erl_ddll:load_driver/2 must stillalways be called before the driver can be started. There is noexplicit way to unregister a driver since this is handled byerl_ddll:unload_driver/1, which must always be used to remove adriver.Known Bugs and problems-----------------------The emulator loop, implemented in beam_emu.c, uses a jump table foroptimal performance. This requires a compiler extension that e.g. DIABdoesn't provide. For this reason, when compiling ERTS for PPC750, thisparticular file must be compiled with gcc. Note that this is true foroptimized (opt) compilation, not for debug compilation.The emulator files ggc.c and erl_process.c are incorrectly compiled byDIAB for PPC750 if the general optimization switch, -XO, is used. Fornow, gcc may instead be used for these two files.DIAB's "local static variables optimization" (default when compilingwith -XO) screws up addressing of some global variables and needs tobe disabled.A bug in the OSE INET implementation made it impossible to disable theNagle algorithm. This gave distibuted Erlang bad performance in TCP/IPcommunication. The bug has been fixed by OSE Systems and a patchexists for OSE Delta v4.4 for PowerPC.