User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Thu Aug 26, 2021 8:23 pm

RichardRussell wrote:
Thu Aug 26, 2021 7:53 pm
Don't worry too much about matching MODE numbers for modes above 7
Incidentally, MODE 7 itself can be 'perfectly' emulated if your VGA implementation supports the 512-character mode (9-bit character select, 3-bit background colour, 3-bit foreground colour and 1-bit flashing select). 512 characters is (just) enough to display all the Videotex (Teletext/Viewdata) symbols, including double-height alphanumerics,, single- and double-height contiguous mosaics and single- and double-height separated mosaics.

Again, I have x86 assembly language code to implement MODE 7 that way.

Memotech Bill
Posts: 380
Joined: Sun Nov 18, 2018 9:23 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 10:57 am

RichardRussell wrote:
Thu Aug 26, 2021 8:23 pm
Incidentally, MODE 7 itself can be 'perfectly' emulated if your VGA implementation supports the 512-character mode (9-bit character select, 3-bit background colour, 3-bit foreground colour and 1-bit flashing select). 512 characters is (just) enough to display all the Videotex (Teletext/Viewdata) symbols, including double-height alphanumerics,, single- and double-height contiguous mosaics and single- and double-height separated mosaics.

Again, I have x86 assembly language code to implement MODE 7 that way.
The Pico has no hardware support for character generation. It all has to be done in software. My experience is that timing limitations mean that each scan line has to be duplicated. In order to fit 25 lines of text on the screen I need an 8x9 font, which will be displayed as 8x18.

Yes, it should be possible to do an emulation of MODE 7.

If your ASM code includes definition of the glyphs for the fonts it could be helpful. How would you like to get that to me? One option might be to raise an issue on my GitHub repository.

ejolson
Posts: 8628
Joined: Tue Mar 18, 2014 11:47 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 2:25 pm

Memotech Bill wrote:
Fri Aug 27, 2021 10:57 am
RichardRussell wrote:
Thu Aug 26, 2021 8:23 pm
Incidentally, MODE 7 itself can be 'perfectly' emulated if your VGA implementation supports the 512-character mode (9-bit character select, 3-bit background colour, 3-bit foreground colour and 1-bit flashing select). 512 characters is (just) enough to display all the Videotex (Teletext/Viewdata) symbols, including double-height alphanumerics,, single- and double-height contiguous mosaics and single- and double-height separated mosaics.

Again, I have x86 assembly language code to implement MODE 7 that way.
The Pico has no hardware support for character generation. It all has to be done in software. My experience is that timing limitations mean that each scan line has to be duplicated. In order to fit 25 lines of text on the screen I need an 8x9 font, which will be displayed as 8x18.

Yes, it should be possible to do an emulation of MODE 7.

If your ASM code includes definition of the glyphs for the fonts it could be helpful. How would you like to get that to me? One option might be to raise an issue on my GitHub repository.
The thought that software driven VGA using the second core might be possible is one of the reasons along with simplicity that the original port of the interpreter uses only the first core. Graphics seem to be difficult due to RAM requirements, but a text based interface as in

viewtopic.php?p=1900168#p1900168

could be possible.
Last edited by ejolson on Fri Aug 27, 2021 3:55 pm, edited 1 time in total.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 3:00 pm

Memotech Bill wrote:
Fri Aug 27, 2021 10:57 am
The Pico has no hardware support for character generation. It all has to be done in software.
So it's not really VGA at all, but just a frame buffer with a certain resolution and colour depth?

In one way that makes things easier, since there is no shortage of off-the-shelf code available to support BBC BASIC's screen modes using just a frame buffer, for example in Matrix Brandy. That has the character fonts you might need too.

What resolutions, colour depths and refresh rates can the Pico do?

Memotech Bill
Posts: 380
Joined: Sun Nov 18, 2018 9:23 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 3:48 pm

RichardRussell wrote:
Fri Aug 27, 2021 3:00 pm
Memotech Bill wrote:
Fri Aug 27, 2021 10:57 am
The Pico has no hardware support for character generation. It all has to be done in software.
So it's not really VGA at all, but just a frame buffer with a certain resolution and colour depth?

What resolutions, colour depths and refresh rates can the Pico do?
As mentioned, I do have code for a 640x480x16 colour framebuffer. But that uses too much RAM.

Instead I will use a text buffer, and generate each raster line on the fly for each frame using the SCANLINE library. That will generate a 640x480x60Hz VGA signal with a 640x320 resolution (each scanine is duplicated). Each new scanline has to be rendered in the time the previous two are being output, so there is a limit on how much processing can be done in the rendering.

I am using the VGA demo board, which has 5bit resistor DACs on GPIO pins for each colour.

Memotech Bill
Posts: 380
Joined: Sun Nov 18, 2018 9:23 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 4:42 pm

The Pico has a total of 264KB of RAM. Any RAM used for video will come out of that available for Basic.

A 640x480x4bit framebuffer requires 150KB of RAM. In order to have 80 column text you really need a horizontal pixel count of 640. I suppose that 640x320x4bit (75KB) might just be workable.

Using a text buffer instead might use 6 bytes per character cell (2 bytes foreground colour, 2 bytes background colour, 1 byte code point, 1 byte flag). With an 80col x 26row buffer (one extra line for scrolling) that only requires 12.2KB. This could be reduced further by using fewer bits for the colours, but then there is a time penalty to do the palette lookup when rendering each character.

You also need a one scanline render buffer of 640x2 bytes = 1.25KB. You need this even for framebuffers if the framebuffer is less than 2 bytes per pixel.

I know that 640x480x60Hz is possible. If overclocked 800x600 may be possible. But the higher the vertical resolution the less time available for rendering each scanline.

User avatar
davidcoton
Posts: 6584
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 5:53 pm

Memotech Bill wrote:
Fri Aug 27, 2021 4:42 pm
The Pico has a total of 264KB of RAM. Any RAM used for video will come out of that available for Basic.
Lots of good memories of using the Beeb from this thread -- a Beeb was my second computer. At the time, I worked for a BBC Micro reseller. I'm sure the primary participants know most of what follows, but here are some details for the rest of us. I still have access to the User Guide (including Preliminary and Advanced versions).

The BBC Model B had 32KB RAM. Any RAM used for video came out of that available for Basic. This made the highest resolution modes virtually useless. Modes 0-3 used too much memory for use on the 16K RAM in a Model A.

Modes 0-2 used 20KB RAM. Only a few K were available for programs and variables in these modes, around 8KB depending on the hardware fitted.
The Mode 0 resolution was 80x32 characters or 640x256 graphics, in two colours. Modes 1 and 2 traded more colours for lower horizontal resolution. Mode 3 was 80x25 text only, but still used a 16KB bitmap. Modes 4-6 were half resolution versions of modes 0, 1 and 3. Mode 7 (Teletext) provided 40x25 characters in 1KB of RAM, block graphics only, in 8 colours. IIRC the control characters (colour and text/graphics, flash, etc) occupied a character position.

Admittedly, the Beeb then had a graphics processor (6845) and a ULA to generate the video signal, but 256K RAM would have been an unthinkable luxury! None of it was VGA compatible -- VGA was not introduced until 1987. Finally, the UK version as described here generated a PAL compatible signal (available as RGB, composite, or UHF modulated). The American version used fewer rows in each mode to give an NTSC-compatible signal.

I understand that the current project is about getting BBC BASIC running on a Pico -- however, it would be interesting to see how much of a BBC Microcomputer could be emulated on Pico-based hardware. :ugeek: :lol:
Location: 345th cell on the right of the 210th row of L2 cache

User avatar
rpdom
Posts: 19283
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 6:04 pm

davidcoton wrote:
Fri Aug 27, 2021 5:53 pm
Mode 7 (Teletext) provided 40x25 characters in 1KB of RAM, block graphics only, in 8 colours. IIRC the control characters (colour and text/graphics, flash, etc) occupied a character position.
Yes. The control characters were displayed as a space, unless the "Hold Graphics" control character had been used on that line, in which case the control character was displayed as the previous graphics character.
however, it would be interesting to see how much of a BBC Microcomputer could be emulated on Pico-based hardware.
A lot of it. There is a fully compatible BBC Micro emulator that runs on an overclocked Pico that will run Beeb code. It emulates keyboard and video. There are videos of various original games running on it including Frak! and Elite. I thin Kilograham was involved in it.
https://www.youtube.com/watch?v=vusGo64sDFk
Unreadable squiggle

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 6:54 pm

Memotech Bill wrote:
Fri Aug 27, 2021 4:42 pm
The Pico has a total of 264KB of RAM. Any RAM used for video will come out of that available for Basic.
A 640x480x4bit framebuffer requires 150KB of RAM. In order to have 80 column text you really need a horizontal pixel count of 640. I suppose that 640x320x4bit (75KB) might just be workable.
The BBC Micro uses the following amounts of memory for each mode, as hopefully you know:

MODE 0: 20K (640 x 256 x 2)
MODE 1: 20K (320 x 256 x 4)
MODE 2: 20K (160 x 256 x 16)
MODE 3: 16K (640 x 200 x 2)
MODE 4: 10K (320 x 256 x 2)
MODE 5: 10K (160 x 256 x 4)
MODE 6: 8K (320 x 200 x 2)
MODE 7: 1K (Teletext)

Importantly, the amount of memory available to BASIC changes dynamically according to the MODE selected. So if you can do the same, and perhaps implement some higher-resolution and/or greater colour-depth modes, that would allow the BASIC programmer to decide how he wants to trade off memory available to BASIC against graphics capability.

But I'm not at all sure how you can arrange the memory layout to enable that. If the frame buffer is at the very top of the 240K block, you would need to dynamically move the CPU's stack according to the graphics mode, and I don't know if that's possible.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 7:01 pm

davidcoton wrote:
Fri Aug 27, 2021 5:53 pm
I understand that the current project is about getting BBC BASIC running on a Pico -- however, it would be interesting to see how much of a BBC Microcomputer could be emulated on Pico-based hardware. :ugeek: :lol:
As has been noted, it's been done.

Acorn/BBC Micro purists would be horrified by our attempts to implement 'my' BBC BASIC on a Pico. :cry:

Memotech Bill
Posts: 380
Joined: Sun Nov 18, 2018 9:23 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 7:04 pm

davidcoton wrote:
Fri Aug 27, 2021 5:53 pm
Modes 0-2 used 20KB RAM. Only a few K were available for programs and variables in these modes, around 8KB depending on the hardware fitted.
The Mode 0 resolution was 80x32 characters or 640x256 graphics, in two colours. Modes 1 and 2 traded more colours for lower horizontal resolution. Mode 3 was 80x25 text only, but still used a 16KB bitmap. Modes 4-6 were half resolution versions of modes 0, 1 and 3. Mode 7 (Teletext) provided 40x25 characters in 1KB of RAM, block graphics only, in 8 colours. IIRC the control characters (colour and text/graphics, flash, etc) occupied a character position.
Yes, I have been thinking further about this. A 20K framebuffer is certainly more reasonable. For MODE 0, Richard's BBCSDL doubles the vertical resolution to 640x512. That would require a 40K framebuffer. And halving the horizontal resolution every time the colour depth is doubled keeps the frame buffer size constant.

A 640x512 image cannot be displayed in 640x480 VGA. But if I can do 800x600 it can be shown centred, with 80 pixel margin on either side, and 44 line margin top and bottom.

Extending the idea further an 800x600x1bit framebuffer requires 58.6K. That would enable me to reproduce the original Beeb modes 0-7 exactly (or with doubled vertical resolution), centred in the screen, plus the following full screen modes:
  • 800x600 2-colour
  • 400x600 4-colour
  • 200x600 16-colour
  • 400x300 16-colour
In addition, to accelerate rendering a 256x16 byte (=4K) lookup table will be required.

Only difference is I think the memory will have to be statically allocated and not shared with Basic, unless Richard can advise a way to do that.

Cross posted with the above. I think I can put the framebuffer anywhere so long as it doesn't move too often (only on a mode change). But I don't know how to tell Basic that that memory is reserved.

ejolson
Posts: 8628
Joined: Tue Mar 18, 2014 11:47 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 7:40 pm

RichardRussell wrote:
Fri Aug 27, 2021 7:01 pm
davidcoton wrote:
Fri Aug 27, 2021 5:53 pm
I understand that the current project is about getting BBC BASIC running on a Pico -- however, it would be interesting to see how much of a BBC Microcomputer could be emulated on Pico-based hardware. :ugeek: :lol:
As has been noted, it's been done.

Acorn/BBC Micro purists would be horrified by our attempts to implement 'my' BBC BASIC on a Pico. :cry:
That's right. Throughout this thread I've emphasized that BBC Basic on the Pico is not retro-computing but a self-hosted native programming environment. This makes it possible, for example, to efficiently use GPIO and PIO to solve practical problems.

What we have here is more like micro Python with a built-in editor and not at all like an 8-bit 6502 CPU emulator.

Memotech Bill
Posts: 380
Joined: Sun Nov 18, 2018 9:23 am

Re: BBC BASIC on the Raspberry Pi Pico?

Fri Aug 27, 2021 8:58 pm

ejolson wrote:
Fri Aug 27, 2021 7:40 pm
That's right. Throughout this thread I've emphasized that BBC Basic on the Pico is not retro-computing but a self-hosted native programming environment. This makes it possible, for example, to efficiently use GPIO and PIO to solve practical problems.

What we have here is more like micro Python with a built-in editor and not at all like an 8-bit 6502 CPU emulator.
Although on the VGA demo board documented in https://datasheets.raspberrypi.org/rp20 ... rp2040.pdf (chapter 3) which I am using there are almost no free GPIO pins by the time the VGA resistor DACs, SD card and sound are connected. It would be possible to create a custom board with fewer resistors in the DACs and no sound chip to free up a few connections, but that will then require changes to at least the video code. Not too many changes if just disconnecting the lsb of the DACs.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 4:26 pm

Memotech Bill wrote:
Fri Aug 27, 2021 7:04 pm
I think I can put the framebuffer anywhere so long as it doesn't move too often (only on a mode change). But I don't know how to tell Basic that that memory is reserved.
Any attempt at 'dynamic' placement of the framebuffer within BASIC's memory allocation comes with undesirable limitations:

  • Below HIMEM: You could only safely use a MODE statement when the interpreter's stack is empty, i.e. not within a loop, FN or PROC.
  • Above HIMEM: Changing the MODE to one which needs a larger buffer would evict any installed libraries (and cause a memory leak).

If you think dynamic allocation is worth pursuing, the second option is probably the less onerous. Although no existing programs will expect this behaviour, adapting them so that the MODE statement comes before any INSTALL statements would generally not be difficult.

ejolson
Posts: 8628
Joined: Tue Mar 18, 2014 11:47 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 4:34 pm

RichardRussell wrote:
Sat Aug 28, 2021 4:26 pm
Memotech Bill wrote:
Fri Aug 27, 2021 7:04 pm
I think I can put the framebuffer anywhere so long as it doesn't move too often (only on a mode change). But I don't know how to tell Basic that that memory is reserved.
Any attempt at 'dynamic' placement of the framebuffer within BASIC's memory allocation comes with undesirable limitations:

  • Below HIMEM: You could only safely use a MODE statement when the interpreter's stack is empty, i.e. not within a loop, FN or PROC.
  • Above HIMEM: Changing the MODE to one which needs a larger buffer would evict any installed libraries (and cause a memory leak).

If you think dynamic allocation is worth pursuing, the second option is probably the less onerous. Although no existing programs will expect this behaviour, adapting them so that the MODE statement comes before any INSTALL statements would generally not be difficult.
Since we have such a huge system stack now, would it be possible to put the frame buffer there. The next post will detail the current memory map and maybe an idea for a stack allocated video buffer.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 4:45 pm

ejolson wrote:
Sat Aug 28, 2021 4:34 pm
Since we have such a huge system stack now, I'd put the frame buffer there.
It's the easiest option, but it means that a fixed amount of memory must be allocated for the framebuffer (at least, I assume so), hence losing the flexibility of trading off the graphics resolution against the memory needed by a BASIC program etc. Losing 64K or so, whenever the VGA output is in use, is quite a large price to pay.

ejolson
Posts: 8628
Joined: Tue Mar 18, 2014 11:47 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 4:51 pm

RichardRussell wrote:
Sat Aug 28, 2021 4:45 pm
ejolson wrote:
Sat Aug 28, 2021 4:34 pm
Since we have such a huge system stack now, I'd put the frame buffer there.
It's the easiest option, but it means that a fixed amount of memory must be allocated for the framebuffer (at least, I assume so), hence losing the flexibility of trading off the graphics resolution against the memory needed by a BASIC program etc. Losing 64K or so, whenever the VGA output is in use, is quite a large price to pay.
I see what you mean. The difficulty seems to be having two heaps, multiple stacks and no virtual address space that allows each to grow independently.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 5:09 pm

Memotech Bill wrote:
Fri Aug 27, 2021 7:04 pm
  • 800x600 2-colour
  • 400x600 4-colour
  • 200x600 16-colour
  • 400x300 16-colour
Is there a particular reason why you've not included 800x300 4-colour in the set? Is the pixel clock too fast?

I presume all these modes have a full palette, i.e. the physical colours can have any RGB555 value. The BBC Micro had a hardware palette, of course, in the infamous VidProc ULA chip.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 5:19 pm

ejolson wrote:
Sat Aug 28, 2021 4:51 pm
The difficulty seems to be having two heaps, multiple stacks and no virtual address space that allows each to grow independently.
To be fair we've already got a very flexible arrangement, with four independently-growable regions: the interpreter's stack which grows down from HIMEM, the heap which grows up to meet it, the CPU stack which grows down from the top of memory, and the libraries which grow up to meet that.

But that does mean the only place to add yet another variable-size region (and it would have to change size only infrequently, on a MODE change) is between the top of the interpreter's stack and the bottom of the libraries, with one or other of the limitations I mentioned in my previous post depending on which end is fixed and which moves.

Memotech Bill
Posts: 380
Joined: Sun Nov 18, 2018 9:23 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 6:44 pm

RichardRussell wrote:
Sat Aug 28, 2021 5:09 pm
Is there a particular reason why you've not included 800x300 4-colour in the set? Is the pixel clock too fast?
RichardRussell wrote:
Sat Aug 28, 2021 5:09 pm

No real reason for not including it. Just overlooked it. If I can get this to work the pixel clock will be the same for every mode, generating an 800x600x60Hz signal. The width stretching is just done by outputting the same colour multiple times. Similarly the height stretching is done by outputting the same line multiple times. It is just a saving in framebuffer memory.

A couple of other options that are theoretically possible are:
  • 200x300x256 colour
  • 400x150x256 colour
RichardRussell wrote:
Sat Aug 28, 2021 5:09 pm
I presume all these modes have a full palette, i.e. the physical colours can have any RGB555 value. The BBC Micro had a hardware palette, of course, in the infamous VidProc ULA chip.
Correct, it should be possible to use the COLOUR command to assign any RGB555 value to any of the logical colours.
Last edited by Memotech Bill on Sat Aug 28, 2021 7:24 pm, edited 1 time in total.

Memotech Bill
Posts: 380
Joined: Sun Nov 18, 2018 9:23 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 6:58 pm

RichardRussell wrote:
Sat Aug 28, 2021 4:26 pm
Memotech Bill wrote:
Fri Aug 27, 2021 7:04 pm
I think I can put the framebuffer anywhere so long as it doesn't move too often (only on a mode change). But I don't know how to tell Basic that that memory is reserved.
Any attempt at 'dynamic' placement of the framebuffer within BASIC's memory allocation comes with undesirable limitations:

  • Below HIMEM: You could only safely use a MODE statement when the interpreter's stack is empty, i.e. not within a loop, FN or PROC.
  • Above HIMEM: Changing the MODE to one which needs a larger buffer would evict any installed libraries (and cause a memory leak).
If you think dynamic allocation is worth pursuing, the second option is probably the less onerous. Although no existing programs will expect this behaviour, adapting them so that the MODE statement comes before any INSTALL statements would generally not be difficult.
We now have the libtop pointer. Is there a similar libbot pointer independent of himem. If so, is there anything stopping just moving the libraries up when needing to expand the framebuffer, and back down again when shrinking it?

I never owned a BBC micro, so I am not that familiar with the language. However I do now have a copy of the manual. It looks as though the that machine did move himem when changing MODE. And the manual does document not in a procedure and function.

The memory map is going to get more complex anyway. Video generation will run in the other core, so I will need to allocate some memory for the core 1 stack. Hopefully it will not need too much.

ejolson
Posts: 8628
Joined: Tue Mar 18, 2014 11:47 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 8:17 pm

Memotech Bill wrote:
Sat Aug 28, 2021 6:58 pm
The memory map is going to get more complex anyway. Video generation will run in the other core, so I will need to allocate some memory for the core 1 stack. Hopefully it will not need too much.
The memory map of the last version I posted was

Code: Select all

-------------------------------------------------
FLASH | ROOT_OFFSET | Basic interpreter
=2M   | =1M         | free space
      |------------------------------------------
      |             | root LittleFS image
-------------------------------------------------
RAM= | data=32  | global variables
20K  | bss=5456 |
     |-------------------------------------------
     | malloc | TinyUSB malloc
     | heap   | LittelFS malloc
     |        | copy buffer malloc
     |        | KEY statement malloc
     |        | lfswrap FCB malloc
     |        | command history malloc
     |        | free space
-------------------------------------------------
SCRATCH_Y | PAGE_OFFSET | ACCSLEN=1K
=244K     | =5888       | Basic scratch
          |--------------------------------------
          | Basic program
          | interpreter heap
          | free space 
          | interpreter stack
          |---HIMEM boundary---------------------
          | BASIC libraries
          |---LIBTOP boundary--------------------
          | free space
          | CPU stack
-------------------------------------------------
The GitHub version after adding FAT filesystem support appears similar, except now RAM=24K and SCRATCH_Y=240K.

The obvious place to put the second CPU stack would be between SCRATCH_Y and RAM. This is what's done in the standard memory map. The result would then look like

Code: Select all

-------------------------------------------------
FLASH | ROOT_OFFSET | Basic interpreter
=2M   | =1M         | free space
      |------------------------------------------
      |             | root LittleFS image
-------------------------------------------------
RAM= | data=32  | global variables
24K  | bss=5456 |
     |-------------------------------------------
     | malloc | TinyUSB malloc
     | heap   | LittelFS malloc
     |        | copy buffer malloc
     |        | KEY statement malloc
     |        | lfswrap FCB malloc
     |        | command history malloc
     |        | free space
-------------------------------------------------
SCRATCH_X | free space
=4K       | second CPU stack
-------------------------------------------------
SCRATCH_Y | PAGE_OFFSET | ACCSLEN=1K
=236K     | =5888       | Basic scratch
          |--------------------------------------
          | Basic program
          | interpreter heap
          | free space
          | interpreter stack
          |---HIMEM boundary---------------------
          | BASIC libraries
          |---LIBTOP boundary--------------------
          | free space
          | first CPU stack
-------------------------------------------------
My understanding is that one has to disable interrupts on both cores during the times LittleFS writes to flash while running the ARM binary from flash. It's possible storing the executable for the second core in RAM removes this requirement. If so, that would be a great simplification and further allow the video to continue refreshing while a file is being saved. Does the VGA driver already run from RAM?

If anyone reading this could comment on the details of writing to flash while running code on both cores, that would be appreciated.

Memotech Bill
Posts: 380
Joined: Sun Nov 18, 2018 9:23 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 8:55 pm

ejolson wrote:
Sat Aug 28, 2021 8:17 pm
My understanding is that one has to disable interrupts on both cores during the times LittleFS writes to flash while running the ARM binary from flash. It's possible storing the executable for the second core in RAM removes this requirement. If so, that would be a great simplification and further allow the video to continue refreshing while a file is being saved. Does the VGA driver already run from RAM?
The code for the main video render loop has to reside in RAM for speed reasons. However the SCANLINE video code relies extensively on interrupts to keep CPU, DMA and PIO in step. So any significant period with interrupts disabled is likely to impact video generation.

I am almost seeing to different Pico versions for two different use cases:
  • A version with console on USB or UART, storage in flash and lots of free GPIO connections. A micro-python alternative. SD card storage as an optional extra for logging applications.
  • A version with USB keyboard and VGA output. This is much closer to a retro-computing application. Includes graphics capabilities. Using the commercially available board has no free GPIO, although it would be possible to make a custom board with some available GPIO.
I am also coming to the conclusion that it may be necessary to split the source code that way, otherwise too many #ifdef.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 9:13 pm

Memotech Bill wrote:
Sat Aug 28, 2021 6:58 pm
is there anything stopping just moving the libraries up when needing to expand the framebuffer, and back down again when shrinking it?
That won't work, because pointers to FNs and PROCs (which are what libraries contain) are absolute; so if you move the library they will point to the wrong place! Generally, BBC BASIC's pointers are absolute, at least they are in 32-bit editions.
It looks as though the that machine did move himem when changing MODE. And the manual does document not in a procedure and function.
Yes, on the BBC Micro (uniquely) you cannot change MODE in a PROC or FN, but that's not a serious limitation. However with more recent versions of BBC BASIC (including Acorn's ARM BASIC 5, Brandy BASIC and my BASICs), in which the interpreter's stack is also used by loops, it would mean you cannot change MODE in a FOR...NEXT, REPEAT...UNTIL or WHILE...ENDWHILE loop either. That would be unacceptable.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC BASIC on the Raspberry Pi Pico?

Sat Aug 28, 2021 10:40 pm

Just looking at the README at GitHub and there appears to be one thing out-of-date and another which may be a misunderstanding:

  • "HIMEM-PAGE=65K with an additional 32K has [sic] reserved for CALL and INSTALL libraries".
The current values are much greater than this I think (hope), more like 160K and 64K respectively.

  • "The *CD command has been modified to automatically change the built-in variable @dir$....".
@dir$ is neither the 'current' directory nor the directory from which the executable was launched, it's the directory containing the currently loaded BASIC program. The purpose of @dir$ is to tell a program from where to load resource files, such as sprites, images, sounds, music etc.

In practice, in the Console Mode editions, it's the directory containing the program which was specified on the command line. So for example if executed with:

Code: Select all

bbcbasic /path/to/myprog.bbc
@dir$ should contain "/path/to/". It should not contain the path containing bbcbasic nor the "current" directory (if the filing system has such a concept, which it doesn't on Android and may not on the Pico).

It's debatable whether CHAIN should change @dir$; currently it doesn't in any of my versions because CHAIN is assumed to be for running an overlay rather than an entirely different program. For example you might have:

Code: Select all

      CHAIN @dir$ + "overlays/overlay1"
in which case changing @dir$ would not be helpful.

Return to “General”