Inside AMPLE memory

A G Walduck

This feature takes a look 'behind the scenes' at some of the inner workings of AMPLE.

Memory, modules, vectors and IRQs

In a BBC Model B with standard DFS and no other ROMs claiming private workspace (i.e. OSHWM (PAGE) at &1900), and with the standard Studio 5000 (or Studio 5000-4) !BOOT sequence, the fixed modules are loaded at the following locations:

Music 5000 setup

M.INT      at &1900 - &1CFF
Workspace  at &1D00 - &202B
M.M5       at &202C - &2FFF
M.EW       at &3000 - &32FF
M.MENU     at &3300 - &36FF
M.FX1A     at &3700 - &3AFF
M.INS1     at &3B00 - &3EFF

Music 4000 setup

M.INT      at &1900 - &1CFF
M.M4       at &1D00 - &20FF
Workspace  at &2100 - &243B
M.M5       at &243C - &33FF
M.EW       at &3400 - &36FF
M.MENU     at &3700 - &3AFF
M.FX1A     at &3B00 - &3EFF
M.INS1     at &3F00 - &42FF

Any temporary modules (e.g. M.PAD, M.MIX) will then load at &3F00 or above (&4300 or above for M4000).

Although the length of none of these modules is an exact number of pages of memory, the shortening of (most of) these programs to start at a page boundary is a consequence of the irreversible process of INSTALLing them.

Examination of the first few bytes of each module shows some interesting features, which can change between the version on the disc, and the version finally resident in memory. To date I have noticed the following locations (relative to the start of the module):

- in the disc image

00/01 file length
02/03 zero
04/05 pointer to relocation data
06/07 loading offset (e.g. &32C (or &33C) for M.M5)
08/09 ? (pointer to location near end of module)
   0A
   0B

- in the version in memory

00/01 new length (shorter than above)
02/03 location of start of module in memory ('base' page)
04/05 zero (as relocation data now incomplete)
06/07 unchanged from above
08/09 unchanged from above
   0A incremented by 'base' page
   0B incremented by 'base' page

The relocation data is a series of consecutive byte offset increments, terminated by three consecutive zero bytes, starting at the location given by the pointer at 04/05 in the disc image.

The list always starts with the bytes 04 07 01, corresponding to the need to increment locations 03,0A and 0B, as mentioned above, by the module 'base' page value.

If a zero byte exists in this list (as it does in M.M5) then the following two bytes are used as a two-byte increment for the adjustment process. This explains the need for a string of three consecutive zero bytes for termination of these lists.

If the module is fixed then, when this process is complete, the relocation data is no longer needed. The new length of the module can therefore be set to the first convenient page boundary after the start of the relocation data. Since subsequent modules or programs will overwrite this data, the relocation data pointer is zeroed.

Vectors and interrupts in AMPLE

The OSBYTE vector (BYTEV) points to location &6EC in a short section of code between &6C0 and &6FC, where interception of OSBYTE &8E (enter language ROM) occurs. Other OSBYTE calls are redirected via &54C to the default OSBYTE entry (at &E772 on a BBC Model B with OS 1.20).

The default AMPLE IRQ1V points to &6D4 in the same code section, but in a fully working environment it will point to &1941 (i.e. in M.INT).

Locating user routines

On page 65 of the AMPLE Nucleus Programmer Guide it states that "AMPLE leaves locations &8E and &8F free for use by user routines". Whilst this may (or may not) be true for Nucleus alone, it certainly is not true for Nucleus plus the normal complement of modules. I have instead (illegally) resorted to using zero-page locations &90-&9F (reserved for Econet) with no ill effect on a non-Econet machine.

---

The next issue of AMPLINEX will include a companion utility (also written by A G Walduck) which gives a dynamic display of any area of memory as AMPLE is working.

---

Published in AMPLINEX 005, May 1988