Here’s a refresh of the Nodes of Yesod main theme tune from the upcoming tvOS version of the game. This is an updated version of the original score composed by Fred Gray, which I’ve brought up to date a little bit by using some modern instruments.
I recently received my Indiegogo backer edition of the ZX Spectrum Vega by Retro Computers.
Due to a recent move I’d neglected to update the delivery address for the Vega unit, and I must thank SMS Electronics for going above and beyond to make sure a unit reached me – thanks!
I was looking forward to testing the Vega, even though I have previously expressed some skepticism on this site about the design. Retro Computers somehow managed to include a set of games from Ultimate Play The Game (these have been denied distribution elsewhere), and I was especially looking forward to trying those.
Unfortunately, at this point I cannot give the Vega positive review. Issues I’ve encountered include:
- The video quality, for me, is awful. Disclaimer: I live in the USA, so there could be extenuating circumstances; however, on the displays I’ve been able to try with the Vega, a Toshiba 40″ LCD TV and a Dell 24″ multi-sync monitor, I have not been able to get good image. The only video connection possible is composite video (in 2015!) – there’s no HDMI or other option. On the Toshiba, the TV syncs OK to the Vega in either PAL or NTSC mode, but the image quality is very poor – a sort of frozen dot crawl and distorted double image.
On the Dell, I can’t get the Vega to sync at all (a composite modded Spectrum works fine and with a decent picture quality), and instead there is a distorted black and white image that constantly rolls (with Vega in either NTSC or PAL mode). I’m all for a bit of nostalgia, but a simulation of a poorly tuned 1970’s black and white TV is not really what I had in mind.
- There are 1,000 games included with the Vega, and while there may be some gems in there, there is an awful lot of depressingly bad rubbish. It’s not fun to wade through title after title looking for something halfway decent to play.
- Unfortunately, I had a hard time with the buttons on the device, which are arranged in a bit of an odd way. I’ve made grumbling noises previously about the decision by Retro Computers to create a Sinclair Spectrum clone with no keyboard, but I was reserving judgement a little bit until I could get my hands on one. Not only does the Vega lack a full keyboard, but the controller style layout they have provided does not work very well with certain games – namely those requiring any sort of diagonal movement, which I found quite difficult. As I think back to the original Spectrum, many games required two hands to play. You might have up and down controlled by two keys using your left hand, and then left and right controlled by two keys using your right hand. Perhaps your thumb would be used to hit a jump or fire key. On the Vega, it is hard to do diagonal moves using your left thumb alone. Certainly the default mapping, with the red d-pad mapped to directions, makes some of the included games hard to play. Particularly Atic Atac and Sabre Wulfe which were very frustrating to play. Even more so than they were originally.
So far then, quite disappointing, but not totally unexpected. I had half a mind to use the Vega unit as a development target for some refreshes of the Odin Spectrum titles, but since I can’t get a decent video image, and since the controls are so unpleasant to use, I’m not sure that even makes sense.
In conclusion, the lack of decent video (HDMI) and the lack of a full keyboard make this a somewhat expensive (£100!) gimmick.
Back in late 2014, Chris Wilkins approached me to write a “memoir” for his upcoming book, “The Story of the ZX Spectrum in Pixels: VOLUME 1.”
The book, which launched in December 2014, was the result of a successful Kickstarter campaign, and per Chris’s Fusionretrobooks.com site:
The book, ‘The Story of the ZX Spectrum in Pixels‘, is 236 pages in length and finished to the very same high standard adopted for ‘The History of Ocean Software‘ and ‘The Story of U.S. Gold‘ publications . The ‘ Sinclair’ logo on the front cover is embossed making the book a desirable addition to any gaming fan or book collector
The book is predominantly a visual journey charting the best games on the ZX Spectrum from 1982 onwards until the early 90’s. Each spread contains a large iconic image of the game and is accompanied by artwork from the inlay, the game’s advertisement where available and further game screens showing the loading screen, menu etc.
We have also interviewed over 19 programmers, artists and musicians to get their view on the Spectrum and how it helped launch their careers into gaming including Rick Dickinson, the man who designed the Sinclair range of computers.
It’s an excellent read (my contribution notwithstanding), and recommended to anyone interested in the retro gaming scene (and specifically the Sinclair ZX Spectrum). Volume 2 is now well underway and available for preorder, having again been successfully Kickstarted, and I’m personally looking forward to reading it!
To (possibly) whet your appetite, here’s an extract from my contribution to volume 1:
The next year, back home in Barnsley, I bought a 16K Sinclair ZX Spectrum and 13” black & white TV, total price £200 in 1983 money from WH Smiths, with a lot of help from my Mum. My early recollections, upon acquiring the Spectrum, are spending hours and hours loading and exploring the Horizons tape, and then playing Manic Miner, Lunar Jetman and then later Atic Atac. I bought the Spectrum primarily due to my interest in electronic music, but pretty soon I was trying to figure out how to make games in Z80. I remember disassembling Time Gate by Quicksilver, and the minor epiphany when I finally understood LDIR for block byte copies. Thanks John Hollis!
Quite by chance, I came across a page on Chris Smith’s zxdesign.info site: The Sidewize Test. Chris’ site focuses on “reverse engineering of the ZX Spectrum and related projects”, and this particular page is about problems Chris had running my game Sidewize on his Harlequin Spectrum ULA clone.
Sidewize is a game I wrote in 1987, and its one claim to fame/infamy is that it smooth-scrolls approx 2/3 of the Speccy screen @ a silky smooth 50 frames per second.
When I came across Chris’ site I was reminded of one of the tricks used in Sidewize to facilitate the smooth scroll. Back in the 80’s, before the Internet was a thing, information about computers and programming was often spread by word of mouth. And so it was, one fine day in Liverpool, in a conversation with Dougie Burns (programmer of HypaBall on the Speccy @ Odin), Dougie mentioned that his friend Joffa Smith had utilized an IO port on the Speccy to read the value of the current color attribute being written (by the ULA) to the screen, and that this was part of the secret sauce for the smooth scrolling seen in Joffa’s games (Cobra, for example). Being somewhat of a trade secret, the details of the port were not revealed, and so naturally I set out, by a process of trial and error, to discover it for myself – the utility of this being obvious.
On Chris Smith’s site, he extracted some Sidewize code that was causing his Harlequin Speccy ULA emulation some difficulty:
9CF4 LD BC, 40FFh
9CF7 LD E, 40h
9CF9 LD A,R
9CFb IN A,(C)
9CFD CP E
9CFE JP NZ, 9CF9h
In this code, you can see that I’m reading from port 0x40ff, checking for a value, and then looping if that value is not found. To be honest I am not clear what the LD A,R instruction is doing here (though I suspect this is related to the JP NZ,9CF9h instruction and possibly some self-modifying code to conditionally branch on the state of the Z80 parity flag which is set by the LD A,R), but generally this loop is waiting for an attribute value of 0x40, which corresponds to “bright black”, and this renders as plain old black on the TV screen (and so is visually indistinguishable from other parts of the screen). See the image below, which is a screen grab from the game:
The area labeled below the active playing area is set to “bright black”. The above referenced code waits for the TV raster to reach the top of that area, and return flow back to the caller when that happens. Then, the game can start to redraw the screen, starting from the top, safe in the knowledge that game code will not cross with the raster and cause flickering or tearing. Ordinarily, program code can wait for the vertical blanking interrupt (typically using the HALT instruction on the Spectrum), but using the attribute waiting trick buys back a whole lot of extra time.
Chris’ site has a detailed discussion about the so called “floating bus”, which is the mechanism by which screen color attributes come to be on port 0x40ff. In my experimentation, I found that reading from port 0x40ff gave much more reliable results than other ports I tried. Chris’ site may shed some light on why that is (this address is in so called “contended” memory address space – memory that is accessed by both the ULA for screen updates and by the Z80 CPU). Perhaps the contention results in more “reliable” results when reading from that particular port?
Unfortunately, this trick is not very portable across the different ZX Spectrum models, being as it is “undocumented”. It’s also tricky to emulate, and the various ZX Spectrum emulators exhibit variable results in this area. Artifacts in the Sidewize game include flickering enemies and player weapon graphics (the walkthrough on YouTube suffers from these artifacts).
So I’ve ordered one of these.
It’s a ZX Spectrum clone built in the late 80’s / early 90’s in the ex-USSR (Ukraine). There were many ZX Spectrum clones manufactured unofficially in Russia, the particular example I have ordered (from eBay) is new, unused and sealed in its box.
It’s going to be a bit of an adventure to get this to display on a modern TV/monitor as it outputs a non-standard RGB + composite sync signal. In order to connect this to a modern (ish) VGA monitor, I’ve also ordered (from eBay, Amazon link below) one of these:
This board can take the low ~15Khz RGB signal in convert it to a VGA signal. None of this stuff has arrived yet, but I’ll post updates here later if I can get any of this to work.
I recently joined a Facebook group Z80 Assembly for the ZX Spectrum which, as its name suggests, is a group focused on Z80 assembly language coding for the ZX range of computers.
The group recently organized a couple of casual Z80 coding challenges, the first of which was to fill the ZX Spectrum screen with a checkerboard pattern:
Something simple for the first challenge. Write the shortest code to fill the screen with a chequerboard pattern of 1 pixel squares. No RAM, ROM other than the 6144 byte bitmap screen memory should be written to.
Target: under 25 bytes.
1. Your program shouldn’t rely on the initial contents of registers.
2. Programs must return. The RET instruction is included in the size.
3. So everyone has a fair chance comment with the code size not code.
4. There are no prizes, just the chance to show off your coding skill.
This yielded some interesting solutions, the winning examples of which are archived here on John Metcalf’s blog site. The winning solutions came in at 15 bytes (see link), I could only manage 16 bytes:
checker_speccy: ld hl,$5700
l0: dec l
The next challenge was to mirror the ZX Speccy screen:
Something slightly more complex this time. Write the shortest code to mirror the entire Sinclair Spectrum screen (256×192 pixels) left to right including the colours / attributes. The deadline is Monday 15th, midday (GMT).
Target: under 50 bytes.Your program shouldn’t rely on the initial contents of registers.
No RAM/ROM other than the screen memory should be written to.
Programs must return. The RET instruction is included in the size.
So everyone has a fair chance comment with the code size not code.
There are no prizes, just the chance to show off your coding skills.
The winning solutions are again archived on John Metcalf’s site. The winning solution came in at 34(!) bytes; my effort came in @ a reasonable 38 bytes:
mirror_speccy: ld hl,$57ff
The Z80 programming prowess demonstrated by the winning entries is pretty impressive. The spec for the second challenge was to come up with a solution in the smallest number of bytes (which is not typical for real world applications), and I think many of us were thrown by this. For example, in order to save one byte in one of the winning solutions, Introspec observed that while seeking to load an immediate value of 0x8 in the B register, he already had the value 0x58 in the H register; the genius observation here was that 0x58 would do just as nicely as 0x8 since all that the value was used for was a loop count, and that rotating some registers around 88 (0x58) times is merely 11 times slower than rotating the same values 8 times, but it saves one whole byte, which is a win in this case!
Not that this stuff is directly useful in my day job, but I am definitely learning some new tricks here.
As an aside, I downloaded the excellent (and free!) “Zeus” Z80 development IDE by Simon Brattel for this stuff. The download (Windows only, unfortunately, but works well in VMWare Fusion on my Mac) can be found here, along with numerous example files. Zeus comprises an editor, assembler, disassembler, Spectrum Emulator and debugger. Highly recommended.
Looking forward to more of these challenges!
The Indiegogo campaign to create a game-controllerified Speccy has been funded in 1 day!
As I write this, the crowd-funded project (to which Sir Clive Sinclair has lent his support) is sitting @ £110K, with the funding target @ £100K, which will fund 1,000 units.
Personally, my hopes were raised when I read about the project through social media links. The nitty gritty specifications are:
- Smaller than original Spectrum – “controller” sized for use two-handed as a controller.
- Has 4 direction keys plus another 5 keys of unknown function (presumably programmable somehow). The dead flesh keyboard of the original Spectrum has gone (though there is supposed to be an onscreen keyboard).
- Has composite video output only (no HDMI or other high quality video output). Video connector on the back of the unit.
- Is powered through a second connection on the back.
- No other expansion connectors.
- SD reader/writer built-in.
- 1,000 bundled games (though rights to these games are not yet secured).
- ARM based emulation of Spectrum functionality.
As I analyzed the specs however, I had a gradual sinking feeling. If the unit featured the following I’d be a lot more excited:
- Full keyboard (dropping the keyboard seems like a major shortcoming).
- HDMI connector (composite video in 2014?) Apparently HDMI is too expensive/complicated.
- Joystick connector (USB).
I’d even consider cracking open the old Z80 assembler if the device was more full featured. It’s not clear how you could do remote development for the device without more connections to the outside, for example. Copying files to SD would be a pain. Perhaps there’s a way hook up some sort of downloader. I suppose there are numerous ways to do Speccy development using emulators, but it’d be cool to have an easy to use real hardware target.
I’m not sure how this device is really any better than a Raspberry Pi , which would offer much more functionality at a fraction of the cost. Embed a Rasp Pi in a new case, done.
The crowd-sourced units are pretty expensive for what they are too – £100 each!
Having said all this, the crowd-sourced fundraising was very successful. There’s definitely a latent fondness for the old Spectrum machine, and this project seems to have ignited that.
Note: this article expands upon material I provided for the RetroGamer #129 article on Heartland.
In 1986, Odin Computer Graphics Ltd published the game “Heartland” for 8-bit platforms such as the Sinclair Spectrum, Commodore 64 and Amstrad CPC. Colin Grunes was responsible for art, level design & background lore. I did the coding on the Spectrum and Amstrad CPC versions, and contributed to gameplay design. Keith Robinson coded the Commodore 64 version.
Heartland development was commenced around the time of the Odin deal with TelecomSoft to create 10 new games, and Heartland was the first title released under that deal. As it happened, Odin moved office in the middle of development of Heartland, though it was not a very big move (it was across the courtyard in Canning Place to another unit – the old Bug Byte office, as it happens). The new office was much bigger – we needed the space for the additional developers we would hire for the TelecomSoft deal. The move was not unduly difficult, we just carried our gear over one afternoon. That building was demolished in the 90’s to make way for downtown redevelopment in Liverpool.
The catalyst for Heartland’s development occurred during the development of Robin of the Wood (on which Paul Salmon was the main artist). In that period, Colin Grunes (lead artist on Nodes of Yesod) was creating the initial walk cycle for the main Heartland character, the Hero Wizard Eldritch (otherwise known as Bertie, who’s full name may or may not have been Bertie Big Boy), in addition to other graphics ideas for backgrounds and some of the enemies. As soon as RotW was finished I began to experiment with dynamic mask generator code using the walk cycle. Before long, I had lots of Berties walking left and right on the screen using the masking technique, and this really gelled the visual direction for Heartland.
We tended not to do a lot of up-front design at Odin, not on details. So we would agree on the large stuff and then work out the details as we went along. Lots of things could drive the design, such as how many 16 pixel wide sprites would fit into a certain space (for the number of pages to collect), etc.
In terms of story development, Heartland was very much a collaborative effort. The graphics drove a lot of the back story, certainly, but ideas came from all around, as each idea came up, we’d discuss ways to integrate this or that idea into the game. I’m sure there were ideas from other developers, and from Paul McKenna (our Managing Director). It is likely that ideas came from Marc Wilding, Paul Salmon, Keith Robinson, Stuart Fotheringham and other founding members of Odin.
There are clearly elements of Nodes of Yesod and Robin of the Wood in the game, in that the game is in side view and is room based. The map is a lot less linear than either of those games, the screens being linked by portals going into and out of the screen, in addition to the screen flipping, elevators and staircases.. A few of the ideas I’d included in the much expanded Amstrad CPC version of Jet Set Willy made an appearance here too – the space section, for example, though that of course was also a nod to Nodes of Yesod.
Colin and I worked together very well. We had already collaborated on Nodes of Yesod, and after Heartland we worked on Sidewize and Crosswize together at Odin. We also later worked on an (ultimately abortive) Atari ST/Amiga game @ Denton Designs called Gargantuan. Heartland was the first time we worked directly together as a duo (Nodes was always more of a team effort).
On the art side, we had graphics for the first level very early on, along with the main Bertie sprites. The other graphics were developed in tandem with the game code and level editor that I created. Colin created all the pixel art in in Melbourne Draw, painstakingly using the Spectrum’s rubber keys, though there may have been some sketches. It’s amazing what could be done without a drawing tablet, or even a mouse! There was definitely collaboration on ideas for art, but Colin did the vast majority of the pixel work. Stuart “Stoo” Fotheringham did a bunch of the in-game plants, and maybe one or two other things. Colin did the loading screen, I remember him slaving away trying to get the attributes to line up with the hand and the planet! That said, Stoo did create several of the loading screens for other games at Odin/Thor.
Gerry Fisher did a fantastic job on the box art (on which the game’s loading screen is based) as usual. He did the Nodes of Yesod, Arc of Yesod and Robin of the Wood covers too.
Heartland was written from scratch (not based on Nodes of Yesod or Robin of the Wood) in Z80 assembly language. The code for the game was developed on a BBC Model B computer with the Z80 second processor running CPM. Under CPM we used the M80/L80 assembler/linker combination, and the Memo text editor. The Beebs had twin disk drives, so tools would run on one drive and game code would live on the other. In order to get code to the Spectrum, we’d use one of a variety of downloaders. At different times we used custom parallel and serial downloaders attached in various ways to the Spectrums (including Interface 1). Early on at Odin, some development had been attempted on Spectrums using MicroDrives, but this was quickly abandoned due to the unreliability of the Microdrive media.
The Beebs were really nice to use, though I seldom used the machine in actual BBC Micro mode. I think I might have spent a few hours playing Elite, having said that.
I developed a visual tool for level creation. It allowed Colin to design room layouts, and then move between the rooms. It could save and load data (I think we had disk drives for the Spectrums at this stage).
For Heartland I developed a graphical masking technique that was the cornerstone of the game – I wanted to be able to give a more solid feel to the sprites. In order to explain this, I’ll contrast how previous games drew their sprites. Bear in mind that the techniques here are pretty specific to what is essentially a 1 bit wide bitplane on the ZX Spectrum.
In Nodes of Yesod I used an “XOR” technique, which basically creates a “hole” where sprites or other graphical elements overlap. In a nutshell, the XOR (exclusive or) logical operation combines pixels as shown in the following image:
The XOR technique is efficient and easy to implement, and it has the benefit that in order to erase a sprite, you just draw it again in the same position! So, there’s no need to keep track of which parts of the screen have changes. You’ll notice that in Nodes of Yesod, things seldom overlap for very long. This is in part to avoid seeing holes where things overlap.
In Robin of the Wood, I used an “OR” technique, which results in a slightly more solid feel when sprites overlap each other. Combining pixels using OR looks like this:
This explains the lack of “holes” contained in the image when sprites overlap. The downside to this technique is that it is not in itself “self erasing”, and it takes more programming effort, and more CPU cycles (in general) to keep the screen updated. It is also more difficult to discern foreground details from the background.
For Robin of the Wood, I kept a list of “dirty rectangles” so that instead of redrawing the entire screen I could just redraw those parts that changed. Again, more CPU cycles and additional complexity are introduced in this approach.
In RotW, things are allowed to overlap more than in Nodes of Yesod. This is because the OR technique is not as visually distracting as the XOR technique.
AND & OR Mask Technique
In Heartland I used a “mask” approach, which essentially uses a “cookie cutter” to remove all pixels behind each sprite. Usually this cookie cutter has a larger area than the actual sprite, resulting in a (typically) black border around the sprites, and solid black areas in the inner part of the sprite. The cookie cutter mask is applied before drawing the sprite, using and AND approach, the result looks like this:
You can clearly see that one of the elements is supposed to be in front of the other. By creating a cookie cutter “AND” mask, you can clear space behind each sprite in which to draw it. Drawing of the actual sprite is then accomplished using the OR approach.
This technique is quite effective in producing more solid looking graphics, but it has a couple of drawbacks. For one, more CPU cycles are needed to draw each sprite (since you have to “cookie cut” a hole for every sprite); additionally, storing this mask for every pixel doubles (on the ZX Spectrum) the amount of memory needed to store each sprite. The main problem in Heartland was fitting everything into memory (it was a single load game), and this is where the “dynamic mask” approach came in. To do this, every sprite and “prop” in the game was stored without a mask. In order to generate the mask dynamically, at level initialization time each graphic was shifted one pixel left, one pixel right, one pixel up and one pixel down. These resulting images were then combined together to create an image “fatter” than the original, and then this image was inverted to become the mask. The following images shows this visually:
The technique of generating the masks worked pretty well. Occasionally, there’d be a “hole” in the mask if more than a 3 pixel gap existed in the original art, but it was usually a quick job for Colin to fix up the error.
Music & Audio
Keith Tinman did the music, I did the sound effects, such as they were. The music player was an evolution of previous code that we’d used in Robin of the Woods, and that player was written by Andy Walker and I. It was a 2 channel player that made use of the fact that the Spectrum beeper could actually output three levels (essentially zero volume, ear bit, mic bit), so you could play two notes at once by careful bit toggling. We didn’t really have a good way of transcribing music from musical keyboard to the game, so there was lots of manual data entry involved.
As I mentioned earlier, Heartland was the first full game to be delivered under the agreement between Odin and Telecomsoft, in fact it was probably one of the reasons the deal was signed in the first place. There was certainly pressure to complete games once the deal was signed, as we were supposed to completed 10 games inside of 1 year.
We actually hired a bunch of people to help develop those 10 titles (I did 2.5 of them, with Heartland Speccy, Heartland CPC and Sidewize), but it was hard to maintain quality and pace of development with the new hires. Frankly, there wasn’t enough management experience at Odin, and what had worked for one or two concurrent titles just didn’t scale well to 10 titles in a year. Doing so many titles in a year definitely drove down the quality of the games.
As far as I remember TelecomSoft had very little input on the creative direction for Heartland, they had some approvals, but generally left us to get on with it. They did start to take rather more of an interest in things as we approached the end of the 12 month period as it became clear that Odin was having difficulty delivering the agreed upon number of games. There were several visits during that period.
C64 & Amstrad Versions
I did the Amstrad CPC ports (both the cassette version and the disk version), and I had a lot of fun with that. I used mode 0 on the Amstrad, which gave the game a chunky, but very colorful look. I worked from home for a few weeks during this work, and it was a very productive time. The Amstrad version came together very quickly.
Colin created the mode 0 art, and even though the screen aspect ratio was different on the CPC, I made all the existing room layouts work OK with minimal changes (much to Colin’s relief!)
The music on the CPC version is derived directly from the Spectrum version. The Spectrum beeper track has 2 channels, so to fill out the sound for the CPC on the 3-channel AY chip I simply doubled up the lead line, detuning one of the channels by a small amount to give a “chorus” or “phasing” effect.
I had very little involvement with the C64 version of the game, other than some input on the data structures and graphics organization, and then to answer any questions that came up with the code. The C64 version was coded by Keith Robinson, and work started on the game after the Spectrum game was underway.
While the working title for the game was “Kimera”, it turned out that there was another game by a similar name (Chimera), so the name Heartland was selected for the final game. By the way, Heartland is the name of a Sisters of Mercy song, and the lead singer of the Sisters of Mercy is Andrew Eldritch.
Other random trivia. After Odin had closed, Colin and I pitched a game called Heart of Yesod around to a few publishers. This was to be an Amiga and Atari ST game that brought the worlds of Nodes of Yesod and Heartland together. It was something like Nodes of Yesod meets Heartland by way of Narnia (there was a wardrobe involved) and Mr Ben. I have a copy of the typewritten backstory doc around here somewhere, but perhaps needless to say, that game did not get funded.
There are a couple of things I would do differently if I could do it over again. First, the mechanic for going through doorways is really fiddly! Should have just used two keys, one for “into screen” and one for “out”. More importantly, I wish there were platforms in the games. All action occurs at ground level, and you effectively play out a big maze. Platforms would have allowed us to create more puzzles, and opened up the game world somewhat.
Thanks to Colin’s art, Heartland is a very pretty looking game. As I mentioned above, certain aspects of the control scheme seem overly fiddly to my 2014 eyes, and I wish the game had more of a platform aspect to it, but overall I am reasonably happy with it. I especially like the Amstrad CPC versions of the game – the frame rate is higher and the game is more colorful there.
A couple of videos below that should be pretty interesting for fans of the good old ZX Spectrum. These are the first two parts in a series, with more major modifications (including making a portable Speccy) coming. Enjoy!
Updated Sunday August 24 2014: post updated with all three parts of the portable Speccy project. Disappointing that we don’t actually see more of the finished project. Kind of amazing that it works at all! Cool stuff though.
This may possibly jog a memory for Sheffield folk who went to school in the 70’s.
Where’s United gone – to division one!
Where’s United gone – to division one!
Far, far away
Far, far away
Where’s Wednesday gone – down the River Don!
Where’s Wednesday gone – down the River Don!
Far, far away
Far, far away