Replacing the alternator on a V12 – this sounds a bit daunting, but is actually a fairly simple job! The main advice I want to give though is DO NOT listen to the official service manual. It has all sorts of steps that I found to be completely unnecessary, such as fully disconnecting the oil filter assembly (why??), the underside splash guard or installing the alternator without the pulley and then attaching the pulley in-place (surely you have hardly any room to work with that method). Therefore I expect the official dealer ‘book time’ for this job could be fairly expensive.
I done this job working purely from the top of the car never had to do anything from underneath, except maybe push the plastic cooling tube back on when re-assembling.
Basically just strip down parts for access:
Fan (don’t need a special tool to remove it – a wedged 7mm spanner on the small nuts will prevent it turning whilst you turn the 32mm spanner on the main nut)
Radiator shroud and expansion bottle – unfortunately you will lose some coolant as I choose to fully remove it rather than just try and wedge it out the way. I put some bubble wrap over the radiator to protect it in case I accidently struck when working on other things.
Right side MAF and air box top as pic.
Disconnect radiator top hose at radiator end – you don’t have to disconnect other end if you don’t want to, there is room just to push it out the way.
You may have to disconnect the transmission oil cooler line (right underneath radiator hose) and right side rotor just to get some wiggle room. Can probably do it without but just gives a bit extra room to work with.
Then detension the belt at the tensioner. At this point you can just undo the bolts on the alt and tensioner. You can then tilt the alt forward to give you room to disconnect the two cables at the back. Then just lift it up and out!
Re-assembly is reverse of above. I also cleaned & filed the electrical ‘spade’ connectors as mine were a bit corroded and double checked the main cable was not shorted at any point (eg, in the metal tube it goes through to get to the jump start point). Mine was just fine.
Replacement alt was only $112 plus $46 core from Autozone (US) – which seems pretty good value. Lifetime warranty. Back to a solid 13.6V with the car running
2000 BMW 740iL - problem – clouds of blue smoke everywhere on startup! The internet and it’s dog will tell you this is a classic problem with the M62 V8 engine – failure of the PCV (positive crankcase ventilation) at the rear of the intake manifold. There is a thin rubber diaphragm inside this component and if it tears the engine vacuum will draw oil through the breather pipe into the intake manifold, where of course it will be burned off and produce blue smoke. Specialist BMW mechanics were also sure this was the problem even though my PCV looked ok…
New part was bought and fitted (extremely difficult to remove the old one as the hex bolts all stripped). No difference! I was so convinced this was the problem I bought a second PCV – official BMW this time instead of the Meyle part. Still no difference. Time to dig deeper. You can Google elsewhere for full instructions on removing the intake manifold – but basically just unbolt stuff – you can then remove the fuel rail and wiring loom and suspend it above where it used to be - you do NOT need to disconnect the fuel line to do this.
Look at the amount of oil that had collected in the manifold! Now to remove the right hand side valve cover and the piece that goes along side, called the upper timing cover. This reveals the cam shaft and chains. There was a horrendous mess of congealed oil everywhere inside the engine – it was as if the previous owner had never done an oil change
What we’re looking for is the oil separator valve (OSV) – as the name suggests this separates oil in vapour form coming from the crankcase back to liquid through the use of an air pressure change in the cyclone – liquid drops back to the sump and the air is pulled through to the intake manifold. You can just about see the OSV in the right picture below – it’s buried pretty deep behind the chain but it’s the VANOS rail in particular that makes access difficult. After cleaning up some gunk it became clear the piece of plastic connecting the top of the cyclone to the breather pipe was cracked, which effectively rendered the cyclone useless – so liquid oil as well as vapour was being pulled up through the breather pipe to the manifold – no wonder some much collected there!
At this point I admit I did not replace the OSV – to do this really requires removal of the lower timing cover – essentially the front of the engine – and that requires the oil pump to be removed along with water pump, auxiliaries, locking the cams with a special tool I didn’t have, removing the chain tensioners, etc. You can now imagine why this would be $4000 or $5000 in labour costs at a specialist mechanic (and you probably shouldn’t trust a non-specialist with the VANOS/cam system!). So instead I fashioned an in-place repair of the broken pipe piece – using some high temperature hosing and high temperature epoxy resin. I wasn’t really sure this would work but when I put everything back together it worked! I sold the car over 2 years later and it was 100% fine all that time – no reason to believe it’s not still fine. Absolutely zero oil burning. The horrendous oil gunk I found under the valve cover also seemed to no have no effect – the engine remained extremely smooth and powerful.
2 Days To Vegas was a concept developed by Steel Monkeys initially for PS2 around 2003/2004. Mostly influenced by Grand Theft Auto it was crime themed with vehicles and characters. First pitched as a third person game, it was reduced to first person because of animation cost.
The game was ambitious planned with a brand new engine, new editor, new fx, voice overs, multi-layer streaming audio, and much more.
With perhaps 6 senior programmers assigned to tech, some things were technically very good indeed. The editor was what would become a standard editor in the PS3/360 era – an interface to a running instance of the game – where the designer could just ‘drop in’ objects, assign them physics, etc. I wrote what was called the ‘XML transport layer’ – the editor could request all sorts of information from the game runtime, and then inject all sorts of things back. This used TCP/IP (using the PS2 network adaptor) for live work, but the instruction sequence could be ‘baked down’ to files so levels were constructed using the same code-path when the editor wasn’t present.
Unfortunately only 2 coders or so over that time period were assigned to gameplay.. coupled with some poor art assets and limited design resources the demo designed to pitch the game at E3 that year just wasn’t very playable. Publishers are rarely interested in tech alone with a good game to go with it, and this demo was all tech, no game! The game wasn’t picked up and the company folded a month later (ironically the game improved a lot in that last month – but too late!)
Point of Attack aka Outlanders was a concept developed by Steel Monkeys around 2003. Perhaps a little too influenced by Halo it was one of the very first games to combine FPS with vehicles. That probably seems strange now but back then FPS games were very distinct from vehicle based games.
I worked on the engine and I remember doing game audio, HUD, particle effects and logic for the start of level drop ship and end of level helicopter.
The game pioneered a lot of post-processing effects that again are very common day but were ground breaking around 2002/2003. Depth of field, bloom, motion blur, colour grading and ‘fingers of god’ which was a heavy bloom buffer with feedback causing the bloom to stretch & seep over multiple frames.
And none of them appear to be turned on in the screenshots I found! It looked a lot better at the time.
The game was Xbox based, and unfortunately it was pitched around the time the PS2 was becoming the dominant console of that era. With no publisher on-board the game was cancelled.
Fear Factor Unleashed was a project for PC, Xbox and PS2 based on the Fear Factor tv show. The time scale for the project was very short and the company had no existing cross-platform tech so the decision was taken to use the Renderware middleware. At the time Renderware had a good reputation as it had been used in GTA 3 and Burnout. It soon became clear though that GTA 3 and Burnout must have had a lot of programmers working on the engine, because what was in the base Renderware was not very impressive at all. It’s no exaggeration to say we could have built our own PS2/Xbox/PC tech in the time taken working around Renderware problems or unimplemented features.
Regardless the game featured a mix of 3rd person platforming levels, vehicle based levels and special button press ‘eating’ levels to match the TV show. It certainly wasn’t a triple A game, but was certainly competitive with other mid-range PS2 titles from around that time. The game was never released as the publisher went bankrupt and although a few other publishers were interested nothing came of it.
There was some nice graphics tech in the game, such as heat hazes, render to texture effects, projected lights, reflective water on Xbox/PC and blur/disorient post-fx for when your ‘fear meter’ got too high! I was the lead on the Xbox platform, but as it was only a small team (5 programmers total, later 4) I done a lot of work on PS2 and PC as well. In particular I remember working on character collision detection – using a swept ellipsoid representing the character against the landscape triangle mesh. Swept means you are colliding over time as well as 3d space – so you find out what position in the timestep a potential collision would occur. There is a neat trick to swept ellipsoid detection – imagine transforming the world triangles by the inverse of the ellipsoid – so that if the ellipsoid was a perfect sphere the world is now ‘squashed’. Then transform the triangles around the direction you are sweeping in (imagine looking down the movement direction defined and seeing the triangles in front you – essentially a barycentric space). So now your ellipsoid is just really a 2d sphere looking at oncoming triangles – simply solve triangle versus sphere for every triangle and you have all your collision points! (Testing vertex to be inside or outside of sphere, then line versus circle for each edge of the triangle). The ‘depth’ in this space essentially gives the ‘time’ of collision, and you can just transform the results back to world space position & time step proportion when done.
I found an interesting project on a backup harddrive from 2002 which was the ‘Trojan horse’ software I wrote to analyse the software protection device on the Data East Fighters History arcade pcb game.
I doubt the code itself is very useful anymore but the process it used may still be interesting. You can download the files >here
FH used an ARM cpu – ARM cpus are everywhere these days but were still quite rare in 1993! Coupled to this was a copy protection chip that essentially had a range of input ports the CPU could write to and modified results could be read back. By writing game code variables to the chip and the code that read them back ‘knowing’ the permutation that would be applied the copy protection was quite effective. Unless you knew all the hardware permutations game code would at worst crash and at best behave incorrectly – drawing wrong graphics, game moves not working correctly, etc. Because it was close to impossible to guess what the protection chip did just by examining the software the only solution is to run special software on the board that deliberately probes the protection device by writing known values and examining the results returned. Hence ‘Trojan horse’.
Unlike earlier 8 and 16 bit games it was actually feasible to use a modern C compiler to write code to run on this device, so the official ARM c compiler was used (circa 2000) and the flow was C program -> .o ASM file -> patch ASM into original ROM image -> split ROM image into 2 16 bit images -> burn ROMs to EEPROM -> install EEPROMs on board -> get results!
The main components on the pcb board below are A – the ARM cpu (not marked as ARM – they only licensed the design so the chip was fabricated for Data East and is marked as such). B – two 16 bit program EEPROMs – the 16 bit data buses are interleaved to provide a 32 bit stream for the CPU. C – the protection chip itself. The fact it’s mounted on a daughterboard suggests it was added to the hardware design fairly late.
Recently I noticed Charles Macdonald had furthered the work I done on this – http://cgfm2.emuviews.com/new/detech.txt
Around 1995-1998 I worked on a telnet style chat server for Unix and Windows NT. Any trace of it has long disappeared from the web except I found someone that forked it and added it to Sourceforge around 2005!
There’s some vintage old school C code in that project for sure – who remembers declaring C functions like this?
It had some nice features for internet in the 90′s.. the server opened a port for HTTP as well as chat, so web pages could be generated on the fly from the data associated with the logged in users, so names, descriptions, login times, could be mirrored to a web page.
I found one of the last source code zips and placed it here for download.
VCMame archive project has been added – this allowed the use of Visual Studio 6 and Visual Studio .NET to build and debug the MAME project as opposed to the standard GCC/GDB/makefile command line setup.