Tuesday, 14 July 2020

Toggle Booting a PIC MCU!

Before the 1970s people had to boot computers by laboriously flipping a set of toggle switches on the front of the main processor. Today, all computers have built-in boot ROMs and even embedded microcontrollers are programmed using powerful external computers.

I only consider a processor to be computer if it can support self-hosted programming, so I wondered what it would take to manually toggle in a program on an MCU with no computer and minimal logic. I've produced a video based on this blog here.



I chose a primitive 8-bit PIC, because it has a simple programming algorithm, but even so, I have to enter 56 bits per instruction flashed. It was so tedious I printed out the entire sequence and used a ruler to make sure I didn't lose my position. Here's the 11-instruction program itself:

 0 Bsf Status,5 ;01 0110 1000 0011
 1 Bcf Trisc,4  ;01 0010 0000 0111
 2 Bcf Status,5 ;01 0010 1000 0011
 3 Movlw 53     ;11 0000 0011 0101
 4 Movwf T1con  ;00 0000 1001 0000 65536 cycles at 8us/cycle=
 5 Btfss Pir1,0 ;01 1100 0000 1100 3.8s per full blink.
 6 Goto 5       ;10 1000 0000 0101
 7 Movlw 16     ;11 0000 0001 0000
 8 Xorwf PortC,f;00 0110 1000 0111 (Don't care about RMW issues)
 9 Bcf Pir1,0   ;01 0000 0000 1100
10 Goto 5       ;10 1000 0000 0101

You don't need a GOTO start at address 0: if you don't have any interrupt code you can just start your program at address 0.

The reason why it's so tedious is that programming each instruction involves four command sequences:

  1. Load the instruction into (I presume) an internal buffer.
  2. Burn the instruction into flash memory.
  3. Verify the flash memory instruction you've just programmed (always worthwhile as it's so easy to make a mistake).
  4. Increment the address of the PC. Unlike many MCU flash programming algorithms, the 8-bit PICs can only have their programming address reset (by unpowering the MCU, connecting the PIC's /MCLR signal to 12V, then powering the rest of the MCU at 5V) and then incremented. Thus making a mistake (most likely because you've left out a bit or duplicated one) means you have to start again.

In addition, each programming command expects all the data to be entered from the LSB to the MSB, so in fact I toggled in all the commands backwards, reading each line from right to left. So, the first full command really looked as follows (with '|' separating individual fields):

Bsf Status,5 |0|01 0110 1000 0011|0|000010 Bit 5 is RP0, status is 3
  (Prog)     |                     |001000 Bsf is 01 01bb bfff ffff.
  (ReadBack) |0|-- ---- ---- ----|0|000100
  (Inc)      |                     |000110

The PIC needs just two signals to program it: a clock input and data signal. My hardware is (relatively speaking) super simple.

I use an astoundingly primitive 555 timer chip in its monostable (one shot) mode to debounce the clock. All I needed was a couple of capacitors and resistors to give a 0.2s delay and it would eliminate bounce. All the information I needed came from the wikipedia page on the 555 timer.

The data button was a bit more challenging. I used a few resistors and a red LED as I needed Vdd when I pressed the button, less than 0.8V when I let go, but I also needed to enable the DAT line to drive the LED when verifying data and not exceed current limits even if I accidentally pressed the button when the DAT was trying to output. One of the downsides to this approach is that the LED is barely visible on the video, though in retrospect I think I could have halved the resistor values and it would have been fine.

Finally, I needed a 12V programming voltage for the PIC, and then used a basic 7805 voltage regulator to generate the 5V Vdd voltage for the 555 and PIC. The currents are so small I didn't need to worry about a heatsink for the 7805.

On a PIC it's not good enough just to program the flash, I needed to change the internal configuration to stop the Watchdog from resetting the PIC after 4ms and to use the internal oscillator instead of an external RC oscillator. The spec on programming the configuration is rather confusing, because the sequence to go into config mode requires the full 14-bit configuration setting, and then you have to enter it again as a normal programming instruction.

With some experimentation I got it right in the end! With a bit more detail, I started off by finding out how I could enter one instruction (after running the erase command), and then two instructions. I made two attempts to program the entire program - in the first attempt I made a mistake on the last-but-one instruction and had to start again, I videoed both of them so although the toggling sequence is complete and not spliced from multiple attempts, it wasn't the first attempt.

I had a similar problem with the configuration. It took a few attempts at that to get it right and at one point I thought I had configured it to use an external oscillator and couldn't read the flash anymore. In fact I had mis-inserted the VPP to the right of the 7805's IN pin.

So, it's possible, but not very practical to manually toggle program an MCU, but perhaps survivalist geeks might find it useful in some post-apocolyptic dystopia!

Saturday, 14 March 2020

COVID-19 Herd Immunity Sim

Why Herd Immunity Doesn't work for Covid-19

This is a simulation of the epidemic for the sake of working out how much herd immunity is needed to protect the population.
The answer is around 90+% (98% in this sim). Herd immunity is mistaken.

Explanation

Herd immunity is designed for vaccines.
In normal epidemics, herd immunity works because the contagion distance between someone who contracts the disease and the next person who isn’t immune is large due to the number of people already immune (depending on the % immunity and infection rate). But here, no one has immunity, so the disease would distribute itself throughout the population and the contagion distance remains small even after nearly everyone has become immune. So in this case, herd immunity is incorrect, despite what you may have heard from our PM saying he’s followed the advice of the chief scientist.

How To Use

The easiest way is simply to press the StartSim button. It simulates a population of 160,000 where each person potentially infects 0.8 people in their vicinity each day until they get isolated (in the example in day 5). The default vicinity is 256 (+/-16 in each direction) and if by chance an infected person tries to infect an already infected person, it has no effect.

You can see in realtime how an infection spreads across the population. Initially it appears to be exponential, but fairly quickly isolation cuts in and people who have it tend to come into contact with those who already have it, so they don't infect so many new people.
So, the epidemic then spreads at the boundary.
As it does so, some people - a few - remain uninfected, by chance and as the disease progresses at the boundary, the mass of people now immune effective protect the very few who have never been infected. But this is a very low figure, because the whole population has no prior immunity and is not vaccinated.

You can play around with the infection rate (<=1) and mobility to simulate a ghastly pandemic that seems to spring from everywhere all at once, but ultimately it has little effect on the herd immunity as it effectively doesn't exist.

Remember, this is only a simulation to demonstrate the lack of herd immunity. It does not really project actual figures for infection, nor are the rates correct, nor the population, nor the mobility, nor the potential impact of warmer weather on the virus.

Simulation

Pop: Contagion/day:
Isolate on day: Mobility:

Your browser does not support the HTML5 canvas tag.

Monday, 30 December 2019

Monopoly Sim



Our family plays Monopoly every Boxing Day and the winner gets to keep our Monopoly trophy for a year with their name inscribed on a new lolly stick. I've never won, I should do something about that!

I wanted to simulate the game of monopoly to find out which locations are most likely. The distribution won't be even because GO TO Jail takes you back to Jail (or Just visiting Jail once you pay or throw a double to get out) and some of the other cards take you to different locations on the board (Go, Pall Mall, Marlebone station, Trafalgar Square or Mayfair.

Naturally, it's not good enough just to simulate the game, the quest is whether it's possible to do that on a 1K ZX81. We can do that by some analysis on what really counts for the simulation.

Firstly, obviously, to find out which locations are most popular, we don't need to draw a simulation of the board, simply listing the popularity of each location as a series of numbers will do. On a ZX81 we'd need to count the memory used by the screen for this. Assuming each location could have a popularity up to 255, then we need 4 locations per location: 160 bytes in total.


Secondly, we don't need to store the names of the properties; the value of the properties or rents since if we simply know the popularities, we can calculate the income we'd get from that and the card values.

Thirdly, we don't need to maintain any money, because we only care about popularity; this means we don't need to simulate the bank or money for passing GO and we don't need to simulate chance and community chest cards that involve money. So, the only cards that matter are those that take you to a new location.

Fourthly, we can note that there are only 2 Community Chest cards that don't involve money, a goto GO and goto Jail, which are also part of the Chance cards, so we can re-use two of the chance cards to simulate Community Chest.

Fifthly, we can assume that a play will get out of jail immediately by paying or by having a card - it makes little difference to distributions (though we could simulate runs where the play prefers to get out of jail using a double, this means they'd only move

This means the simulation is pretty simple:

  • We need an array of 40 locations to hold popularities.
  • We need to simulate two dice for moving parts: the sum of two random numbers 1..6.
  • We need to redirect the locations if we land on one of the 3 Chance or 3 Community Chest locations or Goto Jail.
  • The redirect locations are: 0 (GO), 10 (Jail), 11 (Pall Mall), 15 (Marlebone stations), 24 (Trafalgar Square), 39 (Mayfair) or back 3 spaces, but Community Chest is limited to the first two.
  • We could calculate going to jail if the last 3 rolls are matching pairs and this would mean an extra jail visit every 1/216 throws on average. Getting out of jail by throwing a matching pair wouldn't affect results because the throw only puts the player into the 'just visiting' location and thus doesn't affect where they land after leaving jail.
  • Periodically we should display the current popularities.
With all these rules apart from the even dice jail rule and using the normal ZX81 Basic space-saving rules we can squeeze the code into 1Kb.


Line numbers take up 21*5 = 105b. The main code takes up another 305b. M$ takes about 45 bytes variables take up about 6*4 = 24 bytes. The screen takes 160 bytes, making a total of 639 bytes, which is within the limit of a 1K ZX81.

Results

It's just a list of numbers representing the popularity of every location from GO to Mayfair:

The ZX81 is really slow when run in SLOW mode, taking 0.6 seconds per go, or about 84 seconds per round including the printing. About 4,000 runs were taken which took nearly an hour. We could speed this up by running in fast mode; removing lines 25 and replacing line 130 with GOTO 30. Then it would take 0.15s per run, so 4000 runs will take 10 minutes.

What the results mean:

Site Pop Site Pop
Old Kent 32 Whitechapel 41
King's Cross 29 Angel 40
Euston 43 Pentonville 36
Pall Mall 46 Electric 41
Whitehall 35 Northumberland 40
Marlebone 40 Bow St 47
Marlborough 51 Vine St 44
Strand 47 Fleet St 52
Trafalgar 58 Fenchurch 43
Leicester 44 Coventry 40
Water 47 Piccadilly 49
Regent 46 Oxford 39
Bond 32 Liverpool 45
Park Lane 29 Mayfair 51

In this run there were 4173 throws, so there would have been 19 extra go to jail's due to three successive pairs (boosting Electric to Strand by about 7%).

We can see that the four most popular places are Trafalgar, Fleet St, Marlborough and Mayfair and at the other end of the scale, Park Lane, King's cross, Old Kent Road, and Bond Street are significantly less likely. It's understandable that Marlborough would be likely, but I would have thought Bow Street would have been equally likely (both 5/36 probability), but Trafalgar was unexpected - except that it's an actual card destination. We know that Chance was hit (47+70+54 = 171) times without the player being redirected (11/16), so in total it was hit 248 times and therefore 15 of these involved jumps to Trafalgar (lowering the hit rate to 52). A similar number of hits redirected to Mayfair (51-15 = 45 still leaving it more popular than Park Lane).

The sample size is about 4173 across 40 locations, about 104 hits per location, so the variance will be fairly significant. Therefore I haven't deduced too many details from the results.

Conclusions

The main conclusion is this: it's perfectly possible to solve an interesting question by simulation on an old computer with minimal memory. Even on a 1Kb ZX81 there was spare space. It's worth considering what the minimal computing resources are to solve the same problem. It's certainly under 1Kb, so a basic Jupiter Ace or a 1Kb MSP430 should easily be possible along with a PIC16F54 or even maybe an ancient 1802-based ELF computer with the standard 256b of RAM.

Saturday, 3 August 2019

Danger! Danger! Devaluation!

Right now, Brexiters keep claiming that devaluation is good for the economy. They're almost certainly wrong.

Intuitively, a fall in the pound is a bad thing: anything we buy from overseas goes up in price and since a high proportion of what we buy comes from overseas, our cost of living will go up.

But then Brexiters jump in and say "Devaluation is great, because it means more exports and that will make the economy grow." As a general rule, because Brexiters often distort the truth, you should be skeptical. So, are they wrong here too?

It's a good question. Recently I was at my Dad's house and we were watching a TV show called "Factory Wars" on the Yesterday channel. I was surprised to find a bloke from The Institute of Economic Affairs. Why was an economist from a lobbying organisation with secretive funding (hint, Big tobacco and the climate denying US groups like the Heartland Institute) on a history show?

Basically he was using it to push free market ideology. He claimed that the UK escaped the recession in the 1930s because it implemented austerity unlike the US which implemented a Keynesian New Deal. This was completely different to how I'd understood these economies in the 1930s: on the basis that austerity empirically doesn't work; its easy to explain why, and it was the Keynesian New Deal that empowered the US to manufacture the armaments that helped the allies overcome the Nazis.

It's not coincidence that the IEA offered a completely different explanation than what is normally understood: they're based at 55, Tufton Street where Vote Leave was also based. So, again we have another ideologue whose views we should suspect.

So, I checked out what really happened in the UK's economy in the 1930s? Economics Help is really useful. Basically, the crash of 1929 caused a lot of hardship in the UK, but in the mid to late 1930s we dropped the gold standard; which lead to a deflation of the pound and this lead to a mild economic recovery in the south, but the North still had it tough.

So, it looks like Brexiters might be a bit right, and the IEA were misleading as normal. But is it?

Devaluation Model

Actually we can work this out ourselves, because it's easy to model. In our model (for a business, but it can apply at a larger scale) we consider just three variables:

  1. Profits
  2. Internal costs (labour minus rises in the cost of living due to buying overseas goods, maintenance of equipment etc). We assume this is a constant.
  3. Imports (including the increases in the cost of living for employees from overseas goods).

Case A

In the first scenario, we consider a company with reasonably high import costs (50%), a profit margin of 30% and the rest is internal costs (20%). If the pound deflates by 25%, then imports go up to 50*1.25 = 62.5%. So, now our profits are 30-12.5 = 17.5% profits. This means that the company needs to sell 30/17.5 = 71% more goods, but the domestic market will buy less, and the overseas market will only find its products are 25% cheaper (due to devaluation).

So, the question is: is it like overseas customers will buy 71% more, if it's 25% cheaper? This seems unlikely to me.

Case B

Let's consider the second case: profits are 70%, internal costs 20% and imports are 10%. Imports increase by 25% => 12.5%, so we now need to sell: 70/(70-2.5) = 3.7% more. OK, so in this case our product is 25% cheaper, and we only need to sell 3.7% more for us to make more profit, this seems plausible.

So, we have to ask ourselves, what kinds of businesses are like this? Mass market manufacturing (cars, aircraft, smoke alarms) will rely a lot on imports and will make a relatively small profit. Apple, for example has margins between 20% to 30%. Dyson is also about 21%. DELL has an operating profit of just 1.1%. Companies producing consumer items such as smoke alarms have fairly low margins which explains why they would move to cheaper EU countries.

What companies are like case B? Services and financial companies are like that. However, financial companies are likely to move out of the UK due to Brexit, so this means service companies would benefit.

However, to some people, UK manufacturing companies can look good: namely, if you hold a lot of offshore wealth, then UK manufacturing companies struggling under devaluation look like a good buy. In other words, disaster capitalists with offshore accounts, such as people like Jacob Rees Mogg and a large proportion of Conservative party members and MPs.

Epilogue

Brexiters are wrong: it's just a front for their disaster capitalist mission. We can summarise our model and convey why in a simple table:



So, why did the UK not crash due to a double-whammy of austerity and devaluation in the 1930s? That's pretty simple, being the biggest power bloc at the time meant that although most of its food (91%?) was imported along with a significant proportion of goods, a great deal of this was essentially an internal market, with the added advantage that many resources, particularly coal were internal.

Saturday, 6 July 2019

Let the EVs Take the Strain

A recent BBC article says EVs won't solve congestion problems. It's yet another negative headline about EVs to follow from yesterday's negative EV headline where they said EVs were falling in sales for the first month in whatever (when in fact BEV sales had gone up 67%). They even go to the trouble of showing a picture of a rare EV, an 8 year old early prototype Smart ED TwoFour, rather than - say EVs hundreds of times more popular, to get across the idea that EVs are toys. Next week, watch out for the Tesla-bashing article ;-) and no mention of how sales of real EVs in the EU, the US and globally are rocketing.

Similarly, this article uses a bit of truth to hide a bigger lie. In fact EVs will go quite a long way to solving congestion.

Car Use is Falling

Car use is already going down in some parts of the UK, mostly because in London, they're not needed much and elsewhere because insurance for young drivers is prohibitive.
But actually, the nature of EVs will themselves radically change our vehicle usage, primarily because they have so few moving parts and batteries last much longer than originally expected (and will get several times better), to get sufficient wear and tear we're going to have to drive them much more often.

ICE Drives Congestion

The problems we see with urban vehicles are problems relating to ICEs themselves. For example, you can't have a filling station at everyone's house - it's far too dangerous and far too expensive! ICEs force us to place filling stations as widely as can be tolerated and because the effort taken to fill up (compared with plugging in an EV); this in turn forces infrequent filling; large tanks and very long ranges.

But long ranges themselves have the side effect of increasing our journey lengths which impacts everything: distance travelled to shop, to our workplaces, to schools and hospitals and all this increases traffic.

EV Transformations Will Blow Our Minds

EVs will change this radically. We'll have to share cars to get the wear and tear out of them and because charging will become ubiquitous (think every forecourt where your car might hang around); we'll need cars with much shorter ranges on average than even the first generation of EVs: think 10KWh or even 5KWh for the majority of cars and in turn two person EVs will dominate for the vast majority of journeys. But in turn, because we can charge easily, we can expect journeys to shorten too.

Remember in this model, people don't own their cars as much.

Why will people choose tiny, 'under-capacity' cars? It's simple, they'll be much cheaper to build, sell and drive! My Zoe (22KWh) gets about 4 to 4.5 miles per KWh at maybe 12p/KWh. Given a gallon of petrol (4.5L) = 4.5*£1.25 = £5.63, I get 5.63/0.12*4.5 up to 210mpg running costs.

But a Renault Twizy (a 2 person EV with a 6.7KWh battery) will get 6 to 8 miles per KWh, equivalent to 300 to 400mpg running costs.

Given a typical day's travelling in the UK is only about 10 to 20 miles, about 3KWh, that's only half a Twizy's battery. And considering the sheer number of charging points there will be, the average needed journey between charges will only be 5 to 10 miles, just 1.5KWh.

On that basis, a future EV with a 5KWh will seem ample, even though right now, all the talk is about 50KWh to 100KWh batteries.

So, EVs will go a long way to reduce congestion in themselves owing to the different driving model.

Friday, 12 April 2019

Plottastic ZX80!

A guide to plotting pixels in Basic on a ZX80!


Introduction

Both the ZX80 and ZX81 support 8x8 pixel character-only displays and contain 16 graphic characters that can be used to plot fat 4x4 pixel pixels on a two-by-two grid within each character:

These are called Battenberg graphics after the cake of the same name 😀

On a ZX81 it's easy to use these characters to plot (crude) graphics on the screen, the computer provides a PLOT x,y and UNPLOT x,y for this purpose. But with half the ROM on a ZX80, it's much harder - so I wondered, how much harder is it to plot pixels? It turns out it's pretty formidable!

Challenges


  • The ZX80 doesn't have any PLOT or UNPLOT commands.
  • The screen on a ZX80 is like that on a ZX81, when you run a program, the screen first collapses to a minimum of 25 newline characters and expands as you display text. However, on a ZX80, unlike the ZX81, you can't print anywhere on the screen as there's no PRINT AT function, this means we'll have to poke onto the screen.
  • The memory map on a ZX81 has the display immediately after the program, but on a ZX80, the display comes after the variables and the editing workspace which means that it'll move around just by creating a new variable or possibly by performing input (which is a potential problem).
  • Ideally, to convert from pixel coordinates to Battenberg graphics you'd want to map the odd and even x and y coordinates to successive bit positions to index the character.


  • But, unlike the ZX81, the character set on a ZX80 doesn't have the characters in the right order to display Battenberg characters. Instead they contain gaps; the last 8 codes are generated from the first 8 but in reverse order; and some of the first 8 are taken from what ought to be the inverse characters!

The Solution

The solution really comes in a few parts. Firstly, the easiest way to be able to map an ideal pixel value to its Battenberg character is to create a table in RAM, by putting them into a REM statement (the ZX80 has no READ and DATA commands so it's hard to put a table of data into an array, but the first REM statement in a program is at a fixed location). However, even this presents a problem, because only 8 of the graphics characters can be typed. The easiest way to handle that is to write a program which converts a different representation of the characters into the correct ones.

So, on the ZX80, first type this:
After you run it, you'll get this:
Even this was tricky; I had to use character codes above 32, since symbols such as +, -, /, ", etc get translated into keyword codes for the Basic interpreter. The above program illustrates an interesting feature of ZX80 Basic that differs from ZX81 and ZX Spectrum Basic in that AND and OR operations are actually bitwise operations rather than short-circuit boolean operations. Thus P AND 15 masks in only the bottom 4 bits.

Once we have generated the symbols we can delete lines 10 to 30.

The next step is to actually write the code to generate pixels and plot them. Once we know how, it's actually a bit simpler. Firstly, we fill out the screen with spaces (or in my case, with '.'):
This gives us 20, full lines of characters. Because it's going to be difficult to plot a pixel by reading the screen, figuring out the plotted pixels then incorporating the new pixel; I cache a single character in the variable P and its location in the variable L. All my variables a single letters to save space if you try to run it on a 1Kb ZX80. The idea is that if the new print location in L changes, we reset P back to 0, otherwise we incorporate the new pixel.

Next we start the loop and calculations for plotting, in this case a parabola. We loop X=0 to 63 and calculate Y on each loop (it's a parabola that starts at the bottom of the screen):

Finally we perform the pixel plotting and loop round.

This involves saving the previous location in K so we can compare it later; then calculating the new location based on X and Y (since each character position is 2 pixels, we need to divide X and Y by 2 and since there are 32 visible characters and an invisible NEWLINE character on every screen line we must multiply Y/2 by 33). Note, a quirk of ZX80 Basic means that multiplies happen before divides, so Y/2*33 would calculate Y/66!

The pixel bit calculation in line 50 makes use of ZX80 bitwise operators, we want to generate 1 if X=0 (so 1+(X AND 1) will generate either 1 or 2) and then we need to multiply that by the effect of the Y coordinate, which is 1 on the top line, and 4 on the bottom: 1+(Y AND 1)*3 will do that. Hence this will generate the values 1, 2, 4, 8 depending on bit 0 of X, Y.

We must POKE the location L plus an offset of 1 (because the first character of the display is a NEWLINE) and also we must add the location of the display file (it turns out that these calculations don't make the display file move around). We poke it with the pixel value we want indexed into the right character code from the REM statement. Finally we loop round X.

This code generates this graph:
It looks reasonable even though it's generated with integer arithmetic. It's the first pixel plotted graph I've ever seen on a ZX80!

More Examples

My original reason for doing this was to see if I could generate sine waves using a simple method I once found for a Jupiter Ace. Here's the program and the result:
It looks fairly convincing, especially as it's all done with integer arithmetic. Because the code generates both the sine and cosine value, it's easy to turn this into a circle drawing program which produces the following:

It looks a bit odd, that's because the algorithm doesn't quite generate sine and cosine curves. What it's really doing is computing a rotation matrix, but only one of the terms is computed for sine and cosine each time. Hence, the circle looks a bit like an oval with a slight eccentricity.

My graph drawing algorithm has one very serious limitation. Because it doesn't read the screen in order to compute a new pixel, if the graph goes over the same part of the screen twice, the second pass will muck up what was there before. Doing the correct calculations is possible using some table lookups and bitwise operations, though it would slow down the graph generation. I didn't bother, because I only wanted to generate simple graphs.

Conclusion

The ZX80 and ZX81 have very similar hardware, but a number of design decisions in the ZX80's firmware made drawing circles much harder than you might expect. With a lot of effort it is possible to generate some simple graphs 😀

Saturday, 3 November 2018

The Gift of Sisyphus

George Monbiot always writes great articles on sustainability (and although this one is 6 years old it holds up well). Here, what George Monbiot is saying is that (as well as the abusive consequences of extractivism) about 50% of CO2 production is due to this kind of consumerism.

However, I would argue that the priority for everyone is simply to stop using fossil fuels asap. Imagine the same argument if we already had 100% clean energy: Monbiot would be saying that this pointless conumerism causes 0% of CO2 production. So, it would still be pointless, extractivist, and abusive, but it won't fundamentally be raising global temperatures for thousands of years.

The key thing to remember is that it's the total amount of CO2 emissions since the industrial revolution that matters, not the rate we emit. So, Reduce/ Re-use / Recycle (RRR) by itself won't fix global warming if we still use fossil fuel energy at all: it's simply like a bath that's trickling instead of gushing - it'll still overflow eventually.

But eliminating our fossil fuel usage and employing RRR makes it easier and quicker to get to 0 emissions. This still means the priority is clean energy now.

It's possible for most of us to cut out around 66+% of our domestic CO2 production by making just a few big decisions that keep paying both us and the world back. Listed in order of lowest to highest investment:

  1. Switch over to a 100% renewable energy supplier, like Ecotricity, or Good Energy. Pick a big supplier that actually owns Wind turbines, solar power and is starting to invest in baseload energy storage. This will cut out 30% of your emissions.
  2. Radically switch over any gas appliances to electricity. This will probably take a few years, but will include your gas fire and cooker / oven. This will probably address another 15% of your emissions (up to 45% now).
  3. Buy solar power for your house or invest in an Energy4All renewable cooperative. This will make other people's decisions for them, by removing some of the market for the existing fossil fuel industry and placing energy production power in your hands rather than theirs.
  4. Switch to an electric vehicle as soon as you can afford it. This will cut out another 30% of CO2 emissions. Even if you cut down on car driving and cycle or walk instead (a good thing), it's a false economy to believe that it's less polluting to keep an old fossil fuel car going as long as possible, because all it does is delay the time when you go clean: because the emissions involved in the new car will be a fixed cost. Every year we delay on this is a year the fossil fuel car industry has less incentive to switch: vote with your bank account.

The total here amounts to about 75% of your CO2 production and up to 30% of other's CO2 production. I cover this in a bit more detail in this post.

By contrast, difficulty with putting Monbiot's argument into practice is that to address it, we have to change our lifestyles in hundreds of small ways and a few big ways:

  1. To eliminate the consumerism we generate (though it's hard to predict when we'll stop using new things and there are also multiple ways of addressing consumerism, e.g. sharing as many consumables as possible).
  2. To eliminate the consumerism others generate for us (e.g gifts) without appearing to be kill-joys.
  3. To campaign for governments and world organisations to address the root causes, like conflict minerals. This is needed, because time and time again we're going to be suckered by cheaper products that we think we do need, and we don't have the time or knowledge to fully (or even partially) analyse the supply chains and ethics involved. Regulations are needed to shift the playing field in favour. Consider the effort involved by the company Fairphone (I have a fairphone 1) in tracing mineral sources.

So, the probability is that we'll try to do these things for a while, but slowly get overwhelmed by the market forces pushing us in the opposite direction.

This is really just an application of Every Big Helps from Sustainability Without the Hot Air.