< Previous  |  Contents  |  Next >

3 : Firmware

Tube Initialisation

This chapter concerns the actions performed during system initialisation. It is mainly concerned with booting the 512 system and loading DOS Plus, but parts of the operation are common to all co-processors and the initial stages are also performed when the host alone is activated.

It should be noted that the description of the steps performed in loading DOS may not apply precisely to all systems, particularly when exceptions to a normal load are encountered. Actions may depend on a range of variable factors, which together give quite a large number of possible combinations of hardware and software configuration. What is 'normal' for your system may differ in detail in the early stages of the load process, depending on which version of DOS is being loaded, whether the host is a model B, a B+ or a Master 128, whether the load takes place from floppy or hard disc and whether the ADFS in use is Acorn, STL or Watford Electronics. The following, therefore is a description of what theoretically happens.

On the pressing of the CTRL-BREAK keys together, the host performs a complete machine reset under hardware control, more commonly referred to as a hard break. There are some differences between a hard break and a power-up reset (ie when the micro is first switched on) but these differences are of no concern to, and have no effect on, the processes described here.

The hard break resets all vectors and the 6502's stack pointer, reinstates the default filing system, initialises service ROMs, checks the Tube and, if it is off, selects the default host language. This is followed by the return of either the familiar BASIC prompt or another language title screen if the default language is other than BASIC.

However, when the Tube is active, this process is interrupted. This takes place prior to language initialisation but after all other defaults have been set up or reset. On detection of a 'live' Tube, instead of initialising a language, the MOS downloads two sections of code, generally known as the Tube Host Code, from the ROM into page zero and pages four to six. These areas are normally reserved for the current language ROM, but in this case, so far as the host processor is concerned, the Tube is effectively regarded as the 'current language'.

The BRK vector is redirected to point into the Tube host code in page zero at byte &16, both to handle unexpected errors which might occur in any MOS or host software routine as well as to provide an automatic re-entry point to this code, while the program in pages four to six is entered to inform the co-processor of the hard reset.

The code stored in pages four to six is concerned with all standard inter-processor communication across the Tube and all the essential elements of co-processor to host MOS and filing system dialogue is provided by it. In the case of a 6502 co-processor and others, initialisation may subsequently follow a different path. For example, for a 6502 co-processor, if the host's current language ROM has a Second Processor relocation address, as does BASIC, a copy of it is written across the Tube and the language's prompt is displayed virtually immediately, with no necessity for further operations.

The Bootstrap Loader

In the case of the 512, when it is first notified of the hard reset it performs its own equivalent of the host's hard reset, again initially under hardware control. The 80186 executes a hard wired (permanently coded) jump into a tight program loop, which it continues to execute until a signal from the host causes a jump into the main bootstrap loader routine. When such a signal is received the 80186 executes a jump into the bootstrap loader, which first adds the familiar Acorn TUBE 80186 512K display to the host's screen display.

All the 512's hard-wired default code is located in the two EPROMs (as is the 80186 monitor, described later) which are permanently fitted to the 512 board. They contain the initial processor idle loop and sufficient code for the routines required to service the initial elementary inter-processor dialogue across the Tube for system start-up. On receipt of the Tube initialisation signal, the 80186 jumps out of its idle loop and enters the bootstrap loader.

Depending on whether the host's signal indicates a hard or a soft break, control passes to one of two routines. On a soft break the MOS remains in control displaying a * prompt and waiting for keyboard input while, in effect the 80186 awaits further developments within the 80186 monitor. At this stage users can demonstrate for themselves that the default 512 ROM code locates automatically in the 512's RAM by executing a soft break with the Tube enabled and entering:

GO FFFF:0000

As can be seen, this instruction causes execution to commence at the first byte in zero page in the 6502's memory, which at this stage causes the 80186 to jump to the start of the bootstrap code again and re-display the Tube message. After this the system will re-enter the wait loop and do nothing further. In the case of a hard break (or the command DOS or DOSBOOT, after at least a soft break), however, the 80186 enters the loader routine proper.

Bearing in mind that, at this time, the only filing system control available to the system is that provided by the host in native mode, the reason is clearly seen why DOS must be booted from an ADFS format disc, and equally why the 800K DOS format cannot be used for this initial operation.

The bootstrap loader first sends a request to the host to close any open files, then it checks the current filing system type by issuing an OSARGS call. If it is not currently ADFS a filing system change is forced and confirmation is requested. Some versions of DOS on some machines stop here with an error if ADFS is not already selected, while others will perform the filing system change automatically as described.

On receipt of the confirmation of the correct filing system the bootstrap loader next checks for the presence of a Winchester. If a Winchester is available an attempt will be made to load from it by a request for the filing system to load the boot file from the ADFS file DOSBOOT. If DOSBOOT cannot be found on the Winchester, the load will usually automatically revert to floppy disc, but again this may not occur in some configurations.

It is helpful to have an appreciation of the full specification of file attributes to understand the next step. In the host's filing system the full specification of a file's load address is expressed in four bytes, though when the Tube is not active the first two can be, and usually are, omitted for convenience. When the Tube is active, however, the full address must be specified, as all four bytes become relevant. This is because the co-processor's RAM is memory mapped from &00000000 to &FFFEFFFF, while &FFFF0000 to &FFFFFFF is reserved for the host.

This complete addressing range allows 2³² bytes, which is equivalent to 4,294,967,296 bytes or 4 Gigabytes, of which the host therefore occupies only the top 64k.

As can be seen by a *INFO DOSBOOT in native mode, the file has a load address of &04000000. Since the load address of DOSBOOT clearly locates it in the co-processor, the file is read and sent across the Tube via the Tube host code located in pages four to six. The bootstrap loader receives the data on the 512 side of the Tube and locates it in the 512's memory, starting at the address indicated and incrementing the addresses as it does so. On completion of the DOSBOOT load the bootstrap loader's job is complete and control can be passed to the primary loader, which is now resident in the 512's RAM.

The primary loader is initially loaded into low memory at address 0400:0000, which eventually will be required by DOS Plus (which is not yet loaded) and so the primary loader first relocates itself further up memory at 3800:0000. At this stage elementary DOS Plus filing system operations become possible and so the DOS file allocation table (FAT) and catalogue are read, and the (by now DOS, not ADFS) file 6502.SYS is loaded into the 512 from disc, immediately followed by the Digital Research logo screen if the file LOGO.SYS (optional) is present on the disc. (Hackers may wish to replace the LOGO.SYS file with an alternative graphic!)

Having been loaded into the 512, 6502.SYS is at once downloaded back into the host's main RAM and located at &2800. This is followed by immediate initialisation of the new code in the host. The initialisation of 6502.SYS re-directs interrupt request one vector (IRQ1V), the event vector and the user-vector to point into the code. Next, shadow is turned off by an OSBYTE 114, the screen is cleared by the immediately following mode change to BBC screen mode 3. The 6502.SYS code is now fully installed and active in the host. Next, the 512 sends the loader message and the Digital Research logo through 6502.SYS to be displayed on the new screen, while CP/M and the DOS Plus envelope are loaded from disc, in spite of the fact that this screen calls itself the bootstrap loader. This takes some time, so a dot is output to the screen for every 32 clusters (64k) of program loaded, to indicate to the user that the process is continuing satisfactorily.

The system is now almost live, so immediately prior to passing control to the user, or an AUTOEXEC.BAT file if present, DOS Plus must be downloaded to its permanent location and all OS variables and tables initialised. At the same time the 6502.SYS code is again used to initialise the IBM screen display by directly programming the host's 6845 CRTC. Finally the DOS console command processor, COMMAND.COM is loaded from disc and a second copy is written to high memory, AUTOEXEC.BAT is executed if present, and control is passed to the user, giving the familiar DOS prompt, or to an application loaded by the batch file. The system is now ready for use.

The 80186 Monitor

As explained in the preceding section, after enabling the Tube by means of switching on (for external co-processors) or the appropriate *CONFIGURE commands for a Master 128 using the internal Tube, the system will attempt to boot DOS Plus if a hard break has been performed. However, if a soft break is issued instead the 80186 monitor is entered (although on a Master 128 you may need to press ESCAPE).

In practice, the event which is most likely to cause you to do this is when an unexpected hang up or crash has occurred in DOS and you risk losing an appreciable quantity of work if you immediately re-boot the system. In DOS this type of occurrence tends to be more serious than in native BBC mode, primarily because DOS applications generally use much larger files and more data can be lost. The very best insurance against this, of course, is to save working files frequently and back-up at least one, and better two or three, master copies after every work session. Remember also that the following techniques offer no salvation after a power cut. It is to be hoped, therefore, that most of the following information will prove interesting rather than necessary!

It is vital that you remember that, even when the 512 board remains powered up during a DOS re-boot, very large quantities of the 512's memory are overwritten several times and large portions are completely wiped when DOS initialises. If you must attempt to recover data directly from the 512's memory after a hang up or a crash, no other option than a soft break and the monitor exists.

By means of two of the commands, search and dump, areas of the 512's RAM can be searched for key data, the information can be checked visually, and finally by means of a *SAVE filename command (remembering to supply the full 4 byte address correctly) the located data can be secured to a (native format) disc. After this the normal DOS utility MOVE can easily transfer the data back to DOS Plus format for final file reconstruction.

Under no circumstances press CTRL-BREAK if data recovery is to be attempted. No matter how quickly you may realise that you have done it, you might be too late and part of the 512's RAM contents can be lost. Pressing only the BREAK key deposits you in the 80186 monitor, when several facilities will allow you to find and recover your data. Entering the monitor itself has no implications for the recovery of data from the 512's RAM. The monitor is contained in the two EPROMs mounted on the 512 board and is automatically mapped in low memory, in part of the RAM previously occupied by DOS, by a soft break, therefore no user data is overwritten when it is entered.

On pressing BREAK the top of the screen will include the normal display seen when you are about to boot DOS, but nothing else will happen. Instead of a language or a DOS prompt you will find the command line prompt is a star (*)

The star prompt indicates that the 80186 monitor is waiting for manual user input. Commands entered at this point will be read by the MOS and are first passed to the monitor, which examines them. If they are not recognised by the monitor, control will be passed back to the host's MOS and the command is processed in the host in the usual way.

It will be found that not only monitor commands, but any command which will be understood by the host's MOS or its resident software can be issued (including filing system commands and service ROM calls) provided that such software is legally written. Note that ROMs employing dubious coding techniques are very likely to hang the system. However, even if this occurs there is no problem, as any number of repeated soft breaks have no effect on the contents of the 512's memory and should always return you to the monitor prompt.

As can be seen from the sequence of operations when the system is booted, you cannot use the monitor from within DOS by means of STAR command. Although automatically memory mapped in low 512 RAM on pressing BREAK, the boot ROM code is only entered prior to system load. In other words the monitor is no longer memory resident after DOS has booted, since DOS itself uses this area of the 512's RAM. Entering STAR H. from the DOS prompt will clearly demonstrate that the monitor is not available in a live DOS system.

Commands that are not recognised by the monitor or host software will produce the host's normal error response of Bad command, Bad Filename etc. An attempt to call a 6502 relocatable language (such as BASIC) will produce the message Not 80186 code. In the case of languages that can't relocate (even in a 6502 Second Processor) a suitable response should be provided by the language itself. The message given by such languages should be Turn second processor off, Turn Tube off, or something similar and equally to the point.

Monitor Commands

In addition to the standard MOS filing system and host resident software commands, the 80186 monitor provides a range of 512 specific commands. All of these relate solely to the 512's memory except one, which involves transfers between the memories of both machines. The monitor itself responds to the name MON (note that no full stop is required) and *HELP MON will produce the following help display, returning to the '*' prompt immediately afterwards:

*HELP MON
80186 TUBE 1.00
  a         (<segment>:) (<start offset>) (<end offset>)
  dos
  f         (<segment>:) <start offset> <end offset> <fill byte|word>
  go        (<segment>:) <offset>
  mon
  s         (<segment>:) <offset>
  sr        (<segment):) <start offset> <end offset> <"string">
  tfer      <io addr.> (<segment>:) <offset> <length> <r>|<w>

The command prefix, entered immediately following the '*' prompt, identifies the function to be carried out using the parameters which follow. Note that the monitor command prefix is not treated as an abbreviation and in usual DOS manner no point (.) should be added to these either.

Items in angled brackets, eg <segment>, indicate required parameters, though in some cases these may be defaulted as explained below.

Items in round brackets eg (<segment>) indicate that the enclosed item is optional and may be omitted from the command. If, as in the case of (<segment>), although the enclosed item is a required parameter you may elect not specify a value, therefore an appropriate default will be supplied by the monitor.

Items separated by a vertical bar, eg <r>|<w>, are mutually exclusive alternative entries and one of the two must be supplied. Monitor commands conform to normal DOS syntax rules and commands are not case sensitive. Generally either case, or a mixture of the two can be used, with the single exception of the <"string"> argument in the 'sr' (search) command.

Where a segment address must be supplied, the monitor will permit leading zeros to be omitted and any address (stated in paragraphs) may be specified, but wherever a segment address is supplied it must be immediately succeeded by a colon, whether an offset follows or not. If no segment address is supplied the colon is also omitted.

For all commands, if the segment address is omitted the most recently specified segment is used as the default. If no segment has been specified in a previous command the value will default to zero. Extra leading asterisks and unnecessary leading or trailing spaces are ignored.

Where an offset is required it may similarly be entered without leading zeros. If more than four hex digits are entered the most significant digits are ignored.

While the above help display may remind you of the syntax required, it fails to explain exactly what each command does. The following list completes the information.

Name		Function
D		Dump 512 memory, displayed in hex and ASCII
DOS		Boot DOS+ from hard disc or floppy
F		Fill 512 memory with a byte or word
GO		Go to (ie execute code from) a specified address
MON		Re-enter the monitor
S		Show (edit) 512 memory in hex and ASCII
SR		Search 512 memory for a specified character string
TFER		Transfer memory contents between 512 and host

Each of these commands is now examined in detail, with examples of use together with any additional comments which relate to a particular command.

D

Dump specified memory to screen

Syntax

D (<segment:>) (<start offset>) (<end offset>)

Function

This command produces a memory dump from the 512's RAM to the screen between the specified addresses, with a display in hex and ASCII showing 16 bytes on each line. The start address of each line is shown in the normal segment:offset format. Characters outside the normal printable range of 20h to 7Eh (CHR$32 to CHR$127) are shown as a full stop in the ASCII portion of the display.

All of the parameters in this command are optional and may be defaulted. If the segment address is omitted the last used segment value (or zero if none) is used. If the start offset is omitted, the display begins from the address of the last byte displayed plus one, or zero if there is no previous address. If the end address is omitted, the start address plus 128 more bytes are displayed, therefore this requires nine lines of display. As displays are output in multiples of 16 bytes, in effect the default display length becomes 144 bytes. It will be appreciated that it is a practical as well as a logical impossibility to specify an end offset without also supplying a start offset.

Note that a host *SPOOL <filename> command can be issued prior to using this command (or in fact any MON command) to easily create a record of the displays, provided that a suitable disc is placed in the default drive (and *MOUNTed for ADFS). In fact, this technique was employed to capture the examples shown here. The operation may be carried out in any (practical) host filing system, most usually DFS or ADFS. When the required data has been captured, *SPOOL should be used to close the file and correctly write its attributes.

Five examples of the D command are shown, since the method of supplying 512 addresses and the defaults which can apply for other commands are best illustrated by this one. Each of the following example commands were issued exactly in the sequence shown, so that the effects of the defaulted values can be clearly seen and followed from one display to the next.

This is the first MON command, issued immediately after a soft break – only the segment address was specified. Note that the colon is required to indicate that the single parameter is a segment address. Without the colon the value would be taken to be an offset. Since no previous monitor command has been issued the offset in this case defaults to zero and the end address defaults to the start address plus 80h bytes, that is the first byte of the last display line:

*D 1234:
1234:0000 BF 01 60 00 4F 3E 80 01 60 00 CC EE 80 00 97 03
1234:0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1234:0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1234:0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1234:0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1234:0050 00 00 00 00 86 00 8F 11 6A 00 99 11 E1 0E E1 0E
1234:0060 30 02 E2 06 D9 0F 00 00 85 0F 00 F2 A1 04 60 00
1234:0070 00 00 51 12 02 01 00 00 00 00 00 00 00 00 00 00
1234:0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The second command – the offset only is specifled. The segent has defaulted to the value used in the previous command. Note that the start address can be any value from 0000h to FFFFh, that is, it need not be an even or 'round' byte number. The absence of a trailing colon after the single address indicates that this is an offset address:

*D 8000
1234.8000 20 20 20 20 20 20 20 0D 0A 20 20 20 20 20 20 20
1234:8010 20 20 20 20 20 20 20 20 20 63 46 34 2E 55 6E 2D
1234:8020 64 65 6C 65 74 65 20 20 20 63 46 36 2E 54 6F 66
1234:8030 69 6C 65 2F 6D 61 72 6B 20 63 46 38 2E 52 69 67
1234:8040 68 74 2D 66 6C 75 73 68 20 63 46 31 30 2E 53 77
1234:8050 61 70 2D 66 69 6E 64 20 20 0D 0A 0D 0A 0D 0A 4D
1234:8060 45 4E 55 3A 20 20 68 65 6C 70 2C 20 65 78 69 74
1234:8070 2F 63 6F 6D 6D 61 6E 64 2C 20 73 61 76 65 2F 75
1234:8080 6E 73 61 76 65 3B 20 20 6E 61 6D 65 20 74 65 78

The third command – all three parameters, the segment, start offset and end offset are specified so as to start and end the output partway through the previous display, though the result would have been the same if the segment had been omitted:

*D 1234:8020 8030
1234:8020 64 65 6C 65 74 65 20 20 20 63 46 36 2E 54 6F 66
1234:8030 69 6C 65 2F 6D 61 72 6B 20 63 46 38 2E 52 69 67

The colon must be supplied after the segment address, but no space between the colon and the start offset is required (as is implied in the help display) though entering one does not cause an error. It should be noted that although the end offset is specified as 8030, the display does not necessarily terminate at the specified end byte. The complete display line of 16 bytes which includes the supplied end address is always output by this command. This is the reason that the default display length of start-byte + 128 bytes requires nine lines of display.

The fourth command – start and end offsets only were specified:

*D 8040 8060
1234:8040 68 74 2D 66 6C 75 73 68 20 63 46 31 30 2E 53 77
1234:8050 61 70 2D 66 69 6E 64 20 20 0D 0A 0D 0A 0D 0A 4D
1234:8060 45 4E 55 3A 20 20 68 65 6C 70 2C 20 65 78 69 74

Again note that the complete 16 byte line which contains the specified end offset is displayed.

Fifth command – all parameters defaulted:

*D
1234:8070 2F 63 6F 6D 6D 61 6E 64 2C 20 73 61 76 65 2F 75
1234:8080 6E 73 61 76 65 3B 20 20 6E 61 6D 65 20 74 65 78
1234:8090 74 2C 20 66 69 6C 65 20 6C 6F 61 64 2C 20 70 72
1234:80A0 69 6E 74 3B 20 20 64 69 72 65 63 74 6F 72 79 0D
1234:80B0 0A 52 55 4C 55 52 3A 20 20 73 70 6C 69 74 20 73
1234:80C0 63 72 65 65 6E 2C 20 65 64 69 74 20 6D 61 72 67
1234:80D0 69 6E 73 2C 20 6D 65 6E 75 3A 20 69 6E 73 65 72
1234:80E0 74 2C 20 64 65 66 61 75 6C 74 2C 20 74 6F 2F 66
1234:80F0 72 6F 6D 20 66 69 6C 65 2C 20 65 74 63 2E 0D 0A

In this case the segment and and start offset follow from the immediately preceding command and the default of nine lines of display is again applied. Note that if the start offset plus the display range should exceed the end address of the segment (FFFFh), wrap around occurs within the given segment. That is, the byte displayed after, for example, 1234:FFFFh is 1234:0000h.

DOS

Reboot DOS+

Syntax

DOS

Function

This command is intended to allow DOS to be booted without a CTRL BREAK, ie, from the monitor's star prompt after a soft break after leaving DOS, or powering up the coprocessor from native BBC mode followed by a soft break. The command will try to boot DOS, but, depending on what you have been doing immediately previously, in some systems it does not always function correctly. If this is the case the correct effect can sometmes be achieved by entering DOSBOOT from the MON star prompt, though it is equally simple and more reliable to perform a hard break, which will also produce the desired result.

F

Fill memory with a constant

Syntax

F (<segment:>) <start offset> <end offset> <fill byte | word>

Function

This command fills the 512's memory with the supplied fill value, begins at the the specified start offset and up to, but not including, the end offset. Only the segment may be defaulted, both offsets and the fill value must be supplied, there are no defaults. The fill value supplied may be specified either as a byte or as a word (two bytes). Fill bytes must be given as hexadecimal values, strings are not permitted.

*F 1234:1000 2000 20

will fill memory locations 1000h to 1FFFh inclusive, in segment 1234h, with the hexadecimal byte value 20h (space).

*F 1000 1100 ABCD

In this case the segment is defaulted, the previous segment value (or zero if no previous value) being used as the default. The command will fill bytes 1000h to 10FFh inclusive with the hexadecimal word value 'ABCDh'. As in all internal word formats, the low byte precedes the high byte. ie byte 1000h will be CDh, byte 1001h will be ABh and so on up to byte 10FEh which will be CDh and byte 10FFh which will be ABh.

The end offset may be specified as 0 so as to fill from the start offset up to and including the last byte in the segment. For example, to fill the entire segment 1000h with null bytes (0h) the command would be:

*F 1000:0 0 0

GO

Execute code starting at the specified address

Syntax

GO (<segment:>) <offset>

Function

This command directs the 80186 to transfer control to the code at the specified address in the 512's RAM. Its original purpose was for use when debugging the operating system. As such it is of little practical use to the user, for whom far better debuggers are available and who, in any case, would normally want to execute applications code in a live DOS system.

MON

Enter the 80186 monitor

Syntax

MON

Function

This command is also provided for debugging the operating system, when memory addresses can be suitably manipulated to allow the monitor to be entered on demand from within various sections of code. As for 'Go', for end users the command serves virtually no purpose, since it cannot be called either from DOS or from the BBC Micro in native mode, but only from within the monitor itself or from host or 80186 machine code programs loaded and run ftom the monitor prompt.

S

Show memory contents (for editing)

Syntax

S (<segment:>) <start offset>

Function

This command displays the specified contents of the 512's RAM for examination and possible alteration. A single display line of 16 bytes of memory is presented in the same hex and ASCII formats as were seen in the dump command. The cursor is positioned initially under the least significant digit of the first byte specified. Cursor movement and the format of data entry is controlled by the following keys:

CURSOR LEFT		Move left, if at far left display previous 16 bytes
CURSOR RIGHT		Move right, if at far right next 16 bytes
CURSOR UP		Display next 16 bytes
CURSOR DOWN		Display previous 16 bytes
SHIFT+ ←		Move cursor to far left of current line
SHIFT+ →		Move cursor to far right of current line
COPY		Toggle between hex and ASCII entry

The display, like the dump format, shows two 16-byte fields, with the hexadecimal representation on the left of the line and ASCII codes to the right. The COPY key will cause the cursor to jump between the two displays to allow data to be entered in either form.

For example:

*S 0040

followed by three cursor down key presses and two cursor up presses will give the following six display lines in sequence. Note the offsets.

0000:0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0000:0030 D6 1F 00 F0 00 00 00 00 00 00 00 00 00 00 00 00  ................
0000:0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0000:0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0000:0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0000:0030 D6 1F 00 F0 00 00 00 00 00 00 00 00 00 00 00 00  ................

During the display of each line, any of the 16 bytes shown can be amended by moving to it and entering a new value. When the cursor is in the hex field, data is always entered as two digits, each digit being shifted in from the right as it is entered. Ie, to enter 2F into a previously null byte, you would move the cursor to the required hex byte position and first enter the 2, giving 02h then the F, causing the 2 to move left by one digit to give 2Fh. If you continue to enter more digits at the same byte position the cursor does not automatically advance. For example, using the current entry, if you next entered a 6 the 2 would be lost and the resulting value would be F6h.

When the cursor is in the ASCII field, data is entered as ASCII bytes, ie as normal upper or lower case characters from the keyboard, or as control characters (CTRL+char). After the entry of every byte in ASCII format the cursor is automatically moved forwards to the next byte position. When a character is entered into the last byte on the line, the cursor is advanced to the first byte of the next 16-byte display line.

On completion of editing, ESCAPE returns control to the monitor's star prompt.

SR

Search memory for a text string

Syntax

SR (<segment:>) <start offset> <end offset> <"string">

Function

This command searches memory between the specified address limits attempting to match the supplied string, the search argument, which must be enclosed by double quotes. Each occurrence of the string found between the specified limits causes a displayed report of the start address for each match. The addresses are shown in the usual 'segment:offset' format. The search string may be up to a maximum of 72 characters in length and it should be noted that, unlike most entries in DOS, the search argument is case sensitive.

This command is most useful when readable data which can be easily or uniquely identified has to be located in the 512's RAM. Examples are, a key phrase or section title in a wordprocessor document, the first column header in a spreadsheet or the name in a database record and so on. Note that the search is always confined to the specified (or defaulted) segment.

After locating the data string the durnp command should be used to display the entire document or file, if possible. This is a wise precaution, used to verify that the correct part of the RAM has been located. Remember, without this check you may be just recovering a small part of your application's or DOS's workspace, perhaps just a couple of thousand or hundred bytes of data in a work buffer, or the holding area in a wordprocessor, rather than say, a complete 150k file.

To simplify the illustration of search, the same section of memory as was displayed in the dump command has been used, in an attempt to match a space followed by a lower case 'c', and an uppercase 'F'.

The first example searches for the specified string, " cF", in segment 1234h between offsets 7500h and 8500h:

*SR 1234:7500 8500 " cF"
1234:8018
1234:8028
1234:8038
1234:8048
1234:84CD
1234:84E1

By visually comparing the search results to the output from the dump command it can be seen that the address given for each rnatch is the address of the first byte of the matched string. To search for this string right to the end of the segment, the end address may be specified as a single zero, as in the example below which, in this case, produces only one extra match at 8FE0:

*SR 8000 0 " cF"
1234:8018
1234:8028
1234:8038
1234:8048
1234:84CD
1234:84E1
1234:8FE0

If the search is restricted to a smaller area of memory, as you would expect only matches contained entirely within the search limits are induded in the results. Therefore:

*SR 8000 304A " cF"
1234:8018
1234:8028
1234:8038

does not include the occurrence of string " cF" located at offset 8048, since part of this occurrence of the string (the last byte in this case) lies outside the specified search limits. It is perhaps easiest to think of the start and end addresses as the first byte to be searched and the first byte not to be included respectively. This is why an end address of zero permits a search to the end of the segment (offset zero minus one = FFFFh).

As already mentioned, search argument matching is case sensitive, therefore the search:

*SR 1234:8000 0 " CF"

produces no matched strings, nor does a search for either " Cf or " cf" in this case.

Any 8-bit character can be specified in a search string and this can include non-printable characters, but of course not all such characters can be entered directly from the keyboard by a single keypress. The method adopted uses the standard Acorn BBC Micro conventions which are:

The | (vertical bar) character prefix is entered to denote a control sequence, ie |@ is the single ASCII character 0 and |M is the single ASCII character 13, or a carriage return. CTRL+character may not be used in this case, because, for example CTRL-G (|G) only causes the micro to beep, while return (|M or CHR$13) will terminate the command input giving the error Bad string, since there would be no terminating quotation mark. The reason for this is simply that the command line input is being read initially by the host's MOS, character by character, and normal BBC Micro MOS rules apply.

For characters greater than ASCII 127 (7Fh) the 'pling' operator (! or ASCII 21h, sometirnes referred to as 'shriek') is added to indicate that the top bit should be set. This method can also be used with control sequences, when '!' follows the vertical bar preceding the character.

For example "|A" would specify a character value of ASCII 1 (01h) while "|!|@" would specify ASCII Character 128 (or 80h) and "|!|M" would specify CHR$141 or 8Dh.

Two special cases exist, CHR$127 and CHR$255. since both of these would require the entry of a DELETE character, which is naturally impossible since the delete key performs its normal function during command entry. The question mark (ASCII 3Fh, CHR$63) is used in conjunction with the '|' and '!' to indicate these two, so DELETE (7Fh) is entered as "|?", while CHR$255 (FFh) is entered as"|!|?".

Obviously search string entries can become quite confusing when a number of non-printable characters must be included. It should be noted that invalid character modifier combinations do not necessarily cause an error. If a control sequence is not recognised, the modifiers are stripped one by one, reducing the entry until a valid character results. Only if no valid character results from this reduction is an error reported.

For example "|1" would be invalid as it is meaningless, therefore it would be reduced by the monitor character interpreter to "1". Excess '|!' modifiers are likewise stripped and ignored so "|!|!|@" is reduced to "|!|@". Great care must be taken, therefore, in a search performed to recover important data which includes control sequences if the results are to be relied upon.

TFER

Transfer between the 512's RAM and the host's.

Syntax

TFER <I/O address> (<segment:>) <offset> <length> <R/W>

Function

This facility performs fast transfers of blocks of memory between the 512 co-processor's memory and the host's memory, in either direction.

The I/O address parameter, which must always be supplied, refers only to the start address of the memory block in the host's RAM and therefore does not require a full four byte specification (see examples). Segment and offset addresses refer to the 512's memory. with segment being optionally defaulted in a similar manner to previous commands. The offset address must always be supplied. The length must be supplied and refers to the length of the block of data to be transferred. It is specified as a two-hex-byte value, though leading zeros may be omitted, ie 00FF is taken to mean the same as FF.

The final parameter represents the direction of the transfer, which must always be specified. The two possibilities are R (read) or W (write). Conceptually it may help to remember that the monitor resides in the 512, therefore the command is executed by code within the 512, not the host. From the monitor's point of view therefore, 'R' means read into the 512, while 'W' means write from it.

For example:

*TFER 2000 1234:0 4000 W

would transfer the first 4000h bytes from segment 1234h in the 512 to the BBC host's RAM, storing the data starting at address &2000. Note that, in this case, unless a suitable screen mode is selected (eg mode 7) part of the screen will be overwritten by the transferred data. Master 128 users can configure shadow to avoid this problem, using the 'dodge' of ensuring that no boot disc is available when the hard break is issued, followed by an immediate soft break or ESCAPE to return to the monitor.

Users of Model B or B+ hosts should note that, because their shadow RAM is implemented in software rather than hardware, host direct memory accesses (DMAs) are unaffected by shadow settings and this option is of no use to them. In other words, even with shadow RAM selected the data will still be written to the screen RAM.

Transferring in the other direction:

*TFER C000 4000:0000 4000 R

would copy the 16K image of the host's MOS ROM to the 512's memory starting at byte zero in segment 4000h.

The transfer is implemented using OSWORD 0FAh and uses fast Tube transfer types 6 and 7 where possible. If the transfer length is not an integer multiple of 256 (FFh) bytes, remaining bytes (ie length MOD 256) are transferred using the slower type 0 and 1 transfers. The total amount of data transferred is, of course, in practice limited by the host's available RAM. Tube protocols and operational speeds are discussed in the next chapter, but from the subjective point of view of the operator all transfers appear to be virtually instantaneous.

TFER may be used manually or by machine code routines in either processor which have been loaded and run from the monitor prompt. As is usual with toolkits and memory editors, there is no check on the memory addresses to be overwritten by transfers in either direction. It is therefore incumbent on the user to ensure that no vital areas of memory in either the 512 or the host are destroyed by the use of this command.

Host Errors

When an error or escape condition is detected by the host processor, the error number and string are passed across the Tube to the 512, generating an interrupt request. This is serviced by the Tube code in the 512's monitor.

The error number and string are placed in the error buffer of the 512 and a pointer is initialised to point to the error number. The error string is terminated by a null byte (00h). The 512 Tube code then jumps to the error handler which displays the error before returning control to the 80186 monitor.

The error handling provided by the monitor is not suitable for use in stand-alone applications. Stand-alone programs consist of code which runs in the 512 but not under DOS Plus, that is, programs which only use MOS functions and host filing systems.

Monitor error handling is not usable in this way because control is returned to the monitor by the default error handler, not to any other code that may have originally called it. Error handling is further discussed in Chapter Eight, DOS Plus interrupts.

< Previous  |  Contents  |  Next >

About the Master 512 | Bibliography