Cegmon User's Guide

a new monitor for OSI and UK101 BASIC-in-ROM systems user's guide Warranty terms There is no warranty, either expressed or implied, for CEGMON in any version. CEGMON is sold subject to the distributor's standard conditions of sale, copies of which are available on request. Although it has been extensively tested and is believed to be error-free, there is no guarantee that any of the software will operate under conditions not noted in this User Guide. Despite the above, we would be grateful for any comments regarding CEGMON or on any possible faults which may appear, to help us in developing future versions. Licensing and copyright terms CEGMON and its documentation are protected both by copyright and also by our standard licensing agreement for software (copies available on request). In essence, you have bought a 2716 EPROM and associated documentation, and a licence to use the software contained on or in it for your own purposes on your own computer. Copying all or any part of the software onto any medium or into any retrieval system and/or using this on a computer not owned by you is expressly excluded from the terms of your licence and would constitute a breach of contract. CEGMON © 1980 George Chkiantz, Richard Elen, Tom Graves Sold under licence and distributed by Mutek, Quarry Hill, Box, Wiltshire, England Documentation prepared by Wordsmiths, 19a West End, Street, Somerset BA16 OLQ Introduction CEGMON has been developed to provide you with the kind of firmware support that you need to get the most out of your computer. When Ohio Scientific wrote their SYNMON monitor, in the none-too-distant days of expensive computer memory, it is clear that cost was rather more important than flexibility or 'user- friendliness'. To save on cost, OSI's SYNMON 2K monitor chip actually contains 3 monitors for several different machines, and only a meagre /4K is used for each type. CEGMON uses the full 2Kof monitor space. The result is, we hope, a monitor PROM that gives your machine more features and flexibility than any computer in the price range, while retaining the greatest practicable compatibility with the existing firmware and software. Four versions of CEGMON are available: for standard Superboard or CI; enhanced (32X48 display) Superboard or CI; UK101; and C2 or C4. In the following notes the versions are referred to as C1, C1E, 101 and C2 respectively. The main features of CEGMON are: O a screen-editor for use with BASIC or assembler programs, linked directly to the system's call for keyboard input. • a revised keyboard routine, giving typewriter-like response, true ASCII key- values and direct access to most graphics. • a completely new screen-handler, formatting screen output within user- definable 'windows', with cursor control and direct 'window'- or screen-clear. • a full machine-code monitor for development of machine-code routines, which includes machine-code load and save in auto-start format, input of text or graphics as well as hex instructions, tabular hexadecimal display of memory contents, memory mover and breakpoint handler for debugging. • input and output from BASIC or assembler vectored through RAM, allowing direct linkage to user-defined I/O routines. • compatible design: entry points of all SYNMON main routines and most subroutines have been retained; OSI-compatible floppy-disc bootstrap provided on all versions, to support OSl's 610 or 470 disc-controller boards. Start-up On start-up, the usual array of random 'garbage' characters will.appear on the screen. On hittingthe BREAK key (RESET —101),the garbage will be replaced by the CEGMON 'D/C/W/M V prompt at the top of a clear screen. As with SYNMON, answer the prompt with D, C, W or M, to access Disc bootstrap, BASIC Cold start, BASIC Warm start or Monitor respectively. As with SYNMON, the BREAK reset necessarily resets all the input/output vectors, and also resets the current 'window' for the screen handler to the default values, i.e. text display on the full screen area. Accidental BREAK may be a nuisance in some applications, where the vectors or 'window' definition are important; it's probably a good idea, especially on OSI machines rather than UK101, to insert another switch in series with the BREAK key — and well out of the way! — to prevent accidental BREAK. 7 Keyboard The OSI polled keyboard is now decoded in true ASCII format, with one exception: the RUBOUT key is decoded as $5F (9510) to allow it to be used as a 'delete' key with OSI's BASIC or Assembler. The major change is that keyboard use with SHIFT-LOCK released is rather more predictable. The two shift keys are now decoded identically; carriage-return (CR), line-feed (LF), RUBOUT and (not 101) escape (ESC) are all accessible regardless of the state of SHIFTS or SHIFT-LOCK. Control (CTRL) returns the same value from alphabetic keys regardless of SHIFT or SHIFT-LOCK — i.e. CTRL-A and CTRL-a both return an ASCII value of 01; but the state of SHIFT-LOCK is assessed with CTRL for non-alphabetic keys, in order to access otherwise inaccessible characters in the range %7B-7F (123-12710). For the same reason, SHIFT and SHIFT-LOCK pressed together with alphabetic charac ters still produce a range of garbage characters, in order to allow SHIFT-K to -O to access the up-arrow and other characters in the range $5C-5F (91-9510). The BASIC line-delete, @, is decoded as SHIFT-0 (zero) as before, but not asSHiFT-P. SHIFT-O still functions as a character-delete, now working as a true backspace/ delete rather than the crude Teletype underscore; but it is simpler to use RUBOUT, which works regardless of the state of SHIFT or SHIFT-LOCK. The REPEAT key (not 101) is now used as a second control-key, to access the non- ASCII graphics in conjunction with other keys. Note that BASIC'sown input routine masks out most of the control characters and all character-values above ASCI I $7C (12410); however, the masking can be bypassed either by a USR call direct to the keyboard or editor routine, or through a machine-code 'stack trick' via the input vector, as shown in the program example on page 15. Another program example shows a non-halting 'GET' routine, called by a USR call from BASIC. • Screen handler CEGMON's screen handler is an entirely new design, applying the 'protected area' and 'scrolling window' concepts of editing terminals to the memory-mapped display system of OSI's microcomputers. All output to the screen is via a 'window' whose position, height and width are all user-definable, and can be changed simply and quickly within programs. Four non-destructive cursor-positioning commands are available, as is a 'window'-clear command, and also a separate total screen-clear. On start-up, the 'window' is largely identical with the existing formats for CI, C1E, C2 and 101. An obvious difference is that printing starts at the top of the screen, with a small allowance made for overscan. Scrolling only occurs when the base-line of the 'window' would be exceeded; until this happens, PRINTing on the screen is very much faster than under SYNMON. In all other respects, though, the start-up 'window' performs in much the same manner as under SYNMON, and most existing programs would not notice any difference. The cursor controls are as follows: CHR$(10) cursor down (line-feed) CHR$(11) cursor right CHR$(12) cursor home (to top left of 'window') CHR$(13) cursor left to start of line (carriage-return) While this is not a complete set, these controls will be enough for almost all requirements. For example, a practical substitute for the PRINT AT command of some extended BASICs — using cursor-home, cursor-down and cursor-right — is shown in the plotting routine in the program examples in page 18. 'Window'-clear is called by CTRL-SHIFT-N (CTRL-'up-arrow'), CHR$(30). This clears the current window and homes the cursor location, but does not print the cursor. By changing 'windows', it is very easy to blank areas of the screen selectively without recourse to the 'POKEs into the screen within FOR:NEXT loops' programming demanded by SYNMON. The screen can be cleared completely by CTRL-Z, CHR$(26); this also homes the cursor to the top left of the current window. Programming with multiple 'windows' is simple in principle, but you will probably need a working knowledge of the screen memory, map and a little practice in order to use it to its fullest extent. The definition of the current 'window' is held in five consecutive memory locations, from $0222-0226 (546-55010); their values are copied into various other locations during printing, scrolling, 'window'-clear and cursor- home operations. The values at start-up are as follows: Store name and contents location C1 C1E C2 101 SWIDTH column width (-1) $0222 54610 $77 2310 $2F 4710 $3F 6310 $2f 4710 SLTOP low byte of TOP $0223 547w $85 13310 $80 12810 $80 12810 $0C 1210 SHTOP high byte of TOP $0224 54810 $D0 20810 $D0 20810 $D0 20810 $D0 20810 SLBASE low byte of BASE $0225 54910 $85 13310 $40 6410 $40 6410 $CC 20410 SHBASE high byte of BASE $0226 55010 $D3 21110 $D7 215,0 $D7 21510 $D3 21110 These values, and thus the definition of the current 'window', may be changed at any time within a program. The width, as defined by SWIDTH, may be changed on its own; but the others should be changed as a set, to avoid the risk of printing at random into system memory.

Load more