One of the few spin-off advantages of the lockdowns was having time to do some serious messing^W investigating. One such rabbit-hole started by looking at the structure of GEORGE 4 programs on disc. That led to a few discoveries not covered in TP4412 Central Processors, which otherwise does a pretty complete job of documenting the ways in which a binary 1900 program can be stored on various media. These initial details my be seen at Sparse Program Layout
Following on from acquiring an understanding of G4 sparse/shared program images as used by GEORGE 4, I decided to try the obvious next step - to try loading and running one. A trusty G3 system was brought up and a selection of G4 programs were copied into a new directory:
Step 1 - Try loading
LO :LIB.PROGRAM XPCH - this resulted in a fairly expected error, viz:
ERROR IN LO :LIB.PROGRAM XPCH CONTAINS A SPARSE PROGRAM WHICH CAN ONLY RUN UNDER GEORGE 4
OK, that was expected, the next step was to look into the LOADPROG chapter of GEORGE3 (we don't have G4 specific source). This code checked the request block of the file to be loaded for the SPARSE program indicator bit and if set, jumped off to report the error seen above.
So, lets MEND that out. - This one-word patch to GEORGE 3 resulted in
LO :LIB.PROGRAM XPCH giving a different error regarding an invalid core size.
So trying a sort of obvious next step after that error:
LO :LIB.PROGRAM XPCH, CORE 200K
It loaded! A few PTs of the image showed that it looked ok, so a few semi-standard investigatory commands were issued:
AS *LP
AS *CR
MON ON,OPEN
EN 1
It prompted for input, expecting a consolidator steering deck, a valid #XPCK directive was tried. The resulted in #XPCH correctly signing on. - It is double-buffered so the effect of any commands is always one behind. Typing **** caused it to halt with some messages.
This essentially silly experiment showed that the common set of the source between G3 and G4 was robust enough to allow a large G4 image to be loaded by a very slightly modified G3 (provided there was plenty of swapspace and various quotas). It was possible to actually use #XPCH to corectly consolidate normal dense (unpaged 1900) images and have them run. The next text was to try to consolidate a sparse program. - This was going too far, and an illgal instruction was reported. XPCH had obeyed the G4 167 X=2 'HIVE OFF NEW PROCESS' extracode.
To read more of this, read here