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.
I nominate the AY-3-8912, which is a sound generator that also has eight programmable input/output pins — set them as input or output, set or get their level — in a 28-pin package. It sits between the 8910 (16 IO lines, 40-pin package) and the 8913 (no IO, just the audio, 24-pin package).
Of course. After all, the number of pins is related to the task at hand. No manufacturer would choose a package with more pins than necessary.
Examples of main families are:
(Excluding support chips, like priority encoder, status decoder or bus drivers)
Motorola 6800 family
MC6840 - PTM - Programmable Timer (28 pin)
MC6850 - ACIA - Asynchronous ...
Probably because it was the only way to get 100% compatibility with the old software library, which was required while most PS2 titles weren't developped yet. Noone wants to buy a machine without games, and noone wants to upgrade and lose the ability to play old games.
Note like console makers have a "all or nothing" way of handling the compability. For ...
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 quite ...
What "prevents" it is the same thing that prevents graphics cards on modern PCs from running independently: there's simply no benefit to adding what would be needed to make them independent computers, and doing so what compromise the job that they're designed for.
The Cell Broadband Engine consists of one or more Power PC cores (Power Processor Elements or ...
But it's not a ROM; [...] it's actually a PLA
Then again, a ROM and a PLA is essentially the same technology. What differs here is not only the decoding, but that in case of the 6502 only the decoding part is present and it's not monotone.
Such compression is obviously useful. Die space is expensive
True. But it's worth to note that the cited answer says &...
Yes. Speed must be 150ns or faster, technology should be NMOS (CMOS produces too sharp edges that may cause ringing, due to non equalized traces in the PCB, so they may or may not work) and must support 7 bit (128 rows) refresh mode.
Not that I know.
Which are the "standard factory modifications"? The only one I know of is that weird capacitor connected to ...
The initial versions of the CPU and GPU above were over 200 mm², which is quite large. Conjecture: making them initially a single chip would have resulted in substantially diminished yield.
Being already at the upper end what can be done
A Pentium III (Coppermine) of that time had about 10M transistors and ~100 mm², so a die with more than 200 mm² was most ...
what exactly stops them being fully autonomous?
Nothing - except for the way any tight coupled multicore CPU starts up. After reset only the primary core starts executing code, while the rest is kept in a hold state, until prepared and released by the primary core. Further any control about the configuration can (usually) only be exerted by the primary core....
Two interconnected moments in history with the popularity of microcode in microprocessors need to be distinguished:
Firstly, the ratio of price, volume and speed of various types of memory;
Secondly, the ratio of manual labor and the development of automation, including the theory of compilers.
The heyday of the microcode came at a time when the means for ...
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. ...
Not a book, but the Computer History Museum has videos in their online collection of the oral histories given by many people associated with the development of many early silicon IC (and earlier!) products.
The IEEE history center also has some great online resources:
Slightly bananas answer: MC68000.
Okay, I know, it's not a graphics chip. But, you can take some inspiration from the Xerox Alto, which would presumably have been a somewhat familiar source of inspiration to somebody working in graphical workstations in 1980. Since the Alto didn't have access to a modern off the shelf RAMDAC for displaying the contents ...
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 ...
For those interested in the hands-on use of microcode, including how to implement a CPU (1802 - which was NOT microcoded, but a FSM control unit) and a display controller, I developed a compiler that generates the [horizontal] microcode and instruction mapper memory. https://hackaday.io/project/172073-microcoding-for-fpgas
As I understand it, later chips like the 8086 and 68000 use microcode
of the conventional ROM variety.
This is simply not true. 68000 CPU used a combination of PLA-driven decoding and ROM-driven microcode engine. Look https://dl.acm.org/doi/10.1145/1014198.804299 for reference (remember that there is Sci-Hub at your service if you know DOI: https://sci-hub....
All chips will eventually fail due to age if something else doesn't get them first. The bathtub curve reflects this and shows how burn-in improves reliability by weeding out early failures.
Eliminating #3 ("only because of out-of-spec treatment"), the question becomes, what percent of chips die because of age and what percent die because of usage? I think ...
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 hardware ...
Intel very likely did this with surplus batches of ROM-equipped microcontrollers - eg if you look closely at the pinout of the 8031 vs 8051/8751, an 8051 wired up like an 8031 WILL behave as an 8031 no matter what is in the ROM/EPROM.
I am not sure if any modern EEPROM programmer could do it. PROMs are too outdated nowadays. Better look for an older EPROM programmer. PROMs and EPROMs have similar programming process, using the high voltage (+12 V in the most usual cases), so it could, maybe, know how to program a PROM.
But my personal opinion: the best way is to find a datasheet, look ...
I checked the device support list for my Dataman S4, but it doesn't go all the way back to 4Kbit (512x8) devices. The S4 isn't quite a universal programmer, as it can only supply power and Vpp on certain pins of its socket, and so on, but it would be more likely to support relatively old devices than a new unit.
I wasn't even able to find a datasheet for ...
You can create such a device yourself. If you know how to program the 556PT5, you might end up with creating a simple dedicated programmer circuit. Then you can drive your programmer circuit using аrduinо, rаspbеrrу рi or anything alike.
I'd hypothesize that the most frequent reason for old plastic-cased chips to fail is the plastic package itself. Inevitably there is a strain or pressure from the filling plastic to the crystal itself or to the bonding wires. After a long time, plastic might absorb water and the tension would change, or it might eventually get a small crack inside, or simply ...
Yes, the PlayStation 1 CPU had a 32-bit data bus, and RAM was always
32 bits wide, spread over one or more chips.
However, there were at least three major revisions of the Playstation
1 hardware and more than half a dozen different mainboards spread
across a lot of different models.
Information on the earlier models is hard to find. The GameSX wiki
One possible reason could be the production discard:
Let's assume 1 of 1000 CPUs produced is defective and the same is the case for the GPUs.
Then 1000 of one million ICs are defective when producing the ICs separately.
If you place the CPU and the GPU on the same IC, there are:
One IC in one million that have both a defective CPU and a defective GPU
To develop two parts separately is much easier than to develop one big IC. You can use two less or more independent teams. The developing cycle is cheaper and faster with smaller chips.
Once the designs are settled, you can start to manufacture prototypes or the first series, and the "integration process" can run in the background.
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 ...
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 ...