Previous: Internal directory and Buffering
Up: Keyed Files and PDisplay
Previous Page: Internal directory and Buffering
Next Page: Chainer and MarkJump

Storage of port images for Layout messages

The port definitions contained in the layout type of message are implemented by actually initialising a port record with a copy of Ports's routine ptDefine, and inserting the binary image of it into the keyed file as a message item. This method presumes that either a single graphics resolution, known at ``mulch'' time, will always be used by the dialogues, and that ptDefine can assume this resolution when assigning the port's dimensions; or that if the program may be run in different graphics resolutions, the binary image can be dynamically altered to fit the runtime resolution.

But since the DOS versions are to be portable across as many PC graphics adapters as Borland Graphics will support (at least), the first assumption is no longer true; and because screen design often requires ports to be located on the screen to exact pixel tolerances, no reliable technique for scaling a single port definition while retaining reliable screen positioning was found in the time available.

The mulcher was therefore updated to create 3 port record images from a single definition: one for each of the vertical screen resolutions commonly used on PC's at the time 200 deep, 350 deep, and 480 deep. .

However, since PDisplay might well be used on keyed files created by either or both versions of the Mulcher, an extension to the storage method for the binary images was created to let it determine which sort of keyed file it's using:

• The former storage scheme prepends to the port record a byte containing the index, assigned by the Mulcher, into the 16-element table of ports that Keyed Files keeps internally for storing its layout ports. Keyed Files will store the record into that element. So any value of the leading byte over 16 was illegal.
• The new scheme puts a tag byte of 128 in the first byte of the record. This informs keyed files that 3 more overhead bytes follow:

  1 word (2 bytes)

  giving the vertical graphics resolution at which the port record was defined.

  1 byte

  which is the true index for the port, assigned by the Mulcher.

• Mulcher inserts the parallel port images for a single definition command in increasing order of the graphics resolution at which they were defined. It then expects Keyed Files to check those resolutions against the runtime host resolution; and if the ports' presumed resolution is less than or equal to the runtime resolution, replace any previous definition for that port with the newly found one; otherwise it is to retain the previous definition.

This scheme ensures that, though Keyed Files may wind up using a version of the port smaller than appropriate for the runtime resolution, it will never use one too large, which might then go off the screen.

Regrettably, the expansion in size of each keyed file, due to containing equivalent copies of each port record, is not trivial. (This is also partly due to the fact that Turbo Pascal packs the fields of ``packed'' data structures only to the byte level, whereas the p-machine packs them to the bit.) It is nevertheless not unmanageable with the larger media capacities that are becoming more common. It does not in any case compare with the expansion in executable Intel code size over the size of executable p-code files.

It is of course necessary to assure that this updated version of Keyed Files (in practise, the PDisplay unit) is always used, since if the previous one encounters an index value of over 16, it will crash.