Which home-retrocomputers had a 1 single-color( no shades ) monochrome mode, or were by default ?

( I'm referring to home-retrocomputers in a time range from say 1976 to 1984 )

( And even better if they either had no sound-capability, or the sound capability could be turned off, which is a stupid thing to type I know )

( My reason for asking is that in my opinion, 'maybe', this is the type of computer that people who were interested in doing 3D animated graphics, e.g. a 3D rotating cube, should have bought, since I think the graphics-generating-speed 'may' have been faster, however many experts in this area disagree with this theory )

NOTE - The moderators put my question on hold for being too broad, and asked me to rewrite it

closed as too broad by Raffzahn, Wilson, Sean Houlihane, Stephen Kitt, wizzwizz4 Mar 24 '18 at 8:51

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    The color space is unrelated, it simply comes down to resolution and bits per pixel. Typically the highest resolutions were B&W but now you're down to 1 bit/pixel, so you have to deal with the CPU to manage the bit twiddling vs simply storing the screen buffer. For what it's worth, I did "3D graphics" on a PET 2001 (40x24), and, not only was the resolution bad, it was still slow. – Will Hartung Mar 23 '18 at 4:16
  • 2
    @WillHartung FWIW, ZX81 was also not just monochrome, but text only, with 64x48 pseudographic (and no sound) - and the hit game 3D Monster Maze was remarkably, well, 3D. – Radovan Garabík Mar 23 '18 at 8:08
  • 3
    The fastest graphic modes you can get should be 1 byte/pixel, as it gets rid of bit manipulation completely - The only thing you can do quickly in a 1-bit mode is draw vertical and horizontal lines. Otherwise, you need to (1) calculate screen byte to access (2) calculate pixel bit position (3) fetch existing screen byte (4) create pixel mask and mask in pixel (5) write byte to frame buffer. In an 8-bit mode, you simply write a byte with very straight-forward addressing (y * line-length + x). Such 8-bit-modes were, however, out of reach for most of the computers in your envisaged time range. – tofro Mar 23 '18 at 8:12
  • 1
    Still, there were games that managed animated full-3D graphics on machines of the era. Elite, Starion, many flight simulators, maze games, and so on. – Jules Mar 23 '18 at 9:10
  • Also: ZX Spectrum Hard Drivin’; Starstrike II; I, Of the Mask... – Tommy Mar 23 '18 at 11:16

Many machines particularly in the early portion of the period you ask about only had monochrome graphics. The Commodore PET, TRS-80, Sinclair ZX80 and ZX81 were all monochrome only. Many colour machines also had monochrome modes, although usually these were high resolution so wouldn't have had higher performance. The BBC Micro as mentioned in the question is one of these, as is the Amstrad CPC464 and the IBM PC (all 3 of these machines were based on the same display chip, the MC6845). Also, some colour machines that didn't support multiple resolutions used a memory arrangement where monochrome pixels were stored in one area of memory and colours were assigned to them in another, which means that speed of making changes to the pixels if you weren't using colour was as fast as it would have been if the system were monochrome. The Sinclair ZX Spectrum and I believe Commodore 64 used this approach.

This basically means that most of the colour machines of the early 80s had graphics modes that allowed 1-bit-per-pixel operations.

  • 2
    Others: add the MSX and everything else TMS, and the Vic-20 to the 1 bpp plus extra colour information pile; also the Oric is effectively 8/6ths of a bit per pixel monochrome if you avoid control characters, and the Apple II is very much like 8/7ths bpp. I think the 8-bit Ataris also do 1 bpp, and the ST definitely does. The Camputers Lynx is bit planes like the Amiga but TTL so you can go 1 bpp as long as you don't mind graphics that are either red, green or blue. – Tommy Mar 23 '18 at 11:24
  • 1
    Yet more: the CDP1861 “Pixie” graphics on RCA home computers (~1976-1978). Typically configured as a 64×32 bitmap using 256 bytes, as in the CHIP-8 virtual game machine. – scruss Mar 23 '18 at 15:09

( I think the introduction of colors and sound to cheap( 1980 onwards ) home-computers from 1975 to 1985 was the reason( or a reason ) why they were so slow or incapable of satisfactorily displaying 3D moving graphics, and yet this was the sort of effect for which many people bought the machines, I have always wondered if there was a secret 'Monochrome-Mode' available in many of these machines from 1975 to 1985

No, no, and no.

The demand wasn't there

Back then few people bought home computers for 3D graphics. 3D was used mostly in high CAD workstations, which were very expensive and not optimized for arcade games. If the demand for 3D was higher then manufacturers could have optimized their chipsets for it. But most people wanted fast 2D color graphics, which is why chips such as the VIC-II and TMS9918 were developed.

Even after 1985 most home computers concentrated on producing good 2D graphics. The Amiga was the ultimate example. It had a hardware blitter which could draw lines, and the AGA chipset could produce 256 colors. But screens were built from multiple monochrome bitplanes, and the blitter (or CPU) could only work on one bitplane at a time. This was ideal for scrolling 2D backgrounds etc., but not so good for 3D graphics.

The only 80's machine I can think of that was designed specifically for 3D was the Vectrex video game system. It used true vector graphics (not bitmapped, the CRT beam was moved directly around the screen to draw lines) with plastic screen overlays to simulate color and static graphics. The main problem with this design was poor text and zero bitmap capability. It didn't last long and was a commercial failure.

Proper 3D graphics didn't become popular until the IBM VGA card became a standard. It had a 'chunky' 256 color graphics mode with 1 byte per pixel which made mapping surface textures easier. Games such as Wolfenstein 3D and Doom changed people's desires. But it wasn't just the VGA card's chunky pixels that made these games work. They also needed lots of memory and a powerful CPU, things that were beyond the reach of home computers in the early 80's.

The CPU was the bottleneck

Colors could be reduced to speed up rendering. Sound was usually produced by independent hardware, or by toggling a bit in-between doing other stuff. But RAM was slow and expensive, and the CPUs were relatively inefficient.

Without a floating point unit or even integer multiply/divide instructions, the CPU spends most of its time doing calculations. Setting pixels is just the final stage and only takes a few cycles. This is proven by the fact that true 3D games were much slower than complex 2D games, even on machines that had no hardware scrolling or sprites. Games that used pseudo 3D techniques (eg. isometric 3D, scaled software sprites, multi-layer backgrounds) could be just as fast as 2D.

Any 'secrets' were soon discovered

Most machines at that time had monochrome graphics modes that were no secret, but color was more desired for games so the monochrome modes were used less. Some machines (eg. the Apple-II) were both mono and color at the same time, depending on what screen they were hooked up to. A few machines did have 'secret' graphic modes that were simply unintended side-effects of how their chipsets worked - most of them not particularly useful and perhaps even dangerous (eg. reprogramming the sync timing on a 6845 could blow up your monitor).

I'm thinking that a single-color-monochrome computer by default, would be faster than one which has single-color-monochrome only as a selectable mode( since the color capability would still be present etc )

No. The designers of these computers were acutely aware of the limitations and trade-offs that had to be made to get the best performance at lowest cost. Creating a screen mode that doesn't use color but suffers the slowdown of having it would be stupid.

The main reasons for color slowdown are that the CPU has to write to more memory and/or the display controller steals more bandwidth. At the same resolution in monochrome mode the CPU has less work to do and bandwidth requirements are lower, so it can render faster.

Some machines allocate the same amount of video memory no matter what the graphics mode. Resolution then increases as the number of colors decrease, negating the primary benefits of monochrome. However that doesn't make them any slower than a purely monochrome machine at the same resolution.

  • I should gave specified in my question, 'programmable-home-computers', I'm sure there was no way to put a home-made program on the Vectrex( vector-graphics ) 'back then', I think the Compucolor of 1976 also used 'vector-graphics', or maybe it was the 'Compucolor II' – texttext Mar 24 '18 at 21:10
  • You typed "If the demand for 3D was higher then manufacturers could have optimized their chipsets for it.", yes , that explains the lack of suitable machines, it makes me wonder if there were cheap( affordable ) , < 500-$, business or other machines that people could have bought, but then they could not have sold their 3D creations to the main home-computer market ( different hardware ) – – texttext Mar 24 '18 at 21:41
  • 1
    "I'm sure there was no way to put a home-made program on the Vectrex( vector-graphics ) 'back then'" - theoretically it could be programmed with a suitable cartridge, but who would want to? Most commercial games for home computers were cross-developed on more powerful machines anyway (been there, done that!). The Compucolor II's 'graphics mode' was only 128x128 pixels. It was effectively the same as the character-based block graphics on the ZX81 etc. compucolor.org/tech.html – Bruce Abbott Mar 24 '18 at 23:51

My reason for asking, is that I think that all things being equal, that a single-color-monochrome-mode or by default computer, should be faster for things like 3D moving graphics.

You asked a complex question, including some assumptions into it.

You assume that reducing number of colors has direct positive effect on the image rendering. While it should be logically correct, it is not because of the computer architecture. As people in comments say, 8-bit computer operates bytes, not bits, and reducing pixel to one bit may make actually things harder to "assemble" correct 8-bit value for display from 8 distinctive values. From architectural point of view it is faster to operate 8-bit values rather than 1-bit values, thus 256-color dynamic graphics may prove to be faster than monochrome - unless there's hardware acceleration for it.

What do you assume saying "3D moving graphics"?

  • 3D is drawing picture in perspective made up from 3 coordinates;
  • moving assumes specific fps (frames per second);
  • 3D angle view can move.

Thus while games like Monster Maze for ZX or Black Onyx for MSX have 3D look, their frames per second are low, and angle can only be 90 degrees horizontal, so we can hardly compare them to the later games like DOOM which runs at 25 fps. I would say it is a kind of pseudo-3D graphics, however looking great for those times and still now in terms of how developers use capabilities of machines (not just video, but RAM and CPU).

3D graphics would be much faster if they have hardware acceleration - for example, video display processor (VDP) quickly reading data from its VRAM constructing image from various planes and set of coordinates and filling them with texture, but at those times, to my knowledge, these capabilities did not exist for home computers, however some 2D hardware acceleration was already in (e.g. look into the V99x8 VDPs used in MSX).

they were so slow or incapable of satisfactorily displaying 3D moving graphics

You can not talk about performance of graphics without considering performance of whole system, and its resources.

  • hardware acceleration;
  • size of RAM or VRAM storing ready-to-use patterns and textures;
  • CPU speed moving data from RAM or external devices to the video subsystem;
  • other tasks CPU has to do in parallel (e.g. playing music, managing interrupts, or even actively driving output to the screen).

I think the 1-bit vs 1-byte thing is a bit of a red herring, to be honest.

IMHO it is not for simple reason - processing of single bit for 8-bit computer 8 times takes more time than processing 8 bytes, and it hits performance badly if we talk about moving graphics.

3D graphics is all about drawing filled polygons ... it needs to be done in order to remove details from objects behind the object being drawn

I was investigating the issue some time ago, wanted to make FPGA-base video accelerator. And I was told that modern 3D graphics is about triangles; the 3D drawing includes several stages to minimize excessive consumption of GPU power, and, to my understanding, the behind objects (triangles) must simply not appear to be rendered.

and the most useful way of doing that is enumerating the pixels along each edge and then filling across the scanlines from edge to edge

This is very logical, and before I started making my implementation I also thought it would be the best way. In real implementation it is not that straightforward though.

This is done most efficiently in a 1-bit-per-pixel bitmap

Agreed if VRAM would be organized as 1 bit, for 8-bit data width RAM it will cause 8 RMW (read-modify-write) operations.

  • 1
    I think the 1-bit vs 1-byte thing is a bit of a red herring, to be honest. 3D graphics is all about drawing filled polygons (even if the fill is in the background colour, it needs to be done in order to remove details from objects behind the object being drawn), and the most useful way of doing that is enumerating the pixels along each edge and then filling across the scanlines from edge to edge. This is done most efficiently in a 1-bit-per-pixel bitmap, at least for reasonably large polygons (handling the edges would be inefficient for polygons less than ~4 pixels wide I think). – Jules Mar 23 '18 at 9:55
  • 1
    "the behind objects (triangles) must simply not appear to be rendered" -- that's the modern approach, and the only way that scales to large numbers of objects, but for simple scenes drawing the farthest object first and overwriting it with data from closer surfaces is good enough, and requires less calculation. "Agreed if VRAM would be organized as 1 bit, for 8-bit data width RAM it will cause 8 RMW (read-modify-write)" -- Filling along scanlines of a bit-per-pixel buffer can be done with 2 RMW ops for the ends of the fill + 1 write operation per 8 pixels for intermediate points. – Jules Mar 23 '18 at 12:23
  • @Jules For "filled polygons" you're right, but not for wireframe (Elite, for example) – tofro Mar 23 '18 at 13:02
  • Even with wireframe, you could use run-slice drawing rather than classic Bresenham to ensure you RMW each touched byte only exactly once. At the setup cost of a divide with remainder per line though. – Tommy Mar 23 '18 at 14:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.