From 30d4cb6b5f4dbdb735a414156dac57eb64924838 Mon Sep 17 00:00:00 2001 From: Sascha Schneider Date: Sun, 14 Apr 2024 22:41:25 +0200 Subject: [PATCH 1/3] Enable --strict on mkdocs build to fail on warnings on mkdocs. --- .github/workflows/docs.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/docs.yml b/.github/workflows/docs.yml index 252694f..c67f0bf 100644 --- a/.github/workflows/docs.yml +++ b/.github/workflows/docs.yml @@ -18,4 +18,4 @@ jobs: key: ${{ github.ref }} path: .cache - run: pip install mkdocs-material - - run: mkdocs gh-deploy --force \ No newline at end of file + - run: mkdocs gh-deploy --strict --force From bc4ab37c215161a577e8684d12de492eb9a80631 Mon Sep 17 00:00:00 2001 From: Sascha Schneider Date: Sun, 14 Apr 2024 22:49:15 +0200 Subject: [PATCH 2/3] Remove last cppfront references. :) --- mkdocs.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mkdocs.yml b/mkdocs.yml index 2090f59..5862bd6 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,8 +1,8 @@ # To view the documentation locally on your machine, use the following steps # -# Clone the GitHub cppfront repo locally, then on the command line: +# Clone the GitHub agon-docs repo locally, then on the command line: # -# cd /github/cppfront +# cd /github/agon-docs # python -m venv venv # source venv/bin/activate # pip install mkdocs-material From cd5b5eb2532a67d29666cec1ce2b266496bcc8b9 Mon Sep 17 00:00:00 2001 From: Sascha Schneider Date: Sun, 14 Apr 2024 22:53:45 +0200 Subject: [PATCH 3/3] Fix links. --- docs/VDP.md | 2 +- docs/vdp/Bitmaps-API.md | 12 ++++++------ docs/vdp/Buffered-Commands-API.md | 4 ++-- docs/vdp/Enhanced-Audio-API.md | 10 +++++----- docs/vdp/System-Commands.md | 12 ++++++------ docs/vdp/VDU-Commands.md | 14 +++++++------- 6 files changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/VDP.md b/docs/VDP.md index b5d136f..1a97c21 100644 --- a/docs/VDP.md +++ b/docs/VDP.md @@ -119,6 +119,6 @@ Any VDU command that is the VDP does not recognise (such as `VDU 2` when running For more information on these commands and a full list, please consult the `VDU 23` section of the [VDU Commands](vdp/VDU-Commands.md) document. This includes the [Bitmap and Sprite API](vdp/Bitmaps-API.md). -Amongst this you will also find [system commands](vdp/System-Commands.md), which start with `VDU 23, 0` and are unique to the Agon platform. Within the system commands set you will find the [Audio API](vdp/Enhanced-Audio-API.md), and [Buffered Commands API](vdp/Buffered-Commands-API). +Amongst this you will also find [system commands](vdp/System-Commands.md), which start with `VDU 23, 0` and are unique to the Agon platform. Within the system commands set you will find the [Audio API](vdp/Enhanced-Audio-API.md), and [Buffered Commands API](vdp/Buffered-Commands-API.md). diff --git a/docs/vdp/Bitmaps-API.md b/docs/vdp/Bitmaps-API.md index ba47ac0..f596e3d 100644 --- a/docs/vdp/Bitmaps-API.md +++ b/docs/vdp/Bitmaps-API.md @@ -2,7 +2,7 @@ VDU 23, 27 is reserved for the bitmap, sprite, and mouse cursor functionality. -As of VDP 1.04, the bitmap system is integrated with the [Buffered Commands API](vdp/Buffered-Commands-API.md). Bitmap data is stored in buffers, and can be manipulated using the Buffered Commands API on the VDP. +As of VDP 1.04, the bitmap system is integrated with the [Buffered Commands API](Buffered-Commands-API.md). Bitmap data is stored in buffers, and can be manipulated using the Buffered Commands API on the VDP. ## Bitmaps @@ -13,7 +13,7 @@ Acorn only actually had two VDU commands for what it called "sprites", which in The approach taken on Agon (initially at least) was to redefine the "define bitmap from screen" command to instead allow the uploading of a binary bitmap image. In doing so, the parameters of the command changed, and the bitmap identifier was lost from the command parameters. Instead, on the Agon, you need to always perform a "select bitmap" command before any other bitmap commands to set the bitmap being used. Additionally on the Agon, prior to Console8 VDP 2.2.0, plotting bitmaps could only be performed with a custom command, and not with the standard `PLOT` commands. -As of Console8 VDP 2.2.0, it is now possible to use Acorn GXR style "sprite" code on an Agon. The `PLOT` code for drawing bitmaps is now supported, and bitmap command 1 can now be used to capture screen data into a bitmap identically to the GXR. The documentation on the [`PLOT` command](vdp/PLOT-Command.md) (`VDU 25`) explains how to use it to draw bitmaps. +As of Console8 VDP 2.2.0, it is now possible to use Acorn GXR style "sprite" code on an Agon. The `PLOT` code for drawing bitmaps is now supported, and bitmap command 1 can now be used to capture screen data into a bitmap identically to the GXR. The documentation on the [`PLOT` command](PLOT-Commands.md) (`VDU 25`) explains how to use it to draw bitmaps. In addition to GXRs two commands, the Agon VDP has several other commands for managing bitmaps, and additional commands to manage "sprites". @@ -49,7 +49,7 @@ The width and height of the bitmap must be given in pixels, and must match the n It should be noted that whilst the image format supported by this command is for full 24-bit colour images with 256 levels of transparency (alpha) per pixel, the Agon hardware is only capable of displaying 2-bits per colour channel. The graphics system also does not really support transparency, so any non-zero alpha value is interpreted as "fully visible". Data loaded via this command remains in RGBA8888 format on the VDP, but is converted on the fly when the bitmap is drawn to the screen. -(As RGBA8888 is a very wasteful format, given the hardware limitations, other options are now available. Loading bitmaps with this command can take a long time, and it is not possible to intersperse other commands, such as showing progress on-screen, whilst the data is being sent. There are however alternative ways of managing the data which avoids these issues. Please see the section on "Using buffers for bitmaps" in the [Buffered Commands API](vdp/Buffered-Commands-API.md) document for more information.) +(As RGBA8888 is a very wasteful format, given the hardware limitations, other options are now available. Loading bitmaps with this command can take a long time, and it is not possible to intersperse other commands, such as showing progress on-screen, whilst the data is being sent. There are however alternative ways of managing the data which avoids these issues. Please see the section on "Using buffers for bitmaps" in the [Buffered Commands API](Buffered-Commands-API.md) document for more information.) ### `VDU 23, 27, 1, n, 0, 0;`: Capture screen data into bitmap n * @@ -63,7 +63,7 @@ To be clear, this command should be performed _after_ two "move" style PLOT comm If a bitmap with the given ID already exists then it will be overwritten, and similarly if a buffer was already defined with the ID 64000+`n` then that will be overwritten too. -Up to and including the Console8 VDP 2.5.0 release, the bitmap data captured using this command will be stored in "native" format. The nature of the "native" format varies depending on the screen mode. For all screen modes the bitmap will use 1 byte per pixel, but the data within that byte varies. In 64 colour modes, the data is essentially in RGB222 with no alpha channel. It is possible to convert bitmaps captured in 64 colour modes to RGBA2222 format by using the OR operation of the "adjust" command from the [Buffered Commands API](vdp/Buffered-Commands-API.md), ORing all the bytes in the bitmap's buffer with `&C0` to set the pixel alpha bits to be "opaque", and then re-creating the bitmap from the corresponding buffer to be RGBA2222 (format 1). For all other screen modes, the byte represents a palette index. An unfortunate effect of this is that a bitmap captured in one screen mode may not be compatible with other screen modes. +Up to and including the Console8 VDP 2.5.0 release, the bitmap data captured using this command will be stored in "native" format. The nature of the "native" format varies depending on the screen mode. For all screen modes the bitmap will use 1 byte per pixel, but the data within that byte varies. In 64 colour modes, the data is essentially in RGB222 with no alpha channel. It is possible to convert bitmaps captured in 64 colour modes to RGBA2222 format by using the OR operation of the "adjust" command from the [Buffered Commands API](Buffered-Commands-API.md), ORing all the bytes in the bitmap's buffer with `&C0` to set the pixel alpha bits to be "opaque", and then re-creating the bitmap from the corresponding buffer to be RGBA2222 (format 1). For all other screen modes, the byte represents a palette index. An unfortunate effect of this is that a bitmap captured in one screen mode may not be compatible with other screen modes. Also up to and including the Console8 VDP 2.5.0 release, bitmaps captured with this command would use "exclusive" coordinates, and so would be 1 pixel shorter and narrower than the area defined by the graphics cursor positions. (This is _not_ consistent with the behaviour of this command on Acorn systems.) @@ -79,13 +79,13 @@ The bitmap is created in the buffer with the ID 64000+`n`, where `n` is the 8-bi ### `VDU 23, 27, 3, x; y;`: Draw current bitmap on screen at pixel position x, y -Prior to Agon Console8 VDP 2.2.0, this was the only way to draw a bitmap on-screen. On more up to date VDP versions is strongly recommended that you use the appropriate [PLOT command](vdp/PLOT-Commands.md) instead. +Prior to Agon Console8 VDP 2.2.0, this was the only way to draw a bitmap on-screen. On more up to date VDP versions is strongly recommended that you use the appropriate [PLOT command](PLOT-Commands.md) instead. Before this command can be used, a bitmap must be selected using `VDU 23, 27, 0, n`, where `n` is the 8-bit ID of the bitmap to be drawn, or using `VDU 23, 27, &20, bufferId;` using a 16-bit buffer ID. The x and y parameters give the pixel position on the screen at which the top left corner of the bitmap will be drawn. This is in contrast to `PLOT` commands which will (by default) use OS Coordinates, where the origin is at the bottom left of the screen and the screen is always considered to have the dimensions 1280x1024. -Please note that this command does not obey the current graphics viewport or the currently selected coordinate system. The bitmap will be drawn at the given pixel position, and will _not_ be clipped by the viewport. To draw bitmaps with clipping, you are advised to use the appropriate bitmap [PLOT commands](vdp/PLOT-Commands.md) instead. +Please note that this command does not obey the current graphics viewport or the currently selected coordinate system. The bitmap will be drawn at the given pixel position, and will _not_ be clipped by the viewport. To draw bitmaps with clipping, you are advised to use the appropriate bitmap [PLOT commands](PLOT-Commands.md) instead. ### `VDU 23, 27, &20, bufferId;`: Select bitmap using a 16-bit buffer ID * diff --git a/docs/vdp/Buffered-Commands-API.md b/docs/vdp/Buffered-Commands-API.md index 02035e2..bf336c5 100644 --- a/docs/vdp/Buffered-Commands-API.md +++ b/docs/vdp/Buffered-Commands-API.md @@ -52,7 +52,7 @@ VDU 23, 27, &20, bufferId; : REM Select bitmap (using a buffer ID) VDU 23, 27, &21, width; height; format : REM Create bitmap from buffer ``` -More extensive information on the bitmap and sprites API calls can be found in the [bitmaps and sprites documentation](vdp/Bitmaps-API.md). +More extensive information on the bitmap and sprites API calls can be found in the [bitmaps and sprites documentation](Bitmaps-API.md). Until the "create bitmap" call has been made the buffer cannot be used as a bitmap. That is because the system needs to understand the dimensions of the bitmap, as well as the format of the data. Usually this only needs to be done once. The format is given as an 8-bit value, with the following values supported: @@ -82,7 +82,7 @@ Much like with bitmaps, it is advisable to send samples over to the VDP in multi In contrast to bitmaps, the sound system can play back samples that are spread over multiple blocks, so there is no need to consolidate buffers. As a result of this, the sample playback system is also more tolerant of modifications being made to the buffer after a sample has been created from it, even if the sample is currently playing. It should be noted that splitting a buffer may result in unexpected behaviour if the sample is currently playing, such as skipping to other parts of the sample. -Full information on the sound system can be found in the [audio API documentation](vdp/Enhanced-Audio-API.md). +Full information on the sound system can be found in the [audio API documentation](Enhanced-Audio-API.md). Once you have a buffer that contains block(s) that are ready to be used for a sound sample, the following command must be used to indicate that a sample should be created from that buffer: diff --git a/docs/vdp/Enhanced-Audio-API.md b/docs/vdp/Enhanced-Audio-API.md index 6194511..2b8108a 100644 --- a/docs/vdp/Enhanced-Audio-API.md +++ b/docs/vdp/Enhanced-Audio-API.md @@ -13,7 +13,7 @@ Examples are given in BBC BASIC. A common source of errors when sending commands to the VDP from BASIC via VDU commands is to forget to use a `;` after a number to indicate a 16-bit value should be sent. If you see unexpected behaviour from your BASIC code that is the most likely source of the problem. -When a command is processed the VDP may send a message back to MOS with the status of that command. (Generally a return value of `1` indicates success, and `0` failure, but there are some exceptions to this, most notably the Status command. Not all audio comments return a status.) When the MOS receives an audio command status value it will set the audio bit of the VDP protocol flags to indicate that an audio message has been received. It also sets two [system variable values](MOS-API.md#system-variables), `sysvar_audioChannel` and `sysvar_audioSuccess` with the results of the command. `sysvar_audioChannel` is the channel number, and `sysvar_audioSuccess` provides the status of that command. These values can be read using a `mos_sysvars` API call, or an [OSBYTE call from BASIC as documented here](BBC-BASIC-for-Agon.md#accessing-the-mos-system-variables). +When a command is processed the VDP may send a message back to MOS with the status of that command. (Generally a return value of `1` indicates success, and `0` failure, but there are some exceptions to this, most notably the Status command. Not all audio comments return a status.) When the MOS receives an audio command status value it will set the audio bit of the VDP protocol flags to indicate that an audio message has been received. It also sets two [system variable values](../MOS-API.md#system-variables), `sysvar_audioChannel` and `sysvar_audioSuccess` with the results of the command. `sysvar_audioChannel` is the channel number, and `sysvar_audioSuccess` provides the status of that command. These values can be read using a `mos_sysvars` API call, or an [OSBYTE call from BASIC as documented here](../BBC-BASIC-for-Agon.md#accessing-the-mos-system-variables). It should be noted that VDP protocol flags are not automatically cleared by MOS, so it is the responsibility of the application to clear the audio bit of the VDP protocol flags before sending a command. At present there is no way to do this directly from BBC BASIC. @@ -141,7 +141,7 @@ Prior to Console8 VDP 2.5.0 this command did not return a status. These commands are used to manage samples on the VDP which can be assigned to a channel as a waveform for playback. -Sample data is stored in buffers on the VDP, and can be manipulated using the [buffered commands API](vdp/Buffered-Commands-API.md). +Sample data is stored in buffers on the VDP, and can be manipulated using the [buffered commands API](Buffered-Commands-API.md). When a negative number is used in place of the channel number then the command is referring directly to a sample, rather than a channel. Samples referenced in this manner are, by default, stored in buffers in the range 64256-64383 (`&FB00`-`&FB7F`). To map a negative sample number to a buffer range, you need to negate it, subtract 1, and then add it to 64256. This means sample number -1 is stored in buffer 64256, -2 is stored in buffer 64257, and so on. Any buffer however can be used for sample data, using commands listed below that explicitly reference a buffer ID. @@ -155,7 +155,7 @@ Sample commands 5, 3 and above were added in the Console8 VDP 2.2.0 release. This command is used to transfer a sample over to the VDP for later playback. -As sample data can be long, rather than using this command, you are advised instead to upload your sample data to a buffer on the VDP in multiple blocks using the [buffered commands API](vdp/Buffered-Commands-API.md) and then use command 5, 2 (documented below) to indicate that the data within a buffer is a sound sample. That approach also allows for the use of different formats of sample data. +As sample data can be long, rather than using this command, you are advised instead to upload your sample data to a buffer on the VDP in multiple blocks using the [buffered commands API](Buffered-Commands-API.md) and then use command 5, 2 (documented below) to indicate that the data within a buffer is a sound sample. That approach also allows for the use of different formats of sample data. When using this command, the sample data is assumed to be 8-bit signed PCM samples at 16kHz. The sample data is sent as a series of bytes of the given length. @@ -184,7 +184,7 @@ A simple example of how to send a sample to the VDP using this command is as fol NB This example can be very slow as it sends the sample data byte-by-byte, taking just over 1s to send 2kb of data. During this time your computer will be unresponsive, and it is not possible to output to screen any kind of progress as any such `PRINT` command will be interpretted as part of the sample data. Unfortunately at present there is no way to send data in bulk to the VDP from BBC BASIC, or to read chunks of files into memory in one go. For faster transfer of sample data you will need to write a program in assembly language and make use of file access APIs from MOS and the RST #18 vector to send larger chunks of data to the VDP. -The [VDP Buffered Commands API](vdp/Buffered-Commands-API.md) provides an alternative example of sending sample data to the VDP which allows for progress to be reported whilst the sample is being uploaded. +The [VDP Buffered Commands API](Buffered-Commands-API.md) provides an alternative example of sending sample data to the VDP which allows for progress to be reported whilst the sample is being uploaded. As noted above, this command will return 1 on success or 0 for failure. In the event of a failure the VDP will ignore and discard the sample data being sent to it. @@ -206,7 +206,7 @@ This command will return 1 on success or 0 for failure. This command is used to indicate that the data in the given buffer is a sound sample. The channel number will be ignored for the purposes of this command, but will be used in the return result. -The buffer ID is a 16-bit value giving the buffer number to use for the sample. The buffer must have been created using the [buffered commands API](vdp/Buffered-Commands-API.md) before this command is called. +The buffer ID is a 16-bit value giving the buffer number to use for the sample. The buffer must have been created using the [buffered commands API](Buffered-Commands-API.md) before this command is called. The format is a single byte giving the format of the sample data. The following formats are supported: diff --git a/docs/vdp/System-Commands.md b/docs/vdp/System-Commands.md index 0208057..7912c4c 100644 --- a/docs/vdp/System-Commands.md +++ b/docs/vdp/System-Commands.md @@ -100,7 +100,7 @@ This command will return the colour of the pixel at the given pixel position to ## `VDU 23, 0, &85, channel, command, `: Audio commands -Sends a command to the [VDP Enhanced Audio API](vdp/Enhanced-Audio-API.md) ** +Sends a command to the [VDP Enhanced Audio API](Enhanced-Audio-API.md) ** Prior to VDP 1.04 this command could only perform what is now audio command zero, which plays a note on a channel. @@ -180,7 +180,7 @@ There are several built-in mouse cursors that are available for use. These have | 17 | Resize4 | 17x11 resize orientation 4 | | 18 | TextInput | 7x15 text input | -Additional cursors can be defined using the `VDU 23, 27, &40, hotX, hotY` command. For details of that command see the [Bitmaps API](vdp/Bitmaps-API.md) documentation. Using that API it is possible to define a custom mouse cursor using a bitmap, which can then be selected using this command passing in the 16-bit bitmapId in place of a cursorId. +Additional cursors can be defined using the `VDU 23, 27, &40, hotX, hotY` command. For details of that command see the [Bitmaps API](Bitmaps-API.md) documentation. Using that API it is possible to define a custom mouse cursor using a bitmap, which can then be selected using this command passing in the 16-bit bitmapId in place of a cursorId. ### `VDU 23, 0, &89, 4, x; y;`: Set mouse cursor position @@ -299,7 +299,7 @@ From Console8 VDP 2.6.0 onwards, the control keys can be turned off, which may h ## `VDU 23, 0, &A0, bufferId, command, `: Buffered command API ** -Send a command to the [VDP Buffered Commands API](vdp/Buffered-Commands-API.md) +Send a command to the [VDP Buffered Commands API](Buffered-Commands-API.md) ## `VDU 23, 0, &A1`: Update VDP (for exclusive use of the agon-flash tool) ** @@ -311,7 +311,7 @@ Turns logical screen scaling on and off, where 1=on and 0=off. When logical scaling is turned off, the graphics system will no longer use the 1280x1024 logical coordinate system and instead use pixel coordinates. The screen origin point at 0,0 will change to be the top left of the screen, and the Y axis will go down the screen instead of up. -For more information, see the [Screen modes documentation](vdp/Screen-Modes.md). +For more information, see the [Screen modes documentation](Screen-Modes.md). ## `VDU 23, 0, &C1, n`: Switch legacy modes on or off ** @@ -319,7 +319,7 @@ Turns legacy screen modes on and off, where 1=on and 0=off. By default, the original screen modes 0-4 are not available and are instead replaced by new modes that are more compatible with modern monitors. For compatibility with older software, written for Agon systems running earlier versions of the VDP firmware, this command can be used to switch back to those original, legacy, screen modes. -For more information, see the [Screen modes documentation](vdp/Screen-Modes.md). +For more information, see the [Screen modes documentation](Screen-Modes.md). ## `VDU 23, 0, &C3`: Swap the screen buffer and/or wait for VSYNC ** @@ -393,7 +393,7 @@ Packets: - `0x02, x, y`: Cursor position - `0x03, char`: Character read from screen - `0x04, r, g, b, index`: Pixel colour read from screen -- `0x05, channel, status`: Audio command status (see [VDP Enhanced Audio API](vdp/Enhanced-Audio-API.md)) +- `0x05, channel, status`: Audio command status (see [VDP Enhanced Audio API](Enhanced-Audio-API.md)) - `0x06, width; height; cols, rows, colours`: Screen dimensions - width and height are words - `0x07, year, month, day, dayOfYear, dayOfWeek, hour, minute, second`: RTC data * - `0x08, delay, rate, led`: Keyboard status - delay and rate are words diff --git a/docs/vdp/VDU-Commands.md b/docs/vdp/VDU-Commands.md index 2bc9a12..86a6395 100644 --- a/docs/vdp/VDU-Commands.md +++ b/docs/vdp/VDU-Commands.md @@ -157,7 +157,7 @@ The full array of available modes is as follows: | 6 | AND the inverse of the specified colour with the on-screen pixel | | 7 | OR the inverse of the specified colour with the on-screen pixel | -For more information on the various plot commands, please see the [VDP PLOT command documentation](vdp/PLOT-Commands.md) +For more information on the various plot commands, please see the [VDP PLOT command documentation](PLOT-Commands.md) (Acorn's graphics system supported some further GCOL mode options, which could specify the use of a fill pattern, which is not currently supported by the Agon VDP. Support for these modes may be added in a future version of the VDP firmware.) @@ -199,7 +199,7 @@ Please note that the behaviour of the Agon system differs from Acorn systems whe Changes the screen mode to the given mode number. -Please see the [Screen Modes](vdp/Screen-Modes.md) documentation for more information on the screen modes supported by the Agon VDP. +Please see the [Screen Modes](Screen-Modes.md) documentation for more information on the screen modes supported by the Agon VDP. This command is identical to the BASIC `MODE` keyword. @@ -213,7 +213,7 @@ VDU 23, char_no, r1, r2, r3, r4, r5, r6, r7, r8 ``` Where `char_no` is the character number to re-program, and `r1` to `r8` are the 8 bytes of data that define the character in rows from top to bottom. Each byte defines one row of the character, with the least significant bit of each byte defining the left-most pixel of the row, and the most significant bit defining the right-most pixel of the row. -Note: There is a related VDU 23 System Command which can [program the entire character range 0-255](vdp/System-Commands.md#vdu-23-0-90-n-b1-b2-b3-b4-b5-b6-b7-b8-redefine-character-n-0-255-with-8-bytes-of-data-), and a reset command is also available to [reset the font](vdp/System-Commands.md#vdu-23-0-91-reset-all-characters-to-original-definition-) back to default. +Note: There is a related VDU 23 System Command which can [program the entire character range 0-255](System-Commands.md#vdu-23-0-90-n-b1-b2-b3-b4-b5-b6-b7-b8-redefine-character-n-0-255-with-8-bytes-of-data-), and a reset command is also available to [reset the font](System-Commands.md#vdu-23-0-91-reset-all-characters-to-original-definition-) back to default. The second purpose of this command is to send system commands to the VDP. @@ -221,7 +221,7 @@ The following commands are supported: ### `VDU 23, 0, , []`: System commands -Commands starting with `VDU 23, 0` are system commands. These commands are used to configure the VDP and to control its behaviour. This includes functionality such as the [audio system](vdp/Enhanced-Audio-API.md) and the [buffered commands API](vdp/Buffered-Commands-API.md). For more information see the [System Commands](vdp/System-Commands.md) documentation. +Commands starting with `VDU 23, 0` are system commands. These commands are used to configure the VDP and to control its behaviour. This includes functionality such as the [audio system](Enhanced-Audio-API.md) and the [buffered commands API](Buffered-Commands-API.md). For more information see the [System Commands](System-Commands.md) documentation. ### `VDU 23, 1, n`: Cursor control @@ -320,7 +320,7 @@ Enabling scroll protection therefore allows you to print a character to the bott ### `VDU 23, 27, , []`: Bitmap and sprite commands -See the [Bitmap and Sprite Commands](vdp/Bitmaps-API.md) documentation for more information. +See the [Bitmap and Sprite Commands](Bitmaps-API.md) documentation for more information. ### `VDU 23, 28`: Hexload @@ -336,13 +336,13 @@ Coordinates given are "inclusive", meaning that drawing locations up to and incl (Please note that owing to a bug in the VDP firmware, viewports of a single pixel wide or tall were not supported until Console8 VDP 2.7.0. Prior to that version a command to set a single pixel high viewport would be ignored.) -## `VDU 25, mode, x; y;`: [PLOT command](vdp/PLOT-Commands.md) +## `VDU 25, mode, x; y;`: [PLOT command](PLOT-Commands.md) This command is used for graphics plotting, and is equivalent to the BASIC `PLOT` command. The aim for this command is to support all of Acorn's original `PLOT` modes, however currently only a limited number of plotting modes are supported. Support for plot modes has expanded over time, and will continue to expand in the future. -For more information see the [PLOT Commands](vdp/PLOT-Commands.md) documentation. +For more information see the [PLOT Commands](PLOT-Commands.md) documentation. ## `VDU 26`: Reset graphics and text viewports **