Secret colours of the Commodore 64

So there is a potentiometer on the c64’s board that you can adjust to control the color intensity. The people on the assembly line them were supposed to connect them to a screen and adjust the pot until it matched a particular intensity, but there were runs of c64s where they just said "fuck that" and turned it all the way up without checking. Early 64s were SUPER saturated.

The fact that we are having a conversation about it looking dull and washed out makes it clear that this unauthorized shortcut was cracked down upon. But it also helps to explain why there are so many palettes available in most c64 emulators - people tried to match their memories, or a screen grab, of wherever their particular c64 was adjusted.

I'd adjusted mine; if I recall correctly it came with the intensity all the way up. I turned it down but didn't turn it down to the point most people's seem to have been set at, judging from most modern emulated screenshots.

Synchronous clocks do this too... they've driven by a motor that's designed to work in phase with the electrical grid's frequency. This means they rotate at a fixed speed and can be used as a time base for a clock.

From the perspective of the grid operator, however, 50 or 60Hz is not always 50 or 60Hz. A sudden load or a generator tripping offline (to preserve itself) results in a transient slowdown of the frequency of the entire grid. I spent a summer in high school helping out with the analysis of these kinds of disturbances, and there's a distinct pattern to the fluctuation of grid frequency. There are also slight longer term errors in grid frequency, although operators are held to strict standards.

Getting back to clocks, integrating these transient frequency errors over time results in clocks that shift forward and backward relative to real time. This integrated time error is often displayed in grid control rooms, and it is something they deliberately manage to ensure that the 'grid time' is accurate. In practical terms, this means a period of ever so slightly less than nominal frequency is likely to be followed by a period of deliberately induced slightly higher than normal frequency, so that the overall integrated error tends to zero.

More details on the time control aspect on page 13 here: http://www.nerc.com/docs/oc/rs/NERC%20Balancing%20and%20Freq...

Well, alternate fields have a 0.5 scanline offset, so that's sort of true. But you definitely don't see them both at once. Are you sure you've ever used a proper CRT TV? ;) - you can get the alternating effect with LCD TVs, but that's because LCD TVs handle analogue input in a different way.

Justifications for this:

0. TV hblank rate is 15,625Hz - at 50 fields/sec, that's 312.5 lines/field, some way short of the 400 you'd need to display 2 fields

1. Out of the 312.5 lines/field, only 288 are booked for the visible area, and most TVs can barely resolve them precisely anyway

2. When the TV is displaying one field in one set of scanlines, and the previous in the other, where does the data for the previous field come from?

2.1. TVs of the period have no buffer

2.2. Computers of the period don't generally have the RAM (or sometimes the hardware) to double buffer

2.3. The image produced is based on more than just the contents of the RAM anyway, increasing the RAM requirements (if you were to try to do this)

2.3. Cheap DRAM of the period doesn't have the bandwidth to scan out two frames'-worth at once)

Here's a pic of my BBC Micro, with interlaced output, running a program that flashes the screen alternating red and white: http://i.imgur.com/1XvkRso.jpg - you can see that at the top it's scanning out an entirely white frame, and at the bottom there's the end of the previous entirely red frame that's in the process of decaying.

As an example of 2.3 - note that the difference between one frame and the next here is entirely the video registers - the RAM stays exactly the same. Only one of the palette registers changes (and the flashing cursor is added by the hardware as a sort of post process step).

(I suspect the red/green/blue blur at the bottom of the white region is an artefact of my phone's terrible camera. Photos from my (slightly) better camera don't have that, but they do look overall the same. However today only my phone is willing to play ball with my PC.)

Ah, so a trade-off as always.

I wonder if the demoscene has some nice examples where they are more perfectionist about this.

I previously worked with Unix sysadmin tasks and software development at Statnett SF [1], the transmission system operator (TSO) for the national level of the Norwegian electrical power distribution network, and am currently studying at the university to become an electrical engineer. We started learning about transformers, generators and motors in three-phase systems this semester, so that document is of interest to me. I looked over the document briefly and intend to read it in full later, for example tomorrow when I will be going on a two hour train trip to Oslo.

The electricity sector in Norway relies predominantly on hydroelectricity. In 2008, hydroelectricity generated 141 terawatt-hours (TWh) and accounted for 98.5% of the national electricity demand. [2]

I have been told that the nature of hydroelectric power generator installations makes the act of balancing the power system in Norway quite different from what most other countries are dealing with but I think the document you linked will be informative to me none-the-less. Besides, understanding power systems balancing in general and not just for Norway would allow me to work in other countries in the future should I want to. Not saying that the university is going to teach me things that apply to Norway only of course but I hope that you understand what I mean.

PS: Statnett has a live view of the Nordic power balance on their website -- http://statnett.no/en/Market-and-operations/

[1]: http://statnett.no/en/About-Statnett/

[2]: https://en.wikipedia.org/wiki/Electricity_sector_in_Norway