|
ManxomeBromide posted:That just leaves one question, really: why does this Delay mode even exist in the first place? Holy crap. It's hard to express just what a beautiful bit of computer engineering this is. Let's start with the chip: In 1977 cost was a big deal for microprocessors. Basically, the smaller your chip, the more chips you can fit on one die that comes out of your manufacturing process. Since cost is pretty much set per die, that means smaller chips are cheaper more or less in proportion to how much smaller they are. The 6502 is a 40 pin package, and by cutting down to a 28 pin package on the 6507 they could offer it at a lower price. But, to do that they dropped 3 address pins, and ended up with a sixteenth the addressable memory space. If you looked at that now, the savings vs. lost capability seems insane. The really, truly crazy thing is that it was justifiable in 1977 because ROM chips were so drat expensive that the notion of a game on the home market with more than 4kB of memory was laughably overpriced. By 1980 process improvements had made ROM chips a whole lot cheaper. That means that for most of the Atari's commercial career it used a chip based on functionally obsolete design tradeoffs. That the 1982 Atari 5200 (which did use the 6502) failed is a very interesting story in large part about the 2600. Now, the delay mode is really remarkable from a intended function vs. use standpoint. Registers take up a lot of space and therefore money. The SNES' processor, two generations hence, only had four useable registers vs. the Atari's three. What the next generation did to address this problem (although it also added dedicated sprite related hardware) was something called Direct Memory Addressing that lets the device responsible for making the picture access the RAM directly on a few specific RAM addresses. CPU sends an input signal to the peripheral, it reads the RAM, and you're good to go. But that requires close integration between the display device and the CPU and the NES or 5800 had 2kB of ram vs. the 2600's 128b. A simpler solution to synchronization problems with peripherals is to implement a buffer. Buffers are just parking spaces that let you load information before the associated device can act on it. So you get something like: [CPU]----A---->[ ][ ][ ][Device(not ready)] [CPU]----B---->[ ][ ][A][Device(not ready)] [CPU]----C---->[ ][B][A][Device(not ready)] [CPU]__________[C][B][A][Device(not ready)] [CPU]__________[ ][C][B][Device(ready)] [CPU]__________[ ][ ][C][Device(ready)] [CPU]__________[ ][ ][ ][Device(ready)] The VDEL trick essentially does this for the space of one sprite. It's not really a buffer though because the point of a buffer is to allow asynchronous operation between two devices. What Atari actually did in 1982 with the 5200 is a mix of both strategies (not that weird) that used a separate ASIC that's almost it's own microprocessor (kinda odd). I point this out because the update the display register just at the right time trick (called "racing the beam" in late 70's cool speak) kept the price of the system a lot lower than it might have been. That was a big deal in making the 2600 a success. But the 2600 was built at the end of a period of price assumptions and is very, very limited compared to what was being sold just 5 years later. There's a lot of things Atari did to gently caress up the 5200 for themselves, but the fact that 2600 games kept on coming that looked good and fresh (if not cutting edge) really killed the market. So how awesome is the engineering in this game (and others like it)? So awesome that it ate the next generation in the era of some of the most rapid advances in computer hardware and probably is one of the main causes of the video games crash of 1982. Centurium fucked around with this message at 23:06 on Jul 29, 2016 |
#
¿
Jul 29, 2016 23:04
|
|
|
|
| # ¿ Apr 20, 2024 00:37 |
|
|
^^^^^ A big part of that problem was that Atari failed to launch the 5200 with what we know and groan about today as tech demo launch titles. That combined with a lack of internal discipline to move Atari's own designers to 5200 games and suddenly Atari had a console on shelves that they hadn't provided a compelling reason to develop for. Ouch. And then the market crashed. ManxomeBromide posted:Tech Post 3: The Sweep of History ManxomeBromide posted:
So what's the deal with these instruction sets? Why should you care if they're reduced or not? Well, let's talk about a complex instruction set like x86. They use commands that let you do, in one instruction, the things you regularly want to happen, like add register A to register B and store the result in memory. When we say instruction, this is the mnemonic you see in the debug window that shows lines of code. That's (more or less) human readable and lets you know what's going on (like ADD $1 $2 $3- add register one to register two and store the result in register 3) (this is not a real language). But to the machine, this one for one corresponds to logic high/logic low on its inputs that selects which portions of the CPU to use and what to do with the result. Real x86 instructions can be quite complex but man, why would you want to write out every single stage of every single operation? Well, some smart folks started thinking about this. See, the things a microprocessor does don't all happen in one cycle. Without getting into too much detail, the computer has discrete stages where input signals pass through transistors and become results. Some smart folks in a bunch of places figured out that you could squeeze speed in by loading the first part of the next instruction before the last part of the last instruction finished. But there's a limit to how much extra you can get out of that because the hardware is built to minimize the time complicated instructions take and so you have 'lock out' periods where you absolutely, positively can't load anything else before the current instruction passes a certain stage. Then, those Californians and Subjects of Her Majesty got to thinking- what if you just removed all the instructions that fowled up your cramming? That cramming is called pipelining- and thus we have the Microprocessor without Interlocking Pipeline Stages instruction set. No division- too hard. Just subtract a bunch instead. Each instruction does one thing. Add A to B, or add A to 125 in one cycle. Want to store that in the RAM? Write an instruction for it. What you get is a processor that can get pretty close to taking in and putting out one instruction every clock cycle. So even if you're a bit more verbose in your assembly, your processor is just burning through those lines of assembly code. Interestingly, both are still competing designs (well, ARM and Intel. MIPS is a real thing, but I don't think there's much of note using it any more) but for completely different reasons than in this period. Reduced Instruction Set Computers made a lot of sense if you're taking the Atari approach and trying to cram critical operations into a tiny amount of time like if you have to race the cathode tube beam. Complex Instruction Set Computers can be better (especially in this period) at a really broad range of tasks, especially if you need to do a bunch of high complexity (to the processor) tasks regularly. The Playstation was a sweet spot of RISC being really good at video games. Now, we have so drat many transistors cycling so quickly no one really gives a drat (comparatively). Instead, RISC processors are attractive because the same hardware choices that let them run quickly make them easier to eliminate power draw from. That's why ARM is so dominant in phones and light duty computers (whatever your marketing department wants to call the thing you use to browse the internet and that's it.) CISC computers are likewise killing power consumption quickly, but they continue to go for doing more things over a RISC architecture. How does this relate to our plucky 2600? Think about what ManxomeBromide was showing us with having to wait X clock cycles to read or write to the cache, or to perform a write to the I/O to the TV controller. All the while that cathode tube moves at its predestined rate, deaf to your excuses as your write is tardy. Gosh, wouldn't it be better if you could read/write to the cache faster? That's the fundamental pain that led people to work towards RISC architectures. And now you know. And knowing is half the battle. Centurium fucked around with this message at 05:28 on Aug 1, 2016 |
|
#
¿
Aug 1, 2016 05:23
|
|
|
TooMuchAbstraction posted:As I understand it, basically all CPUs are RISC "under the hood" these days due to the performance benefits it conveys. Intel CISC chips actually do a runtime conversion of each CISC operation into a set of RISC operations -- like having a runtime interpreter for your code, implemented at the chip level! For example, the CISC command "load parameters from these addresses X and Y into registers A and B, calculate their sum, and store that at address Z" could be translated into a sequence of four RISC commands: Sort of. That's an adaptation to a much later model of computing described as superscalar. I'm not sure how to describe that without getting both very technical and very off topic. In the very short version, modern CISC machines break the instructions down and then do multiples of them at the same time on the different components of the microprocessor.
|
|
#
¿
Aug 2, 2016 03:04
|
|
|
ManxomeBromide posted:From the reading I was doing on the chips to make that timeline, it also seems that doing it without that split was common at the time too ("microcode"), but that one of the reasons the 6502 was so efficient was that it didn't use that technique. The 68k did. The 6502 was also said to be "pipelined" but I can't map what they must have meant by that to any notion I learned in my Computer Organization and Design class. The 6502 instruction set is actually pretty RISCy on its own. That's a long winded way of saying what they tell a PhD candidate and what actually gets committed to silicon are naturally going to be hard to rectify. And those same professors definitely think the NES is an example of RISC coding. I think most people ask whether there's the ALU/Immediate+memory instructions in drawing the RISC CISC line. ManxomeBromide posted:The x86, meanwhile, has instructions like rep movsw which: That's what I mean when I talk about what a work of art this programming is on Solaris. The hardware left a huge amount in the hands of the programmer, and the programmer made advances that are unthinkable now. Like, ponder the difference between early and late PS2 games. Big graphics difference, sure. But compared to the difference between Pong and Solaris? It's a testament to the power of human ingenuity. ManxomeBromide posted:The next "real" update should be relatively soon. I got about 20 minutes of captures and converting it into a coherent narrative and introduction of mechanics has been slow going.
|
|
#
¿
Aug 4, 2016 19:54
|
|