11

Screen Mode 2 on the BBC micro is 160 x 256 with "16"* colours. This uses up 20Kb of memory. Horizontal-rectangular pixels ( 2 x squares each). 4 bits per pixel (0-15 values for 16 colours)

Screen Mode 1 on the BBC micro is 320 x 256 with 4 colours, again 20Kb.

A half height or half width Mode 1 can be programmed (I've done it) by VDU codes/pokes (?)/*fxs (if I vaguely recall). 2 bits per pixel (0-3 values for 4 colours)

With the memory saving of that, (down to 10Kb)then it should be possible to set mode 1 to use more colours, i.e. 16 colours (4bpp instead of 2). This will double the memory required back to 20Kb but will still fit in the memory.

Any idea how to program to get 16 colours. E.g. VDU command sequences and/or poking memory with the ? command, or *fx command(s)?

Or was it a limitation of bandwidth with the 6845 chip that couldn't handle both 320 horizonal pixels and 4bpp?

The point of this would be to achieve the higher resolution graphics, afforded by the square pixels in mode 1 but with more colours. So that it looked similar to ZX Spectrum games but with the advantage of full programmable individual pixels.

*16 colours is actually only 8. With an additional 8 alternating between 2 colours. 8 colours are black white red yellow green cyan blue magenta

Improve this question

1 Answer 1

Reset to default
13

With all these 'or' in between and jumping between various points, requirements and conclusions, it's a bit unclear what your're looking for.

If this is about most colour with least memory, then the (unofficial) modes Mode 8 and Mode 13 are your thing.

Or was it a limitation of bandwidth with the 6845 chip that couldn't handle both 320 horizontal pixels and 4bpp?

Short answer no. 320 pixel with 4 bits each equals to 1280 bit or 160 bytes per line. Double the maximum the Beeb design can do.

Long Answer:

Yes and No. The 6845 doesn't handle any content or colours. It was originally designed to support a character based screen. It's just a bunch of counters to create sync signals and addresses during a frame. The 6845 only generates the frame. All content generation is external. The addresses were meant to access a linear character screen memory which then gets translated via a character ROM into rows of a character to be shifted into the video signal.

In the BBC the content generation is handled by a custom gate array (usually called Video-ULA) that takes the byte addressed by the 6845 and interprets it according to what's set in its control register.

While the 6845 can be put to use with a large variety of screen formats, it always comes down to the amount of bytes read in a line (*1). In the BBC it can be used to read 10, 20, 40 or 80 bytes per line. That's a maximum of 640 (80x8) bits per line. Resolution and colour depth are factors to this number, so quite simple:

Bits-per-Line divided by Colour-Depth equals Pixels-per-Line

Bits      Colour  Pixels
per Line  Depth   per Line

640       1       640
640       2       320
640       4       160

These are the absolute maximum resolutions per line at a given color depth.

And while there is no secret trick possible to read more lines, we always can read less per line and fewer lines. And that's what accounts for the memory 'saving' mentioned. As mentioned before, the system can be set to read less bytes per line, like only 40, which of course reduced the amount of bits read per line and thus memory needed - but also resolution as well. 40 bytes read mean 320 bits, which can be converted into 80 pixels in 16 colour mode and so on. The formula stays the same. Down to 10 byte per line mode giving twenty 16 colour pixels per line. Handy for some Pong or Breakout, isn't it?

Similar, lines could be skipped saving again memory.

Conclusion: Whatever resolution you want, you're restricted to a maximum of 640 bits per line to hold the data to be displayed.

Having said that, it may be possible to squeeze out a bit more by reprogramming the 6845 directly. Except, neither the OS nor BASIC will give you any support doing this - not to mention that it's not much and rather tricky to make it work within the timing of the Beeb's hardware.

*1 - Or more correct addresses prepared for a memory access.

Improve this answer
4
  • In addition to the Modes ROM, the VideoNULA also offers 80 column text with more than 2 colours, at least 8, with its "attriibute" modes, as well as a palette of 4096 colours available from the 2, 4 and 16 colour modes to choose from. stardot.org.uk/forums/viewtopic.php?t=13632 youtube.com/watch?v=65dyaePHH3Y github.com/bitshifters/bbc-nula/tree/master/gallery/images/…
    – therobyouknow
    Oct 28, 2018 at 9:37
  • Well, with added hardware eveything is possible.
    – Raffzahn
    Oct 28, 2018 at 10:57
  • I would guess that if the half size MODE 1 took the form of a portrait orientation (160 x 256 square pixels rather than 256 x 160 ) whereby the horizontal width was the shortest side and the vertical the longest, then there would be enough bandwidth per horizontal line to support more colours. This would have the same resolution and orientation as MODE 2 - 160 x 256 but square pixels instead of rectangular.
    – therobyouknow
    Apr 17, 2019 at 9:09
  • 3
    @therobyouknow Actually no. The true limitation is that the RAM is used alternately to serve the CPU and the display, so 2MB/sec (16Mbit/s) is available to generate pixels from. Given the fixed video timing parameters (set by the PAL broadcast TV standard), the width of a pixel is effectively defined by its length in time. In MODE 1, the pixel clock is 8MHz, so you can use 2 bits per pixel to define its colour. Period.
    – Chromatix
    Jan 10, 2020 at 19:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .