breakintoprogram / agon-vdp

Official AGON QUARK Firmware: ESP32 VDP

• Hi, I’m @breakintoprogram
• In my spare time I’m working on the official Quark firmware for the Agon Light microcomputer board
• Other notable repositories inlude my ZX Spectrum and Spectrum Next Z80 libraries, and Pico-mposite
• You can find me on social media:
  • Twitter: @breakintoprog
  • Blog: breakintoprogram.co.uk
  • YouTube: youtube.com/BreakIntoProgram
  • Mastadon: oldbytes.space/@breakintoprogram
  • Blue Sky: @breakintoprogram.bsky.social

I am quite happy contributing to the various communitiies I'm involved in with no obligations.

However, if you like what I am doing and would like to contribute, you can do so at ko-fi.com/breakintoprogram.

agon-vdp's Issues

Increased VDU throughput is crashing FabGL

After the latest release, it has been noted that:

• sprites_5.bas crashes after a couple of minutes
• sprites_4.bas crashes, though it will run a lot longer before it does
• sprites_3.bas is fine; that only has 1 frame per sprite
• triangles.bas crashes in MODE 2 after 30 seconds or so

This card has been forked from: breakintoprogram/agon-bbc-basic#13

Add VDU4 and VDU5 support

Please could VDU4 and VDU5 support be added:

• VDU 4: Print at text cursor
• VDU 5: Print at graphics cursor

This would give the ability to switch the printing of text between the two cursors and allow for text positioning that is more precise than the default text positions (as set by the BASIC "TAB" instruction). For example:

10 MODE 1
20 VDU 4
30 PRINT TAB(4,4)"PRINTING AT TEXT CURSOR"
40 VDU 5
50 MOVE 640,512
60 PRINT "PRINTING AT GRAPHICS CURSOR"
70 VDU 4
80 PRINT "BACK AT TEXT CURSOR"

In the above example, the text at line 30 should be near the top of the screen, the text at line 60 roughly in the middle and the text at line 80 following on from the text at line 30.

VDP 1.03rc1 Compiling Issue

I am getting the following error message when compiling:

  agon-vdp/video/video.ino: In function 'void switchTerminalMode()':
  agon-vdp/video/video.ino:414:11: error: 'class fabgl::Terminal' has no member named 'connectSerialPort'; did you mean
        'connectKeyboard'?
  Terminal.connectSerialPort(ESPSerial);
                 ^~~~~~~~~~~~~~~~~
                 connectKeyboard

  exit status 1

Compilation error: 'class fabgl::Terminal' has no member named 'connectSerialPort'; did you mean 'connectKeyboard

I am using the latest FabGL library (1,0.8) with Arduino EDE 2.0.3. Suggestions?

Terminal input as well as PS/2 keyboard input

As an Agon user
I would like to be able to use the USB serial port for keyboard entry
So that I don't have to plug a PS/2 keyboard in

Criteria:

• Must not cause issues with any existing software or modifications
• Optional compilation on VPD may be a way forward

VDU 23,0 extensions

I can't find the code that processes the VDU stream, but from the code in BASIC I see you are using VDU 23,0 to pass various commands to the video processor.
This will clash with programs that already use VDU 23,0 for various things, for example it is common to see VDU 23,0,10,0,0,0,0,0,0,0 to get a solid block cursor, and VDU 23,0,10,32,0,0,0,0,0,0 to turn the cursor off. These would be transparently ignored if the platform doesn't implement it.

I would recommend using VDU 23,0,128+x for platform-specific extensions.

Rename 'VPD' in bootscreen to 'VDP'

Just a small fix for consistency

eZ80->ESP32 UART connection fails if board booted without keyboard connected

When booting the Olimex board without a keyboard connected, the MOS version string is displayed as garbled.

Seen in VDP 1.03 RC3 / MOS 1.03 RC3 and VDP 1.03 RC4 / MOS 1.03 RC4. No other versions tested yet for comparison.

Note this is untested on the original board and may not be specific to Olimex one.

Stepping through MOS code in debugger allowed MOS version string to be displayed clearly (suggesting it may be related to timing perhaps since this process introduces delays?).

Will add further information when I have had a chance to investigate.

Allocate bitmaps in PSRAM over a certain size; BMP bitmap mode

Hi there,

In addition to the sound tinkering in my Pull Request I've been playing with code to stream off the shelf .bmp bitmap assets from the SD card to the VDP. It's lead me to two suggestions, the first of which I think is worthwhile regardless of the second:

Bitmap allocation in memory

At the moment you mandate bitmaps to be malloc'd in SRAM, which makes perfect sense if you're expecting them to be less than at most 64x64 for sprite work. But if you want to load in a one-off logo or similar you quickly run out of SRAM and enter undefined behavior territory - usually it just fails silently. PSRAM runs at around about 12MHz equivalent, so at the resolutions we're dealing with it's more than fast enough to stream bitmap data back to the canvas/framebuffer when demanded. I suggest the following change:

if (height*width > 4096) dataptr = (void *)heap_caps_malloc(sizeof(uint32_t)*width*height, MALLOC_CAP_8BIT); //PSRAM

else dataptr = (void *)heap_caps_malloc(sizeof(uint32_t)*width*height, MALLOC_CAP_8BIT | MALLOC_CAP_INTERNAL); // SRAM

bitmaps[current_bitmap].data = (uint8_t *)dataptr; //In either case, assign it.

I've even tested with all bitmaps malloc'd to PSRAM and it doesn't seem to impact any of my existing code or the various sprite demos. But keeping smaller assets in SRAM as before seems a reasonable balance regardless, just in case.

BMP mode

As I mentioned, this came about because I was playing the best way to load in assets from SD on the ez80 side. We don't have the luxury of being able to ingest assets into RAM on the ez80 in order to play with them and stream them in the way the VDP expects for the existing examples. BMP files are the simplest off the shelf asset, and even they have two issues that are hard to get around when you're ingesting a file top-down one char at a time: pixel data is stored bottom-up, and in the form BGR.

My suggestion is a special variant of cmd == 1 in the bitmap/sprite handling code, cmd == 100:

if(cmd == 100) {
//
// BMP mode. Read data to the new databuffer, then flip the whole map vertically (because BMP is stored bottom-up).
//
 	for(n = 0; n < width*height; n++) ((uint32_t *)bitmaps[current_bitmap].data)[n] = (uint32_t)0xFF000000 | ((uint32_t)readByte() << 16) | ((uint32_t)readByte() << 8) | ((uint32_t)readByte());
 	flip((uint32_t *)bitmaps[current_bitmap].data, width, height);
 	debug_log("vdu_sys_sprites: BMP bitmap %d - data received - width %d, height %d\n\r", current_bitmap, width, height);
}

This approach assumes the ez80 doesn't stream an alpha byte for the bitmap, since .bmp shouldn't contain one. It assumes 0xFF, but you could expand this code easily to toggle the alpha value based on the pixel's colour.

The flip() function in question is a dirt simple function to flip any framebuffer vertically, could be done without a function but is exactly the sort of thing we would struggle to do effectively on the ez80:

void flip(uint32_t* framebuffer, int width, int height) {
    uint32_t* row_buffer = (uint32_t*) malloc(sizeof(uint32_t) * width);
    int row_size = width * sizeof(uint32_t);

    for (int y = 0; y < height / 2; y++) {
        uint32_t* top_row = framebuffer + y * width;
        uint32_t* bottom_row = framebuffer + (height - y - 1) * width;

        memcpy(row_buffer, top_row, row_size);
        memcpy(top_row, bottom_row, row_size);
        memcpy(bottom_row, row_buffer, row_size);
    }

    free(row_buffer);
}

As with the sound PR, I recognise there's a balance here between keeping true to the Agon's design spirit with the ez80 firmly in control and the VDP providing the equivalent functions of a period-correct video or sound IC, and making it possible to fully utilise the hardware combination. The UART link helpfully acts as a downward pressure on going too crazy here, since it takes ~10 seconds to transfer a 128x128 BMP file.

Regards,

Greg

Enhancement: Implement VDU 4 and VDU 5

Having VDU 4 and VDU 5 would make it possible to PRINT at pixel level (and back to character level). Example (from BBC User Guide):
10 VDU 5
20 MOVE 500,500
30 PRINT "2"
40 VDU 4

European Keyboard Support

FabGL has German, Italian and Spanish keyboard layouts as well. so you could add them all. Maybe configure such that diacritics are returned as iso-8859-1 or CP1252. And don't block the ` character please. We can run with a true ASCII screen font if we want. Or iso8859-1/cp1252 fonts.

Increase baud rate ESP32->EZ80 to 1152000

Change in agon.h

Allow the cursor blinking to be disabled

Currently, if the cursor is on, it will always blink. This makes it using the cursor in a text editor annoying because it blinks even when you are going through lines.

Allowing it to not blink and to be always visible makes it a lot easier for follow char / line / page movements.

Enhancement: Add ability to SOUND command to wait for sound playback to complete when duration is not -1

I believe that sound playback with the SOUND command currently operates asynchronously, which is desirable for video game sound effects and music. However, for some applications, it would be useful for sound playback to be synchronous, such that the system waits for the sound playback to complete (unless the duration value is set to -1).

I'm not sure if this feature can be implemented, nor am I sure how to extend the syntax of the current SOUND command to support such a feature.

Feature request: Upload binary data to VDP framebuffer

Please consider adding ability to upload data directly to the "screen" (VDP frame buffer), would make it much easier to display full-screen images / title screens etc.

• Upload RAW RGB bitmap data to "screen"

• Upload palette-indexed bitmap data to screen, which will be converted to appropriate RGB value in the framebuffer.

Edit: Nevermind, it looks like you can upload bitmaps larger than 256x256, which for some reason I thought was the limit.

Implement relative plotting modes and background/inverse.

I would like to implement the distinct 0..7 plot modes:
0..3 use relative coordinates.
4..7 use absolute coordinates
0,4 move, do not draw anything.
1,5 draw in foreground colour.
2,6 draw in inverse colour (this is FabGL's NOT operation I think).
3,7 draw in background colour
FabGL appears to have inverse colour support only for dots and lines, but it would be good to implement all these modes for them. Relative coordinates, fg and bg drawing can also be implemented for the other graphics primitives.

Use ISO-8851-1 (Latin1) codepage

From Lennart Benschop:

Maybe we should settle on iso-8851-1 (Latin1) as the character set for Agon. Then the £ key could return &A3 instead of &60 and the ` key just returns &60 (I have removed this secial case in my version). I know BBC basic for SDL by R.Russell contains a usable iso-8859-1 8x8 font.

Add support for changing number of colours per pixel in set_mode()

As an Agon Programmer
I want to be able to set resolution and # of colour planes independantly
So that I use higher resolutions in FabGL

Background: The ESP32 only has ~400K of DRAM available for data, so higher resolutions at full colour count do not work.

Acceptance Criteria:

• Be able to set the resolution and # of colour planes independantly
• A simple way of setting this up in the set_mode function

Contributers:

• Lennart Benschop
• Igor Chaves Cananea

Implement vdp-gl

Change build instructions for VDP
Implement palette change command updateRGB2PaletteLUT()

Increase quantity and quality of default modes in Agon

As an Agon user
I want to be able to have a selection of video modes with different resolutions
That are compatible with a wide range of monitors

SOUND hangs the system with channel numbers greater than 2

If a SOUND statement is issued with a channel number greater than 2, the system hangs. For example:
SOUND 3,-15,10,100
will cause this issue.
Assume only 3 channels (0-2) supported. Note that BBC BASIC supports 3 channels (1-3) and a noise channel (0)

MOS: 1.03 RC1
VDP: 1.03 RC1
Basic: 1.04 RC1

Sound enhacements round up

This is a mirror to a PR I have floating around (#31) but for the sake of tracking I wanted to list out the improvements to sound functions I humbly think are worthwhile in what I personally would suggest is priority order:

1. Infinite duration and non blocking notes (either as a separate function or where duration is 0 or -1 for the existing function).
2. Functions to alter only the volume or frequency of an infinite note already playing, without needing to issue a full new ahdio command.
3. PCM audio. FabGL can play back 16KHz 8bit signed PCM samples and I would suggest mirroring the approach you've taken to bitmaps, uploading PCM data to a specified 'slot' in PSRAM (which is plenty big and fast enough for this). This opens the door to off the shelf .WAV assets and generally brings audio into the late 80s and early 90s 😆 I have this so high because other than storing the PCM data playback isn't dependent on other audio code (there's a dedicated playsamples function) so it's almost zero effort.
4. Specifying a non-default waveform. My PR repurposes the currently ignored waveform byte in the VDU command to specify the audio function being called, and adds a new further function if a non standard wavetype is desired, but that's by no means necessary!
5. Very basic ADSR/FM sounds - I carried across the 'chiptune' fabgl example more or less unchanged for this, just integrated into the way vdp organises its channel loops.

Implement the mode parameter of GCOL for drawing commands

• 0: Plot the specified colour
• 1: OR the colour with the colour already there
• 2: AND the colour with the colour already there
• 3: XOR the colour with the colour already there
• 4: NOT (invert) the colour already there
• 5: No change to colour already there
• 6: Clear the colour - set it to colour 0

NB: FabGL only supports NOT and swapping the foreground and background colours

Investigate slow text output

Investigate an allegation by Igor Chaves Cananea on the Agon Facebook group that the text output is significantly slower in the later release candidates (after 1.03 RC1).

VDP 1.03 RC1 Keyboard Issue

Hi,
Just installed VDP 1.03 on my Agon Light 2 (Olimex) via Aurdino. All went fine but upon powering on Agon, each key were duplicated when a single was pressed. That is key stroke 'A' reflected as 'AA'
The only way I could install the new MOS 1.03 RC1 was to create an autoexec.txt file with the corresponding FLASH command in it. After that all was fine and able to run the BBC BASIC 1.04 Pre-release version.
Keep up the good work.
P.S. This may not be an issue if MOS 1.03 installed before VDP 1.03. Not sure what is the order.

Ability to send ESP32 programs to run

It seems to me like a lot of potential for graphics acceleration could be gained if it were possible to send programs over the serial link, which could run on the ESP32. This would allow much more direct manipulation of graphics in the VDP’s video memory.

Perhaps it could be implemented by adding some sort of mechanism for callbacks, where code could be run every frame.

Enhancement: Startup Beep

It would be nice to know when the MOS has loaded (perhaps before it executes the autoexec.txt). A use case could be that if there the display isn't connected, the user still knows that the machine itself is ready.

For inspiration on how the beep might sound please check here.

Palette support in VDP

From Phil Dalbeck on Agon FB Group

Is it possible to provide a basic/assembler VDP commands to allow for quick custom pallette configurations on the VDP (along with a sensible default palette)?

Add VDU commands for window operations

VDU 24,left;bottom;right;top;: Set graphics viewport
VDU 28,left,bottom,right,top: Set text viewport
VDU 26: Reset graphics and text viewports

• All graphics and text operations to be relative to those viewports.
• CLS and CLG will clear the viewport, not the canvas, if a viewport is set.
  • They will use the faster Canvas->clear() if no viewports have been set, or after a VDU 26.
  • They will not use the faster Canvas->clear() if the text viewport is defined to be the full canvas size.

Fix BBC BASIC so that it has a logical screen map, origin bottom left

As an Agon programmer
I want to be able to type in existing BBC BASIC programs with graphics commands
And for them to scale / display correctly

Acceptance Criteria:

• Origin: Bottom left of screen
• Scaling: 1280 x 1024 -> Screen Resolution

Suggestions: Maybe select VDP scaling/origin behaviour via a VDP sequence?

Incorporate Gerhard Skronn's Multi font into the VDP

Gerhard Skronn
https://github.com/anoriangit/agon-vdp
Add the ability to change to font files from command line
e.g.
SetFont gamefont.bmf
SetFont user.bmf
SetFont Televideo950.bmf - 14x10 font
SetFont PETSCII.bmf - 8x8 font

Reduce sprite flickering

The VDP sprites system is subject to a lot of flickering caused by updates during screen refresh. Find a way to mitigate this whilst maintaining normal draw performance and stability.

The term "VPD" and "VDP" seem to be incorrect.

I assume "VPD" is a typo. But I've even seen to spelled that way on the Byte Attic website.

Issue when uploading version 1.03RC

Hello,

I have an Agon Light 2 and when I try to upload the sketch for version 1.03rc I get the following error:

Arduino: 1.8.19 (Mac OS X), Board: "ESP32 Dev Module, Disabled, Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS), 240MHz (WiFi/BT), QIO, 80MHz, 4MB (32Mb), 921600, Core 0, Core 1, None"

esptool.py v3.3
Serial port /dev/cu.usbserial-10
Connecting......Traceback (most recent call last):

File "esptool.py", line 5387, in
Chip is ESP32-PICO-D4 (revision 1)
File "esptool.py", line 5380, in _main
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
File "esptool.py", line 4802, in main
Crystal is 40MHz
MAC: 0c:8b:95:aa:16:cc
File "esptool.py", line 1056, in flash_set_parameters
Uploading stub...
File "esptool.py", line 495, in check_command
Running stub...
File "esptool.py", line 468, in command
Stub running...
File "esptool.py", line 413, in read
Changing baud rate to 921600
StopIteration
Changed.
[24080] Failed to execute script 'esptool' due to unhandled exception!
Configuring flash size...
An error occurred while uploading the sketch

Any help is apprecated.

Update standard 8x8 character set to include all CP-1252 characters

Add a MODE 7 emulation to the VDP

True MODE 7 / Teletext emulation

• Control characters for colour, graphics, double-height text

VDU 23 0 255 Crash

This command crashes the Agon Light 2
MOS 1.03 and VDP 1.03 installed

Paged scrolling

As an Agon user
I would like to be able to pause after every page
So that I can browse long listings with ease

Acceptance Criteria:

• VDU 14 or CTRL+N to switch on
• VDU 15 or CTRL+O to switch off
• SHIFT to continue scrolling after each pause
• Must work with all applications without modification

Enahncement: Add text window support (VDU 28).

Now that I have implemented MODE7 in my own fork of the VDP, I see that some existing BBC Basic programs put control characters for foreground colour in the left column and then set a text window using VDU28, so these control codes will remain in place. It is also useful for interactively typing plotting commands, so the typed commands remain in a window separate from the graphics being plotted.

Therefore I think that VDU 28 is quite useful. VDU 28, left_column, bottom_row, right_column, top_row.
VDU 24 (graphics window) could also be implemented and of course VDU 26 to reset the windows to their defaults,which is full screen.
VDU24 probably requires some magic with Canvas->setClippingRectangle() to limit the extent of drawn lines to that window.
VDU28 can just be managed inside video.,ino, adding the required offsets and limit checks.

VGAController->setResolution(SVGA_1024x768_60Hz) crashes AgonLight2

As discussed on Facebook, agon-vdp crashes on my setup (AgonLight2, Sony SDM-E96D) when the modeline passed to the function VGAController->setResolution(modeLine) is the one for Mode 0 defined by the FabGL macro "SVGA_1024x768_60Hz".

The monitor powers off after warning there is no signal and the Agon needs to be reset before it responds again.

Serial debugging shows that the call to setResolution in change_resolution(int colours, char * modeLine) never returns.

   if(modeLine) {                                   
        debug_log("do_setResolution: modeLine: (%s)\n\r", modeLine);
        VGAController->setResolution(modeLine);        // Set the resolution
        debug_log("end_setResolution: modeLine: (%s)\n\r", modeLine);
    }

Serial log output when switching first to mode 1 then to mode 0

vdu_mode: 1
do_setResolution: modeLine: ("512x384@60Hz" 32.5 512 524 592 672 384 385 388 403 -HSync -VSync DoubleScan)
end_setResolution: modeLine: ("512x384@60Hz" 32.5 512 524 592 672 384 385 388 403 -HSync -VSync DoubleScan)
do_modeChange: canvas(512,384), scale(2.500000,2.666667)
vdu_mode: 0
do_setResolution: modeLine: ("1024x768@60Hz" 65 1024 1048 1184 1344 768 771 777 806 -HSync -VSync)

[At this point the monitor powers down. Agon remains unresponsive and serial debug output silent until device is reset.]

Workaround: replace SVGA_1024x768_60Hz modeline for mode 0 with a new custom definition:

#define SVGA_640x512_60Hz "\"640x512@60Hz\" 54 640 664 720 844 512 513 515 533 -HSync -VSync DoubleScan"

VDU 23,16 support for controlling cursor movement and screen scrolling

As a user, I want to be able to draw a screen using user defined graphics and PRINT TAB(X,Y). The current implementation has a problem where printing to the bottom right-most character forces a screen scroll.

This is the same behaviour as seen on the BBC Micro, but a workaround/new functionality was provided in the BBC Master MOS with the addition of VDU 23,16 (https://beebwiki.mdfs.net/VDU_23#VDU_23.2C16_-_Define_cursor_movement).

Please could VDU 23,16 support be added to facilitate this functionality?

This has previously been discussed on Stardot:

https://stardot.org.uk/forums/viewtopic.php?f=54&t=19452&p=270463
https://stardot.org.uk/forums/viewtopic.php?f=2&t=23312&p=333581

Example code, which when run in BeebEm shows the difference in behaviour between the BBC B (and Agon) and Master:

   10REM MODE 1 on the BBC: 40x32 characters (X=40, Y=32)
   20REM MODE 2 on the Agon: 40x25 characters (X=40, Y=25)
   30REM Set appropriate mode below and X,Y values
   50MODE 2
   60X=40
   70Y=25
   90REM Disable screen scrolling:
  100REM BBC Master only!
  110VDU 23,16,1,255,0,0,0,0,0,0
  130PROCdrawscreen
  150A=GET
  170END
  200DEF PROCdrawscreen
  220    REM Define border characters
  240    REM Horizontal Bar
  250    VDU 23,224,0,0,255,255,255,255,0,0
  260    REM Vertical Bar
  270    VDU 23,225,60,60,60,60,60,60,60,60
  280    REM Top Left Corner
  290    VDU 23,226,0,0,63,63,63,63,60,60
  300    REM Top Right Corner
  310    VDU 23,227,0,0,252,252,252,252,60,60
  320    REM Bottom Right Corner
  330    VDU 23,228,60,60,252,252,252,252,0,0
  340    REM Bottom Left Corner
  350    VDU 23,229,60,60,63,63,63,63,0,0
  370    REM Draw the frame
  390    REM *** Draw Line 0 ***
  410    PRINT TAB(0,0) CHR$(226);
  430    FOR J%=1 TO X-2
  440        PRINT TAB(J%,0) CHR$(224);
  450    NEXT J%
  470    PRINT TAB(X-1,0) CHR$(227);
  490    REM *** Draw middle lines ***
  510    FOR J%=1 TO Y-2
  520        PRINT TAB(0,J%) CHR$(225);
  530        PRINT TAB(X-1,J%) CHR$(225);
  540    NEXT J%
  560    REM *** Draw bottom line ***
  580    PRINT TAB(0,Y-1) CHR$(229);
  600    FOR J%=1 TO X-2
  610        PRINT TAB(J%,Y-1) CHR$(224);
  620    NEXT J%
  640    PRINT TAB(X-1,Y-1) CHR$(228);
  660ENDPROC

Add terminal support for CP/M

As an Agon user
I would like to switch to a CP/M compatible terminal mode
Without having to reload the VDP with different code

Acceptance Criteria:

• Need to be able to switch mode in MOS before starting CP/M
• It's a one-way trip, no way to exit CP/M terminal mode without resetting the Agon

Add new VDP command to generate a random number

It would be nice to get an hardware generated number provided by the VDP.

That would use https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/random.html

I don't know how it should be implemented in the MOS, though.

Check the mode change has worked correctly

When changing video mode in the VDP, check that the display height is the same as the viewport or canvas height. If they are not (viewport or canvas height < display height) then the mode has not been set correctly due to lack of memory on the ESP32. Throw an error and revert back to original mode.

Demo 'shadows.bas' has stopped working

This is probably down to the point function, either a change in behaviour due to palettes, or due to VDP timeouts.

Set keyboard delay and rate, and get/set the LED state

The fabgl::Keyboard class maintains virtual key state for every key on the keyboard.

It would be useful (for games, interactive apps and BBCBASIC INKEY scan for keypress) to be able to query the VDP for the current virtual key state (up / down / held) of any key. The VDP could then use fabgl::Keyboard.isVKDown() to return the key state.

As far as I understand the VDP currently only keeps track of the last pressed key (using Keyboard::getNextVirtualKey()).

It would also be nice to be able to send PS/2 commands to the keyboard via VDP, to eg switch the keyboard LEDs on or off, or set key repeat rate.

Set VGA 8 colour mode pallete to match the first 8 colours of vga 16 colour mode.

Currently the default pallete for 8 colour mode is rather boring (black, dark red, dark green, dark blue, red, green, blue, white).
We should set it to match the first 8 colours of the vga 16 colour mode pallete.

This needs to be done after a resolution change because as part of chaning the resolution the default pallete is always set.

So, within change_resolution, after the call to setResolution, we can add:

if (colours == 8) {
        VGAController->setPaletteItem(0, RGB888(0x00, 0x00, 0x00));
	VGAController->setPaletteItem(1, RGB888(0xAA, 0x00, 0x00));
	VGAController->setPaletteItem(2, RGB888(0x00, 0xAA, 0x00));
	VGAController->setPaletteItem(3, RGB888(0xAA, 0xAA, 0x00));
	VGAController->setPaletteItem(4, RGB888(0x00, 0x00, 0xAA));
	VGAController->setPaletteItem(5, RGB888(0xAA, 0x00, 0xAA));
	VGAController->setPaletteItem(6, RGB888(0x00, 0xAA, 0xAA));
	VGAController->setPaletteItem(7, RGB888(0xAA, 0xAA, 0xAA));
}

Switch VDP functionality via shorting expansion connector pins

It would be nice (I believe there is room in the ESP32 storage) if we could have both your BBC Micro-like screen control and VT100 in the VDP at the same time as while it's not hard to switch VDP firmware it can be a PITA moving jumpers (after opening case if you have one), switching power from psu to computer attached usb,... so if we could just jumper a couple of pins on the expansion port (a few esp32 pins seem to be available on it) and the VDP firmware checks them and if not jumpered runs standard screen control firmware and if jumpered switches to vt100 screen control

vdu_sys_sprites heap corruption

Agon crashes after reusing a bitmap, e.g. after running a program twice. VDP 1.03, FabGL 1.0.8

12:49:06.331 -> vdu_sys_sprites: reset
12:49:06.331 -> vdu_sys_sprites: bitmap 0 selected
12:49:06.331 -> CORRUPT HEAP: Bad head at 0x3ffae894. Expected 0xabba1234 got 0x3ffae6f4
12:49:06.331 -> 
12:49:06.331 -> assert failed: multi_heap_free multi_heap_poisoning.c:253 (head != NULL)
12:49:06.331 -> 
12:49:06.331 -> 
12:49:06.331 -> Backtrace: 0x4008788d:0x3ffb2020 0x4008ddc1:0x3ffb2040 0x4009392d:0x3ffb2060 0x4009359f:0x3ffb2190 0x40087c2d:0x3ffb21b0 0x4009395d:0x3ffb21d0 0x400d3317:0x3ffb21f0 0x400d3d28:0x3ffb2230 0x400d3f71:0x3ffb2250 0x400d436a:0x3ffb2270 0x400eb9ad:0x3ffb2290
12:49:06.331 -> 
12:49:06.331 -> 
12:49:06.331 -> 
12:49:06.331 -> 
12:49:06.331 -> ELF file SHA256: 54ce0c32490349e1
12:49:06.331 -> 
12:49:06.597 -> Rebooting...

Fix for me is to let fabgl::~Bitmap() handle heap free.

diff --git a/video.ino b/video.ino
index 3845f84..5c2c61d 100644
--- a/video.ino
+++ b/video.ino
@@ -1383,10 +1383,6 @@ void vdu_sys_sprites(void) {
 			width = rw;
 			height = rh;
 			//
-        	// Clear out any old data first
-			//
-        	free(bitmaps[current_bitmap].data);
-			//
         	// Allocate new heap data
 			//
         	dataptr = (void *)heap_caps_malloc(sizeof(uint32_t)*width*height, MALLOC_CAP_8BIT | MALLOC_CAP_INTERNAL);
@@ -1411,7 +1407,9 @@ void vdu_sys_sprites(void) {
 				// Create bitmap structure
 				//
 				bitmaps[current_bitmap] = Bitmap(width,height,dataptr,PixelFormat::RGBA8888);
-				bitmaps[current_bitmap].dataAllocated = false;
+				bitmaps[current_bitmap].dataAllocated = true;
+        const size_t free_heap = heap_caps_get_free_size(MALLOC_CAP_8BIT | MALLOC_CAP_INTERNAL);
+        debug_log("vdu_sys_sprites: free heap %lu\n\r", free_heap);
 			}
 	        else {
     	    	for(n = 0; n < width*height; n++) readLong_b(); // discard incoming data

8x16 font support

Speak to Lennart Benschop for details, must be complete CP-1252 character set.

*EDIT command *seems* slow and jerky at high resolution modes

*edit , in the lower resolutions is faster to process the input key once you press it, while if you go to higher modes, it takes noticiable time to process the input key, loosing the next pressed keys. Please let me know if you need more detail