Copyright 2001 William Overington

Thursday 26 July 2001

An interesting scenario which I like to consider is that of a person interested in authoring learning material about his or her own specialist subject for broadcasting on DVB-MHP channels around the world who has only the sort of computing facilities and internet facilities that might be obtained reasonably easily in a public library.

Certainly some people who are interested in authoring learning material about his or her own specialist subject for broadcasting on DVB-MHP channels around the world may well have much better facilities, perhaps at home or in a college computing laboratory. However, I like to think about the author in a public library scenario as a benchmark for considering the accessibility to the infrastructure for independent software authors. If an individual software author has greater facilities, then he or she is fortunate.

Please note, however, that these facilities for the scenario of an author in a public library are far greater than those that many people working in big organizations had available just a few years ago.

The scenario then forms two branches, as to whether there is a Java compiler available on the computer being used.

Suppose that there is not a Java compiler available and that an author has available the use of a PC with a text editor, a web browser, a drawing program such as Paint, and that the user of that PC is able to save his or her work on a floppy disc and indeed load files from a floppy disc. There is no hard disc usage available to the user. There is internet access with a web browser but no direct email facility, though users of the library may use a webmail facility if they choose.

The user may need to work on different PCs at different times as the library perhaps has a number of PCs available for use but only some of them have internet access and so a user of the PCs is asked to try to work on a PC that does not require internet access if the particular work that he or she is doing at the time does not require internet access.

Sometimes the librarian asks people if they could move to another machine if, say, someone is working off line using a web browser and all of the machines have a web browser but some machines have a wordprocessing package and some do not because of the licensing cost that would be involved to equip all the machines with the wordprocessing package and someone would like to use a machine that has the wordprocessing package upon it.

The almost magical thing is that there can be a route from someone using these facilities in a public library setting as and when available, to having his or her work, the results of his or her thoughts, broadcast 24 hours a day across whole continents on DVB-MHP channels.

This document is one step in helping to pave that route such that it will hopefully be used by independent authors of distance education packages to send the results of their applying of their skills around the world, broadcast across whole continents.

The route consists of many aspects, some designed specifically for the purpose and some fortunate side effects of progress in other fields. An example of such a side effect is that the Paint program, which is often (always?) bundled with Windows on a PC, previously saved files only in .bmp file format. Modern versions of Paint can also save in .gif and .jpg format, so the problem that the author in the author in a public library scenario might otherwise have had in converting a .bmp file to form a .gif file is not a problem now as such, though for the present as libraries often have a few newer machines and also some older machines, the author may need to take his or her floppy disc from one machine to another in order to obtain use of a PC with a version of Paint that can save a file in .gif format.

Yet the author will gradually learn which machine to use for which purpose and will adapt accordingly. The floppy disc that he or she carries looks to the world as just a piece of media. Yet it carries thoughts and dreams and knowledge to delight learners maybe thousands of miles away from the public library where he or she quietly pursues his or her studies.

So the scenario of the author in a public library entwines both working as best one can using a minimum of facilities with dreams that reach around the earth.

The 1456 object code system (in speech, please say "fourteen fifty-six object code") is a method whereby a person may write software that produces Java quality results without needing to know any Java and without needing access to a Java compiler.

There are a large number of documents about 1456 object code and using it on the web in the documents linked from http://www.users.globalnet.co.uk/~ngo/14560000.htm and readers interested in learning how to use 1456 object code may like to look at those documents. This document does not seek to say a lot about 1456 object code itself but looks at issues concerned with moving towards being able to use 1456 object code on a DVB-MHP channel as a readily available programming option.

Here is a link using just a local file name for readers who have downloaded both this document and the 1456 object code documents to local storage in the same directory as this document and like to study them off line.

14560000.htm

The first matter to emphasize is that 1456 object code is not in any way intended to replace Java as the programming language used for programming content for DVB-MHP channels. 1456 object code does not do the same things as Java and also it relies upon Java for its standardization. However, 1456 object code does fill a niche role, namely of fairly straightforward access to being able to produce quite effective Java quality results, particularly with on screen graphics displays, without needing knowledge of Java nor access to a Java compiler.

The approach is that a software author using 1456 object code produces a text file that contains software written in 1456 object code. That text file is used as a data file by a standardized program that contains a 1456 engine. The 1456 engine interprets the 1456 object code using Java methods such as fillRect and drawString and so on. The on screen effects are indistinguishable by the end user from similar results produced by a specially written Java program. There is a speed penalty in using 1456 object code rather than direct Java programming. For many programs that produce graphics that speed difference is not even noticeable by the end user. Tests of fast looping programs computing millions of random numbers have shown that a program programmed in 1456 object code can under certain conditions achieve something like 40% of the speed of a specially prepared Java program carrying out the same computations. So 1456 object code is quite powerful.

Programming in 1456 object code is approximately equal in complexity to the simpler usages of assembler level programming of a microprocessor. However, programming in 1456 object code is programming directly in the object code, not programming in a source code that is then assembled and converted into an object code. Looking at a 1456 object code program without having studied 1456 object code in a step by step manner may give the impression that it is impossibly difficult to learn. However, all instructions are either one character or two characters long, those instructions that are two characters long have the first character as one of a number of characters specifically designated for use in two character instructions. These specifically designated characters are used in a consistent manner. For example the & character is used as the first character of those two character instructions that produce an integer result, for example &+ is used to add two integers and &- is used to subtract one integer from another. Indeed, all instructions that produce an integer result are two character instructions that start with an & character. The characters + and - on their own form one character instructions that are use for arithmetic on double precision floating point numbers. Instructions that begin with a % character are used to manipulate strings. For example %+ is used to concatenate two strings. Other specifically designated characters are used for other data types, sometimes two specifically chosen characters for one data type. Commands that start with a $ character are used to instruct the graphics system.

I will not describe the system further in this document except to mention that 1456 object code does have built in as standard data types, integers, doubles, characters, strings, complex numbers and quaternions, with facilities to manipulate those data types. Quaternions have been used to produce displays of rotating three-dimensional objects using 1456 object code.

In order to run a 1456 program of his or her own using a web browser a software author does need to have two Java class files, though he or she does not need to program those himself or herself, for they are standardized. They can be downloaded from the internet and stored on a floppy disc much as one could obtain a .gif file from a clip art library. So, similarly in manner to the way that one may place a .gif file from a clip art library in a web style page that one has prepared without needing to have access to the drawing program that someone used to produce it nor to be able to draw, one may place a Java class file from a Java class file library in a web style page that one has prepared without needing to have access to a Java compiler nor to be able to program in Java.

One can indeed in general web page production have Java classes that one does not need to customize and that, say, produce a diagram. However, the Java classes used to run a 1456 object code program are customized, using the contents of a text file that can be produced using a text editor. Such text editors are often available on PCs in public libraries.

I mentioned two Java class files. In fact, the 1456 object code programmer only accesses one of these directly. That Java class file accesses the other Java class file.

The reason for that is that there is a choice of which two files to use, but one of the two is always the same. The file that is the choice is the one used directly by the 1456 programmer. For web based programs that file is called the 1456 applet landscape. There is a choice of 1456 applet landscapes. They are detailed in the documents about 1456 object code for anyone who wishes to study them.

This present document concerns the programming of a 1456 applet landscape that can be used to simulate the use of 1456 object code on a DVB-MHP terminal.

Now, a fundamental problem is that in a DVB-MHP system the 1456 object code might well be contained in a text file rather than in a call to a Java class file, so that this simulation may be well off what is being simulated.

Previous simulations of a DVB-MHP terminal in these Astrolabe Channel documents have been off to an extent regarding scaling yet have, I hope, conveyed a reasonable flavour of that which is being simulated. So, too, I hope this simulation will provide a reasonable flavour of that which is being simulated, yet I am concerned to mention that although the display is I believe a correct simulation within the limits of being a scaled display and although the use of the 1456 engine is a correct simulation, the picking up of the 1456 object code into the 1456 applet landscape is probably not a correct simulation of how a 1456 DVB-MHP landscape would pick up 1456 object code. It might be that the 1456 DVB-MHP landscape would need to be able to read a plain text file containing the 1456 object code program. However, the 1456 object code program that would be in that plain text file would be the same 1456 object code program that is between the quotation marks in the param statements of the applet call in the web page that carries the simulation. So, to that extent the 1456 object code software carried in param statements in this web simulation is a correct simulation of the 1456 software that would be carried on air.

I am, as I write this document, not entirely sure as to whether the 1456 engine software would need modification before being suitable for use in DVB-MHP broadcasts. It might possibly not need modification. I shall have to study that matter some more.

I feel that pursuing the route of trying to use 1456 object code on DVB-MHP broadcasts has mixed possibilities. It is producing a system that may not be used or understood by many content authors and may divert my efforts from learning more about direct Java programming on the DVB-MHP platform. However, it may be that 1456 object code may open up major opportunities for the producing of learning material for distance education by independent software authors who might not otherwise produce learning material for broadcasting upon a DVB-MHP platform. Indeed, the availability of 1456 object code may have a major effect upon the extent of use of the DVB-MHP platform for distance education.

So I proceed with this document, bearing those possibilities in mind. I shall try to produce a 1456 applet landscape for use on the web that will give the overall visual appearance look of one of my previous simulations in these documents about Astrolabe Channel. Behind the scenes it will be a 1456 applet landscape suitable for use by someone who has learned how to use 1456 object code on the web from the other set of documents. Yet, for the moment, I intend not to proceed along the route of developing software for Astrolabe Channel along the lines of using 1456 object code, other than a few examples to accompany this document. This I feel is a balanced approach. The implementation of Astrolabe Channel, perhaps on an experimental basis, hinges on being able to get my programs such as the arithmetic questions and the harmonograph simulation converted to DVB-MHP format by someone who knows how to do that and getting them broadcast by a broadcasting organization. That is two steps, yet as the saying of science goes, chance favours the prepared observer, so I wish Astrolabe Channel to be ready to accept any such chances that come along. The implementation of the 1456 object code system onto the DVB-MHP system is a much bigger task. It may not be impossible, yet it will take longer and hinges on more steps. So, in the hope that chance will favour the prepared inventor, I am including in this set of documents in a byway from the main path this hopefully interesting document in the hope that 1456 object code may well catch the eye of someone specialist in the DVB-MHP platform who might be sufficiently interested in solving how to let 1456 object code achieve its goal of being a language for producing learning material for distance education broadcasts on DVB-MHP channels around the world.

I set out to produce a simulation in this document by first copying the ast00801.java file into ast00901.java and copying the Print1456.java 1456 applet landscape file to a file called ast99999.java. I shall remove from ast00901.java the software that is not part of the simulation environment. The intention is that I shall then gradually move some pieces of software from ast99999.java and paste them into ast00901.java so that in the end I may delete the ast99999.java file. The ast00901.java file should then have the look of one of my web based simulations of a DVB-MHP terminal, with the computing capability of a 1456 applet landscape.

In a similar manner to previous documents I intend to supply several example programs. However, there will be a fundamental difference to the producing of several example programs for use in this document from the producing of several example programs for use in the harmonograph document. For with the harmonograph, each example program has its own Java applet. There is ast00801.class, ast00802.class, ast00803.class and ast00804.class. For this document, there may be several example programs and their on screen displays might be quite different one from another, yet all will use the same ast00901.class applet. Perhaps I may mention here that the first demonstration will have the look and feel of a web based simulation of a DVB-MHP terminal with pushable buttons but will do nothing else. This is because a 1456 applet landscape is traditionally first supplied with a 1456 program that simply starts then halts. That is because any computation effect achieved from a program written in 1456 object code is achieved by editing in a text editor a copy of the HTML file that carries the program that simply starts then halts. This document will not seek to explain the 1456 object code programs used in the examples used in this document. The 1456 object code programs that are used may be studied by looking at the HTML source code of the web pages that contain the simulations. Please know that if you wish to use the programs off line, then you will need to also download the Engine1456.class Java class file as it is called by the ast00901.class class file.

I shall now proceed with programming the ast00901.java program, noting here any particular matters that arise as the programming proceeds.

The matters that arose were as follows.

Firstly, the value of obeycode used for start up of the simulation environment. The simulation program needs to start up and then the 1456 program needs to start up. A 1456 program traditionally starts obeying at label 1. The simulation environment starts up with some simulation environment housekeeping and then passes control to the local program start up. That is fine as far as it goes. However, the simulation environment may be changed by the user of this web based simulation of a DVB-MHP terminal by clicking the mouse in the lower part of the white area as mentioned in a previous document in this series, namely the document Programming with a mouse unit. about using a mouse in a DVB-MHP terminal. Changing the simulation environment in this way restarts the program. However, in this simulation the restarting when the simulation mode is changed, that is when one changes from having a mouse simulated as being attached to having a mouse simulated as not being attached or vice versa or indeed a restart in the same mode, does not change the values of variables in the 1456 engine as the 1456 engine is not reinitialized. Careful design of software in the 1456 object code programs should mean that such overall reinitialization is not needed as good 1456 program design will initialize variables as used and not presume them to be set at zero for numbers, at \u0000 for characters and at null strings for strings, although the 1456 engine software does, in fact, initialize them at the start up of the 1456 engine itself. In the longer term the 1456 engine could perhaps have a method for initializing all of the variables of the 1456 engine added to it so that changing simulation mode could reinitialize the 1456 engine. This should not be a big task, simply moving the present initialization of global variables to a function and then adding a method that calls the function to the methods of the class. The built in initialization of the 1456 engine could take place anyway by calling the function from within the 1456 engine when the 1456 engine starts up. However, as that feature would only be needed for this web based simulation of a DVB-MHP terminal and not for a real DVB-MHP terminal, it may perhaps be best not to implement it and just make mention to anyone using this particular 1456 applet landscape for simulation work that care needs to be taken to have the 1456 software initialize all variables directly and not to presume them initialized by the 1456 engine at start up.

Nevertheless when the 1456 engine is being updated I will consider adding in such a reinitializatiom method to the Engine1456 class.

Secondly, although all of the simulation of the buttons of the DVB-MHP terminal is unaltered, there is an addition to the simulation of the DVB-MHP mouse for the use of the mouse in this program with a 1456 engine. This is that if the DVB-MHP mouse is simulated as being attached, when its button is pressed, the coordinates of the point on the screen at which it is pressed are placed by simulated direct memory access into two items of integer memory of the 1456 engine. The x coordinate is placed in element 5 and the y coordinate in element 6. These numbers are for historical reasons of the 1456 system and are chosen for compatibility with other 1456 applet landscapes that are available in this webspace. Thus a 1456 program has the coordinates on the screen at which a mouse press took place in case it wishes to use them.

Thirdly, it would be desirable if the 1456 object code program is able to find out whether there is a mouse attached. This is achieved by using a simulated software interrupt with a parameter of 41. That is, the software 41? is included in the 1456 object code program. If a mouse is simulated as being attached, a 1 is placed in the integer accumulator register; otherwise a 0 is placed in the integer accumulator register, that is in the ai1456 register. The choice of 41 for the parameter is so as to match the code of the mouse press. It did not need to be 41 that I chose in writing the software; it just seemed more convenient to do that.

Please note that although the structure of the polyglot compatibility section is in the program, the polyglot compatibility section is empty as no strings are displayed on the screen by this program.

However, the concept of a polyglot compatibility section is incorporated in the structuring of the 1456 object code programs. Unicode characters are enterable in 1456 strings. A Java program wishing to use unicode character U+hhhh, where hhhh represents four hexadecimal characters, uses \uhhhh for encoding that character. A 1456 object code program uses 'uhhhh for encoding that character.

Here are links to viewing the web based simulations. A Java enabled browser is required.

The simulation of the harmonograph runs as fast as it is programmed. The delay loop of the ast00802 program is included but it is commented out. The program that runs is thus the equivalent of the ast00804 program. It draws the picture considerably slower than does the ast00804 program yet rather faster than does the ast00802 program.

It is thus quite possible to produce a display fast enough for an eye catching exhibition display using 1456 object code, though the speed will depend upon the microprocessor system used in the hardware of the particular DVB-MHP terminal used.

The web based simulation of 1456 object code upon the DVB-MHP platform, plain program.

This program has no effect, as explained in the main text of this document.

The web based simulation of 1456 object code upon the DVB-MHP platform, some graphic shapes.

Please click on the coloured buttons of the simulated hand held infra-red control device. This ast00902.htm file simply demonstrates that a few changes from the contents of the ast00901.htm file are all that are needed to produce a different effect on the screen of the simulated DVB-MHP screen display, as the same ast00901.class Java class file is used.

The web based simulation of 1456 object code upon the DVB-MHP platform, demonstration using quaternions.

This program allows the rotation about three axes in three-dimensional space of a triangle. 1456 object code has quaternions amongst its standard data types. This program is really just to show how magnificent screen effects can be produced by fairly short 1456 object code programs that make use of the quaternion facilities of the 1456 engine. Traditionally quaternions are regarded as quite an advanced part of mathematics, maybe even somewhat obscure. However, they are very useful for computing rotations and deserve to be more widely known. A person who has mathematical knowledge at the level of using complex numbers in scientific and engineering applications may perhaps be pleasantly surprised as to how straightforward using quaternions can be in computing rotations in three-dimensional space. This is explained in two of the documents in the series of documents on 1456 object code in this webspace.

The web based simulation of 1456 object code upon the DVB-MHP platform, mouse detection.

Courtesy link to ast00601.htm for comparison.

These two programs should produce identical effects upon the screen. These program demonstrate the use of the mouse and also demonstrate that a 1456 program can, for some situations, produce an identical display on the screen to a program written directly in Java.

The web based simulation of 1456 object code upon the DVB-MHP platform, harmonograph.

Courtesy link to ast00802.htm for comparison.

These two programs should produce identical effects upon the screen, though at different drawing speeds. The programs take quite a time to run and may cause the browser to be unable to run another Java applet until they complete their running. The user may need to close down and restart the browser in order to avoid waiting. The ast00802 program has a delay loop in use, whereas the program in ast00905.htm does not use a delay loop.

Courtesy link to ast00804.htm which is the direct Java version without a delay loop.

This document thus sets the scene for the possibility of 1456 object code becoming a useful method for the preparation of content for broadcasting upon DVB-MHP channels around the world.

Astrolabe Channel

Copyright 2001 William Overington

This file is accessible as follows.

http://www.users.globalnet.co.uk/~ngo/ast00900.htm