I’m also a member of the Retro Asylum podcast team, so I’ve been working on several shows (with plenty more in the pipeline) including a completelyÂ impromptuÂ think-on-your-feet episode I had to do at the last minute with my good pal Glenn, when a combination of technology failures and demanding babies threw our carefully made plans out of the window!
Anyway, enough of all of that, I’m sure what you really want to know is how has Starquake been coming along amongst this hive of activity? Well the answer is, surprisingly well. I’ve been plugging away at it and I’m delighted to announce that the game is nearly code complete. What I mean by this is that it will shortly contain all of the elements to make it fully playable. In this state it could be released out into the wild, but I’m not going to do that and I’m afraid you’re going to have to wait a little longer. You see the next stage is all about refinement. This is where I’m going to be adding in all of the little graphical and audio embellishments, the touches that will make this game more than just good remake â€“Â remember what I said at theÂ beginning, my plan is to make this the definitive Starquake remake and not just another clone!
In the last three months, much has changed. Blob is now white like the original 8-bit versions (you will be able to select from a variety of Blobs, including a Satanic version!). I’ve completely redesigned the status panel to provide a much cleaner look. The game now has a ‘game over’ screen and high score table and Blob dies in a… well spectacular way.
I’ve spent many hours tweaking the gameplay. This is one of the hardest elements to get right, making all of the various components behave well together. I’ve been working hard to balance the playing experience and try to make the difficulty level match the original â€“Â ensuring that the nasties aren’t too challenging and making sure that there are no unfair deaths due to poor collision detection (always stack the odds in favor of the player and you’ll get one satisfied gamer!). I’ve also fixed more than a few bugs, so here’s hoping that what you get in your hands will be (virtually) bug-free.
So there it is, that’s what I’ve been up to. There has been a lot going on, but as they say, a picture (or in this case several) is worth a thousand words, so without further ado, here’s a selection of screenshots showing some of the lovely new bits!
One way to start finding the answers is to grab a copy of the machine’s service manuals. These are generally readily available from the internet and will show you exactly how the machine is wired together and what chips it uses. Sure, such manuals are great for repairing old systems, showing you how everything is wired together and often providing you with a number of troubleshooting flow diagrams. However, this is generally where they stop and it’s usually the responsibility of the reader to furnish themselves with any additional material. In the case of standard, off-the-shelf components such as the Z80 processor or the General Instruments AY sound chip, there is plenty of documentation on the internet that can help furnish you with answers. Despite this, one area that is often sadly lacking is insight into how the custom chips of these machines work, and it’s this that Chris Smith’s The ZX Spectrum ULA addresses.
While the centrepoint of this book is undoubtedly a rich and detailed deconstruction of the ‘soul’ of the ZX Spectrum â€“ the ULA, the book also provides an insight into many other areas of microcomputer design in the late 1970s and 1980s. The opening chapters help you understand the industry situation back then, fabrication techniques which will later help you to realise why the ULA was designed in a certain way and why the computer design in general followed a very specific design pattern.
If you’ve ever spent hours pouring over the schematic diagrams of various service manuals (believe me, I have) then this book will answer many of the questions that you might have. For example, why are there multiplexers between the memory chips and processor bus? How is the clock signal generated? As you read through, you will discover that every design decision has been made from a combination of technical and cost factors and the solutions presented are often ingenious. I constantly found myself experiencing a semi-eureka moment as I finally understood the reason for the presence of some of the support chips, which has helped me improve my understanding of how to troubleshoot broken computers as well as how to ‘programatically’ get the best out of them.
Of course â€“ as its title suggests â€“ this book spends a over half of its 300 pages honing in on the design of ULA itself. In particular, there is an extremely detailed description of perhaps the most exciting aspect of a computer’s features: generation of the video display. Questions answered along the way include: Was the attribute clash a bug or clever feature? Why does the machine have a border? Why is the display smaller than other computers? All these and more are answered in the six or so chapters dedicated to video generation.
The video chapters are really one area where you will appreciate having some knowledge of analogue TV systems. The book does go some way to describe how analogue television works, but additional knowledge will no doubt help you enormously and without it, youÂ may find it difficult to grasp some of the more complex concepts. Moving on from the video aspect of the ULA, the latter chapters talk about memory access then IO, including the keyboard and cassette storage system. Even the primitive sound capabilities of the original 48k machine get a brief description and within a few lines you quickly understand the limitations of sound.
The penultimate chapter is perhaps one of the most interesting as it dedicates itself to examining hidden features and bugs of the ZX Spectrum computer. Among the items discussed are why are there dark edges on flashing characters, the phantom key issue and the video
snowing effect. These are all ‘features’ that are very familiar to ZX Spectrum owners and the book explains why they happen.
In conclusion, this book is an absorbing, detailed and fascinating insight into the design and manufacture of the ZX Spectrum’s custom ULA. It is written in a style that is both technical and easy to understand, which is never an easy path to navigate, but this book does so with ease.The language isn’t overly complex making it truly accessible to all levels of technical knowledge. However, as can be expected of any book of this type â€“ the more you know about electronics, the more you’ll get out of it and the best bit is that as your knowledge grows, so too can your understanding of the concepts described. So rather than being a one-off read, this book will no doubtÂ become much-loved and long-term companion that you’ll find yourself referring back to again and again. Chris has clearly spent an enormous amount of time researching, understanding and explaining with passion how Sinclair made the ULA, and has generously shared this information. For die-hard Spectrum fans this book is an absolute must, as it reveals the innermost secrets of Sir Clive’s beloved microcomputer.
The book is published by ZX Design and Media (Chris’ own company) and is available for the bargain price of Â£23.50. Delivery is fast. Following my order, I received the book within three days which considering how near it was to Christmas is a remarkable achievement. I only hope now that Chris will go on to write many more books of this type. I for one would love to know more about the Amstrad CPC’s Gate Array or the custom chips of the C64. One thing is for sure, whatever Chris turns his hand to next â€“ I’m sure will be an excellent piece of work which will meet with great success!
While it’s all well and good Blob being allÂ invulnerableÂ all the time and not losing lives, it hardly makes the game much of a challenge now does it?
This week all of that started to change and I’ve begun creating the animation that will be played when Blob:
If you’d like to see how Blob will die, then check out the video below.
Click here to view the embedded video.
This is still very much work in progress. What you are seeing is the main Blob sprite explode into many pieces which then bounce around the screen in a nice (hopefully) convincing way. There is still much to be added including some niceÂ particleÂ effects – smoke, flames – whatever floats your boat…
Incidentially the death picture (not that you can see it all that well) is by Andrew Dobell and you can find a full sized version here.]]>
Click here to view the embedded video.]]>
In other news, I’ve finalised the distribution of Cheops pyramids, which is now completely random (yep not even I will be able to tell you where they are) and have dished out theÂ obligatory (but far too boring to detail) bug fixes.
Just a quick update for you to enjoy over the weekend, complete with video no less (I know how much more interesting videos are). This week I’ve been mainly bug fixing some of Blob’s interaction routines and improving the nasty AI in my Starquake remake. Sadly none of that gives you anything to look at so I decided to finish the week off by adding a couple of new nasties. Without further ado, I’m very proud to introduce… The ghost nasty and… the um… helmet nasty. To be honest I don’t really know what this guy is supposed to be in the original game, and he looks a bit like an American footballer’s helmet â€“ hence the name. I’ve actually given him a bit of a face-lift and he now looks like a naked mole rat (note the unfortunate teeth). For better or worse, and as unfortunate as he looks, he’s still very much able to annoy Blob as the following video demonstrates:
Click here to view the embedded video.
This is the first video I’ve done with a voiceover which I’m hoping will give you a bit more insight into what I was thinking.]]>
R-Type, is in my opinion one of the best shot-em-up Arcade games ever made. With surreal and imaginativeÂ graphics bearing more than a passingÂ resemblanceÂ to the work of Alien artist H R Giger, and fast paced, excitingÂ game play, R-Type really had it all. Released in 1987 by IRemÂ Corp, the game saw great success in its arcade incarnation. SuchÂ popularityÂ ensured that it was swiftly to home computer systems and consoles with some fantastic conversions appearing on the Amiga, PC Engine, Spectrum and C64.
The CPC version was unfortunately a victim of the famous Speccy-Port. With limited timeÂ availableÂ to make the conversion, the game’s code was lifted directly from the Spectrum and theÂ necessaryÂ routines put in place to convert the graphics and sound routines to work on the Amstrad. Like so manyÂ SpectrumÂ ports, the conversion code took its toll on the CPU and at a speed of just over 3MHz it was impossible for the poor Z80 to run both the spectrum code and the graphics conversion routines at full pace and what we ended up with was a game that ran significantly slower than the other versions.
It wasn’t all bad, despite the monochrome graphics, it still had the excellentÂ game playÂ of its Spetrum forbearer even if it did all feel a bit sluggish. Compared to the colourful arcade versions however, the Amstrad version was a bigÂ disappointment, with the limited graphics and nothing more than simple spot sound effects – CPC owners knew that their machine both deserved and could do much better.
Fast forward to 2010 and a groups of guys working under the name Easter Egg software decided that enough was enough and it was time for the Amstrad to see a proper version of R-Type. Over the next couple of years, they set about creating a remake that would realise the missed potential of the original version. Seeing a release in 2012, Easter Egg’s R-Type remake was a triumph and received universal accolades from retro gaming sites. Restricting itself to 128K machines only, the additional legroom allowed them to remove the terrible Spectrum graphics routines and replaced them with an all new graphics engine complete with 16 colour mode 0 graphics. The result was aÂ completeÂ transformation.Â ColourfulÂ graphics, a new graphics engine that was able to run at a much faster speed and a full musical score through the game – this conversion finally does the Amstrad justice.
The game was released as a CPC disk image for use with any of the popular Amstrad Emulators.Â ThoseÂ ofÂ us lucky enough to have the original CPC hardware could easily copy the image onto a 3.5 or 3″Â floppyÂ disc and play it on the real machine. Now, with the game released and available for download, usually the story would end there – but one day I was approached on the CPC Wiki forum by one of the remake authors who offered me a very special opportunity…
The author goes by the name of TotO and he told me that they were doing a very limited edition run of the game presented on original 3″ CPC floppy disc with authentic packaging and was I interested in them making one for me for a very reasonable fee. being aÂ hugeÂ fan of this remake IÂ couldn’tÂ let an opportunity like this go by, and within a week this landed on my doormat:
I think you have to agree that is a really fantastic item. The attention to detail is amazing, right down to a holographic label and stickers determining machine format. This really is a fabulous collector’s piece and pays exactly the same meticulous attention to detail that is paid to the remake itself. My thanks go out to TotO for making this for me â€“ I’m sure he’ll be delighted to know that it has pride of place on the centre of my retro gaming shelf!]]>
The Starquake story starts way back in 1986. Many events took place that year, Kodak (beaten by Polaroid) left the instant camera market. Spain and Portugal entered the European Community. Such worldwide events however bore little significance to me compared to the excitement of receiving my very first computer, an Amstrad CPC 6128 for my December birthday. Aside from the obligatory CPM Plus and demo discs, the CPC happened to ship with what was to become one of the most important discs I’ve ever owned – a very special compilation of four games called the Amtix Accolades. Usually new computers ship with free games that are utterly awful. Since awful games make next to no money in the first place, they’re very cheap to acquire. In this instance however, this proved not to be the case. Side one of the compilation contained the fantastically frantic Monty on the Run and the bizarre but brilliant Sweevo’s World, while side two contained the challenging puzzler Bounder and perhaps the greatest video game ever made – Starquake.
Released in 1985 by Bubble Bus software and written by Stephen Crow, Starquake contains all the ingredients of an instant classic. Part arcade, part adventure â€“ it sees you taking the role of a robotic life-form called Blob whose job is to rebuild the unstable core of a planet before it explodes, taking the universe with it! A dramatic story line indeed, and while it may sound serious, to lighten the mood, the game is absolutely packed with humour and nods to other games of the time. A read through the instruction leaflet confirms that Mr Crow has a healthy sense of humour.
Taking place in a play area consisting of 512 screens, even today, Starquake’s size is truly epic. When you consider that it was converted to a number of machines including the BBC micro, which only had 32K of RAM, it’s an astounding achievement. Back in the day, Starquake received some great reviews. Crash gave the Spectrum version a near perfect 96%, with the reviewer stating that it “is one of the best games I’ve seen on the Spectrum for one hell of a long time“. Amtix equally raved about the Amstrad version, giving it 91% and a well-deserved accolade. They summed it up by saying “Stephen Crow deserves the hit, and you deserve to treat yourself“.
When I loaded the game for the first time in 1986, I knew nothing about the reviews and had no idea that it was already considered a classic. Remembering back to my first impressions of the game, I recall how I was totally blown away by the look, the atmosphere and the sheer size of it all. For the first few months, I spent all of my time just exploring without actually caring what Blob’s mission was. Due to its sheer scale, there was always something new to discover and it was a wonderful feeling to wonder down a corridor and come across a totally new area.
The graphics are extremely varied, with many different areas. At the beginning, you start off in rocky terrain. As you dive deeper into the rocky caverns you discover areas that are built from molecular structures then as you explore further you find places built from blocks which morph into locations constructed from jungle plants. The variation really is astonishing and part of the fun is trying to discover what’s going to come next.
As time went by, I continually improved at the game and finally completed it after two years. It was the first game I’d ever completed without a cheat and very proud of myself I was too! Sadly in the years that followed, first the disc wore out then finally the Amstrad died. Indeed it wasn’t until the early to mid-90’s that I saw the game again and that was all thanks to emulation. Back in the early 90’s, I heard about the possibility of being able to emulate old computer systems, that is to run a program on a modern machine that would trick software written for a much older/different machine to run on it. At the time I had an Amiga 1200 and came across a Commodore 64 emulator (its name escapes me), but unfortunately with the 1200 running at a mere 14Mhz, everything ran exceptionally slowly and at that point I gave up.
It wasn’t until a few years later when I’d upgraded to a 486 PC that I came across another emulator. This time it was a program called CPE and the best part was that it could emulate the Amstrad CPC systems. I quickly downloaded the program and was delighted to see the familiar old Amstrad yellow welcome message for the first time after more than a decade. Of course I now had an emulator but no games to run on it. Fortunately I learned of a french ftp site (which still runs to this day) that was archiving all Amstrad CPC software. Hardly able to contain my excitement, I opened up the site and was delighted to find that someone had uploaded a disc image of Starquake. A few moments later and finally after many years I experienced a very special moment, seeing Starquake running once again after so many years.
Playing through the game again, I was amazed to find that it had lost virtually nothing with the passage of time and was still as enjoyable as it had been more than 10 years ago. The only real problem was thatÂ computersÂ had moved on, graphics had advanced, and as enjoyable as it was, I could stop thinking how great it would be to be able to realise the game once again but in a more modern reincarnation…
Back in 2002, after a break for many years, I decided to start game programming again. I’d previously done some work in Z80 assembly on the CPC and had played around with 68000 on the Amiga. It was while I’d owned an Amiga that I first encountered Blitz Basic. Here was a platform that allowed you to develop arcade games quickly and easily without all of the time-consuming complications inherent to assembly languages. Playing around with Blitz Basic gave me the opportunity to figure out how to code arcade games. I tried my hand at many different genres an Arkanoid clone, various platform games, a point-and-shoot in the vein of Zombie Apocalypse, all of which helped me to understand what made arcade games tick.
Back to 2002 and I’d just picked up a copy of Blitz Basic for the PC. Despite being a seasoned C++/C programmer, it was again the time-saving and indeed power provided by the Blitz platform that encouraged me to use it to start a project that would see three different versions and a development period of over a decade â€“ a remake of my all-timeÂ favoriteÂ video game, Starquake.
The first version of Starquake, written in Blitz Basic, was a more-or-less straight conversion of the original home computer version. Using graphics taken from the Amstrad version,Â recoloredÂ somewhat crudely in Paint Shop Pro, I finally released a version that looked like this:
Version one was completely playable, but it wasn’t possible to complete the game in the demo release. I was planning on finishing it, but just wasn’t happy with the graphics. Around this time I met an excellent chap called Phil Emerson. He was also writing a Starquake remake, but in C++. We chatted for a while about the challenges of working on a project alone and I managed to convince him that a switch to Blitz instead of C++ would dramatically increase his productivity. He did just that and soon released an Alpha version of his remake which had some very nice graphics (drawn in 800 x 600) and some excellent additional game-play ideas:
You can see some more of Phil’s artwork here.
Unfortunately, like me, even with the increased productivity offered by Blitz, Phil also found that he just didn’t have the time to work on the remake alone. It was with this in mind that we decided to join forces and work on a Starquake remake together.
In the meantime, it was the 2003 Retro Remakes competition and before starting work on Starquake, we decided to hone our collaborative skills and work on something for the competition. As Starquake was already WIP it didn’t qualify as an entry, so we decided to make a remake of SpellBound instead. In the weeks that followed, we got the game 95% done but sadly due to problems with our internet connection (and a disagreement with the then administrators of Retro Remakes) we were never able to enter it into the competition. Having put several weeks of effort into Spellbound, we both felt dejected and decided to take a break for a few months.
Unfortunately, due to personal commitments, Phil was never able to work on Starquake again, so I found myself alone to work on the remake. I was inspired by Phil’s artwork though and having gained some art qualifications myself back in the day, I toyed with the idea of drawing all of the graphics myself.
The year was 2005 and a company called Media Chance had recently released a very interesting vector drawing package called RealDraw. RealDraw was unique in that not only did it allow you to draw images using vectors almost as easily as drawing bitmaps, it also allowed a number of effects to be added to the vector shapes such as 3D bevels, light sources, etc. I found that it was easy to build nice-looking graphics and use the program to give them a convincing 3D look. I played around with a few graphic ideas in a demo version and quickly decided that this was the package for me. Fifty pounds worse off later and I had the full version in my hand.
Armed with RealDraw, I spent the next few months redrawing all of my Starquake graphics. The resolution was increased from the original 320 x 256 to 640 x 480, which allowed me to add a lot of additional detail to the graphics and bring it a bit more up-to-date with modern PC systems. Eventually Starquake version two was born and it looked like this:
It was more version one with a graphical face-lift than anything else, since the code was still written in Blitz. Unfortunately I was beginning to discover problems with the structure of the game I’d written in Blitz and it was becoming apparent that it would be very difficult to iron out all the little bugs and finish everything off without a major reworking. Around the same time, like Phil’s, my life suddenly became very busy.
It was mid 2006 and I’d just accepted a job as a developer with a company writing software for the film and TV industry in Soho, working on a product called ContentAgent. The software was written in C# (a Microsoft language borrowing much from C, C++ and Java) with some C++ plugins. While having a few years of C# experience in a previous role helped, coupled with some years working with C++, it was almost certainly the demonstration of my Blitz version of Starquake that I have to thank for finally persuading them to take on as a developer (I think my boss just wanted to see it finished if I’m honest!).
Over the next few years, I threw myself into developing ContentAgent, which gave me the opportunity to hone my object orientated language skills. C# quickly grew as a language, passing through version 2.0 to 3.0 then 3.5, 4.0 and now 4.5. It also grew as a multimedia platform and began offering DirectX support via the Managed DirectX API. It was at this point that I thought back to Starquake and realised that if I was to switch the project to C#, I would be able to use the benefits of the object orientated system to organise the project in such a way that it wouldn’t suffer from the problems that had plagued my Blitz version.
I hadÂ considered using C++ in the past and had even knocked up a demo using C++ and Allegro. Unfortunately, C++ development is time-consuming and I was never able to find sufficient time to develop something properly. Managed DirectX looked like a perfect fit, so near the end of 2006, I started writing the third version of Starquake using a combination of Managed DirectX and C#.
Over the next year or so, version three developed at a reasonable pace. I got to the point where I had Blob running around the complete game map. However, progress was quite slow and it was becoming apparent than the Managed DirectX wrapper was little more than a wrapper for the C++ libraries and it was going to take considerable time to create something using this combination. Fortunately, around the same time Microsoft released a little something called XNA. XNA was a suite of tools that would allow indie game writers to develop arcade games quickly and easily for the XBOX 360 and Windows PC.
The system is based around C# and consists of a set of libraries that target DirectX. Unlike Managed DirectX, many helper classes are provided which take the pain out of writing ‘boilerplate’ code. This allows would-be game developers with restricted time to get things up and running quickly, while at the same time giving you power to control virtually every aspect of the system should you need to. XNA also has a number of plugins that allow you to create all sorts of special effects such as the excellent MercuryÂ Particle Engine. It can also program the graphic card shaders directly using the High Level Shader Language, which allows you to do virtually anything imaginable.
With a pretty advanced version three of Starquake coded in C#, it was a relatively easy task to move it all over to XNA. At around the same time, I’d gained a lot more experience with Real Draw and at that point, I decided to ditch the graphics again and redraw them from scratch. This time the resolution was upgraded to a much more modern 1200 x 800 (though the game for the most part is faithful to the original 4 x 3, so runs at 1024 x 768). I was keen to redo the graphics, not only because of wanting to go for a higher resolution, but also because I wanted to make use of Alpha. Unfortunately the Blitz language back in the day didn’t support Alpha transparency, which gave the game a very solid look and restricted the sorts of graphical effects available. The full Alpha support of DirectX allowed me to produce some graphics that could look very nice and blend far better with the background scenery:
Work began on the XNA version of Starquake in 2010. It’s now late 2012, the game is now 90% complete, the code is structured well and it finally has graphics I’m pleased with. I’m aiming for a release in autumn 2013 to coincide with the Replay Expo show, but it may be sooner. So there you have it, the complete story of the thrills and spills of the last 10 tears developing my Starquake remake. Starquake is a game that has been with me for nearly 25 years now and with work on the remake continuing, it doesn’t look like it’s going to leave me anytime soon!]]>
For the last couple of weeks I’ve been working long and hard, tirelessly and meticulously, forging something very special… I’m now delighted to announce (cueÂ rapturousÂ applause…) Starquake with… SoundFX. Yes after spending the last two years in absolute silence, Blob and the world around him are mute no more. I’ll be telling you all about the new Sound Effect Engine and XNA in a forthcoming post, but for now, enjoy this little video which not only shows off the spanking new sound engine, but for an added bonus â€“ the new Options screens. Aren’t you the lucky ones?
So what are you waiting for? Click below for this exciting new video!
Click here to view the embedded video.]]>
Greetings dear readers, I was anticipating bringing you a lovely write-up of my recently purchased Amstrad 6128 Plus vintage computer tonight, instead, you’re getting an installment of “Oh my god I’ve been hacked goddammit!”Â â€“ aren’t you the lucky ones eh? Indeed as I strolled confidentially to my WordPress login page earlier this evening, I was (not so) delighted to find that my site had been compromised by the catchily-named #c3284# malware virus, promoting the sudden exclamation of “Oh crap!” (well something like that anyway).
#c3284# is a delightful little beast, which upon finding its way onto your WordPress site, injects itself into one of the PHP files (in my case header.PHP) and from there will open your htaccess file (a directory level configuration file present on a Linux web server) when it’s executed and rewrite it so that your site’s URL directs your precious visitors to a dodgy website which is almost certainly selling Viagra or some form of body augmentation.
Since you almost certainly have no intention of selling Viagra to your users (face it, it’s already a crowded marketplace), this needs to be sorted and quickly. The first indication you’ll get that an attack has taken place will likely be a prompt from Google safe browsing stating that your site contains suspected malware and has been blacklisted. In fact you’ll get something that looks very much like the picture above. This is your prompt to get off your backside and log into your Google Webmaster Tools account. If you don’t have a Webmaster account already, I strongly recommend you sign up right now; it’s an invaluable tool for checking the general health of your site, along with providing a whole host of tools for analysing your website in detail, including traffic, page loading issues and so on.
If you do have a Google Webmaster account, you can quickly browse to the health section for your site, where if a problem as been detected (which it will have if Google has taken the trouble to blacklist your site) it will actually tell you what malicious code it has detected. This will look something like this:
Now the site is clean, how can an attack like this be prevented in the future? Well, usually as a matter of course, excluding the ‘Content’ folder, I set access to all of the files on my WordPress sites to read-only (i.e. set permissions of the files and thus those of the web-server account to read only). For pretty much all WordPress day-to-day tasks such as writing posts this doesn’t matter since WordPress writes most of its information to the database. Obviously read-only will prevent you from being able to edit the structure of site itself, i.e. update plugins or install new themes. For that you will have to re-enable write access for a short time. In my case I’d stupidly forgotten to re-enable read-only support after I’d made some theme changes so the virus had a potential way in.
Following an attack, it’s always a good idea to give your host a quick call to report the issue and get them to run a scan on their server. If you’re on a shared site, there is every chance that another site on that server is infected and in that case it may well be possible for the malware virus to gain access to an account with sufficient privileges and write to your files using an account that has write privileges. While your at it, change your FTP password. Finally inform Google (via the Webmaster Tools) that your site is now clean. This will prompt them to automatically run another scan and if indeed if they confirm this is the case, it will be removed from the blacklist.
So there you go, sadly no write-up on the Amstrad Plus, but alas all is not lost, you now have the benefit of my several hours delving into the dark recesses of the world of hacking, which has hopefully revealed some of the tricks the hackers use and will save your some time should you ever come up against this nasty little bugger, or maybe its brother, cousin or mother, at some time in the future.
Thank you and goodnight!]]>