Spider

Preference is fine, each to their own. For what it is worth (I don't think I've posted this before) I saw / played JSW at least a few months before I saw Manic Miner, so my 'starting experience' with it was not the right way around as such. :lol: The article it was more a kind of short bit as I say, more or less 'modern' players do not expect such 'instant death' or if they do some kind of save point (we have snapshots these days in emulators) and 'back then' devices such as Multiface or Interface3 (if you could find one!) would save a snapshot to tape as well as the Disciple and +D interfaces which if memory serves could also save a snapshot but to disk too. These were quite expensive back in then though as you may recall. Talking of robustness, cartridge based games fall into this category, as the code is read only they can't break it. Although the hardware itself is quite vulnerable to damage such as removing a cartridge while powered can cause damage. Only a small handful of official ones were released and they were all 16K games, they are very expensive now to obtain. Shame as I recall seeing them for about 14.99 back then. With this in mind its possible now to have larger games on a cartridge via a slightly different interface (instead of Interface 2 or Ram Turbo) and a different cartridge rom design although its potentially a DIY project. I can provide details on any of the above if you want, I've purposely skimmed on said detail to keep the post readable. :D Basic type ins, these days quite a lot are 'ready available' as tape files anyway thankfully. I do recall typing in quite a large number of them back then although ones that were full of hex data were something I avoided, it does (these days) seem quite odd to look at three or more pages of data and think "30 years ago I would of typed this in" :o :)

:) Yes the pokes would silence the 'in game' tune permanently although they would not turn off the other in game effects such as 'falling' or 'fatal accident' effects. I'd not say "rubbish old game" though personally ;) It was really one of the best early platform games around which launched a whole host of other games... There was a school of thought on this I read a few months ago about what was termed if I remember correctly "Manic Miner Syndrome" in that the 'small people' who were only used to modern consoles and save points etc, could not deal with MM, they would for instance walk into a fatal fire cell such as a green plant, and then do it again. Fair enough the first time but then surely you'd 'remember' not to do it again ? :unsure: I'm unable to find said article at the moment although it was only a paragraph or two. I think it points out how forgiving (relatively) modern games are in some ways. Having said that its far far easier to modify or alter an older game in most cases to fix things or change/amend anything compared to a newer game where there is no editor available, depends on how said new game was constructed though I guess partly. :)

I've not used that assembler. :) I'm not sure (as above) if you can generate it in an easily extractable form with skoolkit, however I can generate an .asm file for you via ZXBlockEditor and then ZXAssasembler if needed, or you could download and use these yourself if you prefer a more DIY method. ZXBE will allow you to export the data block as a binary file (so will lots of other tools to be fair) however you have the option if ZXA is present of sending it straight to that, and then from there you can edit *or* just export as a straightforward conventional .asm file. If you want to save a bit of time etc I'll create the .asm for you but I'd need to know exactly which file you want it made from as such as there are variations, for instance the pre-release vs the normal release and then the later compilation release. To be fair the main difference here is the in-game tune as the pre-release uses "In the hall of the Mountain King" (Manic Miner in-game tune) and the normal release uses "If I was a rich man" although strangely the compilation release (the one that's speedlock protected) uses the earlier tune, and has a keypad bypass of sorts plus the 'official' bug fixes. Summary being if you want a quick ready to use .asm I'll get one but I need to know the exact file (link if possible) you'd want it creating from. Ideally it needs to be a tape file, .tap , .tzx etc although I can work from a snapshot such as .z80 or .sna if needed.

Not sure if you can do that with skoolkit. :unsure: Do you have an assembler you wanted to use ? I'm only asking as its quite esay to turn either of them into an .asm file... which you can then insert into some assemblers and adjust as required. For small scale edits to be honest I just fire up ZXSpin emulator and use that's built in debugger as it permits editing of code directly. Its quicker and easier than starting an assembly session. :)

I've added the POKES to change 'code' vs 'Code' now either way. :)

Well if you would call them that. :) First of all let us ignore room names that are not centred properly aka "Halfway up the East Wall" and "A bit of tree" amongst a few others are both too far leftwards. A few are too far rightwards too. Of room names though: 1. Room 51 / #33 "Tool Shed" has two spaces between the words instead of one. 2. Room 54 / #36 "West Wing" has two spaces between the words instead of one. When I looked again at the keypad 'bright vs not bright' issue (see here if needed) for something unrelated it brought my attention to the code wording itself. Lets take a closer look, ignore the fact the code is showing "--" this is simply so the same one is shown for each screenshot to keep it simple: "Enter Code at grid location" "Sorry, try code at location" Notice "code" is capitalised on the first but not the second. I'm not 100% sure which is grammatically correct though. Not shown in screenshots however to 'fix' this either way: POKE 34193 , 99 (#8591 , #63) to change the "C" in the first message to a lower-case "c" or to go the other way instead POKE 34230 , 67 (#85B6 , #43) to change the "c" in the second message to an upper-case "C" Also, look at the screenshots here, there is a potential spacing issue too. :) Note that the code entry ID requested has a space between itself and the end of the screen but the text is set to the far left. Either something like a colon needs adding... To do this: POKE 34214 , 58 (#85A6 , #3A) for the first message and POKE 34246 , 58 (#85C6 , #3A) for the second. ... perhaps a simpler, tidier fix is to just move the text along one character instead to make it sit 'neatly' instead. I think I prefer this method: To do this: POKE 34500 , 1 (#86C4 , #01) This changes the LD DE, 18432 to LD DE, 18433 (#4800 to #4801) which the display file address to display the message, in Basic its "PRINT AT 8,0 vs PRINT AT 8,1" In theory the length specified that follows that: LD C,32 (#20) reducing down to 31 (#1F) to prevent overspill onto the next line however this is not essential as its not 'seen' and the last few characters are blank in the message so you are only printing a blank character (ascii 32 / #20) onto a blank space aka: no effect. The length could be reduced by a few characters even with no other changes as the last character blocks on that line are overwritten by the code specified to input anyway.

To expand on IRF's post a bit, here are some links to assist. Bear in mind this relates to the Spectrum version of these games: JSW Disassembly Decimal or Hexadecimal MM Disassembly Decimal or Hexadecimal There are downloads of these for those who prefer to study them offline. I keep a local copy of them to look at, its worth checking for updates occasionally too. One additional point to bear in mind the MM ones are based on the Bug-Byte version which seems to be the most common/popular one. The other variants of it such as the later original Software Projects release, the M.A.D (Mastertronic) and Ventamatic re-releases are slightly different. The re-releases are based on the Software Projects version. Simple way of putting it: Out of the four 'commercial releases' there are two code versions: The Bug-Byte version and 'all the others' as such. The changes are not difficult to work around, in summary a few sprites are different, the cheat code is different and code between about 33902 and 33718 is in a slightly different place, its typically only a few bytes 'away from where you would see it' in the disassembly though. John Elliott's page explains it quite well here too. I think I've seen a partial one of the BBC version too possibly on JGH's site but I'm unable to locate said listing at the moment.

Most welcome. :) There is also the simple ability in about 95% of emulators to mute all sound via either their menu or an option, although this might not be exactly what you need.

Well kind of... I was looking earlier, and although the 'official fix' of moving said object to The Hall without a shape is OK it seems the more I think about it, a "quick fix" , as ideally a shape would of been in order too. Thoughts then turned to simply moving it to the left and up a bit, so its sat at the top of the ramp, this way Willy cannot avoid an 'auto collect' moment no matter which side of Top Landing he falls from into First Landing. This way there's no need to give it a shape either as it won't be 'seen' normally. I did try this quickly with success although manual pokes to 'DIY' it instead afterwards out of curiosity did not quite work for some reason, but I've not looked into that in any detail. It would not be that different "in player mode" to the auto collect item in Swimming Pool even though that as we know is caused by the cell colours rather than its position. The collection is transparent (no pun intended!) to the player. Just seems a little bit easier as this way its not possible to miss it, as can happen if Willy happens to be jumping over the guardian or arrow etc in The Hall and with bad luck he could in theory miss the object completely... :unsure:

Welcome! :D The title screen or in game ? You can toggle in 'in game' music on/off via H,J,K,L or Enter. If you do not mind using a poke or two in an emulator you can turn it off a bit more permanently: Title Screen: POKE 37635,0: POKE 37636,0 In Game Tune: POKE 34904,0 : POKE 34905,0 Note these apply to this version (the Software Projects one) not the more commonly used Bug-Byte version. The 'jump' , 'fall' and 'accident' sound effects are still present but the four pokes above will effectively silence the 'tunes' as such.

I have read this although I do not fully understand it, I do appreciate the writeup as (like other things I've read) when knowledge is gained re-reading them and then they 'gel' perfectly. :)

I thought about this a while back, to be honest I've not examined every variant to see if it exists or not. In theory you could use multiple teleporters to do it but if you stop and think how this is done in other platform games (for random examples: Tech Ted, Spellbound, Pyjamarama etc) , its relatively simple: The 'exit ID' from the lift is simply set to a different level depending on what 'level' is chosen within. The problem here stems from some kind of patch vector to 'select' a floor as such. There is only every one 'lift' room anyway merely (as above) the exit is set to match a floor level: Any thoughts on this ? Its only a wild idea...

A new level (level 0) was added to the 'Builder' file: This 'new' level is intended to show the Trimmer action as such. No other code routines were removed. Details are available in that linked listing.

It does work well however it can cause much mayhem with JSWED it seems. I was able with a little bit of careful sprite movement to have a theoretical 71 or so rooms without any loss of sprite data (or moving them "out of normal range" either) simply by removing the gaps and re-arrangement. You'd have to either split the room data up and edit it peacemeal or more sensibly would be to set the first 9 or so rooms correctly, move them and then edit the rest of the game, with the finished code you'd then (in theory not tested) just add that room data section to the 'first' save. Final minor tweaks may be needed for which one of the elderly Basic editors would more than suffice I think as they would be very easy to modify to allow for the initial room data location. This method in theory means you'd get the advantage of 'friendly' JSWED to use for the majority of the game but you could also 'tidy up' (item location and oddities) the 'full set' afterwards with another editor. I will investigate this a bit closer as and when time allows. A more simpler 'fix' would be to permit JSWED to accept a different value for the room starting data instead of it being hardcoded to 49152... :unsure: hmmm

To slightly clarify on this: The 'keypad remover' is safe on third party games unless the area has been recycled already. It would be prudent to check this. it is provided for this purpose. The 'expanded' one is the one to use in 99% of cases as this removes the keypad as the 'remover' plus the garbage data (easily seen in JSWED) from the sprite area. This is the one to use on an original game before editing. It is likely to work on the majority of third party games too. Here is a comparison picture of the relevant section of the sprite area from JSWED when the 'expanded' one has been used: And two quick pics (in the download descriptor anyway) of it 'in action' Keypad only: Keypad and remnant: It should be noted no other 'unused' or otherwise data is removed, this 'extra' was merely to assist in the initial tidy up of the sprite area, nothing more. :)

View File JSW Keypad Trimmer A simple Basic program to remove the Keypad data completely from the JSW game code. Load in your game code, load the 'trimmer', run it and save the game code afterwards. Two versions are provided: 1. The basic keypad only version. This replaces the long pointless startup routine with a much shorter (32 bytes vs 10 bytes) and removes the following: The keypad messages "Enter code at grid location etc" - 64 bytes starting 34187 The keypad reading/display routines - 156 bytes starting 34463 The keypad graphics and attributes - 255 bytes starting 39680 The codes themselves - 178 bytes starting 40448 Note this does not remove (most) of the 'garbage data' sat in the sprite editing area as its not all stritcly keypad related. For that see (2) below... 2. The slightly extended version. This does not remove any 'unused routines' , it merely expands slightly on the above as some random data is present in the sprite area, this will remove it too. See the screenshot of the before/after for this. It is not recommended to use this one on a third party game before checking said areas have not already been recycled for sprite or other data however it is recommended to use this on a standard game before editing it. To clarify this, as well as the above the following are also emptied: Source remnant - 64 bytes starting 39936 Data remnant - 333 bytes starting 40627 Data remnant - 1152 bytes starting 42624 Submitter Spider Submitted 07/26/2017 Category Tools and Patches  

Slightly confused by that, although what you're saying (if I'm right?) is its more "item x" rather than "room x" that is going to trigger it. By this I mean regardless of room if its in that position in the item table = trigger

http://devserver.com/jswmm_ips45/files/file/99-%7B%3F%7D/

The 'modified' screens were mockups with paint. :) I've not directly tried that method no, perhaps adding a single cell lower down would 'fix' that. I see what you're saying though now. I have tried the 'two earth cell' method though. :thumbsup:

Oh its OK. :) I'm not saying there's anything wrong with doing it just I've been a bit wary of it as things potentially could get messy, a bit like a loop in a loop that jumps out of the 'outer' (outer not inner) then back again. :D

I was looking at this recently with some new and interesting thoughts... First of all lets take a look at the standard 'tree' on the Spectrum: The usual fault here is the earth cell on the right, preventing Willy from climbing the tree. However lets take an alternative view of this, what if that cell was intentional ? As it stands you cannot climb the tree even with the 'head height' concern, from either side. However if you add another earth cell thus: You *can* now climb the tree from the left side. It is very difficult to time it correctly however the jump between the platforms means he hits his head on the new earth cell, resulting in him being 'in' the water cells rather than just falling down. Its possible, I've done it. Another scenario although this one is very unlikely, how about adding some water cells a bit higher up ? This way he can climb from the left again and pass through to the right... As I say I think that is very unlikely. A more likely plausible case would be to question why there are currently 'useless' platforms on the left side halfway up. Lets take another scenario instead, assuming the 'single earth cell' in the tree is correct how about just adding a couple of water cell platforms on the left thus: Now, Willy can climb the tree but only from the Orangery. This seems reasonably plausible as its slightly tricky to reach that area anyway. It also means the ramp on the lower left is more a 'preview of the tree' than anything else. It does mean the right hand platforms are redundant however, but in the same way the left ones are currently. Food for thought (depending on what fruit the tree provides, assuming it is a fruit tree) ;) As a bit of amusement here is a large picture of the tree from a few different platforms. I've only covered the major versions and some variants look so similar (for example the Einstein version looks identical to the Spectrum completely) I left them out. Bear in mind the Spectrum version was obviously first so it was logical they used the same layout, however given the 'hidden / unreachable object' issue as well as things like the 'Conservatory Roof vs fire cell' item, it does not mean what we 'see today' is how it really was intended to be... No prizes for identifying each tree variant though. Finally here are the individual pics from that 'combi' above as it may be easier to view them this way:

I've always been a bit wary of this (generally) as you are sort of then reliant (as I see it at least) on the stack being correct so it knows 'where to go' , this is a bit like jumping into a GOSUB routine in a way when it his the RETURN it needs to have "somewhere" :) :unsure: I see what you're saying though.

I'll just leave this here... ;)

I got held up with other tasks however this did work very well for my tests, thank you. :)