Ship Diorama Build Blog : HMS Rodney : Pt1

The eagle eyed of you will have seen the slew of short model videos going onto my YouTube Channel, and the great and good among you will have subscribed there already, if not the YouTube link is always right there in my blog.

But my new project is a blog exclusive, I'm not planning on filming much of this build, instead we're going to use more high-resolution photographs taken on my phone.

It's also going to be one of the biggest "things" I've ever built.  I've returned to modelling as a hobby in my middle age, but as a kid I was very keen model maker and I had literally hundreds of planes in zoom poses hung from my bedroom ceiling.

But I also had a small fleet, I had the HMS Belfast, HMS Hood and HMS Illustrious in 1/600 by Airfix on my window sill.

In fact in my mid 20's I actually bought and build a second HMS Belfast, which I actually left in my then rented house when I moved out, as I could not find anywhere to put it, but couldn't bring myself to throw her away.

Anyway, I've now decided to start a new fleet and I've decided to go with a 1/700 build of one of my favourite ships HMS Rodney.  Historically this lends some symmetry to my old HMS Hood, as the Rodney exacted terrible revenge by helping to sink the Bismark.

This smaller scale is perhaps my challenge, and the level of detail I want to bring to the model is going to likewise be a challenge.  And I am on the hunt for more detail sets and photo etch to put into use before I get started.  As such, I need to start the model somewhere other then itself, and I've decided on making a diorama.

I can't possibly use epoxy, it's too cold to go work outside and working in my office, I have to be able to put my model making kit all away, so a long cure time is out of the question.  I'm therefore going to start small and simple... I can after all lift the ship back off this base at anytime.

The first step was to use the included base as a template, I tried on card, but immediately saw the materials I had at hand would cause it to disintegrate.  So I found this piece of 2 inch thick polystyrene from a package, and started to mark out the outline.

Next I cut the large sheet to roughly the right size and broke off the excess material.

Next I needed to do some preparation work, I decanted some of my PVA into a spare jar, which has a lid, putting in about 60g of the glue and 80ml of water I shook them vigorously until I had a quite runny PVA mix.

I also retrieved a single piece of aluminium foil roughly the size of the whole base, and I started to roughly layout and gently manipulating the foil to fit like the first layer of my wave effect.

Once I was happy I slipped these aside and painted a layer of neat PVA quite thickly onto the base and then started to place the foil back in place.

making sure to let the foil fall as it liked.

Once it was completely covered I then took single sheets of toilet paper and the PVA water mix and started to layer them over the foil, with the aim of softening the harsh lines, but keeping the pattern random and natural.

Once complete I did a test fit of the plastic base.

And from that alignment started to layout very thin lines of paper and foil atop the current layers, to make an inflection of a bow wave.

A quick test fit.

And once I was happy I got the acrylic paints out, very dilute with water I started with a deep aquamarine gloss from Revell.  Adding a hint of green gave this strong bold colour a real flare of effect.

But, this is only a hint layer and so another layer of toilet paper, single ply this time, was used with the watered down PVA to activate the paint and bring it through.

This further softened the overall wave effect, this is notcable most in the left of field and in the bow wave being much softer and appearing to roll.

A final smattering of watered PVA and I set this whole thing aside.

My plan going forward is to let it dry completely, then trim the excess foil and paper from around the edges, before hitting the glossy acrylic again, but that will be softed with white/grey.  And I'll gloss varnish after that, before picking out the waves with white and giving everything a second gloss varnish.

I've seen a recommendation to use a high gloss varnish of another type, so we'll see... either way, for my first base ever, I'm happy so far, and... it's kept me out of trouble for two and a half hours making it.

See the other parts here:

Part 2

Part 3

Part 4

Code History : Old Computers to Teach New Developers

A fair while ago, I posted about my Virtual CPU code, that code (still not complete) just does addition (and my association subtraction), the point was to lead into code which emulated actual logic gates and indeed I write (somewhere in these pages) a half-adder followed by a full-adder emulation logic in C++ code.

The purpose of this was actually related to my giving a talk to some school children, it was ever intended for these pages, the kids could not wrap their heads around not being able to "just multiply".

They had studied computer memory, and wrote documents in word bigger than the actual memory foot-print of the machines they were talking about.

The teacher, a friend of mine, wanted to demonstrate this to them.... I therefore hoved into view with my 12Kbyte Commodore 16... And challenged the kids to write a program for it... They then had the massive struggle... One bright young chap found a C16 emulator online, and he wrote out a long program in Commodore Basic, which amounted to little more than a text-editor...

It was very impressive work from the young chap, and I've kept his number for when he graduates (in 2021), unfortunately it worked fine on the emulator, as you could assign more memory to the machine... After typing the program into the actual machine... It ran out of memory!  The edit buffer was only 214 bytes...

He had only tested with "10 print 'hello' 20 goto 10", but typing any lengthier program in and it essentially started to overwrite the previous lines of code.

You might call this an oversight, but it was semi-intentional as after all the project was about memory.

So having learned how expensive and precious memory was, and is, in this world of near unlimited storage the kids moved onto assembly, learning about how the lowest level of a machine worked.

This is where my work came into help, because they could not wrap their heads around "not multiplying".  In some chips a multiplication call might be many thousands of gates ("to multiply was 200,000 gates, over half the chip" - 3Dfx Oral History Panel - See video below).

Hence I wrote the code of a CPU only to do addition, to multiple one had to write assembly which did a loop of additions!  I left the kids to write the assembly for division, which is why you never see it here in my code.

It worked, but I find so many commentators have missed this piece of computing history, have missed that machines used to NOT come with every function, you had to emulate some functions in software with the bare-set of commands present.

Some have confused this with the idea of RISC, this isn't what RISC is about, but I distinctly remember being taught about the RISC based machines at school (Acorn machines) and that RISC meant there were "less instructions".  Sofie Wilson herself tells us that this isn't the point of RISC...

Having just spoken to my friend about the possibility of presenting these ideas again to a class of kids, I'm wondering whether I need to clean up all my code here, to actually make-sense of all these disparate and separate sources and write one paper on the topic; histories of this which are readable by kids seem to be sadly lacking, or they start from the point of view of a child of my time, born in the late 1970's whom remembers a time when you have limits in computing.

Kids today see no such limits, and find it hard to relate to them, my own niece and nephews, whom are just turning 15, find it hard to fathom such limits, even when they can sit down with me in front of a 12K machine, or a 512K machine, they can't relate, these pieces of history, these things which previously one had to work around are alien to them.

They don't need to work around them, and this leaves me meeting modern graduates whom lack some of the lowest level debugging and problem solving skills.

Indeed, I see these great efforts to publish frameworks to make modern developers test and think about software, because new developers have never had to get things right the first time...

I did, I'm one of the seeming few, who had to get it right and first time.  This is not bragging, it's actually quite sad, as how do you prove your code is good?  Pointing to a track record counts for very little, especially when the person you are trying to persuade has no interest in you, just your skills.

My most recent anathema, Test Driven Development, seems to be the biggest carbuncle in this form of "modern development"... Write me some code... They might ask, and you can write the code, and show it's correct, or you can write the tests which test the range, the type, the call, the library... Then write the code?... One is quick, efficient, but requires faith in the developer... One is slower, aims to forge faith of the code out of the result... Both end up with the same result, but one requires a leap of faith and trust.

Unfortunately, bugs in code, over the history of development have destroyed that faith in the developer.  There are a precious few developers whom are trusted to act on their own initiative any longer.  I know I work in a part of my employers company where I am trusted to act on my own initiative; with temperance that I have delivered very many years of good working products.

But I'm seeing, and hearing, of so many other parts of companies around us which do not trust their developers, and I would argue, if these developers had had to struggle with some of the historical problems my own generation of developers had struggled with, then they would be trusted more, and be freer to act, rather than being confined and held-back by needing to check, recheck and double check their code.

Trust in one another, a peer review, and where necessary a sentence of text on the purpose of some function or other, should really define good development, the code itself can tell you it's purpose, not the tests, certainly not by just running the code employing observation.

I therefore propose I get off my pontificating bum, clean up all my "virtual CPU" stuff, document some of these issues, and we as part of the development community try to get new developers to challenge themselves against Old Computers... ComputerPhile already demonstrate this with their Crash Bug examples with the Atari ST...

Copy, what's a copy? Oh near enough'll do....

I remember the days when the xerographic process was a mechanical physical operation of light and toner on a drum, so your copies - though they came out slightly worse for wear - were identical to the original, there was no digital tom follery and there was no middle man here.

And perhaps there never should have been, save for the cost of duplication, to minimise costs copiers started to use digital scanning, I noticed this rise about twenty years ago, when the office copier, which we'd lovingly beaten into a pulp for splashing us with toner and smashed the glass on by sitting on it, was finally replaced, and we got a machine noticeably smaller and lighter doing 10x the speed.

This new machine of course as powered by a computer, but at the time then the computer was pretty rudimentary, we're talking Pentium 60mhz being bleeding edge, and embedded solutions like in this copier much much more low power, so of course they used a compression mechanism.

I remember distinctly being told this copier had 32mb of ram, in a era of 4mb standard on the desktop, 32mb seemed like acres.  And the technician told us it could have up to 256mb in module updates... ooooo.....

I always trusted the copier, and assumed it did a 1:1 copy, oh how foolish I feel with this news in the headlines.

Of course a computer is doing this, so its using compression, but never ever did I think about this, nor did I ever think it would be a good idea for that compression software to CHANGE the figures on a copy!

I mean, that's the sole purpose of the hardware, to get form a to b the exact same image data, yet it does not?  And then I thought about the comments further, this software is READING, interpreting, the copy its making changing 6's to 8's.. that's not solely just image break up, that's a decision being made, that's OCR, that's bloody worrying.

I don't want machines reading my documents, I don't want the laser printer to refuse to print because my document is stupid, I don't want the machine to make any assumptions that it knows best, the phrase after all is WYSIWYG... What you see is what you get... I don't W Y S I N W Y G B W T M D F Y.... What you see is not what you get but what the machine decided for you.

The whole affair smacks of too technical a result being squashed into the machines to make them cheaper, and an utter and total lack of testing to any decent degree.  The fact that this problem was only spotted in 2013 begs the question whether this is a new innovation back firing, or a long standing issue as well!