The character ROM is a Signetics 2513 "64×8×5 Character
Generator," a 2560-bit static ROM. (Data sheet alternate
Address lines A1-A3 (Signetics started the numbering at 1) select one
of the eight rows of five pixels for a character (the top row is
usually all-zero for a 5×7 matrix) and address lines A4-A9 indicate
the character code.
The Atari 7800 kept almost all information about sprites, including positions, in general-purpose RAM, re-fetching it every scan line. Any time the RAM spent serving up sprite data was time stolen from the CPU, so the amount of data one could display was very dependent upon how much CPU time one wanted to have left.
The hardware didn't make decisions about ...
The other posts about hardware and gate costs better answer your question, but I'll add this as a counterpoint: A situation where a game programmer decided not to take advantage of hardware collision detection (in this case, for the Atari 8-bit port of Super Pac-Man):
On the 400/800 I noticed that people knee-jerked toward using the player-missile ...
if the programmer can guarantee that sprites will never overlap each other, and that they will be presented in numerically increasing order on each scan line.
A hardware designer's response would be "programmers can't actually guarantee that." And they'd be right.
The hardware would have to be designed to do something sensible if those rules were broken. ...
One thing that strikes me about all these sprite systems is that they are unrestricted in what can overlap what; you can have all eight sprites overlapping each other, with parts of background showing through, so that each pixel can come from one of nine different sources, and the hardware guarantees to handle this perfectly.
The majority of earlier games ...
Did historical sprite systems provide unrestricted positioning and overlap
It wasn't unlimited and unrestricted, but limited by chip resources or memory bandwidth - or in case of inbetween systems by both.
because the designers believed this was very valuable in reducing game development cost?
No. Keep in mind, they often crippled machines ...
Supposing you have a fixed pixel output clock then the bottlenecks are:
shifters, since you need to be sure you may need to sample any sprite at the current location; and either:
bandwidth to fill those shifters, if you're a TMS descendant (which includes all 2d Sega consoles) and are fetching sprite contents from regular video RAM; or
storage for what ...
Hardware of this sort has to be able to cope with the worst-case scenario in any given dot-clock cycle. So it has to look at the top layer pixel, determine whether that is transparent, and if so go down to the next layer and repeat. Only when it finds an opaque pixel (which may be the background) can it determine the colour to drive the video output with.
Not answering answering your question, but "black and white" TVs did produce a "better" picture as they didn't have the wire mask behind the glass, which was often very coarse on early TVs and even monitors. You could sometimes/often get a better grey image on a B&W TV than colour on a monitor.
RF encoding introduces significant noise to the video signal because it moves the signal up to an area of the spectrum that is much more susceptible to interference. A monochrome 240p video signal of the best quality will be defined by its dot clock frequency at ~14 MHz. This would create a good quality 80 column text image as seen on machines like IBM CGA ...
According to EBU R95, the title-safe area for 576i format (corresponding to PAL SDTV) is 258 lines tall in each field. This is just large enough to accommodate the 256 lines per field that the BBC Micro uses. This is probably not a coincidence, as the BBC Micro was in part designed so that the BBC itself could use the micro for generating titles and ...
I can answer half of that only: the BBC did often run into trouble, to the point that they cite the *TV command as early as Page 17 of the user guide:
If the picture on your television screen is either too far up or too
far down the screen, you can move the whole display with the command
*TV 255 will move down one line
*TV 254 will move ...
Preface: The whole circuit isn't complicated, but quite involved. I will try to use 'normal' language to make it less hard to read, as mentioning all the signals and interaction would end in an unreadable conglomeration of words.
you'd write an ASCII byte to the output port and that would be displayed in the next position on the display,
On the circuit ...
I would skip the existing output entirely.
Buy a Chroma 81, which plugs into the expansion slot — no internal modifications necessary — and then monitors the internal bus to reproduce
the video stream of its own volition. It has a SCART socket that you can then connect to your TV, modern or retro.
The Chroma's primary purpose is to add colour graphics ...