Jump to content

Most Liked Content

#855 Willy in 3D

Posted by ZedEighty on 22 November 2015 - 12:28 PM

Hallo Everyone! 


I was directed here by Stuart Brady on the Spectrum 4 Ever Facebook group. I've been dabbling with 3D printed models and have designed a few based on characters from Matthew Smiths' classics. After I posted some pics on FB Stuart suggested that you folks here may also like to see what I've made:












The models are printed in laser-sintered nylon, and are about 4 cm tall. The non-white model parts have been dyed. I designed the 3D models myself, and had them printed by Shapeways.


David :-)

#12004 Playing around.

Posted by Norman Sword on 30 May 2020 - 04:46 PM

Back to the theme of playing around.



I wrote the screen copy basics, when I was showing how I would display Perils of Willy. 


Those screen copy basics were modified into JSW128 VL demo . And expanded again in JSW128VM


Using the screen copy routine that was eventually written for JSW128VM. I expanded the data and added some sprites. I designed and wrote a sprite draw routine, and then added my own sprite movement routines. I then added keyboard routines and fleshed it out with a game control part. All this code is new. It was at this point a few days down the line, that I encountered a major problem in the design of the overall program. Up to this point the movement of graphics and the speed of screen update was ok. However as I added more and more routines it became very noticeable that the stack copy was having a serious problem with regards how it updated the screen. The bigger screen was introducing a phase lag across one raster line and only one raster line. The Glitch this introduced had not been noticed before, and once it was noticed i could not carry on and leave it. At first I puzzled over the nature of the glitch, but eventually I worked out the exact nature of what the problem was. The extra size of the screen was just enough to render the method used as unworkable as far as I was concerned.


I wrote several differing versions of the stack copy, and the problem would seemingly not go away with the fastest methods I could write. The problem was not speed but the method of implementation. I could cast aside the method I was using and write a bigger routine that used more data. Or use a true raster line stack copy via the Ytable. The problems become the negation of speed with repeated look ups of data or the vast amount of data and space needed for rolled out stack copies - None of these were to me an option.

So after about four/five days from the start of doing these routines and having a working couple of rooms to play. I contemplated pulling the plug. The glitch that I was seeing was not acceptable to me. The update method had a serious flaw, and I was struggling to overcome this flaw.



By the end of the first week, I was about to give up.



I decided to scrap the method I was using. My assembler was now littered with dozens of switches and options that implemented various differing methods of stack copy. I tried a new method and copied a lot of macros across and changed the basic method I was implementing. It seemed like every other block of code I had written. I knew the method was not as fast. Yet when I assembled the code and ran it. The glitch had gone. Which proved it was the method implemented originally that was wrong and all the updates and changes could and did not fix it.



I added a few more rooms and then added game control. By the end of the 2nd week I had more or less what is seen in these demo's.

What I have done in the weeks since is refine the code and re-write some of the routines. In some ways I wish I had not written every routine from scratch. It was just easier to say to myself, what do I want. Then write the routine. It seemed pointless using someone else's code that did not do what I wanted. As an example:- name a version of JSW that permits sprites to cross the background. The only answers that I am aware of are JSW2 and JSW2+, the third answer is JSW128VM.  I knew from JSW128VM that it was not an easy change. And I also knew from JSW128Vm that the changes in that version did not go far enough. The whole sprite usage in JSW2 and JSW2+ was sufficiently different, that I could ignore that. 


So in the end it was just quicker to write all my own routines.

The stoppage at this point concerns implementation of Music. Not something I can do. I can write any number of music routines and play the music in my own routines. But I do need a simple file to implement the music as data, along the lines of    O3fs,o3e,o3e,o3f,o3a


Which reads as Octave 3 F sharp, octave 3 E, octave 3 E, Octave 3 F and finally octave 3 A.


Given a music score in the fashion written above I can happily write the music routine. 




Asking me to write this file myself is not going to happen soon.



#11559 Hello!

Posted by geoff on 01 February 2020 - 11:11 AM

I don't know if this is the right place to put this, but never mind. I'm the author of, among other things, "Willy Takes a Trip" and "ZX Willy the Bug Slayer", and I've come to join this community. Hello to you all!


Note: For various complicated reasons, it'd be good if you don't mention my surname here.

#6997 A total rewrite of JSW in 48k using Matthews core code

Posted by Norman Sword on 07 September 2017 - 02:21 PM

I have resurrected this file By Derrick.P.Rowson. Which was on a crashed hard drive. 


This is Not finished, and never will be due to a catastrophic failure of the hard drive.

This is a few weeks work and alas there was no backup of the program.


This version does not have any of the new logic playing sprites.

E.g. sprites that followed willy around both vertically and horizontally, and were free roaming around the screen.

The logic had enough sense to move the sprite wherever it needed.



This version was a development towards having the full Manic Miner + Jet Set Willy in 48k




This game has inbuilt options. (password protected)

Attached Files

#5299 The AND, OR and XOR instructions

Posted by SkoolKid on 12 November 2016 - 03:01 PM

Is there any good reason (e.g. in terms of the effect on the Flags, perhaps?) why the original game engine uses an XOR command at #91FB, instead of an OR?


It's the instruction which merges a guardian's INK colour and BRIGHT value (Bits 0-2 and 6) with the PAPER colour (Bits 3-5) of its host cells.

No, there's particular reason to use XOR instead of OR here. As you've noted, there's no difference in the resulting value in the A register, and there's also no difference in the effect on the flags (which are not checked anyway).

#5007 Atari ST ( JSW )

Posted by SedricAndCharlie on 14 August 2016 - 10:22 AM

I wonder at what point Software Projects changed their mind and commissioned the Stephen McMaster MM/JSW games for the Amiga? Also this led me to reading about Boing! on the C64, the rejected Chris Lancaster conversion of JSW that was passed onto Bubble Bus Software and reworked to avoid copyright. Seems like Software Projects had a lot of odd stuff happening behind the scenes

#4947 Free space and code optimisation in "JSW"

Posted by IRF on 04 August 2016 - 10:35 AM

I'm probably missing the point here but why not just compress the entire code? I know people here are not a big fan of compression as it makes the code harder to read like with JSW2 for example but is that not because there is no decompressor available making editing a lot harder?

but what if you was the one doing all the compressing? might it be easier to edit the code then compress and decompress at will .. imagine the extra rooms and nasties you could cram in using the original JSW engine...

just a thought that's all

I suppose that's one option.

However, I've considered it a nice challenge to find 'efficiencies' in the existing code and therefore try and pack as much into the available space as possible, without compression.

And if nothing else, taking on the task has helped me get my head around how the Z80 machine code works. (I was clueless just a few months ago!!) :wacko:

#4706 Free space and code optimisation in "JSW"

Posted by JohnElliott on 20 June 2016 - 06:41 PM

However, I've just had a look in JSWED, in the Game tab, and it looks like both of these boxes (as well as *all* of the other ones *except* for "Black Willy") *cannot* be either ticked or unticked - they are filled with blue, sort of. I'm not quite sure how to interpret this...


It means that at least one byte in a location touched by the patch is neither the original one from JSW, nor the modified one from the patch. So JSWED cannot safely apply or deapply the patch.

#4654 Complete List of bugs, quirks and anomalies

Posted by IRF on 13 June 2016 - 09:39 PM

Willy enters the 'toilet dash' as soon as he reaches the foot of the bed, regardless of whether he walks or jumps to reach that point.

His getting stuck on the bed is caused by the bed's Conveyor action 'cancelling out' Willy's automatic urge to run rightwards (there's an XOR command involved).  The fact that the 'P' key doesn't release him from this predicament is probably a 'bug' (although Danny might disagree!).

I guess the pillow is a Fire cell because there were no other cell types available when Matt Smith designed the room!

#4605 Complete List of bugs, quirks and anomalies

Posted by Metalmickey on 08 June 2016 - 12:15 AM

Firstly, apologies if a similar topic like this has already been created elsewhere feel free to delete it if there is a better one, i did have a look around and couldn't really find anything like it so i thought i'd create a thread where everyone can contribute to the list of all known oddities found in the game.


Secondly this is not a request for help in working around these bugs, more really a point of reference and maybe a source of information for newcomers and those who didn't play the game so much and don't already know about them all and one single place where they can be looked up


I thought i might start with the most obvious and well documented ones the first four of which prevent the game from being completed:


'The Attic' - The most famous and destructive of them all which of course is triggered when Willy ventures into the attic. A rogue arrow causes all manner of destruction around his house and ultimately renders the game unplayable.


'Conservatory Roof' which features the booby-trapped item, or maybe it's just a little too closely guarded by a 'fire-cell' 


'The Banyan Tree' with what looks like an out of place earth-cell right of the trunk meaning that Willy cannot make his way upwards to the Bit Of Tree above


'First Landing' with the phantom object which is neither seen nor collectible.


The rest of these are comparatively harmless or can be avoided

such as...


'The Nightmare Room' featuring the ugly green blob which, when i first encountered it i thought it was a fire-cell and so i spent many a long afternoon trying to work out how to collect the object without hitting it... turns out that it was just a conveyor belt ... who knew?


'Cuckoo's Nest' with the somewhat disorientated saw that doesn't change direction when it comes back the other way


'Under The Roof' with the phantom 'fire-cells' that prevent Willy from dropping out of the bottom of the screen to the right of the tree trunk, interestingly enough this one was even left in the 'Nightmare Edition' ... maybe Mr Smith deliberately left it there... who knows?


'The Beach' and 'The Roof' both feature a rope that Willy can jump from and reappear at the bottom of the screen


'Rescue Esmeralda' has, in all probability, an unintentional secret passage to 'Ballroom East' when jumping from the conveyor belt at the top right of the screen


'The Watchtower' also has one which takes Willy all the way to the 'Off Licence'


'The Swimming Pool' has an object which Willy needs to make no effort whatsoever to collect, he merely needs to enter the room and it's his


'The Orangery' Here Willy has been endowed with a magnetic head when jumping up and hitting the ledge from the stairs at the bottom left of the screen - not so much a bug, more of a quirk

Apparently i never knew this but there is also a bug which means that the conveyors in rooms such as the West of Kitchen and Tool Shed are not drawn properly .. and the one in the Wine Cellar is not supposed to be there at all.


Finally there's that 'halo' effect where a nasty as a 'bright' blue background following it around, this is evident in 'I'm sure I've Seen This Before', the Emergency Generator and On A Branch Over The Drive


There's probably a few that i have missed, feel free to contribute!

#3137 Pokes for Fixing the Cell Graphics Bug in JSW

Posted by IRF on 25 February 2016 - 11:51 AM

I thought it would be good to have a standalone topic for easy reference, containing the Pokes in Hex (EDIT: and in Decimal) that fix the Cell Graphics Bug.  The credit for most of these goes to Stuart Brady (AKA Zub), although I had a bit of input into fixing the ramp/conveyor pixel patterns and conveyor attribute byte in The Nightmare Room.


I'm not sure if this should be in the 'Remakes' section of the forum or elsewhere; I can relocated it if necessary.  However, I thought this might be the best place as it is highly advisable for anyone developing a game/remake using the JSW game engine to apply these Pokes, to prevent their intended cell graphics from being corrupted in an erratic manner!


The Cell Graphics Bug fix (a generic patch to the game engine) is achieved using the following sixteen Pokes:


POKE 8d54, 06

POKE 8d55, 06

POKE 8d56, cd

POKE 8d57, bb

POKE 8d58, 93

POKE 8d59, 59


POKE 93bb, 11

POKE 93bc, 08

POKE 93bd, 00

POKE 93be, be

POKE 93bf, 23

POKE 93c0, c8

POKE 93c1, 19

POKE 93c2, 10

POKE 93c3, fa

POKE 93c4, c9


EDIT: The above, in decimal:


POKE 36180, 6

POKE 36181, 6

POKE 36182, 205

POKE 36183, 187

POKE 36184, 147

POKE 36185, 89


POKE 37819, 17

POKE 37820, 8

POKE 37821, 0

POKE 37822, 190

POKE 37823, 35

POKE 37824, 200

POKE 37825, 25

POKE 37826, 16

POKE 37827, 250

POKE 37828, 201


An additional fix, specific to The Nightmare Room (where we believe Matthew Smith's intended attribute byte for the conveyor was misplaced in the code, as the bottom pixel row of the ramp cells; this had a knock-on effect on the colour scheme and pixel pattern of the conveyor, even with the Cell Graphics Bug fix in place), can be achieved using the following five Pokes:


POKE ddcc, ff

POKE ddcd, 02

POKE ddce, a5

POKE ddcf, ff

POKE ddd0, 5a


EDIT: The above, in decimal:


POKE 56780, 255

POKE 56781, 2

POKE 56782, 165

POKE 56783, 255

POKE 56784, 90

#2 Welcome

Posted by Spider on 09 August 2014 - 06:17 PM

Welcome! :)


This site is not intended to take any traffic away from other existing sites, its simply a place we have to discuss the range of JetSet Willy and Manic Miner games. Its fair to say these games have stood the test of time very well even now.


Although primarily aimed at the Spectrum versions, we welcome any contributions and thoughts on other platform variants of these games too, both standard and edited.


Feedback (both good and bad!) and suggestions are always appreciated, simply start a new topic in this area (News/Feedback) if you have any comments to provide.


Thank you!

#12154 Playing around.

Posted by Spider on 28 June 2020 - 02:00 PM

That's quite excellent. :)


It does work quite well and add atmosphere to the game. Some credit must go to Pgyuri for the idea initially but I can perhaps foresee this general principle being good for various third party games.


Regarding JSW, I do agree its not terribly ideal however certain screens could possibly use it, perhaps something like WineCellar or other potentially 'dimly lit' areas. Does pose a slight quandary there with if he should have a miner's lamp/helmet or be carrying a torch of somekind but I guess that is something for a different topic.


My other feedback I'd posted previously (not as a hint in any way merely a thought regarding blue/black background area) was if M.W has 'seen' an area it should then remain in blue afterwards, by this I mean the cavern starts as black aside from the area lit by his lamp, but once he's 'seen' an area but left it, it goes to blue.

#12153 Playing around.

Posted by Norman Sword on 28 June 2020 - 01:54 PM

An addendum to the above file - directional beam --- I mentioned it --- so I then needed to do it.

Directional beams of light.




looking left and looking right - when in a normal blue background room

Attached Files

#12144 [File] Manic Miner - DarkLight Modification

Posted by Richard Hallas on 24 June 2020 - 10:26 AM

I really like these mods!

Gloomy Cavern restores the difficulty to being the same as the unmodified Manic Miner… so the new lighting effect ends up being purely cosmetic. However, it looks really good, and I almost like the game better this way… it certainly refreshes it a bit, after nearly 40 years!


As for the original mod with just a small area around Willy visible… this is a really exciting and hard core mode for experienced players. I quite enjoyed it after I'd got used to it in the Central Cavern… but overall I felt that it would be better if Willy could see further ahead.


I wonder… how feasible would it be to extend the visible area by one or two character spaces both ahead and above? And/or make the last visible square above/ahead appear in blue on black, to give a sort of 'light fading away' effect? At the moment the full colour just stops; it would be nice if there could be an extra square in blue on black (either just ahead and above or even all around) to indicate the fading edge of the light.


Anyone up for the challenge?  ;)


A final thought… if anyone did fancy attempting the blue-on-black light-fading-away 'halo' around the visible area, it might be quite nice if the four corners of the visible area could be changed to blue on black and then the sides between them made into this colour scheme, but one character space further away. That would produce a more 'circular' effect for the lit area, which I think would look better. At present, the light is cast in a square, whereas in order to be authentic, it ought to be more of a circle, really.

#11906 Willy versus the Coronavirus

Posted by andrewbroad on 18 April 2020 - 10:28 PM

My local Co-op is getting increasingly bizarre, with its one-out, one-in guard, physical-distancing lines, and windows at the checkouts.

Now it has implemented a one-way system for walking round the shop, and closed some of the openings between the aisles. I felt like I was playing a cross between Pacman and Manic Miner!

#11778 Manic Miner in 48k with 40 rooms

Posted by IRF on 18 March 2020 - 03:03 PM

I just tried out cavern 23 - it's a great, multi-faceted puzzle!

#11668 Hello! I'll be back for a while.

Posted by Korzy_iz_Adbán on 02 March 2020 - 06:49 AM

Thanks to Jet Set Danny, I am going to be back for a while.


It's good to be back here.


Hugs to all of you from Spain.

#11394 JSW's 35th birthday party at Manchester PLAY Expo

Posted by Richard Hallas on 24 October 2019 - 08:25 PM

I've just belatedly noticed this thread, so as one of the people who was there, I thought I'd say a few things from my own perspective, particularly about the competition.

Danny is correct that my "Join the Jet-Set!" came second in the competition, after "Maria vs Some Bastards".

As for the competition itself, I had very mixed feelings about it. On the one hand, I was pleased to have one of my games picked at all; that in itself was a real honour, considering the sheer number of JSW games developed, and also considering that mine is one of the very oldest, having been completed back in 1985.

But on the other hand, the way the competition was presented and run was simply not fair on any level. What was the criterion on which the games were supposed to be judged? How they played? How they looked? How much they stretched the JSW engine in terms of quirky exploits or new routines etc.? Having a competition for which one is "best" is actually pretty meaningless. The only criterion that the audience was permitted to judge, really, was how the games looked – based on the 30-second visual run-through that each one got.

That's the most superficial way possible of judging the games, and even then it wasn't a fair comparison because we weren't comparing 'like with like'. Of the five games being judged, four were pretty straightforward JSW games that looked much like the original JSW and played in the same way. But the fifth, Maria vs Some Bastards, is much the most recent of the set and has been MASSIVELY hacked about to allow the game engine to do all kinds of things it was never supposed to do. The end result is that it has big, bold, spectacular graphics that none of the other games could achieve, and it totally outclasses the competition in terms of looks. But no-one can actually do what that game does with the game engine without a massive amount of hacking; you can't achieve those graphics just by creating a new JSW game with an editor.

So, the audience was asked to judge which of the new games appeared to be the best, based on a brief, superficial viewing of a few screens, yet what they were shown was four 'normal' JSW clones and one super-enhanced on that featured a massively rewritten engine that permitted all sorts of big, bold, cartoony graphics to be used. So *obviously* Maria vs Some Bastards won; there was really no other possible outcome, under the circumstances. Maria vs Some Bastards was written 18 years after Join the Jet-Set! was released, so it's hardly surprising that there'd been plenty of time in those 18 years to do a lot of hacking and find ways to make it look better! Is it really fair to compare a game that's barely been hacked at all (in terms of its engine) with one written two decades later and hacked massively?

I'm not being a sore loser, honestly! I'm just pointing out that it wasn't a fair competition. None of the other four games stood a chance. It was also unfair that the presenter, as he ran through the five candidates, made sure the audience knew which was his own favourite in the set (it was neither mine nor the actual winner, so at least it didn't influence the audience too much).

I don't begrudge Maria vs Some Bastards winning in terms of the effort that's gone into creating it, because it's actually a pretty remarkable game and a lot of work and talent has gone into its creation. I just didn't think it was fair to put that particular game alongside other 'normal' JSW games that didn't stand a chance because they hadn't been totally rewritten in the same way. Besides, if the games could actually have been judged in terms of how successful they are *as games* (i.e. in terms of being fun to play), then I think my own game might even have won. The point is that I deliberately designed it to ( a ) recapture some of the whimsical humour of the original, ( b ) be fun to play, ( c ) be interesting and fairly easy to explore, and ( d ) above all, to be fair. The latter point means that (i) active steps were taken in the design to avoid death loops, (ii) there are few nasty traps (there are a couple, but it's easy to learn where they are and avoid them), and (iii) the game can be completed without losing even a single life if you're skilful. I've always believed in fairness, and my game is fair and completable. That puts it in stark contrast with most (all?) of the other entries, which range from weird and unpredictable to impossible to complete. Maria vs Some Bastards is impossible to complete without a third party hack (released in the same week as this competition!).

On a positive note, I was given the microphone and was allowed to talk through my own game as it was demonstrated on the screen, which was nice. That permitted me to mention a couple of important points about it, namely ( a ) it was one of the very first new JSW games that demonstrated that it was possible to recapture something of the spirit of the original in a new setting, and thus played a significant part in kickstarting the surge of enthusiasm for creating new JSW games, which arose after my two games and Adam Britton's three had been released in the 1990s; and ( b ) I was the first person to figure out how to reprogram the in-game music and offer new tunes in my games.

Looking back at my own game, and having played it again recently because of this competition, I can see various ways in which I could have made a better job of it, and there are certain things I wish I'd done. E.g. I should have been less half-hearted about redesigning Matthew Smith's guardian graphics and drawn more of my own original creations; and I should have animated some of them better and not made them so 'jumpy'. Maybe I should have redesigned more room graphics too (i.e. walls, floors etc.). And so on. Considering all the other games that have come since, and all the engine enhancements, it's shown me just how ingenious some people can be with this game and made me feel that maybe I cut a few corners that I shouldn't have done. But to be fair to myself, I was only a 15-year-old schoolboy when I wrote it (amazing how some of those memories are still quite fresh, 35 years later…!), and I had lots of other commitments at the time, and very little free time of my own… so actually, I do think I managed to make it a pretty good game under the circumstances. Anyway, it was good enough to inspire others to make many more games of their own, so I'm pleased about that, and if I was indeed partially responsible (through my two games) for helping to kickstart the JSW revival then I'm delighted about that. In the end, whilst I'd have like to have won the competition, under the circumstances, coming second was the best I could hope for, and I was actually pretty happy with that. My game is by fair the earliest of the set in the competition and maybe it looks primitive. I do happen to think that it's the only one of the five that's really genuinely fun to play, but that's not something that can be ascertained from a casual 30-second viewing! So coming second was really pretty good.

I did meet Matthew Smith at the end – all too briefly. He was very pleasant and friendly, and I'd have liked longer to talk to him. He seemed genuinely interested in my game, and gave the impression that he'd actually played it – he tried to ask me about how I'd created it, but unfortunately we got distracted by other people and never really had chance to get into a proper conversation. What he did say was that he thought it was "definitely one of the better remakes", which I found flattering.

So anyway, overall I had a very nice time. I hope I don't seem to be whingeing in what I say above; it doesn't really matter to me that my game didn't win. I was just a little disappointed that the competition wasn't fairer, and that the odds were stacked so unevenly, because I do think that if one is going to have a competition, it should be fair. But that's just me.

Basically I had a great day. It was a genuine honour to have my game picked for the competition (and I found it installed on three of the machines in the main hall where you could play retro-games, which was also flattering) – and of course it was a privilege to meet Matthew Smith (something I never thought would happen). I also enjoyed meeting Martyn Carroll and Paul Drury… and, in particular, Daniel Gromann. Danny was kind enough to take a number of photos of me with Matthew Smith, and then he walked me back to the railway station after the event, so that we could chat further. It was great to meet him.

By the way, a video of the whole presentation was indeed made and was put online somewhere. I no longer know where it is/was, but I downloaded a copy to keep myself.

#10301 New MM version for the Atari ST (preview)

Posted by Norman Sword on 03 November 2018 - 11:22 PM

Looks great, but I see problems in how you have animated Willy.

The picture shows the four phases of Willy along the top (original)

The middle row shows the four phases as far as I can tell from your version (These are poorly scaled screen grabs)

The lower row is how I would correct the the animation. E.g. by editing the 2nd phase of animation.

The problem that I see, is caused by Willies hands not seeming to cross over the side of willies body.


Attached Files