Hacker News Reader

Comment by tom_ | Hacker News Reader

It would have been quite a lot more expensive, I assume? Roughly speaking, with 2MHz RAM, and assuming a setup where the CPU and the display system alternate (so 1,000,000 bytes/second bandwidth for each), you have a budget of 40 bytes for the visible part of the line, and large buffers are expensive, so it's just a question of how you spend it. Take the C64 as an example: you've got 320 px mono (40 bytes/line), 160 px 2bpp (40 bytes/line), or 2 40-byte character modes (40 bytes/line). I assume the fetches for the 8 sprites fit in the 24 bytes that are left, as each is 3 bytes wide.

Later machines had more bandwidth and more complicated memory systems, but the limitations are still the same. You have a fixed number of bytes you can fetch from RAM per second, the TV scans out at a certain rate, and that's going to limit what you can do.

View on HN

Arcade games could also more readily use ROM, so tile and sprite data could just flow in parallel to the rendering subsystem -- without worrying about sharing with the CPU or refresh cycles.

That's assuming you're reading all the layers from the same ram. You could increase memory bandwidth by using separate chips for each layer.

Yes, and the C64's colour RAM is a good example, because accesses to it come for free on top of the 64 bytes/line from the main RAM. But more chips is exactly the sort of thing that would make it more expensive. And I assume it would also have been more complex to build, or something - because if it were cheap and easy, surely people would have done it?

Memory usually accounted for a majority of the cost in those days, so there's a lot to be said for a unified memory system in home computers. The standard memory architecture for home computers from 8-bits like C64 to 16-bits like Amiga was unified memory with half the memory cycles each going to the CPU and graphics, and PCM playback on later systems could conveniently steal a few graphics memory cycles during hblank. (The C64's VIC-II also stole CPU memory cycles every 8 scanlines and could be forced into stealing a lot more bandwidth with the 'badlines' technique.) ROM-based arcade machines and consoles generally had memory parallelism for their graphics systems. It puts heavy pressure on the chip pin-out and it requires you to physically allocate the RAM/ROM chips onto different buses. I guess theoretically you could put all the memory chips on multiple buses with a configurable arbiter in front of each so you could change the allocation per application, but the PCB for that would be massive and expensive. Instead there was usually a slow, awkward way to access memory from a different bus, e.g. the graphics bus could be accessed by the CPU only with DMA or a pair of memory-mapped addr/data registers with multi-cycle wait states. So, this kind of architecture isn't really suitable for a general-purpose home computer unless you can afford a large allowance of memory for each bus, but it did exist on high-end home computers like the X68000 that were less cost constrained. Also, Amiga did have the option for a kind of RAM expansion called Fast RAM which was only accessible to the CPU, unlike normal Chip RAM which was accessible on the standard chipset bus to the audio and graphics chips in addition to the CPU. Fast RAM didn't speed up the graphics system but it prevented the CPU from stalling when the other chips wanted to steal CPU memory cycles on the chipset bus (they always take precedence since they have hard real-time constraints).

64 bytes per scan line X 200 scan lines = 12,800 bytes.

1,000,000 / 12,800 = 78.125

i.e. frame rate = 78 frames per second could be updated with that speed.

I am sure 78 frames per second are not really desirable, so the resolution could actually be doubled per scan line:

128 bytes per scan line X 200 scan lines = 25,600

1,000,000 / 25,600 = 39 frames per second.

Reply on news.ycombinator.com