Hydraulics ReseardtWalingford

USINC TIICBOCOUSUIER GRAPEICS TO

DISPI.AT NUUERICAL TrcDH" BESIILTS;

Stuart Davidson

Report I{o. SR 52uay 1985

H Y D R A U L T C S R E S E A R C I l J 4 I I V I . .

WALL INGFORD. OXON.

- 6 JUN I9B5

Registered Office: Hydraulics Research Limited,Watlingford, Oxfordshire OXIO 8BA.Telephone: 0491 35381. Telex: 848552

@Cror r , Copyr igh t 1985

Pub l lshed by permiss lon o f the Cont ro l le r

o f t l e r M a j e s t y t s S E a t i o n e r y 0 f f i c e '

This report describes work carried outunder Cont,ract, DcRl465/31, funded by theDepartment of Transport from April L982to Mareh 1984 and thereafter by theDepartment of the Environment. Anyopinions expressed in this report are notnecessarily those of the fundingDepartment,s. The DoE (ESPU) nominatedofficer was Mr A J M Earrison. The workwas carried out by Mr S Davidson in theComputer Services Department ofHydraulics Research, Wallingford. Thecontract lras managed by Dr A J Brewer.This report is published nith thepernisslon of the Departuent of theEnvironment..

ootmtTs

INTRODUCTION

DESCRIPTION OF CRAPHICS EQUIPMENT

PageI

3

345

7

7916

2 .L2 .22 .3

3 .13 .23 .3

FICI'RE 1

FIGI]RE 2

The graphics controller

The frame buffer

The colour prlnter

DESCRIPTION OF GRAPEICS SOFThIARE

The hard copy facillty

The result fi le dlsplaY facllitY

The editor

INTRODUCTIONEarly in the investlgations lnto the feasib{Lity ofusing a m{cro-computer based colour graphics systeu atllydraulics Research showed that nriting programs toefficie'ntly control such a system requires anunderstandlng of raster techniques and colour theory.

In order to obviate the necessity for the Hydraultcengineer to acqulre such an understanding, researchwas aimed at designing prograns that aLlowed themaccess to the colour graphlcs facllities througheasy-to-use cursor and keyboard controls.

To this end, the fol-lowl-ng programs nere designed andwr l t ten :

(a) An edltor to manipulate displayed irnages.(b) A print program for displaying hard copies

of colour images.(c) A prograu for displaying result f l les from

matheuatlcal models as an ani.mationsequence.

Methods of video recording or filning the displ-ayimages were disiussed with the Photographic Sectiouand advice was sort from outside companles. Severalwere tried and investigatlons continue.

As the research progressed, further areas of interestpresented theuselves and the shortcomings of the baslckit being used became apparent.

The feye catehing' feature of colour images could beuseful ly exploi ted for publ ic i ty purposes. Agraphical presentation of llydraulics work would bevisually striking and informative.

To produce more neaningfuL realistic inages a widerrange of colours would be required. If this werecomblned with a device such as a pallette or light penthat exploits the user-fri.endliness of graphics thenthe system would be open to a wider range of designappl icat ions at Hydraul ics.

Animation of results from mathematical nodels helpedto clar i fy the results. To extend this faci l i ty tomore complex models, a more powerful processor wouldbe required. To sat isfy this requirement asophisticated graphics terminaL could be connected tothe uainframe computer. Thls would also circuuventany restrlctions imposed by transferring resul-ts tothe micro-computer.

Accuracy would be lmproved with a higher resolution'this would enabl-e more complex images to bepresented

Some of these improvements could be achleved at littleext,ra cost.

2 DESCRIPTION OFGRAPEICSEQUIPMENT

2.L The graphicscontrol ler

Pluto is an lntelligent graphics cont,roller. In ltssimple form the system resides on a single board whichcontalns the followlng:

Intel- 16-blt micro-processor192 K bytes Frame bufferGraphics routlnes in flrmwareExpansion Bus for adding extra features

The version of Pluto used for this lnvestlgation wasthe basic board wtth a high resolution option. Thisprovided a choice of eight colours and a resolution of640II x 288 V or 576Y in the hlgh resolution mode.

The system rdas connected to an ACT Sirius 1 mierocomputer which also uses the 8088 micro-processor.With the Pluto card housed ln ao external case,connectlon to. the Sirius was through an interface cardin the Sirius expansion BUS.

To display images, a Cotron Sword uonitor wasconnected to the Pluto.

To access the graphic routines frou a hlgh levellanguage such as Fortran, an assembler library is a

required.

The purpose of the routines ln the Llbrary is to actas an lnterface. Sending data from the call-ingprogram to the address in the hosts memory to shichPluto in connected.

The assembler library originalLy supplied with thesystem was not, suitable for Microsoft, Fortran as usedon the Sir ius. The reason for this was thaE thlsversion of Fortran is able to address outside the 64Klirnit norually irnposed by 16-bit mi.cro-processors andso i t uses r long data pointersr. These areeffect ively 20-bi t wide addresses composed of asegaenE address and an offset within the segment.

Another assembler llbrary was ordered which was ableto cope with the longer addressing space. Thislibrary dld not provlde an int,erface to all the Plutographics routines and so some of these had to bewri t t ,en.

2.2 The Frame bufferOn the baslc Pluto system the frame buffer ls 192Kbytes ln slze. This relatively large amount ofmemory is required because Pluto uses rastertechnlques to display the inage.

Wlth raster displays, each plcture element (pixeL) onthe screen is cont,rolled by a memory Locatlon in theframe buffer.

The value of a location determLnes the colour of thecorrespondLng pixel.

The Lnage ls dlsplayed on the screen by scannlng thefrane buffer in a sinilar manner to that ln which a TVscreen ls scanned. That ls, horizontal lines from thetop Left corner down to bottom right corner andrePeat .

The frane buffer nust be scanned and the imagerefreshed onto the screen many times per second inorder to achieve a r f l icker freet display.

In PLutors low resolut,ion mode, the lnage iscompletely refreshed onto the screen every 1/5oth of asecond.

To achleve the higher resolution of 640H x 576Y, Plutouses interlace teehniques.

Interlaee is a means of producing a high resolutionimage wlthout the associated flicker problems ofscanning a larger frame buffer. This is achieved byscannLng only half of the frame buffer each time. Onone pass the locations controlling even numbered pixellines are scanned and on the next pass, locationscontrolling odd numbered pixel Lines are scanned. Theresult is that new information is stil l beingdisplayed every 1/50th of a second.

In the version of Plut,o used, each locationcontrolling a pixel conslsted of 3-bits. This gave arange of eight possible colours.

These 3-bits can be thought of as controlllng t,hethree primary colours red, green and blue. Therefore,the whole frarne buffer can be thought of as threecolour planes.

The varlous combinatLons of bits being set/unsetproduces the range of colours: Black, Green, Blue,Cyan, Red, Yellow, Magenta and White.

The 192Kpixel s:

( i . e . 6 4 0

The fra'nemanner.

frame buffer supports 640fi by more than 800v

;

x 800 x 3 = 1536000 bi ts = 192000 bytes)

buffer is divided up ln the folloning

Ag'8I+

88v+

2!+V

- ) Lo-res

I Par t i t ion 1

I Lo-res

I Part l t lon 2

I General worki

f srnbol partit

I l i-res iPar t i t ion 0

ngio

space andns

2 .3 The coLourpr lnter

The frame buffer ls dual ported enabling it to beupdated and displayed on the screen slmultaneously.

A Diablo Series C ink jet prlnter was connected to theparal lel port on the Sir ius.

The Diablo provides four basic colours: thesubt,ractive primaries cyan, yellow and magenta. Blackis also provided because, in pr int ing, i t is di f f icul tto obtain a deep black by conbining colours.

The colours cyan, magenta and yellow are thecomplements of the additive primaries red, green andblue respect ively. These subtract lve pr imaries areprovided because in common with other colour hard copydevices the Diablo is based on the CltY colour model.

The basis of the CMY colour nodel is that colours arespecified by what is rernoved fron white light. Whitelight is the sum of the additive primaries red, greenand blue.

As an example: removing red from white light leavesgreen and blue and these combine to produce thesubtractive primary cyan.

Therefore, a surface coated with cyan coloured inkabsorbs red l ight and ref lecEs blue, green. Also, asurface coated with cyan and yellow absorbs red andblue and reflects green fron i1luninat,tng white1 igh t .

Whilst the Diablo is based on the CMY colour model,the Pluto ls based on the RGB colour model.

The basis of the RGB colour nodeL is that colours arederlved from what is added to bLack rather than whatLs subtracted from white f.ight

The Lndivldual contributl.ons of each primary are addedtogether to form the resulting eolour.

Knowledge of both the CMY and RGB colour models wasimportant when writing a routine to copy a screenimage from PLuto to the Dlablo.

3 DESCRIPTION OFGRAPEICS SOFTI{ARE

3.I The hard copyfacility

mrs fa'crl-ity produces hard coples for screen lmages.The following requirements dictated that the routineshould be nritt,en in a language other than Fortran:

r The routine should be as fast as possibleo Perforn logieal operations on all bits in

byteso Send commands dlrect to the printer port

(unforrnatted)

To satisfy these requirements, the routine !ra6 writtenin 8086 Assembler and incorporated in the assemblerint ,erface l ibrary.

The Diablo provides a bit pattern printing mode whichprints four pixel- lines at a time. The format of thecornnand ls: information specifying the colour, numberand length of the pixel 1lne followed by a string ofbytes specifyLng the bi t pattern to be pr inted.

Readlng the Pluto bit planes into individual stringsof bytes formed the basis of the bit pattern requiredin the printing conmand.

The following example of printing cyan on the Diablodeuonstrates reading indivldual bit planes andproducl-ng a bit pattern for the print cbr"mand.

Perform logicaL OR on bytes holding blue and greenplanes:

00110011010101016TTI-T'-]N

Perform logieal NAND wirh byte holding red plane:

0 1 1 1 0 0 0 0

Line of pixel-s - B G B C R Y M Wl r l y e e a ha e u a d l g lc e e n l e tk n o n e

w ta

Read Red plane - 0 0 0 0 1 1 1 IRead Blue pLane - 0 0 I 1 0 0 1 1Read Green plane - 0 1 0 1 0 1 0 I

This will reoove any bits whlch represent pixels withred ln them. This ls effectively subtracting red fromwhite light as detail-ed in CI'IY nodel example.

the bit pattern printlng conmand and thls byte wouldnow be s'ent to the Dlablo to prlnt cyan.

By repeatlng thls process and using the appropriatebit planes at each stage we also print nagenta andyellow.

The result is that both the subtractlve and additiveprimaries are produced on the Diablo. The additiveprimarl.es are produced where the subtractive prlmariesoverlap. For instance, where cyan and ye11ow overlapgreen wlll be produced.

Note: the Dtablo does not prlnt bl-ue because magentaand red overlap to produce violet,, however, this lsusual ly adequate.

Printing black required a slightJ-y different approaeht,o that used for the subtractive primaries. Thereason for this was that colours ln the RGB nodelcombine to produce white whereas they conbine toproduce black in the CMY nodel ( i .e. a locat ion in theframe buffer with bits set ln the red, green and blueplanes would produce a white pixel whereas, printingcyan, magenta and yellow on the Diablo would producemurky black.

To obtain a bit pattern representing blaek pixelsperform a logical NOT on, sayr the red plane:

1 1 1 1 0 0 0 0

Perform logical NAND withr sayr the blue plane:

1 1 0 0 0 0 0 0

Perform logical NAND with the green plane:

1 0 0 0 0 0 0 0

The resulting bit pattern represents the only bl-ackpixel in the exarnple. This would nos be sent to theDiablo as part of the command to print black.

Coping with distort ion in hard copies

To enable an image from one of the low resolutionpartltlons to fil l the screen, the refresh mechanism

3 .2 The result f i ledisplay faei l i ty

leaves alternate pixel lines blank. These blank linesare only noticeabLe when viewlng the screen from avery short distance.

The result is that taking a copy of alt locatlons inthe partition would produce a print, such as Fig 1.

Whereas the ratio of width to height should beapproximately 1:1 as displayed on the screen.

To luprove.the proport lons of the picture blauk l inescould not have been introduced in the hard copy sincethese would have been noticeable. Instead, everypixel line was duplieated.

Essent,ially the screen dunping rouLine detects when alow resolut ion part i t ion ls being displayed. Nornal lythe routine would read 4 pixel lines at a time sincethe Diablo prints 4 at a tlme. However, ln the caseof low resolution only 2 pixel lines were read. Arblt shufflingf routLne then expanded the string ofbytes into a str ing represent ing 4 pixel l ines.

Although the 'bit shufflingr routine had to be used oneach bit-plane for every two pixel lines it was not aconsiderable tine overhead. This was because lt usedhardware implemented string operators in the 8086Assembler.

Using the rbi t shuff l ingr rout ine produced picturessuch as FLg 2

The resolut,ion of the D1ab10 is 1024I{ x c and thePluto is 640iI x 288V (or 576V). Sinee the physicalwidth of the paper and the screen are simllar thismeans that a pixel on the Diablo is approxLmaxeLy 2/3the size of a Pluto pixel

The result is that a ful-l screen dunp of the Plutoappears 2/3 tne size on the Diablo.

To overcone this def ic iency i t would be possible torestrict the amount of the screen to be dumped to 512vin high resolution mode or 256Y in 1ow resolutionmode. Then double each pixel in both directions andprint the inage sideways on the Diablo. Note: in lowresolution each plxel would be quadrupled vertically.

Thls option may be provided in future.

The result f i les used for display purposes, dur ing theinvestigation were produced on the ICL 2972mainframe.

These were transferred to the Sirius by using aterminal emulatLon package on the micro. This

package makes the nlcro appear to the mainframe as aRemote Job Entry (RJE) statlon. The RJE siatioucomprises an operat.lng coasole, virtual line printerand two interactlve terminals.

a

Listing a result fi le from any mainframe terminal tothe nlcrors virtual line printer and controlling thetransfer fron the RJE console enabled the fILe to beplaced on the mlcrors disk.

Format

The flles represented regular grids with real numbersdefining the value of each grid ce11-. These realnumbers represented a wide range of val-ues. However,since Pluto could only display eight colours and thecodes for these were the integers 0-7 there waslnitially no need to transfer the file with realnumbers.

A routine was writt,en and used on the nainframe toconvert ranges of real numbers into single Lntegers.It was fel-t that the tine saving ln transferringvalues as singl-e byte iotegers rather than, sayr sixbyte reals would be valuable. Especially whentransferrlng files containing l-arge numbers of grids.

Displaying (ce1-L for cell )

To handle result fi les on the Sirius a Fortran programwas wrltten.

The prograu read the file header whlch containedinformation on the dimensions of the grid and thenumber of grids ln the fi1e.

The grid dimensions nere glven in terms of the numberof cel1s horizontally and vertically. If the numberof grids ltas greater than one it was assumed that asequence was to be shown and so the low resolutlonoptlon was used. This ls explained uore fully in theanimation section.

10

To determine the dimensions of a grid cel1 ln plxels:

Number vertLcal plxels =

rnreger value of (ffi)

Number horizontal pixels =

Nearest lnteger TNumber * Scal ing;value of

- \Verttcal plxels ^ factor

I f :

. ((Nunber horlzontal pixels x number vertical pixels) >

horizontal resolutlon) then

Decrement number verticalpixels and re-cal culate

I{lth the dimensions of a grld cel1 deternined lnpixels, the program then read the values for a grldinto an array. It then stepped through the arrayplottlng the value of each grld ceLl as a colouredrectangl e

Using this nethod and wlth a1l- grids held in memory'the tine to update the screen ltas approximately 2seconds. This ls not only unacceptably slow butlinits on the amount of available memory could also bequite restr ict ive.

Limits on memory

It has been mentioned that Mlcrosoft Fortran canaddress outside the 64K code segment llnit. The liniton a llnked Fortran nodule is 384K.

This ext,ra space can be used to store arrays if theyare placed in named COMMON bLocks since named COMMONblocks are automatically placed in separate segments.A segnent may be up to 64K bytes in size which is alsothe maximum slze of a Fortran array.

If a typlcal grid produced on the DAP represented a64 x 64 array and each element or grid eaLl wasrepresented by a single integer in a byte then thegrld would occupy 4K bytes. Therefore, sixteen suchgrids could be held in one array in a named COMMONblock .

Up to flve of these maxlmum sized COMMON blocks coul-dbe declared in the 384K link nodule slnce at least 64Kwlll be required for the Fortran code and assemblerinterface l ibrary etc.

The result ls that an animated sequence coul-d containapproximately 80 such grids, all held in memory. Thiscould not only prove restrlctive but the time to readthe file (s) into the arrays lras unacceptably large.

1 1

To overcome the restrictions of thls nethod of displayand holding al1 grids in nemory, Run Length Encodingwas used with unforn:rtted flles

Run Length Encoding (RtE)

Iu a typical image the amount of eontinuous space ofthe same colour ls often qulte Large. The basis ofRLE is both to reduce the amount of lnformation

'required to code this space and reduce the amount oft ime to dlsplay i t .

For Lnstance, a line of 64 grid cells aLl the samecolour would nornally requlre 64 bytes of data to codethem and 64 separate rectangLe plotting commands todisplay them. Ilowever, with RLE the amount of datacan be reduced to 2 bytes. One representing thecolour and the other representing the number of cells.The program Lnterpreting this RLE data would know the

-dinensions of a grid ee1l and so just one rectangleplot coronand would display the whol-e Line of cells.

Unformatted flIes were used for storing the RLE databecause these are more efficient, in terms of speed,than foruatted. Sequential access was used since Lhisis faster than direct access.

A disadvantage of RLE 1s that it can be difficult toedit the data. For instance, lf the colour of a gridce1l in a line of celLs of the same coLour is to bechanged. Then a new field would have to beintroduced, assuming a record represents the wholelmage.

For this reason RLE was not used on the mainframebefore files were transnitted even though the possibledata compressl.on would have been great,er than the realto integer converslon mentioned earlier.

Produce RtE data

The following flow chartfiles from the mainframecontaining records whlchforn.

demonstrates how resultswere convert,ed to filesrepresented grids ln RLE

L2

i

Open result f l le

Open RLE file

Read grid

from result f i le

Display

cell for cellI

RLEi

routine

i

Write ' record to:

RLE file

13

The RLE routine sklpped to the top left corner of eachceI1 as displayed and returned the value of the pLxel.In this way an array was bulLt up whLch included anychanges nade by the editor. The coot,ents of thisarray were then run length encoded and written to theoutput f i le as a single record.

Producing anirnatl.on

In an animatlon sequence the vlewer shorrld not see thescreen being updated. This can be achieved on PLutoby using the two low resolutl.on partitions ln theframe buffer.

The program nas writ,ten to display a sequence ofgrids. The prograe designated one partltion to beupdated and the other to be displayed. A record wasread from the RLE file into an array, thls run lengthencoded data was wrltt,en to the partition to beupdated. When complete, the assignment was swappedand the next record was read, etc. Thls reduced theupdate tlme to approxlmately 1 second. Also, l-initson nemory lrere not a problem because data for only onegrid was held in memory at any one time.

Distortion of dis-played inages

Low resolution images are able to fil l the sereen byleavlng alternate blank pixel lines, whereas hi.ghresolution images use all pixel 1ines.

This results in displayed Lnages requiring dlfferentscaling factors to be applied, depending on whether ahigh or low resoLution screen is used.

Applylng these scaling factors would very likelyresult in lengths with a decinaL fraction. When theseare displayed in pixels they must be whole numberssince a pixel ls the smallest displayable element.The conversion to integer inevlt.ably lntroducesrounding errors. This ls known as the Inearest

integert method.

If this rounding error is present in the width of eachgrid cel l , i t is possible that a not iceable distort ionwould appear in a l ine of, say, 64 cel ls.

Applying the seal ing factor to lengths of cel1s of thesame cotour, as would be possible with RLE data,prevents the cumulative error building up but Lheoverall width of the inage becomes unpredictabLe sincethe nuuber of colour changes is not known. Therefore,thls nethod is less desirable than the previous one.

L 4

In an effort to eircumvent the problem of a cumulativeerror building up, the following method was used. Itls best explained by pseudo-code.

FOR N = 1 TO NIJMBER-OF-IIORIZONTAL-CELLS

REA],-CELL-I{IDTE

SIn{-OF-CELL.WIDTHS

SUM-OF-CELL-I{IDTES

CELL-ITIDTH(N)

HEIGUT_OF CELL xSCALE FACTOR0

SUM-OF-CELL-WIDTI{S +REAI-CELL-WIDTIINEAREST INTEGER

(suM-oF-cELL WTDTES +RXAJ.-CELL-WTDTE) -

NEAREST INTEGER( sttM-or-cELL{,lrDTES )

0 tne\r cELL-wrDTH (N) = trF cELL-WrDTn (N)REPEAT

NB: A cell nlth rdidth 0 ts avoided because this wouLdresuLt in data being l-ost from the displayedinage.

This nethod prevents the cumul,ative error exceeding La pLxel. Ilowever, when thls is compensated for theeffect ls quite severe in that a pixel- is dropped.Thls could cause problems when tbuttingr nultiplegrids together in the same display.

AIso, preventing a ceL1 width of 0 effectively meansthat a flne grid of approxinately 1 pixel per cell isable to buil-d up a cumulative error. This wouLdcertainly cause problems when trying to tbuttt such agrid onto ones which have no cumulative error.

The result is that both methods of displaying gridshave their own merits. During the Lnvestigati.oa, theInearegt integert method was used,

Mulr iple Grids

Any distortion in a grid can appear very uuch worsewhen several grids with different cel1 sizes aredisplayed simultaneously. This is because the gridsmusL rbut,tr up to each other exactly and a singlepixel l ine'discrepancy would be very not iceable.

In a standard multiple grid, the cel1 sizes vary by afactor of three. The origins of the finer grids arespecifl.ed in terms of their cell sizes from the topleft corner of the coursest gr l .d.

15

3.3 The ed i to r

Using this coordinate system and the methods' fordisplaying grids mentLoned so far, the grids wi1-lpossibly fai l to rbuttr together. Especlal , ly Lf afine grid where one cell is represented by one pixeLls used.

Some wotk has been done to overcome these problens andgrids have been 'buttedr together by using a dlfferentcoordinate system. In this system the finer gridorigins were speclfied in terms of the next coursestgrld ce1ls from the next coursest grid origin.

Ilowever, this method was not robust enough to be ageneral case. Also it relies on non-standard resultfiles whereas the intention was to use standard ones.

The result in that a suitable robust and generalmethod has not yet been developed. However, thisproblero will be addressed in the near future.

In addltion to displaytng inages, a facillty tomanipulate then was al-so required. To satisfy thisrequirement a basic editing program was developed.

The edltor was writ.ten in Fortran, providing aninterface to the rout,ines in the assembler library aswell as other Fortran routines.

I t provldes a mean of al ter ing that part of Plutorsframe buffer which ls being displayed.,

The user interacts with the editor by usLng thekeyboard and single let ter, keyword select ion - ( i .e.press tPr for pr lnt) . The cursor is manipulated bythe numeric keypad on the right of the keyboard.

The edltor has a modular structure. This provedvaluable during the investigation since new facilitiescould be tried and tested sinply by adding e:rtrasubrout ines.

L 6

iSet part i t ion towork on to that,' displayed

Open console asunfornatted fi le

Keyboard lnputroutlne

Enlargingroutlne

Key displayroiltine

Cursor moveroutine

Select colourroutine

Flood fi l lroutine

Text pr int ingroutine

Dunp to discroutine

Load frondisc routine

En1 arging routine, fEr

This routine enlarges any part of the screen by afactor of two. The area to be enlarged is shown byXORing a rectangle onto the screen.

To deflie the rectangJ.e the cursor is moved to thebottom right hand corner of the area and the rRr keyls pressed, the cursor is then moved to the top lef tof the area and the r l f key is pressed.

The routine checks that the rectangle does not exceeda guarter of the screen since if thls were expanded itwould not flt. If the dimensions are within linitsthe rectangle is dtsplayed.

The cursor can then be moved to the top left corner ofwhere the expanded box will be displayed. The rE I keyis then pressed again and the routine checks that thecursor ls not too near the edge of the screen.

The rectangle ls then XORted agaln to erase it and theexpanded version Ls displayed at the new cursorposition. Eaeh pixel is expanded into four

Print i .ns rout ine rpr

The routine enables any part of the screen to beprinted on the attached Diablo pr inter.

The area to be printed ls defined by XORlng arectangle onto the screen in the sarne way that theenlarge routine does this. However, no checks aremade on the rectangle diuensions.

The user is able to check that the displayed rectangleencloses the area to be pr inted. I f t t does, therectangle is XORred again to erase it and the area isdumped to the Diablo.

The sereen dump routine is described more fully in thethard copyr sect ion of this report .

Key display rout ine rKl

This routine provides a means of displaying thosecolours available for line drawing, flood fil l ing andboundary f111lng.

The rout ine displays a ser ies ofalong the top left corner of theare arranged from left to rightcode order ( le Black 0, Green 1,4, YeJ-low 5, Magenta 6 and White

coloured rectanglesscreen. The colours

in ascendlng colourBlue 2, Cyan 3, Red7 ) .

1 8

To experiment wlth ruixing various colours a shadingroutine was written for use on earLier verslons of theed i to r .

The routlne produced rectangles which consisted ofvertlcal, pixel wide bands of any two colours- From ashort dlst,ance the bands appeared to bLend togetherlnto the required shade. (ie Alternate red and yellowappeared as Orange).

However, thl.s nethod of obtaining extra colours is nolonger available on current versions of the editor.The reasons for this are:

- The mixed colours were rather dulleompared to the primaries.

- The Pluto rpattern fil-l | .cornmand had to beused to twall papert areas of the screen'this was slow and restr ict ive.

- Plut,o is easily nodified to an 8-blt planenodel and hence 256 colours.

Select colour rout ine 'g '

Thls routine provi.des a means of changing the currentand perimeter colours for line drawing, flood fil l lngand boundary fil l-ing.

The cent,re of the cursor is placed over the desiredcoLour in the key and the '0' key pressed.

If the Y-coordlnate of the cursor falls within theheight of the key a sinple algorithn is applied to theX-coordinate to deternlne which colour the cursor issuperimposed on.

A display on the right of the screen is updated to thecurrent colour.

Cursor move routine

The cursor is defined as a whlte cross hair which lssuperimposed onto the inage without naking anydestruct ive changes.

Movement is affected by the nurneric keypad on ther ight of the keyboard.

Key f5r actb as a toggle switch to set a trai l . I fthe switch ls rorlr a line of the current colour lsdisplayed as the cursor moves. The trail is not

l 9

XORfed on to the screen so that a perimeter can bedefined for boundary fil ls.

Key r. t acts as a t toggler switch to determine by howuuch the cursor ooves. The options are 1 or 10 plxelsin any direction

Keys 1-4 and 6-9 deLermLne the direction of movementof the cursor. Continuous movement Ls achieved byuslng the frepeatt key.

F lood f i l l rou t lne rF ' '

This inplements Plutors flood fil l connand. The pixelat the cent,re of the cursor and aLl connected pixelsof the same colour are changed to the current coLour.

Boundary fil l routine rB I

This is a sinple implementation of Plut,ors boundaryfill conmand.

The area enclosed by the perimeter colour is fil l"edwith the current colour.

Text. printing rorltine tWr

This routlne enabl-es characters to be prlnted on thescreen in any one of four directions.

When the fWr key is pressed the cursor is XORred offthe screen. The direct ion for pr int ing text isselected from keys 2, 4, 6 ot 8 as for cursormovement. Once the direction has been selected, anykeys pressed are echoed onto the screen in thatd i rec t ion .

Pressing rreturnt redisplays the cursor at the end ofthe text.

Dump to disc rout ine rDr

ThLs routine copies that part of the frame bufferbeing displayed to a disc f i le.

When the rDr key is pressed the.user is pronpted forthe name of a file to use. The screen is then copledto the file, unformat,ted.

Load from disc rout ine rLf

Thls is the complementary rout ine to tdump to d isc! .The contents of the named fi le are loaded into thepart l t ion current ly being d isplayed.

20

Figure 1

F igure 2