On the bbc-micro, a half-size mode 1 screen mode with 16 colours instead of 4 can fit in memory but can the video chip be programmed for it?
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
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 (?
) (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 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
hardware video bbc-micro color-display screen
New contributor
add a comment |Â
up vote
4
down vote
favorite
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 (?
) (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 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
hardware video bbc-micro color-display screen
New contributor
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
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 (?
) (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 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
hardware video bbc-micro color-display screen
New contributor
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 (?
) (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 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
hardware video bbc-micro color-display screen
hardware video bbc-micro color-display screen
New contributor
New contributor
New contributor
asked 4 hours ago
therobyouknow
1234
1234
New contributor
New contributor
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
With all these 'or' inbetween 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 (inofficial) 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 horizonal 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 Beep 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 ment 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 wile there is no secret trick possible to read more lines, we always can read less - per line and 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 pixels, thus only 80 pixels in 16 colour mode and so on. The formula stays the same. Down to 10 byte per line mode or 20 16 colour pixels. Handy for some Pong or Breakout, isn't it?
Similar, lines could be skiped saving again memory.
Conclusion: Whatever resolution you want, you're restricted to a macimum 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 reprogrammign the 6845 directly. Except, neiter the OS nor BASIC will give you any support using this - not to mention that it's not much and rather tricky to make it work within the timing of the Beeps Hardware.
*1 - Or more correct addresses prepared for a moemory access.
+1 thanks and accepted answer
â therobyouknow
49 mins ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
With all these 'or' inbetween 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 (inofficial) 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 horizonal 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 Beep 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 ment 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 wile there is no secret trick possible to read more lines, we always can read less - per line and 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 pixels, thus only 80 pixels in 16 colour mode and so on. The formula stays the same. Down to 10 byte per line mode or 20 16 colour pixels. Handy for some Pong or Breakout, isn't it?
Similar, lines could be skiped saving again memory.
Conclusion: Whatever resolution you want, you're restricted to a macimum 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 reprogrammign the 6845 directly. Except, neiter the OS nor BASIC will give you any support using this - not to mention that it's not much and rather tricky to make it work within the timing of the Beeps Hardware.
*1 - Or more correct addresses prepared for a moemory access.
+1 thanks and accepted answer
â therobyouknow
49 mins ago
add a comment |Â
up vote
2
down vote
accepted
With all these 'or' inbetween 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 (inofficial) 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 horizonal 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 Beep 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 ment 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 wile there is no secret trick possible to read more lines, we always can read less - per line and 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 pixels, thus only 80 pixels in 16 colour mode and so on. The formula stays the same. Down to 10 byte per line mode or 20 16 colour pixels. Handy for some Pong or Breakout, isn't it?
Similar, lines could be skiped saving again memory.
Conclusion: Whatever resolution you want, you're restricted to a macimum 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 reprogrammign the 6845 directly. Except, neiter the OS nor BASIC will give you any support using this - not to mention that it's not much and rather tricky to make it work within the timing of the Beeps Hardware.
*1 - Or more correct addresses prepared for a moemory access.
+1 thanks and accepted answer
â therobyouknow
49 mins ago
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
With all these 'or' inbetween 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 (inofficial) 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 horizonal 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 Beep 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 ment 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 wile there is no secret trick possible to read more lines, we always can read less - per line and 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 pixels, thus only 80 pixels in 16 colour mode and so on. The formula stays the same. Down to 10 byte per line mode or 20 16 colour pixels. Handy for some Pong or Breakout, isn't it?
Similar, lines could be skiped saving again memory.
Conclusion: Whatever resolution you want, you're restricted to a macimum 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 reprogrammign the 6845 directly. Except, neiter the OS nor BASIC will give you any support using this - not to mention that it's not much and rather tricky to make it work within the timing of the Beeps Hardware.
*1 - Or more correct addresses prepared for a moemory access.
With all these 'or' inbetween 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 (inofficial) 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 horizonal 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 Beep 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 ment 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 wile there is no secret trick possible to read more lines, we always can read less - per line and 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 pixels, thus only 80 pixels in 16 colour mode and so on. The formula stays the same. Down to 10 byte per line mode or 20 16 colour pixels. Handy for some Pong or Breakout, isn't it?
Similar, lines could be skiped saving again memory.
Conclusion: Whatever resolution you want, you're restricted to a macimum 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 reprogrammign the 6845 directly. Except, neiter the OS nor BASIC will give you any support using this - not to mention that it's not much and rather tricky to make it work within the timing of the Beeps Hardware.
*1 - Or more correct addresses prepared for a moemory access.
edited 37 mins ago
answered 58 mins ago
Raffzahn
34.8k477137
34.8k477137
+1 thanks and accepted answer
â therobyouknow
49 mins ago
add a comment |Â
+1 thanks and accepted answer
â therobyouknow
49 mins ago
+1 thanks and accepted answer
â therobyouknow
49 mins ago
+1 thanks and accepted answer
â therobyouknow
49 mins ago
add a comment |Â
therobyouknow is a new contributor. Be nice, and check out our Code of Conduct.
therobyouknow is a new contributor. Be nice, and check out our Code of Conduct.
therobyouknow is a new contributor. Be nice, and check out our Code of Conduct.
therobyouknow is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7706%2fon-the-bbc-micro-a-half-size-mode-1-screen-mode-with-16-colours-instead-of-4-ca%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password